Re: [ipwave] Review comments on draft-ietf-ipwave-ipv6-over-80211ocb-04.txt

["Sri Gundavelli (sgundave)" <[e-mail]>]

Hi Alex,

Thanks for posting the new version addressing some of my comments. My main
issue is still about the nature of the link based on 802.11-OCB and the
big change that this operating environment (Vehicular) brings to the
table. We can certainly insist that the scope of this work is about
IPv6-over-foo and so any discussions around address configuration modes,
ND, link models, link prefixes ..etc is out of scope. But, note that the
IEEE definition of WAVE, 802.11-OCB, or the DSRC spectrum band is strictly
for vehicular environments and so I tend to this document has to make sure
we explain how one can make IPv6 and the dependent protocols work on
802.11-OCB based links.  We cannot ignore the operating environment.

For a node to send an IPv6 packet, it surely needs to be able to do the
L2/L3 mapping to the respective access technology and transmit the packet.
But, it also needs to generate an IPv6 address (link-local / global),
perform DAD on the link, perform ND resolutions for the destination
address, do the route lookups and send the packet out. So, what is not
clear to me from reading the spec is how all of that works on 802.11-OCB.

1.) Lets take a high-way scenario where 3 vehicles (A, B, C) come in close
proximity and can communicate among themselves.

At T=0, 
C-—A-—B

At T=1, one of the vehicle moves on (with signal level < 33 dbm) from the
previous neighbors. But there is a new node D in the vicinity. Also, node
C is now in another group ( C, E and F)
D-—A—-B

C-—E-—F

From the classic link sense, the node configurations have changed.


2.) How do the nodes communicate among themselves in the base scenario. Do
they use link-local or global address? How do they generate the addresses?

3.) If its global, how do they discover the on-link prefix?

3.) If its link-local (or global) How does DAD work in the above scenario?
With the link topology changing so dynamically, how can ND work here?

4.) Will the nodes support all standard multicast groups. For example,
will they participate in ALL_NODES_MULTICAST GROUP (FF02::1). IF yes, why
is the spec defining a new group for OCB nodes? Why is that needed?


Please see inline for other comments





On 9/10/17, 5:35 PM, "Sri Gundavelli (sgundave)" <[e-mail]>
wrote:

>
>
>On 9/10/17, 6:59 AM, "Alexandre Petrescu" <[e-mail]>
>wrote:
>
>>Sri,
>>
>>Thanks for the review.
>>
>>Le 27/08/2017 à 16:44, Sri Gundavelli (sgundave) a écrit :
>>[...]
>>
>>> 1.) Its not clear, if the document makes any assumption on the
>>> operating environment/communication profile. There is not much
>>> discussion on that aspect; For example, Is it always a one-hop
>>> communication between RSU and OBU where the 802.11-OCB link?  So, is
>>> the use of IPv6 only in that context of 1-hop communication?
>>
>>The question is very relevant, but not place in this document to go to
>>much extent about it in an IP-over-foo document.


I would have agreed with the “IP-over-foo” analogy and stay away from
answering many question, but lets look at the WAVE, 802-11-OCB and DSRC
definitions. It clearly for vehicular environments. That the baseline
assumption. So, when we say IPv6 for 802-11-OCB, the operating environment
cannot be ignored.



>>
>>To answer now: is that 1 OCB hop is right at this time.
>>
>>> 2.) There is also no discussion on how these links get formed in
>>> vehicular environment and when they are attached/detached.
>>
>>As above.
>>
>>> 3.) How do nodes discover each other?  How does ND resolution work?
>>> Are these messages received by a multiple RSU¹s, or a single RSU?
>>> Whats the implication of that. Note that you don¹t have that issue in
>>> 802.11, given the association to an access point, which in turn maps
>>> the links to a VLAN/subnet.
>>
>>I think ND may answer to some of the questions.
>>> 
>>> 4.) What happens as a vehicle moves between RSU¹s, how does it impact
>>>  address configuration?
>>
>>Mobile IP, but not in this document.
>>
>>> Is DHCPv6 based address configuration relevant here?
>>
>>YEs, but not to describe the detail use of DHCPv6-over-foo on
>>IP-over-foo.
>>
>>If you want to just refer to DHCP, that would be at which place in this
>>document?
>>


Sure, but this is a special type of link and so its not clear how this
works.

DHCP server can be outside the link; in the current spec, its not clear
how the node even discovers the on-link prefix, or the default router.


>>
>>[...]
>>> We briefly introduce the vehicular communication scenarios where
>>> IEEE 802.11-OCB links are used.
>>> 
>>> 
>>> [Sri] I have not seen much discussion on the link / communication
>>> assumptions.
>>
>>That's why it says 'briefly'.
>>
>>[...]
>>
>>> The IEEE 802.11 OCB Networks are used for vehicular communications,
>>> as 'Wireless Access in Vehicular Environments'.  The IP
>>> communication scenarios for these environments have been described in
>>> several documents, among which we refer the reader to one recently
>>> updated [I-D.petrescu-its-scenarios-reqs
>>> 
>>><https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#ref
>>>-
>>>I-D.petrescu-its-scenarios-reqs>],
>>> about scenarios and requirements for IP in Intelligent Transportation
>>> Systems.
>>> 
>>> 
>>> [Sri] You can do bit more justice to this section.
>>> 
>>> Explain the link model. ³STA ----802.11-OCB‹‹STA². Then talk about
>>> the applicability in Vehicular networks, with STA's as RSU and OCB.
>>> 
>>> You may also want to talk about, how links get formed/terminated; how
>>>  nodes peer/discover and how mobility works ..etc. While 802.11-OCB
>>> is clearly specified and the use of IPv6 over such link is also not
>>> radically new, but the operating environment which is vehicular
>>> brings many new things. That description is not present any where.
>>
>>I mentioned it but the details are out of scope for an IPv6 over foo
>>document.


Per my comments in the beginning ...




