Subject: [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

From: The IESG <[email-masked]>
Date: Wed, 12 Jun 2019 12:16:30 -0700

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
[email-masked] mailing lists by 2019-06-26. Exceptionally, comments may be
sent to [email-masked] 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)

---

From: 神明達哉 <[email-masked]>
Date: Thu, 13 Jun 2019 11:50:37 -0700

On Wed, Jun 12, 2019 at 12:16 PM The IESG <[email-masked]> 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 [email-masked] 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 <[email-masked]> wrote:

>     rfc7721: Security and Privacy Considerations for IPv6 Address
> Generation Mechanisms (Informational - IETF stream)

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 14 Jun 2019 14:25:23 +1200

I fully agree with Jinmei-san's comment.

Regards
   Brian Carpenter

On 14-Jun-19 06:50, 神明達哉 wrote:
> On Wed, Jun 12, 2019 at 12:16 PM The IESG <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> comments to the [email-masked] <mailto:[email-masked]> mailing lists by 2019-06-26.
> 
> of the interface identifier..  RFC4862 expects it to be specified in
> On Wed, Jun 12, 2019 at 12:16 PM The IESG <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
>     [email-masked] <mailto:[email-masked]> mailing lists by 2019-06-26. Exceptionally, comments may be
>     sent to [email-masked] <mailto:[email-masked]> instead. In either case, please retain the beginning of

---

From: NABIL BENAMAR <[email-masked]>
Date: Fri, 14 Jun 2019 19:13:34 +0100

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

-- 

Best Regards

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

---

From: 神明達哉 <[email-masked]>
Date: Fri, 14 Jun 2019 11:57:44 -0700

At Fri, 14 Jun 2019 19:13:34 +0100,

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

I don't have a strong opinion on this addition, but it wouldn't do
harm.

> <https://tools.ietf.org/html/rfc2464>].

This doesn't seem to be very consistent with the tone of the other
part of the section, in particular:

   Among these types of
   addresses only the IPv6 link-local addresses MAY be formed using an
   EUI-64 identifier, in particular during transition time.
and
   If the IPv6 link-local address is formed using an EUI-64 identifier,...

In that RFC2464 only specifies EUI-64 based identifier while this
draft states it's a MAY.  If I were to edit the section, I'd simply
specify the IID length at the end of the section like this:

  Whether or not the interface identifier is derived from the EUI-64
  identifier, its length is 64 bits as is the case for Ethernet
  [RFC2464].

And for section 4.4, I'd add, for example, the following sentence at
the end of the second paragraph:

  Regardless of how to form the Interface Identifier, its length is 64
  bits, as is the case of the IPv6 over Ethernet specification
  [RFC2464].

--
JINMEI, Tatuya