draft-ietf-6man-rfc6434-bis-04.txt   draft-ietf-6man-rfc6434-bis-05.txt 
Internet Engineering Task Force T. Chown Internet Engineering Task Force T. Chown
Internet-Draft Jisc Internet-Draft Jisc
Obsoletes: 6434 (if approved) J. Loughney Obsoletes: 6434 (if approved) J. Loughney
Intended status: Best Current Practice Intel Intended status: Best Current Practice Intel
Expires: August 26, 2018 T. Winters Expires: August 31, 2018 T. Winters
UNH-IOL UNH-IOL
February 22, 2018 February 27, 2018
IPv6 Node Requirements IPv6 Node Requirements
draft-ietf-6man-rfc6434-bis-04 draft-ietf-6man-rfc6434-bis-05
Abstract Abstract
This document defines requirements for IPv6 nodes. It is expected This document defines requirements for IPv6 nodes. It is expected
that IPv6 will be deployed in a wide range of devices and situations. that IPv6 will be deployed in a wide range of devices and situations.
Specifying the requirements for IPv6 nodes allows IPv6 to function Specifying the requirements for IPv6 nodes allows IPv6 to function
well and interoperate in a large number of situations and well and interoperate in a large number of situations and
deployments. deployments.
This document obsoletes RFC 6434, and in turn RFC 4294. This document obsoletes RFC 6434, and in turn RFC 4294.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
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 August 26, 2018. This Internet-Draft will expire on August 31, 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 27 skipping to change at page 3, line 27
14.2. Neighbor Discovery for IPv6 - RFC 4861 . . . . . . . . . 22 14.2. Neighbor Discovery for IPv6 - RFC 4861 . . . . . . . . . 22
14.3. Stateful Address Autoconfiguration (DHCPv6) - RFC 3315 . 22 14.3. Stateful Address Autoconfiguration (DHCPv6) - RFC 3315 . 22
14.4. IPv6 Prefix Length Recommendation for Forwarding - BCP 14.4. IPv6 Prefix Length Recommendation for Forwarding - BCP
198 . . . . . . . . . . . . . . . . . . . . . . . . . . 22 198 . . . . . . . . . . . . . . . . . . . . . . . . . . 22
15. Constrained Devices . . . . . . . . . . . . . . . . . . . . . 22 15. Constrained Devices . . . . . . . . . . . . . . . . . . . . . 22
16. Network Management . . . . . . . . . . . . . . . . . . . . . 23 16. Network Management . . . . . . . . . . . . . . . . . . . . . 23
16.1. Management Information Base (MIB) Modules . . . . . . . 23 16.1. Management Information Base (MIB) Modules . . . . . . . 23
16.1.1. IP Forwarding Table MIB . . . . . . . . . . . . . . 23 16.1.1. IP Forwarding Table MIB . . . . . . . . . . . . . . 23
16.1.2. Management Information Base for the Internet 16.1.2. Management Information Base for the Internet
Protocol (IP) . . . . . . . . . . . . . . . . . . . 23 Protocol (IP) . . . . . . . . . . . . . . . . . . . 23
16.1.3. Interface MIB . . . . . . . . . . . . . . . . . . . 24 16.1.3. Interface MIB . . . . . . . . . . . . . . . . . . . 23
16.2. YANG Data Models . . . . . . . . . . . . . . . . . . . . 24 16.2. YANG Data Models . . . . . . . . . . . . . . . . . . . . 24
16.2.1. IP Management YANG Model . . . . . . . . . . . . . . 24 16.2.1. IP Management YANG Model . . . . . . . . . . . . . . 24
16.2.2. Interface Management YANG Model . . . . . . . . . . 24 16.2.2. Interface Management YANG Model . . . . . . . . . . 24
17. Security Considerations . . . . . . . . . . . . . . . . . . . 24 17. Security Considerations . . . . . . . . . . . . . . . . . . . 24
18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
19. Authors and Acknowledgments . . . . . . . . . . . . . . . . . 24 19. Authors and Acknowledgments . . . . . . . . . . . . . . . . . 24
19.1. Authors and Acknowledgments (Current Document) . . . . . 24 19.1. Authors and Acknowledgments (Current Document) . . . . . 24
19.2. Authors and Acknowledgments from RFC 6434 . . . . . . . 24 19.2. Authors and Acknowledgments from RFC 6434 . . . . . . . 24
19.3. Authors and Acknowledgments from RFC 4294 . . . . . . . 25 19.3. Authors and Acknowledgments from RFC 4294 . . . . . . . 25
20. Appendix: Changes from RFC 6434 . . . . . . . . . . . . . . . 26 20. Appendix: Changes from RFC 6434 . . . . . . . . . . . . . . . 26
skipping to change at page 11, line 39 skipping to change at page 11, line 39
5.7.2. Minimum MTU considerations 5.7.2. Minimum MTU considerations
While an IPv6 link MTU can be set to 1280 bytes, it is recommended While an IPv6 link MTU can be set to 1280 bytes, it is recommended
that for IPv6 UDP in particular, which includes DNS operation, the that for IPv6 UDP in particular, which includes DNS operation, the
sender use a large MTU if they can, in order to avoid gratuitous sender use a large MTU if they can, in order to avoid gratuitous
fragmentation-caused packet drops. fragmentation-caused packet drops.
5.8. ICMP for the Internet Protocol Version 6 (IPv6) - RFC 4443 5.8. ICMP for the Internet Protocol Version 6 (IPv6) - RFC 4443
ICMPv6 [RFC4443] MUST be supported. "Extended ICMP to Support Multi- ICMPv6 [RFC4443] MUST be supported. "Extended ICMP to Support Multi-
Part Messages" [RFC4884] MAY be supported. Part Messages" [RFC4884] MAY be supported.
5.9. Default Router Preferences and More-Specific Routes - RFC 4191 5.9. Default Router Preferences and More-Specific Routes - RFC 4191
"Default Router Preferences and More-Specific Routes" [RFC4191] "Default Router Preferences and More-Specific Routes" [RFC4191]
provides support for nodes attached to multiple (different) networks, provides support for nodes attached to multiple (different) networks,
each providing routers that advertise themselves as default routers each providing routers that advertise themselves as default routers
via Router Advertisements. In some scenarios, one router may provide via Router Advertisements. In some scenarios, one router may provide
connectivity to destinations the other router does not, and choosing connectivity to destinations the other router does not, and choosing
the "wrong" default router can result in reachability failures. In the "wrong" default router can result in reachability failures. In
order to resolve this scenario IPv6 Nodes MUST implement [RFC4191] order to resolve this scenario IPv6 Nodes MUST implement [RFC4191]
skipping to change at page 12, line 49 skipping to change at page 12, line 49
Nodes that may be deployed in environments where they would benefit Nodes that may be deployed in environments where they would benefit
from such early congestion notification SHOULD implement [RFC3168]. from such early congestion notification SHOULD implement [RFC3168].
In such cases, the updates presented in [RFC8311] may also be In such cases, the updates presented in [RFC8311] may also be
relevant. relevant.
6. Addressing and Address Configuration 6. Addressing and Address Configuration
6.1. IP Version 6 Addressing Architecture - RFC 4291 6.1. IP Version 6 Addressing Architecture - RFC 4291
The IPv6 Addressing Architecture [RFC4291] MUST be supported. The IPv6 Addressing Architecture [RFC4291] MUST be supported.
The current IPv6 Address Architecture is based on a 64-bit boundary The current IPv6 Address Architecture is based on a 64-bit boundary
for subnet prefixes. The reasoning behind this decision is for subnet prefixes. The reasoning behind this decision is
documented in [RFC7421]. documented in [RFC7421].
Implementations MUST also support the Multicast flag updates Implementations MUST also support the Multicast flag updates
documented in [RFC7371] documented in [RFC7371]
6.2. Host Address Availability Recommendations 6.2. Host Address Availability Recommendations
skipping to change at page 15, line 29 skipping to change at page 15, line 29
some of which may require DHCPv6 for stateful address assignment. some of which may require DHCPv6 for stateful address assignment.
Consequently, all hosts SHOULD implement address configuration via Consequently, all hosts SHOULD implement address configuration via
DHCPv6. DHCPv6.
In the absence of observed Router Advertisement messages, IPv6 nodes In the absence of observed Router Advertisement messages, IPv6 nodes
MAY initiate DHCP to obtain IPv6 addresses and other configuration MAY initiate DHCP to obtain IPv6 addresses and other configuration
information, as described in Section 5.5.2 of [RFC4862]. information, as described in Section 5.5.2 of [RFC4862].
Where devices are likely to be carried by users and attached to Where devices are likely to be carried by users and attached to
multiple visisted networks, DHCPv6 client anonymity profiles SHOULD multiple visisted networks, DHCPv6 client anonymity profiles SHOULD
be supported as described in [RFC7844] to minimise the disclosure of be supported as described in [RFC7844] to minimise the disclosure of
identifying information. Section 5 of RFC7844 describes operational identifying information. Section 5 of RFC7844 describes operational
considerations on the use of such anonymity profiles. considerations on the use of such anonymity profiles.
6.6. Default Address Selection for IPv6 - RFC 6724 6.6. Default Address Selection for IPv6 - RFC 6724
IPv6 nodes will invariably have multiple addresses configured IPv6 nodes will invariably have multiple addresses configured
simultaneously, and thus will need to choose which addresses to use simultaneously, and thus will need to choose which addresses to use
for which communications. The rules specified in the Default Address for which communications. The rules specified in the Default Address
Selection for IPv6 [RFC6724] document MUST be implemented. [RFC8028] Selection for IPv6 [RFC6724] document MUST be implemented. [RFC8028]
updates rule 5.5 from [RFC6724]; implementations SHOULD implement updates rule 5.5 from [RFC6724]; implementations SHOULD implement
skipping to change at page 16, line 32 skipping to change at page 16, line 32
(non-address) configuration. If a host implementation supports (non-address) configuration. If a host implementation supports
applications or other protocols that require configuration that is applications or other protocols that require configuration that is
only available via DHCP, hosts SHOULD implement DHCP. For only available via DHCP, hosts SHOULD implement DHCP. For
specialized devices on which no such configuration need is present, specialized devices on which no such configuration need is present,
DHCP may not be necessary. DHCP may not be necessary.
An IPv6 node can use the subset of DHCP (described in [RFC3736]) to An IPv6 node can use the subset of DHCP (described in [RFC3736]) to
obtain other configuration information. obtain other configuration information.
If an IPv6 node implements DHCP it MUST implement the DNS options If an IPv6 node implements DHCP it MUST implement the DNS options
[RFC3646] as most deployments will expect this options are [RFC3646] as most deployments will expect these options are
available. available.
8.2. Router Advertisements and Default Gateway 8.2. Router Advertisements and Default Gateway
There is no defined DHCPv6 Gateway option. There is no defined DHCPv6 Gateway option.
Nodes using the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Nodes using the Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
are thus expected to determine their default router information and are thus expected to determine their default router information and
on-link prefix information from received Router Advertisements. on-link prefix information from received Router Advertisements.
skipping to change at page 17, line 38 skipping to change at page 17, line 38
influence over what devices connect to the network and thus what influence over what devices connect to the network and thus what
configuration mechanisms they support, the operator may be able to configuration mechanisms they support, the operator may be able to
ensure that a particular mechanism is supported by all connected ensure that a particular mechanism is supported by all connected
hosts. In more open environments, however, where arbitrary devices hosts. In more open environments, however, where arbitrary devices
may connect (e.g., a WIFI hotspot), problems can arise. To maximize may connect (e.g., a WIFI hotspot), problems can arise. To maximize
interoperability in such environments, hosts would need to implement interoperability in such environments, hosts would need to implement
multiple configuration mechanisms to ensure interoperability. multiple configuration mechanisms to ensure interoperability.
9. Service Discovery Protocols 9. Service Discovery Protocols
[RFC6762] and [RFC6763] describe multicast DNS (mDNS) and DNS-Based [RFC6762] and [RFC6763] describe multicast DNS (mDNS) and DNS-Based
Service Discovery (DNS-SD) respectively. These protocols, Service Discovery (DNS-SD) respectively. These protocols,
collectively commonly referred to as the 'Bonjour' protocols after collectively commonly referred to as the 'Bonjour' protocols after
their naming by Apple, provide the means for devices to discover their naming by Apple, provide the means for devices to discover
services within a local link and, in the absence of a unicast DNS services within a local link and, in the absence of a unicast DNS
service, to exchange naming information. service, to exchange naming information.
Where devices are to be deployed in networks where service dicovery Where devices are to be deployed in networks where service dicovery
would be beneficial, e.g., for users seeking to discover printers or would be beneficial, e.g., for users seeking to discover printers or
display devices, mDNS and DNS-SD SHOULD be supported. display devices, mDNS and DNS-SD SHOULD be supported.
skipping to change at page 19, line 12 skipping to change at page 19, line 12
provides support for expressing source filters on multicast group provides support for expressing source filters on multicast group
memberships. memberships.
"Extension to Sockets API for Mobile IPv6" [RFC4584] provides "Extension to Sockets API for Mobile IPv6" [RFC4584] provides
application support for accessing and enabling Mobile IPv6 [RFC6275] application support for accessing and enabling Mobile IPv6 [RFC6275]
features. features.
12. Mobility 12. Mobility
Mobile IPv6 [RFC6275] and associated specifications [RFC3776] Mobile IPv6 [RFC6275] and associated specifications [RFC3776]
[RFC4877] allow a node to change its point of attachment within the [RFC4877] allow a node to change its point of attachment within the
Internet, while maintaining (and using) a permanent address. All Internet, while maintaining (and using) a permanent address. All
communication using the permanent address continues to proceed as communication using the permanent address continues to proceed as
expected even as the node moves around. The definition of Mobile IP expected even as the node moves around. The definition of Mobile IP
includes requirements for the following types of nodes: includes requirements for the following types of nodes:
- mobile nodes - mobile nodes
- correspondent nodes with support for route optimization - correspondent nodes with support for route optimization
- home agents - home agents
skipping to change at page 20, line 48 skipping to change at page 20, line 48
and environments where approaches to security other than IPsec can be and environments where approaches to security other than IPsec can be
justified. For example, special-purpose devices may support only a justified. For example, special-purpose devices may support only a
very limited number or type of applications, and an application- very limited number or type of applications, and an application-
specific security approach may be sufficient for limited management specific security approach may be sufficient for limited management
or configuration capabilities. Alternatively, some devices may run or configuration capabilities. Alternatively, some devices may run
on extremely constrained hardware (e.g., sensors) where the full on extremely constrained hardware (e.g., sensors) where the full
IPsec Architecture is not justified. IPsec Architecture is not justified.
Because most common platforms now support IPv6 and have it enabled by Because most common platforms now support IPv6 and have it enabled by
default, IPv6 security is an issue for networks that are ostensibly default, IPv6 security is an issue for networks that are ostensibly
IPv4-only; see [RFC7123] for guidance on this area. IPv4-only; see [RFC7123] for guidance on this area.
13.1. Requirements 13.1. Requirements
"Security Architecture for the Internet Protocol" [RFC4301] SHOULD be "Security Architecture for the Internet Protocol" [RFC4301] SHOULD be
supported by all IPv6 nodes. Note that the IPsec Architecture supported by all IPv6 nodes. Note that the IPsec Architecture
requires (e.g., Section 4.5 of [RFC4301]) the implementation of both requires (e.g., Section 4.5 of [RFC4301]) the implementation of both
manual and automatic key management. Currently, the default manual and automatic key management. Currently, the default
automated key management protocol to implement is IKEv2. As required automated key management protocol to implement is IKEv2. As required
in [RFC4301], IPv6 nodes implementing the IPsec Architecture MUST in [RFC4301], IPv6 nodes implementing the IPsec Architecture MUST
implement ESP [RFC4303] and MAY implement AH [RFC4302]. implement ESP [RFC4303] and MAY implement AH [RFC4302].
skipping to change at page 22, line 44 skipping to change at page 22, line 44
Because of the wide range of deployment scenarios, support for DHCP Because of the wide range of deployment scenarios, support for DHCP
server functionality on routers is optional. However, routers server functionality on routers is optional. However, routers
targeted for deployment within more complex scenarios (as described targeted for deployment within more complex scenarios (as described
above) SHOULD support relay agent functionality. Note that "Basic above) SHOULD support relay agent functionality. Note that "Basic
Requirements for IPv6 Customer Edge Routers" [RFC7084] requires Requirements for IPv6 Customer Edge Routers" [RFC7084] requires
implementation of a DHCPv6 server function in IPv6 Customer Edge (CE) implementation of a DHCPv6 server function in IPv6 Customer Edge (CE)
routers. routers.
14.4. IPv6 Prefix Length Recommendation for Forwarding - BCP 198 14.4. IPv6 Prefix Length Recommendation for Forwarding - BCP 198
Forwarding nodes MUST conform to BCP 198 [RFC7608] and thus IPv6 Forwarding nodes MUST conform to BCP 198 [RFC7608] and thus IPv6
implementations of nodes that may forward packets MUST conform to the implementations of nodes that may forward packets MUST conform to the
rules specified in Section 5.1 of [RFC4632]. rules specified in Section 5.1 of [RFC4632].
15. Constrained Devices 15. Constrained Devices
The target for this document is general IPv6 nodes. In the case of The target for this document is general IPv6 nodes. In the case of
constrained nodes, with limited CPU, memory, bandwidth or power, constrained nodes, with limited CPU, memory, bandwidth or power,
support for certain IPv6 functionality may need to be considered due support for certain IPv6 functionality may need to be considered due
to those limitations. The requirements of this document are to those limitations. The requirements of this document are
RECOMMENDED for all nodes, including constrained nodes, but RECOMMENDED for all nodes, including constrained nodes, but
compromises may need to be made in certain cases. Where such compromises may need to be made in certain cases. Where such
compromises are made, the interoperability of devices should be compromises are made, the interoperability of devices should be
strongly considered, paticularly where this may impact other nodes on strongly considered, paticularly where this may impact other nodes on
the same link, e.g., only supporting MLDv1 will affect other nodes. the same link, e.g., only supporting MLDv1 will affect other nodes.
The IETF 6LowPAN (IPv6 over Low Power LWPAN) WG defined six RFCs, The IETF 6LowPAN (IPv6 over Low Power LWPAN) WG defined six RFCs,
including a general overview and problem statement ([RFC4919], the including a general overview and problem statement ([RFC4919], the
means by which IPv6 packets are transmitted over IEEE 802.15.4 means by which IPv6 packets are transmitted over IEEE 802.15.4
networks [RFC4944] and ND optimisations for that medium [RFC6775]. networks [RFC4944] and ND optimisations for that medium [RFC6775].
If an IPv6 node is concerned about the impact of IPv6 message power If an IPv6 node is concerned about the impact of IPv6 message power
consumption, it SHOULD want to implement the recommendations in consumption, it SHOULD want to implement the recommendations in
[RFC7772]. [RFC7772].
16. Network Management 16. Network Management
Network management MAY be supported by IPv6 nodes. However, for IPv6 Network management MAY be supported by IPv6 nodes. However, for IPv6
nodes that are embedded devices, network management may be the only nodes that are embedded devices, network management may be the only
possible way of controlling these nodes. possible way of controlling these nodes.
Existing network management protocols include SNMP [RFC3411], NETCONF Existing network management protocols include SNMP [RFC3411], NETCONF
[RFC6241] and RESTCONF [RFC8040]. [RFC6241] and RESTCONF [RFC8040].
16.1. Management Information Base (MIB) Modules 16.1. Management Information Base (MIB) Modules
IPv6 MIBs have been updated since the last release of the document; [RFC8096] clarifies the obsoleted status of various IPv6-specific MIB
[RFC8096] obseletes several MIBs, which nodes need no longer modules.
support.
The following two MIB modules SHOULD be supported by nodes that The following two MIB modules SHOULD be supported by nodes that
support a Simple Network Management Protocol (SNMP) agent. support a Simple Network Management Protocol (SNMP) agent.
16.1.1. IP Forwarding Table MIB 16.1.1. IP Forwarding Table MIB
The IP Forwarding Table MIB [RFC4292] SHOULD be supported by nodes The IP Forwarding Table MIB [RFC4292] SHOULD be supported by nodes
that support an SNMP agent. that support an SNMP agent.
16.1.2. Management Information Base for the Internet Protocol (IP) 16.1.2. Management Information Base for the Internet Protocol (IP)
skipping to change at page 24, line 13 skipping to change at page 24, line 8
SNMP agent. SNMP agent.
16.1.3. Interface MIB 16.1.3. Interface MIB
The Interface MIB [RFC2863] SHOULD be supported by nodes the support The Interface MIB [RFC2863] SHOULD be supported by nodes the support
an SNMP agent. an SNMP agent.
16.2. YANG Data Models 16.2. YANG Data Models
The following YANG data models SHOULD be supported by nodes that The following YANG data models SHOULD be supported by nodes that
support a NETCONF agent. support a NETCONF or RESTCONF agent.
16.2.1. IP Management YANG Model 16.2.1. IP Management YANG Model
The IP Management YANG Model [RFC7277] SHOULD be supported by nodes The IP Management YANG Model [I-D.ietf-netmod-rfc7277bis] SHOULD be
that support NETCONF. supported by nodes that support NETCONF or RESTCONF.
16.2.2. Interface Management YANG Model 16.2.2. Interface Management YANG Model
The Interface Management YANG Model [RFC7223] SHOULD be supported by The Interface Management YANG Model [I-D.ietf-netmod-rfc7223bis]
nodes that support NETCONF. SHOULD be supported by nodes that support NETCONF or RESTCONF.
17. Security Considerations 17. Security Considerations
This document does not directly affect the security of the Internet, This document does not directly affect the security of the Internet,
beyond the security considerations associated with the individual beyond the security considerations associated with the individual
protocols. protocols.
Security is also discussed in Section 13 above. Security is also discussed in Section 13 above.
18. IANA Considerations 18. IANA Considerations
skipping to change at page 33, line 49 skipping to change at page 33, line 45
Oversized IPv6 Header Chains", RFC 7112, Oversized IPv6 Header Chains", RFC 7112,
DOI 10.17487/RFC7112, January 2014, DOI 10.17487/RFC7112, January 2014,
<https://www.rfc-editor.org/info/rfc7112>. <https://www.rfc-editor.org/info/rfc7112>.
[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 [I-D.ietf-netmod-rfc7223bis]
Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, Bjorklund, M., "A YANG Data Model for Interface
<https://www.rfc-editor.org/info/rfc7223>. Management", draft-ietf-netmod-rfc7223bis-03 (work in
progress), January 2018.
[RFC7277] Bjorklund, M., "A YANG Data Model for IP Management", [I-D.ietf-netmod-rfc7277bis]
RFC 7277, DOI 10.17487/RFC7277, June 2014, Bjorklund, M., "A YANG Data Model for IP Management",
<https://www.rfc-editor.org/info/rfc7277>. draft-ietf-netmod-rfc7277bis-03 (work in progress),
January 2018.
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
Kivinen, "Internet Key Exchange Protocol Version 2 Kivinen, "Internet Key Exchange Protocol Version 2
(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
2014, <https://www.rfc-editor.org/info/rfc7296>. 2014, <https://www.rfc-editor.org/info/rfc7296>.
[RFC7527] Asati, R., Singh, H., Beebee, W., Pignataro, C., Dart, E., [RFC7527] Asati, R., Singh, H., Beebee, W., Pignataro, C., Dart, E.,
and W. George, "Enhanced Duplicate Address Detection", and W. George, "Enhanced Duplicate Address Detection",
RFC 7527, DOI 10.17487/RFC7527, April 2015, RFC 7527, DOI 10.17487/RFC7527, April 2015,
<https://www.rfc-editor.org/info/rfc7527>. <https://www.rfc-editor.org/info/rfc7527>.
skipping to change at page 40, line 25 skipping to change at page 40, line 25
ISO/IEC 9945:2009", <http://www.ieee.org>. ISO/IEC 9945:2009", <http://www.ieee.org>.
[USGv6] National Institute of Standards and Technology, "A Profile [USGv6] National Institute of Standards and Technology, "A Profile
for IPv6 in the U.S. Government - Version 1.0", July 2008, for IPv6 in the U.S. Government - Version 1.0", July 2008,
<http://www.antd.nist.gov/usgv6/usgv6-v1.pdf>. <http://www.antd.nist.gov/usgv6/usgv6-v1.pdf>.
Authors' Addresses Authors' Addresses
Tim Chown Tim Chown
Jisc Jisc
Lumen House, Library Avenue Lumen House, Library Avenue
Harwell Oxford, Didcot OX11 0SG Harwell Oxford, Didcot OX11 0SG
United Kingdom United Kingdom
Email: tim.chown@jisc.ac.uk Email: tim.chown@jisc.ac.uk
John Loughney John Loughney
Intel Intel
Santa Clara, CA Santa Clara, CA
USA USA
Email: john.loughney@gmail.com Email: john.loughney@gmail.com
Timothy Winters Timothy Winters
University of New Hampshire, Interoperability Lab (UNH-IOL) University of New Hampshire, Interoperability Lab (UNH-IOL)
Durham, NH Durham, NH
United States United States
Email: twinters@iol.unh.edu Email: twinters@iol.unh.edu
 End of changes. 24 change blocks. 
35 lines changed or deleted 36 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/