Transmission of IPv4 Packets over Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) Interfaces
draft-templin-isatapv4-02

Network Working Group                                    F. Templin, Ed.
Internet-Draft                              Boeing Research & Technology
Intended status: Informational                            March 24, 2009
Expires: September 25, 2009

          Transmission of IPv4 Packets over ISATAP Interfaces
                     draft-templin-isatapv4-02.txt

Status of this Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

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

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on September 25, 2009.

Copyright Notice

   Copyright (c) 2009 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 in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Abstract

   The Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)
   specifies a Non-Broadcast, Multiple Access (NBMA) interface type for
   the transmission of IPv6 packets over IPv4 networks using automatic

Templin                Expires September 25, 2009               [Page 1]
Internet-Draft         IPv4 over ISATAP Interfaces            March 2009

   IPv6-in-IPv4 encapsulation.  The original specifications make no
   provisions for the encapsulation and transmission of IPv4 packets,
   however.  This document specifies a method for transmitting IPv4
   packets over ISATAP interfaces.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  ISATAP Interface Model  . . . . . . . . . . . . . . . . . . . . 3
   4.  ISATAP Interface MTU  . . . . . . . . . . . . . . . . . . . . . 4
   5.  IPv6 Operation  . . . . . . . . . . . . . . . . . . . . . . . . 4
   6.  IPv4 Operation  . . . . . . . . . . . . . . . . . . . . . . . . 4
     6.1.  ISATAP IPv4 Address Configuration . . . . . . . . . . . . . 4
     6.2.  IPv4 Route Configuration  . . . . . . . . . . . . . . . . . 5
     6.3.  ISATAP Interface Determination  . . . . . . . . . . . . . . 5
     6.4.  Next-Hop Resolution . . . . . . . . . . . . . . . . . . . . 5
     6.5.  Encapsulation and Transmission  . . . . . . . . . . . . . . 6
     6.6.  IPv4 Multicast Mapping  . . . . . . . . . . . . . . . . . . 6
     6.7.  Recursive Encapsulation Avoidance . . . . . . . . . . . . . 7
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
   8.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 7
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . . . 8
     10.1. Normative References  . . . . . . . . . . . . . . . . . . . 8
     10.2. Informative References  . . . . . . . . . . . . . . . . . . 8
   Appendix A.  Encapsulation Avoidance  . . . . . . . . . . . . . . . 9
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 9

Templin                Expires September 25, 2009               [Page 2]
Internet-Draft         IPv4 over ISATAP Interfaces            March 2009

1.  Introduction

   The Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)
   [RFC5214] specifies a Non-Broadcast, Multiple Access (NBMA) interface
   type for the transmission of IPv6 packets over IPv4 networks using
   automatic IPv6-in-IPv4 encapsulation.  ISATAP interfaces therefore
   typically configure IPv6 addresses and prefixes, but they do not
   configure IPv4 addresses and prefixes.  In typical implementations
   and deployments, an ISATAP interface therefore appears as an ordinary
   interface configured for IPv6 operation but with a null IPv4
   configuration.  This places an unnecessary limitation on the ISATAP
   domain of applicability.

   ISATAP interfaces perform automatic IPv6-in-IPv4 encapsulation over a
   virtual IPv6 overlay that spans a region within a connected IPv4
   routing topology (i.e., a "site") comprising ordinary IPv4 routers.
   ISATAP interfaces configure IPv6 link-local addresses that
   encapsulate an IPv4 address assigned to an underlying IPv4 interface
   within the IPv6 link-local prefix 'fe80::/10' as specified in
   [RFC5214], Sections 6 and 7.  ISATAP interfaces may additionally
   configure IPv6 addresses from a non-link-local IPv6 prefix in exactly
   the same fashion.  As a result, [RFC5214] extends the basic
   transition mechanisms specified in [RFC4213].

   This document specifies mechanisms and operational practices that
   enable automatic IPv4-in-IPv4 encapsulation over ISATAP interfaces in
   the same manner as for IPv6-in-IPv4 encapsulation.  As a result, this
   document also extends the IPv4-in-IPv4 tunneling mechanisms specified
   in [RFC2003].  These mechanisms are useful in a wide variety of
   enterprise network scenarios, e.g., as discussed in the RANGER
   [I-D.templin-ranger] and VET [I-D.templin-autoconf-dhcp] proposals.

   The following sections specify IPv4 operation over ISATAP interfaces.
   A working knowledge of the IPv4 and IPv6 protocols [RFC0791]
   [RFC2460], IPv4-in-IPv4 encapsulation [RFC2003], and IPv6-in-IPv4
   encapsulation [RFC4213][RFC5214] is assumed.

