One document matched: draft-templin-v6ops-isops-11.xml
<?xml version="1.0" encoding="US-ASCII"?>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc strict='yes'?>
<rfc category="info" docName="draft-templin-v6ops-isops-11.txt"
ipr="trust200902">
<front>
<title abbrev="Routing Loop Attack">Operational Guidance for IPv6
Deployment in IPv4 Sites using ISATAP</title>
<author fullname="Fred L. Templin" initials="F." surname="Templin">
<organization>Boeing Research & Technology</organization>
<address>
<postal>
<street>P.O. Box 3707 MC 7L-49</street>
<city>Seattle</city>
<region>WA</region>
<code>98124</code>
<country>USA</country>
</postal>
<email>fltemplin@acm.org</email>
</address>
</author>
<date day="23" month="June" year="2011" />
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<abstract>
<t>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).</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>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 <xref target="RFC1687"></xref>.</t>
<t>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<xref
target="RFC6139"> </xref>.</t>
<t>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) <xref target="RFC5214"></xref> 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.</t>
</section>
<section title="Enabling IPv6 Services using ISATAP">
<t>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,
the near-native prefixes offered by 6rd <xref target="RFC5969"></xref>
or the transitional prefixes offered by 6to4 <xref
target="RFC3056"></xref><xref target="RFC3068"></xref>. 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.</t>
<t>The ISATAP service uses a Non-Broadcast, Multiple Access (NBMA)
tunnel virtual interface model <xref target="RFC2491"></xref><xref
target="RFC2529"></xref> based on IPv6-in-IPv4 encapsulation <xref
target="RFC4213"></xref>. The encapsulation format can further use
Differentiated Service (DS) <xref target="RFC2983"></xref> and Explicit
Congestion Notification (ECN) <xref target="RFC3168"></xref> mapping
between the inner and outer IP headers to ensure expected per-hop
behavior within well-managed sites.</t>
<t>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: <xref
target="RFC4861"></xref>, 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.</t>
<t>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.)</t>
<t>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 <xref target="RFC4861"></xref><xref
target="RFC5214"></xref>. 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.</t>
<t>Following router discovery, ISATAP clients initiate Stateless Address
AutoConfiguration (SLAAC) <xref target="RFC4862"></xref><xref
target="RFC5214"></xref>, the Dynamic Host Configuration Protocol for
IPv6 (DHCPv6) <xref target="RFC3315"></xref> or both. Site
administrators may instead or in addition use manual configuration to
assign IPv6 addresses and/or prefixes to ISATAP clients the same as for
any IPv6 link. Details of SLAAC, DHCPv6 and manual configuration
procedures are discussed in the following sections. </t>
</section>
<section title="SLAAC Services">
<t>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</t>
<t>The following sections discuss operational considerations for
enabling ISATAP SLAAC services within predominantly IPv4 sites.</t>
<section anchor="router-slaac"
title="Advertising ISATAP Router Behavior">
<t>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<xref target="RFC4861"></xref>. When
there are multiple advertising ISATAP routers, the routers can
advertise a shared IPv6 prefix or individual IPv6 prefixes.</t>
</section>
<section anchor="non-router-slaac"
title="Non-Advertising ISATAP Router Behavior">
<t>Non-advertising ISATAP routers that engage in SLAAC behave the same
as for hosts (see below).</t>
</section>
<section anchor="host-slaac" title="ISATAP Host Behavior">
<t>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 <xref
target="RFC4862"></xref><xref target="RFC5214"></xref> 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.</t>
<t>Any IPv6 addresses configured in this fashion and assigned to an
ISATAP interface are known as ISATAP addresses.</t>
</section>
<section anchor="shared"
title="Reference Operational Scenario - Shared Prefix Model">
<t><xref target="shared-prefix-fig"></xref> 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.</t>
<figure anchor="shared-prefix-fig"
title="Reference ISATAP Network Topology using Shared Prefix Model">
<artwork><![CDATA[ .-(::::::::) 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")
]]></artwork>
</figure>
<t>With reference to <xref target="shared-prefix-fig"></xref>,
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 <xref target="no-onlink-prefix-fig"></xref>). 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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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'.</t>
<t>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.</t>
<t>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'.</t>
<t>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.</t>
</section>
<section anchor="individ"
title="Reference Operational Scenario - Individual Prefix Model">
<t><xref target="individ-prefix-fig"></xref> 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.</t>
<figure anchor="individ-prefix-fig"
title="Reference ISATAP Network Topology using Individual Prefix Model">
<artwork><![CDATA[ .-(::::::::) 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")
]]></artwork>
</figure>
<t>With reference to <xref target="individ-prefix-fig"></xref>,
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 <xref target="no-onlink-prefix-fig"></xref>). 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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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'.</t>
<t>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.</t>
<t>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'.</t>
<t>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.</t>
</section>
<section title="SLAAC Site Administration Guidance">
<t>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.</t>
<t>For example, in the shared prefix model in <xref
target="shared"></xref>, 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 <xref target="individ"></xref>, 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.</t>
<t>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.</t>
<t>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 advertising 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.)</t>
<t>Site administrators can instead (or in addition) implement address
selection policy rules <xref target="RFC3484"></xref> through explicit
configurations in each ISATAP client. Site administrators implement
this policy by configuring address selection policy rules <xref
target="RFC3484"></xref> 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.</t>
<t>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 <xref
target="I-D.ietf-6man-addr-select-opt"></xref>. 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.</t>
<t>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.</t>
<t>Finally, site administrators should configure ISATAP routers to not
send ICMPv6 Redirect messages to inform a source client of a better
next hop toward the destination unless there is strong assurance that
the client and the next hop are within the same IPv4 site
partition.</t>
</section>
<section anchor="loopavoid-slaac" title="Loop Avoidance">
<t>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 <xref target="individ-prefix-fig"></xref> 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.</t>
<t>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 <xref target="I-D.ietf-v6ops-tunnel-loops"></xref>,
but other mitigations specified in that document can also be
employed.</t>
<t>Again with reference to <xref target="individ-prefix-fig"></xref>,
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'.</t>
</section>
</section>
<section title="DHCPv6 Services">
<t>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.</t>
<t>ISATAP nodes employ the source address verification checks specified
in Section 7.3 of <xref target="RFC5214"></xref> 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:</t>
<t><list style="symbols">
<t>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.</t>
</list></t>
<t>The following sections discuss operational considerations for
enabling ISATAP DHCPv6 services within predominantly IPv4 sites.</t>
<section anchor="router-dhcpv6"
title="Advertising ISATAP Router Behavior">
<t>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.</t>
</section>
<section anchor="non-router-dhcpv6"
title="Non-Advertising ISATAP Router Behavior">
<t>Non-advertising ISATAP routers can acquire IPv6 prefixes, e.g.,
through the use of DHCPv6 Prefix Delegation <xref
target="RFC3633"></xref> via an advertising router in the same fashion
as described for host-based DHCPv6 stateful address autoconfiguration
in <xref target="host-dhcpv6"></xref>. 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.</t>
<t>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.</t>
<t>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.</t>
</section>
<section anchor="host-dhcpv6" title="ISATAP Host Behavior">
<t>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 <xref target="RFC3315"></xref>. 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.</t>
<t>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.</t>
</section>
<section anchor="avoidance-fig"
title="Reference Operational Scenario - No Prefix Model">
<t><xref target="no-onlink-prefix-fig"></xref> 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:</t>
<figure anchor="no-onlink-prefix-fig"
title="Reference ISATAP Network Topology using No Prefix Model">
<artwork><![CDATA[ .-(::::::::) 2001:db8:3::1
.-(::: IPv6 :::)-. +-------------+
(:::: Internet ::::) | IPv6 Host H |
`-(::::::::::::)-' +-------------+
`-(::::::)-'
,~~~~~~~~~~~~~~~~~,
,----|companion gateway|--.
/ '~~~~~~~~~~~~~~~~~' :
/ |.
,-' `.
; +------------+ +------------+ )
: | Router A | | Router B | /
: | (isatap) | | (isatap) | : fe80::*192.0.2.6
: | 192.0.2.1 | | 192.0.2.1 | ; 2001:db8:2::1
+ +------------+ +------------+ \ +--------------+
fe80::*:192.0.2.2 fe80::*:192.0.2.3 | (isatap) |
| ; | Host G |
: IPv4 Site -+-' +--------------+
`-. (PRL: 192.0.2.1) .)
\ _)
`-----+--------)----+'----'
fe80::*:192.0.2.4 fe80::*:192.0.2.5 .-.
+--------------+ +--------------+ ,-( _)-.
| (isatap) | | (isatap) | .-(_ IPv6 )-.
| Router C | | Router E |--(__Edge Network )
+--------------+ +--------------+ `-(______)-'
2001:db8:0::/48 2001:db8:1::/48 |
| 2001:db8:1::1
.-. +-------------+
,-( _)-. 2001:db8::1 | IPv6 Host F |
.-(_ IPv6 )-. +-------------+ +-------------+
(__Edge Network )--| IPv6 Host D |
`-(______)-' +-------------+
(* == "5efe")
]]></artwork>
</figure>
<t>In <xref target="no-onlink-prefix-fig"></xref>, advertising ISATAP
routers 'A' and 'B' within the IPv4 site connect to the IPv6 Internet
via a companion gateway. (Note that the routers may instead connect to
the IPv6 Internet directly as shown in <xref
target="shared-prefix-fig"></xref>. For the purpose of this example,
we also assume that the IPv4 site is configured within a single IPv4
subnet.</t>
<t>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.</t>
<t>Advertising ISATAP router 'A' next configures a site-interior IPv4
interface with address 192.0.2.2, then configures an advertising
ISATAP router interface with link-local ISATAP address
fe80::5efe:192.0.2.2 over the IPv4 interface. In the same fashion, 'B'
configures the IPv4 interface address 192.0.2.3, then configures its
advertising ISATAP router interface with link-local ISATAP address
fe80::5efe:192.0.2.3.</t>
<t>Non-advertising ISATAP router 'C' connects to one or more IPv6 edge
networks and also connects to the site via an IPv4 interface with
address 192.0.2.4, but it does not advertise the site's IPv4 anycast
address/prefix. 'C' next configures a non-advertising ISATAP router
interface with link-local ISATAP address fe80::5efe:192.0.2.4, then
discovers router 'A' via an IPv6-in-IPv4 encapsulated RS/RA exchange.
'C' next receives the IPv6 prefix 2001:db8::/48 through a DHCPv6
prefix delegation exchange via 'A', then engages in an IPv6 routing
protocol over its ISATAP interface and announces the delegated IPv6
prefix. 'C' finally sub-delegates the prefix to its attached edge
networks, where IPv6 host 'D' autoconfigures the address
2001:db8::1.</t>
<t>Non-advertising ISATAP router 'E' connects to the site, configures
its ISATAP interface, performs an RS/RA exchange, receives a DHCPv6
prefix delegation, and engages in the IPv6 routing protocol the same
as for 'C'. In particular, 'E' configures the IPv4 address 192.0.2.5
and the link-local ISATAP address fe80::5efe:192.0.2.5. 'E' then
receives the delegated IPv6 prefix 2001:db8:1::/48 and sub-delegates
the prefix to its attached edge networks, where IPv6 host 'F'
autoconfigures IPv6 address 2001:db8:1::1.</t>
<t>ISATAP host 'G' connects to the site via an IPv4 interface with
address 192.0.2.6, and also configures an ISATAP host interface with
link-local ISATAP address fe80::5efe:192.0.2.6 over the IPv4
interface. 'G' next performs an anycast RS/RA exchange to discover 'B"
and configure a default IPv6 route with next-hop address
fe80::5efe:192.0.2.3. 'G' then receives the IPv6 address 2001:db8:2::1
from a DHCPv6 address configuration exchange via 'B'; it then assigns
the address to the ISATAP interface but does not assign a
non-link-local IPv6 prefix to the interface.</t>
<t>Finally, IPv6 host 'H' connects to an IPv6 network outside of the
ISATAP domain. 'H' configures its IPv6 interface in a manner specific
to its attached IPv6 link, and autoconfigures the IPv6 address
2001:db8:3::1.</t>
<t>Following this autoconfiguration, when host 'D' has an IPv6 packet
to send to host 'F', it prepares the packet with source address
2001:db8::1 and destination address 2001:db8:1::1, then sends the
packet into the edge network where IPv6 forwarding will eventually
convey it to router 'C'. 'C' then uses IPv6-in-IPv4 encapsulation to
forward the packet to router 'E', since it has discovered a route to
2001:db8:1::/48 with next hop 'E' via dynamic routing over the ISATAP
interface. Router 'E' finally sends the packet into the edge network
where IPv6 forwarding will eventually convey it to host 'F'.</t>
<t>In a second scenario, when 'D' has a packet to send to ISATAP host
'G', it prepares the packet with source address 2001:db8::1 and
destination address 2001:db8:2::1, then sends the packet into the edge
network where it will eventually be forwarded to router 'C' the same
as above. 'C' then uses IPv6-in-IPv4 encapsulation to forward the
packet to router 'A' (i.e., 'C's default router), which in turn
forwards the packet to 'G'. Note that this operation entails two hops
across the ISATAP link (i.e., one from 'C' to 'A', and a second from
'A' to 'G'). If 'G' also participates in the dynamic IPv6 routing
protocol, however, 'C' could instead forward the packet directly to
'G' without involving 'A'.</t>
<t>In a third scenario, when 'D' has a packet to send to host 'H' in
the IPv6 Internet, the packet is forwarded to 'C' the same as above.
'C' then forwards the packet to 'A', which forwards the packet into
the IPv6 Internet.</t>
<t>In a final scenario, when 'G' has a packet to send to host 'H' in
the IPv6 Internet, the packet is forwarded directly to 'B', which
forwards the packet into the IPv6 Internet.</t>
</section>
<section title="DHCPv6 Site Administration Guidance">
<t>Site administrators configure advertising ISATAP routers that also
support the DHCPv6 relay/server function to send RA messages with the
M flag set to 1 as an indication to clients that the stateful DHCPv6
address autoconfiguration services area available. If stateless DHCPv6
services are also available, the RA messages also set the O flag to
1.</t>
<t>As discussed in Section 3.5, gateways and packet filtering devices
of various forms are often deployed in order to divide the site into
separate partitions. Although the purely DHCPv6 model does not involve
the advertisement of non-link-local IPv6 prefixes on ISATAP
interfaces, alignment of IPv6 prefixes used for DHCPv6 address
assignment with IPv4 site partitions is still recommended so that
ISATAP clients can prefer native IPv4 communications over ISATAP IPv6
services for correspondents within their contiguous IPv4
partition.</t>
<t>For example, if the site is assigned the aggregate prefix
2001:db8::/48, then the site administrators can assign the sliver
prefixes 2001:db8:0:0::/64, 2001:db8:0:1::/64, 2001:db8:0:2::/64, etc.
to the different IPv4 partitions within the site. The administrators
can then institute a policy that prefers native IPv4 addresses for
communications between clients covered by the same IPv6 sliver
prefix.</t>
<t>Site administrators can implement this policy implicitly by
configuring advertising ISATAP routers to advertise each sliver prefix
with both the A and L flags set to 0 as an indication that IPv4 should
be preferred over IPv6 destinations that configure addresses from the
same prefix. Site administrators can instead (or in addition)
implement address selection policy rules <xref
target="RFC3484"></xref> through explicit configurations in each
ISATAP client.</t>
<t>For example, each ISATAP client associated with the sliver prefix
2001:db8:0:0::/64 can 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 <xref
target="I-D.ietf-6man-addr-select-opt"></xref>. 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.</t>
<t>Finally, site administrators should configure ISATAP routers to not
send ICMPv6 Redirect messages to inform a source client of a better
next hop toward the destination unless there is strong assurance that
the client and the next hop are within the same IPv4 site partition
(see Section 4.6 for further considerations).</t>
</section>
<section anchor="predirect" title="On-Demand Dynamic Routing for DHCP">
<t>With respect to the reference operational scenarios depicted in
<xref target="no-onlink-prefix-fig"></xref>, there may be use cases in
which a proactive dynamic IPv6 routing protocol cannot be used. For
example, in large enterprise network deployments it would be
impractical for all ISATAP routers to engage in a common routing
protocol instance due to scaling considerations.</t>
<t>In those cases, an on-demand routing capability can be enabled in
which ISATAP nodes send initial packets via an advertising ISATAP
router and receive redirection messages back. For example, when a
non-advertising ISATAP router 'C' has a packet to send to a host
located behind non-advertising ISATAP router 'E', it can send the
initial packets via advertising router 'A' which will return
redirection messages to inform 'C' that 'E' is a better first hop.
Protocol details for this redirection procedure (including a means for
detecting whether the direct path is usable) are specified in <xref
target="I-D.templin-aero"></xref>.</t>
</section>
<section anchor="loopavoid-dhcp" title="Loop Avoidance">
<t>In a purely DHCPv6-based ISATAP deployment, no non-link-local IPv6
prefixes are assigned to ISATAP router interfaces. Therefore, an
ISATAP router cannot mistake another router for an ISATAP host due to
an address that matches an on-link prefix. This corresponds to the
mitigation documented in Section 3.2.4 of <xref
target="I-D.ietf-v6ops-tunnel-loops"></xref>.</t>
<t>Any routing loops introduced in the DHCPv6 scenario would therefore
be due to a misconfiguration in IPv6 routing the same as for any IPv6
router, and hence are out of scope for this document.</t>
</section>
</section>
<section title="Manual Configuration">
<t>In addition to any SLAAC services and DHCPv6 services, site
administrators can use manual configuration to assign non-ISATAP IPv6
addresses to the ISATAP interfaces of client end systems. Site
administrators can also use manual configuration to delegate IPv6
prefixes to non-advertising ISATAP routers instead of (or in addition
to) using DHCPv6 prefix delegation.</t>
<t>The IPv6 prefixes used for manual configuration must be distinct from
any prefixes used for SLAAC, however they may overlap with the prefixes
used for DHCPv6 as long as there is administrative assurance that the
same IPv6 addresses/prefixes will not be delegated by both DHCPv6 and
manual configuration. The manual configuration scenarios and routing
considerations are otherwise the same as discussed for DHCPv6 in Section
4.</t>
<t>When manually configured IPv6 addresses/prefixes are used, the
prefixes must be covered by a shorter IPv6 prefix advertised into the
IPv6 routing system by one or more advertising ISATAP routers. The
advertising routers must further maintain forwarding table entries that
associate the addresses/prefixes with the ISATAP clients to which the
addresses/prefixes are delegated, i.e., the same as for DHCPv6.</t>
</section>
<section anchor="scaling" title="Scaling Considerations">
<t>Sections 3 and 4 depict ISATAP network topologies with only two
advertising ISATAP routers within the site. In order to support larger
numbers of ISATAP clients (and/or multiple site partitions), the site
can deploy more advertising ISATAP routers to support load balancing and
generally shortest-path routing.</t>
<t>Such an arrangement requires that the advertising ISATAP routers
participate in an IPv6 routing protocol instance so that IPv6
addresses/prefixes can be mapped to the correct ISATAP router. The
routing protocol instance can be configured as either a full mesh
topology involving all advertising ISATAP routers, or as a partial mesh
topology with each advertising ISATAP router associating with one or
more companion gateways. Each such companion gateway would in turn
participate in a full mesh between all companion gateways.</t>
</section>
<section title="Site Renumbering Considerations">
<t>Advertising ISATAP routers distribute IPv6 prefixes to ISATAP clients
within the site via DHCPv6 and/or SLAAC. If the site subsequently
reconnects to a different ISP, however, the site must renumber to use
addresses derived from the new IPv6 prefixes <xref
target="RFC1900"></xref><xref target="RFC4192"></xref><xref
target="RFC5887"></xref>.</t>
<t>For IPv6 services provided by SLAAC, site renumbering in the event of
a change in an ISP-served IPv6 prefix entails a simple renumbering of
IPv6 addresses and/or prefixes that are assigned to the ISATAP
interfaces of clients within the site. In some cases, filtering rules
(e.g., within site border firewall filtering tables) may also require
renumbering, but this operation can be automated and limited to only one
or a few administrative "touch points".</t>
<t>In order to renumber the ISATAP interfaces of clients within the site
using SLAAC, advertising ISATAP routers need only schedule the services
offered by the old ISP for deprecation and begin to advertise the IPv6
prefixes provided by the new ISP. ISATAP client interface address
lifetimes will eventually expire, and the host will renumber its
interfaces with addresses derived from the new prefixes. ISATAP clients
should also eventually remove any deprecated SLAAC prefixes from their
address selection policy tables, but this action is not
time-critical.</t>
<t>Finally, site renumbering in the event of a change in an ISP-served
IPv6 prefix further entails locating and rewriting all IPv6 addresses in
naming services, databases, configuration files, packet filtering rules,
documentation, etc. If the site has published the IPv6 addresses of any
site-internal nodes within the public Internet DNS system, then the
corresponding resource records will also need to be updated during the
renumbering operation. This can be accomplished via secure dynamic
updates to the DNS.</t>
</section>
<section title="Path MTU Considerations">
<t>IPv6-in-IPv4 encapsulation overhead effectively reduces the size of
IPv6 packets that can traverse the tunnel in relation to the actual
Maximum Transmission Unit (MTU) of the underlying IPv4 network path
between the encapsulator and decapsulator. Two methods for accommodating
IPv6 path MTU discovery over IPv6-in-IPv4 tunnels (i.e., the static and
dynamic methods) are documented in Section 3.2 of <xref
target="RFC4213"></xref>.</t>
<t>The static method places a "safe" upper bound on the size of IPv6
packets permitted to enter the tunnel, however the method can be overly
conservative when larger IPv4 path MTUs are available. The dynamic
method can accommodate much larger IPv6 packet sizes in some cases, but
can fail silently if the underlying IPv4 network path does not return
the necessary error messages.</t>
<t>This document notes that sites that include well-managed IPv4 links,
routers and other network middleboxes are candidates for use of the
dynamic MTU determination method, which may provide for a better
operational IPv6 experience in the presence of IPv6-in-IPv4 tunnels. The
dynamic MTU determination method can potentially also present a larger
MTU to IPv6 correspondents outside of the site, since IPv6 path MTU
discovery is considered robust even over the wide area in the public
IPv6 Internet.</t>
</section>
<section title="Anycast Considerations">
<t>When an advertising ISATAP router configures an IPv4 anycast address,
and site administrators place the address in the PRL, the router uses
the anycast address as the IPv4 source address for all IPv6-in-IPv4
encapsulated packets it sends. However, the router must also derive its
ISATAP link-local addresses from an IPv4 unicast address assigned to an
underlying IPv4 interface instead of from the anycast address.</t>
<t>For example, if an advertising ISATAP router configures the IPv4
anycast address 192.0.2.1 and also configures an ordinary IPv4 interface
with IPv4 unicast address 192.0.2.91, the router must configure the
ISATAP link-local address fe80::5efe:192.0.2.91 and use this address as
the IPv6 source / destination address in link-local messages it
exchanges with other ISATAP nodes.</t>
<t>This arrangement is necessary so that ISATAP clients can
unambiguously differentiate advertising ISATAP routers. Furthermore,
since the IPv4 anycast source address is a member of the PRL, ISATAP
clients will accept any messages coming from the advertising router even
though the IPv4 source address does not match the IPv4 address embedded
in the IPv6 source address.</t>
</section>
<section title="Alternative Approaches">
<t><xref target="RFC4554"></xref> proposes a use of VLANs for IPv4-IPv6
coexistence in enterprise networks. The ISATAP approach provides a more
flexible and broadly-applicable alternative, and with fewer
administrative touch points.</t>
<t>The tunnel broker service <xref target="RFC3053"></xref> uses
point-to-point tunnels that require end users to establish an explicit
administrative configuration of the tunnel far end, which may be outside
of the administrative boundaries of the site.</t>
<t>6to4 <xref target="RFC3056"></xref><xref target="RFC3068"></xref> and
Teredo <xref target="RFC4380"></xref> provide "last resort" unmanaged
automatic tunneling services when no other means for IPv6 connectivity
is available. These services are given lower priority when the ISATAP
managed service and/or native IPv6 services are enabled.</t>
<t>6rd <xref target="RFC5969"></xref> enables a stateless prefix
delegation capability based on IPv4-embedded IPv6 prefixes, whereas
ISATAP enables a stateful prefix delegation capability based on native
IPv6 prefixes.</t>
<t>IRON <xref target="RFC6179"></xref>, RANGER <xref
target="RFC5720"></xref>, VET <xref target="RFC5558"></xref> and SEAL
<xref target="RFC5320"></xref> were developed as the "next-generation"
of ISATAP and extend to a wide variety of use cases <xref
target="RFC6139"></xref>. However, these technologies are not yet widely
implemented or deployed.</t>
</section>
<section title="IANA Considerations">
<t>This document has no IANA considerations.</t>
</section>
<section anchor="security" title="Security Considerations">
<t>In addition to the security considerations documented in <xref
target="RFC5214"></xref>, sites that use ISATAP should take care to
ensure that no routing loops are enabled <xref
target="I-D.ietf-v6ops-tunnel-loops"></xref>. Additional security
concerns with IP tunneling are documented in <xref
target="RFC6169"></xref>.</t>
</section>
<section anchor="acknowledge" title="Acknowledgments">
<t>The following are acknowledged for their insights that helped shape
this work: Fred Baker, Brian Carpenter, Remi Despres, Thomas Henderson,
Philip Homburg, Lee Howard, Ray Hunter, Joel Jaeggli, John Mann, Gabi
Nakibly, Hemant Singh, Mark Smith, Ole Troan, Gunter Van de Velde,
...</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.5214"?>
<?rfc include="reference.RFC.1918"?>
<?rfc include="reference.RFC.4861"?>
<?rfc include="reference.RFC.4862"?>
<?rfc include="reference.RFC.4213"?>
<?rfc include="reference.RFC.3315"?>
<?rfc include="reference.RFC.3633"?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.6139"?>
<?rfc include="reference.RFC.1900"?>
<?rfc include="reference.RFC.4192"?>
<?rfc include="reference.RFC.5887"?>
<?rfc include="reference.RFC.1687"?>
<?rfc include="reference.RFC.5969"?>
<?rfc include="reference.RFC.2491"?>
<?rfc include="reference.RFC.2529"?>
<?rfc include="reference.RFC.4554"?>
<?rfc include="reference.RFC.3053"?>
<?rfc include="reference.RFC.3056"?>
<?rfc include="reference.RFC.3068"?>
<?rfc include="reference.RFC.4380"?>
<?rfc include="reference.RFC.5320"?>
<?rfc include="reference.RFC.5558"?>
<?rfc include="reference.RFC.5720"?>
<?rfc include="reference.RFC.6169"?>
<?rfc include="reference.RFC.6179"?>
<?rfc include="reference.RFC.2983"?>
<?rfc include="reference.RFC.3168"?>
<?rfc include="reference.RFC.3484"?>
<?rfc include="reference.I-D.ietf-v6ops-tunnel-loops"?>
<?rfc include="reference.I-D.ietf-6man-addr-select-opt"?>
<?rfc include="reference.I-D.templin-aero"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 17:50:08 |