Network Working Group F. Templin
Internet-Draft Boeing Research & Technology
Intended status: Informational May 26, 2011
Expires: November 25, 2011

Operational Guidance for IPv6 Deployment in IPv4 Sites using ISATAP
draft-templin-v6ops-isops-07.txt

Abstract

Many end user sites in the Internet today still have predominantly IPv4 internal infrastructures. These sites range in size from small home/office networks to large corporate enterprise networks, but share the commonality that IPv4 continues to provide satisfactory internal routing and addressing services for most applications. As more and more IPv6-only services are deployed in the Internet, however, end user devices within such sites will increasingly require at least basic IPv6 functionality for external access. It is also expected that more and more IPv6-only devices will be deployed within the site over time. This document therefore provides operational guidance for deployment of IPv6 within predominantly IPv4 sites using the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP).

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http:/⁠/⁠datatracker.ietf.org/⁠drafts/⁠current/⁠.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on November 25, 2011.

Copyright Notice

Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http:/⁠/⁠trustee.ietf.org/⁠license-⁠info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.


Table of Contents

1. Introduction

End user sites in the Internet today currently use IPv4 routing and addressing internally for core operating functions such as web browsing, filesharing, network printing, e-mail, teleconferencing and numerous other site-internal networking services. Such sites typically have an abundance of public or private IPv4 addresses for internal networking, and are separated from the public Internet by firewalls, packet filtering gateways, proxies, address translators and other site border demarcation devices. To date, such sites have had little incentive to enable IPv6 services internally [RFC1687].

End-user sites that currently use IPv4 services internally come in endless sizes and varieties. For example, a home network behind a Network Address Translator (NAT) may consist of a single link supporting a few laptops, printers etc. As a larger example, a small business may consist of one or a few offices with several networks connecting considerably larger numbers of computers, routers, handheld devices, printers, faxes, etc. Moving further up the scale, large banks, restaurants, major retailers, large corporations, etc. may consist of hundreds or thousands of branches worldwide that are tied together in a complex global enterprise network. Additional examples include personal-area networks, mobile vehicular networks, disaster relief networks, tactical military networks, and various forms of Mobile Ad-hoc Networks (MANETs). These cases and more are discussed in RANGERS[RFC6139].

With the proliferation of IPv6 devices in the public Internet, however, existing IPv4 sites will increasingly require a means for enabling IPv6 services so that hosts within the site can communicate with IPv6-only correspondents. Such services must be deployable with minimal configuration, and in a fashion that will not cause disruptions to existing IPv4 services. The Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) [RFC5214] provides a simple-to-use service that sites can deploy in the near term to meet these requirements. This document therefore provides operational guidance for using ISATAP to enable IPv6 services within predominantly IPv4 sites while causing no disruptions to existing IPv4 services.

2. Enabling IPv6 Services using ISATAP

Many existing sites within the Internet predominantly use IPv4-based services for their internal networking needs, but there is a growing requirement for enabling IPv6 services to support communications with IPv6-only correspondents. Smaller sites that wish to enable IPv6 typically arrange to obtain public IPv6 prefixes from an Internet Service Provider (ISP), where the prefixes may be either purely native or the near-native prefixes offered by 6rd [RFC5969]. Larger sites typically obtain provider independent IPv6 prefixes from an Internet registry and advertise the prefixes into the IPv6 routing system on their own behalf, i.e., they act as an ISP unto themselves. In either case, after obtaining IPv6 prefixes the site can automatically enable IPv6 services internally by configuring ISATAP.

The ISATAP service uses a Non-Broadcast, Multiple Access (NBMA) tunnel virtual interface model [RFC2491][RFC2529] based on IPv6-in-IPv4 encapsulation [RFC4213]. The encapsulation format can further use Differentiated Service (DS) [RFC2983] and Explicit Congestion Notification (ECN) [RFC3168] mapping between the inner and outer IP headers to ensure expected per-hop behavior within well-managed sites.

The ISATAP service is based on three basic node types known as advertising ISATAP routers, non-advertising ISATAP routers and ISATAP hosts. Advertising ISATAP routers configure their site-facing ISATAP interfaces as advertising router interfaces (see: [RFC4861], Section 6.2.2). Non-advertising ISATAP routers configure their site-facing ISATAP interfaces as non-advertising router interfaces and obtain IPv6 addresses/prefixes via autoconfiguration exchanges with advertising ISATAP routers. Finally, ISATAP hosts configure their site-facing ISATAP interfaces as simple host interfaces and also coordinate their autoconfiguration operations with advertising ISATAP routers. In this sense, advertising ISATAP routers are "servers" while non-advertising ISATAP routers and ISATAP hosts are "clients" in the service model.

Advertising ISATAP routers arrange to add their IPv4 address to the Potential Router List (PRL) within the site name service. The name service could be either the DNS or some other site-internal name resolution system, but the PRL should be published in such a way that ISATAP clients can resolve the name "isatap.domainname" for the "domainname" suffix associated with their attached link. For example, if the domainname suffix associated with an ISATAP client's attached link is "example.com", then the name of the PRL for that link attachment point is "isatap.example.com". Alternatively, if the site name service is operating without a domainname suffix, then the name of the PRL is simply "isatap". (In either case, however, site administrators should ensure that the name resolution returns IPv4 addresses of advertising ISATAP routers that are topologically close to each ISATAP client depending on their locations.)

After the PRL is published, ISATAP clients within the site will automatically perform a standard IPv6 Neighbor Discovery Router Solicitation (RS) / Router Advertisement (RA) exchange with advertising ISATAP routers [RFC4861][RFC5214]. Each ISATAP client can also test the round-trip delays to multiple advertising ISATAP routers listed in the PRL during an initial exchange, and select those routers with the smallest delays. Alternatively, site administrators could include an IPv4 anycast address in the PRL and assign the address to multiple advertising ISATAP routers. In that case, IPv4 routing within the site would direct the ISATAP client to the nearest advertising ISATAP router.

Following router discovery, ISATAP clients initiate Stateless Address AutoConfiguration (SLAAC) [RFC4862][RFC5214], the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [RFC3315] or both.

3. SLAAC Services

Predominantly IPv4 sites can enable SLAAC services for ISATAP clients that need to communicate with IPv6 correspondents. SLAAC services are enabled using either the "shared" or "individual" prefix model. In the shared prefix model, all advertising ISATAP routers advertise a common prefix (e.g., 2001:db8::/64) to ISATAP clients within the site. In the individual prefix model, advertising ISATAP router advertise individual prefixes (e.g., 2001:db8:0:1::/64, 2001:db8:0:2::/64, 2001:db8:0:3::/64, etc.) to ISATAP clients within the site. Note that combinations of the shared and individual prefix models are also possible, in which some of the site's ISATAP routers advertise shared prefixes and others advertise individual prefixes

The following sections discuss operational considerations for enabling ISATAP SLAAC services within predominantly IPv4 sites.

3.1. Advertising ISATAP Router Behavior

Advertising ISATAP routers that support SLAAC services send RA messages in response to RS messages received on an advertising ISATAP interface. SLAAC services are enabled when advertising ISATAP routers advertise non-link-local IPv6 prefixes in Prefix Information Options (PIOs) with the A flag set to 1[RFC4861]. When there are multiple advertising ISATAP routers, the routers can advertise a shared IPv6 prefix or individual IPv6 prefixes.

3.2. Non-Advertising ISATAP Router Behavior

Non-advertising ISATAP routers that engage in SLAAC behave the same as for hosts (see below).

3.3. ISATAP Host Behavior

ISATAP hosts resolve the PRL and send RS messages to obtain RA messages from an advertising ISATAP router. When the host receives RA messages, it uses SLAAC to configure IPv6 addresses from any advertised prefixes with the A flag set to 1 as specified in [RFC4862][RFC5214] then assigns the addresses to the ISATAP interface. The host also assigns any of the advertised prefixes with the L flag set to 1 to the ISATAP interface.

Any IPv6 addresses configured in this fashion and assigned to an ISATAP interface are known as ISATAP addresses.

3.4. Reference Operational Scenario - Shared Prefix Model

Figure 1 depicts a reference ISATAP network topology for allowing hosts within a predominantly IPv4 site to configure ISATAP services using SLAAC with the shared prefix model. The scenario shows two advertising ISATAP routers ('A', 'B'), two ISATAP hosts ('C', 'D'), and an ordinary IPv6 host ('E') outside of the site in a typical deployment configuration. In this model, routers 'A' and 'B' both advertise the same (shared) IPv6 prefix 2001:db8::/64 into the IPv6 routing system, and also advertise the prefix to ISATAP clients within the site for SLAAC purposes.

               .-(::::::::)      2001:db8:1::1
            .-(::: IPv6 :::)-.  +-------------+
           (:::: Internet ::::) | IPv6 Host E |
            `-(::::::::::::)-'  +-------------+
               `-(::::::)-'
   +------------+       +------------+
   |  Router A  |---.---|  Router B  |.
  ,|  (isatap)  |       |  (isatap)  | `\
 . | 192.0.2.1  |       | 192.0.2.1  |   \
 / +------------+       +------------+    \
:  fe80::*:192.0.2.17   fe80::*:192.0.2.33 :
 \  2001:db8::/64        2001:db8::/64    /
  :                                      :
   :                                   :
   +-             IPv4 Site         -+
  ;            (PRL: 192.0.2.1)       :
  |                                   ;
  :                                -+-'
   `-.                              .)
      \                           _)
       `-----+--------)----+'----'
   fe80::*:192.0.2.18         fe80::*:192.0.2.34
 2001:db8::*:192.0.2.18     2001:db8::*:192.0.2.34
  +--------------+           +--------------+
  |   (isatap)   |           |   (isatap)   |
  |    Host C    |           |    Host D    |
  +--------------+           +--------------+

(* == "5efe")

Figure 1: Reference ISATAP Network Topology using Shared Prefix Model

With reference to Figure 1, advertising ISATAP routers 'A' and 'B' within the IPv4 site connect to the IPv6 Internet either directly or via a companion gateway (e.g., as shown in Figure 3). The routers advertise the shared prefix 2001:db8::/64 into the IPv6 Internet routing system either as a singleton /64 or as part of a shorter aggregated IPv6 prefix if the routing system will not accept prefixes as long as a /64. For the purpose of this example, we also assume that the IPv4 site is configured within multiple IPv4 subnets - each with an IPv4 prefix length of /28.

Advertising ISATAP routers 'A' and 'B' both configure the IPv4 anycast address 192.0.2.1, e.g., on a loopback interface, and the site administrator places the single IPv4 address 192.0.2.1 in the PRL for the site. 'A' and 'B' then both advertise the anycast address/prefix into the site's IPv4 routing system so that ISATAP clients can locate the router that is topologically closest.

Advertising ISATAP router 'A' next configures a site-interior IPv4 interface with address 192.0.2.17 and netmask /28, then configures an advertising ISATAP router interface with link-local ISATAP address fe80::5efe:192.0.2.17 over the IPv4 interface. In the same fashion, 'B' configures a site-interior IPv4 interface with address 192.0.2.33/28, then configures its advertising ISATAP router interface with link-local ISATAP address fe80::5efe:192.0.2.33.

ISATAP host 'C' connects to the site via an IPv4 interface with address 192.0.2.18/28, and also configures an ISATAP host interface with link-local ISATAP address fe80::5efe:192.0.2.18 over the IPv4 interface. 'C' next resolves the PRL, and sends an IPv6-in-IPv4 encapsulated RS message to the IPv4 address 192.0.2.1, where IPv4 routing will direct it to the closest of either 'A' or 'B'. Assuming 'A' is closest, 'C' receives an RA from 'A' then configures a default IPv6 route with next-hop address fe80::5efe:192.0.2.17 via the ISATAP interface and processes the IPv6 prefix 2001:db8::/64 advertised in the PIO. If the A flag is set in the PIO, 'C' uses SLAAC to automatically configure the ISATAP address 2001:db8::5efe:192.0.2.18 and assigns the address to the ISATAP interface. If the L flag is set, 'C' also assigns the prefix 2001:db8::/64 to the ISATAP interface.

In the same fashion, ISATAP host 'D' configures its IPv4 interface with address 192.0.2.34/28 and configures its ISATAP interface with link-local ISATAP address fe80::5efe:192.0.2.34. 'D' next performs an anycast RS/RA exchange that is serviced by 'B', then uses SLAAC to autoconfigure the ISATAP address 2001:db8::5efe:192.0.2.34 and a default IPv6 route with next-hop address fe80::5efe:192.0.2.33. Finally, IPv6 host 'E' connects to an IPv6 network outside of the site. 'E' configures its IPv6 interface in a manner specific to its attached IPv6 link, and autoconfigures the IPv6 address 2001:db8:1::1.

Following this autoconfiguration, when host 'C' inside the site has an IPv6 packet to send to host 'E' outside the site, it prepares the packet with source address 2001:db8::5efe:192.0.2.18 and destination address 2001:db8:1::1. 'C' then uses IPv6-in-IPv4 encapsulation to forward the packet to the link-local address of its default router 'A' (i.e., fe80::5efe:192.0.2.17). 'A' in turn decapsulates the packet and forwards it into the public IPv6 Internet where it will be conveyed to 'E' via normal IPv6 routing. In the same fashion, host 'D' uses IPv6-in-IPv4 encapsulation via its default router 'B' to send IPv6 packets to IPv6 Internet hosts such as 'E'.

When host 'E' outside the site sends IPv6 packets to ISATAP host 'C' inside the site, the IPv6 routing system may direct the packet to either of 'A' or 'B'. If the site is not partitioned internally, the router that receives the packet can use ISATAP to statelessly forward the packet directly to 'C'. If the site may be partitioned internally, however, the packet must first be forwarded to 'C's serving router based on IPv6 routing information. This implies that, in a partitioned site, the advertising ISATAP routers must connect within a full or partial mesh of IPv6 links, and must either run a dynamic IPv6 routing protocol or configure static routes so that incoming IPv6 packets can be forwarded to the correct serving router.

In this example, 'A' can configure the IPv6 route 2001:db8::5efe:192.0.2.32/124 with the IPv6 address of the next hop toward 'B' in the mesh network as the next hop, and 'B' can configure the IPv6 route 2001:db8::5efe:192.0.2.16/124 with the IPv6 address of the next hop toward 'A' as the next hop. (Notice that the /124 prefixes properly cover the /28 prefix of the IPv4 address that is embedded within the IPv6 ISATAP address.) In that case, when 'A' receives a packet from the IPv6 Internet with destination address 2001:db8::5efe:192.0.2.34, it first forwards the packet toward 'B' over an IPv6 mesh link. 'B' in turn uses ISATAP to forward the packet into the site, where IPv4 routing will direct it to 'D'. In the same fashion, when 'B' receives a packet from the IPv6 Internet with destination address 2001:db8::5efe:192.0.2.18, it first forwards the packet toward 'A' over an IPv6 mesh link. 'A' then uses ISATAP to forward the packet into the site, where IPv4 routing will direct it to 'C'.

Finally, when host 'C' inside the site connects to host 'D' inside the site, it has the option of using the native IPv4 service or the ISATAP IPv6-in-IPv4 encapsulation service. When there is operational assurance that IPv4 services between the two hosts are available, the hosts may be better served to continue to use legacy IPv4 services in order to avoid encapsulation overhead and to avoid any IPv4 protocol-41 filtering middleboxes that may be in the path. If 'C' and 'D' may be in different IPv4 network partitions, however, IPv6-in-IPv4 encapsulation should be used with one or both of routers 'A' and 'B' serving as intermediate gateways.

3.5. Reference Operational Scenario - Individual Prefix Model

Figure 2 depicts a reference ISATAP network topology for allowing hosts within a predominantly IPv4 site to configure ISATAP services using SLAAC with the individual prefix model. The scenario shows two advertising ISATAP routers ('A', 'B'), two ISATAP hosts ('C', 'D'), and an ordinary IPv6 host ('E') outside of the site in a typical deployment configuration. In the figure, ISATAP routers 'A' and 'B' both advertise different prefixes taken from the aggregated prefix 2001:db8::/48, with 'A' advertising 2001:db8:0:1::/64 and 'B' advertising 2001:db8:0:2::/64.

               .-(::::::::)      2001:db8:1::1
            .-(::: IPv6 :::)-.  +-------------+
           (:::: Internet ::::) | IPv6 Host E |
            `-(::::::::::::)-'  +-------------+
               `-(::::::)-'
   +------------+       +------------+
   |  Router A  |---.---|  Router B  |.
  ,|  (isatap)  |       |  (isatap)  | `\
 . | 192.0.2.1  |       | 192.0.2.1  |   \
 / +------------+       +------------+    \