2.  Terminology

   The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
   SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
   document, are to be interpreted as described in [RFC2119].

3.  ISATAP Interface Model

   ISATAP interfaces use automatic IPv6-in-IPv4 encapsulation to span a

Templin                Expires September 25, 2009               [Page 3]
Internet-Draft         IPv4 over ISATAP Interfaces            March 2009

   region within a connected IPv4 routing topology (i.e., a "site") in a
   single IPv6 hop.  That is to say that the site comprises border nodes
   with ISATAP interfaces that forward IPv6-in-IPv4 packets across the
   site in a single IPv6 hop, and ordinary IPv4 routers between the
   border nodes that decrement the TTL in the outer IPv4 header.  Border
   nodes that configure ISATAP interfaces within the same site therefore
   see each other as single-hop neighbors.

   ISATAP interfaces are configured over one or more of the node's
   underlying IPv4 interfaces connected to the site.  These underlying
   IPv4 interfaces configure site- or greater-scoped IPv4 addresses, and
   the underlying IPv4 interfaces of two "neighboring" ISATAP interfaces
   may be separated by many IPv4 hops within the site.

   This specification simply extends the ISATAP interface model to also
   support IPv4-in-IPv4 encapsulation.  When IPv4-in-IPv4 encapsulation
   is used, the ISATAP interface spans exactly the same underlying site
   as for IPv6-in-IPv4 encapsulation.

4.  ISATAP Interface MTU

   ISATAP interface MTU considerations are exactly as specified in
   [RFC4213], Section 3.2, and apply equally for both IPv6 and IPv4
   operation.

5.  IPv6 Operation

   IPv6 operations over ISATAP interfaces are exactly as specified in
   [RFC5214].

6.  IPv4 Operation

   The following sections specify IPv4 operation over ISATAP interfaces:

6.1.  ISATAP IPv4 Address Configuration

   As for IPv6 operation, IPv4 operation requires that all ISATAP
   interfaces connected to the same site configure a unique Layer 3 IPv4
   address ("L3ADDR") taken from a shared IPv4 subnet prefix.  L3ADDR is
   used for next-hop determination, but it may also be used as the
   source address for packets that originate from the ISATAP interface
   itself.

   When global-scoped communications are needed, or when a unique "name"
   for the ISATAP site is required (e.g., to distinguish it from other

Templin                Expires September 25, 2009               [Page 4]
Internet-Draft         IPv4 over ISATAP Interfaces            March 2009

   ISATAP sites), L3ADDR is taken from a global-scoped IPv4 prefix
   (e.g., 192.0.2/24).  Otherwise, it may be taken from a link-local-
   scoped IPv4 prefix (e.g., 169.254/16 [RFC3927]).

   Methods for ensuring L3ADDR uniqueness are outside the scope of this
   document.

6.2.  IPv4 Route Configuration

   As for any IPv4 interface, IPv4 Forwarding Information Base (FIB)
   entries (i.e., IPv4 routes) are configured over ISATAP interfaces via
   either administrative or dynamic mechanisms.

   Next hop addresses in FIB entries configured over an ISATAP interface
   correspond to the L3ADDR assigned to the ISATAP interface of a
   neighbor.

