< draft-templin-v6ops-pdhost-13.txt   draft-templin-v6ops-pdhost-14.txt >
Network Working Group F. Templin, Ed. Network Working Group F. Templin, Ed.
Internet-Draft Boeing Research & Technology Internet-Draft Boeing Research & Technology
Intended status: Informational October 2, 2017 Intended status: Informational October 11, 2017
Expires: April 5, 2018 Expires: April 14, 2018
IPv6 Prefix Delegation for Hosts IPv6 Prefix Delegation for Hosts
draft-templin-v6ops-pdhost-13.txt draft-templin-v6ops-pdhost-14.txt
Abstract Abstract
IPv6 prefixes are typically delegated to requesting routers which IPv6 prefixes are typically delegated to requesting routers which
then use them to number their downstream-attached links and networks. then use them to number their downstream-attached links and networks.
This document considers the case when the requesting router is a node This document considers the case when the requesting router is a node
that acts as a host on behalf of its local applications and as a that acts as a host on behalf of its local applications and as a
router on behalf of any downstream networks. router on behalf of any downstream networks.
Status of This Memo Status of This Memo
skipping to change at page 1, line 34 skipping to change at page 1, line 34
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 5, 2018. This Internet-Draft will expire on April 14, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 12 skipping to change at page 2, line 12
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Multi-Addressing Considerations . . . . . . . . . . . . . . . 6 3. Multi-Addressing Considerations . . . . . . . . . . . . . . . 6
4. Multi-Addressing Alternatives for Delegated Prefixes . . . . 6 4. Multi-Addressing Alternatives for Delegated Prefixes . . . . 6
5. MLD/DAD Implications . . . . . . . . . . . . . . . . . . . . 7 5. MLD/DAD Implications . . . . . . . . . . . . . . . . . . . . 7
6. Dynamic Routing Protocol Implications . . . . . . . . . . . . 7 6. Dynamic Routing Protocol Implications . . . . . . . . . . . . 8
7. IPv6 Neighbor Discovery Implications . . . . . . . . . . . . 8 7. IPv6 Neighbor Discovery Implications . . . . . . . . . . . . 8
8. ICMPv6 Implications . . . . . . . . . . . . . . . . . . . . . 8 8. ICMPv6 Implications . . . . . . . . . . . . . . . . . . . . . 8
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
10. Security Considerations . . . . . . . . . . . . . . . . . . . 9 10. Security Considerations . . . . . . . . . . . . . . . . . . . 9
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
12.1. Normative References . . . . . . . . . . . . . . . . . . 10 12.1. Normative References . . . . . . . . . . . . . . . . . . 10
12.2. Informative References . . . . . . . . . . . . . . . . . 11 12.2. Informative References . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
IPv6 Prefix Delegation (PD) entails 1) the communication of a prefix IPv6 Prefix Delegation (PD) entails 1) the communication of a prefix
from a delegating router to a requesting router, 2) a representation from a delegating router to a requesting router, 2) a representation
of the prefix in the delegating router's routing table, and 3) a of the prefix in the delegating router's routing table, and 3) a
skipping to change at page 5, line 46 skipping to change at page 5, line 46
2. Terminology 2. Terminology
The terminology of the normative references apply, and the terms The terminology of the normative references apply, and the terms
"node", "host" and "router" are the same as defined in [RFC8200]. "node", "host" and "router" are the same as defined in [RFC8200].
The following terms are defined for the purposes of this document: The following terms are defined for the purposes of this document:
shared prefix shared prefix
an IPv6 prefix that may be advertised to more than one node on the an IPv6 prefix that may be advertised to more than one node on the
link, e.g., in a Router Advertisement (RA) message Prefix link, e.g., in a Router Advertisement (RA) message Prefix
Information Option (PIO) [RFC4861]. Information Option (PIO) [RFC4861]. The router that advertises
the prefix must consider the prefix as on-link so that the IPv6
Neighbor Discovery (ND) address resolution function will identify
the correct neighbor for each packet.
individual prefix individual prefix
an IPv6 prefix that is advertised to exactly one node on the link, an IPv6 prefix that is advertised to exactly one node on the link,
where the node may be unaware that the prefix is individual and where the node may be unaware that the prefix is individual and
may not participate in prefix maintenance procedures. An example may not participate in prefix maintenance procedures. The router
individual prefix service is documented in that advertises the prefix can consider the prefix as on-link or
not on-link. In the former case, the router performs address
resolution so that it only forwards those packets that match one
of the node's configured addresses. In the latter case, the
router can simply forward all packets matching the prefix to the
node. An example individual prefix service is documented in
[I-D.ietf-v6ops-unique-ipv6-prefix-per-host]. [I-D.ietf-v6ops-unique-ipv6-prefix-per-host].
delegated prefix delegated prefix
an IPv6 prefix that is explicitly delegated to a node for its own an IPv6 prefix that is explicitly delegated to a node for its own
exclusive use, where the node is an active participant in prefix exclusive use, where the node is an active participant in prefix
delegation and maintenance procedures. An example IPv6 PD service delegation and maintenance procedures. The router that delegates
is the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) the prefix simply forwards all packets matching the prefix to the
[RFC3315][RFC3633]. An alternative service based solely on IPv6 node. An example IPv6 PD service is the Dynamic Host
Neighbor Discovery (ND) messaging has also been proposed Configuration Protocol for IPv6 (DHCPv6) [RFC3315][RFC3633]. An
[I-D.pioxfolks-6man-pio-exclusive-bit]. alternative service based solely on IPv6 ND messaging has also
been proposed [I-D.pioxfolks-6man-pio-exclusive-bit].
3. Multi-Addressing Considerations 3. Multi-Addressing Considerations
IPv6 allows nodes to assign multiple addresses to a single interface. IPv6 allows nodes to assign multiple addresses to a single interface.
[RFC7934] discusses options for multi-addressing as well as use cases [RFC7934] discusses options for multi-addressing as well as use cases
where multi-addressing may be desirable. Address configuration where multi-addressing may be desirable. Address configuration
options for multi-addressing include StateLess Address options for multi-addressing include StateLess Address
AutoConfiguration (SLAAC) [RFC4862], DHCPv6 address configuration AutoConfiguration (SLAAC) [RFC4862], DHCPv6 address configuration
[RFC3315], manual configuration, etc. [RFC3315], manual configuration, etc.
skipping to change at page 7, line 43 skipping to change at page 8, line 7
When a node configures addresses for itself from a delegated prefix, When a node configures addresses for itself from a delegated prefix,
it can configure as many addresses as it wants but does not perform it can configure as many addresses as it wants but does not perform
MLD/DAD for any of the addresses over upstream interfaces. This MLD/DAD for any of the addresses over upstream interfaces. This
means that the node can configure arbitrarily many addresses without means that the node can configure arbitrarily many addresses without
causing any multicast messaging over the upstream interface that causing any multicast messaging over the upstream interface that
could disturb other nodes. could disturb other nodes.
6. Dynamic Routing Protocol Implications 6. Dynamic Routing Protocol Implications
The node can be configured to either participate or not participate Nodes that receive delegated prefixes can be configured to either
in a dynamic routing protocol over the upstream interface, according participate or not participate in a dynamic routing protocol over the
to the deployment model. When there are many nodes on the upstream upstream interface, according to the deployment model. When there
link, dynamic routing protocol participation might be impractical due are many nodes on the upstream link, dynamic routing protocol
to scaling limitations, and may also be exacerbated by factors such participation might be impractical due to scaling limitations, and
as node mobility. may also be exacerbated by factors such as node mobility.
Unless it participates in a dynamic routing protocol, the node Unless it participates in a dynamic routing protocol, the node
initially has only a default route pointing to a neighbor via an initially has only a default route pointing to a neighbor via an
upstream interface. This means that packets sent by the node over an upstream interface. This means that packets sent by the node over an
upstream interface will initially go through a default router even if upstream interface will initially go through a default router even if
there is a better first-hop node on the link. there is a better first-hop node on the link.
7. IPv6 Neighbor Discovery Implications 7. IPv6 Neighbor Discovery Implications
The node acts as a simple host to send Router Solicitation (RS) When a node receives a shared or individual prefix, it is required to
messages over upstream interfaces (i.e., the same as described in use the IPv6 ND address resolution function over the upstream
Section 4.2 of [RFC7084]) but also sets the "Router" flag to TRUE in interface to determine the link-layer address of a neighbor that
its Neighbor Advertisement messages. The node considers the upstream configures a target address within the prefix. For shared prefixes,
interfaces as non-advertising interfaces [RFC4861], i.e., it does not the neighbor that configures the target address will respond to the
send RA messages over the upstream interfaces. address resolution request. For individual prefixes, no neighbor
will configure the target address so that the address resolution
requests will go unanswered.
The current first-hop router may send a Redirect message that updates When a node receives a delegated prefix, it acts as a simple host to
the node's neighbor cache so that future packets can use a better send Router Solicitation (RS) messages over upstream interfaces
first-hop node on the link. The Redirect can apply either to a (i.e., the same as described in Section 4.2 of [RFC7084]) but also
singleton destination address, or to an entire destination prefix as sets the "Router" flag to TRUE in its Neighbor Advertisement
described in [I-D.templin-6man-rio-redirect]. messages. The node considers the upstream interfaces as non-
advertising interfaces [RFC4861], i.e., it does not send RA messages
over the upstream interfaces. The node further does not perform the
IPv6 ND address resolution function over upstream interfaces, since
the delegated prefix is explicitly not to be associated with an
upstream interface.
In all cases, the current first-hop router may send a Redirect
message that updates the node's neighbor cache so that future packets
can use a better first-hop node on the link. The Redirect can apply
either to a singleton destination address, or to an entire
destination prefix as described in [I-D.templin-6man-rio-redirect].
8. ICMPv6 Implications 8. ICMPv6 Implications
The Internet Control Message Protocol for IPv6 (ICMPv6) includes a The Internet Control Message Protocol for IPv6 (ICMPv6) includes a
set of control message types [RFC4443] including Destination set of control message types [RFC4443] including Destination
Unreachable (DU). Unreachable (DU).
According to [RFC4443], routers should return DU messages (subject to According to [RFC4443], routers should return DU messages (subject to
rate limiting) with code 0 ("No route to destination") when a packet rate limiting) with code 0 ("No route to destination") when a packet
arrives for which there is no matching entry in the routing table, arrives for which there is no matching entry in the routing table,
skipping to change at page 9, line 10 skipping to change at page 9, line 30
9. IANA Considerations 9. IANA Considerations
This document introduces no IANA considerations. This document introduces no IANA considerations.
10. Security Considerations 10. Security Considerations
Security considerations for IPv6 Neighbor Discovery [RFC4861] and any Security considerations for IPv6 Neighbor Discovery [RFC4861] and any
applicable PD mechanisms apply to this document. applicable PD mechanisms apply to this document.
Additionally, the node may receive unwanted IPv6 packets via an For shared and individual prefixes, if the router that advertises the
upstream interface that match a delegated prefix but do not match prefix considers the prefix as on-link the IPv6 ND address resolution
either a configured IPv6 address or a transport listener. In that function will prevent unwanted IPv6 packets from reaching the node.
case, the node drops the packets and observes the "Destination For delegated prefixes and individual prefixes that are not
Unreachable - Address/Port unreachable" procedures discussed in considered on-link, the router delivers all packets that match the
Section 8. prefix even if they do not match one of the node's configured
addresses. In the latter case, the node may receive unwanted IPv6
packets via an upstream interface that do not match either a
configured IPv6 address or a transport listener. In that case, the
node drops the packets and observes the "Destination Unreachable -
Address/Port unreachable" procedures discussed in Section 8.
The node may also receive IPv6 packets via an upstream interface that The node may also receive IPv6 packets via an upstream interface that
do not match any of the node's delegated prefixes. In that case, the do not match any of the node's delegated prefixes. In that case, the
node drops the packets and observes the "Destination Unreachable - No node drops the packets and observes the "Destination Unreachable - No
route to destination" procedures discussed in Section 8. Dropping route to destination" procedures discussed in Section 8. Dropping
the packets is necessary to avoid a reflection attack that would the packets is necessary to avoid a reflection attack that would
cause the node to forward packets received from an upstream interface cause the node to forward packets received from an upstream interface
via the same or a different upstream interface. via the same or a different upstream interface.
In all cases, the node must decide whether or not to send DUs In all cases, the node must decide whether or not to send DUs
skipping to change at page 9, line 38 skipping to change at page 10, line 14
potential correspondents. In untrusted networks, the node can potential correspondents. In untrusted networks, the node can
refrain from sending DU messages to avoid providing sensitive refrain from sending DU messages to avoid providing sensitive
information to potential attackers. information to potential attackers.
11. Acknowledgements 11. Acknowledgements
This work was motivated by discussions on the v6ops list. Mark Smith This work was motivated by discussions on the v6ops list. Mark Smith
pointed out the need to consider MLD as well as DAD for the pointed out the need to consider MLD as well as DAD for the
assignment of addresses to interfaces. Ricardo Pelaez-Negro, Edwin assignment of addresses to interfaces. Ricardo Pelaez-Negro, Edwin
Cordeiro, Fred Baker, Naveen Lakshman, Ole Troan, Bob Hinden, Brian Cordeiro, Fred Baker, Naveen Lakshman, Ole Troan, Bob Hinden, Brian
Carpenter, Joel Halpern and Albert Manfredi provided useful comments Carpenter, Joel Halpern, Albert Manfredi and Dusan Mudric provided
that have greatly improved the document. useful comments that have greatly improved the document.
This work is aligned with the NASA Safe Autonomous Systems Operation This work is aligned with the NASA Safe Autonomous Systems Operation
(SASO) program under NASA contract number NNA16BD84C. (SASO) program under NASA contract number NNA16BD84C.
This work is aligned with the FAA as per the SE2025 contract number This work is aligned with the FAA as per the SE2025 contract number
DTFAWA-15-D-00030. DTFAWA-15-D-00030.
This work is aligned with the Boeing Information Technology (BIT) This work is aligned with the Boeing Information Technology (BIT)
MobileNet program and the Boeing Research & Technology (BR&T) MobileNet program and the Boeing Research & Technology (BR&T)
enterprise autonomy program. enterprise autonomy program.
 End of changes. 14 change blocks. 
40 lines changed or deleted 67 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/