draft-ietf-v6ops-ipv6rtr-reqs-03.txt   draft-ietf-v6ops-ipv6rtr-reqs-04.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 21, 2018 Comcast Expires: November 27, 2018 Comcast
R. White, Ed. R. White, Ed.
LinkedIn LinkedIn
March 20, 2018 May 26, 2018
Requirements for IPv6 Routers Requirements for IPv6 Routers
draft-ietf-v6ops-ipv6rtr-reqs-03 draft-ietf-v6ops-ipv6rtr-reqs-04
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
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 necessary background to editors and contributors is to provide the necessary background to
guide equipment manufacturers, protocol implementors, 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
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 21, 2018. This Internet-Draft will expire on November 27, 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
skipping to change at page 3, line 4 skipping to change at page 3, line 4
4.3. Flow State and Traceability . . . . . . . . . . . . . . . 17 4.3. Flow State and Traceability . . . . . . . . . . . . . . . 17
5. Requirements Related to IPv6 Forwarding and Addressing . . . 17 5. Requirements Related to IPv6 Forwarding and Addressing . . . 17
5.1. The IPv6 Address is not a Host Identifier . . . . . . . . 17 5.1. The IPv6 Address is not a Host Identifier . . . . . . . . 17
5.2. Router IPv6 Addresses . . . . . . . . . . . . . . . . . . 18 5.2. Router IPv6 Addresses . . . . . . . . . . . . . . . . . . 18
5.3. The Maximum Transmission Unit . . . . . . . . . . . . . . 19 5.3. The Maximum Transmission Unit . . . . . . . . . . . . . . 19
5.4. ICMP Considerations . . . . . . . . . . . . . . . . . . . 20 5.4. ICMP Considerations . . . . . . . . . . . . . . . . . . . 20
5.5. Machine Access to the Forwarding Table . . . . . . . . . 21 5.5. Machine Access to the Forwarding Table . . . . . . . . . 21
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 . . . . 23
5.10. IPv6 Mobility Support . . . . . . . . . . . . . . . . . . 22 5.10. IPv6 Mobility Support . . . . . . . . . . . . . . . . . . 23
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. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
8. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 24 8. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 25
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
9.1. Normative References . . . . . . . . . . . . . . . . . . 25 9.1. Normative References . . . . . . . . . . . . . . . . . . 25
9.2. Informative References . . . . . . . . . . . . . . . . . 25 9.2. Informative References . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
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). The "use and forwarding for Internet Protocol version 6 (IPv6). The "use and
applicability" section below contains more information on the applicability" section below contains more information on the
specific target of this draft, and the envisioned use of the draft. specific target of this draft, and the envisioned use of the draft.
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
skipping to change at page 3, line 49 skipping to change at page 3, line 49
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, Erik Muller, Shawn Zandi, Pete Lumbis, Fred Baker, James Woodyatt, Erik Muller,
and Lee Howard contributed significant text and ideas to this draft. Lee Howard, and Joe Clarke contributed significant text and ideas to
this draft.
1.2. Acknowledgments 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 Mikael Coitti, Brian E. Carpenter, Tim Chown, Peter Lothberg, and Mikael
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
skipping to change at page 5, line 9 skipping to change at page 5, line 9
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.
Because this document is designed to be a reference point rather than Because this document is designed to be a reference point rather than
a best common practice or a standard, this document does not use a best common practice or a standard, this document does not use
[RFC2119] 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.
skipping to change at page 5, line 42 skipping to change at page 5, line 42
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 [RFC1122]: "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
application should not degrade in a way that will cause the application should not degrade in a way that will cause the
failure of adjacent systems when possible. For instance, when a failure of adjacent systems when possible. For instance, when a
routing protocol implementation fails, it should not do so in a routing protocol implementation fails, it should not do so in a
way that will cause the spreading of or continued existence of way that will cause the spreading of or continued existence of
false reachability information, nor should it fail in a way that false reachability information, nor should it fail in a way that
overloads adjacent routers or interacting protocols and causing a overloads adjacent routers or interacting protocols and causing a
cascading failure. cascading failure.
skipping to change at page 11, line 11 skipping to change at page 11, line 4
routers actually have this set of tables and interactions, and some routers actually have this set of tables and interactions, and some
have many more moving parts. This model is simply used as a common have many more moving parts. This model is simply used as a common
reference to promote understanding. reference to promote understanding.
+-------------+ +-------------+ +-------------+ +-------------+
| Candidate | | Startup | | Candidate | | Startup |
| Config |<--+ +-->| Config | | Config |<--+ +-->| Config |
+--+----------+ | | +-------+-----+ +--+----------+ | | +-------+-----+
| | | | | | | |
v | | v v | | v
+-----------------+----+-----------------+ +-----------------+----+-----------------+
| Running Configuration +------>----------+ | Running Configuration |
+---+------------------------------------+
|
| // configuration transformations
|
+---+------------------------------------+
| Intended Configuration |
+---+------------------------------------+
|
| // changes applied subject to local factors
|
+---+------------------------------------+
| Operational Configuration +------>----------+
+---+----------+----------+----------+---+ | +---+----------+----------+----------+---+ |
| | | | | | | | | |
v | | | | v | | | |
+-------+ | | | | +-------+ | | | |
| IS-IS |<-----------------------------------> Adjacent | | IS-IS |<-----------------------------------> Adjacent |
+---+---+ v | | Routers | +---+---+ v | | Routers |
| +-------+ | | | | +-------+ | | |
| | BGP |<------------------------> Peers | | | BGP |<------------------------> Peers |
| +---+---+ v | | | +---+---+ v | |
| | +-------+ | | | | +-------+ | |
skipping to change at page 11, line 47 skipping to change at page 12, line 4
+---+------------------------------------+ | +---+------------------------------------+ |
| Forwarding Information Base (FIB) | | | Forwarding Information Base (FIB) | |
+---+----------+---------------------+---+ | +---+----------+---------------------+---+ |
| | | | | | | |
+---+---+ +---+---+ +---+---+ | +---+---+ +---+---+ +---+---+ |
| Int 1 | | Int 2 | ... | Int X | <---------------+ | Int 1 | | Int 2 | ... | Int X | <---------------+
+-------+ +-------+ +-------+ +-------+ +-------+ +-------+
^ | ^ |
| v | v
Packets In Packets Out Packets In Packets Out
Figure 2 Figure 2
The configuration datastores in this figure follow [RFC8342].
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 targeting increased their reliance on automation, specifically targeting
machine to machine interfaces, such as Remote Procedure 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, Across all interface types, devices should provide and use complete,
idempotent, stateless configurations. Further, default settings idempotent, stateless configurations. Further, default settings
should be accessible in some way, even if they are hidden by default should be accessible in some way, even if they are hidden by default
for configuration readability. 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, running,
running configurations in the router model shown above. In order to intended, and operational configurations in the router model shown
deploy networks at scale, operators rely on automated management of above. In order to deploy networks at scale, operators rely on
router configuration. This effort has traditionally focused on automated management of router configuration. This effort has
Simple Network Management Protocol (SNMP) Management Information Base traditionally focused on screen scraping and other proprietary
(MIBs). In the future, operators expect to move towards open source/ methods of "reading" and "writing" configuration information through
open standards YANG models. a CLI. In the future, operators expect to move towards open source/
open standards YANG models, regardless of how these are encoded and/
or carried (or marshaled).
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 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 [RFC8343]: 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 [RFC8344]: 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 [RFC8349]: A YANG Data Model for Routing Management (NMDA Version)
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
(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
skipping to change at page 13, line 33 skipping to change at page 13, line 39
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 zccess through an
access Ethernet management port
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.
who prefer to use some other mechanism for address management and
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. SLAAC must be able to be disabled by operators who
prefer to use some other mechanism for address management and
assignment (specifically for customer facing edge ports).
o [RFC7217]: Semantically Opaque Interface Identifiers should be o [RFC7217]: Semantically Opaque Interface Identifiers should be
supported unless there's a need to embed MAC address. 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 should be o [RFC7527]: Enhanced Duplicate Address Detection should be
supported. supported.
skipping to change at page 16, line 19 skipping to change at page 16, line 22
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 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]/[RFC8040]: NETCONF/RESTCONF transporting telemetry o [RFC6241] and [RFC8040]: NETCONF/RESTCONF transporting telemetry
formatted according to YANG (see above) formatted according to YANG (see above)
o [I-D.ietf-i2rs-yang-l2-network-topology]: An I2RS model for layer
2 topologies
o [I-D.ietf-netconf-yang-push]: YANG Datastore Subscription
o [RFC5424]: Syslog o [RFC5424]: Syslog
o gRPC based telemetry interfaces [GRPC] o gRPC based telemetry interfaces [GRPC]
o SNMP as appropriate o Simple Network Management Protocol (SNMP) MIBs 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
skipping to change at page 17, line 19 skipping to change at page 17, line 27
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], or some other flow state mechanism. described in [RFC5474], or some other flow state mechanism.
In-situ Operational and Management (iOAM) is a technology that being
developed at the time of this writing; see [I-D.ietf-ippm-ioam-data].
Operators and vendors should consider the deployment of iOAM to
provide deeper information about flow and topology information.
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.
skipping to change at page 25, line 47 skipping to change at page 26, line 15
[I-D.gont-opsec-icmp-ingress-filtering] [I-D.gont-opsec-icmp-ingress-filtering]
Gont, F., Hunter, R., Massar, J., and W. LIU, "Defeating Gont, F., Hunter, R., Massar, J., and W. LIU, "Defeating
Attacks which employ Forged ICMPv4/ICMPv6 Error Messages", Attacks which employ Forged ICMPv4/ICMPv6 Error Messages",
draft-gont-opsec-icmp-ingress-filtering-03 (work in draft-gont-opsec-icmp-ingress-filtering-03 (work in
progress), July 2017. progress), July 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-13 (work in progress),
March 2018. April 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., Chen, M., amit.dass@ericsson.com, a., Wang, L., Chen, M., Dass, A., Ananthakrishnan, H., Kini,
Ananthakrishnan, H., Kini, S., and N. Bahadur, "A YANG S., and N. Bahadur, "A YANG Data Model for Routing
Data Model for Routing Information Base (RIB)", draft- Information Base (RIB)", draft-ietf-i2rs-rib-data-model-15
ietf-i2rs-rib-data-model-10 (work in progress), February (work in progress), May 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-04 (work in progress), March 2018. topology-04 (work in progress), March 2018.
[I-D.ietf-ippm-ioam-data]
Brockners, F., Bhandari, S., Pignataro, C., Gredler, H.,
Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov,
P., Chang, R., daniel.bernier@bell.ca, d., and J. Lemon,
"Data Fields for In-situ OAM", draft-ietf-ippm-ioam-
data-02 (work in progress), March 2018.
[I-D.ietf-netconf-yang-push]
Clemm, A., Voit, E., Prieto, A., Tripathy, A., Nilsen-
Nygaard, E., Bierman, A., and B. Lengyel, "YANG Datastore
Subscription", draft-ietf-netconf-yang-push-15 (work in
progress), February 2018.
[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 30, line 15 skipping to change at page 30, line 39
[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>.
[RFC7934] Colitti, L., Cerf, V., Cheshire, S., and D. Schinazi, [RFC7934] Colitti, L., Cerf, V., Cheshire, S., and D. Schinazi,
"Host Address Availability Recommendations", BCP 204, "Host Address Availability Recommendations", BCP 204,
RFC 7934, DOI 10.17487/RFC7934, July 2016, RFC 7934, DOI 10.17487/RFC7934, July 2016,
<https://www.rfc-editor.org/info/rfc7934>. <https://www.rfc-editor.org/info/rfc7934>.
[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>.
[RFC7991] Hoffman, P., "The "xml2rfc" Version 3 Vocabulary",
RFC 7991, DOI 10.17487/RFC7991, December 2016,
<https://www.rfc-editor.org/info/rfc7991>.
[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 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>. <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,
skipping to change at page 31, line 18 skipping to change at page 31, line 41
[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>.
[RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
and R. Wilton, "Network Management Datastore Architecture
(NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018,
<https://www.rfc-editor.org/info/rfc8342>.
[RFC8343] Bjorklund, M., "A YANG Data Model for Interface [RFC8343] Bjorklund, M., "A YANG Data Model for Interface
Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, Management", RFC 8343, DOI 10.17487/RFC8343, March 2018,
<https://www.rfc-editor.org/info/rfc8343>. <https://www.rfc-editor.org/info/rfc8343>.
[RFC8344] Bjorklund, M., "A YANG Data Model for IP Management", [RFC8344] Bjorklund, M., "A YANG Data Model for IP Management",
RFC 8344, DOI 10.17487/RFC8344, March 2018, RFC 8344, DOI 10.17487/RFC8344, March 2018,
<https://www.rfc-editor.org/info/rfc8344>. <https://www.rfc-editor.org/info/rfc8344>.
[RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N.,
Ananthakrishnan, H., and X. Liu, "A YANG Data Model for Ananthakrishnan, H., and X. Liu, "A YANG Data Model for
Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March
2018, <https://www.rfc-editor.org/info/rfc8345>. 2018, <https://www.rfc-editor.org/info/rfc8345>.
[RFC8346] Clemm, A., Medved, J., Varga, R., Liu, X., [RFC8346] 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", RFC 8346, DOI 10.17487/RFC8346, for Layer 3 Topologies", RFC 8346, DOI 10.17487/RFC8346,
March 2018, <https://www.rfc-editor.org/info/rfc8346>. March 2018, <https://www.rfc-editor.org/info/rfc8346>.
[RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for
Routing Management (NMDA Version)", RFC 8349,
DOI 10.17487/RFC8349, March 2018,
<https://www.rfc-editor.org/info/rfc8349>.
Authors' Addresses Authors' Addresses
Zaid Ali Kahn (editor) Zaid Ali Kahn (editor)
LinkedIn LinkedIn
CA CA
USA USA
Email: zaid@linkedin.com Email: zaid@linkedin.com
John Brzozowski (editor) John Brzozowski (editor)
 End of changes. 35 change blocks. 
46 lines changed or deleted 95 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/