One document matched: draft-templin-v6ops-isops-18.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-18.txt"
ipr="trust200902">
<front>
<title abbrev="ISATAP Operational Guidance">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="18" month="October" year="2012"/>
<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 provides satisfactory internal routing and
addressing services for most applications. As more and more IPv6-only
services are deployed, however, end user devices within such sites will
increasingly require at least basic IPv6 functionality. 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"/>.</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 financial
institutions, 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, various forms of Mobile Ad-hoc
Networks (MANETs), etc.</t>
<t>With the proliferation of IPv6 services, 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"/> provides a simple-to-use service that sites can
deploy in the near term to meet these requirements.</t>
<t>ISATAP has also often been mentioned with respect to IPv6 deployment
in enterprise networks <xref target="RFC4057"/><xref target="RFC4852"/>
<xref target="I-D.ietf-v6ops-enterprise-incremental-ipv6"/>. ISATAP can
therefore be considered as an IPv6 solution alternative based on
candidate enterprise network characteristics.</t>
<t>This document provides operational guidance for using ISATAP to
enable IPv6 services within predominantly IPv4 sites while causing no
disruptions to existing IPv4 services. The terminology of ISATAP (see:
<xref target="RFC5214"/>, Section 3) applies also to this document.</t>
</section>
<section title="Enabling IPv6 Services using ISATAP">
<t>Existing sites within the Internet will soon need to enable IPv6
services. 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 Internet
Service Provider (ISP) unto themselves. Smaller sites that wish to
enable IPv6 can arrange to obtain public IPv6 prefixes from an ISP,
where the prefixes may be either purely native or the near-native
prefixes offered by 6rd <xref target="RFC5969"/>. Alternatively, the
site can obtain prefixes independently of an ISP e.g., via a tunnel
broker <xref target="RFC3053"/>, by using one of its public IPv4
addresses to form a 6to4 prefix <xref target="RFC3056"/>, etc. (Note
however that experience shows that the 6to4 method has some problems in
current deployments that can lead to connectivity failures <xref
target="RFC6343"/>.) In any 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
target="RFC2529"/> based on IPv6-in-IPv4 encapsulation <xref
target="RFC4213"/>. The encapsulation format can further use
Differentiated Service (DS) <xref target="RFC2983"/> and Explicit
Congestion Notification (ECN) <xref target="RFC3168"/> 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 two node types known as advertising
ISATAP routers and ISATAP hosts. (A third node type known as
non-advertising ISATAP routers is defined in <xref
target="I-D.templin-isupdate"/> but out of scope for this document.)
Each node may further have multiple ISATAP interfaces (i.e., one
interface for each site), and may act as an advertising ISATAP router on
some of those interfaces and a simple ISATAP host on others. Hence, the
node type is considered on a per-interface basis.</t>
<t>Advertising ISATAP routers configure their ISATAP interfaces as
advertising router interfaces (see: <xref target="RFC4861"/>, Section
6.2.2). ISATAP hosts configure their 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 ISATAP hosts are "clients" in the service model.</t>
<t>Advertising ISATAP routers arrange to add their IPv4 address to the
site's Potential Router List (PRL) so that ISATAP clients can discover
them, as discussed in Sections 8.3.2 and 9 of <xref target="RFC5214"/>.
Alternatively, site administrators could include IPv4 anycast addresses
in the PRL and assign each such 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>After the PRL is published, ISATAP clients within the site can
automatically perform unicast IPv6 Neighbor Discovery Router
Solicitation (RS) / Router Advertisement (RA) exchanges with advertising
ISATAP routers using IPv6-in-IPv4 encapsulation <xref
target="RFC4861"/><xref target="RFC5214"/>. In the exchange, the IPv4
source address of the RS and the destination address of the RA are an
IPv4 address of the client, while the IPv4 destination address of the RS
and the source address of the RA are an IPv4 address of the server found
in the PRL. Similarly, the IPv6 source address of the RS is a link-local
ISATAP address that embeds the client's IPv4 address, while the source
address of the RA is a link-local ISATAP address that embeds the
server's IPv4 address. (The destination addresses of the RS and RA may
be either the neighbor's link-local ISATAP address or a link-scoped
multicast address depending on the implementation.)</t>
<t>Following router discovery, ISATAP clients can configure and assign
IPv6 addresses and/or prefixes using Stateless Address AutoConfiguration
(SLAAC) <xref target="RFC4862"/><xref target="RFC5214"/>. While out of
scope for this document, use of the Dynamic Host Configuration Protocol
for IPv6 (DHCPv6) <xref target="RFC3315"/> is also possible when
necessary updates to the ISATAP base specification are implemented <xref
target="I-D.templin-isupdate"/>.</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"/>. When there
are multiple advertising ISATAP routers, the routers can advertise a
shared IPv6 prefix or individual IPv6 prefixes.</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 target="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. (Note that
the IPv6 link-local prefix fe80::/64 is always considered on-link on
an ISATAP interface.)</t>
</section>
<section anchor="shared"
title="Reference Operational Scenario - Shared Prefix Model">
<t><xref target="shared-prefix-fig"/> depicts an example ISATAP
network topology for allowing hosts within a predominantly IPv4 site
to configure ISATAP services using SLAAC with the shared prefix model.
The example 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 in the RA
messages they send to ISATAP clients.</t>
<t><figure anchor="shared-prefix-fig"
title="Example ISATAP Network Topology using Shared Prefix Model">
<artwork><![CDATA[ .-(::::::::) 2001:db8:1::1
.-(::: IPv6 :::)-. +-------------+
(:::: Internet ::::) | IPv6 Host E |
`-(::::::::::::)-' +-------------+
`-(::::::)-'
,~~~~~~~~~~~~~~~~~,
,----|companion gateway|--.
/ '~~~~~~~~~~~~~~~~~' :
/ |.
,-' `.
; +------------+ +------------+ )
: | Router A | | Router B | /
: | (isatap) | | (isatap) | :
: | 192.0.2.1 | | 192.0.2.1 | ;
+ +------------+ +------------+ \
fe80::*:192.0.2.1 fe80::*:192.0.2.1
| 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>With reference to <xref target="shared-prefix-fig"/>,
advertising ISATAP routers 'A' and 'B' within the IPv4 site connect to
the IPv6 Internet either directly or via a companion gateway. 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 on a site-interior IPv4 interface, then
configure an advertising ISATAP router interface for the site with
link-local ISATAP address fe80::5efe:192.0.2.1. The site administrator
then places the single IPv4 address 192.0.2.1 in the site's PRL. '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. (Note: advertising ISATAP routers can also
use individual IPv4 unicast addresses instead of, or in addition to, a
shared IPv4 anycast address. In that case, the PRL will contain
multiple IPv4 addresses of advertising routers - some of which may be
anycast and others unicast.)</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 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.1 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 IPv6 address
2001:db8::5efe:192.0.2.18 (i.e., an address with an ISATAP interface
identifier) and assigns it to the ISATAP interface. If the L flag is
set, 'C' also assigns the prefix 2001:db8::/64 to the ISATAP
interface, and the IPv6 address becomes a true ISATAP address.</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
RS/RA exchange that is serviced by 'B', then uses SLAAC to
autoconfigure the address 2001:db8::5efe:192.0.2.34 and a default IPv6
route with next-hop address fe80::5efe:192.0.2.1. 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 IPv4 address 192.0.2.1 which will be
directed to 'A' based on IPv4 routing. '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 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 only 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"/> depicts an example ISATAP
network topology for allowing hosts within a predominantly IPv4 site
to configure ISATAP services using SLAAC with the individual prefix
model. The example 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="Example ISATAP Network Topology using Individual Prefix Model">
<artwork><![CDATA[ .-(::::::::) 2001:db8:1::1
.-(::: IPv6 :::)-. +-------------+
(:::: Internet ::::) | IPv6 Host E |
`-(::::::::::::)-' +-------------+
`-(::::::)-'
,~~~~~~~~~~~~~~~~~,
,----|companion gateway|--.
/ '~~~~~~~~~~~~~~~~~' :
/ |.
,-' `.
; +------------+ +------------+ )
: | 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"/>, advertising
ISATAP routers 'A' and 'B' within the IPv4 site connect to the IPv6
Internet either directly or via a companion gateway. 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 individual
IPv4 unicast addresses 192.0.2.17/28 and 192.0.2.33/28 (respectively)
instead of, or in addition to, a shared IPv4 anycast address. Router
'A' then configures an advertising ISATAP router interface for the
site with link-local ISATAP address fe80::5efe:192.0.2.17, while
router 'B' configures an advertising ISATAP router interface for the
site with link-local ISATAP address fe80::5efe:192.0.2.33. The site
administrator then places the IPv4 addresses 192.0.2.17 and 192.0.2.33
in the site's PRL. 'A' and 'B' then both advertise their IPv4
addresses into the site's IPv4 routing system so that ISATAP clients
can locate the router that is topologically closest. (Note:
advertising ISATAP routers can also use an IPv4 anycast address
instead of, or in addition to, their IPv4 uncast address.)</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 RS message to the
IPv4 address 192.0.2.17, where IPv4 routing will direct it to 'A'. 'C'
then 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 IPv6 address 2001:db8:0:1::5efe:192.0.2.18 (i.e., an
address with an ISATAP interface identifier) and assigns it to the
ISATAP interface. If the L flag is set, 'C' also assigns the prefix
2001:db8:0:1::/64 to the ISATAP interface, and the IPv6 address
becomes a true ISATAP address.</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
RS/RA exchange that is serviced by 'B', then uses SLAAC to
autoconfigure the 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::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 IPv4 address 192.0.2.17 which will be
directed to 'A' based on IPv4 routing. '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"/>,
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"/>, 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
prefixes to different sets of clients, e.g., based on the client's
IPv4 subnet prefix such that the IPv6 prefixes are congruent with the
IPv4 addressing plan. (For example, administrators can configure each
advertising ISATAP router to provide services only to certain sets of
ISATAP clients through inbound IPv6 Access Control List (ACL) entries
that match the IPv4 subnet prefix embedded in the ISATAP interface
identifier of the IPv6 source address). When a shared prefix is used,
site administrators instead configure the ISATAP routers to advertise
the shared prefix to all clients.</t>
<t>Advertising ISATAP routers can advertise prefixes with the (A, L)
flags set to (1,0) so that ISATAP clients will use SLAAC to
autoconfigure IPv6 addresses with ISATAP interface identifiers from
the prefixes and assign them to the receiving ISATAP interface, but
they will not assign the prefix itself to the ISATAP interface. In
that case, the advertising router must assign the sliver prefix for
the site partition to the advertising ISATAP interface. In this way,
the advertising router considers the addresses covered by the sliver
prefix as true ISATAP addresses, but the ISATAP clients themselves do
not. This configuration enables a hub-and-spokes architecture which in
some cases may be augmented by route optimization based on the receipt
of ICMPv6 Redirects.</t>
<t>Site administrators can implement address selection policy rules
<xref target="RFC3484"/> through explicit configurations in each
ISATAP client. Site administrators implement this policy by
configuring address selection policy rules 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"/> discovered by the client,
e.g., using Stateless DHCPv6 <xref target="RFC3736"/>. 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. Additionally, if
the network is small then the shared prefix model works well. If the
network is large, however, a better alternative may be to deploy
separate ISATAP routers in each partition and have each advertise
their own individual prefix.</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, site administrators must take operational
precautions to avoid routing loops. For example, each advertising
ISATAP router should drop any incoming IPv6 packets that would be
forwarded back to itself via another of the site's advertising
routers. Additionally, each advertising ISATAP router should drop any
encapsulated packets received from another advertising router that
would be forwarded back to that same advertising router. This
corresponds to the mitigation documented in Section 3.2.3 of <xref
target="RFC6324"/>, but other mitigations specified in that document
can also be employed.</t>
<t>Note that IPv6 packets with link-local ISATAP addresses are exempt
from these checks, since they cannot be forwarded by an IPv6 router
and may be necessary for router-to-router coordinations.</t>
</section>
<section anchor="ulbit"
title="Interface Identifier Compatibility Considerations">
<t><xref target="RFC5214"/> Section 6.1 specifies the setting of the
"u" bit in the Modified EUI-64 interface identifier format used by
ISATAP. Implementations that comply with the specification set the "u"
bit to 1 when the IPv4 address is known to be globally unique, however
some legacy implementations unconditionally set the "u" bit to 0.</t>
<t>Implementations interpret the ISATAP interface identifier only
within the link to which the corresponding ISATAP prefix is assigned,
hence the value of the "u" bit is interpreted only within the context
of an on-link prefix and not within a global context. Implementers are
responsible for ensuring that their products are interoperable,
therefore implementations must make provisions for ensuring "u" bit
compatibility for intra-link communications.</t>
<t>Site administrators should accordingly configure access control
list entries and other literal representations of ISATAP interface
identifiers such that both values of the "u" bit are accepted. For
example, if the site administrator configures an access control list
entry that matches the prefix "fe80::0000:5efe:192.0.2.0/124" they
should also configure a companion list entry that matches the prefix
"fe80::0200:5efe:192.0.2.0/124.</t>
</section>
</section>
<section title="Manual Configuration">
<t>When no autoconfiguration services are available (e.g., if there are
no advertising ISATAP routers present), site administrators can use
manual configuration to assign IPv6 addresses with ISATAP interface
identifiers to the ISATAP interfaces of clients. Otherwise, site
administrators should avoid manual configurations that would in any way
invalidate the assumptions of the autoconfiguration service. For
example, manually configured addresses may not be automatically
renumbered during a site-wide renumbering event, which could
subsequently result in communication failures.</t>
</section>
<section anchor="scaling" title="Scaling Considerations">
<t>Section 3 depicts 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. 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 target="RFC4192"/><xref
target="RFC5887"/>.</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"/>.</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="Alternative Approaches">
<t><xref target="RFC4554"/> 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"/> 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"/> and Teredo <xref target="RFC4380"/>
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"/> 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>
</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"/>, sites that use ISATAP should take care to ensure
that no routing loops are enabled <xref target="RFC6324"/>. Additional
security concerns with IP tunneling are documented in <xref
target="RFC6169"/>.</t>
</section>
<section anchor="acknowledge" title="Acknowledgments">
<t>The following are acknowledged for their insights that helped shape
this work: Dmitry Anipko, Fred Baker, Ron Bonica, Brian Carpenter, Remi
Despres, Thomas Henderson, Philip Homburg, Lee Howard, Ray Hunter, Joel
Jaeggli, John Mann, Gabi Nakibly, Christopher Palmer, Hemant Singh, Mark
Smith, Ole Troan, and 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.3736"?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.1900"?>
<?rfc include="reference.RFC.5887"?>
<?rfc include="reference.RFC.5969"?>
<?rfc include="reference.RFC.2529"?>
<?rfc include="reference.RFC.4192"?>
<?rfc include="reference.RFC.1687"?>
<?rfc include="reference.RFC.2491"?>
<?rfc include="reference.RFC.4554"?>
<?rfc include="reference.RFC.3053"?>
<?rfc include="reference.RFC.3056"?>
<?rfc include="reference.RFC.4380"?>
<?rfc include="reference.RFC.6169"?>
<?rfc include="reference.RFC.2983"?>
<?rfc include="reference.RFC.3168"?>
<?rfc include="reference.RFC.3484"?>
<?rfc include="reference.RFC.6324"?>
<?rfc include="reference.RFC.4057"?>
<?rfc include="reference.RFC.4852"?>
<?rfc include="reference.I-D.ietf-v6ops-enterprise-incremental-ipv6"?>
<?rfc include="reference.I-D.ietf-6man-addr-select-opt"?>
<?rfc include="reference.I-D.templin-isupdate"?>
<?rfc include="reference.RFC.6343"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 20:33:49 |