Agree. The deploying cost of IPv6 is quite expensive. I started to work on IPv6 and IPv6 transition since 2001. By that time, we optimistically thinkIPv6 could replace IPv4 in 2 or 3 years giving its maturity of basicprotocols and massive advantages. Now, I have to say that we underestimated the deploying cost, a lot. One more thing to be mentioned, IPv6 provides a lot transition approaches to support IPv4/IPv6 coexist. So far, I have not seen such efforts in HIP or Node ID. (I may volunteer to do so.) And in order to obtain the biggest benefit of HIP or Node ID, globally deployment is requested. Therefore, transition solutions may not solve the problems.One could consider doing a combination of adding a new namespace and deploying IPv6. If the cost of deployment is too great for putting IPv6 on hosts, then use IPv4 in hosts as the EID namespace and IPv6 deployed in the core as the locator namespace. If it is easier or more necessary to run IPv6 in the hosts, then the opposite could occur. In fact this later case is probably more necessary so we can have a larger address space that addresses all the hosts in the Internet with IPv6 EIDs and use locators as IPv4 addresses with an IPv4-only core substrate.I took a while to think this through, but I think the answer is that we should have a solution that is capable of doing *both* of these scenarios.
My prototype is doing v4-EIDs with v4-locators as well as v6-EIDs with v6-locators.
On my todo list is the "crossover". So which one should I do first, v4-EIDs-over-v6-locators or v6-EIDs-over-v4-locators?
Anyone else have an opinion?
Further, with all these different shapes and forms of identifier and locator in the picture, I think they are going to need to be tagged, so that the mapping and routing systems know what they are. You can't just send a 32 bit or 128 bit value and expect the receiving router to know by context what it is (in terms of its scope of validity). If you try to map an apple into a pear, you need to know that explicitly.
I think where you are in the topology defines the context (where you is an ITR, TE-ITR, TE-ETR, or ETR). That is, you supply an outer header based on the next-hop knowing how to route on the destination address.
Having said that, we can do things to avoid configuration errors. So if an IPv6 address is in the TLA for EIDs, we can make sure such addresses are not used as locators in config files or upon insertion into mapping databases.
How about the contentious issue of 240.0.0.0/4, should it be used as the TLA for the EID namespace for IPv4?
Dino -- to unsubscribe send a message to rrg-request@psg.com with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg