A Larger Loopback Prefix for IPv6

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 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 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 only provides a single address. Multiple application instances using the 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 , 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. A Unique Local IPv6 Unicast Address (ULA) prefix 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 more loopback addresses, has properties of native IPv6 addresses, and is easy to remember and type. This prefix will also suit other uses of multiple loopback addresses that may emerge. This memo, if published, updates , and .

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.

A new larger loopback prefix should attempt to satisfy all of the following requirements: be a well known prefix, be within an existing special purpose prefix, such as ::/8 (the parent prefix of ::/128 and ::1/128), be easy for a human to remember, be easy for a human to type, should cover the existing loopback prefix, should support 64 bit Interface Identifiers, should provide a large number of /64 subnets.

Ideally, the prefix length of ::1/128 could be shortened, resulting in a larger loopback prefix. However, if the existing loopback prefix length was 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 . Giving up the requirement of covering the existing loopback prefix, the proposed larger loopback prefix is: 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 prefix would adequately meet the larger loopback prefix requirements. However, within the parent ::/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.

Consistent with the IPv6 addressing model , all addresses within the larger loopback prefix are to be logically assigned to one or more of the node's interfaces. Typically, the addresses will be logically assigned to a single virtual "loopback" interface, which returns or loops outgoing packets back to the originating node. It is also common to configure a well known loopback address on the loopback interface during system initialisation. For IPv4, this address is 127.0.0.1/8, while in 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 IPv4 loopback prefix length of /8 when configuring the IPv4 127.0.0.1 loopback address. Some implementations may support more than one loopback interface. These subsequent loopback interfaces, when initialised, should be assigned a locally unique larger loopback prefix /64 subnet, with all addresses within the /64 being logically assigned to the interface. Additionally, the ":1" address for the subnet should be configured on the loopback interface. /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 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 a different /64 from within the larger loopback prefix. The larger loopback prefix addresses that are outside of the subsequent loopback interface assigned /64s would continue to be logically assigned to the first or oldest loopback interface.

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, the egress loopback interface SHOULD be the interface assigned the matching destination loopback address. The 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 be considered assigned to one or more of the host's interfaces.

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. 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") 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.

IPv4 loopback packet processing rules for routers, specified in , 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 . 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 is the same as for IPv6 hosts . For the new larger loopback prefix, the IPv6 router processing rules are changed to match those of IPv4.

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 off.

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 off.

The DNS zone for 1::/32, 0.0.0.0.1.0.0.0.IP6.ARPA, SHOULD be served locally. provides further discussion regarding local serving of DNS zones for non-global IP address space.

Nick Hilliard provided valuable review, comments and advice on this memo. Review and comments where provided by Bill Atwood, Brian Carpenter, Roland Chan, Chris Chaundy, Chris Donovan, Matts Kallioniemi, Erik Kline and Tina Tsou. This memo was prepared using the xml2rfc tool.

IANA is requested to allocate 1::/48 from within ::/8 of the Internet Protocol Version 6 Address Space, for use as a larger loopback prefix for IPv6, as described in this memo, and record to it in the .

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 traffic using conventional unicast processing. For traffic towards non-local larger loopback addresses, traffic will most likely leave the legacy originating host via it's default route, and may be forwarded by legacy routers using their default route. This may disclose sensitive information, violating security policy. 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: on the legacy hosts themselves, on legacy routers interconnecting two different networks, 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.

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 clarification that the larger loopback prefix should fall within ::/8, the parent prefix of ::/128 and ::1/128 Change from 1::/48 to 1::/32 text about logically assigning addresses to interface(s), as per IPv6 addressing model automatic loopback address configuration to multiple loopback interfaces local serving of 0.0.0.1.0.0.0.IP6.ARPA zone in DNS