draft-ietf-v6ops-ipv6rtr-reqs-02.txt   draft-ietf-v6ops-ipv6rtr-reqs-03.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: September 5, 2018 Comcast Expires: September 21, 2018 Comcast
R. White, Ed. R. White, Ed.
LinkedIn LinkedIn
March 4, 2018 March 20, 2018
Requirements for IPv6 Routers Requirements for IPv6 Routers
draft-ietf-v6ops-ipv6rtr-reqs-02 draft-ietf-v6ops-ipv6rtr-reqs-03
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
interconnected 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 interconnected environment can have a major operator in such an interconnected environment can have a major
impact on the stability of the overall Internet (as a system). The impact on the stability of the overall Internet (as a system). The
skipping to change at page 2, line 4 skipping to change at page 2, line 4
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 September 5, 2018. This Internet-Draft will expire on September 21, 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 . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 4 1.2. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 4
1.3. Use and Applicability . . . . . . . . . . . . . . . . . . 4 1.3. Use and Applicability . . . . . . . . . . . . . . . . . . 4
2. Review of the Internet Architecture . . . . . . . . . . . . . 5 2. Review of the Internet Architecture . . . . . . . . . . . . . 5
2.1. Robustness Principle . . . . . . . . . . . . . . . . . . 5 2.1. Robustness Principle . . . . . . . . . . . . . . . . . . 5
2.2. Complexity . . . . . . . . . . . . . . . . . . . . . . . 7 2.2. Complexity . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.1. Elegance . . . . . . . . . . . . . . . . . . . . . . 7 2.2.1. Elegance . . . . . . . . . . . . . . . . . . . . . . 7
2.2.2. Trade-offs . . . . . . . . . . . . . . . . . . . . . 8 2.2.2. Trade-offs . . . . . . . . . . . . . . . . . . . . . 8
2.3. Layered Structure . . . . . . . . . . . . . . . . . . . . 9 2.3. Layered Structure . . . . . . . . . . . . . . . . . . . . 9
2.4. Routers . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.4. Routers . . . . . . . . . . . . . . . . . . . . . . . . . 10
3. Requirements Related to Device Management and Security . . . 12 3. Requirements Related to Device Management and Security . . . 12
skipping to change at page 3, line 11 skipping to change at page 3, line 11
5.6. Processing IPv6 Extension Headers . . . . . . . . . . . . 22 5.6. Processing IPv6 Extension Headers . . . . . . . . . . . . 22
5.7. IPv6 Operation by Default . . . . . . . . . . . . . . . . 22 5.7. IPv6 Operation by Default . . . . . . . . . . . . . . . . 22
5.8. IPv6 Only Operation . . . . . . . . . . . . . . . . . . . 22 5.8. IPv6 Only Operation . . . . . . . . . . . . . . . . . . . 22
5.9. Prefix Length Handling in IPv6 Packet Forwarding . . . . 22 5.9. Prefix Length Handling in IPv6 Packet Forwarding . . . . 22
5.10. IPv6 Mobility Support . . . . . . . . . . . . . . . . . . 22 5.10. IPv6 Mobility Support . . . . . . . . . . . . . . . . . . 22
6. Security Considerations . . . . . . . . . . . . . . . . . . . 23 6. Security Considerations . . . . . . . . . . . . . . . . . . . 23
6.1. Robustness and Security . . . . . . . . . . . . . . . . . 23 6.1. Robustness and Security . . . . . . . . . . . . . . . . . 23
6.2. Programmable Device Access and Security . . . . . . . . . 24 6.2. Programmable Device Access and Security . . . . . . . . . 24
6.3. Zero Touch Provisioning and Security . . . . . . . . . . 24 6.3. Zero Touch Provisioning and Security . . . . . . . . . . 24
6.4. Defaulting to IPv6 Forwarding and Security . . . . . . . 24 6.4. Defaulting to IPv6 Forwarding and Security . . . . . . . 24
7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 24 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 8. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 24
8.1. Normative References . . . . . . . . . . . . . . . . . . 25 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
8.2. Informative References . . . . . . . . . . . . . . . . . 25 9.1. Normative References . . . . . . . . . . . . . . . . . . 25
9.2. Informative References . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 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). The "use and
(but is not limited to) the devices described below. applicability" section below contains more information on the
specific target of this draft, and the envisioned use of the draft.
o Devices which are primarily designed to forward traffic between
multiple interfaces. These are normally referred to by the
Internet community as routers or, in some cases, intermediate
systems.
o Devices which are designed to modify packets rather than "just"
forwarding them. These are often referred to by the Internet
community as middleboxes. See [RFC7663] for a fuller definition
of middleboxes.
Readers should recognize that while this memo applies to IPv6, Readers should recognize that while this memo applies to IPv6,
routers and middleboxes IPv6 packets will often also process IPv4 routers and middleboxes IPv6 packets will often also process IPv4
packets, forward based on MPLS labels, and potentially process many packets, forward based on MPLS labels, and potentially process many
other protocols. This memo will only discuss IPv4, MPLS, and other other protocols. This memo will only discuss IPv4, MPLS, and other
protocols as they impact the behavior of an IPv6 forwarding device; protocols as they impact the behavior of an IPv6 forwarding device;
no attempt is made to specify requirements for protocols other than no attempt is made to specify requirements for protocols other than
IPv6. The reader should, therefore, not count on this document as a IPv6. The reader should, therefore, not count on this document as a
"sole source of truth," but rather use this document as a guide. "sole source of truth," but rather use this document as a guide.
skipping to change at page 4, line 26 skipping to change at page 4, line 19
Abrahamsson for their comments, edits, and ideas on the text of this Abrahamsson for their comments, edits, and ideas on the text of this
draft. draft.
1.3. Use and Applicability 1.3. Use and Applicability
The conceived use of this draft is as a reference point. The first 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 part of the draft is designed to help IPv6 implementors and network
operators to understand Internet and Internetworking technologies, so operators to understand Internet and Internetworking technologies, so
they can better understand the context of IPv6. The second part of they can better understand the context of IPv6. The second part of
this draft outlines a common set of requirements for devices which this draft outlines a common set of requirements for devices which
are designed to forward IPv6 traffic. The primary use of these are designed to forward IPv6 traffic. This can include (but is not
sections is for operators to be able to point to a common set of limited to) the devices described below.
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 o Devices which are primarily designed to forward traffic between
features expected of every IPv6 forwarding device is useful. more than two interfaces. These are normally referred to by the
Specifically: Internet community as routers or, in some cases, intermediate
systems.
o Devices which are designed to modify packets rather than "just"
forwarding them. These are often referred to by the Internet
community as middleboxes. See [RFC7663] for a fuller definition
of middleboxes.
This draft is not designed to apply to consumer devices, such as
smart devices (refrigerators, light bulbs, garage door openers,
etc.), Internet of Things (IoT) devices, cell phones primarily used
as an end user device (such as checking email, social media, games,
and use as a voice device), and other devices of this class. It is
up to each provider or equipment purchaser to determine how best to
apply this document to their environment.
The intended use of this document 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. 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 o If every IPv6 deployment situation is unique, and requires a
different set of features, there will not be a solid definition of different set of features, there will not be a solid definition of
what an IPv6 forwarding device is, or performs. This fragments what an IPv6 forwarding device is, or performs. This fragments
the concept of IPv6 forwarding devices in an unhelpful way, the concept of IPv6 forwarding devices in an unhelpful way,
especially as IPv6 deployment is already seen as difficult. especially as IPv6 deployment is already seen as difficult.
o It encourages developers and vendors to code a multitude of o It encourages developers and vendors to code a multitude of
different IPv6 stacks, one for each possible set of features. different IPv6 stacks, one for each possible set of features.
This fragments the experience with these stacks, potentially This fragments the experience with these stacks, potentially
preventing the development of a well designed, fully featured preventing the development of a well designed, fully featured
stacks the entire community can rely on, stacks the entire community can rely on,
However, because this document is designed to be a reference point Because this document is designed to be a reference point rather than
rather than a best common practice or a standard, this document does a best common practice or a standard, this document does not use
not use upper case "must" and "should" throughout. Rather, it uses [RFC2119] upper case "must" and "should" throughout. Rather, it uses
lower case "must" and "should" throughout, anticipating operators lower case "must" and "should" throughout, anticipating operators
will find such guidance clear and useful. 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
skipping to change at page 6, line 32 skipping to change at page 6, line 36
Protocol and implementation design should take into account use Protocol and implementation design should take into account use
cases that have not yet been thought of by building flexibility cases that have not yet been thought of by building flexibility
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. [RFC8170] provides sound advice
[I-D.iab-protocol-transitions] provides sound advice on protocol on protocol transition planning and mechanisms.
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
skipping to change at page 12, line 52 skipping to change at page 12, line 52
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 [RFC8343]: 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 [RFC8344]: 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
skipping to change at page 16, line 22 skipping to change at page 16, line 22
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 readability, 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]/[RFC8040]: NETCONF/RESTCONF transporting telemetry
according to YANG (see above) formatted 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.
skipping to change at page 17, line 5 skipping to change at page 17, line 5
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 [RFC8346]: An I2RS model for layer 3 topologies
topologies
o [I-D.ietf-i2rs-yang-network-topo]: A Data Model for Network o [RFC8345]: A Data Model for Network Topologies
Topologies
4.3. Flow State and Traceability 4.3. Flow State and Traceability
Network operators frequently need to observe and understand the Network operators frequently need to observe and understand the
types, sources, and destinations of traffic passing through devices. types, sources, and destinations of traffic passing through devices.
For example, information about traffic flows may be used to identify For example, information about traffic flows may be used to identify
abuse (such as DDOS attacks) or to plan network expansions based on abuse (such as DDOS attacks) or to plan network expansions based on
traffic patterns. To support insight and analysis of this traffic, traffic patterns. To support insight and analysis of this traffic,
IPv6 devices should support IPFIX as described in [RFC7011], PSAMP as IPv6 devices should support IPFIX as described in [RFC7011], PSAMP as
described in [RFC5474], sFlow as described in [RFC7011]. described in [RFC5474], or some other flow state mechanism.
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
skipping to change at page 18, line 18 skipping to change at page 18, line 18
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 ([RFC6547] 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 is typically only performed to the nibble o Although aggregation is typically only performed to the nibble
boundaries 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
skipping to change at page 20, line 50 skipping to change at page 20, line 50
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 rate limit the generation of ICMP echo and echo responses o Should rate limit the generation of ICMP echo and echo responses
by default (for instance, using a token bucket method as described by default (for instance, using a token bucket method as described
in [RFC4443]). The device should support the configuration of not in [RFC4443]). The device should support the configuration of not
generating ICMP echo and echo response packets to prevent topology generating ICMP echo, echo response, and time exceeded packets to
discovery. prevent topology discovery.
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.
skipping to change at page 24, line 44 skipping to change at page 24, line 44
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. IANA Considerations
This document has no actions for IANA.
8. 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 9. References
8.1. Normative References 9.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,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
8.2. Informative References 9.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>.
[COMPLEXLAYER] [COMPLEXLAYER]
Meyer, D., "Macro Trends, Architecture, and the Hidden Meyer, D., "Macro Trends, Architecture, and the Hidden
Nature of Complexity", 2010, Nature of Complexity", 2010,
<http://www.slideshare.net/dmm613/ <http://www.slideshare.net/dmm613/
macro-trends-complexityandsdn-32951199>. macro-trends-complexityandsdn-32951199>.
[DoD] Wikipedia, "The Internet Protocol Suite", 2016, [DoD] Wikipedia, "The Internet Protocol Suite", 2016,
<https://en.wikipedia.org/wiki/Internet_protocol_suite>. <https://en.wikipedia.org/wiki/Internet_protocol_suite>.
[GRPC] gRPC, "gRPC", 2016, <http://www.grpc.io>. [GRPC] gRPC, "gRPC", 2016, <http://www.grpc.io>.
[I-D.gont-opsec-icmp-ingress-filtering] [I-D.gont-opsec-icmp-ingress-filtering]
Gont, F., Hunter, R., Massar, J., and S. LIU, "Defeating Gont, F., Hunter, R., Massar, J., and W. LIU, "Defeating
Attacks which employ Forged ICMP/ICMPv6 Error Messages", Attacks which employ Forged ICMPv4/ICMPv6 Error Messages",
draft-gont-opsec-icmp-ingress-filtering-02 (work in draft-gont-opsec-icmp-ingress-filtering-03 (work in
progress), March 2016. progress), July 2017.
[I-D.iab-protocol-transitions]
Thaler, D., "Planning for Protocol Adoption and Subsequent
Transitions", draft-iab-protocol-transitions-08 (work in
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-12 (work in progress), bis", draft-ietf-dhc-rfc3315bis-12 (work in progress),
March 2018. 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,
skipping to change at page 26, line 27 skipping to change at page 26, line 27
[I-D.ietf-i2rs-rib-data-model] [I-D.ietf-i2rs-rib-data-model]
Wang, L., Chen, M., amit.dass@ericsson.com, a., Wang, L., Chen, M., amit.dass@ericsson.com, a.,
Ananthakrishnan, H., Kini, S., and N. Bahadur, "A YANG Ananthakrishnan, H., Kini, S., and N. Bahadur, "A YANG
Data Model for Routing Information Base (RIB)", draft- Data Model for Routing Information Base (RIB)", draft-
ietf-i2rs-rib-data-model-10 (work in progress), February ietf-i2rs-rib-data-model-10 (work in progress), February
2018. 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-04 (work in progress), March 2018.
[I-D.ietf-i2rs-yang-l3-topology]
Clemm, A., Medved, J., Varga, R., Liu, X.,
Ananthakrishnan, H., and N. Bahadur, "A YANG Data Model
for Layer 3 Topologies", draft-ietf-i2rs-yang-
l3-topology-16 (work in progress), December 2017.
[I-D.ietf-i2rs-yang-network-topo]
Clemm, A., Medved, J., Varga, R., Bahadur, N.,
Ananthakrishnan, H., and X. Liu, "A Data Model for Network
Topologies", draft-ietf-i2rs-yang-network-topo-20 (work in
progress), December 2017.
[I-D.ietf-netconf-restconf]
Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", draft-ietf-netconf-restconf-18 (work in
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/ <https://www.joelonsoftware.com/2002/11/11/
the-law-of-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>.
skipping to change at page 27, line 35 skipping to change at page 27, line 19
[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,
DOI 10.17487/RFC2629, June 1999,
<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
Text on Security Considerations", BCP 72, RFC 3552,
DOI 10.17487/RFC3552, July 2003,
<https://www.rfc-editor.org/info/rfc3552>.
[RFC3627] Savola, P., "Use of /127 Prefix Length Between Routers
Considered Harmful", RFC 3627, DOI 10.17487/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 [RFC3719] Parker, J., Ed., "Recommendations for Interoperable
Networks using Intermediate System to Intermediate System Networks using Intermediate System to Intermediate System
(IS-IS)", RFC 3719, DOI 10.17487/RFC3719, February 2004, (IS-IS)", RFC 3719, DOI 10.17487/RFC3719, February 2004,
<https://www.rfc-editor.org/info/rfc3719>. <https://www.rfc-editor.org/info/rfc3719>.
skipping to change at page 30, line 5 skipping to change at page 29, line 18
[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>.
[RFC6547] George, W., "RFC 3627 to Historic Status", RFC 6547,
DOI 10.17487/RFC6547, February 2012,
<https://www.rfc-editor.org/info/rfc6547>.
[RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken,
"Specification of the IP Flow Information Export (IPFIX) "Specification of the IP Flow Information Export (IPFIX)
Protocol for the Exchange of Flow Information", STD 77, Protocol for the Exchange of Flow Information", STD 77,
RFC 7011, DOI 10.17487/RFC7011, September 2013, RFC 7011, DOI 10.17487/RFC7011, September 2013,
<https://www.rfc-editor.org/info/rfc7011>. <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
Management", RFC 7223, DOI 10.17487/RFC7223, May 2014,
<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,
<https://www.rfc-editor.org/info/rfc7224>. <https://www.rfc-editor.org/info/rfc7224>.
[RFC7277] Bjorklund, M., "A YANG Data Model for IP Management",
RFC 7277, DOI 10.17487/RFC7277, June 2014,
<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, <https://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,
<https://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.,
skipping to change at page 31, line 5 skipping to change at page 30, line 15
[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,
<https://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,
<https://www.rfc-editor.org/info/rfc7663>. <https://www.rfc-editor.org/info/rfc7663>.
[RFC7749] Reschke, J., "The "xml2rfc" Version 2 Vocabulary",
RFC 7749, DOI 10.17487/RFC7749, February 2016,
<https://www.rfc-editor.org/info/rfc7749>.
[RFC7772] Yourtchenko, A. and L. Colitti, "Reducing Energy [RFC7772] Yourtchenko, A. and L. Colitti, "Reducing Energy
Consumption of Router Advertisements", BCP 202, RFC 7772, Consumption of Router Advertisements", BCP 202, RFC 7772,
DOI 10.17487/RFC7772, February 2016, DOI 10.17487/RFC7772, February 2016,
<https://www.rfc-editor.org/info/rfc7772>. <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, <https://www.rfc-editor.org/info/rfc7922>. 2016, <https://www.rfc-editor.org/info/rfc7922>.
skipping to change at page 31, line 30 skipping to change at page 30, line 44
[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,
<https://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,
<https://www.rfc-editor.org/info/rfc8028>. <https://www.rfc-editor.org/info/rfc8028>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>.
[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,
<https://www.rfc-editor.org/info/rfc8106>. <https://www.rfc-editor.org/info/rfc8106>.
[RFC8170] Thaler, D., Ed., "Planning for Protocol Adoption and
Subsequent Transitions", RFC 8170, DOI 10.17487/RFC8170,
May 2017, <https://www.rfc-editor.org/info/rfc8170>.
[RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., [RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed.,
"Path MTU Discovery for IP version 6", STD 87, RFC 8201, "Path MTU Discovery for IP version 6", STD 87, RFC 8201,
DOI 10.17487/RFC8201, July 2017, DOI 10.17487/RFC8201, July 2017,
<https://www.rfc-editor.org/info/rfc8201>. <https://www.rfc-editor.org/info/rfc8201>.
[RFC8273] Brzozowski, J. and G. Van de Velde, "Unique IPv6 Prefix [RFC8273] Brzozowski, J. and G. Van de Velde, "Unique IPv6 Prefix
per Host", RFC 8273, DOI 10.17487/RFC8273, December 2017, per Host", RFC 8273, DOI 10.17487/RFC8273, December 2017,
<https://www.rfc-editor.org/info/rfc8273>. <https://www.rfc-editor.org/info/rfc8273>.
[RFC8343] Bjorklund, M., "A YANG Data Model for Interface
Management", RFC 8343, DOI 10.17487/RFC8343, March 2018,
<https://www.rfc-editor.org/info/rfc8343>.
[RFC8344] Bjorklund, M., "A YANG Data Model for IP Management",
RFC 8344, DOI 10.17487/RFC8344, March 2018,
<https://www.rfc-editor.org/info/rfc8344>.
[RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N.,
Ananthakrishnan, H., and X. Liu, "A YANG Data Model for
Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March
2018, <https://www.rfc-editor.org/info/rfc8345>.
[RFC8346] Clemm, A., Medved, J., Varga, R., Liu, X.,
Ananthakrishnan, H., and N. Bahadur, "A YANG Data Model
for Layer 3 Topologies", RFC 8346, DOI 10.17487/RFC8346,
March 2018, <https://www.rfc-editor.org/info/rfc8346>.
Authors' Addresses Authors' Addresses
Zaid Ali Kahn (editor) Zaid Ali Kahn (editor)
LinkedIn LinkedIn
xxx CA
xxx, CA xxx
USA USA
Email: zaid@linkedin.com Email: zaid@linkedin.com
John Brzozowski (editor) John Brzozowski (editor)
Comcast Comcast
xxx
xxx, xxx xxx
USA USA
Email: John_Brzozowski@comcast.com Email: John_Brzozowski@comcast.com
Russ White (editor) Russ White (editor)
LinkedIn LinkedIn
Oak Island, NC 28465 Oak Island, NC 28465
USA USA
Email: russ@riw.us Email: russ@riw.us
 End of changes. 38 change blocks. 
112 lines changed or deleted 104 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/