[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 RFC 6964

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


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

Abstract

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

Status of this Memo

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

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

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

   This Internet-Draft will expire on November 19, 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 November 19, 2011               [Page 1]

Internet-Draft             Routing Loop Attack                  May 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 . . . . . . . . . .  5
     3.3.  ISATAP Host Behavior . . . . . . . . . . . . . . . . . . .  5
     3.4.  Reference Operational Scenario . . . . . . . . . . . . . .  6
     3.5.  Loop Avoidance . . . . . . . . . . . . . . . . . . . . . .  8
   4.  DHCPv6 Services  . . . . . . . . . . . . . . . . . . . . . . .  8
     4.1.  Advertising ISATAP Router Behavior . . . . . . . . . . . .  9
     4.2.  Non-Advertising ISATAP Router Behavior . . . . . . . . . .  9
     4.3.  ISATAP Host Behavior . . . . . . . . . . . . . . . . . . . 10
     4.4.  Reference Operational Scenario . . . . . . . . . . . . . . 10
     4.5.  Loop Avoidance . . . . . . . . . . . . . . . . . . . . . . 13
   5.  Scaling Considerations . . . . . . . . . . . . . . . . . . . . 13
   6.  On-Demand Dynamic Routing  . . . . . . . . . . . . . . . . . . 14
   7.  Site Administration Considerations . . . . . . . . . . . . . . 14
     7.1.  A Simple Example . . . . . . . . . . . . . . . . . . . . . 15
   8.  Site Renumbering Considerations  . . . . . . . . . . . . . . . 15
   9.  Path MTU Considerations  . . . . . . . . . . . . . . . . . . . 16
   10. Alternative Approaches . . . . . . . . . . . . . . . . . . . . 17
   11. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 17
   12. Security Considerations  . . . . . . . . . . . . . . . . . . . 17
   13. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 18
   14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
     14.1. Normative References . . . . . . . . . . . . . . . . . . . 18
     14.2. Informative References . . . . . . . . . . . . . . . . . . 18
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20












Templin                 Expires November 19, 2011               [Page 2]

Internet-Draft             Routing Loop Attack                  May 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 November 19, 2011               [Page 3]

Internet-Draft             Routing Loop Attack                  May 2011


   native or the near-native prefixes offered by 6rd [RFC5969].  Larger
   sites typically obtain provider independent IPv6 prefixes from an
   Internet registry and advertise the prefixes into the IPv6 routing
   system on their own behalf, i.e., they act as an ISP unto themselves.
   In either case, after obtaining IPv6 prefixes the site can
   automatically enable IPv6 services internally by configuring ISATAP.

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

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

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

   After the PRL is published, ISATAP clients within the site will
   automatically perform a standard IPv6 Neighbor Discovery Router
   Solicitation (RS) / Router Advertisement (RA) exchange with
   advertising ISATAP routers [RFC4861][RFC5214].  Each ISATAP client



Templin                 Expires November 19, 2011               [Page 4]

Internet-Draft             Routing Loop Attack                  May 2011


   can also test the round-trip delays to multiple advertising ISATAP
   routers during an initial exchange, and select those routers with the
   smallest delays.  Site administrators could further include an IPv4
   anycast address in the PRL, and assign the address to multiple
   advertising ISATAP routers.  In that case, IPv4 routing within the
   site would direct the ISATAP client to the nearest advertising ISATAP
   router.

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


3.  SLAAC Services

   Predominantly IPv4 sites can enable ISATAP SLAAC services for ISATAP
   clients that need to communicate with IPv6 correspondents.  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 the
   same IPv6 prefixes or a different set of IPv6 prefixes.  For example,
   a first router may advertise 2001:db8:1::/64, a second may advertise
   2001:db8:2::/64, etc.

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



Templin                 Expires November 19, 2011               [Page 5]

Internet-Draft             Routing Loop Attack                  May 2011


   ISATAP interface are known as ISATAP addresses.  Similarly, any IPv6
   prefixes in PIOs received on an ISATAP interface with the L flag set
   to 1 are known as ISATAP prefixes.

3.4.  Reference Operational Scenario

   Figure 1 depicts a reference ISATAP network topology for allowing
   hosts within a predominantly IPv4 site to configure IPv6 services
   using ISATAP with SLAAC.  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:
                  .-(::::::::)      2001:db8:3::1
               .-(::: IPv6 :::)-.  +-------------+
              (:::: Internet ::::) | IPv6 Host E |
               `-(::::::::::::)-'  +-------------+
                  `-(::::::)-'
      +------------+       +------------+
      |  Router A  |---.---|  Router B  |.
     ,|  (isatap)  |       |  (isatap)  | `\
    / +------------+       +------------+    \
   :  fe80::*:192.0.1.1    fe80::*:192.0.1.2  :
    \ 2001:db8:1::/64      2001:db8:1::/64   /
     :                                      :
      :                                   :
      +-             IPv4 Site         -+
     ;     (PRL: 192.0.2.1, 192.0.2.2)   :
     |                                   ;
     :                                -+-'
      `-.                              .)
         \                           _)
          `-----+--------)----+'----'
      fe80::*:192.0.2.3           fe80::*:192.0.2.4
   2001:db8:1::*:192.0.2.3     2001:db8:1::*:192.0.2.4
     +--------------+           +--------------+
     |   (isatap)   |           |   (isatap)   |
     |    Host C    |           |    Host D    |
     +--------------+           +--------------+

   (* == "5efe")

          Figure 1: Reference ISATAP Network Topology using SLAAC

   In Figure 1, advertising ISATAP routers 'A' and 'B' within the IPv4
   site connect to the IPv6 Internet.  (Note that the routers may
   instead connect to the IPv6 Internet via a companion gateway as shown
   in Figure 2.)  Advertising ISATAP router 'A' configures a site-
   interior IPv4 interface with address 192.0.2.1 and arranges to add
   the address to the site's PRL.  'A' next configures an advertising



Templin                 Expires November 19, 2011               [Page 6]

Internet-Draft             Routing Loop Attack                  May 2011


   ISATAP router interface with link-local ISATAP address fe80::5efe:
   192.0.2.1 over the IPv4 interface.  In the same fashion, 'B'
   configures the IPv4 interface address 192.0.2.2, adds the address to
   the PRL, then configures its advertising ISATAP router interface with
   link-local ISATAP address fe80::5efe:192.0.2.2.

   ISATAP host 'C' connects to the site via an IPv4 interface with
   address 192.0.2.3, and also configures an ISATAP host interface with
   link-local ISATAP address fe80::5efe:192.0.2.3 over the IPv4
   interface.  'C' next resolves the PRL to discover the address
   192.0.2.1 and performs an RS/RA exchange with 'A'.  Based on the RA
   information, 'C' next 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:1::/64 advertised in the PIO.  When 'C'
   processes the prefix, it uses SLAAC to automatically configure the
   ISATAP address 2001:db8:1::5efe:192.0.2.3.  'C' then assigns the
   address to the ISATAP interface.

   In the same fashion, ISATAP host 'D' configures its IPv4 interface
   with address 192.0.2.4 and configures its ISATAP interface with link-
   local ISATAP address fe80::5efe:192.0.2.4.  'D' next performs an
   RS/RA exchange with 'B', then uses SLAAC to autoconfigure the ISATAP
   address 2001:db8:1::5efe:192.0.2.4.

   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:3::1.

   Following this autoconfiguration, when host 'C' has an IPv6 packet to
   send to host 'E', it prepares the packet with source address 2001:
   db8::5efe:192.0.2.3 and destination address 2001:db8:3::1.  'C' then
   uses IPv6-in-IPv4 encapsulation to forward the packet to router 'A',
   which in turn decapsulates the packet and forwards it into the public
   IPv6 Internet where it will be conveyed to 'E' via normal IPv6
   routing.  (Note that 'A' may "translate" the packet as it is
   forwarded across the site boundary such that it appears to come from
   a different source address than the one used by host 'C' within the
   site.)  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 'C' connects to host 'D', it has the option of using the
   native IPv4 service or the ISATAP IPv6-in-IPv4 encapsulation service
   since the two hosts configure ISATAP addresses from the same ISATAP
   prefix which implies that they are within the same contiguous IPv4
   routing region (see Section 7).  In that case, the hosts would be
   better served to continue to use legacy IPv4 services in order to



Templin                 Expires November 19, 2011               [Page 7]

Internet-Draft             Routing Loop Attack                  May 2011


   avoid encapsulation overhead and to avoid any IPv4 protocol-41
   filtering middleboxes that may be in the path.  If the hosts instead
   configured ISATAP addresses from different prefixes, however, 'C'
   would instead need to use IPv6 since there is no guarantee that the
   two hosts are within the same contiguous IPv4 routing region.  In
   that case, 'C' uses IPv6-in-IPv4 encapsulation to forward its IPv6
   packets to advertising ISATAP router 'A', which in turn conveys the
   packets to 'D' either directly or via another advertising ISATAP
   router 'B' that services the prefix used by 'D'..

3.5.  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 1 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 1, when 'A' receives a packet coming
   from the IPv6 Internet with destination address 2001:db8:1::5efe:
   192.0.2.2, it drops the packet since the IPv4 address 192.0.2.2
   corresponds to advertising ISATAP router 'B'.  Similarly, when 'B'
   receives a packet coming from the tunnel with an IPv6 destination
   address that would cause the packet to be forwarded back out to the
   IPv6 Internet and with an IPv4 source address 192.0.2.1, it drops the
   packet since 192.0.2.1 corresponds to advertising ISATAP router 'A'.


4.  DHCPv6 Services

   Whether or not advertising ISATAP routers make stateless IPv6
   services available using SLAAC, they can also provide managed IPv6
   services to ISATAP clients (i.e., both hosts and non-advertising
   ISATAP routers) using the Dynamic Host Configuration Protocol for
   IPv6 (DHCPv6).  Any addresses/prefixes obtained via DHCPv6 are



Templin                 Expires November 19, 2011               [Page 8]

Internet-Draft             Routing Loop Attack                  May 2011


   distinct from any IPv6 prefixes assigned to 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.

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



Templin                 Expires November 19, 2011               [Page 9]

Internet-Draft             Routing Loop Attack                  May 2011


   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

   Figure 2 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 November 19, 2011              [Page 10]

Internet-Draft             Routing Loop Attack                  May 2011


                    .-(::::::::)      2001:db8:3::1
                 .-(::: IPv6 :::)-.  +-------------+
                (:::: Internet ::::) | IPv6 Host H |
                 `-(::::::::::::)-'  +-------------+
                    `-(::::::)-'
                ,~~~~~~~~~~~~~~~~~,
           ,----|companion gateway|--.
          /     '~~~~~~~~~~~~~~~~~'  :
         /                           |.
      ,-'                              `.
     ;  +------------+   +------------+  )
     :  |  Router A  |   |  Router B  |  /    fe80::*1:92.0.2.5
      : |  (isatap)  |   |  (isatap)  | ;       2001:db8:2::1
      + +------------+   +------------+  \    +--------------+
     fe80::*:192.0.2.1   fe80::*:192.0.2.2    |   (isatap)   |
     |                                   ;    |    Host G    |
     :              IPv4 Site         -+-'    +--------------+
      `-. (PRL: 192.0.2.1, 192.0.2.2)  .)
         \                           _)
          `-----+--------)----+'----'
     fe80::*:192.0.2.3        fe80::*:192.0.2.4         .-.
     +--------------+         +--------------+       ,-(  _)-.
     |   (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 2: Reference ISATAP Network Topology using DHCPv6

   In Figure 2, 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.)  Advertising ISATAP router 'A' configures a
   provider network IPv4 interface with address 192.0.2.1 and arranges
   to add the address to the provider network PRL.  'A' next configures
   an advertising ISATAP router interface with link-local ISATAP address
   fe80::5efe:192.0.2.1 over the IPv4 interface.  In the same fashion,
   advertising ISATAP router 'B' configures the IPv4 interface address
   192.0.2.2, adds the address to the PRL, then configures the ISATAP
   interface link-local address fe80::5efe:192.0.2.2.



