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: David Conrad
  • Date: Tue Oct 18 18:53:35 2005

Tony,

On Oct 18, 2005, at 1:56 PM, 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.

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.

No. The only code change that must occur is at the core/edge transition device _at both ends_. Let me try explaining this by example:

Assume you have:
- ISP A providing service to site X.
- ISP B providing service to site Y.
- ISP A has locator prefix A000::0
- ISP B has locator prefix B000::0
- Site X has identifier prefix 1000::0
- Site Y has identifier prefix 2000::0
- Host 1000::1 wants to send a packet to host 2000::2

Then:

1. Packet leaves host 1000::1 destined for 2000:2 and ends up at the site edge router for ISP A.
2. The site edge router for ISP A sees destination 2000:2 and looks up the locator in some globally distributed database using the identifier prefix 2000::0, getting back locator prefix B000::0.
3. The site edge router for ISP A rewrites the destination address with the locator prefix, i.e., B000::2.
4. The site edge router for ISP A forwards the packet to the next (core) hop for destination B000::2.
5. The site edge router for ISP B receives the packet destined for B000::2
6. The site edge router for ISP B rewrites the destination prefix with the identifier prefix, i.e., 2000::2
7. The site edge router for ISP B forwards the packet to the destination.

You want multi-homing? Site Y has two ISPs, each having their own locator prefix, e.g., ISP B (B000::0) and ISP C (C000::0). The lookup at step 2 returns two locators and the site edge router for ISP A can choose which path to take (perhaps with advice from the administrator of Site Y encoded in the response from the lookup, e.g., a preference or priority value). Transparent renumbering is obvious. Mobility might be possible with a little work and the old site edge router forwarding to the new site edge router for the duration of the cached response from the lookup.

No code changes within the site or within the core would be necessary.

Of course, the tricky bit is in looking up the locator in the globally distributed database and caching the response (which presumably would be necessary because the lookup will take a long time, relatively speaking). When a new 'conversation' between two hosts start, the initial packet will obviously have increased latency, but subsequent packets could rely on cached information.

Again, I realize this is a hack, but I suspect it is a hack that impacts fewer points than something like shim6.


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.

Well, yes, if source address selection is important. My point was that there didn't have to be new code in the IP stack.


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.

Hmm. Are the aliens who took the _real_ IETF and replaced it with what's there now going to give it back? :-)


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.

I grant additional complexity is necessary. However, additional complexity in every system seems like a bad idea to me.


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.

I very much agree.

Rgds,
-drc