One document matched: draft-templin-v6ops-isops-11.txt
Differences from draft-templin-v6ops-isops-10.txt
Network Working Group F. Templin
Internet-Draft Boeing Research & Technology
Intended status: Informational June 23, 2011
Expires: December 25, 2011
Operational Guidance for IPv6 Deployment in IPv4 Sites using ISATAP
draft-templin-v6ops-isops-11.txt
Abstract
Many end user sites in the Internet today still have predominantly
IPv4 internal infrastructures. These sites range in size from small
home/office networks to large corporate enterprise networks, but
share the commonality that IPv4 continues to provide satisfactory
internal routing and addressing services for most applications. As
more and more IPv6-only services are deployed in the Internet,
however, end user devices within such sites will increasingly require
at least basic IPv6 functionality for external access. It is also
expected that more and more IPv6-only devices will be deployed within
the site over time. This document therefore provides operational
guidance for deployment of IPv6 within predominantly IPv4 sites using
the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP).
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 25, 2011.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
Templin Expires December 25, 2011 [Page 1]
Internet-Draft Routing Loop Attack June 2011
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Enabling IPv6 Services using ISATAP . . . . . . . . . . . . . 3
3. SLAAC Services . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Advertising ISATAP Router Behavior . . . . . . . . . . . . 5
3.2. Non-Advertising ISATAP Router Behavior . . . . . . . . . . 6
3.3. ISATAP Host Behavior . . . . . . . . . . . . . . . . . . . 6
3.4. Reference Operational Scenario - Shared Prefix Model . . . 6
3.5. Reference Operational Scenario - Individual Prefix
Model . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.6. SLAAC Site Administration Guidance . . . . . . . . . . . . 12
3.7. Loop Avoidance . . . . . . . . . . . . . . . . . . . . . . 14
4. DHCPv6 Services . . . . . . . . . . . . . . . . . . . . . . . 15
4.1. Advertising ISATAP Router Behavior . . . . . . . . . . . . 15
4.2. Non-Advertising ISATAP Router Behavior . . . . . . . . . . 15
4.3. ISATAP Host Behavior . . . . . . . . . . . . . . . . . . . 16
4.4. Reference Operational Scenario - No Prefix Model . . . . . 16
4.5. DHCPv6 Site Administration Guidance . . . . . . . . . . . 19
4.6. On-Demand Dynamic Routing for DHCP . . . . . . . . . . . . 20
4.7. Loop Avoidance . . . . . . . . . . . . . . . . . . . . . . 21
5. Manual Configuration . . . . . . . . . . . . . . . . . . . . . 21
6. Scaling Considerations . . . . . . . . . . . . . . . . . . . . 21
7. Site Renumbering Considerations . . . . . . . . . . . . . . . 22
8. Path MTU Considerations . . . . . . . . . . . . . . . . . . . 23
9. Anycast Considerations . . . . . . . . . . . . . . . . . . . . 23
10. Alternative Approaches . . . . . . . . . . . . . . . . . . . . 24
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
12. Security Considerations . . . . . . . . . . . . . . . . . . . 24
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
14.1. Normative References . . . . . . . . . . . . . . . . . . . 25
14.2. Informative References . . . . . . . . . . . . . . . . . . 25
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 27
Templin Expires December 25, 2011 [Page 2]
Internet-Draft Routing Loop Attack June 2011
1. Introduction
End user sites in the Internet today currently use IPv4 routing and
addressing internally for core operating functions such as web
browsing, filesharing, network printing, e-mail, teleconferencing and
numerous other site-internal networking services. Such sites
typically have an abundance of public or private IPv4 addresses for
internal networking, and are separated from the public Internet by
firewalls, packet filtering gateways, proxies, address translators
and other site border demarcation devices. To date, such sites have
had little incentive to enable IPv6 services internally [RFC1687].
End-user sites that currently use IPv4 services internally come in
endless sizes and varieties. For example, a home network behind a
Network Address Translator (NAT) may consist of a single link
supporting a few laptops, printers etc. As a larger example, a small
business may consist of one or a few offices with several networks
connecting considerably larger numbers of computers, routers,
handheld devices, printers, faxes, etc. Moving further up the scale,
large banks, restaurants, major retailers, large corporations, etc.
may consist of hundreds or thousands of branches worldwide that are
tied together in a complex global enterprise network. Additional
examples include personal-area networks, mobile vehicular networks,
disaster relief networks, tactical military networks, and various
forms of Mobile Ad-hoc Networks (MANETs). These cases and more are
discussed in RANGERS[RFC6139].
With the proliferation of IPv6 devices in the public Internet,
however, existing IPv4 sites will increasingly require a means for
enabling IPv6 services so that hosts within the site can communicate
with IPv6-only correspondents. Such services must be deployable with
minimal configuration, and in a fashion that will not cause
disruptions to existing IPv4 services. The Intra-Site Automatic
Tunnel Addressing Protocol (ISATAP) [RFC5214] provides a simple-to-
use service that sites can deploy in the near term to meet these
requirements. This document therefore provides operational guidance
for using ISATAP to enable IPv6 services within predominantly IPv4
sites while causing no disruptions to existing IPv4 services.
2. Enabling IPv6 Services using ISATAP
Many existing sites within the Internet predominantly use IPv4-based
services for their internal networking needs, but there is a growing
requirement for enabling IPv6 services to support communications with
IPv6-only correspondents. Smaller sites that wish to enable IPv6
typically arrange to obtain public IPv6 prefixes from an Internet
Service Provider (ISP), where the prefixes may be either purely
Templin Expires December 25, 2011 [Page 3]
Internet-Draft Routing Loop Attack June 2011
native, the near-native prefixes offered by 6rd [RFC5969] or the
transitional prefixes offered by 6to4 [RFC3056][RFC3068]. Larger
sites typically obtain provider independent IPv6 prefixes from an
Internet registry and advertise the prefixes into the IPv6 routing
system on their own behalf, i.e., they act as an ISP unto themselves.
In either case, after obtaining IPv6 prefixes the site can
automatically enable IPv6 services internally by configuring ISATAP.
The ISATAP service uses a Non-Broadcast, Multiple Access (NBMA)
tunnel virtual interface model [RFC2491][RFC2529] based on IPv6-in-
IPv4 encapsulation [RFC4213]. The encapsulation format can further
use Differentiated Service (DS) [RFC2983] and Explicit Congestion
Notification (ECN) [RFC3168] mapping between the inner and outer IP
headers to ensure expected per-hop behavior within well-managed
sites.
The ISATAP service is based on three basic node types known as
advertising ISATAP routers, non-advertising ISATAP routers and ISATAP
hosts. Advertising ISATAP routers configure their site-facing ISATAP
interfaces as advertising router interfaces (see: [RFC4861], Section
6.2.2). Non-advertising ISATAP routers configure their site-facing
ISATAP interfaces as non-advertising router interfaces and obtain
IPv6 addresses/prefixes via autoconfiguration exchanges with
advertising ISATAP routers. Finally, ISATAP hosts configure their
site-facing ISATAP interfaces as simple host interfaces and also
coordinate their autoconfiguration operations with advertising ISATAP
routers. In this sense, advertising ISATAP routers are "servers"
while non-advertising ISATAP routers and ISATAP hosts are "clients"
in the service model.
Advertising ISATAP routers arrange to add their IPv4 address to the
Potential Router List (PRL) within the site name service. The name
service could be either the DNS or some other site-internal name
resolution system, but the PRL should be published in such a way that
ISATAP clients can resolve the name "isatap.domainname" for the
"domainname" suffix associated with their attached link. For
example, if the domainname suffix associated with an ISATAP client's
attached link is "example.com", then the name of the PRL for that
link attachment point is "isatap.example.com". Alternatively, if the
site name service is operating without a domainname suffix, then the
name of the PRL is simply "isatap". (In either case, however, site
administrators should ensure that the name resolution returns IPv4
addresses of advertising ISATAP routers that are topologically close
to each ISATAP client depending on their locations.)
After the PRL is published, ISATAP clients within the site will
automatically perform a standard IPv6 Neighbor Discovery Router
Solicitation (RS) / Router Advertisement (RA) exchange with
Templin Expires December 25, 2011 [Page 4]
Internet-Draft Routing Loop Attack June 2011
advertising ISATAP routers [RFC4861][RFC5214]. Each ISATAP client
can also test the round-trip delays to multiple advertising ISATAP
routers listed in the PRL during an initial exchange, and select
those routers with the smallest delays. Alternatively, site
administrators could include an IPv4 anycast address in the PRL and
assign the address to multiple advertising ISATAP routers. In that
case, IPv4 routing within the site would direct the ISATAP client to
the nearest advertising ISATAP router.
Following router discovery, ISATAP clients initiate Stateless Address
AutoConfiguration (SLAAC) [RFC4862][RFC5214], the Dynamic Host
Configuration Protocol for IPv6 (DHCPv6) [RFC3315] or both. 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.
3. SLAAC Services
Predominantly IPv4 sites can enable SLAAC services for ISATAP clients
that need to communicate with IPv6 correspondents. SLAAC services
are enabled using either the "shared" or "individual" prefix model.
In the shared prefix model, all advertising ISATAP routers advertise
a common prefix (e.g., 2001:db8::/64) to ISATAP clients within the
site. In the individual prefix model, advertising ISATAP router
advertise individual prefixes (e.g., 2001:db8:0:1::/64, 2001:db8:0:
2::/64, 2001:db8:0:3::/64, etc.) to ISATAP clients within the site.
Note that combinations of the shared and individual prefix models are
also possible, in which some of the site's ISATAP routers advertise
shared prefixes and others advertise individual prefixes
The following sections discuss operational considerations for
enabling ISATAP SLAAC services within predominantly IPv4 sites.
3.1. Advertising ISATAP Router Behavior
Advertising ISATAP routers that support SLAAC services send RA
messages in response to RS messages received on an advertising ISATAP
interface. SLAAC services are enabled when advertising ISATAP
routers advertise non-link-local IPv6 prefixes in Prefix Information
Options (PIOs) with the A flag set to 1[RFC4861]. When there are
multiple advertising ISATAP routers, the routers can advertise a
shared IPv6 prefix or individual IPv6 prefixes.
Templin Expires December 25, 2011 [Page 5]
Internet-Draft Routing Loop Attack June 2011
3.2. Non-Advertising ISATAP Router Behavior
Non-advertising ISATAP routers that engage in SLAAC behave the same
as for hosts (see below).
3.3. ISATAP Host Behavior
ISATAP hosts resolve the PRL and send RS messages to obtain RA
messages from an advertising ISATAP router. When the host receives
RA messages, it uses SLAAC to configure IPv6 addresses from any
advertised prefixes with the A flag set to 1 as specified in
[RFC4862][RFC5214] then assigns the addresses to the ISATAP
interface. The host also assigns any of the advertised prefixes with
the L flag set to 1 to the ISATAP interface.
Any IPv6 addresses configured in this fashion and assigned to an
ISATAP interface are known as ISATAP addresses.
3.4. Reference Operational Scenario - Shared Prefix Model
Figure 1 depicts a reference ISATAP network topology for allowing
hosts within a predominantly IPv4 site to configure ISATAP services
using SLAAC with the shared prefix model. The scenario shows two
advertising ISATAP routers ('A', 'B'), two ISATAP hosts ('C', 'D'),
and an ordinary IPv6 host ('E') outside of the site in a typical
deployment configuration. In this model, routers 'A' and 'B' both
advertise the same (shared) IPv6 prefix 2001:db8::/64 into the IPv6
routing system, and also advertise the prefix to ISATAP clients
within the site for SLAAC purposes.
Templin Expires December 25, 2011 [Page 6]
Internet-Draft Routing Loop Attack June 2011
.-(::::::::) 2001:db8:1::1
.-(::: IPv6 :::)-. +-------------+
(:::: Internet ::::) | IPv6 Host E |
`-(::::::::::::)-' +-------------+
`-(::::::)-'
+------------+ +------------+
| Router A |---.---| Router B |.
,| (isatap) | | (isatap) | `\
. | 192.0.2.1 | | 192.0.2.1 | \
/ +------------+ +------------+ \
: fe80::*:192.0.2.17 fe80::*:192.0.2.33 :
\ 2001:db8::/64 2001:db8::/64 /
: :
: :
+- IPv4 Site -+
; (PRL: 192.0.2.1) :
| ;
: -+-'
`-. .)
\ _)
`-----+--------)----+'----'
fe80::*:192.0.2.18 fe80::*:192.0.2.34
2001:db8::*:192.0.2.18 2001:db8::*:192.0.2.34
+--------------+ +--------------+
| (isatap) | | (isatap) |
| Host C | | Host D |
+--------------+ +--------------+
(* == "5efe")
Figure 1: Reference ISATAP Network Topology using Shared Prefix Model
With reference to Figure 1, advertising ISATAP routers 'A' and 'B'
within the IPv4 site connect to the IPv6 Internet either directly or
via a companion gateway (e.g., as shown in Figure 3). The routers
advertise the shared prefix 2001:db8::/64 into the IPv6 Internet
routing system either as a singleton /64 or as part of a shorter
aggregated IPv6 prefix if the routing system will not accept prefixes
as long as a /64. For the purpose of this example, we also assume
that the IPv4 site is configured within multiple IPv4 subnets - each
with an IPv4 prefix length of /28.
Advertising ISATAP routers 'A' and 'B' both configure the IPv4
anycast address 192.0.2.1, e.g., on a loopback interface, and the
site administrator places the single IPv4 address 192.0.2.1 in the
PRL for the site. 'A' and 'B' then both advertise the anycast
address/prefix into the site's IPv4 routing system so that ISATAP
clients can locate the router that is topologically closest.
Templin Expires December 25, 2011 [Page 7]
Internet-Draft Routing Loop Attack June 2011
Advertising ISATAP router 'A' next configures a site-interior IPv4
interface with address 192.0.2.17 and netmask /28, then configures an
advertising ISATAP router interface with link-local ISATAP address
fe80::5efe:192.0.2.17 over the IPv4 interface. In the same fashion,
'B' configures a site-interior IPv4 interface with address
192.0.2.33/28, then configures its advertising ISATAP router
interface with link-local ISATAP address fe80::5efe:192.0.2.33.
ISATAP host 'C' connects to the site via an IPv4 interface with
address 192.0.2.18/28, and also configures an ISATAP host interface
with link-local ISATAP address fe80::5efe:192.0.2.18 over the IPv4
interface. 'C' next resolves the PRL, and sends an IPv6-in-IPv4
encapsulated RS message to the IPv4 address 192.0.2.1, where IPv4
routing will direct it to the closest of either 'A' or 'B'. Assuming
'A' is closest, 'C' receives an RA from 'A' then configures a default
IPv6 route with next-hop address fe80::5efe:192.0.2.17 via the ISATAP
interface and processes the IPv6 prefix 2001:db8::/64 advertised in
the PIO. If the A flag is set in the PIO, 'C' uses SLAAC to
automatically configure the ISATAP address 2001:db8::5efe:192.0.2.18
and assigns the address to the ISATAP interface. If the L flag is
set, 'C' also assigns the prefix 2001:db8::/64 to the ISATAP
interface.
In the same fashion, ISATAP host 'D' configures its IPv4 interface
with address 192.0.2.34/28 and configures its ISATAP interface with
link-local ISATAP address fe80::5efe:192.0.2.34. 'D' next performs
an anycast RS/RA exchange that is serviced by 'B', then uses SLAAC to
autoconfigure the ISATAP address 2001:db8::5efe:192.0.2.34 and a
default IPv6 route with next-hop address fe80::5efe:192.0.2.33.
Finally, IPv6 host 'E' connects to an IPv6 network outside of the
site. 'E' configures its IPv6 interface in a manner specific to its
attached IPv6 link, and autoconfigures the IPv6 address
2001:db8:1::1.
Following this autoconfiguration, when host 'C' inside the site has
an IPv6 packet to send to host 'E' outside the site, it prepares the
packet with source address 2001:db8::5efe:192.0.2.18 and destination
address 2001:db8:1::1. 'C' then uses IPv6-in-IPv4 encapsulation to
forward the packet to the link-local address of its default router
'A' (i.e., fe80::5efe:192.0.2.17). 'A' in turn decapsulates the
packet and forwards it into the public IPv6 Internet where it will be
conveyed to 'E' via normal IPv6 routing. In the same fashion, host
'D' uses IPv6-in-IPv4 encapsulation via its default router 'B' to
send IPv6 packets to IPv6 Internet hosts such as 'E'.
When host 'E' outside the site sends IPv6 packets to ISATAP host 'C'
inside the site, the IPv6 routing system may direct the packet to
either of 'A' or 'B'. If the site is not partitioned internally, the
Templin Expires December 25, 2011 [Page 8]
Internet-Draft Routing Loop Attack June 2011
router that receives the packet can use ISATAP to statelessly forward
the packet directly to 'C'. If the site may be partitioned
internally, however, the packet must first be forwarded to 'C's
serving router based on IPv6 routing information. This implies that,
in a partitioned site, the advertising ISATAP routers must connect
within a full or partial mesh of IPv6 links, and must either run a
dynamic IPv6 routing protocol or configure static routes so that
incoming IPv6 packets can be forwarded to the correct serving router.
In this example, 'A' can configure the IPv6 route 2001:db8::5efe:
192.0.2.32/124 with the IPv6 address of the next hop toward 'B' in
the mesh network as the next hop, and 'B' can configure the IPv6
route 2001:db8::5efe:192.0.2.16/124 with the IPv6 address of the next
hop toward 'A' as the next hop. (Notice that the /124 prefixes
properly cover the /28 prefix of the IPv4 address that is embedded
within the IPv6 ISATAP address.) In that case, when 'A' receives a
packet from the IPv6 Internet with destination address 2001:db8::
5efe:192.0.2.34, it first forwards the packet toward 'B' over an IPv6
mesh link. 'B' in turn uses ISATAP to forward the packet into the
site, where IPv4 routing will direct it to 'D'. In the same fashion,
when 'B' receives a packet from the IPv6 Internet with destination
address 2001:db8::5efe:192.0.2.18, it first forwards the packet
toward 'A' over an IPv6 mesh link. 'A' then uses ISATAP to forward
the packet into the site, where IPv4 routing will direct it to 'C'.
Finally, when host 'C' inside the site connects to host 'D' inside
the site, it has the option of using the native IPv4 service or the
ISATAP IPv6-in-IPv4 encapsulation service. When there is operational
assurance that IPv4 services between the two hosts are available, the
hosts may be better served to continue to use legacy IPv4 services in
order to avoid encapsulation overhead and to avoid any IPv4
protocol-41 filtering middleboxes that may be in the path. If 'C'
and 'D' may be in different IPv4 network partitions, however, IPv6-
in-IPv4 encapsulation should be used with one or both of routers 'A'
and 'B' serving as intermediate gateways.
3.5. Reference Operational Scenario - Individual Prefix Model
Figure 2 depicts a reference ISATAP network topology for allowing
hosts within a predominantly IPv4 site to configure ISATAP services
using SLAAC with the individual prefix model. The scenario shows two
advertising ISATAP routers ('A', 'B'), two ISATAP hosts ('C', 'D'),
and an ordinary IPv6 host ('E') outside of the site in a typical
deployment configuration. In the figure, ISATAP routers 'A' and 'B'
both advertise different prefixes taken from the aggregated prefix
2001:db8::/48, with 'A' advertising 2001:db8:0:1::/64 and 'B'
advertising 2001:db8:0:2::/64.
Templin Expires December 25, 2011 [Page 9]
Internet-Draft Routing Loop Attack June 2011
.-(::::::::) 2001:db8:1::1
.-(::: IPv6 :::)-. +-------------+
(:::: Internet ::::) | IPv6 Host E |
`-(::::::::::::)-' +-------------+
`-(::::::)-'
+------------+ +------------+
| Router A |---.---| Router B |.
,| (isatap) | | (isatap) | `\
. | 192.0.2.1 | | 192.0.2.1 | \
/ +------------+ +------------+ \
: fe80::*:192.0.2.17 fe80::*:192.0.2.33 :
\ 2001:db8:0:1::/64 2001:db8:0:2::/64 /
: :
: :
+- IPv4 Site -+
; (PRL: 192.0.2.1) :
| ;
: -+-'
`-. .)
\ _)
`-----+--------)----+'----'
fe80::*:192.0.2.18 fe80::*:192.0.2.34
2001:db8:0:1::*:192.0.2.18 2001:db8:0:2::*:192.0.2.34
+--------------+ +--------------+
| (isatap) | | (isatap) |
| Host C | | Host D |
+--------------+ +--------------+
(* == "5efe")
Figure 2: Reference ISATAP Network Topology using Individual Prefix
Model
With reference to Figure 2, advertising ISATAP routers 'A' and 'B'
within the IPv4 site connect to the IPv6 Internet either directly or
via a companion gateway (e.g., as shown in Figure 3). Router 'A'
advertises the individual prefix 2001:db8:0:1::/64 into the IPv6
Internet routing system, and router 'B' advertises the individual
prefix 2001:db8:0:2::/64. The routers could instead both advertise a
shorter shared prefix such as 2001:db8::/48 into the IPv6 routing
system, but in that case they would need to configure a mesh of IPv6
links between themselves in the same fashion as described for the
shared prefix model in Section 3.4. For the purpose of this example,
we also assume that the IPv4 site is configured within multiple IPv4
subnets - each with an IPv4 prefix length of /28.
Advertising ISATAP routers 'A' and 'B' both configure the IPv4
anycast address 192.0.2.1, e.g., on a loopback interface, and the
Templin Expires December 25, 2011 [Page 10]
Internet-Draft Routing Loop Attack June 2011
site administrator places the single IPv4 address 192.0.2.1 in the
PRL for the site. 'A' and 'B' then both advertise the anycast
address/prefix into the site's IPv4 routing system so that ISATAP
clients can locate the router that is topologically closest.
Advertising ISATAP router 'A' next configures a site-interior IPv4
interface with address 192.0.2.17/28, then configures an advertising
ISATAP router interface with link-local ISATAP address fe80::5efe:
192.0.2.17 over the IPv4 interface. In the same fashion, 'B'
configures the IPv4 interface address 192.0.2.33/28, then configures
its advertising ISATAP router interface with link-local ISATAP
address fe80::5efe:192.0.2.33.
ISATAP host 'C' connects to the site via an IPv4 interface with
address 192.0.2.18/28, and also configures an ISATAP host interface
with link-local ISATAP address fe80::5efe:192.0.2.18 over the IPv4
interface. 'C' next resolves the PRL, and sends an IPv6-in-IPv4
encapsulated RS message to the IPv4 address 192.0.2.1, where IPv4
routing will direct it to the closest of either 'A' or 'B'. Assuming
'A' is closest, 'C' receives an RA from 'A' then configures a default
IPv6 route with next-hop address fe80::5efe:192.0.2.17 via the ISATAP
interface and processes the IPv6 prefix 2001:db8:0:1::/64 advertised
in the PIO. If the A flag is set in the PIO, 'C' uses SLAAC to
automatically configure the ISATAP address 2001:db8:0:1::5efe:
192.0.2.18 and assigns the address to the ISATAP interface. If the L
flag is set, 'C' also assigns the prefix 2001:db8:0:1::/64 to the
ISATAP interface.
In the same fashion, ISATAP host 'D' configures its IPv4 interface
with address 192.0.2.34/28 and configures its ISATAP interface with
link-local ISATAP address fe80::5efe:192.0.2.34. 'D' next performs
an anycast RS/RA exchange that is serviced by 'B', then uses SLAAC to
autoconfigure the ISATAP address 2001:db8:0:2::5efe:192.0.2.34 and a
default IPv6 route with next-hop address fe80::5efe:192.0.2.33.
Finally, IPv6 host 'E' connects to an IPv6 network outside of the
site. 'E' configures its IPv6 interface in a manner specific to its
attached IPv6 link, and autoconfigures the IPv6 address
2001:db8:1::1.
Following this autoconfiguration, when host 'C' inside the site has
an IPv6 packet to send to host 'E' outside the site, it prepares the
packet with source address 2001:db8:0:1::5efe:192.0.2.18 and
destination address 2001:db8:1::1. 'C' then uses IPv6-in-IPv4
encapsulation to forward the packet to the link-local ISATAP address
of 'A' (fe80::5efe:192.0.2.17), where 'A' in turn decapsulates the
packet and forwards it into the public IPv6 Internet where it will be
conveyed to 'E' via normal IPv6 routing. In the same fashion, host
'D' uses IPv6-in-IPv4 encapsulation via its default router 'B' to
Templin Expires December 25, 2011 [Page 11]
Internet-Draft Routing Loop Attack June 2011
send IPv6 packets to IPv6 Internet hosts such as 'E'.
When host 'E' outside the site sends IPv6 packets to ISATAP host 'C'
inside the site, the IPv6 routing system will direct the packet to
'A' since 'A' advertises the individual prefix that matches 'C's
destination address. 'A' can then use ISATAP to statelessly forward
the packet directly to 'C'. If 'A' and 'B' both advertise the shared
shorter prefix 2001:db8::/48 into the IPv6 routing system, however
packets coming from 'E' may be directed to either 'A' or 'B'. In
that case, the advertising ISATAP routers must connect within a full
or partial mesh of IPv6 links the same as for the shared prefix
model, and must either run a dynamic IPv6 routing protocol or
configure static routes so that incoming IPv6 packets can be
forwarded to the correct serving router.
In this example, 'A' can configure the IPv6 route 2001:db8:0:2::/64
with the IPv6 address of the next hop toward 'B' in the mesh network
as the next hop, and 'B' can configure the IPv6 route 2001:db8:
0.1::/64 with the IPv6 address of the next hop toward 'A' as the next
hop. Then, when 'A' receives a packet from the IPv6 Internet with
destination address 2001:db8:0:2::5efe:192.0.2.34, it first forwards
the packet toward 'B' over an IPv6 mesh link. 'B' in turn uses
ISATAP to forward the packet into the site, where IPv4 routing will
direct it to 'D'. In the same fashion, when 'B' receives a packet
from the IPv6 Internet with destination address 2001:db8:0:1::5efe:
192.0.2.18, it first forwards the packet toward 'A' over an IPv6 mesh
link. 'A' then uses ISATAP to forward the packet into the site,
where IPv4 routing will direct it to 'C'.
Finally, when host 'C' inside the site connects to host 'D' inside
the site, it has the option of using the native IPv4 service or the
ISATAP IPv6-in-IPv4 encapsulation service. When there is operational
assurance that IPv4 services between the two hosts are available, the
hosts may be better served to continue to use legacy IPv4 services in
order to avoid encapsulation overhead and to avoid any IPv4
protocol-41 filtering middleboxes that may be in the path. If 'C'
and 'D' may be in different IPv4 network partitions, however, IPv6-
in-IPv4 encapsulation should be used with one or both of routers 'A'
and 'B' serving as intermediate gateways.
3.6. SLAAC Site Administration Guidance
In common practice, firewalls, gateways and packet filtering devices
of various forms are often deployed in order to divide the site into
separate partitions. In both the shared and individual prefix models
described above, the entire site can be represented by the aggregate
IPv6 prefix assigned to the site, while each site partition can be
represented by "sliver" IPv6 prefixes taken from the aggregate. In
Templin Expires December 25, 2011 [Page 12]
Internet-Draft Routing Loop Attack June 2011
order to provide a simple service that does not interact poorly with
the site topology, site administrators should therefore institute an
address plan to align IPv6 sliver prefixes with IPv4 site partition
boundaries.
For example, in the shared prefix model in Section 3.4, the aggregate
prefix is 2001:db8::/64, and the sliver prefixes are 2001:db8::5efe:
192.0.2.0/124, 2001:db8::5efe:192.0.2.16/124, 2001:db8::5efe:
192.0.2.32/124, etc. In the individual prefix model in Section 3.5,
the aggregate prefix is 2001:db8::/48 and the sliver prefixes are
2001:db8:0:0::/64, 2001:db8:0:1::/64, 2001:db8:0:2::/64, etc.
When individual prefixes are used, site administrators can configure
advertising ISATAP routers to advertise different individual (sliver)
prefixes to different sets of clients, e.g., based on the client's
IPv4 subnet prefix. When a shared prefix is used, the site
administrator could instead configure the ISATAP routers to advertise
the shared (aggregate) prefix to all clients.
Advertising ISATAP routers can set the L flag in each advertised
prefix as an indication to clients as to when ISATAP IPv6 services
should be preferred or de-preferred with respect to native IPv4
services. For example, if an 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.)
Site administrators can instead (or in addition) implement address
selection policy rules [RFC3484] through explicit configurations in
each ISATAP client. Site administrators implement this policy by
configuring address selection policy rules [RFC3484] in each ISATAP
client in order to give preference to IPv4 destination addresses over
destination addresses derived from one of the client's IPv6 sliver
prefixes.
For example, site administrators can configure each ISATAP client
associated with a sliver prefix such as 2001:db8::5efe:192.0.2.64/124
to add the prefix to its address selection policy table with a lower
precedence than the prefix ::ffff:0:0/96. In this way, IPv4
addresses are preferred over IPv6 addresses from within the same
sliver. The prefix could be added to each ISATAP client either
manually, or through an automated service such as a DHCP option
[I-D.ietf-6man-addr-select-opt]. In this way, clients will use IPv4
communications to reach correspondents within the same IPv4 site
Templin Expires December 25, 2011 [Page 13]
Internet-Draft Routing Loop Attack June 2011
partition, and will use IPv6 communications to reach correspondents
in other partitions and/or outside of the site.
It should be noted that sliver prefixes longer than /64 cannot be
advertised for SLAAC purposes. Also, sliver prefixes longer than /64
do not allow for interface identifier rewriting by address
translators. These factors may favor the individual prefix model in
some deployment scenarios, while the flexibility afforded by the
shared prefix model may be more desirable in others.
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.
3.7. Loop Avoidance
In sites that provide IPv6 services through ISATAP with SLAAC as
described in this section, advertising ISATAP routers must take
operational precautions to avoid routing loops. For example, with
reference to Figure 2 an IPv6 packet that enters the site via
advertising ISATAP router 'A' must not be allowed to exit the site
via advertising ISATAP router 'B' based on an invalid SLAAC address.
As a simple mitigation, each advertising ISATAP router should drop
any packets coming from the IPv6 Internet that would be forwarded
back to the Internet via another advertising router. Additionally,
each advertising ISATAP router should drop any encapsulated packets
received from another advertising router that would be forwarded to
the IPv6 Internet. (Note that IPv6 packets with link-local ISATAP
addresses are excluded from these checks, since they cannot be
forwarded by an IPv6 router and may be necessary for router-to-router
coordinations.) This corresponds to the mitigation documented in
Section 3.2.3 of [I-D.ietf-v6ops-tunnel-loops], but other mitigations
specified in that document can also be employed.
Again with reference to Figure 2, when 'A' receives a packet coming
from the IPv6 Internet with destination address 2001:db8:1::5efe:
192.0.2.2, it drops the packet since the IPv4 address 192.0.2.2
corresponds to advertising ISATAP router 'B'. Similarly, when 'B'
receives a packet coming from the tunnel with an IPv6 destination
address that would cause the packet to be forwarded back out to the
IPv6 Internet and with an IPv4 source address 192.0.2.1, it drops the
packet since 192.0.2.1 corresponds to advertising ISATAP router 'A'.
Templin Expires December 25, 2011 [Page 14]
Internet-Draft Routing Loop Attack June 2011
4. DHCPv6 Services
Whether or not advertising ISATAP routers make stateless IPv6
services available using SLAAC, they can also provide managed IPv6
services to ISATAP clients (i.e., both hosts and non-advertising
ISATAP routers) using the Dynamic Host Configuration Protocol for
IPv6 (DHCPv6). Any addresses/prefixes obtained via DHCPv6 are
distinct from any IPv6 prefixes advertised on the ISATAP interface
for SLAAC purposes, however. In this way, DHCPv6 addresses/prefixes
are reached by viewing the ISATAP tunnel interface as a "transit"
rather than viewing it as an ordinary IPv6 host interface. We refer
to this as the "no prefix" model.
ISATAP nodes employ the source address verification checks specified
in Section 7.3 of [RFC5214] as a prerequisite for decapsulation of
packets received on an ISATAP interface. In order to accommodate
direct communications with hosts and non-advertising ISATAP routers
that use DHCPv6, ISATAP nodes that support route optimization must
employ an additional source address verification check. Namely, the
node also considers the outer IPv4 source address correct for the
inner IPv6 source address if:
o a forwarding table entry exists that lists the packet's IPv4
source address as the link-layer address corresponding to the
inner IPv6 source address via the ISATAP interface.
The following sections discuss operational considerations for
enabling ISATAP DHCPv6 services within predominantly IPv4 sites.
4.1. Advertising ISATAP Router Behavior
Advertising ISATAP routers that support DHCPv6 services send RA
messages in response to RS messages received on an advertising ISATAP
interface. Advertising ISATAP routers also configure either a DHCPv6
relay or server function to service DHCPv6 requests received from
ISATAP clients.
4.2. Non-Advertising ISATAP Router Behavior
Non-advertising ISATAP routers can acquire IPv6 prefixes, e.g.,
through the use of DHCPv6 Prefix Delegation [RFC3633] via an
advertising router in the same fashion as described for host-based
DHCPv6 stateful address autoconfiguration in Section 4.3. The
advertising router in turn maintains IPv6 forwarding table entries
that list the IPv4 address of the non-advertising router as the link-
layer address of the next hop toward the delegated IPv6 prefixes.
In many use case scenarios (e.g., small enterprise networks, MANETs,
Templin Expires December 25, 2011 [Page 15]
Internet-Draft Routing Loop Attack June 2011
etc.), advertising and non-advertising ISATAP routers can engage in a
proactive dynamic IPv6 routing protocol (e.g., OSPFv3, RIPng, etc.)
over their ISATAP interfaces so that IPv6 routing/forwarding tables
can be populated and standard IPv6 forwarding between ISATAP routers
can be used. In other scenarios (e.g., large enterprise networks,
highly mobile MANETs, etc.), this might be impractical dues to
scaling issues. When a proactive dynamic routing protocol cannot be
used, non-advertising ISATAP routers send RS messages to obtain RA
messages from an advertising ISATAP router, i.e., they act as "hosts"
on their non-advertising ISATAP interfaces.
After the non-advertising ISATAP router acquires IPv6 prefixes, it
can sub-delegate them to routers and links within its attached IPv6
edge networks, then can forward any outbound IPv6 packets coming from
its edge networks via other ISATAP nodes on the link.
4.3. ISATAP Host Behavior
ISATAP hosts resolve the PRL and send RS messages to obtain RA
messages from an advertising ISATAP router. Whether or not IPv6
prefixes for SLAAC are advertised, the host can acquire IPv6
addresses, e.g., through the use of DHCPv6 stateful address
autoconfiguration [RFC3315]. To acquire addresses, the host performs
standard DHCPv6 exchanges while mapping the IPv6
"All_DHCP_Relay_Agents_and_Servers" link-scoped multicast address to
the IPv4 address of an advertising ISATAP router.
After the host receives IPv6 addresses, it assigns them to its ISATAP
interface and forwards any of its outbound IPv6 packets via the
advertising router as a default router. The advertising router in
turn maintains IPv6 forwarding table entries that list the IPv4
address of the host as the link-layer address of the delegated IPv6
addresses. Note that IPv6 addresses acquired from DHCPv6 therefore
need not be ISATAP addresses, i.e., even though the addresses are
assigned to the ISATAP interface.
4.4. Reference Operational Scenario - No Prefix Model
Figure 3 depicts a reference ISATAP network topology that uses
DHCPv6. The scenario shows two advertising ISATAP routers ('A',
'B'), two non-advertising ISATAP routers ('C', 'E'), an ISATAP host
('G'), and three ordinary IPv6 hosts ('D', 'F', 'H') in a typical
deployment configuration:
Templin Expires December 25, 2011 [Page 16]
Internet-Draft Routing Loop Attack June 2011
.-(::::::::) 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")
Figure 3: Reference ISATAP Network Topology using No Prefix Model
In Figure 3, 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 Figure 1. For the purpose of this example, we also assume
that the IPv4 site is configured within a single IPv4 subnet.
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
Templin Expires December 25, 2011 [Page 17]
Internet-Draft Routing Loop Attack June 2011
address/prefix into the site's IPv4 routing system so that ISATAP
clients can locate the router that is topologically closest.
Advertising ISATAP router 'A' next configures a site-interior IPv4
interface with address 192.0.2.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.
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.
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.
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.
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.
Following this autoconfiguration, when host 'D' has an IPv6 packet to
Templin Expires December 25, 2011 [Page 18]
Internet-Draft Routing Loop Attack June 2011
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'.
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'.
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.
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.
4.5. DHCPv6 Site Administration Guidance
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.
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.
Templin Expires December 25, 2011 [Page 19]
Internet-Draft Routing Loop Attack June 2011
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.
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 [RFC3484]
through explicit configurations in each ISATAP client.
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
[I-D.ietf-6man-addr-select-opt]. In this way, clients will use IPv4
communications to reach correspondents within the same IPv4 site
partition, and will use IPv6 communications to reach correspondents
in other partitions and/or outside of the site.
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).
4.6. On-Demand Dynamic Routing for DHCP
With respect to the reference operational scenarios depicted in
Figure 3, 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.
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
Templin Expires December 25, 2011 [Page 20]
Internet-Draft Routing Loop Attack June 2011
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
[I-D.templin-aero].
4.7. Loop Avoidance
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
[I-D.ietf-v6ops-tunnel-loops].
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.
5. Manual Configuration
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.
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.
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.
6. Scaling Considerations
Sections 3 and 4 depict ISATAP network topologies with only two
Templin Expires December 25, 2011 [Page 21]
Internet-Draft Routing Loop Attack June 2011
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.
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.
7. Site Renumbering Considerations
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
[RFC1900][RFC4192][RFC5887].
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".
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.
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
Templin Expires December 25, 2011 [Page 22]
Internet-Draft Routing Loop Attack June 2011
via secure dynamic updates to the DNS.
8. Path MTU Considerations
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 [RFC4213].
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.
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.
9. Anycast Considerations
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.
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.
This arrangement is necessary so that ISATAP clients can
unambiguously differentiate advertising ISATAP routers. Furthermore,
Templin Expires December 25, 2011 [Page 23]
Internet-Draft Routing Loop Attack June 2011
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.
10. Alternative Approaches
[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.
The tunnel broker service [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.
6to4 [RFC3056][RFC3068] and Teredo [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.
6rd [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.
IRON [RFC6179], RANGER [RFC5720], VET [RFC5558] and SEAL [RFC5320]
were developed as the "next-generation" of ISATAP and extend to a
wide variety of use cases [RFC6139]. However, these technologies are
not yet widely implemented or deployed.
11. IANA Considerations
This document has no IANA considerations.
12. Security Considerations
In addition to the security considerations documented in [RFC5214],
sites that use ISATAP should take care to ensure that no routing
loops are enabled [I-D.ietf-v6ops-tunnel-loops]. Additional security
concerns with IP tunneling are documented in [RFC6169].
Templin Expires December 25, 2011 [Page 24]
Internet-Draft Routing Loop Attack June 2011
13. Acknowledgments
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, ...
14. References
14.1. Normative References
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) version 6", RFC 3633,
December 2003.
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
for IPv6 Hosts and Routers", RFC 4213, October 2005.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007.
[RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site
Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214,
March 2008.
14.2. Informative References
[I-D.ietf-6man-addr-select-opt]
Matsumoto, A., Fujisaki, T., and J. Kato, "Distributing
Address Selection Policy using DHCPv6",
draft-ietf-6man-addr-select-opt-00 (work in progress),
December 2010.
[I-D.ietf-v6ops-tunnel-loops]
Templin Expires December 25, 2011 [Page 25]
Internet-Draft Routing Loop Attack June 2011
Nakibly, G. and F. Templin, "Routing Loop Attack using
IPv6 Automatic Tunnels: Problem Statement and Proposed
Mitigations", draft-ietf-v6ops-tunnel-loops-07 (work in
progress), May 2011.
[I-D.templin-aero]
Templin, F., "Asymmetric Extended Route Optimization
(AERO)", draft-templin-aero-00 (work in progress),
March 2011.
[RFC1687] Fleischman, E., "A Large Corporate User's View of IPng",
RFC 1687, August 1994.
[RFC1900] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work",
RFC 1900, February 1996.
[RFC2491] Armitage, G., Schulter, P., Jork, M., and G. Harter, "IPv6
over Non-Broadcast Multiple Access (NBMA) networks",
RFC 2491, January 1999.
[RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4
Domains without Explicit Tunnels", RFC 2529, March 1999.
[RFC2983] Black, D., "Differentiated Services and Tunnels",
RFC 2983, October 2000.
[RFC3053] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6
Tunnel Broker", RFC 3053, January 2001.
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains
via IPv4 Clouds", RFC 3056, February 2001.
[RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers",
RFC 3068, June 2001.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP",
RFC 3168, September 2001.
[RFC3484] Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for
Renumbering an IPv6 Network without a Flag Day", RFC 4192,
September 2005.
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through
Network Address Translations (NATs)", RFC 4380,
Templin Expires December 25, 2011 [Page 26]
Internet-Draft Routing Loop Attack June 2011
February 2006.
[RFC4554] Chown, T., "Use of VLANs for IPv4-IPv6 Coexistence in
Enterprise Networks", RFC 4554, June 2006.
[RFC5320] Templin, F., "The Subnetwork Encapsulation and Adaptation
Layer (SEAL)", RFC 5320, February 2010.
[RFC5558] Templin, F., "Virtual Enterprise Traversal (VET)",
RFC 5558, February 2010.
[RFC5720] Templin, F., "Routing and Addressing in Networks with
Global Enterprise Recursion (RANGER)", RFC 5720,
February 2010.
[RFC5887] Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering
Still Needs Work", RFC 5887, May 2010.
[RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4
Infrastructures (6rd) -- Protocol Specification",
RFC 5969, August 2010.
[RFC6139] Russert, S., Fleischman, E., and F. Templin, "Routing and
Addressing in Networks with Global Enterprise Recursion
(RANGER) Scenarios", RFC 6139, February 2011.
[RFC6169] Krishnan, S., Thaler, D., and J. Hoagland, "Security
Concerns with IP Tunneling", RFC 6169, April 2011.
[RFC6179] Templin, F., "The Internet Routing Overlay Network
(IRON)", RFC 6179, March 2011.
Author's Address
Fred L. Templin
Boeing Research & Technology
P.O. Box 3707 MC 7L-49
Seattle, WA 98124
USA
Email: fltemplin@acm.org
Templin Expires December 25, 2011 [Page 27]
| PAFTECH AB 2003-2026 | 2026-04-24 17:54:55 |