Templin                 Expires November 19, 2011              [Page 11]

Internet-Draft             Routing Loop Attack                  May 2011


   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.3, but it does not add the IPv4 address to the site's
   PRL.  'C' next configures a non-advertising ISATAP router interface
   with link-local ISATAP address fe80::5efe:192.0.2.3, then receives
   the IPv6 prefix 2001:db8::/48 through a DHCPv6 prefix delegation
   exchange via one of 'A' or 'B'.  'C' 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, 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.4, the link-local
   ISATAP address fe80::5efe:192.0.2.4, and the delegated IPv6 prefix
   2001:db8:1::/48.  'E' finally 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.5, and also configures an ISATAP host interface with
   link-local ISATAP address fe80::5efe:192.0.2.5 over the IPv4
   interface.  'G' next performs an RS/RA exchange with 'B' to configure
   default IPv6 route with next-hop address fe80::5efe:192.0.2.2, then
   receives the IPv6 address 2001:db8:2::1 from a DHCPv6 address
   configuration exchange via 'B'.  When 'G' receives the IPv6 address,
   it 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
   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



Templin                 Expires November 19, 2011              [Page 12]

Internet-Draft             Routing Loop Attack                  May 2011


   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., a router that advertises "default"),
   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.  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.  Scaling Considerations

   Figure 1 and Figure 2 depict ISATAP network topologies with only two
   advertising ISATAP routers within the site.  In order to support
   larger numbers of ISATAP clients, 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.



