idnits 2.17.1 draft-smith-v6ops-larger-ipv6-loopback-prefix-03.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 3 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 2 instances 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. -- The draft header indicates that this document updates RFC6724, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC6303, 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 (February 11, 2013) is 4089 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-IPV6REG' -- 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 (==), 9 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,6303,6724 February 11, 2013 5 (if approved) 6 Intended status: Standards Track 7 Expires: August 15, 2013 9 A Larger Loopback Prefix for IPv6 10 draft-smith-v6ops-larger-ipv6-loopback-prefix-03 12 Abstract 14 During the development and testing of a network application, it can 15 be useful to run multiple instances of the application using the same 16 transport layer protocol port on the same development host, while 17 also having network access to the application instances limited to 18 the local host. Under IPv4, this has been possible by using 19 different loopback addresses within 127/8. It is not possible under 20 IPv6, as the loopback prefix of ::1/128 only provides a single 21 loopback address. This memo proposes a new larger loopback prefix 22 that will provide many IPv6 loopback addresses. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on August 15, 2013. 41 Copyright Notice 43 Copyright (c) 2013 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 60 2. Larger Loopback Prefix Requirements . . . . . . . . . . . . . 4 61 3. Proposed Larger Loopback Prefix . . . . . . . . . . . . . . . 4 62 4. Address Assignment and Configuration . . . . . . . . . . . . . 5 63 5. Larger Loopback Prefix Processing Rules . . . . . . . . . . . 6 64 5.1. Host Rules . . . . . . . . . . . . . . . . . . . . . . . . 6 65 5.1.1. Packets Originated with Larger Loopback Source 66 and/or Destination Addresses . . . . . . . . . . . . . 6 67 5.1.2. Packets Received Externally With Larger Loopback 68 Source and/or Destination Addresses . . . . . . . . . 7 69 5.2. Router Rules . . . . . . . . . . . . . . . . . . . . . . . 7 70 5.2.1. Packets Originated with Larger Loopback Source 71 and/or Destination Addresses . . . . . . . . . . . . . 8 72 5.2.2. Packets Received Externally With Larger Loopback 73 Source and/or Destination Addresses . . . . . . . . . 8 74 6. Default Address Selection . . . . . . . . . . . . . . . . . . 8 75 7. DNS Considerations . . . . . . . . . . . . . . . . . . . . . . 9 76 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 77 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 78 10. Security Considerations . . . . . . . . . . . . . . . . . . . 9 79 11. Change Log [RFC Editor please remove] . . . . . . . . . . . . 10 80 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 81 12.1. Normative References . . . . . . . . . . . . . . . . . . . 11 82 12.2. Informative References . . . . . . . . . . . . . . . . . . 11 83 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 85 1. Introduction 87 During the development and testing of a network application, it can 88 be useful to run multiple instances of the application on the same 89 development host. It may also be useful or important for network 90 access to these application instances to be limited to only the 91 development host itself. 93 Networked applications that use fixed and usually well known 94 transport layer protocol ports will typically accept incoming traffic 95 on that port for any address assigned to the host. This will prevent 96 multiple instances of the application running on the same port. This 97 port reuse limitation can be overcome by having each application 98 instance bind to different individual addresses available on the 99 host. 101 Under IPv4, the 127/8 loopback prefix [RFC1122] provides many 102 addresses that can be used to run multiple instances of an 103 application on the same port, while also limiting access to the local 104 host. 106 Under IPv6, the ::1/128 loopback prefix [RFC4291] only provides a 107 single address. Multiple application instances using the same port, 108 bound to different loopback addresses, is not possible. 110 The IPv4-Mapped IPv6 Address form of 127/8, ::ffff:127.0.0.0/104 111 [RFC4291], could be used to provide more host local loopback 112 addresses. However these addresses do not have native IPv6 address 113 properties. For example, they cannot accomodate 64 bit Interface 114 Identifiers. Other current and future IPv6 address forms that 115 contain IPv4 addresses or prefixes, such as IPv4-Embedded IPv6 116 Addresses [RFC6052], have or are likely to have similar or other 117 drawbacks. 119 A Unique Local IPv6 Unicast Address (ULA) prefix [RFC4193] could be 120 used to increase the number of addresses available on the local host. 121 However this prefix would need to be manually generated and 122 configured at least once by a system administrator or operator. 123 Without additonal configuration, traffic towards addresses not 124 assigned to the local host would not be prevented from leaving the 125 host, and access may not be limited to the local host. A ULA prefix 126 would not be well known, and would not be convenient to remember and 127 type without violating the randomness requirements of the Global ID 128 component of a ULA prefix. 130 This memo proposes a new larger IPv6 loopback prefix that provides 131 many more loopback addresses, has properties of native IPv6 132 addresses, and is easy to remember and type. Unlike ::1/128, the 133 processing rules for this prefix match those of IPv4's 127/8. These 134 rules allow sending or forwarding of packets with loopback addresses 135 beyond the originating host under certain circumstances. 137 This memo, if published, updates [RFC4291], [RFC5156], [RFC6303] and 138 [RFC6724]. 140 1.1. Requirements Language 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 144 document are to be interpreted as described in RFC 2119 [RFC2119]. 146 2. Larger Loopback Prefix Requirements 148 A new larger loopback prefix should attempt to satisfy all of the 149 following requirements. It should: 151 o be a well known prefix, 153 o be within an existing special purpose prefix, such as 0000::/8 154 (the parent prefix of the current IPv6 loopback address), 156 o be easy for a human to remember, 158 o be easy for a human to type, 160 o cover the existing loopback prefix, 162 o support 64 bit Interface Identifiers, 164 o provide a large number of /64 subnets. 166 3. Proposed Larger Loopback Prefix 168 Ideally, the prefix length of ::1/128 could be shortened, resulting 169 in a larger loopback prefix such as ::/48. However, if the existing 170 loopback prefix length is shortened enough to satisfy all of the 171 larger loopback prefix requirements, it would then cover the IPv4 172 Mapped IPv6 Address prefix, ::ffff:0.0.0.0/96, and prevent its use 173 described in [RFC4038]. 175 Giving up the requirement of covering the existing loopback prefix, 176 the proposed larger loopback prefix is: 178 0001:0000:0000:0000:0000:0000:0000:0000/32 180 or concisely, 182 1::/32 184 This prefix satisfies all remaining larger loopback prefix 185 requirements. 187 Allocating a /32 prefix for the loopback function may seem excessive, 188 as a /48 length prefix would satisfy the larger loopback prefix 189 requirements. However, within the parent 0000::/8 special purpose 190 prefix, there are approximately 16 million /32 prefixes, so a single 191 /32 for the larger loopback prefix is easily afforded. A /32 larger 192 loopback prefix will satisfy all current and likely future uses of 193 the loopback function. 195 4. Address Assignment and Configuration 197 Consistent with the IPv6 addressing model [RFC4291], each address 198 within the larger loopback prefix is associated with one of the 199 node's interfaces, although not necessarily the same interface for 200 all addresses. This means that the node acts as though all addresses 201 within the larger loopback prefix have been configured on one or more 202 interfaces. Applications will accept packets destined to any of the 203 larger loopback prefix addresses, unless the application is bound to 204 specific larger loopback addresses. Typically the addresses will be 205 logically assigned to one or more virtual "loopback" interfaces, 206 which locally returns or loops outgoing packets back to the same node 207 that originated the packets. 209 It is also common to configure a well known loopback address on the 210 loopback interface during system initialisation, making a loopback 211 address visible to the system operator or user. For IPv4, this 212 address is 127.0.0.1/8; for IPv6, it is ::1/128. For the new larger 213 loopback prefix, the address automatically configured on the loopback 214 interface should be: 216 1::1/64 218 A /64 prefix length has been chosen over /32 to provide a 64 bit 219 Interface Identifier for the loopback interface. This is different 220 from the use of the whole loopback prefix length when configuring 221 127.0.0.1/8 or ::1/128. 223 Some nodes may support more than one loopback interface. These 224 subsequent loopback interfaces, when initialised, should be assigned 225 a larger loopback /64 prefix locally unique within the node. All 226 addresses within the assigned /64 are logically assigned to the 227 interface. Additionally, the ":1" address for the subnet should be 228 configured on the loopback interface, making it visible to a system 229 operator or user. 231 /64 subnet identifier uniqueness could be achieved by using the 232 loopback interface instance number as the subnet identifier, with the 233 first instance numbered 0 to suit the use of 1::1/64 on the first 234 loopback interface. For example, the second loopback interface could 235 be assigned 1:0:0:1::/64, while the forth loopback interface could be 236 assigned 1:0:0:3::/64. Alternatively, the interfaces' ifIndex 237 [RFC1213] could be used to determine these subsequent interfaces' 238 loopback /64 subnet identifier. Other schemes which ensure subnet 239 identifier uniqueness would be acceptable. 241 It should be possible for an operator to remove these automatically 242 configured loopback addresses. It should also be possible for an 243 operator to configure further loopback addresses from within the 244 assigned /64, or addresses from other parts of the larger loopback 245 prefix, including other /64s assigned to other loopback interfaces. 246 Other addresses within the assigned /64(s) would continue to be 247 logically assigned to the subsequent loopback interface. 248 Configuration of addresses is for operational visibility and 249 convenience, and does not change the behaviour of non-visible 250 logically assigned addresses. 252 The larger loopback prefix addresses that are outside of the 253 subsequent loopback interface assigned /64s would continue to be 254 logically assigned to the oldest loopback interface. 256 5. Larger Loopback Prefix Processing Rules 258 5.1. Host Rules 260 5.1.1. Packets Originated with Larger Loopback Source and/or 261 Destination Addresses 263 Packets originated with larger loopback source and/or destination 264 addresses MUST be returned to the origin host for standard processing 265 by the local IPv6 protocol implementation. They MUST NOT be sent 266 over any external links attached to the host. 268 If the implementation supports multiple loopback interfaces, and they 269 have been assigned prefixes and addresses from within the larger 270 loopback prefix, the egress loopback interface SHOULD be the 271 interface assigned the matching destination loopback address. The 272 ingress loopback interface MUST be the interface assigned the 273 matching destination loopback address. This will facilitate loopback 274 interface specific handling of the looped traffic, such as traffic 275 filtering or traffic conditioning, which may be useful during network 276 application development. Note that standard IPv6 longest match 277 packet forwarding will facilitate this multiple loopback interface 278 processing. 280 All addresses within the larger loopback prefix MUST always be 281 considered assigned to one of the host's interfaces, consistent with 282 IPv6's addressing model [RFC4291]. Ingress packets, once they have 283 passed any interface specific policies, MUST be delivered to the 284 appropriate protocol module (e.g., such as TCP, SCTP, UDP or ICMPv6) 285 interested in packets with the destination larger loopback prefix 286 address for further processing. 288 5.1.2. Packets Received Externally With Larger Loopback Source and/or 289 Destination Addresses 291 Packets with larger loopback source and/or destination addresses 292 received over any of the external links attached to the host MUST be 293 dropped. ICMPv6 error messages, such as Destination Unreachable 294 messages, MUST NOT be generated for these dropped packets. 296 Implementation suggestion: For these dropped packets, it may be 297 useful to generate an appropriate system log message, indicating a 298 packet with an invalid source or destination address (a "martian" 299 [RFC1812]) was received over an external interface. By default, 300 these messages should be suppressed. If they are enabled, they 301 should be appropriately rate limited to prevent a system log 302 denial-of-service attack. 304 5.2. Router Rules 306 IPv4 loopback packet processing rules for routers, specified in 307 [RFC1812], by default prohibited forwarding of packets with 127/8 308 destinations, other than those originated locally and returned back 309 to the router itself. A software switch could be provided to disable 310 this prohibition. This special case of allowing forwarding of 311 packets towards 127/8 destinations has been taken advantage of by 312 [RFC4379], for MPLS troubleshooting purposes. An equivalent function 313 for IPv6 is provided by using the IPv4-Mapped IPv6 prefix of ::ffff: 314 127.0.0.0/104. 316 The existing ::1/128 packet processing rules for routers are the same 317 as those for IPv6 hosts [RFC4291]. 319 For the new larger loopback prefix, the IPv6 router processing rules 320 are changed to match those of IPv4, to suit future uses similar to 321 the MPLS troubleshooting case. 323 5.2.1. Packets Originated with Larger Loopback Source and/or 324 Destination Addresses 326 By default, a router MUST follow the host processing rules, described 327 previously, for packets originated with larger loopback source and/or 328 destination addresses. 330 A software switch may be provided to permit packets with larger 331 loopback source and/or destination addresses to be sent via an 332 external interface. If provided, this software switch MUST default 333 to being switched off. 335 5.2.2. Packets Received Externally With Larger Loopback Source and/or 336 Destination Addresses 338 By default, a router MUST follow the host processing rules, described 339 previously, for packets received externally with larger loopback 340 source and/or destination addresses. 342 A software switch may be provided to permit received packets with 343 larger loopback source and/or destination addresses to be forwarded 344 via an external interface. This software switch MUST default to 345 being switched off. 347 6. Default Address Selection 349 For the purposes of default address selection [RFC6724], as with 350 ::1/128, addresses within the larger loopback prefix MUST be treated 351 as having link-local scope, and must have a "preferred" configuration 352 status. 354 Within the address selection default policy table, the larger 355 loopback prefix is to be assigned a precedence value of 60. As the 356 existing ::1/128 loopback address has a precedence value of 50, given 357 a choice, a larger loopback prefix address will be chosen as a 358 destination address over ::1/128. 360 Within the address selection default policy table, the larger 361 loopback prefix is to be assigned a label value of 14, for use during 362 source address selection. 364 These default address selection changes should be enabled at the same 365 time that the larger loopback prefix and corresponding processing 366 rules are enabled on a node. 368 7. DNS Considerations 370 The DNS zone for 1::/32, 0.0.0.0.1.0.0.0.IP6.ARPA, SHOULD be served 371 locally. [RFC6303] provides further discussion regarding local 372 serving of DNS zones for non-global IP address spaces. 374 8. Acknowledgements 376 Nick Hilliard provided valuable review, comments and advice on this 377 memo. 379 Review and comments were provided by, in alphabetical order, Bill 380 Atwood, Brian Carpenter, Roland Chan, Chris Chaundy, Chris Donovan, 381 Matts Kallioniemi, Erik Kline and Tina Tsou. Thanks to Bill for 382 persisting with advice on grammar errors. 384 This memo was prepared using the xml2rfc tool. 386 9. IANA Considerations 388 IANA is requested to allocate 0001::/32 from within 0000::/8 of the 389 Internet Protocol Version 6 Address Space, for use as a larger 390 loopback prefix for IPv6, as detailed in this memo, and to record it 391 in the [IANA-IPV6REG]. 393 10. Security Considerations 395 During deployment of a new larger loopback prefix, there will be a 396 transition period where some hosts and routers have implemented the 397 larger loopback processing rules defined in this memo while others 398 haven't. These legacy hosts and routers will forward larger loopback 399 prefix traffic using conventional unicast processing. For traffic 400 towards non-local larger loopback addresses, traffic will most likely 401 leave the legacy originating host via its default route, and may be 402 forwarded by legacy routers using their default route. This may 403 unintentionally disclose sensitive information. 405 Packet filters, matching traffic with larger loopback source and/or 406 destination addresses, should be used to prevent unintended 407 forwarding of loopback traffic. They should be deployed at the 408 following locations: 410 o on the legacy hosts themselves, 411 o on legacy routers interconnecting different networks, such as on a 412 router interconnecting a private network and the Internet, 414 o on appropriate security domain boundary legacy routers within the 415 local network, if not all legacy routers within the local network. 417 Routes for the new larger loopback prefix should not be announced or 418 accepted if received, unless necessary for special cases where 419 packets with larger loopback prefix addresses are allowed to be 420 forwarded. 422 11. Change Log [RFC Editor please remove] 424 draft-smith-larger-ipv6-loopback-prefix-00, initial version, 425 2012-07-24 427 draft-smith-larger-ipv6-loopback-prefix-01, much less verbose 428 version, 2012-08-17 430 draft-smith-larger-ipv6-loopback-prefix-02, clarifications, 431 2013-01-07 433 o clarification that the larger loopback prefix should fall within 434 ::/8, the parent prefix of ::/128 and ::1/128 436 o Change from 1::/48 to 1::/32 438 o text about logically assigning addresses to interface(s), as per 439 IPv6 addressing model 441 o automatic loopback address configuration to multiple loopback 442 interfaces 444 o local serving of 0.0.0.1.0.0.0.IP6.ARPA zone in DNS 446 draft-smith-larger-ipv6-loopback-prefix-03, clarifications, 447 2013-02-07 449 o default address selection precedence and label values 451 o comment about other IPv4 in IPv6 address forms 453 o more clarifications 455 o grammar corrections 457 12. References 459 12.1. Normative References 461 [IANA-IPV6REG] 462 Internet Assigned Numbers Authority, "IPv6 Special Purpose 463 Address Registry", 2013, . 466 [RFC1122] Braden, R., "Requirements for Internet Hosts - 467 Communication Layers", STD 3, RFC 1122, October 1989. 469 [RFC1213] McCloghrie, K. and M. Rose, "Management Information Base 470 for Network Management of TCP/IP-based internets:MIB-II", 471 STD 17, RFC 1213, March 1991. 473 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 474 Requirement Levels", BCP 14, RFC 2119, March 1997. 476 12.2. Informative References 478 [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", 479 RFC 1812, June 1995. 481 [RFC4038] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E. 482 Castro, "Application Aspects of IPv6 Transition", 483 RFC 4038, March 2005. 485 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 486 Addresses", RFC 4193, October 2005. 488 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 489 Architecture", RFC 4291, February 2006. 491 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 492 Label Switched (MPLS) Data Plane Failures", RFC 4379, 493 February 2006. 495 [RFC5156] Blanchet, M., "Special-Use IPv6 Addresses", RFC 5156, 496 April 2008. 498 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 499 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 500 October 2010. 502 [RFC6303] Andrews, M., "Locally Served DNS Zones", BCP 163, 503 RFC 6303, July 2011. 505 [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, 506 "Default Address Selection for Internet Protocol Version 6 507 (IPv6)", RFC 6724, September 2012. 509 Author's Address 511 Mark Smith 512 In My Own Time 513 PO BOX 521 514 HEIDELBERG, VIC 3084 515 AU 517 Email: markzzzsmith@yahoo.com.au