:  fe80::*:192.0.2.17   fe80::*:192.0.2.33 :
 \ 2001:db8:0:1::/64    2001:db8:0:2::/64  /
  :                                      :
   :                                   :
   +-             IPv4 Site         -+
  ;            (PRL: 192.0.2.1)       :
  |                                   ;
  :                                -+-'
   `-.                              .)
      \                           _)
       `-----+--------)----+'----'
   fe80::*:192.0.2.18         fe80::*:192.0.2.34
2001:db8:0:1::*:192.0.2.18  2001:db8:0:2::*:192.0.2.34
  +--------------+           +--------------+
  |   (isatap)   |           |   (isatap)   |
  |    Host C    |           |    Host D    |
  +--------------+           +--------------+

(* == "5efe")

Figure 2: Reference ISATAP Network Topology using Individual Prefix Model

With reference to Figure 2, advertising ISATAP routers 'A' and 'B' within the IPv4 site connect to the IPv6 Internet either directly or via a companion gateway (e.g., as shown in Figure 3). Router 'A' advertises the individual prefix 2001:db8:0:1::/64 into the IPv6 Internet routing system, and router 'B' advertises the individual prefix 2001:db8:0:2::/64. The routers could instead both advertise a shorter shared prefix such as 2001:db8::/48 into the IPv6 routing system, but in that case they would need to configure a mesh of IPv6 links between themselves in the same fashion as described for the shared prefix model in Section 3.4. For the purpose of this example, we also assume that the IPv4 site is configured within multiple IPv4 subnets - each with an IPv4 prefix length of /28.