Templin                 Expires November 19, 2011              [Page 13]

Internet-Draft             Routing Loop Attack                  May 2011


6.  On-Demand Dynamic Routing

   With respect to the reference operational scenarios depicted in
   Figure 2, 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
   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].


7.  Site Administration Considerations

   In common practice, site administrators often deploy packet filtering
   devices of various forms in order to divide the site into separate
   partitions.  Such devices may prevent IPv4 protocol-41 packets from
   traversing a partition boundary even when other IPv4 protocol packets
   are permitted to traverse the boundary.  In order to avoid
   communication failures that may result from filtering, ISATAP clients
   should only enable the service after an initial reachability exchange
   with an advertising ISATAP router.  Communications between ISATAP
   clients that configure addresses from the same ISATAP prefix should
   therefore also only be used when the path between the clients is
   first tested in an initial reachability exchange.

   In order to provide a simple service that does not interact poorly
   with existing site topological arrangements, site administrators can
   configure advertising ISATAP routers to align their advertised ISATAP
   prefixes with the site's underlying IPv4 network partitions by
   advertising different prefixes to different sets of clients (e.g., as
   identified by the client's IPv4 prefix).  Site administrators can
   further institute a policy that prefers native IPv4 addresses over
   ISATAP addresses for intra-site communications when possible.

   Site administrators can implement this policy by configuring address
   selection policy rules in each ISATAP client that prefer IPv4
   destination addresses over destination addresses derived from their
   ISATAP prefixes [RFC3484].  For example, if the site has reserved the



Templin                 Expires November 19, 2011              [Page 14]

Internet-Draft             Routing Loop Attack                  May 2011


   prefix 2001:db8::/64 for ISATAP SLAAC services, each ISATAP client
   could add the prefix 2001:db8::/64 to its address selection policy
   table with a lower precedence than the prefix ::ffff:0:0/96.  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].

