[ipwave] ND potential issues in Wireless Links - request for inclusion in Problem Statement draft

[Alexandre Petrescu <[e-mail]>]

Hi Paul,

I would like to request you as the editor, to include this xml text in 
the Problem Statement draft of IPWAVE WG.

This text was discussed recently in the IPWAVE WG.  It was initially a 
part of the IPv6-over-OCB draft, but it is more of a Problem Statement 
than a solution.

The original author of the text is Pascal Thubert.  The text was a bit 
tweaked by me and others.  Maybe Pascal would like to make sure his 
intent is still reflected.

RFC8505 citation: from my standpoint, if this paragraph is placed in the 
Problem Statement draft, and if it wants to cite a potential solution to 
the ND problems like RFC8505, then I will not disagree.

Note: the Problem Statement draft already mentions something about 
6lowpan in its section 'Link Model'.

Yours,

Alex

--------------------------------------------------------------------------------
     <section title='Neighbor Discovery (ND) Potential Issues in 
Wireless Links'
	     anchor='nd-wireless'>
       <t>
	IPv6 Neighbor Discovery (IPv6 ND) [RFC4861][RFC4862] was
	designed for point-to-point and transit links such as
	Ethernet, with the expectation of a cheap and reliable support
	for multicast from the lower layer. Section 3.2 of RFC 4861
	indicates that the operation on Shared Media and on
	non-broadcast multi-access (NBMA) networks require additional
	support, e.g., for Address Resolution (AR) and duplicate
	address detection (DAD), which depend on multicast. An
	infrastructureless radio network such as OCB shares properties
	with both Shared Media and NBMA networks, and then adds its
	own complexity, e.g., from movement and interference that
	allow only transient and non-transitive reachability between
	any set of peers.
       </t>
       <t>
	The uniqueness of an address within a scoped domain is a key
	pillar of IPv6 and the base for unicast IP communication. RFC
	4861 details the DAD method to avoid that an address is
	duplicated. For a link local address, the scope is the link,
	whereas for a Globally Reachable address the scope is much
	larger.  The underlying assumption for DAD to operate
	correctly is that the node that owns an IPv6 address can reach
	any other node within the scope at the time it claims its
	address, which is done by sending a NS multicast message, and
	can hear any future claim for that address by another party
	within the scope for the duration of the address ownership.
       </t>
       <t>
	In the case of OCB, there is a potentially a need to define a
	scope that is compatible with DAD, and that cannot be the set
	of nodes that a transmitter can reach at a particular time,
	because that set varies all the time and does not meet the DAD
	requirements for a link local address that could possibly be
	used anytime, anywhere. The generic expectation of a reliable
	multicast is not ensured, and the operation of DAD and AR
	(Address Resolution) as specificed by RFC 4861 cannot be
	guaranteed.  Moreoever, multicast transmissions that rely on
	broadcast are not only unreliable but are also often
	detrimental to unicast traffic (see
	[draft-ietf-mboned-ieee802-mcast-problems]).
       </t>
       <t>
	Early experience indicates that it should be possible to
	exchange IPv6 packets over OCB while relying on IPv6 ND alone
	for DAD and AR (Address Resolution) in good conditions.
	However, this does not apply if TBD TBD TBD.  In the absence
	of a correct DAD operation, a node that relies only on IPv6 ND
	for AR and DAD over OCB should ensure that the addresses that
	it uses are unique by means others than DAD. It must be noted
	that deriving an IPv6 address from a globally unique MAC
	address has this property but may yield privacy issues.
       </t>
       <t>
	RFC 8505 provides a more recent approach to IPv6 ND and in
	particular DAD. RFC 8505 is designed to fit wireless and
	otherwise constrained networks whereby multicast and/or
	continuous access to the medium may not be guaranteed. RFC
	8505 Section 5.6 "Link-Local Addresses and Registration"
	indicates that the scope of uniqueness for a link local
	address is restricted to a pair of nodes that use it to
	communicate, and provides a method to assert the uniqueness
	and resolve the link-Layer address using a unicast exchange.
       </t>
       <t>
	RFC 8505 also enables a router (acting as a 6LR) to own a
	prefix and act as a registrar (acting as a 6LBR) for addresses
	within the associated subnet. A peer host (acting as a 6LN)
	registers an address derived from that prefix and can use it
	for the lifetime of the registration. The prefix is advertised
	as not onlink, which means that the 6LN uses the 6LR to relay
	its packets within the subnet, and participation to the subnet
	is constrained to the time of reachability to the 6LR. Note
	that RSU that provides internet connectivity MAY announce a
	default router preference [RFC 4191], whereas a car that does
	not provide that connectivity MUST NOT do so. This operation
	presents similarities with that of an access point, but at
	Layer-3. This is why RFC 8505 well-suited for wireless in
	general.
       </t>
       <t>
	Support of RFC 8505 is may be implemented on OCB. OCB nodes
	that support RFC 8505 would support the 6LN operation in order
	to act as a host, and may support the 6LR and 6LBR operations
	in order to act as a router and in particular own a prefix
	that can be used by RFC 8505-compliant hosts for address
	autoconfiguration and registration.
       </t>
     </section>