>ISATAP is indeed an interesting point. However, there is still some work to >do for ISATAP to act as a scalable Internet routing architecture.
ISATAP was designed as an *intra-site* map-and-encaps architecture, where the traditional view of "site" deals with connected network regions that occur at the edges, e.g., a home network, a corporate enterprise network, a MANET, etc. But, the interdomain routing core can also be considered a "site" of sorts, so it is possible the domain of application should be widened. >Suppose >that the whole Internet is composed of many independent IPv4 address spaces, >which are connected via ISATAP routers. Let's think of the Internet as a gigantic inner site that connects outer edge sites that have ISATAP routers at their borders. The ISATAP routers have global IPv4 addresses assigned on their Internet-facing interfaces, private IPv4 addresses assigned on their site-internal IPv4 interfaces, and link-local IPv6 addresses assigned on their site-internal ISATAP interfaces (which are virtual interfaces configured over the site-internal IPv4 interfaces). When an ISATAP router for edge site A needs to forward an IPv6 packet to node X in edge site B, some Internet wide map-and-encaps scheme (e.g., LISP) will determine the global IPv4 locator for the ISATAP router at site B. When the ISATAP router at site B receives the packet, it will in turn do an edge site-internal map-and-encaps to determine the private IPv4 locator for a dual-stack router within the site that serves node X. So, there are (at least) two levels of map-and-encaps and two levels of IPv4 locators; the first within the Internet core and the second at the edge site-interal level. >The ISATAP router still needs to >route packets based on the EID (IPv6), which is not scalable since the EID >should be topology-irrelevant. As described above, it is (at least) two levels of IPv4 map-and-encaps, followed by a single level of IPv6 routing within the edge site. The IPv6 address is only an EID up until the ultimate edge of the edge site, where it may also serve as an RLOC within a limited IPv6 edge routing domain. >Besides, in a multi-homed IPv4-enabled site >network, the dual-stack host will obtain multiple IPv6 addresses from >different ISATAP gateways, which one should be used as EID? Obtaining IPv6 addresses for assignment on ISATAP interfaces through SLAAC is one alternative, but obtaining IPv6 prefixes for assignment on other site-internal interfaces (including loopback interfaces) may be the preferred method. (Note that /128s can be obtained through prefix delegation the same as for any IPv6 prefix.) But that said, I agree there is a gateway aggregation consideration for the ISATAP gateways of multi-homed sites. Failing a gateway aggregation mechanism, the dual-stack end-system (host or router) should use the ISATAP router that delegated its IPv6 prefixes as its egress gateway to the Internet (e.g., due to uRPF checking). The gateway aggregation solution space is being addressed in the IETF AUTOCONF working group. Thanks - Fred [EMAIL PROTECTED] PS Although the above is couched solely in terms of map-and-encaps, ISATAP still works within the edge sites whether the Internet core is using map-and-encaps or some form of global IPv6 routing. >Best wishes, >Xiaohu XU -- to unsubscribe send a message to [EMAIL PROTECTED] 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
