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) Where.... {} 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 machine. 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