asp writes:
| Or seperate the end system identifer from the routing goop. This
| solves lots of problems (while introducing others).
Right, so in the 8+8 model, some router performs a NAT function by
writing in the routing goop portion at an address abstraction boundary.
The host does not need to know the routing goop that will be used,
nor does it need to know the full routing goop associated with a
host from which it receives a packet.
However, I am wary of your terminology. Rather than a system
identifier, you instead want a local locator -- something that
is unique within the local addressing scope and which allows
other hosts and routers in the scope to locate the correct receiving
interface. The "routing goop" is a locator which is useful to
hosts outside the local addressing scope, and may vary from location
to location in the Internet.
In particular, if you follow the excellent posting by Anthony Atkieski
about variable-length addressing, you might find yourself agreeing
that in principle the "routing goop" may vary from place to place
not only by value, but also by length.
The NAT function is that which translates the "routing goop"
from "undefined" to something useful outside the originating
local addressing scope. It can also translate the "routing goop"
from one value to another. That translation can also be an extension;
e.g. changing "4321" into "654321".
The "system identifier" is either a locator (which is how I guess
you mean to use it) or an actual system name, which would behave
more like a DNS entry.
The IRTF's NSRG is looking at what the system name/endpoint identifier
should be, how it should be carried, how it can be used to determine
what locators to use, and so forth. It's a tricky problem in some ways.
If you overload these concepts and stuff the value into a packet,
(like 8+8), it could be a unique number (8 bytes long in this case).
In a given local routing scope we flat-route on those 8 byte addresses.
Outside that routing scope, you would not route on those 8 byte addresses
at all (you'd use the other 8 bytes of "routing goop").
If the "system identifier" 8 bytes are globally unique, than any
action where in IPv4 you operate on IP address as a way of identifying
a host, you would only use those 8 bytes. For example, the equivalent
of an IN-ADDR.ARPA lookup would use only those bytes, and none of the
routing goop bytes.
The NAT function then can be more restricted - it translates
only the "routing goop" part and not the "system identifier" part
of an 8+8 address. The "system identifier" 8 bytes is used by
end hosts to determine that they are talking to the same entities,
even though the "routing goop" has been adjusted one or more times
in flight between the two hosts.
This can all be emulated in IPv4 iff we have a separate namespace
for "system identifier" carried in a conversation somehow.
However, since it does make NAT much more straightforward, I do
not expect the bruised-knees brigade to admit or even recognize
the extra utility that such a namespace would bring to IPv6. -:(
Fortunately, and to scare Steve Deering again, there are some
bright and sane people who think most of IPv6 isn't so bad, and
who are willing to play nicely in NSRG in hopes of improving it.
This bodes well.
Sean.