IPv4 + IPv8 Addressing

Since NANOG people are generally experts about IPv4
and other networking topics. It might be easier to explain
the "IP handle" issues using more nitty gritty examples.

Imagine that most packets entering the IPv4 core transport
network are IPv8-style encapsulations. What you would have
on the data links would be....

  { [ IPv4 Header ] [ IPv8 Header ] } (payload)


  {} represents the combined IPv4/8 Header
  [] represents a 20 byte IPv4/8 header
  () represents the data or payload with other layers

If you look at the combined IPv4 and IPv8 headers you
will see that there are 40 bytes present. (assume no options)
In the IPv4 Header is all of the standard stuff including a
checksum and a 32 bit address field. In the IPv8 Header
there is no checksum and instead there is a 3+8+32 bit
address field (i.e.. 43 bits).

The address field for the combined IPv4/8 Header is
75 bits long...32+3+8+32 = 75.

Given this, it is important for NANOG planners to consider
what that IPv4 address really means. In the current IPv4 network
that 32 bit address is used by routers and hosts to route the
packet to the correct O/S that pulls the headers off and
routes the payload to the right processes or other parts
of the O/S.

In the future, that IPv4 32 bit address may not have the
same "meaning". Instead, it may become a tag or ASN-based
index which indicates where the packet shown above should
be gatewayed onto the IPv8 network. In an IPv8-only world,
in theory, large companies could have ONE IPv4 address
and that address could be reused over and over on major
networks that support a gateway to the IPv8 network.

If a 16 bit ASN is used as a convention to form the low
16 bits of that 32 bit IPv4 number, then the 75 bits become...

  16+16+3+8+32 or 16+ASN+3+8+32

OK...if you are still with me, let's look at what happens
when an IPv4/8 packet enters a large ISP's network
that supports a gateway to the IPv8 world. In this scheme
that ISP's routers look at the 16+ASN and find that
they have a specific route to a gateway to the IPv8 network.
The packet gets routed there and stripped of the IPv4
header and sent along with the 3+8+32 addressing.
Note that many ISPs can use the SAME 16+ASN
address as long as they dump the packet on to the
IPv8 network. Once that happens, that ISP has done
its job as an IPv4 core operator.

If the ISP does not have the specific information about
that 16+ASN address, then the IPv4/8 packet gets
routed on the global IPv4 core and eventually makes its
way to the router or host that supports that address and
that machine handles the gateway to the IPv8 network.
There of course is a huge performance difference in each
scenario. In the first case the ISP is smart enough to
have that specific 16+ASN routed directly to their gateway.
Large companies can pay key ISPs in certain areas to
trap those addresses and make sure that their packets
get this special handling. This is a revenue opportunity
for ISPs and large back-bone providers.

Returning to the concept of an IP address as a opaque
handle, one can see that in these scenarios the 16+ASN
component of the 75 bit IPv4/8 address is not really
a routable address in the current view of IPv4. Instead,
it can become an index or handle which is used to
identify the proper IPv4/8 gateway to use on the local

Now...you might be asking, how does the "system"
come up with these 16+ASN values to glue on the front
of the 3+8+32 packets ? In the system that I am working
on, the answer is...the IPv4 DNS...in other words, if
you are sitting on the outside of the IPv4 core transport
and you have 3+8+32 addresses, you ask the DNS to
give you a "route" or "handle" which is a good place to
send 3+8 traffic. The DNS returns a 32 bit 16+ASN value
and that is used in the first 32 bits of the 75 bit address.
Via the DNS, various 16+ASN values can be returned
and of course, time, and caching and the dynamics of
the changing network come into play.

All the people sitting on the outside "see" are the
3+8+32 bit addresses. The IPv4 core provides the DNS
and the 16+ASN based transport. In this way, we allow
the core to evolve to be a rock-solid fault-resilent network
run by people like yourselves, and a new Address
Management scheme can build around the edges using
familiar technologies and varying degrees of service
and reliability with the core largely transparent from a
day to day operational point of view...

Thanks for your time...

Jim Fleming
Unir Corporation
IBC, Tortola, BVI

Jim, et al,

  I think it might be a good idea to create seperate lists
  for experimental protocols such as IPv8, at least until
  such time as it's operationally relevant to all of us.