[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02 RFC 5579

Network Working Group                                    F. Templin, Ed.
Internet-Draft                                      Boeing Phantom Works
Intended status: Informational                         December 10, 2008
Expires: June 13, 2009


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

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of 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 June 13, 2009.

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








Templin                   Expires June 13, 2009                 [Page 1]


Internet-Draft         IPv4 over ISATAP Interfaces         December 2008


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.  ISATAPv4 Address Format . . . . . . . . . . . . . . . . . . 4
     6.2.  IPv4 Address Configuration  . . . . . . . . . . . . . . . . 5
     6.3.  IPv4 Route Configuration  . . . . . . . . . . . . . . . . . 5
     6.4.  ISATAP Interface Addressing Parameters  . . . . . . . . . . 5
     6.5.  Next Hop Resolution and ISATAP Interface Determination  . . 6
     6.6.  Underlying IPv4 Interface Determination . . . . . . . . . . 6
     6.7.  Encapsulation and Transmission  . . . . . . . . . . . . . . 7
     6.8.  Recursive Encapsulation Avoidance . . . . . . . . . . . . . 7
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
   8.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 7
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
     10.1. Normative References  . . . . . . . . . . . . . . . . . . . 7
     10.2. Informative References  . . . . . . . . . . . . . . . . . . 8
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 8
   Intellectual Property and Copyright Statements  . . . . . . . . . . 9



























Templin                   Expires June 13, 2009                 [Page 2]


Internet-Draft         IPv4 over ISATAP Interfaces         December 2008


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.  Indeed, in typical
   implementations and deployments, an ISATAP interface 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 an IPv4 routing region comprising
   ordinary IPv4 routers.  ISATAP router and host 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 host
   interfaces additionally configure IPv6 non-link-local addresses that
   encapsulate an IPv4 address from an underlying IPv4 interface in 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].

   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
   connected IPv4 routing region in a single IPv6 hop.  That is to say



Templin                   Expires June 13, 2009                 [Page 3]


Internet-Draft         IPv4 over ISATAP Interfaces         December 2008


   that the routing region comprises border nodes with ISATAP interfaces
   that send IPv6-in-IPv4 packets across the IPv4 routing region in a
   single IPv6 hop, and ordinary IPv4 routers between the border nodes
   that decrement the TTL in the outer IPv4 header.

   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 connected
   underlying IPv4 topology 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

6.1.  ISATAPv4 Address Format

   This document defines an imaginary 64-bit address format (i.e., the
   "ISATAPv4 address" format) that is the concatenation of a 32 bit IPv4
   link-local or global address as the prefix with the 32 bit IPv4
   address of an underlying IPv4 interface as the suffix.  The ISATAPv4
   address format is shown in Figure 1:

   |0                               3|3                              6|
   |0                               1|2                              3|
   +---------------------------------+--------------------------------+
   |  ISATAP Interface IPv4 Address  | Underlying Interface IPv4 Addr.|
   +---------------------------------+--------------------------------+

                     Figure 1: ISATAPv4 Address Format

   Since IPv4 address are only 32 bits in length, however, ISATAPv4
   addresses never appear as the source or destination addresses of
   packets on the wire.  Indeed, under normal circumstances they need
   not be represented in any physical manifestation in routing
   protocols, protocol stack implementations, documentation, etc.




Templin                   Expires June 13, 2009                 [Page 4]


Internet-Draft         IPv4 over ISATAP Interfaces         December 2008


   Instead, the 32-bit prefix part of the imaginary ISATAPv4 address is
   used for IPv4 address configuration on ISATAP interfaces while the
   32-bit suffix part is used for address resolution and next hop
   determination.

   In the future, ISATAPv4 addresses may be specified for inclusion in
   the Domain Name System (DNS) [RFC1035], e.g., as "AA" ("double-A")
   resource records.

6.2.  IPv4 Address Configuration

   ISATAP intefaces configure an IPv4 address taken from the prefix
   portion of an ISATAPv4 address (see: Section 6.1).

   ISATAP router interfaces that implement this specification configure
   an IPv4 link-local address per [RFC3927] as a minimal configuration
   to enable IPv4 operation.  The IPv4 link-local address must be unique
   among the addresses assigned to all of the node's interfaces, but it
   is not used as the source/destination address of IPv4 packets nor as
   a Router ID in a dynamic routing protocol therefore it need not be
   checked for uniqueness among all nodes connected over the ISATAP
   interface.

   ISATAP host interfaces (and ISATAP router interfaces that must also
   support host operations) instead configure a non-link-local IPv4
   address taken from an IPv4 prefix assigned to the ISATAP interface.
   Unlike IPv4 link-local addresses, however, non-link-local IPv4
   addresses must be managed for uniqueness among all nodes connected
   over the ISATAP interface.

