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 <iesg-secretary@xxxxxxxx <mailto: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 <mailto: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, Tatuya > > On Wed, Jun 12, 2019 at 12:16 PM The IESG <iesg-secretary@xxxxxxxx <mailto: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 <mailto:ietf@xxxxxxxx> mailing lists by 2019-06-26. Exceptionally, comments may be > sent to iesg@xxxxxxxx <mailto: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) > > > >
