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/