expansion on my note about IPv7 and EIDs

[Robert L Ullmann <[e-mail]>]

Hi,

This expands a little on a previous posting; I was told it was way
too concise trying to explain migrating IPv4/v7 addressing to EIDs.

---
Picking out one little bit from Noel to make a starting point:

	Date: Sat, 24 Apr 93 11:03:38 -0400
	From: [e-mail] (Noel Chiappa)

	Second, to the extent that it is clear *what* IP addresses *name*
	(since this was never made clear explicitly at the time the
	architecture was designed), it seems that they name *interfaces*.
	Sample test: a host with two interfaces has two IP addresses. ("If it
	walks like a duck, and quacks like a duck...."  :-)

Actually, it is more like "Since we call it a duck, it must be a duck!"
("Sooo... if she _weighs_ the same as a duck ... ", "yes ...", " ... she's
a witch!! Burn her!")

I disagree. We clearly have multiple interfaces to the same logical net
(which want the same address) and multiple networks present on the same
interface. (RFC791: "That is, provision must be made for a host to have
several physical interfaces to the network with EACH HAVING SEVERAL logical
internet addresses.")

What an IP address names is a host's logical presence on a network.

This has little or nothing to do with an "interface", except that they are
_sometimes_ one-to-one. (A good example is a single host slip-linked to a
LAN; the simplest thing to do is to give it a host number on the LAN's
network, and have the intermediary proxy-ARP. The point of the setup is to
give the host a logical presence on the LAN network; the address names that
presence.)

The idea that an interface has exactly one IP address was an ASSUMPTION, a
design decision made (without realization, I suspect) by the implementors
of the Berkeley Unix TCP/IP. (Or did they get it from a precursor?)

In my opinion, it was a very bad decision; it is painful to fix. (Now we
have "unnumbered interfaces", as though they were supposed to have numbers,
and "secondary addresses".) It led directly to the perversity of a
"loopback" address, to talk to the "loopback interface". Using all-zeros
(this host on this net) would have been, and still is, a better choice.
(Now you even see the perversity propagated into the DNS, with a name like
"localhost." for the address that shouldn't exist in the first place.)

Much better to have zero or more addresses for the host, and have a default
selected for each interface for selecting the transport layer source EID
(since the model does overload "address" and "EID" on the same number, as
Noel points out.) Zero or more you say? Sure, so even on an isolated host I
can do telnet 0.0.0.0.0.0.0.0.

---
There is another assumption made, by the logical fallacy of deriving
the converse.

The IP catenet model does say:

	"If a host has an address on network X, it can send directly
	 to any other host with an address on network X."

It does NOT say: (the converse)

	"If a host can send directly to a host with an address (only)
	 on network X, the host must have an address on network X."

Since it can't be derived, we can assign the truth value either way
(it is an independent axiom of the system), and we get two different
models:

The Strict Catenet Model:
	"If a host (only) on network X sends to a host (only) on
	 network Y, it must send through a host (router) that is
	 on both networks X and Y. (Or a series of such hosts.)"

The Loose Catenet Model:
	"A host may send directly to a host on a different network."

The latter is much more useful in the real world. There are some
implementations (a particular router comes to mind) that insist on the
strict model, and this forces assignment of addresses to hosts that really
don't need or want them. (It is amusing to watch such routers operating in
the belief that they are routing traffic between different logical nets on
the same physical cable, while all the hosts happily talk directly to each
other. :-)

A good example is X.25 and ISDN, where it is perfectly reasonable to
have the host talking directly to other hosts on thousands of other nets.

---
With the loose catenet model you don't need the inane business of
assigning "network" numbers to point-to-point links (and hence don't
need to configure any). The routing simply knows (e.g. learns via the
ordinary routing protocol) which networks are (best) reached by going
to the other end of the link. (One of my favorite quotes, Radia Perlman
in Interconnections, on not needing link addresses: "Hey, you! Yes, of
course, I mean you. Who else would I be talking to? The cable?" ;-)

When you are building a network of P-P links, like a WAN backbone, you
assign a net number to the local net in each switching center, and
a host number to each switch. (IMP/host :-)

---
Now that we don't have all those extraneous addresses around, we can
start doing proper Level I routing of them, treating them as EIDs.
(The routing tracks the location on the physical net of each fate-
sharing endpoint.)

---
Then if you have a routing protocol (like RAP) that can do Level I,
intra-area, and interdomain routing with the same protocol, you can start
letting those EIDs wander as far as your router thrust and authentication
can take you.

This moves to an even looser model, no longer described by catenated
networks: 
	"A host may be able to send directly to another host, or
	 maybe not."

--- 
The "address" now has the proper semantics of EIDs: they appear in the
datagrams for use by the transport layer and for use by the "entrance"
router to assign them to a flow or forward-route (you don't want every host
to have to do that, do you? Sure, _some_ will. Particularily if the host
wants to do a bandwidth-reserved flow, or wants to be able to check (ala
Perlman robust paths) that the datagram came via a particular path.)

The EIDs are tracked directly (to the limit of thrust/bandwidth,) or
indirectly by the routing layer. No, this isn't a requirement of the EID
concept, it is _one_way_ for the net to follow movements of EIDs. This is
the design choice made by IPv7/RAP.

They are assigned administrativly. Again, this is a design choice. Part of
the reason is to expand on the IPv4 EID assignment system rather than
changing the world; i.e. in IPv4, EIDs (one of the two overloaded functions
of the v4 "address") are in fact administrative assignments.

The other reason is that it is going to be useful for a long time to be
able to route blocks of these things, even though the eventual system may
be able to do pure EID->(DNS or something*)->path->destination.

(* See RFC1183 sect 3, and make _sure_ you look at reference [13] :-)

Yes, you detect another design choice. Say an application (session layer
for purists) wants to communicate with a remote process it knows by
name (delta.process.com/smtp). There are two possibilities:

	1) map name->(EID,pathID), then offer both EID (in the transport
	   header), and pathID (in the network header) to the network
	   service interface at each transmission. (If the EID is part
	   of the pathID, it just means it doesn't need to be in the
	   transport header.)

	2) map name->EID, offer EID to the network service interface,
	   the network service interface maps EID->pathID. The network
	   forwards on pathID.

IPv7 chooses the latter. Rationale: It means the session/transport doesn't
have to know about the pathIDs. The advantages are that the network service
isn't involved in the session/transport layer binding; that means it doesn't
have to be on the same machine, and doesn't need to know if higher layers
have retained the bound values.

Most end-node hosts won't use the pathID at all, relying on the entrance
router to do this. Which is a good thing, because most end nodes will be
IPv4 for a long time. Possibly some may be hybrid hosts, using IPv4 + the
v7AE option and enjoying universal connectivity.

With my Best Regards,
Robert