draft-ietf-v6ops-ipv6rtr-reqs-01.txt   draft-ietf-v6ops-ipv6rtr-reqs-02.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: July 6, 2018 Comcast Expires: September 5, 2018 Comcast
R. White, Ed. R. White, Ed.
LinkedIn LinkedIn
January 2, 2018 March 4, 2018
Requirements for IPv6 Routers Requirements for IPv6 Routers
draft-ietf-v6ops-ipv6rtr-reqs-01 draft-ietf-v6ops-ipv6rtr-reqs-02
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 interconnected 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 interconnected environment can have a major
on the stability of the overall Internet (as a system). The impact on the stability of the overall Internet (as a system). The
widespread adoption of IPv6 could, particularly, disrupt network widespread adoption of IPv6 could, particularly, disrupt network
operations, in a way that impacts the entire system. operations, in a way that impacts the entire system.
This time of transition is an opportune time to take stock of lessons This time of transition is an opportune time to take stock of lessons
learned through the operation of large scale networks on IPv4, and learned through the operation of large scale networks on IPv4, and
consider how to apply these lessons to IPv6. This document provides consider how to apply these lessons to IPv6. This document provides
an overview of the design and architectural decisions that attend an overview of the design and architectural decisions that attend
IPv6 deployment, and a set of IPv6 requirements for routers, IPv6 deployment, and a set of IPv6 requirements for routers,
switches, and middleboxes deployed in IPv6 networks. The hope of the switches, and middleboxes deployed in IPv6 networks. The hope of the
editors and contributors is to provide the neccessary background to editors and contributors is to provide the necessary background to
guide equipment manufacturers, protocol implemenetors, and network guide equipment manufacturers, protocol implementors, and network
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 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 July 6, 2018. This Internet-Draft will expire on September 5, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 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
(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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Contributors . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Contributors . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Acknowledgements . . . . . . . . . . . . . . . . . . . . 4 1.2. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 4
2. Review of the Internet Architecture . . . . . . . . . . . . . 4 1.3. Use and Applicability . . . . . . . . . . . . . . . . . . 4
2.1. Robustness Principle . . . . . . . . . . . . . . . . . . 4 2. Review of the Internet Architecture . . . . . . . . . . . . . 5
2.2. Complexity . . . . . . . . . . . . . . . . . . . . . . . 6 2.1. Robustness Principle . . . . . . . . . . . . . . . . . . 5
2.2.1. Elegance . . . . . . . . . . . . . . . . . . . . . . 6 2.2. Complexity . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.2. Tradeoffs . . . . . . . . . . . . . . . . . . . . . . 7 2.2.1. Elegance . . . . . . . . . . . . . . . . . . . . . . 7
2.3. Layered Structure . . . . . . . . . . . . . . . . . . . . 8 2.2.2. Trade-offs . . . . . . . . . . . . . . . . . . . . . 8
2.4. Routers . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.3. Layered Structure . . . . . . . . . . . . . . . . . . . . 9
3. Requirements Related to Device Management and Security . . . 11 2.4. Routers . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1. Programmable Device Access . . . . . . . . . . . . . . . 11 3. Requirements Related to Device Management and Security . . . 12
3.2. Human Readable Device Access . . . . . . . . . . . . . . 12 3.1. Programmable Device Access . . . . . . . . . . . . . . . 12
3.3. Supporting Zero Touch Provisioning for Connected Devices 12 3.2. Human Readable Device Access . . . . . . . . . . . . . . 13
3.4. Device Protection against Denial of Service Attacks . . . 13 3.3. Supporting Zero Touch Provisioning for Connected Devices 13
4. Requirements Related to Telemetry . . . . . . . . . . . . . . 14 3.4. Device Protection against Denial of Service Attacks . . . 15
4.1. Device State and Traceablity . . . . . . . . . . . . . . 15 4. Requirements Related to Telemetry . . . . . . . . . . . . . . 15
4.2. Topology State and Traceability . . . . . . . . . . . . . 15 4.1. Device State and Traceablity . . . . . . . . . . . . . . 16
5. Requirements Related to IPv6 Forwarding and Addressing . . . 16 4.2. Topology State and Traceability . . . . . . . . . . . . . 16
5.1. The IPv6 Address is not a Host Identifier . . . . . . . . 16 4.3. Flow State and Traceability . . . . . . . . . . . . . . . 17
5.2. Router IPv6 Addresseses . . . . . . . . . . . . . . . . . 16 5. Requirements Related to IPv6 Forwarding and Addressing . . . 17
5.3. The Maximum Transmission Unit . . . . . . . . . . . . . . 17 5.1. The IPv6 Address is not a Host Identifier . . . . . . . . 17
5.4. ICMP Considerations . . . . . . . . . . . . . . . . . . . 19 5.2. Router IPv6 Addresses . . . . . . . . . . . . . . . . . . 18
5.5. Machine Access to the Forwarding Table . . . . . . . . . 20 5.3. The Maximum Transmission Unit . . . . . . . . . . . . . . 19
5.6. Processing IPv6 Extension Headers . . . . . . . . . . . . 20 5.4. ICMP Considerations . . . . . . . . . . . . . . . . . . . 20
5.7. IPv6 Operation by Default . . . . . . . . . . . . . . . . 20 5.5. Machine Access to the Forwarding Table . . . . . . . . . 21
5.8. IPv6 Only Operation . . . . . . . . . . . . . . . . . . . 21 5.6. Processing IPv6 Extension Headers . . . . . . . . . . . . 22
5.9. Prefix Length Handling in IPv6 Packet Forwarding . . . . 21 5.7. IPv6 Operation by Default . . . . . . . . . . . . . . . . 22
5.10. IPv6 Mobility Support . . . . . . . . . . . . . . . . . . 21 5.8. IPv6 Only Operation . . . . . . . . . . . . . . . . . . . 22
5.9. Prefix Length Handling in IPv6 Packet Forwarding . . . . 22
6. Security Considerations . . . . . . . . . . . . . . . . . . . 21 5.10. IPv6 Mobility Support . . . . . . . . . . . . . . . . . . 22
6.1. Robustness and Security . . . . . . . . . . . . . . . . . 22 6. Security Considerations . . . . . . . . . . . . . . . . . . . 23
6.2. Programmable Device Access and Security . . . . . . . . . 22 6.1. Robustness and Security . . . . . . . . . . . . . . . . . 23
6.3. Zero Touch Provisioning and Security . . . . . . . . . . 23 6.2. Programmable Device Access and Security . . . . . . . . . 24
6.4. Defaulting to IPv6 Forwarding and Security . . . . . . . 23 6.3. Zero Touch Provisioning and Security . . . . . . . . . . 24
7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 23 6.4. Defaulting to IPv6 Forwarding and Security . . . . . . . 24
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 24
8.1. Normative References . . . . . . . . . . . . . . . . . . 23 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
8.2. Informative References . . . . . . . . . . . . . . . . . 23 8.1. Normative References . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 8.2. Informative References . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
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 9
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, James Woodyatt and Lee Howard Shawn Zandi, Pete Lumbis, Fred Baker, James Woodyatt, Erik Muller,
contributed significant text and ideas to this draft. and Lee Howard contributed significant text and ideas to this draft.
1.2. Acknowledgements 1.2. Acknowledgments
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 Mikael
their comments, edits, and ideas on the text of this draft. Abrahamsson for their comments, edits, and ideas on the text of this
draft.
1.3. Use and Applicability
The conceived use of this draft is as a reference point. The first
part of the draft is designed to help IPv6 implementors and network
operators to understand Internet and Internetworking technologies, so
they can better understand the context of IPv6. The second part of
this draft outlines a common set of requirements for devices which
are designed to forward IPv6 traffic. The primary use of these
sections is for operators to be able to point to a common set of
functionality which should be available across all IPv6
implementations. Several members of the community have argued there
is no common set of IPv6 features; rather each deployment of IPv6
calls for different feature sets. From this perspective, each
operator should consider the features required for a particular
deployment, and only ask for the required feature set.
However, the authors of this draft believe outlining a common set of
features expected of every IPv6 forwarding device is useful.
Specifically:
o If every IPv6 deployment situation is unique, and requires a
different set of features, there will not be a solid definition of
what an IPv6 forwarding device is, or performs. This fragments
the concept of IPv6 forwarding devices in an unhelpful way,
especially as IPv6 deployment is already seen as difficult.
o It encourages developers and vendors to code a multitude of
different IPv6 stacks, one for each possible set of features.
This fragments the experience with these stacks, potentially
preventing the development of a well designed, fully featured
stacks the entire community can rely on,
However, because this document is designed to be a reference point
rather than a best common practice or a standard, this document does
not use upper case "must" and "should" throughout. Rather, it uses
lower case "must" and "should" throughout, anticipating operators
will find such guidance clear and useful.
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.
These concepts are not explicitly called out in any specification, These concepts are not explicitly called out in any specification,
nor do they necessarily impact protocol design or packet forwarding nor do they necessarily impact protocol design or packet forwarding
directly. This section provides an overview of these concepts and directly. This section provides an overview of these concepts and
considerations to help the reader understand the larger context of considerations to help the reader understand the larger context of
this document. this document.
2.1. Robustness Principle 2.1. Robustness Principle
Every point where multiple protocols interact, is an interaction Every point where multiple protocols interact, is an interaction
surface that can threaten the robustness of the overall system. surface that can threaten the robustness of the overall system.
While it may seem the global Internet has achieved a level of While it may seem the global Internet has achieved a level of
stability that makes it immune to such considerations, the reality is stability that makes it immune to such considerations, the reality is
every network is a complex system, and is therefore subject to every network is a complex system, and is therefore subject to
massive non repeatable unanticipated failures. Postel's Robustness massive non repeatable unanticipated failures. Postel's Robustness
Principle countered this problem with a simple statement, explicated Principle countered this problem with a simple statement, explicated
in [RFC7922]: "Be conservative in what you do, and liberal in what in [RFC1122]: "Be conservative in what you do, and liberal in what
you accept from others." you accept from others."
However, since this time, it has been noted that following this law However, since this time, it has been noted that following this law
allows errors in protocols to accumulate over time, with overall allows errors in protocols to accumulate over time, with overall
negative effects on the system as a whole. [RFC1918] describes negative effects on the system as a whole. [RFC1918] describes
several points in conjunction with this principle that bear updating several points in conjunction with this principle that bear updating
based on further experience with large scale protocol and network based on further experience with large scale protocol and network
deployments within the Internet community, including: deployments within the Internet community, including:
o Applications should deal with error states gracefully; an o Applications should deal with error states gracefully; an
skipping to change at page 5, line 12 skipping to change at page 6, line 8
overloads adjacent routers or interacting protocols and causing a overloads adjacent routers or interacting protocols and causing a
cascading failure. cascading failure.
o It is best to assume the network is filled with poor o It is best to assume the network is filled with poor
implementations and malevolent actors, both of which will find implementations and malevolent actors, both of which will find
every possible failure mode over time. every possible failure mode over time.
o It is best to assume every technology will be used to the limits o It is best to assume every technology will be used to the limits
of its technical capabilities, rather than assuming a particular of its technical capabilities, rather than assuming a particular
protocol's scope of use will align (in any way) with the intent of protocol's scope of use will align (in any way) with the intent of
the original designer(s). [RFC5218] defines a wildly sucessful the original designer(s). [RFC5218] defines a wildly successful
protocol as one that "far exceeds its original goals, in terms of protocol as one that "far exceeds its original goals, in terms of
purpose (being used in scenarios far beyond the initial design), purpose (being used in scenarios far beyond the initial design),
in terms of scale (being deployed on a scale much greater than in terms of scale (being deployed on a scale much greater than
originally envisaged), or both." Successful implementations originally envisaged), or both." Successful implementations
attract more functionality, much like a few nodes in a scale free attract more functionality, much like a few nodes in a scale free
graph eventually become connectivity hubs. graph eventually become connectivity hubs.
o Protocols and implementations change over time. A corollary of o Protocols and implementations change over time. A corollary of
the assumption that protocols will be used until they reach their the assumption that protocols will be used until they reach their
technical limits is that protocols will change over time as they technical limits is that protocols will change over time as they
skipping to change at page 5, line 38 skipping to change at page 6, line 34
into protocols. Protocols should also remained focused on a into protocols. Protocols should also remained focused on a
narrow range of use cases; it is often wise to invent a new narrow range of use cases; it is often wise to invent a new
protocol than to extend a single protocol into a broad set of use protocol than to extend a single protocol into a broad set of use
cases. cases.
o Protocols are sometimes replaced or updated to new versions in o Protocols are sometimes replaced or updated to new versions in
order to add new capabilities or features. Updating a protocol order to add new capabilities or features. Updating a protocol
requires great care in providing for a transition mechanism requires great care in providing for a transition mechanism
between older and newer versions. draft-iab-protocol-transitions between older and newer versions. draft-iab-protocol-transitions
[I-D.iab-protocol-transitions] provides sound advice on protocol [I-D.iab-protocol-transitions] provides sound advice on protocol
transition planning and mehanisms. transition planning and mechanisms.
o Obscure, but legal, protocol features are often ignored or left o Obscure, but legal, protocol features are often ignored or left
unimplemented. Protocols must handle receiving unexpected unimplemented. Protocols must handle receiving unexpected
information gracefully so they do not fail because of incomplete information gracefully so they do not fail because of incomplete
or partial implementations. Protocols should avoid specifying or partial implementations. Protocols should avoid specifying
contradictory states, or features that will cause interoperability contradictory states, or features that will cause interoperability
issues if multiple implementations choose to implement different issues if multiple implementations choose to implement different
feature sets. feature sets.
o Monocultures are almost always bad. While multiple o Monocultures are almost always bad. While multiple
implementations can represent an interaction surface which implementations can represent an interaction surface which
increases complexity, particularly if a brad set of protocol increases complexity, particularly if a broad set of protocol
capabilities and/or implementation features are used, using the capabilities and/or implementation features are used, using the
same implementation at every point in a deployment results in a same implementation at every point in a deployment results in a
monoculture. In a monoculture, a single event can trigger a mono-culture. In a monoculture, a single event can trigger a
defect in every router, causing a network failure. Monocultures defect in every router, causing a network failure. Mono-cultures
must be carefully balanced against interaction surfaces; often must be carefully balanced against interaction surfaces; often
this is best accomplished by using multiple implementations and this is best accomplished by using multiple implementations and
minimal, widely implemented, and well understood protocol minimal, widely implemented, and well understood protocol
features. features.
A summary of the points above might be this: It is important to work A summary of the points above might be this: It is important to work
within the bounds of what is actually implemented in any given within the bounds of what is actually implemented in any given
protocol, and to leave corner cases for another day. It is often protocol, and to leave corner cases for another day. It is often
easy to assume "virtual oceans" are easier to boil than physical easy to assume "virtual oceans" are easier to boil than physical
ones, or for an ocean to appear much smaller because it is being ones, or for an ocean to appear much smaller because it is being
implemented in software. This is often deceptive. It is never implemented in software. This is often deceptive. It is never
helpful to boil the ocean whether in a design, an implementation, or helpful to boil the ocean whether in a design, an implementation, or
a protocol. a protocol.
2.2. Complexity 2.2. Complexity
Complexity, as articulated by Mike O'Dell (see [RFC3439]), is "the Complexity, as articulated by Mike O'Dell (see [RFC3439]), is "the
primary mechanism which impede efficient scaling, and as a result is primary mechanism which impedes efficient scaling, and as a result is
the primary driver of increases in both capital expenditures (CAPEX) the primary driver of increases in both capital expenditures (CAPEX)
and operational expenditures (OPEX)." At the same time, complexity and operational expenditures (OPEX)." At the same time, complexity
cannot be "solved," but rather must be "managed." The simplest and cannot be "solved," but rather must be "managed." The simplest and
most obvious solution to any problem is often easy to design, deploy, most obvious solution to any problem is often easy to design, deploy,
and manage. It's also often wrong and/or broken. As much as and manage. It's also often wrong and/or broken. As much as
developers, designers, and operators might like to make things as developers, designers, and operators might like to make things as
simple as possible, hard problems require complex solutions. See simple as possible, hard problems require complex solutions. See
Alderson and Doyle [COMPLEXHARD] for a discussion of the relationship Alderson and Doyle [COMPLEXHARD] for a discussion of the relationship
between hard problems and complex solutions. between hard problems and complex solutions.
skipping to change at page 7, line 10 skipping to change at page 8, line 7
o Seeing the problem from different angles, trying to break the o Seeing the problem from different angles, trying to break the
problem up in multiple ways; and trying, abandoning, and problem up in multiple ways; and trying, abandoning, and
rebuilding ideas and implementations until a better way is found. rebuilding ideas and implementations until a better way is found.
o Sometimes the complexity of the solution will overwhelm the use o Sometimes the complexity of the solution will overwhelm the use
case; sometimes it is better to leave the apparent problem case; sometimes it is better to leave the apparent problem
unsolved, or allow the community time and space to find a simpler unsolved, or allow the community time and space to find a simpler
solution. solution.
2.2.2. Tradeoffs 2.2.2. Trade-offs
There are always tradeoffs. For any protocol, network, or There are always trade-offs. For any protocol, network, or
operational design decision, there will always be a tradeoff between operational design decision, there will always be a trade-off between
at least two competing goals. If some problem appears to have a at least two competing goals. If some problem appears to have a
single solution without tradeoffs, this doesn't mean the tradeoffs single solution without trade-offs, this doesn't mean the trade-offs
don't exist. Rather, it means the tradeoffs haven't been discovered don't exist. Rather, it means the trade-offs haven't been discovered
yet. In the area of protocol and network design, these tradeoffs yet. In the area of protocol and network design, these trade-offs
often take the form of common "choose two or three" situations, such often take the form of common "choose two of three" situations, such
as "quick, cheap, high quality." In network and protocol design, the as "quick, cheap, high quality." In network and protocol design, the
tradeoffs are often: trade-offs are often:
o The amount of state carried in the system and the speed at which o The amount of state carried in the system and the speed at which
it changes, or simply the state. The amount of state required to it changes, or simply the state. The amount of state required to
operate a system as it scales tends to be nonlinear. Some operate a system as it scales tends to be nonlinear. Some
instances of this are described in [RFC3439] section 2.2.1, the instances of this are described in [RFC3439] section 2.2.1, the
Amplification Principle. Amplification Principle.
o The number of interaction surfaces between the components that o The number of interaction surfaces between the components that
make up the complete system, and the depth of those interaction make up the complete system, and the depth of those interaction
surfaces. Some examples of surfaces are described in surfaces. Some examples of surfaces are described in
[RFC3439]section 2.2.2, the Coupling Principle. Layering is [RFC3439]section 2.2.2, the Coupling Principle. Layering is
essentially a form of abstraction; all abstractions are subject to essentially a form of abstraction; all abstractions are subject to
the law of leaky abstractions, [LEAKYABS] which states: "all the law of leaky abstractions, [LEAKYABS] which states: "all
nontrivial absractions leak." nontrivial abstractions leak."
o The desired optimization, including efficient use of network o The desired optimization, including efficient use of network
resources, optimal support for business objectives, and optimal resources, optimal support for business objectives, and optimal
support for a specific set of applications. support for a specific set of applications.
These three make up a "triangle problem." For instance, to increase These three make up a "triangle problem." For instance, to increase
the optimization of traffic flow through a network generally requires the optimization of traffic flow through a network generally requires
adding more state to the control plane, leading to problems in adding more state to the control plane, leading to problems in
complexity due to amplification. To reduce amplification, the complexity due to amplification. To reduce amplification, the
control plane (or perhaps the various functions the control plane control plane (or perhaps the various functions the control plane
serves) can be broken up into subsystems, or modules. Breaking the serves) can be broken up into subsystems, or modules. Breaking the
control plane up into subsystems, however, introduces interaction control plane up into subsystems, however, introduces interaction
surfaces between the components, which is another form of complexity. surfaces between the components, which is another form of complexity.
[RFC7980] provides a good overview of network complexity; in [RFC7980] provides a good overview of network complexity; in
particular, section 3 of that document provides some examples of particular, section 3 of that document provides some examples of
complexity tradeoffs. complexity trade-offs.
2.3. Layered Structure 2.3. Layered Structure
The Internet data plane is organized around broad top and bottom The Internet data plane is organized around broad top and bottom
layers, and much thinner middle layer. This is illustrated in the layers, and much thinner middle layer. This is illustrated in the
figure below. figure below.
\ / \ /
\ HTTP, FTP, SNMP, ETC. / \ HTTP, FTP, SNMP, ETC. /
\ / \ /
skipping to change at page 8, line 41 skipping to change at page 9, line 41
the Internet ecosystem has traditionally been called the Network the Internet ecosystem has traditionally been called the Network
Layer, in reference to the Department of Defense (DoD) [DoD] and OSI Layer, in reference to the Department of Defense (DoD) [DoD] and OSI
models. [OSI] The Internet ecosystem includes two different models. [OSI] The Internet ecosystem includes two different
protocols in this central location. protocols in this central location.
o IPv4, an older network protocol that, it is anticipated, will be o IPv4, an older network protocol that, it is anticipated, will be
replaced over time as the Internet ecosystem standardizes on IPv6 replaced over time as the Internet ecosystem standardizes on IPv6
o IPv6, a newer network protocol that is being adopted o IPv6, a newer network protocol that is being adopted
MPLS is often used as a "middle" subtransport layer, and at other MPLS is often used as a "middle" sub-transport layer, and at other
times as "middle" sub data link layer; hence MPLS is difficult to times as "middle" sub data link layer; hence MPLS is difficult to
classify within the strictly hierarchical model depicted here. These classify within the strictly hierarchical model depicted here. These
protocols are often treated as if they exist in strict hierarchical protocols are often treated as if they exist in strict hierarchical
layers with a well defined and followed Application Programming layers with a well defined and followed Application Programming
Interface (API), data models, Remote Procedure Calls (RPCs), sockets, Interface (API), data models, Remote Procedure Calls (RPCs), sockets,
etc. The reality, however, is there are often solid reasons for etc. The reality, however, is there are often solid reasons for
violating these layers, creating interaction surfaces that are often violating these layers, creating interaction surfaces that are often
deeper than intended or understood without some experience. Beyond deeper than intended or understood without some experience. Beyond
this, such layering mechanisms act as information abstractions. It this, such layering mechanisms act as information abstractions. It
is well known that all such abstractions leak (see above on the law is well known that all such abstractions leak (see above on the law
skipping to change at page 11, line 15 skipping to change at page 12, line 15
3. Requirements Related to Device Management and Security 3. Requirements Related to Device Management and Security
Network engineering began in the era of Command Line Interfaces Network engineering began in the era of Command Line Interfaces
(CLIs), and has generally stayed with these CLIs even as the (CLIs), and has generally stayed with these CLIs even as the
Graphical User Interface (GUI) has become the standard way of Graphical User Interface (GUI) has become the standard way of
interacting with almost every other computing device. Direct human interacting with almost every other computing device. Direct human
interaction with routers and middleboxes in large scale and complex interaction with routers and middleboxes in large scale and complex
environments, however, tends to result in an unacceptably low Mean environments, however, tends to result in an unacceptably low Mean
Time Between Mistakes (MTBM), directly impacting the overall Time Between Mistakes (MTBM), directly impacting the overall
availability of the network. In reaction to this, operators have availability of the network. In reaction to this, operators have
increased their reliance on automation, specifically targetting increased their reliance on automation, specifically targeting
machine to machine intefaces, such as Remote Procesdure Calls (RPCs) machine to machine interfaces, such as Remote Procedure Calls (RPCs)
and Application Programming Interface (API) solutions, to manage and and Application Programming Interface (API) solutions, to manage and
configure routers and middleboxes. This section considers the configure routers and middleboxes. This section considers the
various components of device management. various components of device management.
Across all interface types, devices should provide and use complete,
idempotent, stateless configurations. Further, default settings
should be accessible in some way, even if they are hidden by default
for configuration readability.
3.1. Programmable Device Access 3.1. Programmable Device Access
Configuration primarily relates to the startup, candidate, and Configuration primarily relates to the startup, candidate, and
running configurations in the router model shown above. In order to running configurations in the router model shown above. In order to
deploy networks at scale, operators rely on automated management of deploy networks at scale, operators rely on automated management of
router configuration. This effort has traditionally focused on router configuration. This effort has traditionally focused on
Simple Network Management Protocol (SNMP) Management Information Base Simple Network Management Protocol (SNMP) Management Information Base
(MIBs). In the future, operators expect to move towards open source/ (MIBs). In the future, operators expect to move towards open source/
open standards YANG models. open standards YANG models.
Vendors and implementors should implement machine readable interfaces Vendors and implementors should implement machine readable interfaces
with overlays to support human interaction, rather than human with overlays to support human interaction, rather than human
readable interfaces with overlays to support machine to machine readable interfaces with overlays to support machine to machine
interaction. Emphasis should be placed on machine to machine interaction. Emphasis should be placed on machine to machine
interaction for day to day operations, rather than on human readable interaction for day to day operations, rather than on human readable
interfaces, which are largely used in the process of troubleshooting. interfaces, which are largely used in the process of troubleshooting.
Within the realm of machine to machine interfaces, emphasis should be Within the realm of machine to machine interfaces, emphasis should be
placed on marshaling information in YANG models. placed on marshaling information in YANG models.
To support automated router configuration, IPv6 routers and routers To support automated router configuration, IPv6 routers and routers
SHOULD support YANG and SNMP configuration, including (but not should support YANG and SNMP configuration, including (but not
limited to): limited to):
o Openconfig models [OPENCONF] related to the protocols configured o Openconfig models [OPENCONF] related to the protocols configured
on the device, interface state, and device state on the device, interface state, and device state
o [RFC7223]: A YANG Data Model for Interface Management o [RFC7223]: A YANG Data Model for Interface Management
o [RFC7224]: IANA Interface Type YANG Module o [RFC7224]: IANA Interface Type YANG Module
o [RFC7277]: A YANG Data Model for IP Management o [RFC7277]: A YANG Data Model for IP Management
o [RFC7317]: A YANG Data Model for System Management o [RFC7317]: A YANG Data Model for System Management
o Simple Network Management Protocol (SNMP) MIBs as appropriate o Simple Network Management Protocol (SNMP) MIBs as appropriate
3.2. Human Readable Device Access 3.2. Human Readable Device Access
To operate a network at scale, operators rely on the ability to To operate a network at scale, operators rely on the ability to
access routers and middleboxes to troubleshoot and gather state access routers and middleboxes to troubleshoot and gather state
manually through a number of different interfaces. These interfaces manually through a number of different interfaces. These interfaces
should provide current device configuration, current device state should provide current device configuration, current device state
skipping to change at page 12, line 20 skipping to change at page 13, line 24
To operate a network at scale, operators rely on the ability to To operate a network at scale, operators rely on the ability to
access routers and middleboxes to troubleshoot and gather state access routers and middleboxes to troubleshoot and gather state
manually through a number of different interfaces. These interfaces manually through a number of different interfaces. These interfaces
should provide current device configuration, current device state should provide current device configuration, current device state
(such as interface state, packets drops, etc.), and current control (such as interface state, packets drops, etc.), and current control
plane contents (such as the RIB in the figure above). In other plane contents (such as the RIB in the figure above). In other
words, manual interfaces should provide information about the router words, manual interfaces should provide information about the router
(the whole device stack). (the whole device stack).
To support manual state gathering and troubleshooting, IPv6 routers To support manual state gathering and troubleshooting, IPv6 routers
and middleboxes SHOULD support: and middleboxes should support:
o TELNET ([RFC0854]): TELNET SHOULD be disabled by default, but o TELNET ([RFC0854]): TELNET should be disabled by default, but
should be available for operational purposes as required or as should be available for operational purposes as required or as
configured by the operator configured by the operator
o SSH ([RFC4253]): SSH SHOULD be the default access for IPv6 capable o SSH ([RFC4253]): SSH should be the default access for IPv6 capable
routers routers
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 -- important goals in the real world. IPv6 routers should be reduced -- important goals in the real world. IPv6 routers 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 unless there's a need to embed MAC address.
o [RFC7934]: Host Address Availability, the ability to assign o [RFC7934]: Host Address Availability, the ability to assign
multiple addresses to a host, SHOULD be supported. multiple addresses to a host, should be supported.
o [RFC7527]: Enhanced Duplicate Address Detection MUST be supported. o [RFC7527]: Enhanced Duplicate Address Detection should be
supported.
o [RFC7527]: Enhanced Duplicate Address Detection may be disabled
for manually configured interfaces.
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 o [RFC7772]: Routers supporting IPv6 should support Reducing Energy
Consumption of Router Advertisements Consumption of Router Advertisements
o [RFC8273]: Routers supporting IPv6 SHOULD support Unique IPv6 o [RFC8273]: Routers supporting IPv6 should support Unique IPv6
Prefix per Host 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) if DHCPv6 is supported.
o [RFC8106]: IPv6 Router Advertisement Options for DNS o [RFC8106]: IPv6 Router Advertisement Options for DNS
Configuration. This includes the ability to send Router Configuration. This includes the ability to send Router
Advertisements (RAs) with DNS information. Advertisements (RAs) with DNS information.
Whether these are enabled by default, or require extra configuration, Whether these are enabled by default, or require extra configuration,
is left as an exercise for providers and implementation developers to is left as an exercise for providers and implementation developers to
determine on a case by case basis. determine on a case by case basis.
3.4. Device Protection against Denial of Service Attacks 3.4. Device Protection against Denial of Service Attacks
skipping to change at page 14, line 11 skipping to change at page 15, line 19
types of attacks cost network operators a great deal in opportunity types of attacks cost network operators a great deal in opportunity
and operational costs in prevention and responses. To provide for and operational costs in prevention and responses. To provide for
effective counters to DoS and DDoS attacks directly on routers: effective counters to DoS and DDoS attacks directly on routers:
o Manufacturers and system integrators should test and clearly o Manufacturers and system integrators should test and clearly
report the packet/traffic load handling capabilities of devices report the packet/traffic load handling capabilities of devices
with and without various encryption methods enabled with and without various encryption methods enabled
o Routers should be able to police traffic destined to the control o Routers should be able to police traffic destined to the control
plane based on the rate of traffic received, including the ability plane based on the rate of traffic received, including the ability
ot police individual flows, targeted services, etc., at individual to police individual flows, targeted services, etc., at individual
rates as described in [RFC6192] rates as described in [RFC6192]
o Ideally, devices should be able to statefully filter traffic o Ideally, devices should be able to statefully filter traffic
destined to the control plane destined to the control plane
There are other useful techniques for dealing with DDoS attacks at There are other useful techniques for dealing with DDoS attacks at
the network level, including: transferring sessions to a new address the network level, including: transferring sessions to a new address
and abandoning the address under attack, using BGP communities to and abandoning the address under attack, using BGP communities to
spread the attack over multiple ingress ports and "consume" it, and spread the attack over multiple ingress ports and "consume" it, and
requiring mutual authentication before allocating larger resource requiring mutual authentication before allocating larger resource
skipping to change at page 15, line 12 skipping to change at page 16, line 18
plane, and the forwarding plane of the network. Each of the sections plane, and the forwarding plane of the network. Each of the sections
below considers one of these three telemetry types. below considers one of these three telemetry types.
4.1. Device State and Traceablity 4.1. Device State and Traceablity
Ideally, the entire network could be monitored using a single Ideally, the entire network could be monitored using a single
modeling language to ease implementation of telemetry systems and modeling language to ease implementation of telemetry systems and
increase the pace at which new software can be deployed in production increase the pace at which new software can be deployed in production
environments. In real deployments, it is often impossible to reach environments. In real deployments, it is often impossible to reach
this ideal; however, reducing the languages and methods used, while this ideal; however, reducing the languages and methods used, while
focusing on machine readibility, can greatly ease the deployment and focusing on machine readability, can greatly ease the deployment and
management of a large scale network. Specifically, IPv6 routers management of a large scale network. Specifically, IPv6 routers
SHOULD support: should support:
o [RFC6241]: NETCONF/RESTCONF transporting telemetry formatted o [RFC6241]: NETCONF/RESTCONF transporting telemetry formatted
according to YANG (see above) according to YANG (see above)
o [RFC5424]: Syslog o [RFC5424]: Syslog
o gRPC based telemetry interfaces [GRPC] o gRPC based telemetry interfaces [GRPC]
o SNMP as appropriate o SNMP as appropriate
Syslog and SNMP access for telemetry should be considered "legacy," Syslog and SNMP access for telemetry should be considered "legacy,"
and should not be the focus of new telemetry access development and should not be the focus of new telemetry access development
efforts. efforts.
4.2. Topology State and Traceability 4.2. Topology State and Traceability
IPv6 routers are part of a system of devices that, combined, make up IPv6 routers are part of a system of devices that, combined, make up
the entire network. Viewing the network as a system is often crucial the entire network. Viewing the network as a system is often crucial
for operational purposes. For instance, being able to understand for operational purposes. For instance, being able to understand
changes in the topology and utlization of a network can lead to changes in the topology and utilization of a network can lead to
insights about traffic flow and network growth that lead to a greater insights about traffic flow and network growth that lead to a greater
understanding of how the network is operating, where problems are understanding of how the network is operating, where problems are
developing, and how to improve the network's performance. To support developing, and how to improve the network's performance. To support
systemic monitoring of the network topology, IPv6 devices SHOULD systemic monitoring of the network topology, IPv6 devices should
support at least: support at least:
o [RFC5424]: North-Bound Distribution of Link-State and Traffic o [RFC5424]: North-Bound Distribution of Link-State and Traffic
Engineering (TE) Information using BGP Engineering (TE) Information using BGP
o [I-D.ietf-i2rs-yang-l2-network-topology]: An I2RS model for layer o [I-D.ietf-i2rs-yang-l2-network-topology]: An I2RS model for layer
2 topologies 2 topologies
o [I-D.ietf-i2rs-yang-l3-topology]: An I2RS model for layer 3 o [I-D.ietf-i2rs-yang-l3-topology]: An I2RS model for layer 3
topologies topologies
o [I-D.ietf-i2rs-yang-network-topo]: A Data Model for Network o [I-D.ietf-i2rs-yang-network-topo]: A Data Model for Network
Topologies Topologies
4.3. Flow State and Traceability
Network operators frequently need to observe and understand the
types, sources, and destinations of traffic passing through devices.
For example, information about traffic flows may be used to identify
abuse (such as DDOS attacks) or to plan network expansions based on
traffic patterns. To support insight and analysis of this traffic,
IPv6 devices should support IPFIX as described in [RFC7011], PSAMP as
described in [RFC5474], sFlow as described in [RFC7011].
5. Requirements Related to IPv6 Forwarding and Addressing 5. Requirements Related to IPv6 Forwarding and Addressing
There are a number of capabilities that a device SHOULD have to be There are a number of capabilities that a device should have to be
deployed into an IPv6 network, and several forwarding plane deployed into an IPv6 network, and several forwarding plane
considerations operators and vendors need to bear in mind. The considerations operators and vendors need to bear in mind. The
sections below explain these considerations. sections below explain these considerations.
5.1. The IPv6 Address is not a Host Identifier 5.1. The IPv6 Address is not a Host Identifier
The IPv6 address is commonly treated as a host identifier; it is not. The IPv6 address is commonly treated as a host identifier; it is not.
Rather, it is an interface identifier that describes the topological Rather, it is an interface identifier that describes the topological
point where a particular host connects to the Internet. point where a particular host connects to the Internet.
Specifically: Specifically:
o The IPv6 address will change when a device changes where it o The IPv6 address will change when a device changes where it
connects to the network. connects to the network.
o A single host can have multiple addresses. For instance, a host o A single host can have multiple addresses. For instance, a host
may have one address per interface, or multiple addresses assigned may have one address per interface, or multiple addresses assigned
through different mechanisms, or through multiple connection through different mechanisms, or through multiple connection
points. points.
o A single IPv6 address may represent many hosts, as in the case of o A single IPv6 address may represent many hosts, as in the case of
a group of hosts reachable through multicast address, or a set of a group of hosts reachable through a multicast address, or a set
services reachable through an anycast address. of services reachable through an anycast address.
Because the host address may change at any time, it is generally Because the host address may change at any time, it is generally
harmful to embed IPv6 addresses inside upper layer headers to harmful to embed IPv6 addresses inside upper layer headers to
identify a particular host. identify a particular host.
5.2. Router IPv6 Addresseses 5.2. Router IPv6 Addresses
Internet Routing Registries may allocate a network operator a wide Internet Routing Registries may allocate a network operator a wide
range of prefix lengths (see [RFC6177] for further information). range of prefix lengths (see [RFC6177] for further information).
Within this allocation, network operators will often suballocate Within this allocation, network operators will often suballocate
address space along nibble boundaries (/48, /52, /56, /60, and /64) address space along nibble boundaries (/48, /52, /56, /60, and /64)
for ease of configuration and management. Several common practices for ease of configuration and management. Several common practices
are: are:
o Each multiaccess interface is allocated a /64 o Each multiaccess interface is allocated a /64
o Point-to-point links are allocated a /64, but SHOULD be addressed o Point-to-point links are allocated a /64, but should be addressed
with a longer prefix length to prevent certain kinds of denial of with a longer prefix length to prevent certain kinds of denial of
service attacks ([RFC3627] originally mandated 64 bit prefix service attacks ([RFC3627] originally mandated 64 bit prefix
lengths on point-to-point links; [RFC6164] explains possible lengths on point-to-point links; [RFC6164] explains possible
security issues with assigning a 64 bit prefix length to a point- security issues with assigning a 64 bit prefix length to a point-
to-point, and recommends a /127 instead) to-point, and recommends a /127 instead)
o Although aggregation may only performed to the nibble boundaries o Although aggregation is typically only performed to the nibble
noted above, variances are possible boundaries noted above, variances are possible
o Loopback addresses are assigned a /128 o Loopback addresses are assigned a /128
Given these common practices, routers designed to run IPv6 SHOULD Given these common practices, routers designed to run IPv6 should
support the following addressing conventions: support the following addressing conventions:
o The default prefix length on any interface other than a loopback o The default prefix length on any interface other than a loopback
SHOULD be a /64 should be a /64
o Configuring a prefix length longer than a /64 on any multi-access o Configuring a prefix length longer than a /64 on any multi-access
interface SHOULD require additional configuration steps to prevent interface should require additional configuration steps to prevent
manual configuration errors manual configuration errors
o Routers MUST NOT assume IPv6 prefix lengths only on nibble o Routers must not assume IPv6 prefix lengths only on nibble
boundaries boundaries
o Routers SHOULD support any prefix length shorter or greater than o Routers should support any prefix length shorter or greater than
/64 /64
o Loopback interfaces SHOULD default to a /128 prefix length unless o Loopback interfaces should default to a /128 prefix length unless
some additional configuration is undertaken to override this some additional configuration is undertaken to override this
default setting default setting
o Routers MUST be able to generate link local addresses on all links o Routers must be able to generate link local addresses on all links
and/or interfaces using stateless address autoconfiguration (see and/or interfaces using stateless address autoconfiguration (see
[RFC6434]). [RFC6434]).
5.3. The Maximum Transmission Unit 5.3. The Maximum Transmission Unit
The long history of the Maximum Transmission Unit (MTU) in networks The long history of the Maximum Transmission Unit (MTU) in networks
is not a happy one. Specific problems with MTU sizing include: is not a happy one. Specific problems with MTU sizing include:
o Many different default sizes on different media types, from very o Many different default sizes on different media types, from very
small (576 bytes on X.25) to very large (17914 bytes on 16Mbps small (576 bytes on X.25) to very large (17914 bytes on 16Mbps
Token Ring) Token Ring)
o Many different ways to calcualte the MTU on any given link; for o Many different ways to calculate the MTU on any given link; for
instance a 9000 byte MTU can be calculated as 8184 bytes on one instance a 9000 byte MTU can be calculated as 8184 bytes on one
operating system, 8972 on another, and 9000 on a third operating system, 8972 on another, and 9000 on a third
o The increasing use of tunnel encapsulations in the network; for o The increasing use of tunnel encapsulations in the network; for
instance MPLS over GRE over IP over... instance MPLS over GRE over IP over...
o The wide variety of default MTUs across many different end hosts o The wide variety of default MTUs across many different end hosts
and operating systems and operating systems
o The general ineffectiveness of path MTU discovery to operate o The general ineffectiveness of path MTU discovery to operate
skipping to change at page 18, line 33 skipping to change at page 19, line 52
o 64 byte packet onto a 100Mb/s link: .05ms o 64 byte packet onto a 100Mb/s link: .05ms
o 1500 byte packet onto a 100Mb/s link: .12ms o 1500 byte packet onto a 100Mb/s link: .12ms
o 9000 byte packet onto a 100Mb/s link: .72ms o 9000 byte packet onto a 100Mb/s link: .72ms
A 64 byte packet trapped behind a single 1500 byte packet on a 10Mb/s A 64 byte packet trapped behind a single 1500 byte packet on a 10Mb/s
link suffers 1.2ms of serialization delay. Each additional 1500 byte link suffers 1.2ms of serialization delay. Each additional 1500 byte
packet added to the queue in front of the 64 byte packet adds and packet added to the queue in front of the 64 byte packet adds and
addtional 1.2ms of delay. In contrast, a 64 byte packet trapped additional 1.2ms of delay. In contrast, a 64 byte packet trapped
behind a single 9000 byte packet on a 10Mb/s link suffers 7.7ms of behind a single 9000 byte packet on a 10Mb/s link suffers 7.7ms of
serialization delay. Each additional 9000 byte packet added to the serialization delay. Each additional 9000 byte packet added to the
queue adds an additional 7.2ms of serialization delay. The practical queue adds an additional 7.2ms of serialization delay. The practical
result is that larger MTU sizes on lower speed links can add a result is that larger MTU sizes on lower speed links can add a
significant amount of delay and jitter into a flow. On the other significant amount of delay and jitter into a flow. On the other
hand, increasing the MTU on higher speed links appears to add hand, increasing the MTU on higher speed links appears to add
megligable additional delay and jitter. negligible additional delay and jitter.
The result is that it costs less in terms of overall systemic The result is that it costs less in terms of overall systemic
performance to use higher MTUs on higher speed links than on lower performance to use higher MTUs on higher speed links than on lower
speed links. Based on this, increasing the MTU across any particular speed links. Based on this, increasing the MTU across any particular
link may not increase overall end-to-end performance, but can greatly link may not increase overall end-to-end performance, but can greatly
enhance the performance of local applications (such as a local BGP enhance the performance of local applications (such as a local BGP
peering session, or a large/long standing elephant flow used to peering session, or a large/long standing elephant flow used to
transfer data across a local fabric), while also providing room for transfer data across a local fabric), while also providing room for
tunnel encapsulations to be added with less impact on lower MTU end tunnel encapsulations to be added with less impact on lower MTU end
systems. systems.
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 [RFC3719], 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 [RFC8201]: 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 Protocol (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
and/or ICMP filters configured on the ingress edge of a provider and/or ICMP filters configured on the ingress edge of a provider
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 rate limit the generation of ICMP echo and echo responses
negative impacts on many aspects of IPv6 operation, particularly by default (for instance, using a token bucket method as described
path MTU in [RFC4443]). The device should support the configuration of not
generating ICMP echo and echo response packets to prevent topology
o SHOULD filter ICMP echo and echo response by default, to prevent discovery.
the discovery of reachable hosts and topology.
o SHOULD rate limit the generation of ICMP error messages with a o Should rate limit the generation of ICMP error messages with a
token bucket method as described in [RFC4443]. Rate limits SHOULD token bucket method as described in [RFC4443]. Rate limits should
be narrow enough to (a) protect the device's ability to generate be narrow enough to (a) protect the device's ability to generate
packets and (b) reduce the usefulness of ICMP error packets as packets and (b) reduce the usefulness of ICMP error packets as
part of a distributed denial of service attack. Limits SHOULD be part of a distributed denial of service attack. Limits should be
generous enough to allow successful path MTU discovery and generous enough to allow successful path MTU discovery and
traceroute. For example, in a small/mid-size device, the possible traceroute. For example, in a small/mid-size device, the possible
defaults could be bucket size=100, refill rate=100/s. Larger defaults could be bucket size=100, refill rate=100/s. Larger
devices can afford more generous rate limits. 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 o Should not filter Destination Unreachable or Packet Too Big ICMP
error messages by default, as this has negative impacts on many error messages by default, as this has negative impacts on many
aspects of IPv6 operation, particularly path MTU discovery. 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 trade-off here
between allowing unlimited ICMP, which would allow path MTU detection is between allowing unlimited ICMP, which would allow path MTU
to work, or limiting ICMP in a way that prevents negative side detection to work, or limiting ICMP in a way that prevents negative
effects for individual devices, and hence the operational side 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 opportunity 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
prove, for instance, that a particular host is unreachable. The non- prove, for instance, that a particular host is unreachable. The non-
existence of an ICMP message, however, does not prove a particular existence of an ICMP message, however, does not prove a particular
host exists or does not. host exists or does not.
5.5. Machine Access to the Forwarding Table 5.5. Machine Access to the Forwarding Table
In order to support treating the "network as a whole" as a single In order to support treating the "network as a whole" as a single
programmable system, it is important for each router have the ability programmable system, it is important for each router have the ability
skipping to change at page 20, line 49 skipping to change at page 22, line 17
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 Operation by Default 5.7. IPv6 Operation by Default
If a device forwards and/or originates IPv4 packets by default If a device forwards and/or originates IPv4 packets by default
(without explicit configuration by the operator), it SHOULD forward (without explicit configuration by the operator), it should forward
and/or originate IPv6 packets by default. See the security and/or originate IPv6 packets by default. See the security
considerations section below for reflections on the automatic considerations section below for reflections on the automatic
configuration of IPv6 forwarding in parallel with IPv4. configuration of IPv6 forwarding in parallel with IPv4.
5.8. IPv6 Only Operation 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 usable 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.9. 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 5.10. IPv6 Mobility Support
Mobile IPv6 [RFC6275] and associated specifications, including Mobile IPv6 [RFC6275] and associated specifications, including
[RFC3776] and [RFC4877] allow a node to change its point of [RFC3776] and [RFC4877] allow a node to change its point of
attachment within the Internet, while maintaining (and using) a attachment within the Internet, while maintaining (and using) a
permanent address. All communication using the permanent address permanent address. All communication using the permanent address
continues to proceed as expected even as the node moves around. At continues to proceed as expected even as the node moves around. At
the present time, Mobile IP has seen only limited implementation. the present time, Mobile IP has seen only limited implementation.
More usage and deployment experience is needed with mobility before More usage and deployment experience is needed with mobility before
any specific approach can be recommended for broad implementation in any specific approach can be recommended for broad implementation in
hosts and routers. Consequently, routers MAY support [RFC6275] and hosts and routers. Consequently, routers may support [RFC6275] and
associated specifications (these specifications are not required for associated specifications (these specifications are not required for
IPv6 routers). 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
between operational concerns and security concerns into one place. between operational concerns and security concerns into one place.
ICMP security is already considered in the section on ICMP; it will ICMP security is already considered in the section on ICMP; it will
not be considered further here. Link local only addressing wil not be considered further here. Link local only addressing will
increase security by removing transit only links within the network increase security by removing transit only links within the network
as a reachable destination. as a reachable destination.
6.1. Robustness and Security 6.1. Robustness and Security
Robustness, particularly in the area of error handling, largely Robustness, particularly in the area of error handling, largely
improves security if designed and implemented correctly. Many improves security if designed and implemented correctly. Many
attacks take advantage of mistakes in implementations and variations attacks take advantage of mistakes in implementations and variations
in protocols. In particular, any feature that is unevenly in protocols. In particular, any feature that is unevenly
implemented among a number of implementations often offers an attack implemented among a number of implementations often offers an attack
skipping to change at page 22, line 31 skipping to change at page 23, line 48
breadth of attack surfaces. breadth of attack surfaces.
Another point to consider at the intersection of robustness and Another point to consider at the intersection of robustness and
security is the issue of monocultures. Monocultures are in and of security is the issue of monocultures. Monocultures are in and of
themselves a potential attack surface, in that finding a single themselves a potential attack surface, in that finding a single
failure mode can be exploited to take an entire network (or operator) failure mode can be exploited to take an entire network (or operator)
down. On the other hand, reducing the number of implementations for down. On the other hand, reducing the number of implementations for
any particular protocol will decrease the set of "random" features any particular protocol will decrease the set of "random" features
deployed in the network. These two goals will often be opposed to deployed in the network. These two goals will often be opposed to
one another. Network designers and operators need to consider these one another. Network designers and operators need to consider these
two sides of this tradeoff, and make an intelligent decision about two sides of this trade-off, and make an intelligent decision about
how much diversity to implement versus how to control the attack how much diversity to implement versus how to control the attack
surface represented by deploying a wide array of implementations. surface represented by deploying a wide array of implementations.
6.2. Programmable Device Access and Security 6.2. Programmable Device Access and Security
Programmable interfaces, including programmable configuration, Programmable interfaces, including programmable configuration,
telemetry, and machine interface to the routing table, introduce a telemetry, and machine interface to the routing table, introduce a
large attack surface; operators should be careful to ensure this large attack surface; operators should be careful to ensure this
attack surface is properly secured. Specifically: attack surface is properly secured. Specifically:
skipping to change at page 23, line 23 skipping to change at page 24, line 39
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 6.4. Defaulting to IPv6 Forwarding and Security
Operators should be aware that devices which forward IPv6 by default Operators should be aware that devices which forward IPv6 by default
can introduce a new attack surface or new threats without explicit can introduce a new attack surface or new threats without explicit
configuration. Operators SHOULD verify that IPv6 policies, including configuration. Operators should verify that IPv6 policies, including
filtering, match or fulfill the same intent as any existing IPv4 filtering, match or fulfill the same intent as any existing IPv4
policies when deploying devices capable of forwarding both IPv4 and policies when deploying devices capable of forwarding both IPv4 and
IPv6. 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,
skipping to change at page 24, line 38 skipping to change at page 25, line 49
[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-10 (work in progress), bis", draft-ietf-dhc-rfc3315bis-12 (work in progress),
September 2017. March 2018.
[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., Chen, M., amit.dass@ericsson.com, a.,
amit.dass@ericsson.com, a., Kini, S., and N. Bahadur, "A Ananthakrishnan, H., Kini, S., and N. Bahadur, "A YANG
YANG Data Model for Routing Information Base (RIB)", Data Model for Routing Information Base (RIB)", draft-
draft-ietf-i2rs-rib-data-model-09 (work in progress), ietf-i2rs-rib-data-model-10 (work in progress), February
December 2017. 2018.
[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-
skipping to change at page 26, line 9 skipping to change at page 27, line 21
<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,
<https://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, <https://www.rfc-editor.org/info/rfc854>. 1983, <https://www.rfc-editor.org/info/rfc854>.
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122,
DOI 10.17487/RFC1122, October 1989,
<https://www.rfc-editor.org/info/rfc1122>.
[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,
<https://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,
<https://www.rfc-editor.org/info/rfc1918>. <https://www.rfc-editor.org/info/rfc1918>.
[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,
<https://www.rfc-editor.org/info/rfc2629>. <https://www.rfc-editor.org/info/rfc2629>.
[RFC3176] Phaal, P., Panchen, S., and N. McKee, "InMon Corporation's
sFlow: A Method for Monitoring Traffic in Switched and
Routed Networks", RFC 3176, DOI 10.17487/RFC3176,
September 2001, <https://www.rfc-editor.org/info/rfc3176>.
[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,
<https://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,
<https://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, <https://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,
<https://www.rfc-editor.org/info/rfc3646>. <https://www.rfc-editor.org/info/rfc3646>.
[RFC3719] Parker, J., Ed., "Recommendations for Interoperable
Networks using Intermediate System to Intermediate System
(IS-IS)", RFC 3719, DOI 10.17487/RFC3719, February 2004,
<https://www.rfc-editor.org/info/rfc3719>.
[RFC3776] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to [RFC3776] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to
Protect Mobile IPv6 Signaling Between Mobile Nodes and Protect Mobile IPv6 Signaling Between Mobile Nodes and
Home Agents", RFC 3776, DOI 10.17487/RFC3776, June 2004, Home Agents", RFC 3776, DOI 10.17487/RFC3776, June 2004,
<https://www.rfc-editor.org/info/rfc3776>. <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,
<https://www.rfc-editor.org/info/rfc3810>. <https://www.rfc-editor.org/info/rfc3810>.
skipping to change at page 27, line 37 skipping to change at page 29, line 13
<https://www.rfc-editor.org/info/rfc4877>. <https://www.rfc-editor.org/info/rfc4877>.
[RFC5218] Thaler, D. and B. Aboba, "What Makes for a Successful [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,
<https://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,
<https://www.rfc-editor.org/info/rfc5424>. <https://www.rfc-editor.org/info/rfc5424>.
[RFC5474] Duffield, N., Ed., Chiou, D., Claise, B., Greenberg, A.,
Grossglauser, M., and J. Rexford, "A Framework for Packet
Selection and Reporting", RFC 5474, DOI 10.17487/RFC5474,
March 2009, <https://www.rfc-editor.org/info/rfc5474>.
[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,
<https://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,
<https://www.rfc-editor.org/info/rfc6177>. <https://www.rfc-editor.org/info/rfc6177>.
skipping to change at page 28, line 23 skipping to change at page 30, line 5
[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, <https://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,
<https://www.rfc-editor.org/info/rfc6540>. <https://www.rfc-editor.org/info/rfc6540>.
[RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken,
"Specification of the IP Flow Information Export (IPFIX)
Protocol for the Exchange of Flow Information", STD 77,
RFC 7011, DOI 10.17487/RFC7011, September 2013,
<https://www.rfc-editor.org/info/rfc7011>.
[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,
<https://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,
<https://www.rfc-editor.org/info/rfc7223>. <https://www.rfc-editor.org/info/rfc7223>.
 End of changes. 92 change blocks. 
150 lines changed or deleted 234 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/