draft-ietf-v6ops-ipv6rtr-reqs-00.txt   draft-ietf-v6ops-ipv6rtr-reqs-01.txt 
Network Working Group Z. Kahn, Ed. Network Working Group Z. Kahn, Ed.
Internet-Draft LinkedIn Internet-Draft LinkedIn
Intended status: Informational J. Brzozowski, Ed. Intended status: Informational J. Brzozowski, Ed.
Expires: November 6, 2017 Comcast Expires: July 6, 2018 Comcast
R. White, Ed. R. White, Ed.
LinkedIn LinkedIn
May 5, 2017 January 2, 2018
Requirements for IPv6 Routers Requirements for IPv6 Routers
draft-ietf-v6ops-ipv6rtr-reqs-00 draft-ietf-v6ops-ipv6rtr-reqs-01
Abstract Abstract
The Internet is not one network, but rather a collection of networks. The Internet is not one network, but rather a collection of networks.
The interconnected nature of these networks, and the nature of the The interconnected nature of these networks, and the nature of the
interconneted systems that make up these networks, is often more interconneted systems that make up these networks, is often more
fragile than it appears. Perhaps "robust but fragile" is an fragile than it appears. Perhaps "robust but fragile" is an
overstatement, but the actions of each vendor, implementor, and overstatement, but the actions of each vendor, implementor, and
operator in such an interconneted environment can have a major impact operator in such an interconneted environment can have a major impact
on the stability of the overall Internet (as a system). The on the stability of the overall Internet (as a system). The
skipping to change at page 1, line 44 skipping to change at page 1, line 44
operators in effective IPv6 deployment. operators in effective IPv6 deployment.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 http://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 November 6, 2017. This Internet-Draft will expire on July 6, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 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
(http://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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
skipping to change at page 2, line 39 skipping to change at page 2, line 39
2.2.1. Elegance . . . . . . . . . . . . . . . . . . . . . . 6 2.2.1. Elegance . . . . . . . . . . . . . . . . . . . . . . 6
2.2.2. Tradeoffs . . . . . . . . . . . . . . . . . . . . . . 7 2.2.2. Tradeoffs . . . . . . . . . . . . . . . . . . . . . . 7
2.3. Layered Structure . . . . . . . . . . . . . . . . . . . . 8 2.3. Layered Structure . . . . . . . . . . . . . . . . . . . . 8
2.4. Routers . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.4. Routers . . . . . . . . . . . . . . . . . . . . . . . . . 9
3. Requirements Related to Device Management and Security . . . 11 3. Requirements Related to Device Management and Security . . . 11
3.1. Programmable Device Access . . . . . . . . . . . . . . . 11 3.1. Programmable Device Access . . . . . . . . . . . . . . . 11
3.2. Human Readable Device Access . . . . . . . . . . . . . . 12 3.2. Human Readable Device Access . . . . . . . . . . . . . . 12
3.3. Supporting Zero Touch Provisioning for Connected Devices 12 3.3. Supporting Zero Touch Provisioning for Connected Devices 12
3.4. Device Protection against Denial of Service Attacks . . . 13 3.4. Device Protection against Denial of Service Attacks . . . 13
4. Requirements Related to Telemetry . . . . . . . . . . . . . . 14 4. Requirements Related to Telemetry . . . . . . . . . . . . . . 14
4.1. Device State and Traceablity . . . . . . . . . . . . . . 14 4.1. Device State and Traceablity . . . . . . . . . . . . . . 15
4.2. Topology State and Traceability . . . . . . . . . . . . . 15 4.2. Topology State and Traceability . . . . . . . . . . . . . 15
5. Requirements Related to IPv6 Forwarding and Addressing . . . 15 5. Requirements Related to IPv6 Forwarding and Addressing . . . 16
5.1. The IPv6 Address is not a Host Identifier . . . . . . . . 16 5.1. The IPv6 Address is not a Host Identifier . . . . . . . . 16
5.2. Router IPv6 Addresseses . . . . . . . . . . . . . . . . . 16 5.2. Router IPv6 Addresseses . . . . . . . . . . . . . . . . . 16
5.3. The Maximum Transmission Unit . . . . . . . . . . . . . . 17 5.3. The Maximum Transmission Unit . . . . . . . . . . . . . . 17
5.4. ICMP Considerations . . . . . . . . . . . . . . . . . . . 19 5.4. ICMP Considerations . . . . . . . . . . . . . . . . . . . 19
5.5. Machine Access to the Forwarding Table . . . . . . . . . 20 5.5. Machine Access to the Forwarding Table . . . . . . . . . 20
5.6. Processing IPv6 Extension Headers . . . . . . . . . . . . 20 5.6. Processing IPv6 Extension Headers . . . . . . . . . . . . 20
5.7. IPv6 Only Operation . . . . . . . . . . . . . . . . . . . 20 5.7. IPv6 Operation by Default . . . . . . . . . . . . . . . . 20
5.8. Prefix Length Handling in IPv6 PAcket Forwarding . . . . 21 5.8. IPv6 Only Operation . . . . . . . . . . . . . . . . . . . 21
5.9. Prefix Length Handling in IPv6 Packet Forwarding . . . . 21
5.10. IPv6 Mobility Support . . . . . . . . . . . . . . . . . . 21
6. Security Considerations . . . . . . . . . . . . . . . . . . . 21 6. Security Considerations . . . . . . . . . . . . . . . . . . . 21
6.1. Robustness and Security . . . . . . . . . . . . . . . . . 21 6.1. Robustness and Security . . . . . . . . . . . . . . . . . 22
6.2. Programmable Device Access and Security . . . . . . . . . 22 6.2. Programmable Device Access and Security . . . . . . . . . 22
6.3. Zero Touch Provisioning and Security . . . . . . . . . . 22 6.3. Zero Touch Provisioning and Security . . . . . . . . . . 23
7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 22 6.4. Defaulting to IPv6 Forwarding and Security . . . . . . . 23
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 23
8.1. Normative References . . . . . . . . . . . . . . . . . . 22 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
8.1. Normative References . . . . . . . . . . . . . . . . . . 23
8.2. Informative References . . . . . . . . . . . . . . . . . 23 8.2. Informative References . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30
1. Introduction 1. Introduction
This memo defines and discusses requirements for devices that perform This memo defines and discusses requirements for devices that perform
forwarding for Internet Protocol version 6 (IPv6). This can include forwarding for Internet Protocol version 6 (IPv6). This can include
(but is not limited to) the devices described below. (but is not limited to) the devices described below.
o Devices which are primarily designed to forward traffic between o Devices which are primarily designed to forward traffic between
multiple interfaces. These are normally referred to by the multiple interfaces. These are normally referred to by the
Internet community as routers or, in some cases, intermediate Internet community as routers or, in some cases, intermediate
skipping to change at page 4, line 7 skipping to change at page 4, line 7
rather than substantive differences. rather than substantive differences.
This document is broken into the following sections: a review of This document is broken into the following sections: a review of
Internet architecture and principles, requirements relating to device Internet architecture and principles, requirements relating to device
management, requirements related to telemetry, requirements related management, requirements related to telemetry, requirements related
to IPv6 forwarding and addressing, and future considerations. to IPv6 forwarding and addressing, and future considerations.
Following these sections, a short conclusion is provided for review. Following these sections, a short conclusion is provided for review.
1.1. Contributors 1.1. Contributors
Shawn Zandi, Pete Lumbis, Fred Baker, and Lee Howard contributed Shawn Zandi, Pete Lumbis, Fred Baker, James Woodyatt and Lee Howard
significant text and ideas to this draft. contributed significant text and ideas to this draft.
1.2. Acknowledgements 1.2. Acknowledgements
The editors and contributors would like to thank Ron Bonica, Lorenzo The editors and contributors would like to thank Ron Bonica, Lorenzo
Coitti, Brian E. Carpenter, Tim Chown, Peter Lothberg, and ... for Coitti, Brian E. Carpenter, Tim Chown, Peter Lothberg, and ... for
their comments, edits, and ideas on the text of this draft. their comments, edits, and ideas on the text of this draft.
2. Review of the Internet Architecture 2. Review of the Internet Architecture
The Internet relies on a number of basic concepts and considerations. The Internet relies on a number of basic concepts and considerations.
skipping to change at page 12, line 39 skipping to change at page 12, line 39
o All network devices supporting IPv6 MUST support Ethernet console o All network devices supporting IPv6 MUST support Ethernet console
access access
3.3. Supporting Zero Touch Provisioning for Connected Devices 3.3. Supporting Zero Touch Provisioning for Connected Devices
To operate a network at scale, operators rely on protocols and To operate a network at scale, operators rely on protocols and
mechanisms that reduce provisioning time to a minimum. The preferred mechanisms that reduce provisioning time to a minimum. The preferred
state is zero touch provisioning; plug a new router in and it just state is zero touch provisioning; plug a new router in and it just
works without any manual configuration. The closer an operator can works without any manual configuration. The closer an operator can
come to this ideal, the more MTBM and Operational Expenses (OPEX) can come to this ideal, the more MTBM and Operational Expenses (OPEX) can
be reduced -- an important goals in the real world. IPv6 routers be reduced -- important goals in the real world. IPv6 routers should
should support several standards, including, but not limited to: support several standards, including, but not limited to:
o [I-D.ietf-dhc-rfc3315bis]: Dynamic Configuration Protocol for IPv6 o [I-D.ietf-dhc-rfc3315bis]: Dynamic Configuration Protocol for IPv6
MUST be supported. SLAAC MUST be able to be disabled by operators MUST be supported. SLAAC MUST be able to be disabled by operators
who prefer to use some other mechanism for address management and who prefer to use some other mechanism for address management and
assignment (specifically for customer facing edge ports). assignment (specifically for customer facing edge ports).
o [RFC4862]: IPv6 Stateless Address Autoconfiguration (SLAAC) MUST o [RFC4862]: IPv6 Stateless Address Autoconfiguration (SLAAC) MUST
be supported, and MUST be enabled by default on all router be supported, and MUST be enabled by default on all router
interfaces. interfaces.
o [RFC7217]: Semantically Opaque Interface Identifiers SHOULD be o [RFC7217]: Semantically Opaque Interface Identifiers SHOULD be
supported. supported.
o [RFC7934]: Host Address Availability, the ability to assign
multiple addresses to a host, SHOULD be supported.
o [RFC7527]: Enhanced Duplicate Address Detection MUST be supported. o [RFC7527]: Enhanced Duplicate Address Detection MUST be supported.
o [RFC8028]: First-Hop Router Selection by Hosts, specifically o [RFC8028]: First-Hop Router Selection by Hosts, specifically
section 2.1, which says a router SHOULD be able to send a PIO with section 2.1, which says a router SHOULD be able to send a PIO with
both the L and A bits cleared. both the L and A bits cleared.
o [RFC3810]: Routers supporting IPv6 MUST support Multicast Listener o [RFC3810]: Routers supporting IPv6 MUST support Multicast Listener
Discovery Version 2 Discovery Version 2
o [RFC7772]: Routers supporting IPv6 SHOULD support Reducing Energy
Consumption of Router Advertisements
o [RFC8273]: Routers supporting IPv6 SHOULD support Unique IPv6
Prefix per Host
The provisioning of Domain Name Systems (DNS) system information is a The provisioning of Domain Name Systems (DNS) system information is a
contentious topic, based on provider, operating system, interface, contentious topic, based on provider, operating system, interface,
and other requirements. This document therefore addresses the and other requirements. This document therefore addresses the
mechanisms that must be included in IPv6 router implementations, but mechanisms that must be included in IPv6 router implementations, but
leaves the option of what to configure and deploy to the network leaves the option of what to configure and deploy to the network
operator. Routers supporting IPv6, and intended for user facing operator. Routers supporting IPv6, and intended for user facing
connections, MUST support: connections, MUST support:
o [RFC3646]: DNS Configuration options for Dynamic Host o [RFC3646]: DNS Configuration options for Dynamic Host
Configuration Protocol for IPv6 (DHCPv6). Configuration Protocol for IPv6 (DHCPv6).
skipping to change at page 19, line 7 skipping to change at page 19, line 15
The general rule of thumb is to assume the largest size MTU should be The general rule of thumb is to assume the largest size MTU should be
used on higher speed transit only links in order to support a wide used on higher speed transit only links in order to support a wide
array of available link sizes, default MTUs, and tunnel array of available link sizes, default MTUs, and tunnel
encapsulations. Routers designed for a network core, data center encapsulations. Routers designed for a network core, data center
core, or use on the global Internet SHOULD support at least 9000 byte core, or use on the global Internet SHOULD support at least 9000 byte
MTUs on all interfaces. MTU detection mechanisms, such as IS-IS MTUs on all interfaces. MTU detection mechanisms, such as IS-IS
hello padding, described in [RFC7922], SHOULD be enabled to ensure hello padding, described in [RFC7922], SHOULD be enabled to ensure
correct point-to-point MTU configuration. Devices SHOULD also correct point-to-point MTU configuration. Devices SHOULD also
support: support:
o [RFC1981]: Path MTU Discovery for IP version 6 o [RFC8201]: Path MTU Discovery for IP version 6
o [RFC4821]: Packetization Layer Path MTU Discovery o [RFC4821]: Packetization Layer Path MTU Discovery
5.4. ICMP Considerations 5.4. ICMP Considerations
Internet Control Message Protocool (ICMP) is described in [RFC0792] Internet Control Message Protocool (ICMP) is described in [RFC0792]
and [RFC4443]. ICMP is often used to perform a traceroute through a and [RFC4443]. ICMP is often used to perform a traceroute through a
network (normally by using a TTL expired ICMP message), for Path MTU network (normally by using a TTL expired ICMP message), for Path MTU
discovery, and, in IPv6, for autoconfiguration and neighbor discovery, and, in IPv6, for autoconfiguration and neighbor
discovery. ICMP is often blocked by middleboxes of various kinds discovery. ICMP is often blocked by middleboxes of various kinds
skipping to change at page 19, line 29 skipping to change at page 19, line 37
network, most often to prevent the discovery of reachable hosts and network, most often to prevent the discovery of reachable hosts and
network topology. Routers implementing IPv6: network topology. Routers implementing IPv6:
o SHOULD NOT filter ICMP unreachables by default, as this has o SHOULD NOT filter ICMP unreachables by default, as this has
negative impacts on many aspects of IPv6 operation, particularly negative impacts on many aspects of IPv6 operation, particularly
path MTU path MTU
o SHOULD filter ICMP echo and echo response by default, to prevent o SHOULD filter ICMP echo and echo response by default, to prevent
the discovery of reachable hosts and topology. the discovery of reachable hosts and topology.
o SHOULD rate limit the generation of ICMP messages relative to the o SHOULD rate limit the generation of ICMP error messages with a
ability of the device to generate packets and to block the use of token bucket method as described in [RFC4443]. Rate limits SHOULD
ICMP packets being used as part of a distributed denial of service be narrow enough to (a) protect the device's ability to generate
attack packets and (b) reduce the usefulness of ICMP error packets as
part of a distributed denial of service attack. Limits SHOULD be
generous enough to allow successful path MTU discovery and
traceroute. For example, in a small/mid-size device, the possible
defaults could be bucket size=100, refill rate=100/s. Larger
devices can afford more generous rate limits.
o SHOULD implement the filtering suggestions in o SHOULD implement the filtering suggestions in
[I-D.gont-opsec-icmp-ingress-filtering] [I-D.gont-opsec-icmp-ingress-filtering]
o SHOULD NOT filter Destination Unreachable or Packet Too Big ICMP
error messages by default, as this has negative impacts on many
aspects of IPv6 operation, particularly path MTU discovery.
There are implications for path MTU discovery and other useful There are implications for path MTU discovery and other useful
mechanisms in filtering and rate limiting ICMP. The tradeoff here is mechanisms in filtering and rate limiting ICMP. The tradeoff here is
between allowing unlimited ICMP, which would allow path MTU detection between allowing unlimited ICMP, which would allow path MTU detection
to work, or limiting ICMP in a way that prevents negative side to work, or limiting ICMP in a way that prevents negative side
effects for individual devices, and hence the operational effects for individual devices, and hence the operational
capabilities of the network as a whole. Operators rightly limit ICMP capabilities of the network as a whole. Operators rightly limit ICMP
to reduce the attack surface against their network, as well as the to reduce the attack surface against their network, as well as the
opportinity for "perfect storm" events that inadvertently reduce the opportinity for "perfect storm" events that inadvertently reduce the
capability of routers and middleboxes. Hence ICMP can be treated as capability of routers and middleboxes. Hence ICMP can be treated as
"quasi-reliable" in many situations; existence of an ICMP message can "quasi-reliable" in many situations; existence of an ICMP message can
skipping to change at page 20, line 32 skipping to change at page 20, line 46
o [I-D.ietf-i2rs-rib-data-model]: A YANG Data Model for Routing o [I-D.ietf-i2rs-rib-data-model]: A YANG Data Model for Routing
Information Base (RIB) Information Base (RIB)
o [RFC7922]: I2RS Traceability o [RFC7922]: I2RS Traceability
5.6. Processing IPv6 Extension Headers 5.6. Processing IPv6 Extension Headers
(To be added) (To be added)
5.7. IPv6 Only Operation 5.7. IPv6 Operation by Default
If a device forwards and/or originates IPv4 packets by default
(without explicit configuration by the operator), it SHOULD forward
and/or originate IPv6 packets by default. See the security
considerations section below for reflections on the automatic
configuration of IPv6 forwarding in parallel with IPv4.
5.8. IPv6 Only Operation
While the transition to IPv6 only networks may take years (or perhaps While the transition to IPv6 only networks may take years (or perhaps
decades), a number of operators are moving to deploy IPv6 on internal decades), a number of operators are moving to deploy IPv6 on internal
networks supporting transport and data center fabric applications networks supporting transport and data center fabric applications
more quickly. Routers and middleboxes that support IPv6 SHOULD more quickly. Routers and middleboxes that support IPv6 SHOULD
support IPv6 only operation, including: support IPv6 only operation, including:
o Link Local addressing MUST be configurable and useable as the o Link Local addressing MUST be configurable and useable as the
primary address on all interfaces on a device. primary address on all interfaces on a device.
o IPv4 and/or MPLS SHOULD NOT be required for proper device o IPv4 and/or MPLS SHOULD NOT be required for proper device
operation. For instance, an IPv4 address should not be required operation. For instance, an IPv4 address should not be required
to determine the router ID for any protocol. See [RFC6540] to determine the router ID for any protocol. See [RFC6540]
section 2. section 2.
o Any control plane protocol implementations MUST support the o Any control plane protocol implementations MUST support the
recommendations in [RFC7404] for operation using link local recommendations in [RFC7404] for operation using link local
addresses only. addresses only.
5.8. Prefix Length Handling in IPv6 PAcket Forwarding 5.9. Prefix Length Handling in IPv6 Packet Forwarding
Routers MUST support IPv6 destination lookups in the forwarding Routers MUST support IPv6 destination lookups in the forwarding
process on a single bit prefix length increments, in accordance with process on a single bit prefix length increments, in accordance with
[RFC7608]. [RFC7608].
5.10. IPv6 Mobility Support
Mobile IPv6 [RFC6275] and associated specifications, including
[RFC3776] and [RFC4877] allow a node to change its point of
attachment within the Internet, while maintaining (and using) a
permanent address. All communication using the permanent address
continues to proceed as expected even as the node moves around. At
the present time, Mobile IP has seen only limited implementation.
More usage and deployment experience is needed with mobility before
any specific approach can be recommended for broad implementation in
hosts and routers. Consequently, routers MAY support [RFC6275] and
associated specifications (these specifications are not required for
IPv6 routers).
6. Security Considerations 6. Security Considerations
This document addresses several ways in which devices designed to This document addresses several ways in which devices designed to
support IPv6 forwarding. Some of the recommendations here are support IPv6 forwarding. Some of the recommendations here are
designed to increase device security; for instance, see the section designed to increase device security; for instance, see the section
on device access. Others may intersect with security, but are not on device access. Others may intersect with security, but are not
specifically targeted at security, such as running IPv6 link local specifically targeted at security, such as running IPv6 link local
only on links. These are not discussed further here, as they improve only on links. These are not discussed further here, as they improve
the security stance of the network. Other areas discussed in this the security stance of the network. Other areas discussed in this
draft are more nuanced. This section gathers the intersection draft are more nuanced. This section gathers the intersection
skipping to change at page 22, line 35 skipping to change at page 23, line 19
Zero touch provisioning opens a new attack surface; insider attackers Zero touch provisioning opens a new attack surface; insider attackers
can simply install a new device, and assume it will be autoconfigured can simply install a new device, and assume it will be autoconfigured
into the network. A "simple" solution would be to install door into the network. A "simple" solution would be to install door
locks, but this will likely not be enough; defenses need to be locks, but this will likely not be enough; defenses need to be
layered to be effective. It is recommended that devices installed in layered to be effective. It is recommended that devices installed in
the network need to contain a hardware or software identification the network need to contain a hardware or software identification
system that allows the operator to identify devices that are system that allows the operator to identify devices that are
installed in the network. installed in the network.
6.4. Defaulting to IPv6 Forwarding and Security
Operators should be aware that devices which forward IPv6 by default
can introduce a new attack surface or new threats without explicit
configuration. Operators SHOULD verify that IPv6 policies, including
filtering, match or fulfill the same intent as any existing IPv4
policies when deploying devices capable of forwarding both IPv4 and
IPv6.
7. Conclusion 7. Conclusion
The deployment of IPv6 throughout the Internet marks a point in time The deployment of IPv6 throughout the Internet marks a point in time
where it is good to review the overall Internet architecture, and where it is good to review the overall Internet architecture, and
assess the impact on operations of these changes. This document assess the impact on operations of these changes. This document
provides an overview of a lot of these changes and lessons learned, provides an overview of a lot of these changes and lessons learned,
as well as providing pointers to many of the relevant documents to as well as providing pointers to many of the relevant documents to
understand each topic more deeply. understand each topic more deeply.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
8.2. Informative References 8.2. Informative References
[COMPLEXHARD] [COMPLEXHARD]
Alderson, D. and J. Doyle, "Contrasting Views of Alderson, D. and J. Doyle, "Contrasting Views of
Complexity and Their Implications For Network-Centric Complexity and Their Implications For Network-Centric
Infrastructures", 2010, Infrastructures", 2010,
<http://ieeexplore.ieee.org/abstract/ <http://ieeexplore.ieee.org/abstract/
document/5477188/?reload=true>. document/5477188/?reload=true>.
skipping to change at page 23, line 40 skipping to change at page 24, line 38
[I-D.iab-protocol-transitions] [I-D.iab-protocol-transitions]
Thaler, D., "Planning for Protocol Adoption and Subsequent Thaler, D., "Planning for Protocol Adoption and Subsequent
Transitions", draft-iab-protocol-transitions-08 (work in Transitions", draft-iab-protocol-transitions-08 (work in
progress), March 2017. progress), March 2017.
[I-D.ietf-dhc-rfc3315bis] [I-D.ietf-dhc-rfc3315bis]
Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
Richardson, M., Jiang, S., Lemon, T., and T. Winters, Richardson, M., Jiang, S., Lemon, T., and T. Winters,
"Dynamic Host Configuration Protocol for IPv6 (DHCPv6) "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
bis", draft-ietf-dhc-rfc3315bis-07 (work in progress), bis", draft-ietf-dhc-rfc3315bis-10 (work in progress),
March 2017. September 2017.
[I-D.ietf-i2rs-fb-rib-data-model] [I-D.ietf-i2rs-fb-rib-data-model]
Hares, S., Kini, S., Dunbar, L., Krishnan, R., Bogdanovic, Hares, S., Kini, S., Dunbar, L., Krishnan, R., Bogdanovic,
D., and R. White, "Filter-Based RIB Data Model", draft- D., and R. White, "Filter-Based RIB Data Model", draft-
ietf-i2rs-fb-rib-data-model-01 (work in progress), March ietf-i2rs-fb-rib-data-model-01 (work in progress), March
2017. 2017.
[I-D.ietf-i2rs-fb-rib-info-model] [I-D.ietf-i2rs-fb-rib-info-model]
Kini, S., Hares, S., Dunbar, L., Ghanwani, A., Krishnan, Kini, S., Hares, S., Dunbar, L., Ghanwani, A., Krishnan,
R., Bogdanovic, D., and R. White, "Filter-Based RIB R., Bogdanovic, D., and R. White, "Filter-Based RIB
Information Model", draft-ietf-i2rs-fb-rib-info-model-00 Information Model", draft-ietf-i2rs-fb-rib-info-model-00
(work in progress), June 2016. (work in progress), June 2016.
[I-D.ietf-i2rs-rib-data-model] [I-D.ietf-i2rs-rib-data-model]
Wang, L., Ananthakrishnan, H., Chen, M., Wang, L., Ananthakrishnan, H., Chen, M.,
amit.dass@ericsson.com, a., Kini, S., and N. Bahadur, "A amit.dass@ericsson.com, a., Kini, S., and N. Bahadur, "A
YANG Data Model for Routing Information Base (RIB)", YANG Data Model for Routing Information Base (RIB)",
draft-ietf-i2rs-rib-data-model-07 (work in progress), draft-ietf-i2rs-rib-data-model-09 (work in progress),
January 2017. December 2017.
[I-D.ietf-i2rs-yang-l2-network-topology] [I-D.ietf-i2rs-yang-l2-network-topology]
Dong, J. and X. Wei, "A YANG Data Model for Layer-2 Dong, J. and X. Wei, "A YANG Data Model for Layer-2
Network Topologies", draft-ietf-i2rs-yang-l2-network- Network Topologies", draft-ietf-i2rs-yang-l2-network-
topology-03 (work in progress), July 2016. topology-03 (work in progress), July 2016.
[I-D.ietf-i2rs-yang-l3-topology] [I-D.ietf-i2rs-yang-l3-topology]
Clemm, A., Medved, J., Varga, R., Liu, X., Clemm, A., Medved, J., Varga, R., Liu, X.,
Ananthakrishnan, H., and N. Bahadur, "A YANG Data Model Ananthakrishnan, H., and N. Bahadur, "A YANG Data Model
for Layer 3 Topologies", draft-ietf-i2rs-yang- for Layer 3 Topologies", draft-ietf-i2rs-yang-
l3-topology-08 (work in progress), January 2017. l3-topology-16 (work in progress), December 2017.
[I-D.ietf-i2rs-yang-network-topo] [I-D.ietf-i2rs-yang-network-topo]
Clemm, A., Medved, J., Varga, R., Bahadur, N., Clemm, A., Medved, J., Varga, R., Bahadur, N.,
Ananthakrishnan, H., and X. Liu, "A Data Model for Network Ananthakrishnan, H., and X. Liu, "A Data Model for Network
Topologies", draft-ietf-i2rs-yang-network-topo-12 (work in Topologies", draft-ietf-i2rs-yang-network-topo-20 (work in
progress), March 2017. progress), December 2017.
[I-D.ietf-netconf-restconf] [I-D.ietf-netconf-restconf]
Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", draft-ietf-netconf-restconf-18 (work in Protocol", draft-ietf-netconf-restconf-18 (work in
progress), October 2016. progress), October 2016.
[LEAKYABS] [LEAKYABS]
Spolsky, J., "The Law of Leaky Abstractions", 2002, Spolsky, J., "The Law of Leaky Abstractions", 2002,
<https://www.joelonsoftware.com/2002/11/11/the-law-of- <https://www.joelonsoftware.com/2002/11/11/
leaky-abstractions/>. the-law-of-leaky-abstractions/>.
[OPENCONF] [OPENCONF]
OpenConfig, "Openconfig release YANG models", 2016, OpenConfig, "Openconfig release YANG models", 2016,
<https://github.com/openconfig/public/tree/master/ <https://github.com/openconfig/public/tree/master/
release>. release>.
[OSI] Wikipedia, "OSI Model", 2016, [OSI] Wikipedia, "OSI Model", 2016,
<https://en.wikipedia.org/wiki/OSI_model>. <https://en.wikipedia.org/wiki/OSI_model>.
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,
RFC 792, DOI 10.17487/RFC0792, September 1981, RFC 792, DOI 10.17487/RFC0792, September 1981,
<http://www.rfc-editor.org/info/rfc792>. <https://www.rfc-editor.org/info/rfc792>.
[RFC0854] Postel, J. and J. Reynolds, "Telnet Protocol [RFC0854] Postel, J. and J. Reynolds, "Telnet Protocol
Specification", STD 8, RFC 854, DOI 10.17487/RFC0854, May Specification", STD 8, RFC 854, DOI 10.17487/RFC0854, May
1983, <http://www.rfc-editor.org/info/rfc854>. 1983, <https://www.rfc-editor.org/info/rfc854>.
[RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", [RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers",
RFC 1812, DOI 10.17487/RFC1812, June 1995, RFC 1812, DOI 10.17487/RFC1812, June 1995,
<http://www.rfc-editor.org/info/rfc1812>. <https://www.rfc-editor.org/info/rfc1812>.
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
and E. Lear, "Address Allocation for Private Internets", and E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996,
<http://www.rfc-editor.org/info/rfc1918>. <https://www.rfc-editor.org/info/rfc1918>.
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery
for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August
1996, <http://www.rfc-editor.org/info/rfc1981>.
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
DOI 10.17487/RFC2629, June 1999, DOI 10.17487/RFC2629, June 1999,
<http://www.rfc-editor.org/info/rfc2629>. <https://www.rfc-editor.org/info/rfc2629>.
[RFC3439] Bush, R. and D. Meyer, "Some Internet Architectural [RFC3439] Bush, R. and D. Meyer, "Some Internet Architectural
Guidelines and Philosophy", RFC 3439, Guidelines and Philosophy", RFC 3439,
DOI 10.17487/RFC3439, December 2002, DOI 10.17487/RFC3439, December 2002,
<http://www.rfc-editor.org/info/rfc3439>. <https://www.rfc-editor.org/info/rfc3439>.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552, Text on Security Considerations", BCP 72, RFC 3552,
DOI 10.17487/RFC3552, July 2003, DOI 10.17487/RFC3552, July 2003,
<http://www.rfc-editor.org/info/rfc3552>. <https://www.rfc-editor.org/info/rfc3552>.
[RFC3627] Savola, P., "Use of /127 Prefix Length Between Routers [RFC3627] Savola, P., "Use of /127 Prefix Length Between Routers
Considered Harmful", RFC 3627, DOI 10.17487/RFC3627, Considered Harmful", RFC 3627, DOI 10.17487/RFC3627,
September 2003, <http://www.rfc-editor.org/info/rfc3627>. September 2003, <https://www.rfc-editor.org/info/rfc3627>.
[RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic [RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic
Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646,
DOI 10.17487/RFC3646, December 2003, DOI 10.17487/RFC3646, December 2003,
<http://www.rfc-editor.org/info/rfc3646>. <https://www.rfc-editor.org/info/rfc3646>.
[RFC3776] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to
Protect Mobile IPv6 Signaling Between Mobile Nodes and
Home Agents", RFC 3776, DOI 10.17487/RFC3776, June 2004,
<https://www.rfc-editor.org/info/rfc3776>.
[RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener
Discovery Version 2 (MLDv2) for IPv6", RFC 3810, Discovery Version 2 (MLDv2) for IPv6", RFC 3810,
DOI 10.17487/RFC3810, June 2004, DOI 10.17487/RFC3810, June 2004,
<http://www.rfc-editor.org/info/rfc3810>. <https://www.rfc-editor.org/info/rfc3810>.
[RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253,
January 2006, <http://www.rfc-editor.org/info/rfc4253>. January 2006, <https://www.rfc-editor.org/info/rfc4253>.
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
Control Message Protocol (ICMPv6) for the Internet Control Message Protocol (ICMPv6) for the Internet
Protocol Version 6 (IPv6) Specification", RFC 4443, Protocol Version 6 (IPv6) Specification", STD 89,
DOI 10.17487/RFC4443, March 2006, RFC 4443, DOI 10.17487/RFC4443, March 2006,
<http://www.rfc-editor.org/info/rfc4443>. <https://www.rfc-editor.org/info/rfc4443>.
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU
Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007,
<http://www.rfc-editor.org/info/rfc4821>. <https://www.rfc-editor.org/info/rfc4821>.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, Address Autoconfiguration", RFC 4862,
DOI 10.17487/RFC4862, September 2007, DOI 10.17487/RFC4862, September 2007,
<http://www.rfc-editor.org/info/rfc4862>. <https://www.rfc-editor.org/info/rfc4862>.
[RFC5218] Thaler, D. and B. Aboba, "What Makes For a Successful [RFC4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with
IKEv2 and the Revised IPsec Architecture", RFC 4877,
DOI 10.17487/RFC4877, April 2007,
<https://www.rfc-editor.org/info/rfc4877>.
[RFC5218] Thaler, D. and B. Aboba, "What Makes for a Successful
Protocol?", RFC 5218, DOI 10.17487/RFC5218, July 2008, Protocol?", RFC 5218, DOI 10.17487/RFC5218, July 2008,
<http://www.rfc-editor.org/info/rfc5218>. <https://www.rfc-editor.org/info/rfc5218>.
[RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424,
DOI 10.17487/RFC5424, March 2009, DOI 10.17487/RFC5424, March 2009,
<http://www.rfc-editor.org/info/rfc5424>. <https://www.rfc-editor.org/info/rfc5424>.
[RFC6164] Kohno, M., Nitzan, B., Bush, R., Matsuzaki, Y., Colitti, [RFC6164] Kohno, M., Nitzan, B., Bush, R., Matsuzaki, Y., Colitti,
L., and T. Narten, "Using 127-Bit IPv6 Prefixes on Inter- L., and T. Narten, "Using 127-Bit IPv6 Prefixes on Inter-
Router Links", RFC 6164, DOI 10.17487/RFC6164, April 2011, Router Links", RFC 6164, DOI 10.17487/RFC6164, April 2011,
<http://www.rfc-editor.org/info/rfc6164>. <https://www.rfc-editor.org/info/rfc6164>.
[RFC6177] Narten, T., Huston, G., and L. Roberts, "IPv6 Address [RFC6177] Narten, T., Huston, G., and L. Roberts, "IPv6 Address
Assignment to End Sites", BCP 157, RFC 6177, Assignment to End Sites", BCP 157, RFC 6177,
DOI 10.17487/RFC6177, March 2011, DOI 10.17487/RFC6177, March 2011,
<http://www.rfc-editor.org/info/rfc6177>. <https://www.rfc-editor.org/info/rfc6177>.
[RFC6192] Dugal, D., Pignataro, C., and R. Dunn, "Protecting the [RFC6192] Dugal, D., Pignataro, C., and R. Dunn, "Protecting the
Router Control Plane", RFC 6192, DOI 10.17487/RFC6192, Router Control Plane", RFC 6192, DOI 10.17487/RFC6192,
March 2011, <http://www.rfc-editor.org/info/rfc6192>. March 2011, <https://www.rfc-editor.org/info/rfc6192>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<http://www.rfc-editor.org/info/rfc6241>. <https://www.rfc-editor.org/info/rfc6241>.
[RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility
Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July
2011, <https://www.rfc-editor.org/info/rfc6275>.
[RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node [RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node
Requirements", RFC 6434, DOI 10.17487/RFC6434, December Requirements", RFC 6434, DOI 10.17487/RFC6434, December
2011, <http://www.rfc-editor.org/info/rfc6434>. 2011, <https://www.rfc-editor.org/info/rfc6434>.
[RFC6540] George, W., Donley, C., Liljenstolpe, C., and L. Howard, [RFC6540] George, W., Donley, C., Liljenstolpe, C., and L. Howard,
"IPv6 Support Required for All IP-Capable Nodes", BCP 177, "IPv6 Support Required for All IP-Capable Nodes", BCP 177,
RFC 6540, DOI 10.17487/RFC6540, April 2012, RFC 6540, DOI 10.17487/RFC6540, April 2012,
<http://www.rfc-editor.org/info/rfc6540>. <https://www.rfc-editor.org/info/rfc6540>.
[RFC7217] Gont, F., "A Method for Generating Semantically Opaque [RFC7217] Gont, F., "A Method for Generating Semantically Opaque
Interface Identifiers with IPv6 Stateless Address Interface Identifiers with IPv6 Stateless Address
Autoconfiguration (SLAAC)", RFC 7217, Autoconfiguration (SLAAC)", RFC 7217,
DOI 10.17487/RFC7217, April 2014, DOI 10.17487/RFC7217, April 2014,
<http://www.rfc-editor.org/info/rfc7217>. <https://www.rfc-editor.org/info/rfc7217>.
[RFC7223] Bjorklund, M., "A YANG Data Model for Interface [RFC7223] Bjorklund, M., "A YANG Data Model for Interface
Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, Management", RFC 7223, DOI 10.17487/RFC7223, May 2014,
<http://www.rfc-editor.org/info/rfc7223>. <https://www.rfc-editor.org/info/rfc7223>.
[RFC7224] Bjorklund, M., "IANA Interface Type YANG Module", [RFC7224] Bjorklund, M., "IANA Interface Type YANG Module",
RFC 7224, DOI 10.17487/RFC7224, May 2014, RFC 7224, DOI 10.17487/RFC7224, May 2014,
<http://www.rfc-editor.org/info/rfc7224>. <https://www.rfc-editor.org/info/rfc7224>.
[RFC7277] Bjorklund, M., "A YANG Data Model for IP Management", [RFC7277] Bjorklund, M., "A YANG Data Model for IP Management",
RFC 7277, DOI 10.17487/RFC7277, June 2014, RFC 7277, DOI 10.17487/RFC7277, June 2014,
<http://www.rfc-editor.org/info/rfc7277>. <https://www.rfc-editor.org/info/rfc7277>.
[RFC7317] Bierman, A. and M. Bjorklund, "A YANG Data Model for [RFC7317] Bierman, A. and M. Bjorklund, "A YANG Data Model for
System Management", RFC 7317, DOI 10.17487/RFC7317, August System Management", RFC 7317, DOI 10.17487/RFC7317, August
2014, <http://www.rfc-editor.org/info/rfc7317>. 2014, <https://www.rfc-editor.org/info/rfc7317>.
[RFC7404] Behringer, M. and E. Vyncke, "Using Only Link-Local [RFC7404] Behringer, M. and E. Vyncke, "Using Only Link-Local
Addressing inside an IPv6 Network", RFC 7404, Addressing inside an IPv6 Network", RFC 7404,
DOI 10.17487/RFC7404, November 2014, DOI 10.17487/RFC7404, November 2014,
<http://www.rfc-editor.org/info/rfc7404>. <https://www.rfc-editor.org/info/rfc7404>.
[RFC7527] Asati, R., Singh, H., Beebee, W., Pignataro, C., Dart, E., [RFC7527] Asati, R., Singh, H., Beebee, W., Pignataro, C., Dart, E.,
and W. George, "Enhanced Duplicate Address Detection", and W. George, "Enhanced Duplicate Address Detection",
RFC 7527, DOI 10.17487/RFC7527, April 2015, RFC 7527, DOI 10.17487/RFC7527, April 2015,
<http://www.rfc-editor.org/info/rfc7527>. <https://www.rfc-editor.org/info/rfc7527>.
[RFC7608] Boucadair, M., Petrescu, A., and F. Baker, "IPv6 Prefix [RFC7608] Boucadair, M., Petrescu, A., and F. Baker, "IPv6 Prefix
Length Recommendation for Forwarding", BCP 198, RFC 7608, Length Recommendation for Forwarding", BCP 198, RFC 7608,
DOI 10.17487/RFC7608, July 2015, DOI 10.17487/RFC7608, July 2015,
<http://www.rfc-editor.org/info/rfc7608>. <https://www.rfc-editor.org/info/rfc7608>.
[RFC7663] Trammell, B., Ed. and M. Kuehlewind, Ed., "Report from the [RFC7663] Trammell, B., Ed. and M. Kuehlewind, Ed., "Report from the
IAB Workshop on Stack Evolution in a Middlebox Internet IAB Workshop on Stack Evolution in a Middlebox Internet
(SEMI)", RFC 7663, DOI 10.17487/RFC7663, October 2015, (SEMI)", RFC 7663, DOI 10.17487/RFC7663, October 2015,
<http://www.rfc-editor.org/info/rfc7663>. <https://www.rfc-editor.org/info/rfc7663>.
[RFC7772] Yourtchenko, A. and L. Colitti, "Reducing Energy
Consumption of Router Advertisements", BCP 202, RFC 7772,
DOI 10.17487/RFC7772, February 2016,
<https://www.rfc-editor.org/info/rfc7772>.
[RFC7922] Clarke, J., Salgueiro, G., and C. Pignataro, "Interface to [RFC7922] Clarke, J., Salgueiro, G., and C. Pignataro, "Interface to
the Routing System (I2RS) Traceability: Framework and the Routing System (I2RS) Traceability: Framework and
Information Model", RFC 7922, DOI 10.17487/RFC7922, June Information Model", RFC 7922, DOI 10.17487/RFC7922, June
2016, <http://www.rfc-editor.org/info/rfc7922>. 2016, <https://www.rfc-editor.org/info/rfc7922>.
[RFC7934] Colitti, L., Cerf, V., Cheshire, S., and D. Schinazi,
"Host Address Availability Recommendations", BCP 204,
RFC 7934, DOI 10.17487/RFC7934, July 2016,
<https://www.rfc-editor.org/info/rfc7934>.
[RFC7980] Behringer, M., Retana, A., White, R., and G. Huston, "A [RFC7980] Behringer, M., Retana, A., White, R., and G. Huston, "A
Framework for Defining Network Complexity", RFC 7980, Framework for Defining Network Complexity", RFC 7980,
DOI 10.17487/RFC7980, October 2016, DOI 10.17487/RFC7980, October 2016,
<http://www.rfc-editor.org/info/rfc7980>. <https://www.rfc-editor.org/info/rfc7980>.
[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,
<http://www.rfc-editor.org/info/rfc8028>. <https://www.rfc-editor.org/info/rfc8028>.
[RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, [RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli,
"IPv6 Router Advertisement Options for DNS Configuration", "IPv6 Router Advertisement Options for DNS Configuration",
RFC 8106, DOI 10.17487/RFC8106, March 2017, RFC 8106, DOI 10.17487/RFC8106, March 2017,
<http://www.rfc-editor.org/info/rfc8106>. <https://www.rfc-editor.org/info/rfc8106>.
[RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed.,
"Path MTU Discovery for IP version 6", STD 87, RFC 8201,
DOI 10.17487/RFC8201, July 2017,
<https://www.rfc-editor.org/info/rfc8201>.
[RFC8273] Brzozowski, J. and G. Van de Velde, "Unique IPv6 Prefix
per Host", RFC 8273, DOI 10.17487/RFC8273, December 2017,
<https://www.rfc-editor.org/info/rfc8273>.
Authors' Addresses Authors' Addresses
Zaid Ali Kahn (editor) Zaid Ali Kahn (editor)
LinkedIn LinkedIn
xxx xxx
xxx, CA xxx xxx, CA xxx
USA USA
Email: zaid@linkedin.com Email: zaid@linkedin.com
 End of changes. 66 change blocks. 
80 lines changed or deleted 162 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/