Subject: [ipwave] QoSData, EPD, 1609 WAVE, EtherType - common text towards resolution

From: Alexandre PETRESCU <[email-masked]>
Date: Fri, 16 Mar 2018 14:43:43 +0100

Hi IPWAVErs,

I propose the following text to resolve commonly the QoSData and 1609 
WAVE EPD recent issues.

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

Remove this phrase:
> Other alternative views of layering are EtherType Protocol 
> Discrimination (EPD), see Appendix E, and SNAP see [RFC1042].

Yours,

Alex

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Fri, 16 Mar 2018 17:26:14 +0100

Hi Alex,

Thanks for driving this.

People, please do express if you agree or not with Alex's proposal. It
is important to get as much feedback as possible by the time of the
IPWAVE F2F session in London, so we can close this for one and for all.

Thanks,

Carlos

On Fri, 2018-03-16 at 14:43 +0100, Alexandre PETRESCU wrote:
> _______________________________________________
> its mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/its

---

From: Nabil Benamar <[email-masked]>
Date: Fri, 16 Mar 2018 16:48:43 +0000

Hi Carlos,

As a co-author of the draft, I have no objection to the changes suggested
by Alex.

Best regards
Nabil Benamar
-------------------
نبيل بنعمرو

---

From: François Simon <[email-masked]>
Date: Mon, 19 Mar 2018 15:07:10 -0400

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 am not sure why the access category MUST be set to AC_BK. Does all IPv6 exchanges will be of the lowest priority?  This does not give much flexibility for various applications.  AC_BK is mostly used for bulk data transfer or printer job.  Perhaps set as a default would be more appropriate.

Fygs

-----Original Message-----
From: Carlos Jesús Bernardos Cano <[email-masked]> 
Sent: Friday, March 16, 2018 12:26 PM
To: Alexandre PETRESCU <[email-masked]>; [email-masked]
Cc: Sandra Céspedes U. <[email-masked]>; Kevin Smith <[email-masked]>; John Kenney <[email-masked]>; Tijink Jasja <[email-masked]>; Tony Li <[email-masked]>; François Simon <[email-masked]>; Dick Roy <[email-masked]>
Subject: Re: [ipwave] QoSData, EPD, 1609 WAVE, EtherType - common text towards resolution

Hi Alex,

Thanks for driving this.

People, please do express if you agree or not with Alex's proposal. It is important to get as much feedback as possible by the time of the IPWAVE F2F session in London, so we can close this for one and for all.

Thanks,

Carlos

On Fri, 2018-03-16 at 14:43 +0100, Alexandre PETRESCU wrote:
> > 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 
> > In the Ethernet II header, the value of the Type field MUST be set 
> > to 0x86DD (IPv6).
> 
> Remove this phrase:
> [email-masked] <mailto:[email-masked]>

---

From: Tony Li <[email-masked]>
Date: Mon, 19 Mar 2018 21:07:08 +0000

> I am not sure why the access category MUST be set to AC_BK. Does all IPv6 exchanges will be of the lowest priority?  This does not give much flexibility for various applications.  AC_BK is mostly u…

As noted previously and in the meeting, there is no security of the IPv6 traffic class and very few networks make an effort to police it meaning that it is largely unused.

If we attempt to make use of it without some means of ensuring its validity, we then encourage hackers to attack their protocol stacks to get better service at the expense of others.

Tony