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

Sun Nov 28 22:39:25 UTC 2004

On Sun, 28 Nov 2004, Paul Vixie wrote:

>
> > (catching up)
>
> (you missed some stuff.)

eh, so must I have, atleast about multi-homing :) I'll ask below.
(and yes, I'm still behind on the ipv6 reading I was supposed to do)

>
> > On 2004-11-22, at 18.52, Paul Vixie wrote:
> >
> > > (let me put it this way: A6/DNAME was shot down because of
> > > complexity, and it was simpler than this.)
> >
> > I am not convinced A6/DNAME would have solved all problems, not even
> > all of the ones you pointed out.
>
> 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.

There are all sorts of reasons, from a client side, why ipv6 seems like a
huge mess, this is but one of them. It seems to me that other things like
outage detection toward the provider specific addresses (uu is down and
att is up, too bad I tried to get to the uu address) might also be a
problem.

>From the server side things also seem extra-messy in v6:
1) forcing N DNS updates for each system address change (uu-forward,
mfn-forward, att-forward... and reverses if you care about that as well)
2) 'extra' server resources to serve extra zones with the same
information.
3) forcing urpf-like routing of traffic: uu out uu, att out att and mfn
out mfn off diverse routers upstream from the local LAN.

The world has been pushed toward multihoming of critical resources
(critical at multiple levels) over the last 10 years, forcing extra
complexity into v6 such that multihoming is now 'very difficult' (maybe
not for Paul or Mr. Rosen, but for many folks still) will delay the
rollout of v6 and it's acceptance.

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.

> such logic, it seems to me that MULTI6's only option is to make NAT work,
> even if you call it "site local addressing" or even "ULA's".  (show me.)

there are, and will be in the future, folks that WANT NAT, regardless of
the perceived 'badness' of it...

-Chris