6.3.  ISATAP Interface Determination

   When the node's IPv4 layer has a packet to send, it performs an IPv4
   FIB lookup to determine the outgoing ISATAP interface and the next-
   hop L3ADDR.  The node then checks the packet length against the MTU
   configured on the ISATAP interface.

   If the packet is no larger than the MTU, the node admits it into the
   ISATAP interface without fragmentation.  If the packet is larger than
   the MTU, the node examines the "Don't Fragment (DF)" flag in the IPv4
   header.  If DF=1, it drops the packet and returns an ICMPv4
   "fragmentation needed" message to the original source [RFC1191];
   otherwise it fragments the packet using IPv4 fragmentation and admits
   each fragment into the ISATAP interface.

6.4.  Next-Hop Resolution

   When the node admits an IPv4 packet/fragment into the ISATAP
   interface, it resolves the next-hop L3ADDR into a next-hop Layer 2
   address ("L2ADDR") which in reality is the IPv4 address of an
   underlying interface of the ISATAP neighbor which may be many IPv4
   hops away.  Methods for resolving the next-hop L3ADDR into a next-hop
   L2ADDR are through static table lookup or through some other means
   outside the scope of this document.

   The node next performs an IPv4 FIB lookup on the next-hop L2ADDR to
   determine the correct underlying IPv4 interface.  If the FIB lookup
   fails, the node drops the packet and returns an ICMPv4 "Destination
   Unreachable" message to the original source [RFC0792]; otherwise, it
   encapsulates the packet and submits it to the IPv4 layer as described
   below.

Templin                Expires September 25, 2009               [Page 5]
Internet-Draft         IPv4 over ISATAP Interfaces            March 2009

6.5.  Encapsulation and Transmission

   After performing the IPv4 FIB lookup on the next-hop L2ADDR, the node
   encapsulates the packet as specified in [RFC2003] with the IPv4
   address of the underlying interface as the outer IPv4 source address
   and the next-hop L2ADDR as the outer IPv4 destination address.  The
   node sets the DF flag in the outer IPv4 header according to Section
   3.2 of [RFC4213].  The node also sets the IP protocol field in the
   outer IPv4 header to 4 (i.e., ip-protocol-4).

   The node then submits the encapsulated packet to the IPv4 layer.  The
   IPv4 layer fragments the packet if necessary, then forwards each
   fragment to the underlying IPv4 interface.  The underlying IPv4
   interface then performs address resolution on the outer IPv4
   destination address (i.e., the next-hop L2ADDR) and submits the
   packet for transmission on the underlying link layer.

6.6.  IPv4 Multicast Mapping

   In many aspects, ISATAP is simply a unicast-only derivative of
   "6over4" [RFC2529].  For various reasons, however, ISATAP has seen
   practical wide-scale deployment while the 6over4 approach has been
   silently carried forward through ongoing research efforts.  This
   specification extends the ISATAP interface model to support IPv4
   multicast mapping in a manner that exactly parallels IPv6 multicast
   mapping in 6over4 (see: [RFC2529], Section 6).  Indeed, the approach
   might more aptly be named as "4over4" were it not for the fact that
   the name "ISATAP" has already become ingrained in the widely
   published terminology.

   IPv4 multicast mapping is available only on ISATAP interfaces
   configured over sites that support IPv4 multicast.  For such sites,
   an IPv4 packet sent on an ISATAP interface with a multicast
   destination address DST MUST be encapsulated for transmission on an
   underlying IPv4 interface to the IPv4 multicast address of
   Organization-Local Scope using the mapping below.  The mapped address
   SHOULD be taken from the block 239.193.0.0/16, a different sub-block
   of the Organization-Local Scope address block, or, if all of those
   are not available, from the expansion blocks defined in [RFC2365].
   Note that when they are formed using the expansion blocks, they use
   only a /16 sized block.

