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