Advertising ISATAP routers 'A' and 'B' both configure the IPv4 anycast address 192.0.2.1, e.g., on a loopback interface, and the site administrator places the single IPv4 address 192.0.2.1 in the PRL for the site. 'A' and 'B' then both advertise the anycast address/prefix into the site's IPv4 routing system so that ISATAP clients can locate the router that is topologically closest.

Advertising ISATAP router 'A' next configures a site-interior IPv4 interface with address 192.0.2.17/28, then configures an advertising ISATAP router interface with link-local ISATAP address fe80::5efe:192.0.2.17 over the IPv4 interface. In the same fashion, 'B' configures the IPv4 interface address 192.0.2.33/28, then configures its advertising ISATAP router interface with link-local ISATAP address fe80::5efe:192.0.2.33.

ISATAP host 'C' connects to the site via an IPv4 interface with address 192.0.2.18/28, and also configures an ISATAP host interface with link-local ISATAP address fe80::5efe:192.0.2.18 over the IPv4 interface. 'C' next resolves the PRL, and sends an IPv6-in-IPv4 encapsulated RS message to the IPv4 address 192.0.2.1, where IPv4 routing will direct it to the closest of either 'A' or 'B'. Assuming 'A' is closest, 'C' receives an RA from 'A' then configures a default IPv6 route with next-hop address fe80::5efe:192.0.2.17 via the ISATAP interface and processes the IPv6 prefix 2001:db8:0:1::/64 advertised in the PIO. If the A flag is set in the PIO, 'C' uses SLAAC to automatically configure the ISATAP address 2001:db8:0:1::5efe:192.0.2.18 and assigns the address to the ISATAP interface. If the L flag is set, 'C' also assigns the prefix 2001:db8:0:1::/64 to the ISATAP interface.

