|
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)
Tony, On Oct 16, 2005, at 1:15 AM, Tony Li wrote: 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.A real locator/identifier separation requires a rewrite. 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. 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? 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. 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. I'm suggesting not mucking with the packet format anymore. It might be ugly, but it can be made to work until somebody comes up with IPv7. Instead, since the locator/identifier split wasn't done in the protocol, do the split in _operation_. Make the edge/core boundary real. Both edge and core could be addressed without hierarchy, but the mapping between the edge and core would change such that the edge would never be seen in the DFZ. Within the core, nothing new or different need be done (well, except for deploying IPv6 and running the core/edge translators). Within the edge, nothing new need be done either. Yes, it is a hack. But I suspect it would address the real requirements (or, at least my pet requirement :-)). Rgds, -drc
|