7.1.  A Simple Example

   Consider a large, multinational enterprise network that wishes to
   enable IPv6 services without significant alterations to its long-
   established IPv4 network operations and policies.  The enterprise
   network has a mature IPv4 routing and addressing system; possibly
   including firewalling and filtering policies which divide the
   enterprise into multiple partitions.

   The enterprise network administrators obtain a single IPv6 prefix
   such as 2001:db8::/64 and arrange to advertise the prefix into the
   global IPv6 routing system.  The administrators further configure
   sufficient advertising ISATAP routers throughout the enterprise
   network so that there will be at least one advertising ISATAP router
   within close topological and/or geographic proximity with all
   potential ISATAP clients.  Each advertising ISATAP router is
   configured to advertise the IPv6 prefix 2001:db8::/64 on its
   advertising ISATAP interface.  Each advertising ISATAP router
   configures an IPv4 anycast address such as 192.0.2.1 (e.g., by
   assigning the address to a loopback interface) and advertises the
   address within the enterprise-interior IPv4 routing system.

   Finally, the administrators configure all prospective ISATAP clients
   to prefer IPv4 addresses over IPv6 addresses derived from the prefix
   2001:db8::/64 so that clients will continue to use IPv4 services for
   communications within the enterprise network as they have always
   done.  When the prospective clients have been configured with the
   correct address selection policies, the enterprise network
   administrators finally add the IPv4 anycast address 192.0.2.1 to the
   PRL for the enterprise, e.g., by adding the address to the resource
   records for the name "isatap" within the enterprise network name
   service.  This action automatically enables the ISATAP service for
   all prospective clients, which can then use SLAAC to configure an
   ISATAP address from the prefix 2001:db8::/64 and use the address to
   communicate with IPv6 correspondents outside of the enterprise
   network.


8.  Site Renumbering Considerations

   Advertising ISATAP routers distribute IPv6 prefixes to ISATAP clients



Templin                 Expires November 19, 2011              [Page 15]

Internet-Draft             Routing Loop Attack                  May 2011


   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 basic 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 the 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
   via secure dynamic updates to the DNS.


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



Templin                 Expires November 19, 2011              [Page 16]

Internet-Draft             Routing Loop Attack                  May 2011


   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.


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

   IRON [RFC6179], RANGER [RFC5720], VET [RFC5558] and SEAL [RFC5320]
   are a tribute to those in all walks of life who serve with dignity
   and honor for the benefit of others.


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 November 19, 2011              [Page 17]

Internet-Draft             Routing Loop Attack                  May 2011


13.  Acknowledgments

   The following are acknowledged for their insights that helped shape
   this work: Fred Baker, Brian Carpenter, Thomas Henderson, Philip
   Homburg, Lee Howard, Ray Hunter, Joel Jaeggli, 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]
              Nakibly, G. and F. Templin, "Routing Loop Attack using



Templin                 Expires November 19, 2011              [Page 18]

Internet-Draft             Routing Loop Attack                  May 2011


              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.

   [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,
              February 2006.

   [RFC4554]  Chown, T., "Use of VLANs for IPv4-IPv6 Coexistence in
              Enterprise Networks", RFC 4554, June 2006.



Templin                 Expires November 19, 2011              [Page 19]

Internet-Draft             Routing Loop Attack                  May 2011


   [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 November 19, 2011              [Page 20]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/