In the same fashion, ISATAP host 'D' configures its IPv4 interface with address 192.0.2.34/28 and configures its ISATAP interface with link-local ISATAP address fe80::5efe:192.0.2.34. 'D' next performs an anycast RS/RA exchange that is serviced by 'B', then uses SLAAC to autoconfigure the ISATAP address 2001:db8:0:2::5efe:192.0.2.34 and a default IPv6 route with next-hop address fe80::5efe:192.0.2.33. Finally, IPv6 host 'E' connects to an IPv6 network outside of the site. 'E' configures its IPv6 interface in a manner specific to its attached IPv6 link, and autoconfigures the IPv6 address 2001:db8:1::1.

Following this autoconfiguration, when host 'C' inside the site has an IPv6 packet to send to host 'E' outside the site, it prepares the packet with source address 2001:db8:0:1::5efe:192.0.2.18 and destination address 2001:db8:1::1. 'C' then uses IPv6-in-IPv4 encapsulation to forward the packet to the link-local ISATAP address of 'A' (fe80::5efe:192.0.2.17), where 'A' in turn decapsulates the packet and forwards it into the public IPv6 Internet where it will be conveyed to 'E' via normal IPv6 routing. In the same fashion, host 'D' uses IPv6-in-IPv4 encapsulation via its default router 'B' to send IPv6 packets to IPv6 Internet hosts such as 'E'.

When host 'E' outside the site sends IPv6 packets to ISATAP host 'C' inside the site, the IPv6 routing system will direct the packet to 'A' since 'A' advertises the individual prefix that matches 'C's destination address. 'A' can then use ISATAP to statelessly forward the packet directly to 'C'. If 'A' and 'B' both advertise the shared shorter prefix 2001:db8::/48 into the IPv6 routing system, however packets coming from 'E' may be directed to either 'A' or 'B'. In that case, the advertising ISATAP routers must connect within a full or partial mesh of IPv6 links the same as for the shared prefix model, and must either run a dynamic IPv6 routing protocol or configure static routes so that incoming IPv6 packets can be forwarded to the correct serving router.

In this example, 'A' can configure the IPv6 route 2001:db8:0:2::/64 with the IPv6 address of the next hop toward 'B' in the mesh network as the next hop, and 'B' can configure the IPv6 route 2001:db8:0.1::/64 with the IPv6 address of the next hop toward 'A' as the next hop. Then, when 'A' receives a packet from the IPv6 Internet with destination address 2001:db8:0:2::5efe:192.0.2.34, it first forwards the packet toward 'B' over an IPv6 mesh link. 'B' in turn uses ISATAP to forward the packet into the site, where IPv4 routing will direct it to 'D'. In the same fashion, when 'B' receives a packet from the IPv6 Internet with destination address 2001:db8:0:1::5efe:192.0.2.18, it first forwards the packet toward 'A' over an IPv6 mesh link. 'A' then uses ISATAP to forward the packet into the site, where IPv4 routing will direct it to 'C'.

Finally, when host 'C' inside the site connects to host 'D' inside the site, it has the option of using the native IPv4 service or the ISATAP IPv6-in-IPv4 encapsulation service. When there is operational assurance that IPv4 services between the two hosts are available, the hosts may be better served to continue to use legacy IPv4 services in order to avoid encapsulation overhead and to avoid any IPv4 protocol-41 filtering middleboxes that may be in the path. If 'C' and 'D' may be in different IPv4 network partitions, however, IPv6-in-IPv4 encapsulation should be used with one or both of routers 'A' and 'B' serving as intermediate gateways.

3.6. SLAAC Site Administration Guidance

In common practice, firewalls, gateways and packet filtering devices of various forms are often deployed in order to divide the site into separate partitions. In both the shared and individual prefix models described above, the entire site can be represented by the aggregate IPv6 prefix assigned to the site, while each site partition can be represented by "sliver" IPv6 prefixes taken from the aggregate. In order to provide a simple service that does not interact poorly with the site topology, site administrators should therefore institute an address plan to align IPv6 sliver prefixes with IPv4 site partition boundaries.

For example, in the shared prefix model in Section 3.4, the aggregate prefix is 2001:db8::/64, and the sliver prefixes are 2001:db8::5efe:192.0.2.0/124, 2001:db8::5efe:192.0.2.16/124, 2001:db8::5efe:192.0.2.32/124, etc. In the individual prefix model in Section 3.5, the aggregate prefix is 2001:db8::/48 and the sliver prefixes are 2001:db8:0:0::/64, 2001:db8:0:1::/64, 2001:db8:0:2::/64, etc.

