idnits 2.17.1 draft-templin-isatapv4-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (March 24, 2009) is 5505 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC1035' is defined on line 352, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-04) exists of draft-ietf-v6ops-tunnel-security-concerns-01 == Outdated reference: A later version (-38) exists of draft-templin-autoconf-dhcp-37 == Outdated reference: A later version (-09) exists of draft-templin-ranger-07 Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Templin, Ed. 3 Internet-Draft Boeing Research & Technology 4 Intended status: Informational March 24, 2009 5 Expires: September 25, 2009 7 Transmission of IPv4 Packets over ISATAP Interfaces 8 draft-templin-isatapv4-02.txt 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on September 25, 2009. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 Abstract 46 The Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) 47 specifies a Non-Broadcast, Multiple Access (NBMA) interface type for 48 the transmission of IPv6 packets over IPv4 networks using automatic 49 IPv6-in-IPv4 encapsulation. The original specifications make no 50 provisions for the encapsulation and transmission of IPv4 packets, 51 however. This document specifies a method for transmitting IPv4 52 packets over ISATAP interfaces. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. ISATAP Interface Model . . . . . . . . . . . . . . . . . . . . 3 59 4. ISATAP Interface MTU . . . . . . . . . . . . . . . . . . . . . 4 60 5. IPv6 Operation . . . . . . . . . . . . . . . . . . . . . . . . 4 61 6. IPv4 Operation . . . . . . . . . . . . . . . . . . . . . . . . 4 62 6.1. ISATAP IPv4 Address Configuration . . . . . . . . . . . . . 4 63 6.2. IPv4 Route Configuration . . . . . . . . . . . . . . . . . 5 64 6.3. ISATAP Interface Determination . . . . . . . . . . . . . . 5 65 6.4. Next-Hop Resolution . . . . . . . . . . . . . . . . . . . . 5 66 6.5. Encapsulation and Transmission . . . . . . . . . . . . . . 6 67 6.6. IPv4 Multicast Mapping . . . . . . . . . . . . . . . . . . 6 68 6.7. Recursive Encapsulation Avoidance . . . . . . . . . . . . . 7 69 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 70 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 71 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 72 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 73 10.1. Normative References . . . . . . . . . . . . . . . . . . . 8 74 10.2. Informative References . . . . . . . . . . . . . . . . . . 8 75 Appendix A. Encapsulation Avoidance . . . . . . . . . . . . . . . 9 76 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 78 1. Introduction 80 The Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) 81 [RFC5214] specifies a Non-Broadcast, Multiple Access (NBMA) interface 82 type for the transmission of IPv6 packets over IPv4 networks using 83 automatic IPv6-in-IPv4 encapsulation. ISATAP interfaces therefore 84 typically configure IPv6 addresses and prefixes, but they do not 85 configure IPv4 addresses and prefixes. In typical implementations 86 and deployments, an ISATAP interface therefore appears as an ordinary 87 interface configured for IPv6 operation but with a null IPv4 88 configuration. This places an unnecessary limitation on the ISATAP 89 domain of applicability. 91 ISATAP interfaces perform automatic IPv6-in-IPv4 encapsulation over a 92 virtual IPv6 overlay that spans a region within a connected IPv4 93 routing topology (i.e., a "site") comprising ordinary IPv4 routers. 94 ISATAP interfaces configure IPv6 link-local addresses that 95 encapsulate an IPv4 address assigned to an underlying IPv4 interface 96 within the IPv6 link-local prefix 'fe80::/10' as specified in 97 [RFC5214], Sections 6 and 7. ISATAP interfaces may additionally 98 configure IPv6 addresses from a non-link-local IPv6 prefix in exactly 99 the same fashion. As a result, [RFC5214] extends the basic 100 transition mechanisms specified in [RFC4213]. 102 This document specifies mechanisms and operational practices that 103 enable automatic IPv4-in-IPv4 encapsulation over ISATAP interfaces in 104 the same manner as for IPv6-in-IPv4 encapsulation. As a result, this 105 document also extends the IPv4-in-IPv4 tunneling mechanisms specified 106 in [RFC2003]. These mechanisms are useful in a wide variety of 107 enterprise network scenarios, e.g., as discussed in the RANGER 108 [I-D.templin-ranger] and VET [I-D.templin-autoconf-dhcp] proposals. 110 The following sections specify IPv4 operation over ISATAP interfaces. 111 A working knowledge of the IPv4 and IPv6 protocols [RFC0791] 112 [RFC2460], IPv4-in-IPv4 encapsulation [RFC2003], and IPv6-in-IPv4 113 encapsulation [RFC4213][RFC5214] is assumed. 115 2. Terminology 117 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 118 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 119 document, are to be interpreted as described in [RFC2119]. 121 3. ISATAP Interface Model 123 ISATAP interfaces use automatic IPv6-in-IPv4 encapsulation to span a 124 region within a connected IPv4 routing topology (i.e., a "site") in a 125 single IPv6 hop. That is to say that the site comprises border nodes 126 with ISATAP interfaces that forward IPv6-in-IPv4 packets across the 127 site in a single IPv6 hop, and ordinary IPv4 routers between the 128 border nodes that decrement the TTL in the outer IPv4 header. Border 129 nodes that configure ISATAP interfaces within the same site therefore 130 see each other as single-hop neighbors. 132 ISATAP interfaces are configured over one or more of the node's 133 underlying IPv4 interfaces connected to the site. These underlying 134 IPv4 interfaces configure site- or greater-scoped IPv4 addresses, and 135 the underlying IPv4 interfaces of two "neighboring" ISATAP interfaces 136 may be separated by many IPv4 hops within the site. 138 This specification simply extends the ISATAP interface model to also 139 support IPv4-in-IPv4 encapsulation. When IPv4-in-IPv4 encapsulation 140 is used, the ISATAP interface spans exactly the same underlying site 141 as for IPv6-in-IPv4 encapsulation. 143 4. ISATAP Interface MTU 145 ISATAP interface MTU considerations are exactly as specified in 146 [RFC4213], Section 3.2, and apply equally for both IPv6 and IPv4 147 operation. 149 5. IPv6 Operation 151 IPv6 operations over ISATAP interfaces are exactly as specified in 152 [RFC5214]. 154 6. IPv4 Operation 156 The following sections specify IPv4 operation over ISATAP interfaces: 158 6.1. ISATAP IPv4 Address Configuration 160 As for IPv6 operation, IPv4 operation requires that all ISATAP 161 interfaces connected to the same site configure a unique Layer 3 IPv4 162 address ("L3ADDR") taken from a shared IPv4 subnet prefix. L3ADDR is 163 used for next-hop determination, but it may also be used as the 164 source address for packets that originate from the ISATAP interface 165 itself. 167 When global-scoped communications are needed, or when a unique "name" 168 for the ISATAP site is required (e.g., to distinguish it from other 169 ISATAP sites), L3ADDR is taken from a global-scoped IPv4 prefix 170 (e.g., 192.0.2/24). Otherwise, it may be taken from a link-local- 171 scoped IPv4 prefix (e.g., 169.254/16 [RFC3927]). 173 Methods for ensuring L3ADDR uniqueness are outside the scope of this 174 document. 176 6.2. IPv4 Route Configuration 178 As for any IPv4 interface, IPv4 Forwarding Information Base (FIB) 179 entries (i.e., IPv4 routes) are configured over ISATAP interfaces via 180 either administrative or dynamic mechanisms. 182 Next hop addresses in FIB entries configured over an ISATAP interface 183 correspond to the L3ADDR assigned to the ISATAP interface of a 184 neighbor. 186 6.3. ISATAP Interface Determination 188 When the node's IPv4 layer has a packet to send, it performs an IPv4 189 FIB lookup to determine the outgoing ISATAP interface and the next- 190 hop L3ADDR. The node then checks the packet length against the MTU 191 configured on the ISATAP interface. 193 If the packet is no larger than the MTU, the node admits it into the 194 ISATAP interface without fragmentation. If the packet is larger than 195 the MTU, the node examines the "Don't Fragment (DF)" flag in the IPv4 196 header. If DF=1, it drops the packet and returns an ICMPv4 197 "fragmentation needed" message to the original source [RFC1191]; 198 otherwise it fragments the packet using IPv4 fragmentation and admits 199 each fragment into the ISATAP interface. 201 6.4. Next-Hop Resolution 203 When the node admits an IPv4 packet/fragment into the ISATAP 204 interface, it resolves the next-hop L3ADDR into a next-hop Layer 2 205 address ("L2ADDR") which in reality is the IPv4 address of an 206 underlying interface of the ISATAP neighbor which may be many IPv4 207 hops away. Methods for resolving the next-hop L3ADDR into a next-hop 208 L2ADDR are through static table lookup or through some other means 209 outside the scope of this document. 211 The node next performs an IPv4 FIB lookup on the next-hop L2ADDR to 212 determine the correct underlying IPv4 interface. If the FIB lookup 213 fails, the node drops the packet and returns an ICMPv4 "Destination 214 Unreachable" message to the original source [RFC0792]; otherwise, it 215 encapsulates the packet and submits it to the IPv4 layer as described 216 below. 218 6.5. Encapsulation and Transmission 220 After performing the IPv4 FIB lookup on the next-hop L2ADDR, the node 221 encapsulates the packet as specified in [RFC2003] with the IPv4 222 address of the underlying interface as the outer IPv4 source address 223 and the next-hop L2ADDR as the outer IPv4 destination address. The 224 node sets the DF flag in the outer IPv4 header according to Section 225 3.2 of [RFC4213]. The node also sets the IP protocol field in the 226 outer IPv4 header to 4 (i.e., ip-protocol-4). 228 The node then submits the encapsulated packet to the IPv4 layer. The 229 IPv4 layer fragments the packet if necessary, then forwards each 230 fragment to the underlying IPv4 interface. The underlying IPv4 231 interface then performs address resolution on the outer IPv4 232 destination address (i.e., the next-hop L2ADDR) and submits the 233 packet for transmission on the underlying link layer. 235 6.6. IPv4 Multicast Mapping 237 In many aspects, ISATAP is simply a unicast-only derivative of 238 "6over4" [RFC2529]. For various reasons, however, ISATAP has seen 239 practical wide-scale deployment while the 6over4 approach has been 240 silently carried forward through ongoing research efforts. This 241 specification extends the ISATAP interface model to support IPv4 242 multicast mapping in a manner that exactly parallels IPv6 multicast 243 mapping in 6over4 (see: [RFC2529], Section 6). Indeed, the approach 244 might more aptly be named as "4over4" were it not for the fact that 245 the name "ISATAP" has already become ingrained in the widely 246 published terminology. 248 IPv4 multicast mapping is available only on ISATAP interfaces 249 configured over sites that support IPv4 multicast. For such sites, 250 an IPv4 packet sent on an ISATAP interface with a multicast 251 destination address DST MUST be encapsulated for transmission on an 252 underlying IPv4 interface to the IPv4 multicast address of 253 Organization-Local Scope using the mapping below. The mapped address 254 SHOULD be taken from the block 239.193.0.0/16, a different sub-block 255 of the Organization-Local Scope address block, or, if all of those 256 are not available, from the expansion blocks defined in [RFC2365]. 257 Note that when they are formed using the expansion blocks, they use 258 only a /16 sized block. 260 +-------+-------+-------+-------+ 261 | 239 | OLS | DST2 | DST3 | 262 +-------+-------+-------+-------+ 264 DST2, DST3 last two bytes of IPv4 multicast address. 266 OLS from the configured Organization-Local 267 Scope address block. SHOULD be 193, 268 see [RFC2365] for details. 270 Figure 1: ISATAPv4 Multicast Mapping 272 No new IANA registration procedures are required for the above. 274 6.7. Recursive Encapsulation Avoidance 276 The node must take care in managing its IPv4 FIB table entries in 277 order to avoid looping through recursive encapsulations. 279 7. IANA Considerations 281 There are no IANA considerations for this document. 283 8. Security Considerations 285 The security considerations specified in [RFC2003] apply equally to 286 this document. The security considerations specified in ISATAP 287 [RFC5214] and 6over4 [RFC2529] also apply, with the exception that 288 ip-protocol-4 encapsulation is used instead of ip-protocol-41. 290 Updated tunnel security considerations are found in 291 [I-D.ietf-v6ops-tunnel-security-concerns]. 293 9. Acknowledgements 295 This work extends the ISATAP interface model, which has evolved 296 through the insights of many contributers over the course of many 297 decades. 299 10. References 300 10.1. Normative References 302 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 303 September 1981. 305 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 306 RFC 792, September 1981. 308 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 309 November 1990. 311 [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, 312 October 1996. 314 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 315 Requirement Levels", BCP 14, RFC 2119, March 1997. 317 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 318 (IPv6) Specification", RFC 2460, December 1998. 320 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 321 Domains without Explicit Tunnels", RFC 2529, March 1999. 323 [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic 324 Configuration of IPv4 Link-Local Addresses", RFC 3927, 325 May 2005. 327 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 328 for IPv6 Hosts and Routers", RFC 4213, October 2005. 330 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 331 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 332 March 2008. 334 10.2. Informative References 336 [I-D.ietf-v6ops-tunnel-security-concerns] 337 Hoagland, J., Krishnan, S., and D. Thaler, "Security 338 Concerns With IP Tunneling", 339 draft-ietf-v6ops-tunnel-security-concerns-01 (work in 340 progress), October 2008. 342 [I-D.templin-autoconf-dhcp] 343 Templin, F., "Virtual Enterprise Traversal (VET)", 344 draft-templin-autoconf-dhcp-37 (work in progress), 345 March 2009. 347 [I-D.templin-ranger] 348 Templin, F., "Routing and Addressing in Next-Generation 349 EnteRprises (RANGER)", draft-templin-ranger-07 (work in 350 progress), February 2009. 352 [RFC1035] Mockapetris, P., "Domain names - implementation and 353 specification", STD 13, RFC 1035, November 1987. 355 [RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, 356 RFC 2365, July 1998. 358 Appendix A. Encapsulation Avoidance 360 In some instances, an ISATAP interface may be configured over a site 361 in which all single-hop ISATAP neighbors are also known to be single- 362 hop neighbors in the underlying site. In that case alone, if the 363 next-hop L3ADDR and next-hop L2ADDR are both routable within the 364 underlying site the ISATAP interface MAY avoid encapsulation and 365 submit the unencapsulated packets directly to the IPv4 layer while 366 using the next-hop L2ADDR (i.e., and not the next-hop L3ADDR) as the 367 next hop. 369 Author's Address 371 Fred L. Templin (editor) 372 Boeing Research & Technology 373 P.O. Box 3707 MC 7L-49 374 Seattle, WA 98124 375 USA 377 Email: fltemplin@acm.org