Re: [ipwave] Last Call: <draft-ietf-ipwave-ipv6-over-80211ocb-46.txt> (Basic support for IPv6 over IEEE Std 802.11 Networks operating Outside the Context of a Basic Service Set (IPv6-over-80211-OCB)) to Proposed Standard

[NABIL BENAMAR <[e-mail]>]

Hi Jinmei,

Thank you for your comment.

What do you think of the following changes:

OLD

In the Introduction

“

   "....The resulting stack operates over 802.11-OCB

   and provides at least P2P connectivity using IPv6 ND and link-local

   addresses."



“
NEW

“

   "......The resulting stack inherits from IPv6 over Ethernet [RFC
2464] and operates over 802.11-OCB

   providing at least P2P connectivity using IPv6 ND and link-local addresses.



In section 4.3


I will add the following sentence



    The best practices for forming IPv6 addresses are inherited from
Ethernet.

    In particular, the IID is 64 bits long [RFC2464
<https://tools.ietf.org/html/rfc2464>].






On Thu, Jun 13, 2019 at 7:50 PM 神明達哉 <[e-mail]> wrote:

> On Wed, Jun 12, 2019 at 12:16 PM The IESG <[e-mail]> wrote:
>
> > The IESG has received a request from the IP Wireless Access in
> > Vehicular Environments WG (ipwave) to consider the following
> > document: - 'Basic support for IPv6 over IEEE Std 802.11 Networks
> > operating Outside the Context of a Basic Service Set
> > (IPv6-over-80211-OCB)' <draft-ietf-ipwave-ipv6-over-80211ocb-46.txt>
> > as Proposed Standard
>
> > The IESG plans to make a decision in the next few weeks, and
> > solicits final comments on this action. Please send substantive
> > comments to the [e-mail] mailing lists by 2019-06-26.
>
> Version 46 of this draft doesn't seem to specify the exact length
> of the interface identifier.  RFC4862 expects it to be specified in
> this kind of "link-type specific document":
>
>    interface identifier - [...] The
>       exact length of an interface identifier and the way it is created
>       is defined in a separate link-type specific document that covers
>       issues related to the transmission of IP over a particular link
>       type (e.g., [RFC2464]).  Note that the address architecture
>       [RFC4291] also defines the length of the interface identifiers for
>       some set of addresses, but the two sets of definitions must be
>       consistent.
>
> Specifying the length is critical since (for example) otherwise an
> implementation can't perform the validation described in Section 5.5.3 of
> RFC4862.
>
> I suggest Section 4.4 (and probably also 4.3 for link-local) of this
> draft explicitly specifies the length of the interface identifier.
> And then I'd note that the length can (in practice) only be 64 bits
> because of the assumption about the consistency with the address
> architecture (the "Note that..." part of the above citation) and
> because of the fact that the current address architecture states the
> length is 64 bits for link-local and practically all global IPv6
> addresses in use.  I'm aware of the (in)famous tussle on the use of
> the fixed value of 64, but I'm not making this comment for advocating
> for the fixed value; I'm just pointing out a logical consequence of
> the assumption of the current SLAAC standard and the constants used in
> the current standards.
>
> --
> JINMEI, Tatuya
>
> On Wed, Jun 12, 2019 at 12:16 PM The IESG <[e-mail]> wrote:
>
>>
>> The IESG has received a request from the IP Wireless Access in Vehicular
>> Environments WG (ipwave) to consider the following document: - 'Basic
>> support
>> for IPv6 over IEEE Std 802.11 Networks operating Outside
>>    the Context of a Basic Service Set (IPv6-over-80211-OCB)'
>>   <draft-ietf-ipwave-ipv6-over-80211ocb-46.txt> as Proposed Standard
>>
>> The IESG plans to make a decision in the next few weeks, and solicits
>> final
>> comments on this action. Please send substantive comments to the
>> [e-mail] mailing lists by 2019-06-26. Exceptionally, comments may be
>> sent to [e-mail] instead. In either case, please retain the
>> beginning of
>> the Subject line to allow automated sorting.
>>
>> Abstract
>>
>>
>>    This document provides methods and settings, and describes
>>    limitations, for using IPv6 to communicate among nodes in range of
>>    one another over a single IEEE 802.11-OCB link with minimal change to
>>    existing stacks.  Optimizations and usage of IPv6 over more complex
>>    scenarios is not covered and is subject of future work.
>>
>>
>>
>>
>> The file can be obtained via
>> https://datatracker.ietf.org/doc/draft-ietf-ipwave-ipv6-over-80211ocb/
>>
>> IESG discussion can be tracked via
>>
>> https://datatracker.ietf.org/doc/draft-ietf-ipwave-ipv6-over-80211ocb/ballot/
>>
>>
>> No IPR declarations have been submitted directly on this I-D.
>>
>>
>> The document contains these normative downward references.
>> See RFC 3967 for additional information:
>>     rfc3753: Mobility Related Terminology (Informational - IETF stream)
>>     rfc7721: Security and Privacy Considerations for IPv6 Address
>> Generation Mechanisms (Informational - IETF stream)
>>     rfc5889: IP Addressing Model in Ad Hoc Networks (Informational - IETF
>> stream)
>>     rfc6959: Source Address Validation Improvement (SAVI) Threat Scope
>> (Informational - IETF stream)
>>
>>
>>
>>
>>

-- 

Best Regards

Nabil Benamar
Associate Professor
Department of Computer Sciences
School of Technology
Moulay Ismail University
Meknes. Morocco