Templin                Expires September 25, 2009               [Page 6]
Internet-Draft         IPv4 over ISATAP Interfaces            March 2009

   +-------+-------+-------+-------+
   |  239  |  OLS  | DST2  | DST3  |
   +-------+-------+-------+-------+

       DST2, DST3          last two bytes of IPv4 multicast address.

       OLS                 from the configured Organization-Local
                           Scope address block.  SHOULD be 193,
                           see [RFC2365] for details.

                   Figure 1: ISATAPv4 Multicast Mapping

   No new IANA registration procedures are required for the above.

6.7.  Recursive Encapsulation Avoidance

   The node must take care in managing its IPv4 FIB table entries in
   order to avoid looping through recursive encapsulations.

7.  IANA Considerations

   There are no IANA considerations for this document.

8.  Security Considerations

   The security considerations specified in [RFC2003] apply equally to
   this document.  The security considerations specified in ISATAP
   [RFC5214] and 6over4 [RFC2529] also apply, with the exception that
   ip-protocol-4 encapsulation is used instead of ip-protocol-41.

   Updated tunnel security considerations are found in
   [I-D.ietf-v6ops-tunnel-security-concerns].

9.  Acknowledgements

   This work extends the ISATAP interface model, which has evolved
   through the insights of many contributers over the course of many
   decades.

10.  References

Templin                Expires September 25, 2009               [Page 7]
Internet-Draft         IPv4 over ISATAP Interfaces            March 2009

10.1.  Normative References

   [RFC0791]  Postel, J., "Internet Protocol", STD 5, RFC 791,
              September 1981.

   [RFC0792]  Postel, J., "Internet Control Message Protocol", STD 5,
              RFC 792, September 1981.

   [RFC1191]  Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
              November 1990.

   [RFC2003]  Perkins, C., "IP Encapsulation within IP", RFC 2003,
              October 1996.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, December 1998.

   [RFC2529]  Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4
              Domains without Explicit Tunnels", RFC 2529, March 1999.

   [RFC3927]  Cheshire, S., Aboba, B., and E. Guttman, "Dynamic
              Configuration of IPv4 Link-Local Addresses", RFC 3927,
              May 2005.

   [RFC4213]  Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
              for IPv6 Hosts and Routers", RFC 4213, October 2005.

   [RFC5214]  Templin, F., Gleeson, T., and D. Thaler, "Intra-Site
              Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214,
              March 2008.

10.2.  Informative References

   [I-D.ietf-v6ops-tunnel-security-concerns]
              Hoagland, J., Krishnan, S., and D. Thaler, "Security
              Concerns With IP Tunneling",
              draft-ietf-v6ops-tunnel-security-concerns-01 (work in
              progress), October 2008.

   [I-D.templin-autoconf-dhcp]
              Templin, F., "Virtual Enterprise Traversal (VET)",
              draft-templin-autoconf-dhcp-37 (work in progress),
              March 2009.

   [I-D.templin-ranger]

Templin                Expires September 25, 2009               [Page 8]
Internet-Draft         IPv4 over ISATAP Interfaces            March 2009

              Templin, F., "Routing and Addressing in Next-Generation
              EnteRprises (RANGER)", draft-templin-ranger-07 (work in
              progress), February 2009.

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, November 1987.

   [RFC2365]  Meyer, D., "Administratively Scoped IP Multicast", BCP 23,
              RFC 2365, July 1998.

Appendix A.  Encapsulation Avoidance

   In some instances, an ISATAP interface may be configured over a site
   in which all single-hop ISATAP neighbors are also known to be single-
   hop neighbors in the underlying site.  In that case alone, if the
   next-hop L3ADDR and next-hop L2ADDR are both routable within the
   underlying site the ISATAP interface MAY avoid encapsulation and
   submit the unencapsulated packets directly to the IPv4 layer while
   using the next-hop L2ADDR (i.e., and not the next-hop L3ADDR) as the
   next hop.

Author's Address

   Fred L. Templin (editor)
   Boeing Research & Technology
   P.O. Box 3707 MC 7L-49
   Seattle, WA  98124
   USA

   Email: fltemplin@acm.org

Templin                Expires September 25, 2009               [Page 9]