North American Network Operators Group
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: And Now for Something Completely Different (was Re: IPv6 news)

  • From: Tony Li
  • Date: Tue Oct 18 17:04:42 2005 

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