When individual prefixes are used, site administrators can configure advertising ISATAP routers to advertise different individual (sliver) prefixes to different sets of clients, e.g., based on the client's IPv4 subnet prefix. When a shared prefix is used, the site administrator could instead configure the ISATAP routers to advertise the shared (aggregate) prefix to all clients.

Advertising ISATAP routers can set the L flag in each advertised prefix as an indication to clients as to when ISATAP IPv6 services should be preferred or de-preferred with respect to native IPv4 services. For example, if an advertsing router advertises a prefix to multiple clients which might not be able to send IPv6-in-IPv4 encapsulated packets to each other directly within the site, the router should set the L flag to 0 as an indication that IPv4 should be preferred over IPv6 destinations that configure addresses from the same prefix. (Otherwise, the clients would be obliged to use the advertising ISATAP router as an IPv6 first-hop toward the destination even though the destination could be reached directly via IPv4.)

Site administrators can instead (or in addition) implement address selection policy rules [RFC3484] through explicit configurations in each ISATAP client. Site administrators implement this policy by configuring address selection policy rules [RFC3484] in each ISATAP client in order to give preference to IPv4 destination addresses over destination addresses derived from one of the client's IPv6 sliver prefixes.

For example, site administrators can configure each ISATAP client associated with a sliver prefix such as 2001:db8::5efe:192.0.2.64/124 to add the prefix to its address selection policy table with a lower precedence than the prefix ::ffff:0:0/96. In this way, IPv4 addresses are preferred over IPv6 addresses from within the same sliver. The prefix could be added to each ISATAP client either manually, or through an automated service such as a DHCP option [I-D.ietf-6man-addr-select-opt]. In this way, clients will use IPv4 communications to reach correspondents within the same IPv4 site partition, and will use IPv6 communications to reach correspondents in other partitions and/or outside of the site.

It should be noted that sliver prefixes longer than /64 cannot be advertised for SLAAC purposes. Also, sliver prefixes longer than /64 do not allow for interface identifier rewriting by address translators. These factors may favor the individual prefix model in some deployment scenarios, while the flexibility afforded by the shared prefix model may be more desirable in others.

3.7. Loop Avoidance

In sites that provide IPv6 services through ISATAP with SLAAC as described in this section, advertising ISATAP routers must take operational precautions to avoid routing loops. For example, with reference to Figure 2 an IPv6 packet that enters the site via advertising ISATAP router 'A' must not be allowed to exit the site via advertising ISATAP router 'B' based on an invalid SLAAC address.

As a simple mitigation, each advertising ISATAP router should drop any packets coming from the IPv6 Internet that would be forwarded back to the Internet via another advertising router. Additionally, each advertising ISATAP router should drop any encapsulated packets received from another advertising router that would be forwarded to the IPv6 Internet. (Note that IPv6 packets with link-local ISATAP addresses are excluded from these checks, since they cannot be forwarded by an IPv6 router and may be necessary for router-to-router coordinations.) This corresponds to the mitigation documented in Section 3.2.3 of [I-D.ietf-v6ops-tunnel-loops], but other mitigations specified in that document can also be employed.

Again with reference to Figure 2, when 'A' receives a packet coming from the IPv6 Internet with destination address 2001:db8:1::5efe:192.0.2.2, it drops the packet since the IPv4 address 192.0.2.2 corresponds to advertising ISATAP router 'B'. Similarly, when 'B' receives a packet coming from the tunnel with an IPv6 destination address that would cause the packet to be forwarded back out to the IPv6 Internet and with an IPv4 source address 192.0.2.1, it drops the packet since 192.0.2.1 corresponds to advertising ISATAP router 'A'.

4. DHCPv6 Services

