Hi, I think it should be obvious from the discussions on this and other lists that the mapping considerations for any map/encaps scheme are the hard part. I think this has been known for a very long time, and I'm sure there are folks watching these discussions who are seeing issues rehashed that they have known about for years. As such, it might be worth considering whether a stateless mapping capability is possible.
As it turns out, for IPv6-in-IPv4 encapsulation a stateless mapping is possible when the IPv6 EID address embeds the IPv4 RLOC address. This is the case for schemes such as 6to4, 6rd and isatap. 6to4 in particular was designed to support router-to-router tunneling between DFZ routers, where the ITR can determine the ETR's RLOC through a simple stateless extraction of the RLOC from the EID. This eliminates the needs for a mapping database, delaying or dropping initial packets, alternate topologies, and other cumbersome aspects associated with stateful mapping. So, it might be worth asking whether a stateless mapping scheme such as 6to4's could be used. AFAICT, there are only a few aspects of 6to4 that would limit its applicability as a general solution for EID/RLOC separation in the DFZ. First, 6to4 uses a well-known prefix (WKP) that is rather long if the intention were to use it as the primary routing and addressing mechanism for IPv6 in the Internet DFZ. In particular, 2002::/16 occupies only 1/2^16th of the total IPv6 address space, which means that the rest of the space would expect to use some other form of IPv6 routing and addressing. This may have been an artifact of the original 6to4 design goal of providing only a transition mechanism. But, now that we are seeing proposals to have map/encaps solutions as a core aspect of routing and addressing in the Internet it may be worth revisiting those earlier assumptions. Secondly, each 6to4 IPv6 EID prefix is tied to a single IPv4 RLOC address. This means that if the IPv4 RLOC is down, then the entire IPv6 EID prefix is unreachable. It may be that a multi-addressing scheme would be able to switch gracefully between multiple IPv6 EID prefixes when one goes down, but there are obvious interactions for mobility, session continuity, etc. that would tend to favor a stable and highly-available IPv6 prefix. Thirdly, the ip-proto-41 encapsulation used by 6to4 may have suboptimal interactions with core Internet gear that expects to see only certain IP protocols. Additionally, there is no nonce field nor a bit field for negotiations between the ITR and ETR (e.g., an acknowledgement request bit). It should be easy to see that these shortcomings could be addressed through minor augmentations to the original 6to4 design (for now we can call it '6to4++') to allow for both stateless mapping and more robust communications. First, a much shorter IPv6 well-known prefix 'WKP::/N' could be procured for this stateless mechanism when a small value for N is chosen. When concatenated with the 32-bit IPv4 RLOC as 'WKP:V4ADDR::/(N+32)' this would still give a very short prefix to each holder of a public IPv4 address. Secondly, prefix availability could be greatly enhanced if multiple site border routers configured 'V4ADDR' as an IPv4 anycast address such that there would be multiple ETRs available for each IPv6 prefix. In that case, IPv4 routing in the DFZ would direct packets to the nearest available ETR. Finally, the WKP would serve as an indication that a new encapsulation format IPv6-in-(foo)-in-IPv4 is to be used. The (foo) layer could look very much like LISP, SEAL, etc. and it could contain nonces, bitfields, etc. that would make communications between the ITR and ETR more robust. The (foo) layer would also give a handle for the ETR to provide path MTU feedback to the ITR with a useable nonce. In general, I believe that the larger the mapping domain the more cumbersome stateful mapping becomes and the more beneficial stateless mapping becomes. As such, it might be worth considering whether a stateless mapping system via '6to4++' could be used in the Internet DFZ core. Any thoughts? Fred [email protected] _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
