who gets a /32 [Re: IPV6 renumbering painless?]

Mon Nov 29 09:20:14 UTC 2004

>> the property of a6/dname that wasn't widely understood was its intrinsic
>> multihoming support.  the idea was that you could go from N upstreams to
>> N+1 (or N-1) merely by adding/deleting DNAME RRs.  so if you wanted to
>> switch from ISP1 to ISP2 you'd start by adding a connection to ISP2, then
>> add a DNAME for ISP2, then delete the DNAME for ISP1, then disconnect
>> ISP1.
>>
>
> This makes some sense, however, how does the client system know which
> address it should use? what lets the client know that the path from
> client->server-address-ATT is better/worse/same as the path from
> client->server-address-MFN or client->server-address-uu ? I would think
> that the 'best' solution for all parties would be 'one' address for an end
> system, or one path to the end system.
>
Because when it matters, the administrator of the zone has the option of
removing the DNAME records for the provider that is sucking at the moment.
Not a panacea, but, at least help.

Single address may or may not be the best solution.  One path to end system
is definitely NOT the right answer for everyone.  More paths is less 
failure.

> Perhaps this is just 'normal' technology acceptance process, and perhaps
> I'm missing a great many things in 'the v6-way', but if the multihoming
> can't be worked out in a sane manner I can't see rollout and acceptance of
> v6 coming any time soon.
>
Apparently, you are, because, the whole DNAME/A6 thing was deprecated and
we were lamenting that it's existence would have made this somewhat simpler
to administer.

> there are, and will be in the future, folks that WANT NAT, regardless of
> the perceived 'badness' of it...
>
Why?  You still have yet to justify this position.

Owen

-- 
If it wasn't crypto-signed, it probably didn't come from me.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20041129/1a13dd13/attachment.sig>