< draft-chakrabarti-nordmark-6man-efficient-nd-03.txt		draft-chakrabarti-nordmark-6man-efficient-nd-04.txt >
	6man WG S. Chakrabarti		6man WG S. Chakrabarti
	Internet-Draft Ericsson		Internet-Draft Ericsson
	Updates: 4861 (if approved) E. Nordmark		Updates: 4861 (if approved) E. Nordmark
	Intended status: Standards Track		Intended status: Standards Track Arista Networks
	Expires: April 18, 2014 P. Thubert		Expires: April 25, 2014 P. Thubert
	Cisco Systems		Cisco Systems
	M. Wasserman		M. Wasserman
	Painless Security		Painless Security
	October 15, 2013		October 22, 2013
	Wired and Wireless IPv6 Neighbor Discovery Optimizations		Wired and Wireless IPv6 Neighbor Discovery Optimizations
	draft-chakrabarti-nordmark-6man-efficient-nd-03		draft-chakrabarti-nordmark-6man-efficient-nd-04
	Abstract		Abstract
	IPv6 Neighbor Discovery (RFC 4861) protocol has been designed for		IPv6 Neighbor Discovery (RFC 4861) protocol has been designed for
	neighbor's address resolution, unreachability detection, address		neighbor's address resolution, unreachability detection, address
	autoconfiguration, router advertisement and solicitation. With the		autoconfiguration, router advertisement and solicitation. With the
	progress of Internet adoption on various industries including home,		progress of Internet adoption on various industries including home,
	wireless, M2M and cellular networks there is a desire for optimizing		wireless, M2M and cellular networks there is a desire for optimizing
	the legacy IPv6 Neighbor Discovery protocol. This document describes		the legacy IPv6 Neighbor Discovery protocol. This document describes
	a method of optimization by reducing multicast messages and		a method of optimization by reducing multicast messages and
	skipping to change at page 1, line 46 ¶		skipping to change at page 1, line 46 ¶
	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 http://datatracker.ietf.org/drafts/current/.		Drafts is at http://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 April 18, 2014.		This Internet-Draft will expire on April 25, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2013 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
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	skipping to change at page 2, line 37 ¶		skipping to change at page 2, line 37 ¶
	7. New Neighbor Discovery Options and Messages . . . . . . . . . 10		7. New Neighbor Discovery Options and Messages . . . . . . . . . 10
	7.1. Address Registration Option . . . . . . . . . . . . . . . 10		7.1. Address Registration Option . . . . . . . . . . . . . . . 10
	7.2. Refresh and De-registration . . . . . . . . . . . . . . . 12		7.2. Refresh and De-registration . . . . . . . . . . . . . . . 12
	7.3. A New Router Advertisement Flag . . . . . . . . . . . . . 13		7.3. A New Router Advertisement Flag . . . . . . . . . . . . . 13
	7.4. The Transaction Identification(TID) . . . . . . . . . . . 13		7.4. The Transaction Identification(TID) . . . . . . . . . . . 13
	8. Efficiency-aware Neighbor Discovery Messages . . . . . . . . . 14		8. Efficiency-aware Neighbor Discovery Messages . . . . . . . . . 14
	9. Efficiency-aware Host Behavior . . . . . . . . . . . . . . . . 15		9. Efficiency-aware Host Behavior . . . . . . . . . . . . . . . . 15
	10. The Efficiency Aware Default Router (NEAR) Behavior . . . . . 16		10. The Efficiency Aware Default Router (NEAR) Behavior . . . . . 16
	10.1. Router Configuration Modes . . . . . . . . . . . . . . . . 17		10.1. Router Configuration Modes . . . . . . . . . . . . . . . . 17
	10.2. Movement Detection . . . . . . . . . . . . . . . . . . . . 17		10.2. Movement Detection . . . . . . . . . . . . . . . . . . . . 17
	10.2.1. Registration ownership . . . . . . . . . . . . . . . 17		10.2.1. Registration ownership . . . . . . . . . . . . . . . 18
	11. NCE Management in efficiency-aware Routers . . . . . . . . . . 18		11. NCE Management in efficiency-aware Routers . . . . . . . . . . 18
	11.1. Handling ND DOS Attack . . . . . . . . . . . . . . . . . . 20		11.1. Handling ND DOS Attack . . . . . . . . . . . . . . . . . . 20
	12. Mixed-Mode Operations . . . . . . . . . . . . . . . . . . . . 20		12. Mixed-Mode Operations . . . . . . . . . . . . . . . . . . . . 21
	13. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . . . 21		13. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . . . 22
	14. Handling Sleepy Nodes . . . . . . . . . . . . . . . . . . . . 23		14. Handling Sleepy Nodes . . . . . . . . . . . . . . . . . . . . 23
	15. Duplicate Address Detection . . . . . . . . . . . . . . . . . 23		15. Duplicate Address Detection . . . . . . . . . . . . . . . . . 23
	16. Mobility Considerations . . . . . . . . . . . . . . . . . . . 23		16. Mobility Considerations . . . . . . . . . . . . . . . . . . . 24
	17. Other Considerations . . . . . . . . . . . . . . . . . . . . . 24		17. Other Considerations . . . . . . . . . . . . . . . . . . . . . 24
	17.1. Detecting Network Attachment(DNA) . . . . . . . . . . . . 24		17.1. Detecting Network Attachment(DNA) . . . . . . . . . . . . 24
	17.2. Proxying for Efficiency-Aware hosts . . . . . . . . . . . 24		17.2. Proxying for Efficiency-Aware hosts . . . . . . . . . . . 25
	17.3. DHCPv6 Interaction . . . . . . . . . . . . . . . . . . . . 25		17.3. DHCPv6 Interaction . . . . . . . . . . . . . . . . . . . . 25
	18. RPL Implications . . . . . . . . . . . . . . . . . . . . . . . 25		18. VRRP Interaction . . . . . . . . . . . . . . . . . . . . . . . 26
	19. Updated Neighbor Discovery Constants . . . . . . . . . . . . . 26		19. RPL Implications . . . . . . . . . . . . . . . . . . . . . . . 26
	20. Security Considerations . . . . . . . . . . . . . . . . . . . 26		20. Updated Neighbor Discovery Constants . . . . . . . . . . . . . 26
	21. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26		21. Security Considerations . . . . . . . . . . . . . . . . . . . 27
	22. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 26		22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
	23. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27		23. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 27
	24. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27		24. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27
	24.1. Normative References . . . . . . . . . . . . . . . . . . . 27		25. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
	24.2. Informative References . . . . . . . . . . . . . . . . . . 28		25.1. Normative References . . . . . . . . . . . . . . . . . . . 28
	Appendix A. Usecase Analysis . . . . . . . . . . . . . . . . . . 29		25.2. Informative References . . . . . . . . . . . . . . . . . . 28
	A.1. Data Center Routers on the link . . . . . . . . . . . . . 29		Appendix A. Usecase Analysis . . . . . . . . . . . . . . . . . . 30
	A.2. Edge Routers and Home Networks . . . . . . . . . . . . . . 29		A.1. Data Center Routers on the link . . . . . . . . . . . . . 30
			A.2. Edge Routers and Home Networks . . . . . . . . . . . . . . 30
	A.3. M2M Networks . . . . . . . . . . . . . . . . . . . . . . . 30		A.3. M2M Networks . . . . . . . . . . . . . . . . . . . . . . . 30
	A.4. Wi-fi Networks . . . . . . . . . . . . . . . . . . . . . . 30		A.4. Wi-fi Networks . . . . . . . . . . . . . . . . . . . . . . 31
	A.5. 3GPP Networks . . . . . . . . . . . . . . . . . . . . . . 30		A.5. 3GPP Networks . . . . . . . . . . . . . . . . . . . . . . 31
	A.6. Industrial Networks . . . . . . . . . . . . . . . . . . . 31		A.6. Industrial Networks . . . . . . . . . . . . . . . . . . . 31
	A.7. Set and forget offline network . . . . . . . . . . . . . . 31		A.7. Set and forget offline network . . . . . . . . . . . . . . 31
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31
	1. Introduction		1. Introduction
	Conceptually, IPv6 multicast messages are supposed to avoid broadcast		Conceptually, IPv6 multicast messages are supposed to avoid broadcast
	messages, but in practice, the multicast operation at the link level		messages, but in practice, the multicast operation at the link level
	is that of a broadcast nevertheless. This did not matter much at the		is that of a broadcast nevertheless. This did not matter much at the
	time ND [ND] was originally designed, when an Ethernet network was		time ND [ND] was originally designed, when an Ethernet network was
	skipping to change at page 15, line 46 ¶		skipping to change at page 15, line 46 ¶
	Registration Authority and RFC 2373. If this draft feature is		Registration Authority and RFC 2373. If this draft feature is
	implemented and configured, the host MUST NOT re-direct Neighbor		implemented and configured, the host MUST NOT re-direct Neighbor
	Discovery messages. The host is not required to join the solicited-		Discovery messages. The host is not required to join the solicited-
	node multicast address but it MUST join the all-node multicast		node multicast address but it MUST join the all-node multicast
	address.		address.
	A host always sends packets to (one of) its default router(s). This		A host always sends packets to (one of) its default router(s). This
	is accomplished by the routers never setting the 'L' flag in the		is accomplished by the routers never setting the 'L' flag in the
	Prefix options.		Prefix options.
			The EAH host may register with more than one default routers in a
			subnet but it SHOULD use one default primary router for a source IP-
			address at a time.
			If an EAH receives a status code 2 in response to its registration
			request from a NEAR router, the node MUST be able to choose another
			router to register with (when available).
	The host is unable to forward routes or participate in a routing		The host is unable to forward routes or participate in a routing
	protocol. A legacy IPv6 Host compliant EAH SHOULD be able to fall		protocol. A legacy IPv6 Host compliant EAH SHOULD be able to fall
	back to RFC 4861 host behavior if there is no efficiency-aware router		back to RFC 4861 host behavior if there is no efficiency-aware router
	(NEAR) in the link.		(NEAR) in the link.
	The efficiency-aware host MUST NOT send or accept re-direct messages.		The efficiency-aware host MUST NOT send or accept re-direct messages.
	It does not join solicited node multicast address.		It does not join solicited node multicast address.
	If the EAH is capable of generating TID and configured for this		If the EAH is capable of generating TID and configured for this
	operation, the EAH MUST use the TID field and appropriate associated		operation, the EAH MUST use the TID field and appropriate associated
	operation bits in the ARO message during registration and refresh.		operation bits in the ARO message during registration and refresh.
	In some cases, hosts may need to send MAX_RTR_SOLICITATIONS(3) to		In some cases, hosts may need to send MAX_RTR_SOLICITATIONS(3) to
	receive the reply back from the default router. In a lossy link or		receive the reply back from the default router. In a lossy link or
	due to sleepy default router, the hosts may have to send more than 3		due to sleepy default router, the hosts may have to send more than 3
	solicitations [Resilient-RS]. But this can easily increase the		solicitations [Resilient-RS]. But this can easily increase the
	number of siganling traffic in the network. Thus it is RECOMMEDED		number of siganling traffic in the network. Thus it is RECOMMENDED
	that the EAH nodes start with the default MAX_RTR_SOLICITATION [ND]		that the EAH nodes start with the default MAX_RTR_SOLICITATION [ND]
	value in a low power network.		value in a low power network.
	However, in some scenarios the packet loss resilient router		However, in some scenarios the packet loss resilient router
	solicitation method may be applicable [Resilient-RS].		solicitation method may be applicable [Resilient-RS].
	10. The Efficiency Aware Default Router (NEAR) Behavior		10. The Efficiency Aware Default Router (NEAR) Behavior
	The main purpose of the default router in the context of this		The main purpose of the default router in the context of this
	document is to receive and process the registration request, forward		document is to receive and process the registration request, forward
	skipping to change at page 17, line 14 ¶		skipping to change at page 17, line 22 ¶
	protects the router from Denial Of Service attacks. Similarly, if		protects the router from Denial Of Service attacks. Similarly, if
	Neighbor Unreachability Detection on the router determines that the		Neighbor Unreachability Detection on the router determines that the
	host is UNREACHABLE (based on the logic in [ND]), the Neighbor Cache		host is UNREACHABLE (based on the logic in [ND]), the Neighbor Cache
	entry SHOULD NOT be deleted but be retained until the Registration		entry SHOULD NOT be deleted but be retained until the Registration
	Lifetime expires. If an ARO arrives for an NCE that is in		Lifetime expires. If an ARO arrives for an NCE that is in
	UNCREACHABLE state, that NCE should be marked as STALE.		UNCREACHABLE state, that NCE should be marked as STALE.
	A default router keeps a cache for all the nodes' IP addresses,		A default router keeps a cache for all the nodes' IP addresses,
	created from the Address Registration processing.		created from the Address Registration processing.
			The NEAR router SHOULD deny registration to a new registration
			request with the status code 2 when it reaches the maximum capacity
			for handling the neighbor cache.
	10.1. Router Configuration Modes		10.1. Router Configuration Modes
	An efficiency-aware Router(NEAR) MUST be able to configure in		An efficiency-aware Router(NEAR) MUST be able to configure in
	efficiency-aware-only mode where it will expect all hosts register		efficiency-aware-only mode where it will expect all hosts register
	with the router following RS; thus NEAR will not support legacy		with the router following RS; thus NEAR will not support legacy
	hosts. However, it will create legacy NCE for the routers in the		hosts. However, it will create legacy NCE for the routers in the
	network assuming that the routers do not register with it. This mode		network assuming that the routers do not register with it. This mode
	is able to prevent ND flooding on the link.		is able to prevent ND flooding on the link.
	An efficiency-aware Router(NEAR) SHOULD be able to have configuration		An efficiency-aware Router(NEAR) SHOULD be able to have configuration
	skipping to change at page 18, line 14 ¶		skipping to change at page 18, line 27 ¶
	subtracting the present time from the registration received time		subtracting the present time from the registration received time
	recorded at the NCE. The NEAR router then responds with a NA with		recorded at the NCE. The NEAR router then responds with a NA with
	ARO option Status being equal to 3 and replaces the 'registration		ARO option Status being equal to 3 and replaces the 'registration
	lifetime' field with the 'age' of registration. Upon receiving the		lifetime' field with the 'age' of registration. Upon receiving the
	NA from the neighboring routers the prospective default router		NA from the neighboring routers the prospective default router
	determines its registration ownership. If the other router		determines its registration ownership. If the other router
	registration age is higher than its own registration age, then the		registration age is higher than its own registration age, then the
	current router is considered to have the most recent registration		current router is considered to have the most recent registration
	ownership.		ownership.
	If both routers registration age are zero or within a 50msec window,		If both routers registration age are zero or within
	then the TID field is used to determine the ownership. The higher		MAX_REG_AGE_DIFFERENCE window, then the TID field is used to
	value of TID wins. Note that the registration ownership and local		determine the ownership. The higher value of TID wins. Note that
	movement detection behavior in NEAR router MUST be optionally		the registration ownership and local movement detection behavior in
	configured. The NEAR routers MAY implement this feature.		NEAR router MUST be optionally configured. The NEAR routers MAY
	Configuring this option is needed when the NEAR routers are used in a		implement this feature. Configuring this option is needed when the
	low power and lossy network environment.		NEAR routers are used in a low power and lossy network environment.
	11. NCE Management in efficiency-aware Routers		11. NCE Management in efficiency-aware Routers
	The use of explicit registrations with lifetimes plus the desire to		The use of explicit registrations with lifetimes plus the desire to
	not multicast Neighbor Solicitation messages for hosts imply that we		not multicast Neighbor Solicitation messages for hosts imply that we
	manage the Neighbor Cache entries slightly differently than in [ND].		manage the Neighbor Cache entries slightly differently than in [ND].
	This results in two different types of NCEs and the types specify how		This results in two different types of NCEs and the types specify how
	those entries can be removed:		those entries can be removed:
	Legacy: Entries that are subject to the normal rules in		Legacy: Entries that are subject to the normal rules in
	skipping to change at page 21, line 37 ¶		skipping to change at page 21, line 48 ¶
	available in the network during the startup. If the EAH was		available in the network during the startup. If the EAH was
	operational in efficiency-aware mode and it determines that the NEAR		operational in efficiency-aware mode and it determines that the NEAR
	is no longer available, then it should send a RS and find an		is no longer available, then it should send a RS and find an
	alternate default router in the link. If no efficiency-aware router		alternate default router in the link. If no efficiency-aware router
	is indicated from the RA, then the EAH SHOULD fall back into RFC 4861		is indicated from the RA, then the EAH SHOULD fall back into RFC 4861
	behavior. On the other hand, in the efficiency-aware mode EAH SHOULD		behavior. On the other hand, in the efficiency-aware mode EAH SHOULD
	ignore multicast Router Advertisements(RA) sent by the legacy and		ignore multicast Router Advertisements(RA) sent by the legacy and
	Mixed-mode routers in the link.		Mixed-mode routers in the link.
	In mixed mode operation, the Router SHOULD be able to do local		In mixed mode operation, the Router SHOULD be able to do local
	movement detection based on ARO if it is configured for that		movement detection based on ARO from EAH hosts. For the legacy
	operation for EAH hosts. For the legacy hosts, the mixed-mode router		hosts, the mixed-mode router MAY follow classical IPv6 methods of
	MAY follow classical IPv6 methods of movement detection and MAY act		movement detection and MAY act as ND proxy by sending NA with 'O'
	as ND proxy by sending NA with 'O' bit.[ Reference??]		bit.[RFC 3775]
	The routers that are running on efficiency-aware mode or legacy mode		The routers that are running on efficiency-aware mode or legacy mode
	SHOULD NOT dynamically switch the mode without flushing the Neighbor		SHOULD NOT dynamically switch the mode without flushing the Neighbor
	Cache Entries.		Cache Entries.
	In mixed mode, the NEAR SHOULD have a configurable interval for		In mixed mode, the NEAR SHOULD have a configurable interval for
	periodic unsolicited router advertisements based on the media type.		periodic unsolicited router advertisements based on the media type.
	13. Bootstrapping		13. Bootstrapping
	The bootstrapping mechanism described here is applicable for the		The bootstrapping mechanism described here is applicable for the
	skipping to change at page 25, line 40 ¶		skipping to change at page 26, line 5 ¶
	MUST be notified by NEAR for its efficiency-aware service interfaces.		MUST be notified by NEAR for its efficiency-aware service interfaces.
	DHCPv6 server then SHOULD inform the DHCP requestor node about the		DHCPv6 server then SHOULD inform the DHCP requestor node about the
	default-rotuer capability during the address assignment period.		default-rotuer capability during the address assignment period.
	Although the solution described in this document prevents unnecesary		Although the solution described in this document prevents unnecesary
	multicast messages in the IPv6 ND procedure, it does not affect		multicast messages in the IPv6 ND procedure, it does not affect
	normal IPv6 multicast packets and ability of nodes to join and leave		normal IPv6 multicast packets and ability of nodes to join and leave
	the multicast group or forwarding multicast traffic or responding to		the multicast group or forwarding multicast traffic or responding to
	multicast queries.		multicast queries.
	18. RPL Implications		18. VRRP Interaction
			TBD: This section will discuss if efficient ND mixed mode and
			efficiency mode require any special consideration with VRRP function.
			19. RPL Implications
	RPL [RFC6550] does not provide means for duplicate address detection		RPL [RFC6550] does not provide means for duplicate address detection
	and in particular does not have a concept of unique identifier. On		and in particular does not have a concept of unique identifier. On
	the other hand, RPL is designed to discover and resolve conflicts		the other hand, RPL is designed to discover and resolve conflicts
	that arise when a mobile device changes its point of attachment, with		that arise when a mobile device changes its point of attachment, with
	a sequence counter that is owned by the device and incremented at		a sequence counter that is owned by the device and incremented at
	each new registration, called a DAOSequence. As we extend 6LoWPAN ND		each new registration, called a DAOSequence. As we extend 6LoWPAN ND
	operation over a backbone and scale, there is a similar need to		operation over a backbone and scale, there is a similar need to
	resolve the latest point of attachment of a device, whether this		resolve the latest point of attachment of a device, whether this
	device moves at layer 2 over a WIFI infrastructure, or at layer 3		device moves at layer 2 over a WIFI infrastructure, or at layer 3
	within a RPL DODAG or from a DODAG to another one attached to the		within a RPL DODAG or from a DODAG to another one attached to the
	same backbone. In order to cover all cases in a consistent fashion,		same backbone. In order to cover all cases in a consistent fashion,
	this document requires that a sequence counter call TID for		this document requires that a sequence counter call TID for
	Transaction ID and with the similar rules as the RPL DAOSequence is		Transaction ID and with the similar rules as the RPL DAOSequence is
	added to the ND registration. This document defines the TID		added to the ND registration. This document defines the TID
	operations and RPL may use the reserved fields for their purpose		operations and RPL may use the reserved fields for their purpose
	inside the LLN.		inside the LLN.
	19. Updated Neighbor Discovery Constants		20. Updated Neighbor Discovery Constants
	This section discusses the updated default values of ND constants		This section discusses the updated default values of ND constants
	based on [ND] section 10. New and changed constants are listed only		based on [ND] section 10. New and changed constants are listed only
	for efficiency-aware-nd implementation. These values SHOULD be		for efficiency-aware-nd implementation. These values SHOULD be
	configurable and tunable to fit implementations and deployment.		configurable and tunable to fit implementations and deployment.
	Router Constants:		Router Constants:
	MAX_RTR_ADVERTISEMENTS(NEW) 3 transmissions		MAX_RTR_ADVERTISEMENTS(NEW) 3 transmissions
	MIN_DELAY_BETWEEN_RAS(CHANGED) 1 second		MIN_DELAY_BETWEEN_RAS(CHANGED) 1 second
	TENTATIVE_LEGACY_NCE_LIFETIME(NEW) 30 seconds		TENTATIVE_LEGACY_NCE_LIFETIME(NEW) 30 seconds
			MAX_REG_AGE_DIFFERENCE(NEW) 50 mseconds
	Host Constants:		Host Constants:
	MAX_RTR_SOLICITATION_INTERVAL(NEW) 60 seconds		MAX_RTR_SOLICITATION_INTERVAL(NEW) 60 seconds
	Also refer to [ENH-ND] , [IMPAT-ND] and [6LOWPAN-ND] for further		Also refer to [ENH-ND] , [IMPAT-ND] and [6LOWPAN-ND] for further
	tuning of ND constants.		tuning of ND constants.
	20. Security Considerations		21. Security Considerations
	These optimizations are not known to introduce any new threats		These optimizations are not known to introduce any new threats
	against Neighbor Discovery beyond what is already documented for IPv6		against Neighbor Discovery beyond what is already documented for IPv6
	[RFC 3756].		[RFC 3756].
	Section 11.2 of [ND] applies to this document as well.		Section 11.2 of [ND] applies to this document as well.
	This mechanism minimizes the possibility of ND /64 DOS attacks in		This mechanism minimizes the possibility of ND /64 DOS attacks in
	efficiency-aware mode. See Section 11.1.		efficiency-aware mode. See Section 11.1.
	21. IANA Considerations		22. IANA Considerations
	A new flag (E-bit) in RA has been introduced. IANA assignment of the		A new flag (E-bit) in RA has been introduced. IANA assignment of the
	E-bit flag is required upon approval of this document.		E-bit flag is required upon approval of this document.
	22. Changelog		23. Changelog
	Changes from draft-chakrabarti-nordmark-energy-aware-nd-02:		Changes from draft-chakrabarti-nordmark-energy-aware-nd-02:
	o Added clarification that SLLA is not required for ARO in a		o Added clarification that SLLA is not required for ARO in a
	point-to-point link		point-to-point link
	o Clarified that the document is indeed an optimization for legacy		o Clarified that the document is indeed an optimization for legacy
	IPv6 ND		IPv6 ND
	o Adressed editorial comments and fixed typoes. Some more		o Adressed editorial comments and fixed typoes. Some more
	editorial work is needed		editorial work is needed
	o Added another usecase for Z-Wave example. Clarified 3GPP		o Added another usecase for Z-Wave example. Clarified 3GPP
	Networks related comments on existing ND optimizations.		Networks related comments on existing ND optimizations.
	23. Acknowledgements		24. Acknowledgements
	The primary idea of this document are from 6LoWPAN Neighbor Discovery		The primary idea of this document are from 6LoWPAN Neighbor Discovery
	document [6LOWPAN-ND] and the discussions from the 6lowpan working		document [6LOWPAN-ND] and the discussions from the 6lowpan working
	group members, chairs Carsten Bormann and Geoff Mulligan and through		group members, chairs Carsten Bormann and Geoff Mulligan and through
	our discussions with Zach Shelby, editor of the [6LOWPAN-ND].		our discussions with Zach Shelby, editor of the [6LOWPAN-ND].
	The inspiration of such a IPv6 generic document came from Margaret		The inspiration of such a IPv6 generic document came from Margaret
	Wasserman who saw a need for such a document at the IOT workshop at		Wasserman who saw a need for such a document at the IOT workshop at
	Prague IETF.		Prague IETF.
	skipping to change at page 27, line 37 ¶		skipping to change at page 28, line 10 ¶
	by Joel Halpern. Thanks to Joel Halpern for pinpointing the problems		by Joel Halpern. Thanks to Joel Halpern for pinpointing the problems
	that are now addressed in the NCE management section.		that are now addressed in the NCE management section.
	The authors like to thank Dave Thaler, Stuart Cheshire, Jari Arkko,		The authors like to thank Dave Thaler, Stuart Cheshire, Jari Arkko,
	Ylva Jading, Niklas J. Johnsson, Reda Nedjar, Purvi Shah, Jaume Rius		Ylva Jading, Niklas J. Johnsson, Reda Nedjar, Purvi Shah, Jaume Rius
	Riu, Fredrik Garneij, Andrew Yourtchenko, Jouni Korhonen, Suresh		Riu, Fredrik Garneij, Andrew Yourtchenko, Jouni Korhonen, Suresh
	Krishnan, Brian Haberman, Anders Brandt, Mark Smith, Lorenzo Colitti,		Krishnan, Brian Haberman, Anders Brandt, Mark Smith, Lorenzo Colitti,
	David Miles and Carsten Bormann for their useful comments and		David Miles and Carsten Bormann for their useful comments and
	suggestions on this work.		suggestions on this work.
	24. References		25. References
	24.1. Normative References		25.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an		[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
	IANA Considerations Section in RFCs", BCP 26, RFC 2434,		IANA Considerations Section in RFCs", BCP 26, RFC 2434,
	October 1998.		October 1998.
	[6LOWPAN-ND]		[6LOWPAN-ND]
	Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann,		Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann,
	skipping to change at page 28, line 17 ¶		skipping to change at page 28, line 37 ¶
	September 2007.		September 2007.
	[LOWPAN] Montenegro, G. and N. Kushalnagar, "Transmission of IPv6		[LOWPAN] Montenegro, G. and N. Kushalnagar, "Transmission of IPv6
	Packets over IEEE 802.15.4 networks", RFC 4944,		Packets over IEEE 802.15.4 networks", RFC 4944,
	September 2007.		September 2007.
	[LOWPANG] Kushalnagar, N. and G. Montenegro, "6LoWPAN: Overview,		[LOWPANG] Kushalnagar, N. and G. Montenegro, "6LoWPAN: Overview,
	Assumptions, Problem Statement and Goals", RFC 4919,		Assumptions, Problem Statement and Goals", RFC 4919,
	August 2007.		August 2007.
	24.2. Informative References		25.2. Informative References
	[IPV6] Deering, S. and R. Hinden, "Internet Protocol, Version 6		[IPV6] Deering, S. and R. Hinden, "Internet Protocol, Version 6
	(IPv6), Specification", RFC 2460, December 1998.		(IPv6), Specification", RFC 2460, December 1998.
	[DNA] Krishnan, S. and G. Daley, "Simple Procedures for		[DNA] Krishnan, S. and G. Daley, "Simple Procedures for
	Detecting Network Attachments in IPv6", RFC 6059,		Detecting Network Attachments in IPv6", RFC 6059,
	November 2010.		November 2010.
	[RFC6550] "RPL: IPv6 Routing Protocol for Low-Power and Lossy		[RFC6550] "RPL: IPv6 Routing Protocol for Low-Power and Lossy
	Networks", RFC 6550, March 2012.		Networks", RFC 6550, March 2012.
	skipping to change at page 31, line 33 ¶		skipping to change at page 32, line 15 ¶
	Authors' Addresses		Authors' Addresses
	Samita Chakrabarti		Samita Chakrabarti
	Ericsson		Ericsson
	San Jose, CA		San Jose, CA
	USA		USA
	Email: samita.chakrabarti@ericsson.com		Email: samita.chakrabarti@ericsson.com
	Erik Nordmark		Erik Nordmark
			Arista Networks
	San Jose, CA		San Jose, CA
	USA		USA
	Email: nordmark@sonic.net		Email: nordmark@sonic.net
	Pascal Thubert		Pascal Thubert
	Cisco Systems		Cisco Systems
	Email: pthubert@cisco.com		Email: pthubert@cisco.com
	Margaret Wasserman		Margaret Wasserman
	Painless Security		Painless Security
	Email: mrw@lilacglade.org		Email: mrw@lilacglade.org
End of changes. 29 change blocks.
	48 lines changed or deleted		66 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/