Re: [ipwave] FW: ipwave - comments and concerns - 1609 WAVE, EPD - towards resolution

[Tijink Jasja <[e-mail]>]

Hi Alex,

on the EAL topic. Take again the following text from the draft:

" IP packets are transmitted over 802.11-OCB as standard Ethernet
   packets.  As with all 802.11 frames, an Ethernet adaptation layer
   MUST be used with 802.11-OCB as well."

I understand the second sentence is a requirement you put to implementations that feature an ethernet interface and an 802.11 interface. 

But the first sentence: that one seems not true to me according to what you report of your own tests - 802.11 packets do not have ethernet headers. So the first sentence is incorrect, right? Or do I simply misunderstand it and what you want to say is: 

"IP packets are transmitted over 802.11-OCB as over standard Ethernet:  as with all 802.11 frames, an Ethernet adaptation layer  MUST be used with 802.11-OCB as well."


Regards Jasja


-----Ursprüngliche Nachricht-----
Von: Alexandre Petrescu [mailto:[e-mail]] 
Gesendet: Samstag, 17. März 2018 13:10
An: Kevin Smith <[e-mail]>
Cc: Tijink Jasja <[e-mail]>; [e-mail]
Betreff: Re: FW: [ipwave] ipwave - comments and concerns - 1609 WAVE, EPD - towards resolution


Le 16/03/2018 à 18:34, Kevin Smith a écrit :
[...]

> I suggest that in section 4.2.1 "Ethernet Adaptation Layer" we add the 
> following paragraph:
> 
>> The IPv6 packet transmitted on 802.11-OCB MUST be immediately 
>> preceded by a Logical Link Control (LLC) header and an 802.11 header. 
>> In the LLC header, and in accordance with the EtherType Protocol 
>> Discrimination (EPD), the value of the Type field MUST be  set to 
>> 0x86DD (IPv6).  In the 802.11 header, the value of the Subtype 
>> sub-field in the Frame Control field MUST be set to 8 (i.e.
>> 'QoS Data'); the value of the Traffic Identifier (TID) sub-field of 
>> the QoS Control field of the 802.11 header MUST be set to binary
>> 001 (i.e. User Priority 'Background', QoS Access Category 'AC_BK').
>> 
>> In the Ethernet II header, the value of the Type field MUST be set  
>> to 0x86DD (IPv6).
> 
> Do you agree with this text?
> 
> [KS]: I agree with the part that addresses the LLC header. I don't 
> disagree with the part addressing the 802.11 header, I'm just not an  
> expert in this area and so defer to others. I believe that others in  
> the 1609 WG have been discussing this with the ipwave list?

Noted.

Others have discussed the QoS part and there seems to be agreement with that.

>> I note that ipwave mentions EPD, but also SNAP and does not specify 
>> which method to use.
> 
> I propose we remove this phrase:
>> Other alternative views of layering are EtherType Protocol 
>> Discrimination (EPD), see Appendix E, and SNAP see [RFC1042].
> 
> Do you agree?
> 
> [KS]: Yes.

Noted.

>> Moreover ipwave discusses an abstract "Ethernet Adaptation Layer" 
>> but does not specify a header format, and this further confuses the 
>> question for deployers - what should we implement?
> 
> The Ethernet Adaptation Layer (more precisely 802.11-to-Ethernet AL)  
> is not so abstract, because it is widely implemented. This layer does 
> conversion between headers: at reception from the network it 
> transforms a .11/LLC header into an EthernetII header; reversely, at  
> sending it transforms an EthernetII header into a .11/LLC header.
> This is shown in Figure 1.
> 
> The EAL does not intend to specify a header format. The header formats 
> involved are the IEEE 802.11, LLC and EthernetII. The fields  in these 
> headers are specified by IEEE.
> 
> [KS]: I don't understand why the EAL is relevant to "Transmission of
>  IPv6 Packets over IEEE 802.11 Networks operating in mode Outside the  
> Context of a Basic Service Set". If I want to write software that 
> sends IPv6 packets over 802.11 OCB, all I need to know is how to 
> construct the LLC sublayer header, etc. The EAL sounds like a 
> "bridge", and perhaps belongs in a separate document (and perhaps has 
> already been addressed in some existing document?)

We wanted to have IPv6-over-OCB document that is minimal change from existing works: RFC 2464 IPv6-over-Ethernet and implementations.

In implementations, that's how IPv6 works: whenever IPv6 stack wants to sit on a link layer (802.15.4, WiFi, LTE) it actually sits on an Adaptation Layer.  Because IPv6 only knows Ethernet (RFC2464).

Whenever a new link layer technology appears, people struggle to make it first look like Ethernet.  Only then does IPv6 run easily on it.

Because of that, I tend to agree it could makes sense to make an
IPv6-over-802.11 document first (including EAL), and the OCB version
after.   The OCB version would be much smaller.

At the same time, such document IPv6-over-802.11 does not exist.  It could not be developped in the IPWAVE WG which is aiming at vehicle networking, not .11 in general.

It would take so long to create a new IPv6-over-.11 document, and only then to advance the IPv6-over-OCB draft.

An additional reason as to why it would take long is that the mapping of
IPv6 fields on 802.11 fields is not straightforward at all.  (QoS is one aspect, but there is also frag fields, security and more).

> Regardless, including a description of the EAL does not violate 
> anything in 1609.3, as it is out of scope with 1609.3.

Noted.

> 
> Some *new comments* from my side:
> 
> - ipwave 4.2.1 it states "An 'adaptation' layer is inserted between a 
> MAC layer and the Networking layer." This sounds like a requirement.
> If I am developing a product that is only concerned with sending IPv6 
> over OCB, and does not require "bridging", then how do I reconcile 
> this requirement?

It is a requirement indeed.  But the adaptation layer is already there, do not worry.

If one develops a new product, one is likely to use existing kernels - they do include EAL, even though they dont call it so.

If one develops from scratch (very rare), one would have to answer questions like how does Frag fields map between IPv6 and 802.11, security, and other very complicated questions.  Agreement would be
needed too.   I think one will rather prefer too to rely on Ethernet
(RFC2464), as so many other people did in the past.

"Bridging": I do not know what you mean by 'bridging'?  In linux bridging is a tool called 'brctl'.  It bridges two distinct interfaces, e.g. an Ethernet interface to a WiFi interface.  Here we would 'bridge'
Ethernet and 802.11 on the same interface.  It's not 'bridging', it's 'adaptation'.

Worse: 'brctl' does not work when we want to 'bridge' a OCB interface to an Ethernet interface.  I do not why.  I guess the 802. groups will figure it out one day and fix it.

But Ethernet Adaptation Layer (named 'bridging' by you?) works ok.

> - ipwave 4.2 it states "IP packets are transmitted over 802.11-OCB as 
> standard Ethernet packets. As with all 802.11 frames, an Ethernet  
> adaptation layer MUST be used with 802.11-OCB as well." Again EAL is  
> stipulated as a requirement. And I'm not sure about the stipulation  
> that packets are transmitted as "standard Ethernet packets", is this  
> accurate?

YEs.

I verify it this way:

Use available Wireshark tool on WiFi interface, enable IPv6 on the computer, and dump some IPv6 packets.  They all have EthernetII headers, rather than LLC and 802.11 headers.  Then capture the same in 'monitor'
mode, or 'mon' interface in 802.11 OCB, and the .11/LLC headers will show instead.

> Does this mean that 802.3 headers are included?

The EthernetII headers (not 802.3 Ethernet, I believe different) are included in the processing during the execution of this EAL.  But these EthernetII headers are not sent on the 802.11 air.

> This is definitely not stipulated in 1609.3. Packets transmitted over 
> OCB by a WAVE device using 1609.3 are well formed IPv6 packets, but 
> not "Ethernet packets", i.e., no 802.3 headers are included. This 
> seems like an interoperability problem between ipwave and 1609 WAVE.

The packets put on the air on 802.11-OCB links with the IPv6-over-OCB draft do not include EthernetII headers.  SO I do not think there is an interop problem 1609 WAVE with IPv6-over-OCB draft.

> 
>> 2.       It is not clear that ipwave provides any functionality 
>> that 1609 WAVE does not already provide.
> 
> Well, 1609 WAVE does not specify the conversion between .11/LLC 
> headers and EthernetII headers, right?
> 
> [KS]: Correct it does not, as this topic is out of scope for 1609 WAVE 
> (e.g., we don't specify the other interfaces such as Ethernet that may 
> be present in the device). Also see my comments above regarding the 
> EAL.

It is in scope here.  Maybe 1609 document can refer to here.

> 1609 WAVE does not specify the MTU size for IPv6, right?
> 
> [KS]: No it does not. 802.11 (normative to 1609) specifies maximum 
> MSDU size as 2304 octets. For WSMP 1609.3 specifies a maximum MSDU 
> size of 2302 (allowing for the 2-octet LLC header), and a default 
> value of 1400. You are correct in that a MSDU size for IPv6 is not 
> specified explicitly, but I don't know if some other RFCs related to
>  IPv6 over 802.11 already do that? Regardless, stipulating a default  
> value of 1500 for MTU size does not violate anything in 1609.3.

Noted.

For explanation, the figure 1500 for MTU for IPv6-over-OCB comes from implementations inheriting from old Ethernet behaviour.  We dont want to break that.  Moreover, it is compatible with RFC8200 (IPv6) which requires the minimum MTU to be at least 1280bytes for all links supporting IPv6.

IPv6 people are aware that many links do support more than 1500bytes MTU.  I heard of 10000bytes for some core links.  Yet the IPv6-over-foo for these links do not require the MTU 10000bytes.


> 
> 1609 WAVE does not specify that IPv6 must be preceded by .11 QoSData  
> (not just .11 Data), and BACKGROUND, right?
> 
> [KS]: Certainly 1609 does not. 1609 only restricts IPv6 packets to the 
> SCH (they are not allowed on the CCH). 802.11 specifies defaults  for 
> all UP and AC parameters, indicates which frame types are allowed, 
> etc. But as far as I can tell the stipulation that IPv6 use  QoSData 
> and AC_BK is new and something that ipwave introduces?

It seems so.  People agree with it.

> Again, I'm not an expert on this topic and I believe others in the
> 1609 WG have been discussing this with the ipwave list. Regardless, 
> this additional restriction does not violate 1609.3.
> 
> 1609 WAVE does not recommend in particular RFC8064 to form 
> semantically opaque Interface Identifiers, right?
> 
> [KS]: 1609 does not recommend anything like this, but on the other 
> hand 1609 does not prohibit it either. 1609 does not generally 
> speaking "recommend", rather it "specifies" and leaves all else up to 
> the system designer/implementer/deployer. And as mentioned previously, 
> 1609 allows any and all IETF protocols to be implemented.
> Regardless, this recommendation does not violate anything in 1609.3.

Noted.

> 
> (and a few others).
> 
>> 1609 WAVE includes a number of mechanisms that enable IPv6 networks 
>> to be configured. In addition to the WSA/WRA mechanism, 1609.3 allows 
>> any IETF protocols to be implemented, e.g., IETF RFC 4861, Neighbor 
>> Discovery for IP Version 6 (IPv6) (which is listed as a normative 
>> reference in 1609.3). Helpful would be some example use-cases that 
>> illustrate problems to be solved, and how ipwave will solve those 
>> problems (i.e., that 1609 WAVE does not already solve).
> 
> There is a draft that describes some use-cases of IPv6 in vehicular
> networks: draft-ietf-ipwave-vehicular-networking-02
> 
> [KS]: Thanks for pointing me to that, lots of info there! I'll spend  
> some time reviewing that when I can.
> 
> I think some parts of 1609 WAVE, in particular WRA, are not used in 
> Europe. Whereas this IPv6-over-OCB draft is used the same wherever 
> Internet is present (Europe, America, Continents).
> 
> [KS]: 1609 went to great lengths to harmonize WSM and WSA frame 
> formats with ISO/ETSI standards, these harmonized frames are included 
> in all of the -2016 revisions to 1609. So for example the 1609.3 WSA 
> is interoperable with the service advertisement used in Europe. See 
> ISO 16460, and see also ETSI TS 102 890-1.

I agree harmonization is good and needed.

In case that harmonization relies on IPv6 as specified at IETF, these are my comments to the ETSI document.

Quickly skimming, it calls it "IPv6 routing advertisement".  It is "IPv6 Router Advertisement".

The 'default' route is used when no other route is available.  The 'default' route typically gives access to the Internet, not to one particular server ("ITS-S": station).  For particular servers, one may use RFC4191 instead, for "more specific routes" or, the routes known as 'host-based routes'.

Thank you for the comments.

Alex



>> My concern is that the IETF ipwave document may cause significant 
>> confusion among deployers, and possibly lead to a lack of 
>> interoperability. Thank you for the opportunity to comment, I look 
>> forward to the discussion.
> 
> I would like to help with clarification. Let us discuss this.
> 
> [KS]: Sounds good!
> 
> Alex
> 
>> 
>> 
>> 
>> Best regards,
>> 
>> Kevin
> 
> _______________________________________________ its mailing list 
> [e-mail] https://www.ietf.org/mailman/listinfo/its
> 
>