Skip to main content

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

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 Fred Templin
Last updated 2016-01-05
RFC stream (None)
Formats
Additional resources
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-templin-v6ops-pdhost-01
Network Working Group                                    F. Templin, Ed.
Internet-Draft                              Boeing Research & Technology
Intended status: Informational                          January 05, 2016
Expires: July 8, 2016

      Delegating a Prefix to a Host for Multi-addressing Purposes
                   draft-templin-v6ops-pdhost-01.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 July 8, 2016.

Copyright Notice

   Copyright (c) 2016 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 July 8, 2016                  [Page 1]
Internet-Draft         Prefix Delegation for Hosts          January 2016

   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 the Dynamic Host
   Configuration Protocol for IPv6 (DHCPv6) [RFC3315][RFC3633].  Using
   DHCPv6 Prefix Delegation (PD) [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
   delegation [RFC3315], as well as assignment of multiple addresses
   from a delegated prefix.

Templin                   Expires July 8, 2016                  [Page 2]
Internet-Draft         Prefix Delegation for Hosts          January 2016

   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
   Multicast Listener Discovery (MLD) to join the appropriate solicited-
   node multicast group(s) and 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 MLD/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 interface, and configures a default route that points to a
   router on the WAN link.  The node can then act as both 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 an
   internal virtual interface (e.g., a loopback interface) and assign
   one or more addresses taken from the prefix to the virtual interface.
   In that case, applications on the node can use the assigned addresses
   according to the weak end system model.

   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.

Templin                   Expires July 8, 2016                  [Page 3]
Internet-Draft         Prefix Delegation for Hosts          January 2016

   In both of these latter two cases, the node acts as a host internally
   even though it behaves as a router from the standpoint of prefix
   delegation and neighbor discovery over the WAN interface.  The host
   can configure as many addresses for itself as it wants.

4.  DAD Implications

   When a node configures addresses for itself using either SLAAC or
   DHCPv6 address delegation and assigns the addresses to the WAN
   interface, the node MUST perform MLD/DAD by sending multicast packets
   the solicited-node multicast address to test whether another node
   that configures a duplicate address is on the link.  When there are
   many such addresses 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 MLD/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.  Note however that nodes that
   assign the addresses directly to the WAN interface must be capable of
   disabling DAD on the WAN interface.

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 entry 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 July 8, 2016                  [Page 4]
Internet-Draft         Prefix Delegation for Hosts          January 2016

8.  Acknowledgements

   This work was motivated by recent discussions on the v6ops list.
   Mark Smith pointed out the need to consider MLD as well as DAD for
   the assignment of addresses to interfaces.

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 July 8, 2016                  [Page 5]
Internet-Draft         Prefix Delegation for Hosts          January 2016

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-04 (work in progress),
              January 2016.

   [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 July 8, 2016                  [Page 6]