idnits 2.17.1 draft-cmetz-v6ops-v4mapped-api-harmful-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 4 longer pages, the longest (page 2) being 59 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 5 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 20 characters in excess of 72. ** The abstract seems to contain references ([Gilligan,2003], [Hinden,2003]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 133: '...sockets MUST correctly handle receptio...' RFC 2119 keyword, line 163: '...t option off, it MUST correctly handle...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (Oct 21, 2003) is 7493 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'Hinden' on line 35 looks like a reference -- Missing reference section? '2003' on line 160 looks like a reference -- Missing reference section? 'Gilligan' on line 160 looks like a reference -- Missing reference section? 'Metz' on line 200 looks like a reference -- Missing reference section? '2000' on line 200 looks like a reference Summary: 10 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Craig Metz 3 INTERNET-DRAFT Extreme Networks 4 Expires: Apr 21, 2004 Jun-ichiro itojun Hagino 5 Research Lab, IIJ 6 Oct 21, 2003 8 IPv4-Mapped Address API Considered Harmful 9 draft-cmetz-v6ops-v4mapped-api-harmful-01.txt 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with all 14 provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering Task 17 Force (IETF), its areas, and its working groups. Note that other groups 18 may also distribute working documents as Internet-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 material 23 or to cite them other than as ``work in progress.'' 25 To view the list Internet-Draft Shadow Directories, see 26 http://www.ietf.org/shadow.html. 28 Distribution of this memo is unlimited. 30 The internet-draft will expire in 6 months. The date of expiration will 31 be Apr 21, 2004. 33 Abstract 35 The IPv6 Addressing Architecture [Hinden, 2003] defines the "IPv4-mapped 36 IPv6 address." This representation is used in the IPv6 basic API 37 [Gilligan, 2003] to denote IPv4 addresses using AF_INET6 sockets. The 38 use of IPv4-mapped addresses on AF_INET6 sockets degrades portability, 39 complicates IPv6 systems, and is likely to create security problems. 40 This document discusses each issue in turn. Finally, it proposes to 41 resolve these problems by recommending deprecation of this mechanism. 43 1. Drawbacks due to IPv4 mapped address support 45 ^L 47 DRAFT IPv4-mapped Addr. API Considered Harmful Oct 2003 49 1.1. Degraded portability 51 RFC3493 section 3.7 specifies the behavior of IPv4-mapped addresses with 52 an AF_INET6 socket. However, the description fails to specify important 53 details that are necessary for good portability. Specifically, the 54 specification needs to define: 56 (1) The interaction between multiple bind(2) attempts to the same port, 57 with different addresses. What happens when an application does and 58 does not call setsockopt(..., SO_REUSEPORT, ...) in order to bind(2) 59 to the same port on AF_INET and AF_INET6? What happens when an 60 application calls bind(2) on AF_INET socket, and an application 61 calls bind(2) on an AF_INET6 socket with IPv4-mapped address? Note 62 that there are many more issues here that need specification. 64 (2) The selection/interaction of port numbers between AF_INET and 65 AF_INET6 sockets on bind(2) and/or connect(2) system calls. This is 66 related to (1). 68 (3) The treatment of socket options (setsockopt(2) and getsockopt(2)) 69 with IPv4-mapped addresses on AF_INET6 sockets. What happens when 70 an application calls setsockopt(2) for IPv4 options or IPv6 options 71 on an AF_INET6 socket that is not yet bound (and, therefore, the 72 host does not know if IPv4 or IPv6 communication will be used)? 73 What happens when an application calls setsockopt(2) for IPv4 74 options or IPv6 options on an AF_INET6 socket that is bound to 75 IPv4-mapped addresses? 77 (4) The delivery of multicast packets to AF_INET and AF_INET6 sockets. 78 What happens when an application binds to the IPv6 unspecified 79 address (::) with a certain port -- does it receive IPv4 multicast 80 traffic as well? What will be the relationship between 81 IP_MULTICAST_IF and IPV6_MULTICAST_IF socket options? What happens 82 when an application calls sendto(2) to an IPv4-mapped address for an 83 IPv4 multicast address? How will the source address be selected? 85 Due to these ambiguities, developers of applications that use 86 IPv4-mapped addresses on AF_INET6 sockets might encounter portability 87 problems. 89 1.2. Increased implementation complexity 91 Implementation of IPv4-mapped addresses has a real and significant cost, 92 both in the system software (e.g., network stack, kernel, and system 93 libraries) and in the application software (ALL of which must now 94 correctly handle IPv4-mapped addresses). The combined man-time for 95 developers, testers, document writers, and support staff is a real and 96 potentially tangible added cost of this particular feature. Because 97 applications are affected, the number of implementations for which this 98 cost will apply has the potential to be huge. 100 ^L 102 DRAFT IPv4-mapped Addr. API Considered Harmful Oct 2003 104 Implementation of IPv4-mapped addresses increases the complexity of all 105 IPv6 implementations, both in the system software and in the application 106 software. Increased complexity is bad for software engineering reasons 107 beyond the scope of this document. Technology market forces and 108 Internet history have demonstrated that simpler protocols and simpler 109 systems have a tendency to be more successful than complex alternatives. 111 If the community wishes to see IPv6 achieve successful deployment, it is 112 important that the resource costs and complexity costs associated with 113 IPv6 be as low as possible. Where opportunities exist to decrease these 114 costs, the community should seriously consider doing so in order to 115 nurture deployment. 117 1.3. Access control complexity 119 RFC3493 section 3.7 adds extra complexity to address-based access 120 controls. It is likely that there will be many errors introduced by of 121 this. 123 Due to RFC3493 section 3.7, AF_INET6 sockets will accept IPv4 packets. 124 On an IPv4/v6 dual stack node, if there is no AF_INET listening socket, 125 most users would believe that there will be no access from IPv4 peers. 126 However, if an AF_INET6 listening socket is present, IPv4 peers will be 127 able to access the service. This is likely to confuse users and result 128 in configuration errors that can be exploited by malicious parties. (It 129 is violating the security principle of least surprise) 131 AF_INET6 sockets will accept IPv4 packets even (and especially) if the 132 application is not expecting them. Every application that uses AF_INET6 133 sockets MUST correctly handle reception of IPv4 packets. Failure of a 134 developer to consider every relevant case might lead to a security 135 problem. This is likely to be overlooked by developers -- especially 136 those new to IPv6 development (as most are). This is likely to result 137 in applications with flaws that can be exploited by malicious parties. 138 (Again, this is violating the security principle of least surprise) 140 Systems that support IPv4 communications on AF_INET6 sockets using 141 IPv4-mapped addresses have a greater potential to have security problems 142 than they would if they did not have this feature. 144 2. Recommended solution (standard-wise) 146 o Deprecate RFC3493 section 3.7. By doing so, IPv6 implementations will 147 be greatly simplified, both in the system software and in all IPv6 148 application software. 150 3. Alternative solution (standard-wise) 152 o Expand RFC3493 section 3.7 to fully define the behavior of AF_INET6 153 sockets using IPv4-mapped addresses. 155 ^L 157 DRAFT IPv4-mapped Addr. API Considered Harmful Oct 2003 159 o Change the default value for IPV6_V6ONLY socket option defined in 160 [Gilligan, 2003] to "on." With this approach, systems must still 161 implement the complex interactions between AF_INET and AF_INET6 162 socket, which can lead to security problems. Also, once a application 163 turns the socket option off, it MUST correctly handle all cases where 164 an IPv4-mapped address might be used or it may have security problems. 166 4. Implementation tips to application developers 168 o In EVERY application, check for IPv4-mapped addresses wherever 169 addresses enter code paths under your control (i.e., are returned from 170 system calls, or from library calls, or are input from the user or a 171 file), and handle them in an appropriate manner. This approach is 172 difficult in reality, and there is no way to determine whether it has 173 been followed fully. 175 o Do not intentionally use RFC3493 section 3.7 (IPv4 traffic on AF_INET6 176 socket). Implement server applications by using separate AF_INET and 177 AF_INET6 listening sockets. Explicitly set the IPV6_V6ONLY socket 178 option to on, whenever the socket option is available on the system. 180 NOTE: Due to the lack of standard behavior in bind(2) semantics, 181 this may not be possible on some systems. Some IPv6 stack does not 182 permit bind(2) to 0.0.0.0, after bind(2) to ::. Also, there is no 183 standard on how IPv4 traffic will be routed when both 0.0.0.0 and 184 :: listening sockets are available on the same port. 186 NOTE: The deployment of IPV6_V6ONLY socket option is still low, not 187 many systems support it yet. 189 o Implement programs in a protocol-independent manner using 190 getaddrinfo(3) and getnameinfo(3), instead of hard-coding AF_INET6. 191 RFC3493 section 3.7 leads people to port IPv4 application to IPv6 by 192 replacing AF_INET into AF_INET6. However, by hard-coding AF_INET6 193 into the program, developers are failing to correct their dependencies 194 on particular protocol families. As a consequence, any future 195 protocol support will again require the application to be modified. 196 Applications that hard-code AF_INET6 require IPv6-capable systems and 197 will fail on a system that only has IPv4 support. It is critical to 198 implement programs in a protocol-independent manner if you want to 199 ship a single program (binary/source) that runs on IPv4-only, 200 IPv6-only, as well as IPv4/v6 dual stack systems [Metz, 2000] . 202 5. Security considerations 204 This document discusses security issues with the use of IPv4-mapped 205 address. A recommended and alternate solution is provided. 207 ^L 209 DRAFT IPv4-mapped Addr. API Considered Harmful Oct 2003 211 6. Change History 213 00 -> 01 214 2553bis draft is now RFC3493. Refer RFC3513 instead of RFC2373. 215 Refer Craig's paper. 217 References 219 Hinden, 2003. 220 R. Hinden and S. Deering, "IP Version 6 Addressing Architecture" in 221 RFC3513 (April 2003). ftp://ftp.isi.edu/in-notes/rfc3513.txt. 223 Gilligan, 2003. 224 R. Gilligan, S. Thomson, J. Bound, J. McCann, and W. R. Stevens, "Basic 225 Socket Interface Extensions for IPv6" in RFC3493 (February 2003). 226 ftp://ftp.isi.edu/in-notes/rfc3493.txt. 228 Metz, 2000. 229 Craig Metz, "Protocol Independence Using the Sockets API" in USENIX 230 annual conference, Freenix track (June 2000). 231 http://www.usenix.org/publications/library/proceedings/usenix2000/freenix/metzprotocol.html. 233 Author's address 235 Craig Metz 236 Extreme Networks 237 220 Spring Street, Suite 100 238 Herndon, VA 20170-5209, USA 239 Tel: +1 703 885 6721 240 email: cmetz@inner.net 242 Jun-ichiro itojun Hagino 243 Research Laboratory, Internet Initiative Japan Inc. 244 Takebashi Yasuda Bldg., 245 3-13 Kanda Nishiki-cho, 246 Chiyoda-ku,Tokyo 101-0054, JAPAN 247 Tel: +81-3-5259-6350 248 Fax: +81-3-5259-6351 249 email: itojun@iijlab.net 251 ^L