Whether or not advertising ISATAP routers make stateless IPv6 services available using SLAAC, they can also provide managed IPv6 services to ISATAP clients (i.e., both hosts and non-advertising ISATAP routers) using the Dynamic Host Configuration Protocol for IPv6 (DHCPv6). Any addresses/prefixes obtained via DHCPv6 are distinct from any IPv6 prefixes advertised on the ISATAP interface for SLAAC purposes, however. In this way, DHCPv6 addresses/prefixes are reached by viewing the ISATAP tunnel interface as a "transit" rather than viewing it as an ordinary IPv6 host interface. We refer to this as the "no prefix" model.

ISATAP nodes employ the source address verification checks specified in Section 7.3 of [RFC5214] as a prerequisite for decapsulation of packets received on an ISATAP interface. In order to accommodate direct communications with hosts and non-advertising ISATAP routers that use DHCPv6, ISATAP nodes that support route optimization must employ an additional source address verification check. Namely, the node also considers the outer IPv4 source address correct for the inner IPv6 source address if:

  • a forwarding table entry exists that lists the packet's IPv4 source address as the link-layer address corresponding to the inner IPv6 source address via the ISATAP interface.

The following sections discuss operational considerations for enabling ISATAP DHCPv6 services within predominantly IPv4 sites.

4.1. Advertising ISATAP Router Behavior

Advertising ISATAP routers that support DHCPv6 services send RA messages in response to RS messages received on an advertising ISATAP interface. Advertising ISATAP routers also configure either a DHCPv6 relay or server function to service DHCPv6 requests received from ISATAP clients.

4.2. Non-Advertising ISATAP Router Behavior

Non-advertising ISATAP routers can acquire IPv6 prefixes, e.g., through the use of DHCPv6 Prefix Delegation [RFC3633] via an advertising router in the same fashion as described for host-based DHCPv6 stateful address autoconfiguration in Section 4.3. The advertising router in turn maintains IPv6 forwarding table entries that list the IPv4 address of the non-advertising router as the link-layer address of the next hop toward the delegated IPv6 prefixes.

In many use case scenarios (e.g., small enterprise networks, MANETs, etc.), advertising and non-advertising ISATAP routers can engage in a proactive dynamic IPv6 routing protocol (e.g., OSPFv3, RIPng, etc.) over their ISATAP interfaces so that IPv6 routing/forwarding tables can be populated and standard IPv6 forwarding between ISATAP routers can be used. In other scenarios (e.g., large enterprise networks, highly mobile MANETs, etc.), this might be impractical dues to scaling issues. When a proactive dynamic routing protocol cannot be used, non-advertising ISATAP routers send RS messages to obtain RA messages from an advertising ISATAP router, i.e., they act as "hosts" on their non-advertising ISATAP interfaces.

After the non-advertising ISATAP router acquires IPv6 prefixes, it can sub-delegate them to routers and links within its attached IPv6 edge networks, then can forward any outbound IPv6 packets coming from its edge networks via other ISATAP nodes on the link.

4.3. ISATAP Host Behavior

ISATAP hosts resolve the PRL and send RS messages to obtain RA messages from an advertising ISATAP router. Whether or not IPv6 prefixes for SLAAC are advertised, the host can acquire IPv6 addresses, e.g., through the use of DHCPv6 stateful address autoconfiguration [RFC3315]. To acquire addresses, the host performs standard DHCPv6 exchanges while mapping the IPv6 "All_DHCP_Relay_Agents_and_Servers" link-scoped multicast address to the IPv4 address of an advertising ISATAP router.

After the host receives IPv6 addresses, it assigns them to its ISATAP interface and forwards any of its outbound IPv6 packets via the advertising router as a default router. The advertising router in turn maintains IPv6 forwarding table entries that list the IPv4 address of the host as the link-layer address of the delegated IPv6 addresses. Note that IPv6 addresses acquired from DHCPv6 therefore need not be ISATAP addresses, i.e., even though the addresses are assigned to the ISATAP interface.

4.4. Reference Operational Scenario - No Prefix Model

Figure 3 depicts a reference ISATAP network topology that uses DHCPv6. The scenario shows two advertising ISATAP routers ('A', 'B'), two non-advertising ISATAP routers ('C', 'E'), an ISATAP host ('G'), and three ordinary IPv6 hosts ('D', 'F', 'H') in a typical deployment configuration: