idnits 2.17.1 draft-denis-behave-v4v6exthdr-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 279 has weird spacing: '... act chg ...' == Line 302 has weird spacing: '...in_addr i4fm6...' == Line 303 has weird spacing: '...in_addr i4fm6...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 09, 2009) is 5527 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-08) exists of draft-ietf-dccp-simul-open-07 ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Behavior Engineering for Hindrance R. Denis-Courmont 3 Avoidance Nokia 4 Internet-Draft March 09, 2009 5 Intended status: Experimental 6 Expires: September 10, 2009 8 IPv6 destination header option for IPv4 translator mapping notification 9 draft-denis-behave-v4v6exthdr-01 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on September 10, 2009. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. 46 Abstract 48 This memo defines a new IPv6 Destination header option to convey the 49 transport mapping information from an IPv4-IPv4 protocol translator 50 to the IPv6 end of a protocol-translated packet flow. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 3. IPv4-IPv6 Translation . . . . . . . . . . . . . . . . . . . . 5 57 3.1. Inserting the flow mapping option . . . . . . . . . . . . 5 58 3.1.1. Usage with connection-oriented protocols . . . . . . . 5 59 3.1.2. Usage with other protocols . . . . . . . . . . . . . . 6 60 3.2. Receiving the flow mapping option . . . . . . . . . . . . 6 61 4. Option format . . . . . . . . . . . . . . . . . . . . . . . . 7 62 5. UNSAF Considerations . . . . . . . . . . . . . . . . . . . . . 8 63 5.1. Exit strategy . . . . . . . . . . . . . . . . . . . . . . 8 64 5.2. Interactions with legacy NATs . . . . . . . . . . . . . . 8 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 66 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 67 8. API Considerations . . . . . . . . . . . . . . . . . . . . . . 11 68 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 69 9.1. Normative References . . . . . . . . . . . . . . . . . . . 12 70 9.2. Informative References . . . . . . . . . . . . . . . . . . 12 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 73 1. Introduction 75 To overcome the shortage of IPv4 addresses within the Internet, 76 Network Address and Port Translators (NATs) have been widely 77 deployed, such that multiple IPv4 nodes can share a single IPv4 78 address. However, that method is known to break certain application 79 protocols, which need to know their own assigned external IP address 80 and/or port number (i.e. the transport address). New solutions are 81 now under consideration which would extend NAT mechanisms such that 82 IPv6 nodes could access the IPv4 Internet. 84 This memo proposes an in-band method for such a IPv6-IPv4 NAT to 85 notify affected IPv6 applications of the IPv4 transport address 86 associated with any of their active communication flows. A new 87 option for the IPv6 Destination extension header, the Translated Flow 88 Mapping option is hereby defined to carry this information. 90 2. Definitions 92 TBD. 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 96 document are to be interpreted as described in [RFC2119]. 98 3. IPv4-IPv6 Translation 100 An IPv4-IPv6 NAT performs two separate functions: 102 o It receives IPv4 packets on its IPv4 interface, translates them to 103 IPv6. To that end, for each IPv4 packet, it crafts a new IPv6 104 header to replace the IPv4 header, may modify the inner transport 105 protocol header. Then, it sends the resulting translated IPv6 106 packets through its IPv6 interface. 108 o Reciprocally, it translates IPv6 packets into IPv4 packets. 110 The details of IPv4-IPv6 translation are beyond the scope of this 111 document, please refer to [whatever IETF ends up specifying for this] 112 instead. 114 3.1. Inserting the flow mapping option 116 When a translator receives an IPv4 packet, following certain 117 conditions, it inserts an IPv6 Destination extension header 118 containing a Translated Flow Mapping option (as defined in the next 119 section). 121 As a general rule, this option MUST NOT be inserted, if the resulting 122 packet would exceed the known MTU to the IPv6 destination, or 1280 123 bytes if there is no known MTU. 125 3.1.1. Usage with connection-oriented protocols 127 For connection-oriented transport protocols, this option SHOULD be 128 inserted is part of the protocol handshake, and SHOULD NOT be 129 inserted otherwise. 131 3.1.1.1. Datagram Congestion Control Protocol (DCCP) 133 This option SHOULD be inserted within DCCP Sync, DCCP Sync/Ack and 134 DCCP Listen packets. See [RFC4340] and [I-D.ietf-dccp-simul-open]. 136 3.1.1.2. Stream Control Transmission Protocol (SCTP) 138 TBD. 140 3.1.1.3. Transmission Control Protocol (TCP) 142 This option SHOULD be inserted within TCP SYN and TCP SYN/ACK 143 packets. See [RFC0793]. 145 3.1.2. Usage with other protocols 147 So long as a translated packet is small enough (with regards to the 148 MTU rule above), and uses a non-connection-oriented (including UDP 149 and UDP-Lite) or unknown transport protocol, the translator MAY 150 insert the option. If it is known that the packet is one of the 151 first 10 (FIXME: is this OK?) packets translated in the same 152 direction for the corresponding mapping, then the translator SHOULD 153 insert the option. 155 3.2. Receiving the flow mapping option 157 Processing of the flow mapping option is optional. In fact, an IPv6 158 implementation that does not support the flow mapping option MUST 159 ignore it, according to [RFC2460] (this is not a new requirement for 160 IPv6 implementation). 162 The content of the flow mapping option is merely informational. 163 Hence, there are no particular requirements as regards its 164 processing. An IPv6 stack that implements the flow mapping option 165 MAY store and or forward the flow mapping informations, as it sees 166 fit. For instance, it might forward the informations to the 167 application (see below for an example API) if it requests them. 169 4. Option format 171 0 1 2 3 172 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 | Option Type | Option Length | Mapped Port | 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 | Mapped IPv4 Address | 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 | Remote IPv4 Address | 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 Translated Flow Mapping option 183 The Translated Flow Mapping option format is defined as follow: 185 Option Type: XXX (TBD: IANA) 187 Option Length: 10 (10 bytes worth of data) 189 Mapped Port: If the type of the first header that is not an IPv6 190 extension header is DCCP, SCTP, TCP, UDP or UDP-Lite, the 191 transport protocol mapped port number. This is the destination 192 port number found in the original IPv4 packet that was translated 193 into the IPv6 packet containing this option. Otherwise, this must 194 be set to zero by sender, and ignored by receivers. 196 Mapped IPv4 Address: Destination IPv4 address, as found in the 197 origin IPv4 packet before translation. 199 Remote IPv4 Address: Source IPv4 address, as found in the origin 200 IPv4 packet before translation. 202 The Translated Flow Mapping option requires a 4n alignment (as 203 defined per [RFC2460] section 4.2). In particular, if it is the only 204 non-padding option in an IPv6 extension header, it will be preceded 205 by two bytes of padding. That is normally achieved through a single 206 PadN option with a zero-length payload. 208 5. UNSAF Considerations 210 The Translated Flow Mapping option can be inserted by translators and 211 received by IPv6 nodes. 213 5.1. Exit strategy 215 It is expected that any applicable translation mechanism will define 216 its own UNSAF Considerations, at least as regards the translators. 217 Those should be referred to when it comes to inserting the Flow 218 Mapping option. In particular, such a specification shall narrow 219 down the scope of the translation scheme, define an exit strategy and 220 longer term solutions (e.g. complete translation-free native IPv6 221 networking). See [RFC3424] for further references. 223 However, a dedicated exit strategy is required for the IPv6 nodes 224 that would be capable of parsing the Translated Flow Mapping option. 226 When applicable translator deployments are being phased out, parsing 227 the option becomes increasingly irrelevant, as the option will be 228 absent from any received packets. At that point, IPv6 229 implementations can stop recognizing and parsing the option. They 230 can instead return an error to any IPv6 application that would still 231 try to use of the Flow Mapping option. IPv6 applications MUST be 232 prepared to deal with IPv6 implementations that do not support this 233 specification. 235 5.2. Interactions with legacy NATs 237 Legacy NATs do not support this option. This situation can normally 238 be detected by the absence of the Translated Flow Mapping option. 240 Problems may occur if a translator that implements this specification 241 is located behind a legacy NAT. In this case, the Translated Flow 242 Mapping option may contain incorrect informations. This can most 243 often be detected by verifying that the embedded IPv4 address is a 244 globally unique one rather than a private one (as defined by 245 [RFC1918] and [RFC3927]). 247 However, any application using this extension SHOULD be prepared to 248 fail gracefully if incorrect informations are received. Indeed, a 249 legacy NAT could internally use public address space. Or the (non- 250 legacy) translator could be deployed in a closed network using 251 private IPv4 addresses, even in the absence of legacy NATs. 253 6. Security Considerations 255 By maliciously inserting or altering a Translated Flow Mapping option 256 to an IPv6 packet, an attacker could cause manipulate IP and 257 transport addressing informations to be received. 259 This may specifically allow an IPv6 attacker to refer the victim 260 recipient node to an arbitrary IPv4 third party. As usual, IP nodes 261 should not make assumptions to lightly as regard the IP address 262 information they get. This problem is very similar to that of an 263 IPv6 node handling a source-spoofed IPv6 packet, and the same 264 precautions applies. In particular, proper transport or application- 265 layer congestion control mechanisms need to be used, to prevent a 266 distributed denial-of-service attack. Also, in security-sensitive 267 cases, adequate security protocols are needed, such as TLS or IPsec. 269 The Translated Flow Mapping option can also cause a victim recipient 270 to assume an incorrect arbitrary IPv4 self-referral address. TBD: Do 271 we need to fix this? How? 273 7. IANA Considerations 275 The Translated Flow Mapping option requires an IPv6 Option number. 277 IPv6 Option Number [RFC2460]: 279 HEX act chg rest 280 --- --- --- ----- 281 XX 00 0 XXXXX Translated Flow Mapping 283 The first two bits indicate that the IPv6 node may skip over this 284 option and continue processing the header if it doesn't recognize the 285 option type, and the third bit indicates that the Option Data may not 286 change en-route. 288 This document should be listed as the reference document. 290 8. API Considerations 292 This section is non-normative. It defines a potential API to 293 retrieve the flow mapping information as an extension to the Advanced 294 IPv6 socket API [RFC3542]. 296 The flow mapping informations shall be passed to applications using a 297 structure defined in , and containing at least the 298 following fields: 300 struct in6_ipv4flowmapping { 301 struct uint16_t i4fm6_mapped_port; 302 struct in_addr i4fm6_mapped_addr; 303 struct in_addr i4fm6_remote_addr; 304 }; 306 Flow mapping structure 308 For datagram (type SOCK_DGRAM) and raw (type SOCK_RAW) sockets, a 309 socket option can configure receiving the flow information as 310 ancilliary data on a per-packet basis, using recvmsg. This socket 311 option shall be set to 0 (off) by default. Setting it to 1 (on) 312 shall enabled flow mapping infos reception. Setting it to -1 313 (default) shall disable it. When enabled, an ancilliary data with 314 level IPPROTO_IPV6, type IPV6_IPV4FLOWMAPPING shall be returned to 315 the application, if a Flow Mapping option was found in the received 316 packet. 318 int on = 1; 320 setsockopt(fd, IPPROTO_IPV6, IPV6_RECVIPV4FLOWMAPPING, 321 &yes, sizeof(yes)); 323 Per-packet socket option 325 For a connected socket, a read-only socket option may be used to 326 fetch the flow mapping information if known (i.e. if at least one 327 packet with a Flow Mapping Option was received). If unknown, the 328 returned structure shall contain all zeroes. 330 struct in6_ipv4flowmapping val; 332 getsockopt(fd, IPPROTO_IPV6, IPV6_IPV4FLOWMAPPING, 333 &val, sizeof(val)); 335 Connected socket option 337 9. References 339 9.1. Normative References 341 [I-D.ietf-dccp-simul-open] 342 Fairhurst, G., "DCCP Simultaneous-Open Technique to 343 Facilitate NAT/Middlebox Traversal", 344 draft-ietf-dccp-simul-open-07 (work in progress), 345 February 2009. 347 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 348 RFC 793, September 1981. 350 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 351 E. Lear, "Address Allocation for Private Internets", 352 BCP 5, RFC 1918, February 1996. 354 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 355 Requirement Levels", BCP 14, RFC 2119, March 1997. 357 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 358 (IPv6) Specification", RFC 2460, December 1998. 360 [RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral 361 Self-Address Fixing (UNSAF) Across Network Address 362 Translation", RFC 3424, November 2002. 364 [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic 365 Configuration of IPv4 Link-Local Addresses", RFC 3927, 366 May 2005. 368 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 369 Congestion Control Protocol (DCCP)", RFC 4340, March 2006. 371 9.2. Informative References 373 [RFC3542] Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei, 374 "Advanced Sockets Application Program Interface (API) for 375 IPv6", RFC 3542, May 2003. 377 Author's Address 379 Remi Denis-Courmont 380 Nokia Corporation 381 P.O. Box 407 382 NOKIA GROUP 00045 383 FI 385 Phone: +358 50 487 6315 386 Email: remi.denis-courmont@nokia.com