< draft-templin-6man-rio-redirect-07.txt   draft-templin-6man-rio-redirect-08.txt >
Network Working Group F. Templin, Ed. Network Working Group F. Templin, Ed.
Internet-Draft Boeing Research & Technology Internet-Draft Boeing Research & Technology
Updates: rfc4191 (if approved) J. Woodyatt Updates: rfc4191 (if approved) J. Woodyatt
Intended status: Standards Track Google Intended status: Standards Track Google
Expires: June 20, 2019 December 17, 2018 Expires: December 26, 2019 June 24, 2019
Route Information Options in IPv6 Neighbor Discovery Route Information Options in IPv6 Neighbor Discovery
draft-templin-6man-rio-redirect-07.txt draft-templin-6man-rio-redirect-08.txt
Abstract Abstract
The IPv6 Neighbor Discovery (ND) protocol allows nodes to discover The IPv6 Neighbor Discovery (ND) protocol allows nodes to discover
neighbors on the same link. Router Advertisement (RA) messages can neighbors on the same link. Router Advertisement (RA) messages can
also convey routing information by including a non-zero (default) also convey routing information by including a non-zero (default)
Router Lifetime, and/or Route Information Options (RIOs). This Router Lifetime, and/or Route Information Options (RIOs). This
document specifies backward-compatible extensions that permit nodes document specifies backward-compatible extensions that permit nodes
to include RIOs in other IPv6 ND messages to support the discovery of to include RIOs in other IPv6 ND messages to support the discovery of
more-specific routes among neighbors on the link. more-specific routes among neighbors on the link.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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 June 20, 2019. This Internet-Draft will expire on December 26, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 4, line 7 skipping to change at page 4, line 7
An example of a good application for RIO is the local-area subnets An example of a good application for RIO is the local-area subnets
served by the routers described in "Basic Requirements for IPv6 served by the routers described in "Basic Requirements for IPv6
Customer Edge Routers" [RFC7084]. While many customer edge routers Customer Edge Routers" [RFC7084]. While many customer edge routers
are capable of operating in a mode with a dynamic routing protocol are capable of operating in a mode with a dynamic routing protocol
operating in the local-area network, the default mode of operation is operating in the local-area network, the default mode of operation is
typically designed for unmanaged operation without any dynamic typically designed for unmanaged operation without any dynamic
routing protocol. On these networks, the only means for any node to routing protocol. On these networks, the only means for any node to
learn about routers on the link is by using the Router Discovery learn about routers on the link is by using the Router Discovery
protocol described in [RFC4861]. protocol described in [RFC4861].
Nevertheless, hosts on unmanaged home subnets may use "IPv6 Prefix Nevertheless, hosts on unmanaged home subnets may use prefix
Options for DHCPv6" [RFC3633] (DHCPv6 PD) to receive IPv6 routing delegation services such as DHCPv6 [RFC8415] to receive IPv6 routing
prefixes for additional subnets allocated from the space provided by prefixes for additional subnets allocated from the space provided by
the service provider, and operate as routers for other links where the service provider, and operate as routers for other links where
hosts in delegated subnets are attached. Hosts may even learn about hosts in delegated subnets are attached. Hosts may even learn about
more specific routes than the default route by processing RIOs in RA more specific routes than the default route by processing RIOs in RA
messages as described in [RFC4191]. messages as described in [RFC4191].
However, due to perceptions of the security considerations for hosts However, due to perceptions of the security considerations for hosts
in processing RIOs on unmanaged networks, the default configuration in processing RIOs on unmanaged networks, the default configuration
for common host IPv6 implementations is to ignore RIOs. Accordingly, for common host IPv6 implementations is to ignore RIOs. Accordingly,
on typical home networks the forwarding path from hosts on one subnet on typical home networks the forwarding path from hosts on one subnet
skipping to change at page 9, line 43 skipping to change at page 9, line 43
When the Source receives the NA message it can install any RIO When the Source receives the NA message it can install any RIO
information that matches the Redirect RIOs in its routing table. The information that matches the Redirect RIOs in its routing table. The
following sections present more detailed specifications for the following sections present more detailed specifications for the
Router, Source and Target. Router, Source and Target.
4.4.1. Router Specification 4.4.1. Router Specification
When the Router receives a packet from the Source it searches its When the Router receives a packet from the Source it searches its
routing table for a prefix that covers the destination address (e.g., routing table for a prefix that covers the destination address (e.g.,
2001:db8::/N as depicted in Figure 1), where prefix could be 2001:db8::/N as depicted in Figure 1), where prefix could be
populated in the routing table during DHCPv6 Prefix Delegation populated in the routing table during prefix delegation, via manual
[RFC3633], via manual configuration, etc. If the next hop for the configuration, etc. If the next hop for the prefix is on-link (i.e.,
prefix is on-link (i.e., a "Target" in the terms of [RFC4861]), the a "Target" in the terms of [RFC4861]), the Router then prepares a
Router then prepares a Redirect message with the Destination Address Redirect message with the Destination Address field set to the
field set to the packet's IPv6 destination address, with the Target packet's IPv6 destination address, with the Target Address field set
Address field set to the link-local address of the Target, with a to the link-local address of the Target, with a TLLAO set to the
TLLAO set to the link-layer address of the Target, and with an RIO link-layer address of the Target, and with an RIO that includes route
that includes route information for the prefix with Route Lifetime, information for the prefix with Route Lifetime, Prf, and S set to 0.
Prf, and S set to 0. The Router then sends the Redirect message to
the Source (subject to rate limiting). The Router then sends the Redirect message to the Source (subject to
rate limiting).
4.4.2. Source Specification 4.4.2. Source Specification
According to [RFC4861], a Source that receives a valid Redirect According to [RFC4861], a Source that receives a valid Redirect
message updates its destination cache per the Destination Address and message updates its destination cache per the Destination Address and
its neighbor cache per the Target Address. According to [RFC4191], its neighbor cache per the Target Address. According to [RFC4191],
Sources can be classified as Type "A", "B" or "C" based on how they Sources can be classified as Type "A", "B" or "C" based on how they
process RIOs, where a Type "C" Source updates its routing table per process RIOs, where a Type "C" Source updates its routing table per
any RIO elements included in an RA message. Finally, according to any RIO elements included in an RA message. Finally, according to
[RFC8028], a Type "C" Source operating on a Multi-Prefix Network with [RFC8028], a Type "C" Source operating on a Multi-Prefix Network with
skipping to change at page 16, line 19 skipping to change at page 16, line 19
<https://www.rfc-editor.org/info/rfc4443>. <https://www.rfc-editor.org/info/rfc4443>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
DOI 10.17487/RFC4861, September 2007, DOI 10.17487/RFC4861, September 2007,
<https://www.rfc-editor.org/info/rfc4861>. <https://www.rfc-editor.org/info/rfc4861>.
9.2. Informative References 9.2. Informative References
[I-D.templin-v6ops-pdhost] [I-D.templin-v6ops-pdhost]
Templin, F., "Multi-Addressing Considerations for IPv6 Templin, F., "IPv6 Prefix Delegation and Multi-Addressing
Prefix Delegation", draft-templin-v6ops-pdhost-21 (work in Models", draft-templin-v6ops-pdhost-23 (work in progress),
progress), June 2018. December 2018.
[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,
<https://www.rfc-editor.org/info/rfc3633>.
[RFC3756] Nikander, P., Ed., Kempf, J., and E. Nordmark, "IPv6 [RFC3756] Nikander, P., Ed., Kempf, J., and E. Nordmark, "IPv6
Neighbor Discovery (ND) Trust Models and Threats", Neighbor Discovery (ND) Trust Models and Threats",
RFC 3756, DOI 10.17487/RFC3756, May 2004, RFC 3756, DOI 10.17487/RFC3756, May 2004,
<https://www.rfc-editor.org/info/rfc3756>. <https://www.rfc-editor.org/info/rfc3756>.
[RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander,
"SEcure Neighbor Discovery (SEND)", RFC 3971, "SEcure Neighbor Discovery (SEND)", RFC 3971,
DOI 10.17487/RFC3971, March 2005, DOI 10.17487/RFC3971, March 2005,
<https://www.rfc-editor.org/info/rfc3971>. <https://www.rfc-editor.org/info/rfc3971>.
skipping to change at page 17, line 25 skipping to change at page 17, line 20
[RFC7934] Colitti, L., Cerf, V., Cheshire, S., and D. Schinazi, [RFC7934] Colitti, L., Cerf, V., Cheshire, S., and D. Schinazi,
"Host Address Availability Recommendations", BCP 204, "Host Address Availability Recommendations", BCP 204,
RFC 7934, DOI 10.17487/RFC7934, July 2016, RFC 7934, DOI 10.17487/RFC7934, July 2016,
<https://www.rfc-editor.org/info/rfc7934>. <https://www.rfc-editor.org/info/rfc7934>.
[RFC8028] Baker, F. and B. Carpenter, "First-Hop Router Selection by [RFC8028] Baker, F. and B. Carpenter, "First-Hop Router Selection by
Hosts in a Multi-Prefix Network", RFC 8028, Hosts in a Multi-Prefix Network", RFC 8028,
DOI 10.17487/RFC8028, November 2016, DOI 10.17487/RFC8028, November 2016,
<https://www.rfc-editor.org/info/rfc8028>. <https://www.rfc-editor.org/info/rfc8028>.
[RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
Richardson, M., Jiang, S., Lemon, T., and T. Winters,
"Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
RFC 8415, DOI 10.17487/RFC8415, November 2018,
<https://www.rfc-editor.org/info/rfc8415>.
Appendix A. Link-layer Address Changes Appendix A. Link-layer Address Changes
Type "D" hosts send unsolicited NAs to announce link-layer address Type "D" hosts send unsolicited NAs to announce link-layer address
changes per standard neighbor discovery [RFC4861]. Link-layer changes per standard neighbor discovery [RFC4861]. Link-layer
address changes may be due to localized factors such as hot-swap of address changes may be due to localized factors such as hot-swap of
an interface card, but could also occur during movement to a new an interface card, but could also occur during movement to a new
point of attachment on the same link. point of attachment on the same link.
Appendix B. Interfaces with Multiple Link-Layer Addresses Appendix B. Interfaces with Multiple Link-Layer Addresses
Type "D" host interfaces may have multiple connections to the link; Type "D" host interfaces may have multiple connections to the link;
each with its own link-layer address. Type "D" nodes can therefore each with its own link-layer address. Type "D" nodes can therefore
include multiple link-layer address options in IPv6 ND messages. include multiple link-layer address options in IPv6 ND messages.
Neighbors that receive these messages can cache and select link-layer Neighbors that receive these messages can cache and select link-layer
addresses in a manner outside the scope of this specification. addresses in a manner outside the scope of this specification.
Appendix C. Change Log Appendix C. Change Log
<< RFC Editor - remove prior to publication >> << RFC Editor - remove prior to publication >>
Changes from -07 to -08:
o Changed DHCPv6 Prefix Delegation reference to RFC8415.
Changes from -06 to -07: Changes from -06 to -07:
o Fixed spelling and grammar. o Fixed spelling and grammar.
Changes from -05 to -06: Changes from -05 to -06:
o Minor adjustments to text and requirements. o Minor adjustments to text and requirements.
Changes from -04 to -05: Changes from -04 to -05:
 End of changes. 9 change blocks. 
24 lines changed or deleted 30 lines changed or added

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