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

[神明達哉 <[e-mail]>]

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