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

["Mr. Jaehoon Paul Jeong" <[e-mail]>]

Hi Alex,
I will reflect a part of the text below for a problem statement abound the
ND and link model.
In the revision of the IPWAVE PS draft, I will make its text as short and
concrete as possible
according to the request from Sri and Russ such that the PS draft should
focus on
the problems themselves without possible solutions.

I will acknowledge Pascal as a contributor in the PS draft.

Thanks.

Best Regards,
Paul

On Thu, Apr 18, 2019 at 9:39 PM Alexandre Petrescu <
[e-mail]> wrote:

> 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>
>


-- 
===========================
Mr. Jaehoon (Paul) Jeong, Ph.D.
Associate Professor
Department of Software
Sungkyunkwan University
Office: [phone]
Email: [e-mail], [e-mail]
Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php
<http://cpslab.skku.edu/people-jaehoon-jeong.php>