Internet Engineering Task Force M. Smith Internet-Draft IMOT Updates: 4291,5156,6303,6724 February 11, 2013 (if approved) Intended status: Standards Track Expires: August 15, 2013 A Larger Loopback Prefix for IPv6 draft-smith-v6ops-larger-ipv6-loopback-prefix-03 Abstract During the development and testing of a network application, it can be useful to run multiple instances of the application using the same transport layer protocol port on the same development host, while also having network access to the application instances limited to the local host. Under IPv4, this has been possible by using different loopback addresses within 127/8. It is not possible under IPv6, as the loopback prefix of ::1/128 only provides a single loopback address. This memo proposes a new larger loopback prefix that will provide many IPv6 loopback addresses. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on August 15, 2013. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of Smith Expires August 15, 2013 [Page 1] Internet-Draft A Larger IPv6 Loopback Prefix February 2013 publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 2. Larger Loopback Prefix Requirements . . . . . . . . . . . . . 4 3. Proposed Larger Loopback Prefix . . . . . . . . . . . . . . . 4 4. Address Assignment and Configuration . . . . . . . . . . . . . 5 5. Larger Loopback Prefix Processing Rules . . . . . . . . . . . 6 5.1. Host Rules . . . . . . . . . . . . . . . . . . . . . . . . 6 5.1.1. Packets Originated with Larger Loopback Source and/or Destination Addresses . . . . . . . . . . . . . 6 5.1.2. Packets Received Externally With Larger Loopback Source and/or Destination Addresses . . . . . . . . . 7 5.2. Router Rules . . . . . . . . . . . . . . . . . . . . . . . 7 5.2.1. Packets Originated with Larger Loopback Source and/or Destination Addresses . . . . . . . . . . . . . 8 5.2.2. Packets Received Externally With Larger Loopback Source and/or Destination Addresses . . . . . . . . . 8 6. Default Address Selection . . . . . . . . . . . . . . . . . . 8 7. DNS Considerations . . . . . . . . . . . . . . . . . . . . . . 9 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 10. Security Considerations . . . . . . . . . . . . . . . . . . . 9 11. Change Log [RFC Editor please remove] . . . . . . . . . . . . 10 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 12.1. Normative References . . . . . . . . . . . . . . . . . . . 11 12.2. Informative References . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 Smith Expires August 15, 2013 [Page 2] Internet-Draft A Larger IPv6 Loopback Prefix February 2013 1. Introduction During the development and testing of a network application, it can be useful to run multiple instances of the application on the same development host. It may also be useful or important for network access to these application instances to be limited to only the development host itself. Networked applications that use fixed and usually well known transport layer protocol ports will typically accept incoming traffic on that port for any address assigned to the host. This will prevent multiple instances of the application running on the same port. This port reuse limitation can be overcome by having each application instance bind to different individual addresses available on the host. Under IPv4, the 127/8 loopback prefix [RFC1122] provides many addresses that can be used to run multiple instances of an application on the same port, while also limiting access to the local host. Under IPv6, the ::1/128 loopback prefix [RFC4291] only provides a single address. Multiple application instances using the same port, bound to different loopback addresses, is not possible. The IPv4-Mapped IPv6 Address form of 127/8, ::ffff:127.0.0.0/104 [RFC4291], could be used to provide more host local loopback addresses. However these addresses do not have native IPv6 address properties. For example, they cannot accomodate 64 bit Interface Identifiers. Other current and future IPv6 address forms that contain IPv4 addresses or prefixes, such as IPv4-Embedded IPv6 Addresses [RFC6052], have or are likely to have similar or other drawbacks. A Unique Local IPv6 Unicast Address (ULA) prefix [RFC4193] could be used to increase the number of addresses available on the local host. However this prefix would need to be manually generated and configured at least once by a system administrator or operator. Without additonal configuration, traffic towards addresses not assigned to the local host would not be prevented from leaving the host, and access may not be limited to the local host. A ULA prefix would not be well known, and would not be convenient to remember and type without violating the randomness requirements of the Global ID component of a ULA prefix. This memo proposes a new larger IPv6 loopback prefix that provides many more loopback addresses, has properties of native IPv6 addresses, and is easy to remember and type. Unlike ::1/128, the Smith Expires August 15, 2013 [Page 3] Internet-Draft A Larger IPv6 Loopback Prefix February 2013 processing rules for this prefix match those of IPv4's 127/8. These rules allow sending or forwarding of packets with loopback addresses beyond the originating host under certain circumstances. This memo, if published, updates [RFC4291], [RFC5156], [RFC6303] and [RFC6724]. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. Larger Loopback Prefix Requirements A new larger loopback prefix should attempt to satisfy all of the following requirements. It should: o be a well known prefix, o be within an existing special purpose prefix, such as 0000::/8 (the parent prefix of the current IPv6 loopback address), o be easy for a human to remember, o be easy for a human to type, o cover the existing loopback prefix, o support 64 bit Interface Identifiers, o provide a large number of /64 subnets. 3. Proposed Larger Loopback Prefix Ideally, the prefix length of ::1/128 could be shortened, resulting in a larger loopback prefix such as ::/48. However, if the existing loopback prefix length is shortened enough to satisfy all of the larger loopback prefix requirements, it would then cover the IPv4 Mapped IPv6 Address prefix, ::ffff:0.0.0.0/96, and prevent its use described in [RFC4038]. Giving up the requirement of covering the existing loopback prefix, the proposed larger loopback prefix is: Smith Expires August 15, 2013 [Page 4] Internet-Draft A Larger IPv6 Loopback Prefix February 2013 0001:0000:0000:0000:0000:0000:0000:0000/32 or concisely, 1::/32 This prefix satisfies all remaining larger loopback prefix requirements. Allocating a /32 prefix for the loopback function may seem excessive, as a /48 length prefix would satisfy the larger loopback prefix requirements. However, within the parent 0000::/8 special purpose prefix, there are approximately 16 million /32 prefixes, so a single /32 for the larger loopback prefix is easily afforded. A /32 larger loopback prefix will satisfy all current and likely future uses of the loopback function. 4. Address Assignment and Configuration Consistent with the IPv6 addressing model [RFC4291], each address within the larger loopback prefix is associated with one of the node's interfaces, although not necessarily the same interface for all addresses. This means that the node acts as though all addresses within the larger loopback prefix have been configured on one or more interfaces. Applications will accept packets destined to any of the larger loopback prefix addresses, unless the application is bound to specific larger loopback addresses. Typically the addresses will be logically assigned to one or more virtual "loopback" interfaces, which locally returns or loops outgoing packets back to the same node that originated the packets. It is also common to configure a well known loopback address on the loopback interface during system initialisation, making a loopback address visible to the system operator or user. For IPv4, this address is 127.0.0.1/8; for IPv6, it is ::1/128. For the new larger loopback prefix, the address automatically configured on the loopback interface should be: 1::1/64 A /64 prefix length has been chosen over /32 to provide a 64 bit Interface Identifier for the loopback interface. This is different from the use of the whole loopback prefix length when configuring 127.0.0.1/8 or ::1/128. Some nodes may support more than one loopback interface. These subsequent loopback interfaces, when initialised, should be assigned Smith Expires August 15, 2013 [Page 5] Internet-Draft A Larger IPv6 Loopback Prefix February 2013 a larger loopback /64 prefix locally unique within the node. All addresses within the assigned /64 are logically assigned to the interface. Additionally, the ":1" address for the subnet should be configured on the loopback interface, making it visible to a system operator or user. /64 subnet identifier uniqueness could be achieved by using the loopback interface instance number as the subnet identifier, with the first instance numbered 0 to suit the use of 1::1/64 on the first loopback interface. For example, the second loopback interface could be assigned 1:0:0:1::/64, while the forth loopback interface could be assigned 1:0:0:3::/64. Alternatively, the interfaces' ifIndex [RFC1213] could be used to determine these subsequent interfaces' loopback /64 subnet identifier. Other schemes which ensure subnet identifier uniqueness would be acceptable. It should be possible for an operator to remove these automatically configured loopback addresses. It should also be possible for an operator to configure further loopback addresses from within the assigned /64, or addresses from other parts of the larger loopback prefix, including other /64s assigned to other loopback interfaces. Other addresses within the assigned /64(s) would continue to be logically assigned to the subsequent loopback interface. Configuration of addresses is for operational visibility and convenience, and does not change the behaviour of non-visible logically assigned addresses. The larger loopback prefix addresses that are outside of the subsequent loopback interface assigned /64s would continue to be logically assigned to the oldest loopback interface. 5. Larger Loopback Prefix Processing Rules 5.1. Host Rules 5.1.1. Packets Originated with Larger Loopback Source and/or Destination Addresses Packets originated with larger loopback source and/or destination addresses MUST be returned to the origin host for standard processing by the local IPv6 protocol implementation. They MUST NOT be sent over any external links attached to the host. If the implementation supports multiple loopback interfaces, and they have been assigned prefixes and addresses from within the larger loopback prefix, the egress loopback interface SHOULD be the interface assigned the matching destination loopback address. The Smith Expires August 15, 2013 [Page 6] Internet-Draft A Larger IPv6 Loopback Prefix February 2013 ingress loopback interface MUST be the interface assigned the matching destination loopback address. This will facilitate loopback interface specific handling of the looped traffic, such as traffic filtering or traffic conditioning, which may be useful during network application development. Note that standard IPv6 longest match packet forwarding will facilitate this multiple loopback interface processing. All addresses within the larger loopback prefix MUST always be considered assigned to one of the host's interfaces, consistent with IPv6's addressing model [RFC4291]. Ingress packets, once they have passed any interface specific policies, MUST be delivered to the appropriate protocol module (e.g., such as TCP, SCTP, UDP or ICMPv6) interested in packets with the destination larger loopback prefix address for further processing. 5.1.2. Packets Received Externally With Larger Loopback Source and/or Destination Addresses Packets with larger loopback source and/or destination addresses received over any of the external links attached to the host MUST be dropped. ICMPv6 error messages, such as Destination Unreachable messages, MUST NOT be generated for these dropped packets. Implementation suggestion: For these dropped packets, it may be useful to generate an appropriate system log message, indicating a packet with an invalid source or destination address (a "martian" [RFC1812]) was received over an external interface. By default, these messages should be suppressed. If they are enabled, they should be appropriately rate limited to prevent a system log denial-of-service attack. 5.2. Router Rules IPv4 loopback packet processing rules for routers, specified in [RFC1812], by default prohibited forwarding of packets with 127/8 destinations, other than those originated locally and returned back to the router itself. A software switch could be provided to disable this prohibition. This special case of allowing forwarding of packets towards 127/8 destinations has been taken advantage of by [RFC4379], for MPLS troubleshooting purposes. An equivalent function for IPv6 is provided by using the IPv4-Mapped IPv6 prefix of ::ffff: 127.0.0.0/104. The existing ::1/128 packet processing rules for routers are the same as those for IPv6 hosts [RFC4291]. For the new larger loopback prefix, the IPv6 router processing rules Smith Expires August 15, 2013 [Page 7] Internet-Draft A Larger IPv6 Loopback Prefix February 2013 are changed to match those of IPv4, to suit future uses similar to the MPLS troubleshooting case. 5.2.1. Packets Originated with Larger Loopback Source and/or Destination Addresses By default, a router MUST follow the host processing rules, described previously, for packets originated with larger loopback source and/or destination addresses. A software switch may be provided to permit packets with larger loopback source and/or destination addresses to be sent via an external interface. If provided, this software switch MUST default to being switched off. 5.2.2. Packets Received Externally With Larger Loopback Source and/or Destination Addresses By default, a router MUST follow the host processing rules, described previously, for packets received externally with larger loopback source and/or destination addresses. A software switch may be provided to permit received packets with larger loopback source and/or destination addresses to be forwarded via an external interface. This software switch MUST default to being switched off. 6. Default Address Selection For the purposes of default address selection [RFC6724], as with ::1/128, addresses within the larger loopback prefix MUST be treated as having link-local scope, and must have a "preferred" configuration status. Within the address selection default policy table, the larger loopback prefix is to be assigned a precedence value of 60. As the existing ::1/128 loopback address has a precedence value of 50, given a choice, a larger loopback prefix address will be chosen as a destination address over ::1/128. Within the address selection default policy table, the larger loopback prefix is to be assigned a label value of 14, for use during source address selection. These default address selection changes should be enabled at the same time that the larger loopback prefix and corresponding processing rules are enabled on a node. Smith Expires August 15, 2013 [Page 8] Internet-Draft A Larger IPv6 Loopback Prefix February 2013 7. DNS Considerations The DNS zone for 1::/32, 0.0.0.0.1.0.0.0.IP6.ARPA, SHOULD be served locally. [RFC6303] provides further discussion regarding local serving of DNS zones for non-global IP address spaces. 8. Acknowledgements Nick Hilliard provided valuable review, comments and advice on this memo. Review and comments were provided by, in alphabetical order, Bill Atwood, Brian Carpenter, Roland Chan, Chris Chaundy, Chris Donovan, Matts Kallioniemi, Erik Kline and Tina Tsou. Thanks to Bill for persisting with advice on grammar errors. This memo was prepared using the xml2rfc tool. 9. IANA Considerations IANA is requested to allocate 0001::/32 from within 0000::/8 of the Internet Protocol Version 6 Address Space, for use as a larger loopback prefix for IPv6, as detailed in this memo, and to record it in the [IANA-IPV6REG]. 10. Security Considerations During deployment of a new larger loopback prefix, there will be a transition period where some hosts and routers have implemented the larger loopback processing rules defined in this memo while others haven't. These legacy hosts and routers will forward larger loopback prefix traffic using conventional unicast processing. For traffic towards non-local larger loopback addresses, traffic will most likely leave the legacy originating host via its default route, and may be forwarded by legacy routers using their default route. This may unintentionally disclose sensitive information. Packet filters, matching traffic with larger loopback source and/or destination addresses, should be used to prevent unintended forwarding of loopback traffic. They should be deployed at the following locations: o on the legacy hosts themselves, Smith Expires August 15, 2013 [Page 9] Internet-Draft A Larger IPv6 Loopback Prefix February 2013 o on legacy routers interconnecting different networks, such as on a router interconnecting a private network and the Internet, o on appropriate security domain boundary legacy routers within the local network, if not all legacy routers within the local network. Routes for the new larger loopback prefix should not be announced or accepted if received, unless necessary for special cases where packets with larger loopback prefix addresses are allowed to be forwarded. 11. Change Log [RFC Editor please remove] draft-smith-larger-ipv6-loopback-prefix-00, initial version, 2012-07-24 draft-smith-larger-ipv6-loopback-prefix-01, much less verbose version, 2012-08-17 draft-smith-larger-ipv6-loopback-prefix-02, clarifications, 2013-01-07 o clarification that the larger loopback prefix should fall within ::/8, the parent prefix of ::/128 and ::1/128 o Change from 1::/48 to 1::/32 o text about logically assigning addresses to interface(s), as per IPv6 addressing model o automatic loopback address configuration to multiple loopback interfaces o local serving of 0.0.0.1.0.0.0.IP6.ARPA zone in DNS draft-smith-larger-ipv6-loopback-prefix-03, clarifications, 2013-02-07 o default address selection precedence and label values o comment about other IPv4 in IPv6 address forms o more clarifications o grammar corrections Smith Expires August 15, 2013 [Page 10] Internet-Draft A Larger IPv6 Loopback Prefix February 2013 12. References 12.1. Normative References [IANA-IPV6REG] Internet Assigned Numbers Authority, "IPv6 Special Purpose Address Registry", 2013, . [RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989. [RFC1213] McCloghrie, K. and M. Rose, "Management Information Base for Network Management of TCP/IP-based internets:MIB-II", STD 17, RFC 1213, March 1991. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 12.2. Informative References [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995. [RFC4038] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E. Castro, "Application Aspects of IPv6 Transition", RFC 4038, March 2005. [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005. [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006. [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006. [RFC5156] Blanchet, M., "Special-Use IPv6 Addresses", RFC 5156, April 2008. [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, October 2010. [RFC6303] Andrews, M., "Locally Served DNS Zones", BCP 163, RFC 6303, July 2011. Smith Expires August 15, 2013 [Page 11] Internet-Draft A Larger IPv6 Loopback Prefix February 2013 [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, "Default Address Selection for Internet Protocol Version 6 (IPv6)", RFC 6724, September 2012. Author's Address Mark Smith In My Own Time PO BOX 521 HEIDELBERG, VIC 3084 AU Email: markzzzsmith@yahoo.com.au Smith Expires August 15, 2013 [Page 12]