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

["Kevin Smith" <[e-mail]>]

Hello All,

Thank you Dick for the clarification regarding Ethernet II: It has been
incorporated into IEEE 802.3. I suspected it but didn't have the time to dig
into it. I believe it is accurate to say that if we write "Ethernet frame"
then we are talking about a frame specified by IEEE 802.3.

Regarding using QoS data frames - ipwave does not intend to state that it is
a requirement in 802.11. Clearly 802.11 lists several options for frame
types when operating OCB. However ipwave (if for example it were a profile
of 1609.3) is requiring that QoS data frames be used.

The text, that I wrote, on review, is ambiguous.  However Alex has restated
it as "IP packets MUST be transmitted over 802.11-OCB media as QoS Data
frames whose format is specified in IEEE Std 802.11."  

Best,
Kevin

-----Original Message-----
From: Dick Roy [mailto:[e-mail]] 
Sent: Sunday, March 18, 2018 3:22 AM
To: 'Kevin Smith' <[e-mail]>; 'Tijink Jasja'
<[e-mail]>; 'Alexandre Petrescu'
<[e-mail]>
Cc: [e-mail]
Subject: RE: [ipwave] FW: ipwave - comments and concerns - 1609 WAVE, EPD -
towards resolution

The confusion starts with the undefined term "Ethernet Adaptation Layer
(EAL)" and the misguided attempts to use that term in the document.

There in NO adaptation layer in 1609.3/802.11-OCB.  At the MAC sublayer,
type encoding is used in the 5.9GHz band, that's it.  BTW - at the MAC
sublayer, PDUs are called frames.  So IPv6 packets (NPDUs) are MSDUs. There
is no adaptation necessary.  

As for QoS data frames, once again that is NOT a requirement in 802.11 (or
1609.3) so don't say that!

Ethernet II is part of 802.3, and today the only used part.  Length encoding
(and SNAP) at the LLC sublayer are appendages that are rapidly dying away
now.  The most important fact is that they are NOT used in IPv6 / 802.11-OCB
in 5.9GHz. 

RR

-----Original Message-----
From: its [mailto:[e-mail]] On Behalf Of Kevin Smith
Sent: Saturday, March 17, 2018 8:57 PM
To: 'Tijink Jasja'; 'Alexandre Petrescu'
Cc: [e-mail]
Subject: Re: [ipwave] FW: ipwave - comments and concerns - 1609 WAVE, EPD -
towards resolution

Addendum: Looking at RFC 2464, I see in clause 3. Frame Format the statement
"IPv6 packets are transmitted in standard Ethernet frames." 

Which of course exactly matches the text I'm questioning in ipwave. So I see
where it comes from. But considering that RFC 2464 was last updated almost
20 years ago, perhaps the statement is no longer the best way to describe
how IPv6 packets are encapsulated at L2?

Anyway, I'm really out of my element here, just doing research. My input is
based on my own experiences and interpretations, having been involved in
1609 stack development and developing products using 1609 WAVE since 2005.
So when I read ipwave, I was (and still am on some issues) confused. So
hopefully all of this discussion will result in an ipwave document that
clarifies some areas and is less confusing to many of us in the 1609 WAVE
community.

I appreciate the discussion.

Regards,
Kevin
P.S. Please do see my comments immediately below ...

-----Original Message-----
From: its [mailto:[e-mail]] On Behalf Of Kevin Smith
Sent: Saturday, March 17, 2018 12:26 PM
To: 'Tijink Jasja' <[e-mail]>; 'Alexandre Petrescu'
<[e-mail]>
Cc: [e-mail]
Subject: Re: [ipwave] FW: ipwave - comments and concerns - 1609 WAVE, EPD -
towards resolution

Hi Alex,

I have the same concern as does Jasja regarding the statement found in the
draft: "IP packets are transmitted over 802.11-OCB as standard Ethernet
packets."

I believe that statement is technically incorrect, or at best very
confusing. The term "Ethernet" is widely used to refer to wired networks
specified by IEEE 802.3. Ethernet II (or Ethernet Version 2) is one type of
Ethernet frame format, and the one most widely used in IP networks. There
are others. I'm unsure exactly where Ethernet II is specified, originally is
was specified in "Digital Equipment Corporation, Intel, Xerox, The Ethernet,
Version 2.0, November 1982.", but it must have been incorporated into 802.3
or perhaps some IETF RFCs?

I'd propose the text be revised to something more specific like this: "IPv6
packets are transmitted over 802.11-OCB as QoS Data frames as specified in
IEEE Std 802.11." 

Note also I changed "IP" to "IPv6". 

Regards,
Kevin

-----Original Message-----
From: Tijink Jasja [mailto:[e-mail]]
Sent: Saturday, March 17, 2018 5:37 AM
To: Alexandre Petrescu <[e-mail]>; Kevin Smith
<[e-mail]>
Cc: [e-mail]
Subject: AW: FW: [ipwave] ipwave - comments and concerns - 1609 WAVE, EPD -
towards resolution

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

_______________________________________________
its mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/its

_______________________________________________
its mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/its