A Larger Loopback Prefix for IPv6
draft-smith-v6ops-larger-ipv6-loopback-prefix-02
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Author | Mark Smith | ||
| Last updated | 2013-01-14 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-smith-v6ops-larger-ipv6-loopback-prefix-02
Internet Engineering Task Force M. Smith
Internet-Draft IMOT
Updates: 4291,5156,6303 January 14, 2013
(if approved)
Intended status: Standards Track
Expires: July 18, 2013
A Larger Loopback Prefix for IPv6
draft-smith-v6ops-larger-ipv6-loopback-prefix-02
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 loopback IPv6 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 July 18, 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 July 18, 2013 [Page 1]
Internet-Draft A Larger IPv6 Loopback Prefix January 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 . . . . . . . . . 6
5.2. Router Rules . . . . . . . . . . . . . . . . . . . . . . . 7
5.2.1. Packets Originated with Larger Loopback Source
and/or Destination Addresses . . . . . . . . . . . . . 7
5.2.2. Packets Received Externally With Larger Loopback
Source and/or Destination Addresses . . . . . . . . . 7
6. DNS Considerations . . . . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
9. Security Considerations . . . . . . . . . . . . . . . . . . . 8
10. Change Log [RFC Editor please remove] . . . . . . . . . . . . 9
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
11.1. Normative References . . . . . . . . . . . . . . . . . . . 9
11.2. Informative References . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10
Smith Expires July 18, 2013 [Page 2]
Internet-Draft A Larger IPv6 Loopback Prefix January 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 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 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.
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
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 [RFC4291], [RFC5156] and [RFC6303].
Smith Expires July 18, 2013 [Page 3]
Internet-Draft A Larger IPv6 Loopback Prefix January 2013
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:
o be a well known prefix,
o be within an existing special purpose prefix, such as ::/8 (the
parent prefix of ::/128 and ::1/128),
o be easy for a human to remember,
o be easy for a human to type,
o should cover the existing loopback prefix,
o should support 64 bit Interface Identifiers,
o should 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. 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 [RFC4038].
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.
Smith Expires July 18, 2013 [Page 4]
Internet-Draft A Larger IPv6 Loopback Prefix January 2013
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.
4. Address Assignment and Configuration
Consistent with the IPv6 addressing model [RFC4291], 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 [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
Smith Expires July 18, 2013 [Page 5]
Internet-Draft A Larger IPv6 Loopback Prefix January 2013
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.
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, 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.
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.
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
Smith Expires July 18, 2013 [Page 6]
Internet-Draft A Larger IPv6 Loopback Prefix January 2013
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]. 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 [RFC4291].
For the new larger loopback prefix, the IPv6 router processing rules
are changed to match those of IPv4.
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 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 off.
6. 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 space.
Smith Expires July 18, 2013 [Page 7]
Internet-Draft A Larger IPv6 Loopback Prefix January 2013
7. Acknowledgements
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.
8. IANA Considerations
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
[IANA-IPV6REG].
9. 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
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:
o on the legacy hosts themselves,
o on legacy routers interconnecting two different networks,
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.
Smith Expires July 18, 2013 [Page 8]
Internet-Draft A Larger IPv6 Loopback Prefix January 2013
10. 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
11. References
11.1. Normative References
[IANA-IPV6REG]
Internet Assigned Numbers Authority, "IPv6 Special Purpose
Address Registry", 2013, <http://www.iana.org/assignments/
iana-ipv6-special-registry>.
[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.
11.2. Informative References
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers",
RFC 1812, June 1995.
Smith Expires July 18, 2013 [Page 9]
Internet-Draft A Larger IPv6 Loopback Prefix January 2013
[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.
[RFC6303] Andrews, M., "Locally Served DNS Zones", BCP 163,
RFC 6303, July 2011.
Author's Address
Mark Smith
In My Own Time
PO BOX 521
HEIDELBERG, VIC 3084
AU
Email: markzzzsmith@yahoo.com.au
Smith Expires July 18, 2013 [Page 10]