Re: IPv7 ...

[[e-mail] (Robert L Ullmann)]

Hi,

	Please explain how things work when an IPv7 host in one administrative
	domain wants to send a packet to an IPv7 host in a different AD, and
	the path must pass through IPv4-only hosts.  Exactly what does the
	IPv4 packet originated by the IPv7 source contain in its address fields
	and any added IPv4 options?

IP host delta.process.com (126.0.0.192.42.95.1.68) sending to (some
imaginary host) 104.5.6.200.1.1.1.17. When the datagram runs into the
first IPv4 host/router, it becomes:

source: 192.42.95.68	dest: 200.1.1.17   AE option (104.5.6/1, 126.0.0/1)

And this is routed in the IPv4 world. Note that (sect 10.1) IPv7 srip:

"An IPv7 host will be able to connect to another IPv7 host anywhere in
the internet even though most of the paths and routers are IPv4, and
still use the full addressing.  This will continue to work until
non-unique network numbers are assigned, by which time most of the
infrastructure should be IPv7."

I.e. as long as the "backbone" infrastructure is IPv4, the network
numbers still need to be unique. (But then that is almost a tautology :-)

--
	the role of an "address" once you have tuned addresses into EIDs.)  I
	don't see any frotzes in IPv7, so are you suggesting that IPv7 should
	be handled by doing global, flat routing?

Ah, could be. But I'm not exactly fond of that. More like binding
EID->routing info->FrI/FlowI setup. (You understand Nimrod, right?
Like nearly everyone else? :-) Better to say that there will end up
being some backstop at AD level (AD foo is NANP LATA 617/508*, it mostly
should be routed toward Eastern Massachusetts :-); a max of 10^7 flat
within and across ADs, and whatever local magic within each network.

(*note that a LATA is an _administrative_ entity, within the
delegation rooted in ITU authority.)

--
	This is something that puzzled me in your draft.  You claimed that the
	IPv4 address "class" system was designed to aid routing.  Where did you
	get that idea?  The "class" system simply allowed there to be more than
	256 (minus 1 or 2) IP network numbers, essentially increasing the size
	of the flat network number space.

Because it did something non-obvious at the time: represented the
catenet structure in the addresses. We take that for granted now, but
it was an explicit statement of: "we aren't going to route all IMPS
flat any more, there will be multiple catenated nets, and that
structure will be represented _thusly_."

Then we found there ought to be subnets, and supernets, and that the
catenet model was too limited, and with some pain eradicated the
assumptions built in to do catenet routing (static or whatnot.)

--
	I'm willing to believe that.  (I have myself advocated doing flat
	routing to tens of millions of sites within a metro area.)  But just
	saying "it isn't difficult" is not sufficient.  Please tell us exactly
	how networks should be planned and administered such that flat routing
	to 10^9 nets is feasible, and how we are going to move from our
	current technology base (in which 10,000 nets *is* a problem) to your
	proposed infrastructure, before the Internet melts.  (Please treat
	this as a request for education, not a disagreement.)

There are a few dozen different combinations, depending on what sort of
network you are using to do your backbone. (Which means it will be done
different ways :-) With something like SMDS, you might use RFC1183/sect3
DNS. With. say, the ISDN telephone net at a lower layer:

(I will ask a small understanding from people familiar with the NANP routing
area; I sin by oversimplifying, but I don't have the time to write the 200
page treatise needed to do justice ;-).

The NANP (North American Numbering Plan) area of the telephone network
consists of about 200,000 exchanges. (first simplification; we assume the
pre-NXX system is full, and treat multiple co-located exchanges as
distinct.) Each exchange has up to 10,000 physical subscriber circuits.

Just for fun: suppose you were using the physical inter-exchange cable plant
of the combined NANP area to provide direct IPv7 service, where each address
was 48:16 (net:host) with no internal syntax in the net number? (We'll
assume exactly 10^9 net access points.) We can share it with the voice
service, until the voice service is all running _over_ IP.

We look only at the "border problem": how do you locate all the connected
networks. Ma Bell already solved the (easier) interior problem: we have all
those lines labeled and routed.

You want your number routed? Fine, it will cost you $25/year admin fee for
each candidate access point (you want more than one, unless you are a single
residence, plugged to a single exchange), plus $10 for each change order.
Note these don't change fast, they change as physical access lines are
turned up or transit policies administratively altered. Just register it at
least one hour in advance. Send an EDI message.

Revenue: 25 Billion Dollars/Year.

Distribute the map of network number->circuit number (aka interior net
number:subscriber line) to all switches. Total information: 16 bytes * 1G
entries is 16 Gbytes. Use a DS3-rate spanning tree, replay the whole table
to all exchange centers every hour.

Datagrams are routed toward the nearest (in interior view) candidate access
point for the leaf network. If the access point selected is down, "tunnel"
(target-route) the traffic to another candidate access point for the net.

Best Regards,
Robert