Network Working Group F. Templin, Ed. Internet-Draft Boeing Research & Technology Intended status: Informational February 18, 2009 Expires: August 22, 2009 Transmission of IPv4 Packets over ISATAP Interfaces draft-templin-isatapv4-01.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 August 22, 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 (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. Abstract The Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) specifies a Non-Broadcast, Multiple Access (NBMA) interface type for Templin Expires August 22, 2009 [Page 1] Internet-Draft IPv4 over ISATAP Interfaces February 2009 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. 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 7 10.1. Normative References . . . . . . . . . . . . . . . . . . . 7 10.2. Informative References . . . . . . . . . . . . . . . . . . 8 Appendix A. Encapsulation Avoidance . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 Templin Expires August 22, 2009 [Page 2] Internet-Draft IPv4 over ISATAP Interfaces February 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]. 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 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 Templin Expires August 22, 2009 [Page 3] Internet-Draft IPv4 over ISATAP Interfaces February 2009 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 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- Templin Expires August 22, 2009 [Page 4] Internet-Draft IPv4 over ISATAP Interfaces February 2009 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 August 22, 2009 [Page 5] Internet-Draft IPv4 over ISATAP Interfaces February 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 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 IPv4 multicast mapping on ISATAP interfaces exactly parallels IPv6 multicast mapping (see: [RFC2529], Section 6). IPv4 multicast forwarding over the underlying IPv4 site MUST be available. 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. +-------+-------+-------+-------+ | 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. Templin Expires August 22, 2009 [Page 6] Internet-Draft IPv4 over ISATAP Interfaces February 2009 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 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. [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, Templin Expires August 22, 2009 [Page 7] Internet-Draft IPv4 over ISATAP Interfaces February 2009 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. [RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC 2365, July 1998. [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 Domains without Explicit Tunnels", RFC 2529, March 1999. 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 August 22, 2009 [Page 8]