[85894] in North American Network Operators' Group
Re: And Now for Something Completely Different (was Re: IPv6 news)
daemon@ATHENA.MIT.EDU (Tony Li)
Tue Oct 18 17:02:44 2005
In-Reply-To: <0671BEBE-6B04-4C1E-893D-26BB4A359AED@virtualized.org>
Cc: Paul Vixie <vixie@vix.com>, nanog@merit.edu
From: Tony Li <tony.li@tony.li>
Date: Tue, 18 Oct 2005 13:56:17 -0700
To: David Conrad <drc@virtualized.org>
Errors-To: owner-nanog@merit.edu
David,
>> A real locator/identifier separation requires a rewrite.
>
> Not necessarily. If you transition at the edge, what happens
> within the site matters only to the site and what matters to the
> core only matters to the core. No stacks, either core or edge,
> need to be rewritten.
Transitioning at the edge implies to me that the hosts need to know
about different semantics for the IPv6 header. That, in turn,
implies that there is different code for the hosts.
Alternately, if there is no new code anywhere, it's clear that you
must necessarily have the same semantics and must not have made a
change.
>> Any system that provided site-wide source address control was
>> going to require a rewrite.
>
> Not necessarily (depending on what you mean by the ambiguous term
> "address"). A lot depends on the actual requirements for source
> locator or identifier control.
Again, source address selection is going to require something
different than what we have today. The host might have to interact
with some centralized policy server, execute a selection algorithm,
or consult an oracle. Whatever that might be, there is new code
involved.
>> David, I should point out that if only a small number of folks
>> care about multihoming, then only a small number of folks need to
>> change their stacks.
>
> I thought all clients would have to be modified if they wanted to
> take full advantage of a shim6 enabled multi-homed server?
The keyword there is "full". Unmodified clients can still interact
with a multi-homed server in a legacy manner.
>> And even in your solution, there would need to be some changes to
>> the end host if you want to support exit point selection, or carry
>> alternate locators in the transport.
>
> One of the problems that I have seen in the IETF is calling desires
> "requirements". How important is exit point selection? Are there
> ways of implementing exit point selection without changing the IP
> stack? How critical is it that alternate locators be carried in
> the transport? Does the lack of that functionality make the
> protocol unusable?
>
> What _are_ the actual requirements (not the "Goals")? From my
> perspective, the really, really critical flaw in both IPv4 and IPv6
> is the lack of _transparent_ renumberability. Multi-homing is also
> a flaw, but less critical and I believe it can be addressed with
> the right solution to renumberability. A "few" folks worry about
> multi-homing. Everybody worries about end site renumbering.
As with any political process, the stated requirements are a function
of perspective. The stated requirements may or may not have anything
to do with reality, realizability, practicality, or architectural
elegance.
>> It's just a mess. I think that we all can agree that a real
>> locator/identifier split is the correct architectural direction,
>> but that's simply not politically tractable.
>>
> Right. And since it couldn't be done the right way in the
> protocol, we make the protocol much more complicated and force a
> reset to address functionality that relatively few folks need.
It could have been done the right way in the protocol, but it
wasn't. Yes, the result is that the subsequent 'work around'
solution is much more complicated than it could have been.
Again, between multihoming and mobility, the ubiquity and necessity
of Internet access, and the reliability of the last mile, this is not
going to remain a rare or even minority issue.
Regards,
Tony
