Delegating a Prefix to a Host for Multi-addressing Purposes
draft-templin-v6ops-pdhost-00

Network Working Group                                    F. Templin, Ed.
Internet-Draft                              Boeing Research & Technology
Intended status: Informational                         November 06, 2015
Expires: May 9, 2016

      Delegating a Prefix to a Host for Multi-addressing Purposes
                   draft-templin-v6ops-pdhost-00.txt

Abstract

   IPv6 prefixes are typically delegated to requesting routers which
   then use them to number their downstream-attached links and networks.
   The requesting router then acts as a router between the downstream-
   attached hosts and the upstream provider network.  The router could
   also act as a host under the weak end system model, and otherwise
   behaves as a standard router.  This document considers the case when
   the "requesting router" is actually a host, and receives a prefix
   that it can use for multi-addressing purposes.  The host does not
   connect any downstream-attached networks, and uses the prefix solely
   for its own multi-addressing purposes.

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 May 9, 2016.

Copyright Notice

   Copyright (c) 2015 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
   publication of this document.  Please review these documents

Templin                    Expires May 9, 2016                  [Page 1]
Internet-Draft         Prefix Delegation for Hosts         November 2015

   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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Multi-Addressing  . . . . . . . . . . . . . . . . . . . . . .   2
   3.  Multi-Addressing Alternatives . . . . . . . . . . . . . . . .   3
   4.  DAD Implications  . . . . . . . . . . . . . . . . . . . . . .   4
   5.  Route Optimization  . . . . . . . . . . . . . . . . . . . . .   4
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   5
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   5
     9.2.  Informative References  . . . . . . . . . . . . . . . . .   6
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   IPv6 provides a prefix delegation service using either the Dynamic
   Host Configuration Protocol for IPv6 (DHCPv6) [RFC3315][RFC3633] or
   through an implicit delegation from a Prefix Information Option (PIO)
   in a Router Advertisement (RA) [RFC4861] (out of scope for this
   document).  When DHCPv6 Prefix Delegation (PD) is used [RFC3633], a
   requesting router asks for a prefix from a delegating router.  When
   the prefix is delegated, the requesting router assigns the prefix to
   its downstream-attached link (i.e., the "LAN" interface).  The
   requesting router then acts as a router between hosts on the LAN
   interface and the upstream provider network (i.e., the "WAN"
   interface).  The router could also act as a host under the weak end
   system model [RFC1122], and otherwise behaves as a standard router.
   This document considers the case when the "requesting router" is
   actually a simple host, and receives a prefix delegation as if it
   were a router.  The host need not have a LAN interface, and can use
   the prefix solely for its own multi-addressing purpose.

2.  Multi-Addressing

   IPv6 allows for assignment of multiple addresses to a single
   interface.  [I-D.ietf-v6ops-host-addr-availability] discusses options
   for multi-addressing as well as use cases where multi-addressing may
   be desirable.  Multi-addressing options include Stateless Address
   Autoconfiguration (SLAAC) [RFC4862] or stateful DHCPv6 address

Templin                    Expires May 9, 2016                  [Page 2]
Internet-Draft         Prefix Delegation for Hosts         November 2015

   delegation [RFC3315], as well as assignment of multiple addresses
   from a delegated prefix.

   SLAAC and DHCPv6 address delegation typically obtain addresses from
   an on-link prefix configured on the link over which the addresses are
   obtained.  When this happens, the address recipient is obliged to use
   the Duplicate Address Detection (DAD) algorithm [RFC4862] to ensure
   that no other node on the link configures a duplicate address.
   Alternatively, address delegation from a delegated prefix can be used
   by a node under either the weak or strong end system models
   [RFC1122].  In that case, the DAD procedure is not necessary, since
   the prefix has been delegated to the node for its own exclusive use
   and the prefix is NOT assigned to the link over which the prefix was
   obtained.

3.  Multi-Addressing Alternatives

   When a node receives a prefix delegation, it has many alternatives
   for the way in which it can provision the prefix.  [RFC7278]
   discusses alternatives for provisioning a prefix obtained by a User
   Equipment (UE) device under the 3rd Generation Partnership Program
   (3GPP) service model.  This document considers the general case when
   the node receives a prefix delegation in which the prefix is
   delegated for the exclusive use of the prefix recipient.

   When the node receives the prefix (e.g., a /64), it can assign the
   prefix to a LAN interface and configure multiple addresses for itself
   on the LAN interface.  The node uses link-local-only addressing on
   the WAN interaface, and configures a default route that points to a
   router on the WAN link.  The node can then both act as a host for its
   own applications and a router for any downstream-attached hosts.
   This approach is often known as the "tethered" configuration.

   When the node does not have any LAN interfaces, it may still wish to
   obtain a prefix solely for multi-addressing purposes.  In a first
   alternative, the node can receive the prefix acting as a requesting
   router over the WAN interface but then assign the prefix to a
   loopback interface and assign one or more addresses taken from the
   prefix to the loopback interface.  In that case, applications on the
   node can use the assigned addresses according to the weak end system
   model and the node must have IP forwarding enabled.

   In a second alternative, the node can receive the prefix as a
   requesting router over the WAN interface but then assign the prefix
   to a loopback interface and assign one or more addresses taken from
   the prefix to the WAN interface.  In that case, applications on the
   node can use the assigned addresses according to the strong end
   system model, and the node need not have IP forwarding enabled.

