[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 04

Internet Engineering Task Force                                 M. Smith
Internet-Draft                                                      IMOT
Updates: 4291,5156,6303,6724                           February 20, 2013
(if approved)
Intended status: Standards Track
Expires: August 24, 2013


                   A Larger Loopback Prefix for IPv6
            draft-smith-v6ops-larger-ipv6-loopback-prefix-04

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 commonly 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.  The processing rules
   for this new larger loopback prefix also allow sending or forwarding
   of packets containing these addresses beyond the originating router
   under certain circumstances.

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 24, 2013.

Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.




Smith                    Expires August 24, 2013                [Page 1]


Internet-Draft        A Larger IPv6 Loopback Prefix        February 2013


   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
   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 24, 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 have commonly been able to be used to run multiple
   instances of an application on the same port, while also limiting
   access to the local host.

   The IPv6 addressing architecture [RFC4291] only specifies a single
   loopback address (::1/128).  Multiple IPv6 loopback addresses are not
   available to bind application instances to when using the same port
   on the same host.

   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 accommodate 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 generated and configured at
   least once by a system administrator or operator.  Without additional
   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 easy to remember and type accurately without
   violating the randomness requirements of the Global ID component of a
   ULA prefix.  Using hostnames in DNS or the local host's name
   resolution file (e.g., /etc/hosts) to overcome the effort required to
   remember or type a ULA prefix may not be possible for some types of
   applications which directly deal with IPv6 addresses.



Smith                    Expires August 24, 2013                [Page 3]


Internet-Draft        A Larger IPv6 Loopback Prefix        February 2013


   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 accurately.  As with
   ::1/128, it is intended to be automatically configured during system
   initialisation, making it ubiquitous.  Unlike ::1/128, the processing
   rules for this prefix match those of IPv4's 127/8.  These rules allow
   sending or forwarding of packets with the new larger loopback prefix
   addresses beyond the originating router 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 [EASY-NUMBERS],

   o  be easy for a human to type accurately [DOET],

   o  cover the existing IPv6 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 new single larger loopback prefix for IPv6, 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].



Smith                    Expires August 24, 2013                [Page 4]


Internet-Draft        A Larger IPv6 Loopback Prefix        February 2013


   Giving up the requirement of covering the existing IPv6 loopback
   prefix, the proposed new 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 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 always logically assigned to 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 a specific larger loopback address.  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 [DOET].  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

   This address will be easy for a human to both remember
   [EASY-NUMBERS][DOET] and type accurately [DOET].

   A /64 prefix length has been chosen over /32 to provide a 64 bit



Smith                    Expires August 24, 2013                [Page 5]


Internet-Draft        A Larger IPv6 Loopback Prefix        February 2013


   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
   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 [DOET].

   /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 [DOET], 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



Smith                    Expires August 24, 2013                [Page 6]


Internet-Draft        A Larger IPv6 Loopback Prefix        February 2013


   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
   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:



Smith                    Expires August 24, 2013                [Page 7]


Internet-Draft        A Larger IPv6 Loopback Prefix        February 2013


   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
   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 [RFC6724], 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 [RFC6724], the



Smith                    Expires August 24, 2013                [Page 8]


Internet-Draft        A Larger IPv6 Loopback Prefix        February 2013


   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.


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, Owen DeLong,
   Chris Donovan, Matts Kallioniemi, Erik Kline and Tina Tsou.  Thanks
   to Bill for persisting with advice on grammar errors.  Owen DeLong
   does not agree with what is proposed in this memo, however his review
   and comments, as with the other reviewers' comments, have helped
   improve it.

   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



Smith                    Expires August 24, 2013                [Page 9]


Internet-Draft        A Larger IPv6 Loopback Prefix        February 2013


   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,

   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



Smith                    Expires August 24, 2013               [Page 10]


Internet-Draft        A Larger IPv6 Loopback Prefix        February 2013


   o  default address selection precedence and label values

   o  comment about other IPv4 in IPv6 address forms

   o  more clarifications

   o  grammar corrections

   draft-smith-larger-ipv6-loopback-prefix-04, minor fixups, 2013-02-20

   o  usability references (DOET and EASY-NUMBERS)

   o  minor clarifications

   o  grammar corrections


12.  References

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

12.2.  Informative References

   [DOET]     Norman, D., "The Design of Everyday Things", 2002, <http:/
              /www.jnd.org/books/the-design-of-everyday-things.html>.

   [EASY-NUMBERS]
              Milikowski, M. and J. Elshout, "What makes a number easy
              to remember?", 1995, <http://http://www.rekencentrale.nl/
              bestanden/Andere_artikelen_MM/1995_1999/pdf_files/
              What_makes_a_number_easy.pdf>.

   [RFC1812]  Baker, F., "Requirements for IP Version 4 Routers",



Smith                    Expires August 24, 2013               [Page 11]


Internet-Draft        A Larger IPv6 Loopback Prefix        February 2013


              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.

   [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 24, 2013               [Page 12]


Html markup produced by rfcmarkup 1.123, available from https://tools.ietf.org/tools/rfcmarkup/