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

Re: OMB: IPv6 by June 2008

  • From: Sean Doran
  • Date: Fri Jul 08 19:42:39 2005 
Small detail:

On 6 Jul, 2005, at 16:30, David Conrad wrote:
If IPv6 had actually addressed one or more of routing scalability, multi-homing, or transparent renumbering
These are the same problem, looked at in different ways.

The issue is: graph-sorting scalability demands abstraction; abstraction demands abstraction boundaries; abstraction boundaries must be reflected in node names (i.e., locators); nodes are physically portable, topologically portable, or both.

To be fair, mass deployment of local wireless LANs for large numbers of people with portable equipment they carry with them from meeting to hotel room to coffee shop to airport lounge to home would not have been the obvious future for anyone in the ROAD process.

However, this is today's reality, and the movement of "named things" is more likely to increase than not.

"Stretchy LISes" has mostly hidden the physical portable aspect of named things. Bridging is ancient and well-understood.

Logical portability happens too, for individual named things and varying-sized collections of them.

The stretchy LIS approach works at a cost of header overhead and inefficient traffic flow. The widespread use of VPNs demonstrates this well.

The alternative is to deal with disjunctions between the named thing and its topological location.

Model A: you go from office to IETF meeting, the IP address you use to talk to the world stays the same, and comes from your office's address space. You use VPN technology to make this happen.

Model B: you go from office to IETF meeting, and the IP address you use to talk to the world comes from the IETF meeting's address space.

Now go to your hotel room. Model A: your socket-like things are still bound to the office address, and if you walked briskly enough, your sessions are likely still alive when you reconnect to your office with the VPN tech.

Model B: oops, you have a new address. You can't use the old address. Your sessions are very likely toast. Good thing there are tools like screen(1) and restartable ftp!

The difference between A and B is independent of the header formats, so long as the named thing normally overloads its identity and location.

Model A allows for a disjunction between the identity and location, by bridging through the real topology to connect to a distant collection of addresses, abstracted via variable-length prefixes.

Model B does not allow for a disjunction in the absence of a session protocol, in which case the session layer identifier is the named thing, and the current IP address is the locator.

The session layer does not have to be particularly heavyweight, it does not have to be distinctly "above" the network and transport layers, it does not have to be the only session support available to the other protocols in use between communicating entities.

Integrating renumbering-adaptability within the lower (N/T) has some attractions especially with regard to preserving the traditional datagram and octet-stream modes, reducing the peer-to-peer handshaking in the event of renumbering of one of the parties, and in leveraging the current DNS architecture.

It would also eliminate the market need for NAT as a tool to assist in -- or avoid -- large-scale simultaneous renumbering as when a single-homed site switches ISPs.

Instead, IPv6 dealt with a problem that, for the most part, does not immediately affect the US market but which (arguably) does affect the other regions. I guess you can, if you like, blame it on the accountants...
People should blame it on the multiplexors.

There is lots of scope for multiplexing address use: not everyone is awake and powered on simultaneously; not everyone really does need to accept inbound connections from *everywhere*, at least not all the time; not everyone needs to run a particular service on the same numbered port; some services are fine with uniqueness involving network-layer-addresss+protocol+port(+possible other things).

NAT, like other forms of multiplexing the Internet has benefited from (e.g. TDM, WDM, time-sharing operating systems, ...), can allow for more efficient in one's use of limited resources -- in this case, aggregated address space -- in a way accountants seem able to cope with. Yes, TANSTAAFL.

Sean.