Templin                    Expires May 9, 2016                  [Page 3]
Internet-Draft         Prefix Delegation for Hosts         November 2015

   In both of these latter two cases, the node acts as a pure host
   internally even though it behaved as a router from the standpoint of
   prefix delegation.  The host can configure as many addresses for
   itself as it wants.

4.  DAD Implications

   When a node configures adddresses for itself using either SLAAC or
   DHCPv6 address delegation and assigns the addresses to the WAN
   interface, the node MUST perform DAD by sending multicast packets to
   test whether another node that configures a duplicate address is on
   the link.  When there are many such addressses and/or many such
   nodes, this could result in substantial multicast traffic that
   affects all nodes on the link.

   When a node configures addresses for itself using a delegated prefix,
   the node can configure as many addresses as it wants but does not
   perform DAD for any of the addresses over the WAN interface.  This
   means that millions of addresses can be assigned without having any
   multicast messaging over the WAN link that could disturb other nodes.
   This becomes important when there are many such nodes and/or many
   addresses configured per node.

5.  Route Optimization

   When a node does not assign a non-link-local prefix on the WAN
   interface, it initially has only a default route pointing to a router
   on the WAN link.  This means that all packets the node sends over the
   WAN interface will initially need to go through the default router
   even if there is a better first-hop node on the link.  In that case,
   the default router can send a Redirect to inform the node of a better
   first hop.  The Redirect populates an entery in the node's neighbor
   cache for the WAN interface, and future packets can take the more
   direct route without disturbing the default router.  The Redirect can
   apply either to a singleton destination address, or to an entire
   destination prefix as described in AERO [I-D.templin-aerolink].

6.  IANA Considerations

   This document introduces no IANA considerations.

7.  Security Considerations

   TBD.

Templin                    Expires May 9, 2016                  [Page 4]
Internet-Draft         Prefix Delegation for Hosts         November 2015

8.  Acknowledgements

   TBD

9.  References

9.1.  Normative References

   [RFC0791]  Postel, J., "Internet Protocol", STD 5, RFC 791,
              DOI 10.17487/RFC0791, September 1981,
              <http://www.rfc-editor.org/info/rfc791>.

   [RFC1122]  Braden, R., Ed., "Requirements for Internet Hosts -
              Communication Layers", STD 3, RFC 1122,
              DOI 10.17487/RFC1122, October 1989,
              <http://www.rfc-editor.org/info/rfc1122>.

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
              December 1998, <http://www.rfc-editor.org/info/rfc2460>.

   [RFC3315]  Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
              C., and M. Carney, "Dynamic Host Configuration Protocol
              for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
              2003, <http://www.rfc-editor.org/info/rfc3315>.

   [RFC3633]  Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
              Host Configuration Protocol (DHCP) version 6", RFC 3633,
              DOI 10.17487/RFC3633, December 2003,
              <http://www.rfc-editor.org/info/rfc3633>.

   [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
              "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
              DOI 10.17487/RFC4861, September 2007,
              <http://www.rfc-editor.org/info/rfc4861>.

   [RFC4862]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
              Address Autoconfiguration", RFC 4862,
              DOI 10.17487/RFC4862, September 2007,
              <http://www.rfc-editor.org/info/rfc4862>.

   [RFC7278]  Byrne, C., Drown, D., and A. Vizdal, "Extending an IPv6
              /64 Prefix from a Third Generation Partnership Project
              (3GPP) Mobile Interface to a LAN Link", RFC 7278,
              DOI 10.17487/RFC7278, June 2014,
              <http://www.rfc-editor.org/info/rfc7278>.

Templin                    Expires May 9, 2016                  [Page 5]
Internet-Draft         Prefix Delegation for Hosts         November 2015

9.2.  Informative References

   [I-D.ietf-v6ops-host-addr-availability]
              Colitti, L., Cerf, V., Cheshire, S., and D. Schinazi,
              "Host address availability recommendations", draft-ietf-
              v6ops-host-addr-availability-02 (work in progress),
              November 2015.

   [I-D.templin-aerolink]
              Templin, F., "Asymmetric Extended Route Optimization
              (AERO)", draft-templin-aerolink-63 (work in progress),
              August 2015.

Author's Address

   Fred L. Templin (editor)
   Boeing Research & Technology
   P.O. Box 3707
   Seattle, WA  98124
   USA

   Email: fltemplin@acm.org

Templin                    Expires May 9, 2016                  [Page 6]