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
- Re: And Now for Something Completely Different (was Re... Tony Li
-
