RE: [RRG] What does incremental deployment mean

["Templin, Fred L" <Fred.L.Templin@boeing.com>]

>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
fred.l.templin@boeing.com

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 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