6.3.  IPv4 Route Configuration

   As for any IPv4 interface, IPv4 Forwarding Information Base (FIB)
   entries (i.e., IPv4 routes) with an interface identifier
   corresponding to an ISATAP interface are configured via either
   administrative or dynamic mechanisms.

   Next hop addresses in FIB entries with an interface identifier
   corresponding to an ISATAP interface use the suffix from the ISATAPv4
   address (see: Section 6.1), i.e., the next hop address is taken from
   the IPv4 address of an underlying IPv4 interface of the next hop
   node.

6.4.  ISATAP Interface Addressing Parameters

   For each IPv4 packet transmitted over an ISATAP interface, the node
   must determine:




Templin                   Expires June 13, 2009                 [Page 5]


Internet-Draft         IPv4 over ISATAP Interfaces         December 2008


   o  'SRC-IP' - the IPv4 source address of the packet.

   o  'DST-IP' - the IPv4 destination address of the packet.

   o  'IS-ID' - the ID of the ISATAP interface via which 'DST-IP' is
      reached.

   o  'IS-NH' - the IPv4 address of the next hop toward 'DST-IP' via
      'IS-ID'.

   o  'UI-ID' - the ID of the underlying IPv4 interface via which
      'IS-NH' is reached.

   o  'UI-IP' - the IPv4 address assigned to the underlying IPv4
      interface.

   o  'UI-NH' - the L2 address for 'IS-NH' when 'IS-NH' is on-link on
      'UI-ID'; otherwise, the IPv4 address of the next hop toward
      'IS-NH'.

   Determination of these addressing parameters is discussed in the
   following sections.

6.5.  Next Hop Resolution and ISATAP Interface Determination

   When the node's IPv4 layer has a packet to send, it performs an IPv4
   FIB lookup on 'DST-IP' to determine 'IS-ID' and 'IS-NH'.  The node
   then checks the packet length against the MTU configured on the
   ISATAP interface indicated by 'IS-ID'.

   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 'SRC-IP' [RFC1191]; otherwise it
   fragments the packet using IPv4 fragmentation and admits each
   fragment into the ISATAP interface.

6.6.  Underlying IPv4 Interface Determination

   After the node admits an IPv4 packet/fragment into the ISATAP
   interface, it performs an IPv4 FIB lookup on 'IS-NH' to determine a
   FIB table entry containing 'UI-ID', 'UI-IP' and 'UI-NH' for the
   underlying IPv4 interface.  If the lookup fails, the node drops the
   packet and returns an ICMPv4 "Destination Unreachable" message to
   'SRC-IP' [RFC0792]; otherwise, it encapsulates the packet and submits
   it to the IPv4 layer as described below.




Templin                   Expires June 13, 2009                 [Page 6]


Internet-Draft         IPv4 over ISATAP Interfaces         December 2008


6.7.  Encapsulation and Transmission

   After performing the IPv4 FIB lookup on 'IS-NH' (see Section 6.6), if
   'IS-NH' is not on-link on the underlying interface identified by
   'UD-ID', the node encapsulates the packet as specified in [RFC2003]
   with (src='UI-IP'; dst = 'IS-NH') in the outer IPv4 header and sets
   the DF flag in the outer IPv4 header according to Section 3.2 of
   [RFC4213].  If 'IS-NH' is on-link on the underlying interface,
   however, the node omits this encapsulation.

   The node then submits the packet to the IPv4 layer with a pointer to
   the FIB table entry containing 'UI-ID', 'UI-IP' and 'UI-NH'.  The
   IPv4 layer fragments the encapsulated packet if necessary, then
   forwards each fragment to the underlying IPv4 interface.  The
   underlying IPv4 interface then performs address resolution to
   determine the L2 address for 'UI-NH', then forwards the packet to the
   L2 address via the underlying link layer.

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

   Security considerations for tunneling are found in the normative
   references.


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

10.1.  Normative References

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



Templin                   Expires June 13, 2009                 [Page 7]


Internet-Draft         IPv4 over ISATAP Interfaces         December 2008


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

   [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

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


Author's Address

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

   Email: fltemplin@acm.org










Templin                   Expires June 13, 2009                 [Page 8]


Internet-Draft         IPv4 over ISATAP Interfaces         December 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.











Templin                   Expires June 13, 2009                 [Page 9]


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