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].
On Thu, Jun 13, 2019 at 7:50 PM 神明達哉 <jinmei@xxxxxxxxxx> wrote:
On Wed, Jun 12, 2019 at 12:16 PM The IESG <iesg-secretary@xxxxxxxx> 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 ietf@xxxxxxxx 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, TatuyaOn Wed, Jun 12, 2019 at 12:16 PM The IESG <iesg-secretary@xxxxxxxx> 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
ietf@xxxxxxxx mailing lists by 2019-06-26. Exceptionally, comments may be
sent to iesg@xxxxxxxx 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
