idnits 2.17.1 draft-smith-v6ops-larger-ipv6-loopback-prefix-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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. -- The draft header indicates that this document updates RFC4291, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC5156, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4291, updated by this document, for RFC5378 checks: 2003-10-10) -- 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 (August 17, 2012) is 4270 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) -- Obsolete informational reference (is this intentional?): RFC 4379 (Obsoleted by RFC 8029) -- Obsolete informational reference (is this intentional?): RFC 5156 (Obsoleted by RFC 6890) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force M. Smith 3 Internet-Draft IMOT 4 Updates: 4291,5156 (if approved) August 17, 2012 5 Intended status: Standards Track 6 Expires: February 18, 2013 8 A Larger Loopback Prefix for IPv6 9 draft-smith-v6ops-larger-ipv6-loopback-prefix-01 11 Abstract 13 During the development of a network application, it can be useful to 14 run multiple instances of the application using the same transport 15 layer protocol port on the same development host, while also having 16 network access to the application instances limited to the local 17 host. Under IPv4, this has been possible by using different loopback 18 addresses within 127/8. It is not possible under IPv6, as the 19 loopback prefix of ::1/128 only provides a single loopback address. 20 This memo proposes a new larger loopback prefix that will provide 21 many loopback IPv6 addresses. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on February 18, 2013. 40 Copyright Notice 42 Copyright (c) 2012 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 4 59 2. Larger Loopback Prefix Requirements . . . . . . . . . . . . . . 4 60 3. Proposed Larger Loopback Prefix . . . . . . . . . . . . . . . . 4 61 4. Larger Loopback Prefix Processing Rules . . . . . . . . . . . . 5 62 4.1. Host Rules . . . . . . . . . . . . . . . . . . . . . . . . 5 63 4.1.1. Packets Sent with Larger Loopback Source and/or 64 Destination Addresses . . . . . . . . . . . . . . . . . 5 65 4.1.2. Packets Received Externally With Larger Loopback 66 Source and/or Destination Addresses . . . . . . . . . . 5 67 4.2. Router Rules . . . . . . . . . . . . . . . . . . . . . . . 5 68 4.2.1. Packets Sent with Larger Loopback Source and/or 69 Destination Addresses . . . . . . . . . . . . . . . . . 6 70 4.2.2. Packets Received Externally With Larger Loopback 71 Source and/or Destination Addresses . . . . . . . . . . 6 72 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 73 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 74 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 75 8. Change Log [RFC Editor please remove] . . . . . . . . . . . . . 7 76 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 77 9.1. Normative References . . . . . . . . . . . . . . . . . . . 7 78 9.2. Informative References . . . . . . . . . . . . . . . . . . 7 79 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 81 1. Introduction 83 During the development of a network application, it can be useful to 84 run multiple instances of the application on the same development 85 host. It may also be useful or important for network access to these 86 application instances to be limited to the development host itself. 88 Networked applications that use fixed transport layer protocol ports 89 will typically accept incoming traffic on that port for any address 90 assigned to the host. This will prevent multiple instances of the 91 application running on the same port. This port reuse limitation can 92 be overcome by having each application instance bind to different 93 individual addresses available on the host. 95 Under IPv4, the 127/8 loopback prefix [RFC1122] provides many 96 addresses that can be used to run multiple instances of an 97 application on the same port, while also limiting access to the local 98 host. 100 Under IPv6, the ::1/128 loopback prefix [RFC4291] only provides a 101 single address. Multiple application instances using the the same 102 port, bound to different loopback addresses, is not possible. 104 The IPv4-Mapped IPv6 Address form of 127/8, ::ffff:127.0.0.0/104 105 [RFC4291], could be used to provide more host local loopback 106 addresses. However these addresses do not have native IPv6 address 107 properties. For example, they cannot accomodate 64 bit Interface 108 Identifiers. 110 A Unique Local IPv6 Unicast Address (ULA) prefix [RFC4193] could be 111 used to increase the number of addresses available on the local host. 112 However this prefix would need to be manually generated and 113 configured at least once by a system administrator. Without 114 additonal configuration, traffic towards most addresses within the 115 prefix would not be prevented from leaving the local host, and access 116 may not be limited to the local host. A ULA prefix would not be well 117 known, and would not be convenient to remember and type without 118 violating the randomness requirements of the Global ID component of a 119 ULA prefix. 121 This memo proposes a new larger IPv6 loopback prefix that provides 122 more loopback addresses and has properties of native IPv6 addresses. 123 This prefix will also suit other uses of multiple loopback addresses 124 that may emerge. 126 This memo, if published, updates [RFC4291] and [RFC5156]. 128 1.1. Requirements Language 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 132 document are to be interpreted as described in RFC 2119 [RFC2119]. 134 2. Larger Loopback Prefix Requirements 136 A new larger loopback prefix should attempt to satisfy all of the 137 following requirements: 139 o be a well known prefix, 141 o be within an existing special purpose prefix, 143 o be easy for a human to remember, 145 o be easy for a human to type, 147 o covers the existing loopback prefix, 149 o supports 64 bit Interface Identifiers, 151 o provides a large number of /64 subnets. 153 3. Proposed Larger Loopback Prefix 155 The proposed larger loopback prefix is: 157 0001:0000:0000:0000:0000:0000:0000:0000/48 159 or concisely, 161 1::/48 163 This prefix meets all but one of the requirements, as it does not 164 cover the existing ::1/128 loopback prefix. It is not possible for a 165 larger loopback prefix with a length of /64 or shorter to cover 166 ::1/128, as this would also cover both the IPv4 Mapped IPv6 Address 167 prefix, ::ffff:0.0.0.0/96, and the deprecated IPv4-Compatible IPv6 168 Address prefix, ::0.0.0.0/96 [RFC4291]. 170 Some IP implementations represent or perform the loopback function 171 using a "loopback" virtual link layer interface. 127.0.0.1/8 is 172 usually configured on this interface at system initialisation, even 173 though all addresses within 127/8 are valid loopback addresses. 175 Similarly, ::1/128 is also usually configured on the loopback 176 interface at system initialisation. 178 For the new larger loopback prefix, the address automatically 179 configured on a loopback interface should be: 181 1::1/64 183 4. Larger Loopback Prefix Processing Rules 185 4.1. Host Rules 187 4.1.1. Packets Sent with Larger Loopback Source and/or Destination 188 Addresses 190 Packets with larger loopback source and/or destination addresses MUST 191 be returned to the originating host for standard processing by the 192 local IPv6 protocol implementation. They MUST NOT be sent over any 193 external links attached to the host. 195 All destinations within the larger loopback prefix MUST be considered 196 assigned to the local host. 198 4.1.2. Packets Received Externally With Larger Loopback Source and/or 199 Destination Addresses 201 Packets with larger loopback source and/or destination addresses 202 received over any of the external links attached to the host MUST be 203 dropped. ICMPv6 error messages, such as Destination Unreachable 204 messages, MUST NOT be generated for these dropped packets. 206 For these dropped packets, it may be useful to generate an 207 appropriate system log message, indicating a packet with an invalid 208 source or destination address (a "martian") was received over an 209 external interface. By default, these messages should be suppressed. 210 If they are enabled, they should be appropriately rate limited to 211 prevent a system log denial-of-service attack. 213 4.2. Router Rules 215 IPv4 loopback packet processing rules for routers, specified in 216 [RFC1812], by default prohibited forwarding of packets with 127/8 217 destinations, other than those originated locally and returned back 218 to the router itself. A software switch could be provided to disable 219 this prohibition. This special case of allowing forwarding of 220 packets towards 127/8 destinations has been taken advantage of by 221 [RFC4379]. An equivalent function for IPv6 is provided by using the 222 IPv4-Mapped IPv6 prefix of ::ffff:127.0.0.0/104. 224 The existing ::1/128 packet processing rules for routers is the same 225 as for IPv6 hosts [RFC4291]. 227 For the new larger loopback prefix, the IPv6 router processing rules 228 are modified to match those of IPv4. 230 4.2.1. Packets Sent with Larger Loopback Source and/or Destination 231 Addresses 233 By default, a router MUST follow the host processing rules, described 234 previously, for packets sent with larger loopback source and/or 235 destination addresses. 237 A software switch may be provided to permit packets with larger 238 loopback source and/or destination addresses to be sent via an 239 external interface. If provided, this software switch MUST default 240 to off. 242 4.2.2. Packets Received Externally With Larger Loopback Source and/or 243 Destination Addresses 245 By default, a router MUST follow the host processing rules, described 246 previously, for packets received externally with larger loopback 247 source and/or destination addresses. 249 A software switch may be provided to permit received packets with 250 larger loopback source and/or destination addresses to be forwarded 251 via an external interface. This software switch MUST default to off. 253 5. Acknowledgements 255 Nick Hilliard provided valuable review and comments on this memo. 257 6. IANA Considerations 259 IANA is requested to allocate 1::/48 from within 0::/8 of the 260 Internet Protocol Version 6 Address Space, for use as a larger 261 loopback prefix for IPv6, as described in this memo. 263 7. Security Considerations 265 During deployment of a new larger loopback prefix, there will be a 266 transition period where some hosts and routers have implemented the 267 larger loopback processing rules defined in this memo while others 268 haven't. These legacy hosts and routers will forward larger loopback 269 traffic using conventional unicast processing. For traffic towards 270 non-local larger loopback addresses, traffic will most likely leave 271 the legacy originating host via it's default route, and may be 272 forwarded by legacy routers using their default route. This may 273 disclose sensitive information, violating security policy. 275 Packet filters, matching traffic with larger loopback source and/or 276 destination addresses, should be used to prevent unintended 277 forwarding of loopback traffic. They should be deployed at the 278 following locations: 280 o on the legacy hosts themselves, 282 o on legacy routers interconnecting two different networks, 284 o on appropriate security domain boundary legacy routers within the 285 local network, if not all legacy routers within the local network. 287 Routes for the new larger loopback prefix should not be announced or 288 accepted if received under any circumstances. 290 8. Change Log [RFC Editor please remove] 292 draft-smith-larger-ipv6-loopback-prefix-00, initial version, 293 2012-07-24 295 draft-smith-larger-ipv6-loopback-prefix-01, much less verbose 296 version, 2012-08-17 298 9. References 300 9.1. Normative References 302 [RFC1122] Braden, R., "Requirements for Internet Hosts - 303 Communication Layers", STD 3, RFC 1122, October 1989. 305 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 306 Requirement Levels", BCP 14, RFC 2119, March 1997. 308 9.2. Informative References 310 [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", 311 RFC 1812, June 1995. 313 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 314 Addresses", RFC 4193, October 2005. 316 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 317 Architecture", RFC 4291, February 2006. 319 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 320 Label Switched (MPLS) Data Plane Failures", RFC 4379, 321 February 2006. 323 [RFC5156] Blanchet, M., "Special-Use IPv6 Addresses", RFC 5156, 324 April 2008. 326 Author's Address 328 Mark Smith 329 In My Own Time 330 PO BOX 521 331 HEIDELBERG, VIC 3084 332 AU 334 Email: markzzzsmith@yahoo.com.au