IPv6 Prefix Delegation for
HostsBoeing Research & TechnologyP.O. Box 3707SeattleWA98124USAfltemplin@acm.orgI-DInternet-DraftIPv6 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 Internetwork, and can also
act as a host under the weak end system model. This document considers
the case when the "requesting router" is actually a simple host which
receives a delegated prefix that it can use solely for its own internal
multi-addressing purposes under the strong end system model. This method
can be applied in a wide variety of use cases to allow ample address
availability without impacting link performance.IPv6 Prefix Delegation (PD) entails 1) the communication of a prefix
from a delegating authority to a requesting node, 2) a representation of
the prefix in the routing system, and 3) a control messaging service to
maintain delegated prefix lifetimes. Following delegation, the prefix is
available for the requesting node's exclusive use and is not shared with
any other nodes. An example IPv6 PD service is DHCPv6 PD .Using services such as DHCPv6 PD, a Delegating Router 'D' delegates a
prefix 'P' to a Requesting Node 'R'' as shown in :In this figure, when Delegating Router 'D' delegates prefix
'P', the prefix is injected into the routing system in some fashion to
ensure that IPv6 packets with destination addresses covered by 'P' are
unconditionally forwarded to Requesting Node 'R'. Meanwhile, 'R'
receives 'P' via its "WAN" interface and sub-delegates 'P' to its
downstream-attached links via one or more "LAN" interfaces. Hosts 'Hn'
on a LAN interface subsequently receive addresses 'An' taken from 'P'
via an address autoconfiguration service such as IPv6 Stateless Address
Autoconfiguration (SLAAC) . 'R' then acts as a
router between hosts 'Hn' and correspondents reachable via the WAN
interface. 'R' can also (or instead) act as a host under the weak end
system model if it can assign addresses taken
from 'P' to its own internal virtual interfaces (e.g., a loopback).This document considers the case when 'R' is actually a simple host,
and receives a prefix delegation 'P' as if it were a router. The host
need not have any LAN interfaces, and can use the prefix solely for its
own internal addressing purposes. This could include assigning IPv6
adddresses taken from prefix 'P' to the WAN interface and then
functioning as a host under the strong end system model as shown in :In the above diagram, Requesting Node 'R' receives prefix 'P'
from Delegating Router 'D' the same as described above. However, when
'R' receives 'P' it assigns addresses 'An' taken from 'P' to the WAN
interface instead of sub-delegating 'P' to downstream attached LAN
interfaces. The major benefit for a host managing a delegated prefix in
this fashion is multi-addressing. With multi-addressing, the host can
assign an unlimited supply of addresses to make them available for local
applicaitons without requiring coordination with any other nodes.This approach is applicable to a wide variety of use cases. For
example, it can be used to coordinate the Virtual Private Network (VPN)
interfaces of mobile devices (e.g., cellphones, tablets, laptop
computers, etc.) that connect into a home enterprise network via public
access networks. In that case, the mobile device can assign addresses
taken from prefix 'P' to the VPN interface so that applications would
work the same as for a simple host connected to a LAN. The approach can
also be applied to aviation applications for both manned and unmanned
aircraft where the aircraft is treated as a mobile host that needs to
maintain stable IPv6 addresses even as it hands off between available
aviation data links across various phases of flight. The approach
further applies to any prefix delegation use case where the prefix
recipient wishes to act as a simple host, for example a cellular service
customer device that receives a prefix delegation from their service
provider.The following sections present multi-addressing considerations for
hosts that employ prefix delegation mechanisms.The terminology of the normative references apply. The following
terms are defined for the purposes of this document:an IPv6 prefix that may be
advertised to more than one node on the same link, e.g., in a Prefix
Information Option (PIO) included in a Router Advertisement (RA)
message . The shared prefix property applies
not only on multi-access links (e.g., Ethernet), but also on
point-to-point links where the shared prefix is visible to both ends
of the link.a prefix that is delegated
to a requesting node solely for its own use, and is not delegated to
any other nodes on the link.IPv6 allows nodes to assign multiple addresses to a single interface.
discusses options
for multi-addressing as well as use cases where multi-addressing may be
desirable. Address configuration options for multi-addressing include
SLAAC , stateful DHCPv6 address configuration
and any other address formation methods (e.g.,
manual configuration).Nodes that use SLAAC and DHCPv6 address configuration configure
addresses from a shared prefix and assign them to the link over which
the prefix was received. When this happens, the node is obliged to use
Multicast Listener Discovery (MLD) to join the appropriate
solicited-node multicast group(s) and to use the Duplicate Address
Detection (DAD) algorithm to ensure that no
other node that receives the shared prefix configures a duplicate
address.In contrast, a node that uses address configuration from a delegated
prefix can assign addresses to the interface over which the prefix is
received without invoking MLD/DAD, since the prefix has been delegated
to the node for its own exclusive use and is not shared with any other
nodes.When a node receives a prefix delegation, it has many alternatives
for the way in which it can provision the prefix. 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
more 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 sub-delegate
the prefix to its LAN interfaces and configure one or more addresses for
itself on a LAN interface. The node also 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 accodring to the weak end system model 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 for multi-addressing purposes. In a first alternative,
the node can receive the prefix acting as a requesting node 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 node over the WAN interface but then 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 as shown in .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.When a node configures addresses for itself using either SLAAC or
DHCPv6 from a shared prefix, the node performs MLD/DAD by sending
multicast messages to test whether there is another node on the link
that configures a duplicate address from the shared prefix. 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 arbitrarily many addresses can be assigned without causing
any multicast messaging over the WAN link that could disturb other
nodes. Note however that nodes that assign addresses directly to the WAN
interface must be capable of disabling MLD/DAD on the WAN interface,
i.e., by setting DupAddrDetectTransmits to zero .The node acts as a simple host to send Router Solicitation messages
over the WAN interface the same as described in Section 4.2 of .In order to maintain the appearance of a router (i.e., even though it
is acting as a simple host), the node sets the "Router" flag to TRUE in
any Neighbor Advertisement messages it sends. This ensures that the
"isRouter" flag in the neighbor cache entries of any neighbors remains
TRUE.The node initially has only a default route pointing to a router on
the WAN link. This means that packets sent over the node's WAN interface
will initially go through a default router even if there is a better
first-hop node on the link. In that case,a Redirect message can update
the node's neighbor cache, 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 .In some instances, a node may receive both delegated and shared
prefixes. In that case, the node could avoid MLD/DAD for addresses
configured from the delegated prefixes and employ MLD/DAD for addresses
configured from he shared prefixes. Note however that since
DupAddrDetectTransmits applies on a per-interface (and not a per-prefix)
basis any such considerations are out of scope since this document does
not update any standards-track specifications.This document introduces no IANA considerations.Security considerations are the same as specified for DHCPv6 Prefix
Delegation in .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. Ricardo Pelaez-Negro, Edwin
Cordeiro, Fred Baker and Naveen Lakshman provided useful comments that
have greatly improved the draft.