>>
>>[...]
>>
>>> [Sri] I am really not sure how link throughput (12Mbps) relates to
>>> "IPv6 support on OCB links".
>>
>>802.11-OCB max 12mbit/s means one _can_ run a wide range of applications
>>on it.  Other links are so small and rare that you can not run IPv6 on
>>them, must change IPv6. (LORA, 15.4, etc).
>>
>>> o  Operation Outside the Context of a BSS (OCB): the (earlier
>>> 802.11p) 802.11-OCB links are operated without a Basic Service Set
>>> (BSS).  This means that the frames IEEE 802.11 Beacon, Association
>>> Request/Response, Authentication Request/Response, and similar, are
>>> not used.  The used identifier of BSS (BSSID) has a hexadecimal value
>>> always 0xffffffffffff (48 '1' bits, represented as MAC address
>>> ff:ff:ff:ff:ff:ff, or otherwise the 'wildcard' BSSID), as opposed to
>>> an arbitrary BSSID value set by administrator (e.g.
>>> 'My-Home-AccessPoint').  The OCB operation - namely the lack of
>>> beacon-based scanning and lack of authentication - has a potentially
>>> strong impact on the use of the Mobile IPv6 protocol [RFC6275
>>> <https://tools.ietf.org/html/rfc6275>] and on the protocols for IP
>>> layer security [RFC4301 <https://tools.ietf.org/html/rfc4301>].
>>> 
>>> 
>>> [Sri] The document till now has been arguing heavily on how IPv6
>>> operates so naturally on these links and now I see discussion on
>>> ³Impact to a high-level protocol such as MIPv6². You may want to fix
>>> the earlier text.
>>I removed 'impact' word.   But also, the way MIP adapts to OCB is
>>outside the scope of this document.
>>
>>> In any case, the absence of link-layer security practically impacts
>>> every application, not just MIPv6. Also, MIPv6 does not make any
>>> assumptions on the link-layer security. Also, the the
>>> 0xFF-FF-FF-FF-FF-FF as the BSSID, makes the messages readable by all
>>>  other RSU¹s in proximity. I think the discussion on the nature of
>>> the link, who all see¹s the messages.. how L2 addresses are resolved
>>> is not explained clearly.
>>
>>I added some text about ND and some in the security section about how
>>this is open.
>>
>>[...]
>>
>>> Other aspects particular to 802.11-OCB which are also particular to
>>> 802.11 (e.g. the 'hidden node' operation) may have an influence on
>>> the use of transmission of IPv6 packets on 802.11-OCB networks.*The
>>> subnet structure which may be assumed in 802.11-OCB networks is
>>> strongly influenced by the mobility of vehicles.*
>>> 
>>> 
>>> [Sri] Per my earlier comment, the link model, addressing ..etc needs
>>> to be explained in more detail. It is not clear what exactly the
>>> ³subnet structure² that is assumed in 802.11-OCB.
>>
>>Improved the subnet structure section.


May require few more details


>>
>>[...]>     The Equivalent Transmit Time on Channel is a concept that may
>>be used
>>> as an alternative to the MTU concept.  A rate of transmission may be
>>> specified as well.  The ETTC, rate and MTU may be in direct
>>> relationship.
>>> 
>>> [Sri] The last paragraph needs some additional context. Did
>>> 802.11-OCB introduce ETTC concept?
>>
>>We heard this term at mic in Berlin BoF.  Sounded like a more universal
>>term.  Should we remove it?



I understand the relation between MTU and the ETTC. But, if we talk about
it, we have to explain which parameter drives the other. How do you
exactly set the MTU based on the ETTC rate. More details on needed.



>>
>>[...]
>>> The mapping between qos-related fields in the IPv6 header (e.g.
>>> "Traffic Class", "Flow label") and fields in the "802.11 QoS Data
>>> Header" (e.g.  "QoS Control") are not specified in this document.
>>> Guidance for a potential mapping is provided in
>>> [I-D.ietf-tsvwg-ieee-802-11
>>> 
>>><https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#ref
>>>-
>>>I-D.ietf-tsvwg-ieee-802-11>],
>>> although it is not specific to OCB mode.
>>> 
>>> 
>>> 
>>> [Sri] The applicability of the QoS mapping draft to 802.11-OCB needs
>>>  further investigation, IMO.
>>
>>YEs, it is out of scope in this document.
>>
>>> 5.3 
>>> 
>>><https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#sec
>>>t
>>>ion-5.3>.
>>>
>>> 
>>Link-Local Addresses
>>> 
>>> 
>>> 
>>> The link-local address of an 802.11-OCB interface is formed in the
>>> same manner as on an Ethernet interface.  This manner is described
>>> in section 5 of [RFC2464]
>>> <https://tools.ietf.org/html/rfc2464#section-5>.
>>> 
>>> 
>>> 
>>> [Sri] Does this go against the 8064 recommendation on Interface
>>> identifier generation?
>>
>>YEs.


We should state that.



>>
>>> May be RFC7217 for interface identifier generation in conjunction
>>> with the link-local address generation per RFC2464
>>
>>YEs.  But I think it's up to rfc2464-bis to say that, and this
>>IPv6-over-OCB to just refer to rfc2464-bis.

As with any bis document, its not going merge newer specs into it. We
still need to refer to the other documents, IMO.




>>
>>[...]
>>> For unicast as for multicast, there is no change from the unicast
>>> and multicast address mapping format of Ethernet interfaces, as
>>> defined by sections6
>>> 
>>><https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#sec
>>>t
>>>ion-6>
>>> and7 
>>> 
>>><https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#sec
>>>t
>>>ion-7>
>>> of [RFC2464 <https://tools.ietf.org/html/rfc2464>].
>>> 
>>> 
>>> 
>>> [Sri] RFC6085 specified mapping is also relevant; If the
>>> communication peers are aware that there is only one peer, it should
>>> apply 6085 specified mapping. That mode is relevant for 802.11-OCB
>>> types links as well.
>>
>>Same here, would be great to get 6085 into 2464-bis, at which point this
>>ip-over-ocb inherits from 2464-bis.


I do not think 2464-bis will add new references. Its up to you, but 6085
may be relevant here.


>>
>>I added a reference to 2464-bis.
>>
>>> 5.4.1 
>>> 
>>><https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#sec
>>>t
>>>ion-5.4.1>.
>>>
>>> 
>>Address Mapping -- Unicast
>>> 
>>> 
>>> 
>>> The procedure for mapping IPv6 unicast addresses into Ethernet link-
>>> layer addresses is described in [RFC4861
>>> <https://tools.ietf.org/html/rfc4861>].  The Source/Target Link-
>>> layer Address option has the following form when the link-layer is
>>> Ethernet.
>>> 
>>> [Sri] I thought, mapping of IPv6 unicast addresses to Ethernet
>>> link-layer addresses is specified in section 6, of RFC2464 and not in
>>>  RFC4861.
>>
>>Either we have a brief paragraph that just refers to 2464 section 6, or
>>copy paste that section from 2464 and update its [DISC] reference to
>>4861.  That I did, in order to have the text a bit longer.
>>
>>At this time I keep it that way, unless someone opposes.


May be I am missing some thing. The mapping is defined in 2464 and so the
4861 reference may be incorrect.


>>
>>A key question here is how is 2464bis advancing, and how we coordinate
>>with it.
>>[...]
>>> An IPv6 packet with a multicast destination address DST, consisting
>>> of the sixteen octets DST[1] through DST[16], is transmitted to the
>>> IEEE 802.11-OCB MAC multicast address whose first two octets are the
>>> value 0x3333 and whose last four octets are the last four octets of
>>> DST.
>>> 
>>> [Sri] Please add a reference to Section 7, RFC4861 and also RFC6085.
>>> In general, for both unicast and multicast, you may want to clearly
>>> say that this is per the existing specs and duplicated here for
>>> convenience.
>>
>>Should _this_ document do it, or should the 2464bis do it?  At this time
>>I keep it that way.


I am not tracking the bis and so not sure if it will include all these
documents. Any ways …your call

>>[...]
>>
>>> The Interface Identifier for an 802.11-OCB interface is formed using
>>> the same rules as the Interface Identifier for an Ethernet
>>> interface; this is described insection 4 of [RFC2464]
>>> <https://tools.ietf.org/html/rfc2464#section-4>.  No changes are
>>> needed, but some care must be taken when considering the use of the
>>> SLAAC procedure.
>>> 
>>> 
>>> 
>>> [Sri] Per my earlier comment, please refer to the current
>>> recommendation on interface-identifier generation and its use in
>>> link-local, global or other addresses.
>>
>>Per my comments above - what do you think about 2464bis doing your
>>recommendations, rather than this one.
>>
>>Depending on that, we can see further with this document.
>>
>>[...]
>>
>>> The 802.11 networks in OCB mode may be considered as 'ad-hoc'
>>> networks.  The addressing model for such networks is described in
>>> [RFC5889 <https://tools.ietf.org/html/rfc5889>].o
>>> 
>>> 
>>> [Sri] Per my earlier comment, there is no system level view of the
>>> network where 802.11-OCB links are used. So, in the absence of such
>>> discussion So, I am not sure what part of RFC5889 is applicable here.
>>> 
>>That's the only RFC the IETF has about the subnet structure in 'ad-hoc'
>>networks, and the 'ad-hoc' is what OCB is like.
>>
>>> For example, link-local addresses may just work fine.
>>
>>Yes, added.
>>
>>[...]
>>
>>> Overall, the captured message is identical with a capture of an IPv6
>>> packet emitted on a 802.11b interface.  The contents are precisely
>>> similar.
>>> 
>>> 
>>> [Sri] I suggest moving this discussion under the section
>>> ³Implementation Status²,
>>
>>Agreed.
>>
>>> which will eventually be removed from the RFC.
>>
>>But at the same time it depicts this topology of
>>Router-connected-to-Host, using 802.11-OCB.  This is something that you
>>requested earlier with STA1----STA2 with OCB in the middle.
>>
>>So I suggest to keep this section in Appendix.
>>
>>> There is nothing new here. This are details on experimentation. But,
>>> if you think there is some useful information such as discussion on
>>> Capture mode ..etc, you may want to move this entire section to
>>> Appendix. Implementors may use these tools for verification.
>>
>>Yes.
>>
>>[...] >
>><https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-04#sect
>>i
>>on-8>.
>>> IANA Considerations
>>> 
>>> 
>>> 
>>> [Sri] I though there was one IANA request on some multicast related?
>>
>>added
>>
>>Alex
>