Subject: [ipwave] Fwd: New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-05.txt

From: Alexandre Petrescu <[email-masked]>
Date: Sun, 10 Sep 2017 15:58:22 +0200

Dear participants to IPWAVE WG,

This is the new IPv6-over-802.11-OCB addressing all the Reviewers comments.

This is the ChangeLog:

o Lengthened the title and cleanded the abstract.
o Added text suggesting LLs may be easy to use on OCB, rather than
GUAs based on received prefix.
o Added the risks of spoofing and hijacking.
o Removed the text speculation on adoption of the TSA message.
o Clarified that the ND protocol is used.
o Clarified what it means "No association needed".
o Added some text about how two STAs discover each other.
o Added mention of external (OCB) and internal network (stable), in
the subnet structure section.
o Added phrase explaining that both .11 Data and .11 QoS Data
headers are currently being used, and may be used in the future.
o Moved the packet capture example into an Appendix Implementation
Status.
o Suggested moving the reliability requirements appendix out into
another document.
o Added a IANA Consiserations section, with content, requesting for
a new multicast group "all OCB interfaces".
o Added new OBU term, improved the RSU term definition, removed the
ETTC term, replaced more occurences of 802.11p, 802.11 OCB with
802.11-OCB.
o References:
* Added an informational reference to ETSI’s IPv6-over-
GeoNetworking.
* Added more references to IETF and ETSI security protocols.
* Updated some references from I-D to RFC, and from old RFC to
new RFC numbers.
* Added reference to multicast extensions to IPsec architecture
RFC.
* Added a reference to 2464-bis.
* Removed FCC informative references, because not used.
o Updated the affiliation of one author.
o Reformulation of some phrases for better readability, and
correction of typographical errors.

Alex

-------- Message transféré --------
Sujet : 	New Version Notification for 
draft-ietf-ipwave-ipv6-over-80211ocb-05.txt
Date : 	Sun, 10 Sep 2017 06:55:20 -0700
De : 	[email-masked]
Pour : 	Nabil Benamar <[email-masked]>, Christian Huitema 
<[email-masked]>, Jong-Hyouk Lee <[email-masked]>, Jérôme 
Härri <[email-masked]>, Alexandre Petrescu 
<[email-masked]>, Tony Li <[email-masked]>, Alexandre 
Petrescu <[email-masked]>, Jerome Haerri 
<[email-masked]>, Thierry Ernst <[email-masked]>, 
[email-masked]

A new version of I-D, draft-ietf-ipwave-ipv6-over-80211ocb-05.txt
has been successfully submitted by Alexandre Petrescu and posted to the
IETF repository.

Name:		draft-ietf-ipwave-ipv6-over-80211ocb
Revision:	05
Title:		Transmission of IPv6 Packets over IEEE 802.11 Networks operating in mode Outside the Context of a Basic Service Set (IPv6-over-80211-OCB)
Document date:	2017-09-10
Group:		ipwave
Pages:		37
URL:            https://www.ietf.org/internet-drafts/draft-ietf-ipwave-ipv6-over-80211ocb-05.txt
Status:         https://datatracker.ietf.org/doc/draft-ietf-ipwave-ipv6-over-80211ocb/
Htmlized:       https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-05
Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv6-over-80211ocb-05
Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-ipwave-ipv6-over-80211ocb-05

Abstract:
    In order to transmit IPv6 packets on IEEE 802.11 networks run outside
    the context of a basic service set (OCB, earlier "802.11p") there is
    a need to define a few parameters such as the supported Maximum
    Transmission Unit size on the 802.11-OCB link, the header format
    preceding the IPv6 header, the Type value within it, and others.
    This document describes these parameters for IPv6 and IEEE 802.11-OCB
    networks; it portrays the layering of IPv6 on 802.11-OCB similarly to
    other known 802.11 and Ethernet layers - by using an Ethernet
    Adaptation Layer.

    In addition, the document lists what is different in 802.11-OCB
    (802.11p) links compared to more 'traditional' 802.11a/b/g/n links,
    where IPv6 protocols operate without issues.  Most notably, the
    operation outside the context of a BSS (OCB) has impact on IPv6
    handover behaviour and on IPv6 security.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: François Simon <[email-masked]>
Date: Thu, 14 Sep 2017 05:44:03 -0400

Mr. Petrescu,

Find attached comments on version 06 of the document.

Let me know if you have any questions.

Francois Yves Simon

Lojik Technologies

From: its [mailto:[email-masked]] On Behalf Of Alexandre Petrescu
Sent: Sunday, September 10, 2017 9:58 AM
To: [email-masked]
Subject: [ipwave] Fwd: New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-05.txt

This is the ChangeLog:

Alex

-------- Message transféré -------- 

Sujet : 

New Version Notification for draft-ietf-ipwave-ipv6-over-80211ocb-05.txt

Date : 

Sun, 10 Sep 2017 06:55:20 -0700

De : 

[email-masked] <mailto:[email-masked]> 

Pour : 

Nabil Benamar  <mailto:[email-masked]> <[email-masked]>, Christian Huitema  <mailto:[email-masked]> <[email-masked]>, Jong-Hyouk Lee  <mailto:[email-masked]> <[email-masked]>, Jérôme Härri  <mailto:[email-masked]> <[email-masked]>, Alexandre Petrescu  <mailto:[email-masked]> <[email-masked]>, Tony Li  <mailto:[email-masked]> <[email-masked]>, Alexandre Petrescu  <mailto:[email-masked]> <[email-masked]>, Jerome Haerri  <mailto:[email-masked]> <[email-masked]>, Thierry Ernst  <mailto:[email-masked]> <[email-masked]>, [email-masked] <mailto:[email-masked]> 

 
Abstract:

 

The IETF Secretariat

---

From: Alexandre Petrescu <[email-masked]>
Date: Sun, 17 Sep 2017 20:29:18 +0200

Mr. Simon,

We received your comments and tried to resolve them.

1. This is the changelog that solves simple things.  I invite you to
    look how they are solved in the new version, -07.
    o  Added new terms: OBRU and RSRU ('R' for Router).  Refined the
       existing terms RSU and OBU, which are no longer used throughout
       the document.
    o  Improved definition of term "802.11-OCB".
    o  Clarified that OCB does not "strip" security, but that the
       operation in OCB mode is "stripped off of all .11 security".
    o  Clarified that theoretical OCB bandwidth speed is 54mbits, but
       that a commonly observed bandwidth in IP-over-OCB is 12mbit/s.
    o  Corrected typographical errors, and improved some phrasing.

2. I would like to ask you three questions:

Do you know whether there is an EtherType allocated by IEEE for WAVE
messages?  I noticed in packets BSM-over-802.11-OCB that the used type
is 0x88DC.  Packet available upon request.  This value is in LLC Header,
Type Field.  It is understood by the Wireshark tool.  But I dont see it
listed at IANA, IEEE 802 Numbers:
https://www.iana.org/assignments/ieee-802-numbers/ieee-802-numbers.xhtml
But on that page I do see 0x8947 for GeoNetworking and 0x86DD for IPv6.

Do you think this existing text is wrong?:
> At the time of writing, the prohibition [of IPv6] is explicit at
> higher layer protocols providing services to the application; these
> higher layer protocols are specified in IEEE 1609 documents, i.e.
> the "WAVE" stack.

Finally, in your review, when you read the -06 text saying "Some
channels are reserved for safety communications; the IPv6 packets should
not be sent on these channels." you are commenting in your review that
"This assumes that Safety applications would not use IPv6; erroneous
assumption."  My question is the following: do you want text deleted?
Which one?  Or is it just a comment?  Know that some WG members already
suggested that "IPv6 packets should be sent on the channels reserved for
safety".

Alex

Le 14/09/2017 à 11:44, François Simon a écrit :
> *From:*its [mailto:[email-masked]] *On Behalf Of *Alexandre
> Petrescu *Sent:* Sunday, September 10, 2017 9:58 AM *To:*
> [email-masked] *Subject:* [ipwave] Fwd: New Version Notification for 
> o Lengthened the title and cleanded the abstract. o Added text
> suggesting LLs may be easy to use on OCB, rather than GUAs based on
> received prefix. o Added the risks of spoofing and hijacking. o
> Removed the text speculation on adoption of the TSA message. o
> Clarified that the ND protocol is used. o Clarified what it means "No
> association needed". o Added some text about how two STAs discover
> each other. o Added mention of external (OCB) and internal network
> (stable), in the subnet structure section. o Added phrase explaining
> that both .11 Data and .11 QoS Data headers are currently being used,
> and may be used in the future. o Moved the packet capture example
> into an Appendix Implementation Status. o Suggested moving the
> reliability requirements appendix out into another document. o Added
> a IANA Consiserations section, with content, requesting for a new
> multicast group "all OCB interfaces". o Added new OBU term, improved
> the RSU term definition, removed the ETTC term, replaced more
> occurences of 802.11p, 802.11 OCB with 802.11-OCB. o References: *
> Added an informational reference to ETSI’s IPv6-over- GeoNetworking. 
> * Added more references to IETF and ETSI security protocols. *
> Updated some references from I-D to RFC, and from old RFC to new RFC
> numbers. * Added reference to multicast extensions to IPsec
> architecture RFC. * Added a reference to 2464-bis. * Removed FCC
> informative references, because not used. o Updated the affiliation
> of one author. o Reformulation of some phrases for better
> readability, and correction of typographical errors.
> 
> Alex
> 
> *Sujet : *
> New Version Notification for
> *Date : *
> *De : *
> *Pour : *
> Nabil Benamar <[email-masked]> <mailto:[email-masked]>, 
> Christian Huitema <[email-masked]> <mailto:[email-masked]>,
>  Jong-Hyouk Lee <[email-masked]> <mailto:[email-masked]>, 
> Jérôme Härri <[email-masked]> 
> <mailto:[email-masked]>, Alexandre Petrescu 
> <[email-masked]> <mailto:[email-masked]>, Tony
> Li <[email-masked]> <mailto:[email-masked]>, Alexandre Petrescu 
> <[email-masked]> <mailto:[email-masked]>,
> Jerome Haerri <[email-masked]>
> <mailto:[email-masked]>, Thierry Ernst
> <[email-masked]> <mailto:[email-masked]>,
> [email-masked] <mailto:[email-masked]>
> 
> Title:         Transmission of IPv6 Packets over IEEE 802.11 Networks
> operating in mode Outside the Context of a Basic Service Set
> (IPv6-over-80211-OCB)
> 
> URL:https://www.ietf.org/internet-drafts/draft-ietf-ipwave-ipv6-over-80211ocb-05.txt
>
>  
> Status:https://datatracker.ietf.org/doc/draft-ietf-ipwave-ipv6-over-80211ocb/
>
>  
> Htmlized:https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-05
>
>  
> Htmlized:https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv6-over-80211ocb-05
>
>  
> Diff:https://www.ietf.org/rfcdiff?url2=draft-ietf-ipwave-ipv6-over-80211ocb-05
>
>  Abstract:
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Sun, 17 Sep 2017 21:33:01 +0200

Le 17/09/2017 à 20:29, Alexandre Petrescu a écrit :
[...]
> suggested that "IPv6 packets should be sent on the channels reserved for

I meant "_not_ be sent on the channels reserved for safety", obviously.

Alex

>> Added an informational reference to ETSI’s IPv6-over- GeoNetworking. * 
>> Added more references to IETF and ETSI security protocols. *
> _______________________________________________
> its mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/its

---

From: William Whyte <[email-masked]>
Date: Mon, 18 Sep 2017 06:41:44 -0400

Hi Alex,

> Do you know whether there is an EtherType allocated by IEEE for WAVE messages?

The IANA listing isn't the definitive listing of ethertype values. The
definitive listing is at http://standards-oui.ieee.org/ethertype/eth.txt,
which assigns 88dc to "Wireless Access in a Vehicle Environment (WAVE)
Short Message Protocol (WSM) as defined in IEEE P1609.3."

BTW, note that "WAVE messages" isn't the best terminology to use -- this is
an identifier for WAVE *Short* Messages, or WSMs. "WAVE messages" is a term
with no defined meaning.

Cheers,

William

On Sun, Sep 17, 2017 at 3:33 PM, Alexandre Petrescu <
[email-masked]> wrote:

>>> Jérôme Härri <[email-masked]> <mailto:[email-masked]>,
>>> Alexandre Petrescu <[email-masked]> <mailto:
>>> [email-masked]>, Tony
>>> Li <[email-masked]> <mailto:[email-masked]>, Alexandre Petrescu <
>>> [email-masked]> <mailto:[email-masked]>,

-- 

PLEASE UPDATE YOUR ADDRESS BOOKS WITH MY NEW ADDRESS:
[email-masked]

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 18 Sep 2017 12:50:28 +0200

Hi William,

Le 18/09/2017 à 12:41, William Whyte a écrit :
> messages?
> The IANA listing isn't the definitive listing of ethertype values.

I agree, the IANA listing is just echoing the IEEE listing with respect 
to EtherTypes.   But it is very useful.

> The definitive listing is at 
> http://standards-oui.ieee.org/ethertype/eth.txt, which assigns 88dc
> to "Wireless Access in a Vehicle Environment (WAVE) Short Message
> Protocol (WSM) as defined in IEEE P1609.3."
> 
> BTW, note that "WAVE messages" isn't the best terminology to use --
> this is an identifier for WAVE *Short* Messages, or WSMs. "WAVE
> messages" is a term with no defined meaning.

I agree.  To clarify myself, Wireshark calls 0x88DC "(WAVE) Short 
Message Protocol (WSM)".  Maybe this is more in-line with what is expected.

Alex

> 
> Cheers,
> 
> William
> 
> On Sun, Sep 17, 2017 at 3:33 PM, Alexandre Petrescu 
> <[email-masked] <mailto:[email-masked]>>
> wrote:
> 
> 
> 
> Le 17/09/2017 à 20:29, Alexandre Petrescu a écrit : [...]
> 
> channels are reserved for safety communications; the IPv6 packets
> should not be sent on these channels." you are commenting in your 
> review that "This assumes that Safety applications would not use
> IPv6; erroneous assumption."  My question is the following: do you
> want text deleted? Which one?  Or is it just a comment?  Know that
> some WG members already suggested that "IPv6 packets should be sent
> on the channels reserved for safety".
> 
> 
> *From:*its [mailto:[email-masked] 
> <mailto:[email-masked]>] *On Behalf Of *Alexandre Petrescu
> *Sent:* Sunday, September 10, 2017 9:58 AM *To:* [email-masked]
> <mailto:[email-masked]> *Subject:* [ipwave] Fwd: New Version
> Notification for draft-ietf-ipwave-ipv6-over-80211ocb-05.txt
> 
> Clarified that the ND protocol is used. o Clarified what it means
> "No association needed". o Added some text about how two STAs 
> discover each other. o Added mention of external (OCB) and internal 
> network (stable), in the subnet structure section. o Added phrase 
> explaining that both .11 Data and .11 QoS Data headers are currently 
> being used, and may be used in the future. o Moved the packet
> capture example into an Appendix Implementation Status. o Suggested
> moving the reliability requirements appendix out into another
> document. o Added a IANA Consiserations section, with content,
> requesting for a new multicast group "all OCB interfaces". o Added
> new OBU term, improved the RSU term definition, removed the ETTC
> term, replaced more occurences of 802.11p, 802.11 OCB with
> 802.11-OCB. o References: * Added an informational reference to
> ETSI’s IPv6-over- GeoNetworking. * Added more references to IETF and
> ETSI security protocols. * Updated some references from I-D to RFC,
> and from old RFC to new RFC numbers. * Added reference to multicast
> extensions to IPsec architecture RFC. * Added a reference to
> 2464-bis. * Removed FCC informative references, because not used. o
> Updated the affiliation of one author. o Reformulation of some
> phrases for better readability, and correction of typographical
> errors.
> 
> Alex
> 
> <mailto:[email-masked] <mailto:[email-masked]>>
> 
> *Pour : *
> 
> 
> 
> Nabil Benamar <[email-masked] <mailto:[email-masked]>>
> <mailto:[email-masked] <mailto:[email-masked]>>, Christian
> Huitema <[email-masked] <mailto:[email-masked]>> 
> <mailto:[email-masked] <mailto:[email-masked]>>, Jong-Hyouk
> Lee <[email-masked] <mailto:[email-masked]>>
> <mailto:[email-masked] <mailto:[email-masked]>>, Jérôme
> Härri <[email-masked] <mailto:[email-masked]>> 
> <mailto:[email-masked] <mailto:[email-masked]>>,
> Alexandre Petrescu <[email-masked] 
> <mailto:[email-masked]>> 
> <mailto:[email-masked] 
> <mailto:[email-masked]>>, Tony Li <[email-masked]
> <mailto:[email-masked]>> <mailto:[email-masked]
> <mailto:[email-masked]>>, Alexandre Petrescu
> <[email-masked] <mailto:[email-masked]>> 
> <mailto:[email-masked] 
> <mailto:[email-masked]>>, Jerome Haerri
> <[email-masked] <mailto:[email-masked]>> 
> <mailto:[email-masked] <mailto:[email-masked]>>,
> Thierry Ernst <[email-masked]
> <mailto:[email-masked]>> <mailto:[email-masked] 
> <mailto:[email-masked]>>, [email-masked]
> <mailto:[email-masked]> <mailto:[email-masked]
> <mailto:[email-masked]>>
> 
> Title:         Transmission of IPv6 Packets over IEEE 802.11 
> Networks operating in mode Outside the Context of a Basic Service
> Set (IPv6-over-80211-OCB)
> 
<https://www.ietf.org/internet-drafts/draft-ietf-ipwave-ipv6-over-80211ocb-05.txt>
> Status:https://datatracker.ietf.org/doc/draft-ietf-ipwave-ipv6-over-80211ocb/
<https://datatracker.ietf.org/doc/draft-ietf-ipwave-ipv6-over-80211ocb/>
> Htmlized:https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-05
<https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-05>
> Htmlized:https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv6-over-80211ocb-05
<https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv6-over-80211ocb-05>
> Diff:https://www.ietf.org/rfcdiff?url2=draft-ietf-ipwave-ipv6-over-80211ocb-05
<https://www.ietf.org/rfcdiff?url2=draft-ietf-ipwave-ipv6-over-80211ocb-05>
> until the htmlized version and diff are available at tools.ietf.org
> <http://tools.ietf.org>.
> 
> The IETF Secretariat
> 
> 
> _______________________________________________ its mailing list 
> [email-masked] <mailto:[email-masked]> 
> <https://www.ietf.org/mailman/listinfo/its>
> 
> 
> _______________________________________________ its mailing list 
> [email-masked] <mailto:[email-masked]> 
> <https://www.ietf.org/mailman/listinfo/its>
> 
> 
> 
> 
> --
> 
> 
> [email-masked] <mailto:[email-masked]>

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 19 Sep 2017 13:42:35 +0200

Le 19/09/2017 à 00:19, Dick Roy a écrit :
> Alex et.al.,
> 
> To clarify, there is NO IANA listing for messages of any kind

But there is this listing there:
https://www.iana.org/assignments/ieee-802-numbers/ieee-802-numbers.xhtml

It does say 0x86DD for IPv6 and 0x8947 for GeoNetworking.  Do you think 
0x88DC does not fit there too? ("(WAVE) Short Message Protocol (WSM)")

If I want to build a unique box (not multiple boxes one per Region) I'd 
have to write the code such that it multiplexes based on that EtherType. 
  It might be that code is an IP code.  As such I'd look at IANA to see 
the EtherTypes.

Alex

, WSMs
> included.  The IANA listings to which you refer below are the ethertype
> listings.  Ethertypes identify protocols, not messages.  0x88DC is assigned
> to the WAVE Short Message Protocol which specifies how to construct a
> transport layer header and a network layer header for exchanging TSDUs
> between peer entities where there is NO network layer addressing at all!
> Note that in ISO, the equivalent protocol used to be called NNTP
> (Null-Network & Transport layer Protocol) for just that reason!
> 
> Cheers,
> 
> RR
> 
> -----Original Message-----
> Sent: Monday, September 18, 2017 3:50 AM
> To: William Whyte
> Cc: [email-masked]
> Subject: Re: [ipwave] -06 comments
> 
> Hi William,
> 
>> ETSI's IPv6-over- GeoNetworking. * Added more references to IETF and

---

From: William Whyte <[email-masked]>
Date: Tue, 19 Sep 2017 08:45:19 -0400

Dick's point is that messages are application-layer data objects; what an
ethertype identifies is a protocol.

Cheers,

William

On Tue, Sep 19, 2017 at 7:42 AM, Alexandre Petrescu <
[email-masked]> wrote:

> It might be that code is an IP code.  As such I'd look at IANA to see the
> EtherTypes.
>
> Alex
>
>
> , WSMs
>
>>> URL:https://www.ietf.org/internet-drafts/draft-ietf-ipwave-
>> ipv6-over-80211oc
>> b-05.txt
>>
>>>
>>>
>>> <https://www.ietf.org/internet-drafts/draft-ietf-ipwave-
>> ipv6-over-80211ocb-0
>> 5.txt>
>>
>>>
>>>
>>>
>>>
>>> Status:https://datatracker.ietf.org/doc/draft-ietf-ipwave-
>> ipv6-over-80211ocb
>> /
>>
>>>
>>>
>>> Htmlized:https://datatracker.ietf.org/doc/html/draft-ietf-ip
>> wave-ipv6-over-8
>> 0211ocb-05
>>
>>>
>>>
>>> <https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv
>> 6-over-80211ocb-
>> 05>
>>
>>>
>>>
>>>
>>>
>>> Diff:https://www.ietf.org/rfcdiff?url2=draft-ietf-ipwave-
>> ipv6-over-80211ocb-
>> 05
>>
>>>
>>>

--

---

From: François Simon <[email-masked]>
Date: Tue, 19 Sep 2017 10:22:45 -0400

Mr. Petrescu,

Here are the answers to your questions.

If you have additional questions, please, let me know.

Sincerely,

Francois Simon
Lojik Technologies

[Fygs: Only the US views are addressed here.]
We received your comments and tried to resolve them.

[Fygs: Most of the “trials” have used 10 Mhz channel spacing and 6 mbit/s]

Do you know whether there is an EtherType allocated by IEEE for WAVE messages?  I noticed in packets BSM-over-802.11-OCB that the used type is 0x88DC.  Packet available upon request.  This value is in LLC Header, Type Field.  It is understood by the Wireshark tool.  But I dont see it listed at IANA, IEEE 802 Numbers:
https://www.iana.org/assignments/ieee-802-numbers/ieee-802-numbers.xhtml
But on that page I do see 0x8947 for GeoNetworking and 0x86DD for IPv6.

[Fygs: Reference http://standards-oui.ieee.org/ethertype/eth.txt :

0x88DC is the Ether type for WAVE WSMP assigned to IEEE 1609 WG – out of scope for IPWAVE – IPv6 over OCB.

88dc  -  IEEE P1609 WG   3800 N Fairfax Drive #207, Arlington VA  22203-1759   -  Wireless Access in a Vehicle Environment (WAVE) Short Message Protocol (WSM) as defined in IEEE P1609.3.

0x86DD is the Ether type for IPv6 assigned to the Internet Society.

86DD - USC/ISI 4676 Admiralty Way, Marina del Rey  CA  90292 US - Crawford, M. - 
IPv6 - Internet Protocol Version 6 - Transmission of IPv6 Packets over Ethernet Networks, RFC-2464, Internet Society, Dec. 1998 -                                      
Packets over Ethernet Networks, RFC-2464, Internet Society, Dec.        
http://www.ietf.org/rfc/rfc2464.txt                                                                                                                                                 

0x8947 is the Ether type for GeoNetworking assigned to ETSI.

8947  -  ETSI 650 Route des lucioles, Sophia Antipolis 06921 FR  -                                                                                             
GeoNetworking as defined in ETSI EN 302 636-4-1.
Link to the protocol: http://webapp.etsi.org/workprogram/Frame_WorkItemList.asp?SearchPage=TRUE&qSORT=HIGHVERSION&qINCLUDE_SUB_TB=True&butSimple=++Search++&qETSI_STANDARD_TYPE=&qETSI_NUMBER=302+636-4-1&qETSI_ALL=TRUE&qMILESTONE=&qACHIEVED_DAY=&qACHIEVED_MONTH=&qACHIEVED_YEAR=&qREPORT_TYPE=SUMMARY&optDisplay=10&qTB_ID=&includeNonActiveTB=FALSE]              

> higher layer protocols are specified in IEEE 1609 documents, i.e.

[Fygs: See comments below.]

Finally, in your review, when you read the -06 text saying "Some channels are reserved for safety communications; the IPv6 packets should not be sent on these channels." you are commenting in your review that "This assumes that Safety applications would not use IPv6; erroneous assumption."  My question is the following: do you want text deleted?
Which one?  Or is it just a comment?  Know that some WG members already suggested that "IPv6 packets should be sent on the channels reserved for safety".

[Fygs: Text from “version 7”: 

“Prohibition of IPv6 on some channels relevant for IEEE 802.11-OCB, as opposed to IPv6 not being prohibited on any channel on which
802.11a/b/g/n runs:

      *  Some channels are reserved for safety communications; the IPv6
         packets should not be sent on these channels.

      *  At the time of writing, the prohibition is explicit at higher
         layer protocols providing services to the application; these
         higher layer protocols are specified in IEEE 1609 documents,
         i.e. the "WAVE" stack.

      *  National or regional specifications and regulations specify the
         use of different channels; these regulations must be followed.

 Any channels within the 5.9 GHz band can be used to exchange safety applications data, except for the 5 MHz in the lower part of the band which is “reserved”.  However, FCC identify channels 172 (33 dBm max. EIRP) and 184 (33/44 dBm max. EIRP) which are “designated for public safety applications involving safety of life and property.” The national regulations (FCC – 47 CFR) specify the channel use details but does not specify protocols.

Since IPWAVE IPv6 over OCB is exclusively related to “IPv6 – LLC” Service Access Point (SAP) (above the OCB MAC), there is no requirement to be compatible with the IEEE 1609 protocol stack.  Therefore, the prohibition is irrelevant and should not be stated. LLC, IEEE 802.11, and FCC have no protocol restriction on any of the channels of 5.9 GHz band].

It is recommended to delete this entire section (shown above) of the document.]

Alex

-----Original Message-----
From: Alexandre Petrescu [mailto:[email-masked]] 
Sent: Monday, September 18, 2017 8:01 AM
To: François Simon <[email-masked]>
Subject: Re: -06 comments

Mr. Simon,

I just corrected my meessage, publicly.

Please post publicly about this, and about the way we addressed all other comments from your review.

Alex

Le 18/09/2017 à 13:55, François Simon a écrit :
> Mr. Petrescu,
> 
> I will answer the questions.  Do you want the response CCed to the WG members?  If so re-send the e-mail with the following statement corrected: " Know that some WG members already suggested that "IPv6 packets should be sent on the channels reserved for safety"
> 
> Sincerely,
> 
> Fygs
> 
> From: Alexandre Petrescu [mailto:[email-masked]]
> Sent: Sunday, September 17, 2017 2:29 PM
> To: François Simon <[email-masked] <mailto:[email-masked]> >
> Cc: [email-masked] <mailto:[email-masked]> 
> Subject: Re: -06 comments
> 
> Mr. Simon,
> 
> Do you know whether there is an EtherType allocated by IEEE for WAVE messages?  I noticed in packets BSM-over-802.11-OCB that the used type is 0x88DC.  Packet available upon request.  This value is in LLC Header, Type Field.  It is understood by the Wireshark tool.  But I dont see it listed at IANA, IEEE 802 Numbers:
> https://www.iana.org/assignments/ieee-802-numbers/ieee-802-numbers.xht
> ml But on that page I do see 0x8947 for GeoNetworking and 0x86DD for 
> IPv6.
> 
> Finally, in your review, when you read the -06 text saying "Some channels are reserved for safety communications; the IPv6 packets should not be sent on these channels." you are commenting in your review that "This assumes that Safety applications would not use IPv6; erroneous assumption."  My question is the following: do you want text deleted?
> Which one?  Or is it just a comment?  Know that some WG members already suggested that "IPv6 packets should be sent on the channels reserved for safety".
> 
> Alex
> 
> 
> 
> 
>> *Subject:* [ipwave] Fwd: New Version Notification for 
>> Updated some references from I-D to RFC, and from old RFC to new RFC numbers.
>> * Added reference to multicast extensions to IPsec architecture RFC. 
>> * Added a reference to 2464-bis. * Removed FCC informative 
>> references, because not used. o Updated the affiliation of one 
>> author. o Reformulation of some phrases for better readability, and 
>> [email-masked] <mailto:[email-masked]>  <mailto:[email-masked]>
>>
>> *Pour : *
>>
>>
>>
>> Nabil Benamar <[email-masked] <mailto:[email-masked]> > <mailto:[email-masked]>, 
>> Christian Huitema <[email-masked] <mailto:[email-masked]> > <mailto:[email-masked]>, 
>> Jong-Hyouk Lee <[email-masked] <mailto:[email-masked]> > <mailto:[email-masked]>, 
>> Jérôme Härri <[email-masked] <mailto:[email-masked]> > 
>> <[email-masked] <mailto:[email-masked]> > <mailto:[email-masked]>, Tony 
>> Li <[email-masked] <mailto:[email-masked]> > <mailto:[email-masked]>, Alexandre Petrescu 
>> <[email-masked] <mailto:[email-masked]> > <mailto:[email-masked]>,
>> Jerome Haerri <[email-masked] <mailto:[email-masked]> > 
>> <[email-masked] <mailto:[email-masked]> > <mailto:[email-masked]>, 
>> [email-masked] <mailto:[email-masked]>  <mailto:[email-masked]>
>>
>> URL:https://www.ietf.org/internet-drafts/draft-ietf-ipwave-ipv6-over-
>> 8
>> 0211ocb-05.txt
>>
>>   
>> Status:https://datatracker.ietf.org/doc/draft-ietf-ipwave-ipv6-over-8
>> 0
>> 211ocb/
>>
>>   
>> Htmlized:https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-8021
>> 1
>> ocb-05
>>
>>   
>> Htmlized:https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv6
>> -
>> over-80211ocb-05
>>
>>   
>> Diff:https://www.ietf.org/rfcdiff?url2=draft-ietf-ipwave-ipv6-over-80
>> 2
>> 11ocb-05
>>
>>   Abstract:
>>

---

From: Jérôme Härri <[email-masked]>
Date: Tue, 19 Sep 2017 17:05:41 +0200

Dear Mr. Simon,

As far as I know, IEEE 802.11-2016 OCB is 10Mhz only. The 6Mbps is a profile that is applied by WAVE and ETSI ITS but is out of scope of IETF..we basically do not need to respect it (actually we should not, as the tests showing the superior channel usage of 6Mps has been obtained for fixed size BSM/CAM at constant Transmit Power and in Full Broadcast mode)…

The only thing we can write there is that IEEE 802.11-2016 OCB has a maximum capacity (theoretical bandwidth) of 27Mbps due to the 10Mhz constraints…finding the optimal modulation for IPv6 traffic should be left open. 

For the Ethertype for OCB, it is important to differentiate what we mean by IEEE. 

·         IEEE 802.11 does not do it, and I would not understand why they would need it, as OCB is clearly identified at LL by a wildcard BSSID as well as ToDS and fromDS fields to set to 0. 

·         IEEE 1609.x indeed proposed an Ethertype (used over the last decade if I am not mistaken) for the WAVE stack (not BSM)..BSM use such ethertype as they are not transmitted over IPv6 (or IPv4), but only because they use a WAVE headers (and the WAVE non-IP stack). Would BSM be sent over IPv6, they would most likely not use this ethertype. 

o   In EU, the ETSI followed a similar strategy for the GeoNet stack (the Geonet headers)…CAM use the GeoNet Ethertype but would most likely not use it if CAM would be sent over plain IPv6. 

Now the question is: Why would we need a new Ethertype if we do plain IPv6-over-OCB…Why would we need to differentiate at L3 OCB from BSS/IBSS WiFi ? IPv6 header and packets are the same, only the access technology changes, which is out of scope of IETF. Could we use an IPv6 Profile to provide some traffic differentiation? 

I understand there might be requirements at L3 to know that some of the ‘assumed’ security mechanisms at 802.11 level be absent (or that IPv6 ND would need to operate differently…), and therefore to adopt an alternative strategy…I am just wondering if an Ethertype is the right tool for this….Maybe some use cases could we worth drawing and discussing. 

Best Regards,

Jérôme 

From: its [mailto:[email-masked]] On Behalf Of François Simon
Sent: Tuesday 19 September 2017 16:23
To: 'Alexandre Petrescu'
Cc: [email-masked]; [email-masked]
Subject: Re: [ipwave] -06 comments

Mr. Petrescu,

Sincerely,

Francois Simon

Lojik Technologies

       the document.

Link to the protocol: http://webapp.etsi.org/workprogram/Frame_WorkItemList.asp?SearchPage=TRUE <http://webapp.etsi.org/workprogram/Frame_WorkItemList.asp?SearchPage=TRUE&qSORT=HIGHVERSION&qINCLUDE_SUB_TB=True&butSimple=++Search++&qETSI_STANDARD_TYPE=&qETSI_NUMBER=302+636-4-1&qETSI_ALL=TRUE&qMILESTONE=&qACHIEVED_DAY=&qACHIEVED_MONTH=&qACHIEVED_YEAR=&qREPORT_TYPE=SUMMARY&optDisplay=10&qTB_ID=&includeNonActiveTB=FALSE> &qSORT=HIGHVERSION&qINCLUDE_SUB_TB=True&butSimple=++Search++&qETSI_STANDARD_TYPE=&qETSI_NUMBER=302+636-4-1&qETSI_ALL=TRUE&qMILESTONE=&qACHIEVED_DAY=&qACHIEVED_MONTH=&qACHIEVED_YEAR=&qREPORT_TYPE=SUMMARY&optDisplay=10&qTB_ID=&includeNonActiveTB=FALSE]              

802.11a/b/g/n runs:

         i.e. the "WAVE" stack.

Alex

-----Original Message-----
From: Alexandre Petrescu [mailto:[email-masked]]
Sent: Monday, September 18, 2017 8:01 AM
To: François Simon <[email-masked]>
Subject: Re: -06 comments

Mr. Simon,

Alex

> From: Alexandre Petrescu [ <mailto:[email-masked]> mailto:[email-masked]]

> To: François Simon < <mailto:[email-masked]> [email-masked]>

> Cc:  <mailto:[email-masked]> [email-masked]

>  <https://www.iana.org/assignments/ieee-802-numbers/ieee-802-numbers.xht> https://www.iana.org/assignments/ieee-802-numbers/ieee-802-numbers.xht

>> *From:*its [ <mailto:[email-masked]> mailto:[email-masked]] *On Behalf Of *Alexandre 

>>  <mailto:[email-masked]> [email-masked]

>> This is the new IPv6-over-802.11-OCB addressing all the Reviewers 

>> comments.

>>  <mailto:[email-masked]> [email-masked] < <mailto:[email-masked]> mailto:[email-masked]>

>> Nabil Benamar < <mailto:[email-masked]> [email-masked]> < <mailto:[email-masked]> mailto:[email-masked]>, 

>> Christian Huitema < <mailto:[email-masked]> [email-masked]> < <mailto:[email-masked]> mailto:[email-masked]>, 

>> Jong-Hyouk Lee < <mailto:[email-masked]> [email-masked]> < <mailto:[email-masked]> mailto:[email-masked]>, 

>> Jérôme Härri < <mailto:[email-masked]> [email-masked]> 

>> < <mailto:[email-masked]> mailto:[email-masked]>, Alexandre Petrescu 

>> < <mailto:[email-masked]> [email-masked]> < <mailto:[email-masked]> mailto:[email-masked]>, Tony 

>> Li < <mailto:[email-masked]> [email-masked]> < <mailto:[email-masked]> mailto:[email-masked]>, Alexandre Petrescu 

>> < <mailto:[email-masked]> [email-masked]> < <mailto:[email-masked]> mailto:[email-masked]>,

>> Jerome Haerri < <mailto:[email-masked]> [email-masked]> 

>> < <mailto:[email-masked]> mailto:[email-masked]>, Thierry Ernst 

>> < <mailto:[email-masked]> [email-masked]> < <mailto:[email-masked]> mailto:[email-masked]>, 

>>  <mailto:[email-masked]> [email-masked] < <mailto:[email-masked]> mailto:[email-masked]>

>> has been successfully submitted by Alexandre Petrescu and posted to 

>> the

>>  <URL:https://www.ietf.org/internet-drafts/draft-ietf-ipwave-ipv6-over-> URL:https://www.ietf.org/internet-drafts/draft-ietf-ipwave-ipv6-over-

>> Please note that it may take a couple of minutes from the time of 

>> submission

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 19 Sep 2017 17:51:48 +0200

Le 19/09/2017 à 17:05, Jérôme Härri a écrit :
[...]
> Now the question is: Why would we need a new Ethertype if we do plain
>  IPv6-over-OCB…

Let me clarify myself: I am not asking for a new EtherType for
IPv6-over-OCB.  IPv6-over-OCB uses 0x86DD, and that's fine.

What may be needed, is IANA to list 0x88DC too, for the sake of
completeness at IANA.  That's not in IPv6-over-OCB.

> Why would we need to differentiate at L3 OCB from BSS/IBSS WiFi ?
> IPv6 header and packets are the same, only the access technology 
> changes, which is out of scope of IETF. Could we use an IPv6 Profile
> to provide some traffic differentiation?
> 
> I understand there might be requirements at L3 to know that some of
> the ‘assumed’ security mechanisms at 802.11 level be absent (or that
> IPv6 ND would need to operate differently…), and therefore to adopt
> an alternative strategy…I am just wondering if an Ethertype is the
> right tool for this….

No, not the right tool.  Sorry if I made a mistake here stirring the waters.

If somebody with IP background builds a unique box for all country
markets (instead of currently 2 distinct boxes) then that somebody will
look up EtherTypes at IEEE and at IETF and everywhere else where it is
necessary.  One can live with that, it's just browsing the web.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 19 Sep 2017 17:54:59 +0200

Le 19/09/2017 à 16:22, François Simon a écrit :
[...]
> [Fygs: Most of the “trials” have used 10 Mhz channel spacing and 6 mbit/s]

Some of trials someone tried on road did 12mbit/s.  Not sure what 
channel spacing was it, though.

[...]> *[Fygs: Text from “version 7”: *
> 
> *“**/Prohibition of IPv6 on some channels relevant for IEEE 802.11-OCB, 
> as opposed to IPv6 not being prohibited on any channel on which/*
> 
> */802.11a/b/g/n runs:/*
> 
> */      *  Some channels are reserved for safety communications; the IPv6/*
> 
> */         packets should not be sent on these channels./*
> 
> */      *  At the time of writing, the prohibition is explicit at higher/*
> 
> */         layer protocols providing services to the application; these/*
> 
> */         higher layer protocols are specified in IEEE 1609 documents,/*
> 
> */         i.e. the "WAVE" stack./*
> 
> */      *  National or regional specifications and regulations specify the/*
> 
> */         use of different channels; these regulations must be 
> followed/**.*
> 
> * Any channels within the 5.9 GHz band can be used to exchange safety 
> applications data, except for the 5 MHz in the lower part of the band 
> which is “reserved”.  However, FCC identify channels 172 (33 dBm max. 
> EIRP) and 184 (33/44 dBm max. EIRP) which are “**/designated for public 
> safety applications involving safety of life and property/**.” The 
> national regulations (FCC – 47 CFR) specify the channel use details but 
> does not specify protocols.*
> 
> *Since IPWAVE IPv6 over OCB is exclusively related to “IPv6 – LLC” 
> Service Access Point (SAP) (above the OCB MAC), there is no requirement 
> to be compatible with the IEEE 1609 protocol stack.  Therefore, the 
> prohibition is irrelevant and should not be stated. LLC, IEEE 802.11, 
> and FCC have no protocol restriction on any of the channels of 5.9 GHz 
> band].*
> 
> *It is recommended to delete this entire section (shown above) of the 
> document.]*

Noted.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 19 Sep 2017 20:46:29 +0200

Le 19/09/2017 à 19:15, Dick Roy a écrit :
> I believe the IANA listing is simply meant to reflect the content of the
> IEEE RA ethertype assignments.  It is apparently only updated occasionally
> and is today a bit out of date.  I would not worry about such small matters.
> I would, however, look to the IEEE RA site as the official site for
> ethertypes, not the IANA site.

Agreed.

(and please fix the email issue so your emails get into the archive, 
without me having to respond)

Alex

> -----Original -----
> Sent: Tuesday, September 19, 2017 4:43 AM
> To: [email-masked]; 'William Whyte'
> Cc: [email-masked]

---

From: François Simon <[email-masked]>
Date: Wed, 20 Sep 2017 10:43:56 -0400

Mr. Harri,

In the US 802.11-2016 OCB supports two 20 MHz channels in the 5.9 MHz band; Service Channels 175 and 181.

In the US, the certification of products will require conformance to the IEEE 802.11 standard which makes mandatory the support of 3, 6, and 12 Mb/s for 10 MHz channel spacing and 6, 12, and 24 Mb/s for 20 MHz channel spacing.

It is true that the maximum data rate for 10 MHz channel is 27 MHz.   However, the data rate / modulation has nothing to do with the content of the PPDU data field. Each OFDM frame (PPDU) being transmitted, the 4 LSB of the SIGNAL field must be set to the required data rate (i.e.; 0x0101 – QPSK R=1/2 for 6 Mbps for 10 MHz channel spacing).  One must not confuse data rate and throughput.

Ethertype for OCB

*	The LLC provides multiplexing for several network protocols coexisting within the network transported on the same medium. In the case of OCB, 0x86DD for IPv6, 0x88DC for WSMP, etc.
*	The Ethertype identifies transport protocol; not application data (i.e., BSM). A BSM data message transported in an IPv6 frame, IPv6 being the transport protocol, would indeed be identified as Ethertype 0x86DD, the same BSM being transported in a WSM would be identify by 0X88dDC.

“Now the question is: Why would we need a new Ethertype if we do plain IPv6-over-OCB…Why would we need to differentiate at L3 OCB from BSS/IBSS WiFi ? IPv6 header and packets are the same, only the access technology changes, which is out of scope of IETF. Could we use an IPv6 Profile to provide some traffic differentiation?”

You are correct in respect of OCB is just an “add-on” to BSS, IBSS, and WiFi. And yes the technology change is out of scope as long that IPv6 use of the OCB services stays within the OCB constraints.

Sincerely,

Francois Simon

From: Jérôme Härri [mailto:[email-masked]] 
Sent: Tuesday, September 19, 2017 11:06 AM
To: 'François Simon' <[email-masked]>; 'Alexandre Petrescu' <[email-masked]>
Cc: [email-masked]
Subject: RE: [ipwave] -06 comments

Dear Mr. Simon,

*	IEEE 802.11 does not do it, and I would not understand why they would need it, as OCB is clearly identified at LL by a wildcard BSSID as well as ToDS and fromDS fields to set to 0. 

*	IEEE 1609.x indeed proposed an Ethertype (used over the last decade if I am not mistaken) for the WAVE stack (not BSM)..BSM use such ethertype as they are not transmitted over IPv6 (or IPv4), but only because they use a WAVE headers (and the WAVE non-IP stack). Would BSM be sent over IPv6, they would most likely not use this ethertype. 

*	In EU, the ETSI followed a similar strategy for the GeoNet stack (the Geonet headers)…CAM use the GeoNet Ethertype but would most likely not use it if CAM would be sent over plain IPv6. 

Best Regards,

Jérôme 

From: its [mailto:[email-masked]] On Behalf Of François Simon
Sent: Tuesday 19 September 2017 16:23
To: 'Alexandre Petrescu'
Cc: [email-masked] <mailto:[email-masked]> ; [email-masked] <mailto:[email-masked]> 
Subject: Re: [ipwave] -06 comments

Mr. Petrescu,

Sincerely,

Francois Simon

Lojik Technologies

       the document.

802.11a/b/g/n runs:

         i.e. the "WAVE" stack.

Alex

-----Original Message-----
From: Alexandre Petrescu [mailto:[email-masked]]
Sent: Monday, September 18, 2017 8:01 AM
To: François Simon <[email-masked] <mailto:[email-masked]> >
Subject: Re: -06 comments

Mr. Simon,

Alex