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

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

At Fri, 14 Jun 2019 19:13:34 +0100,
NABIL BENAMAR <[e-mail]> wrote:

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

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

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

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