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

[Owen DeLong <owen () delong com>]

> > 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.

Attachment: _bin
Description: