Subject: Re: [ipwave] WGLC for draft-ietf-ipwave-ipv6-over-80211ocb-08

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Mon, 02 Oct 2017 15:38:28 +0200

Hi,

Kind reminder. So far we have received no responses.

Let me state the obvious. Without a number of response supporting the
document progressing, we will not be able to move it to the IESG.

Please provide your comments.

Thanks,

Carlos

On Sat, 2017-09-23 at 20:42 +0200, Carlos Jesús Bernardos Cano wrote:
> Hi,
> 
> Hereby we are issuing a WGLC for draft-ietf-ipwave-ipv6-over-
> 80211ocb-
> 08. 
> 
> The WGLC will be open till the 8th of October to give enough time for
> people to review. We kindly ask the WG to review the document and
> provide comments.
> 
> If you have no comments and think the document is ready, please do
> send
> a note stating that to the WG ML.
> 
> Additional information about the document is below:
> 
>         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)
>         Authors         : Alexandre Petrescu
>                           Nabil Benamar
>                           Jérôme Härri
>                           Christian Huitema
>                           Jong-Hyouk Lee
>                           Thierry Ernst
>                           Tony Li
>         Filename        : draft-ietf-ipwave-ipv6-over-80211ocb-08.txt
>         Pages           : 38
>         Date            : 2017-09-19
> 
> Abstract:
>    In order to transmit IPv6 packets on IEEE 802.11 networks running
>    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) impacts IPv6 handover
>    behaviour and IPv6 security.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-ipwave-ipv6-over-80211ocb
> /
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-08
> https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv6-over-802
> 11
> ocb-08
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-ipwave-ipv6-over-80211oc
> b-
> 08
> 
> Thank you for your support.
> 
> -- Russ and Carlos

---

From: José Santa Lozano <[email-masked]>
Date: Mon, 2 Oct 2017 16:29:44 +0200

Dear Carlos, all,

I support the document in its current form.

Regards,

-- 
José Santa Lozano
Department of Information and Communication Engineering
Faculty of Computer Science
University of Murcia
30100 Murcia, Spain
Phone: +34-868-884616 / +34-868-884455
Fax: +34-868-884151

> El 2 oct 2017, a las 15:38, Carlos Jesús Bernardos Cano <[email-masked]> escribió:
> 
> Hi,
> 
> _______________________________________________
> its mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/its

---

From: Margaret Cullen <[email-masked]>
Date: Mon, 2 Oct 2017 12:50:50 -0400

Hi Carlos,

Sorry for the relatively late feedback on this document...  This is the first time I’ve noticed this document, and (having worked on multiple IP over Foo efforts) I thought I might be able to offer some useful feedback.

General Comments:
Section 1 says:  "The IPv6 network layer operates on 802.11-OCB in the same manner as it operates on 802.11 WiFi, with a few particular exceptions.”  The document then goes on to duplicate a lot of information that is already included in other RFCs (such as a description of the 802.11 Ethernet Adaptation Layer, the frame format for transmitting IPv6 packets over Ethernet, and the format of the Source/Target Link-Layer address option, etc.).  I checked a lot of that information against the original RFCs to see if there were any changes specific to OCB, and there weren’t any in the sections I checked.  I am not sure what advantage there is to repeating all of that information here, and I think it makes it harder to pick out the 802.11-OCB-specific information.  Sections 2, 3, 4, part of 5.5, 5.6 and 6 seems to contain most of the information that is specific to 802.11-OCB.  IMO, that is the sort of information that should be included in this document, rather than the duplication of packet and option formats from other RFCs.  

I am concerned about the fact that running IPv6 over 802.11-OCB is substantially less secure than running it over standard 802.11.  The document lists options to address this, but none of them are mandatory to implement.  Should they be?  For instance, should we say that when IPv6 is run over 802.11-OCB the “relative function” from the IEEE (IEEE 1609.3-2016 [IEEE-1609.3], clause 5.5.1 and IEEE 1609.4-2016 [IEEE-1609.4], clause 6.7) MUST be implemented?  Would that resolve the security issues raised in Section 6?

If I am understanding correctly, there will be no global address allocation on these networks, only link-local address allocation.  Is that correct?  If so, this document should probably mention that.  If I am wrong, then where would the global subnet prefix(es) come from?

Specific Comments:

In Section 7:  I think you are attempting to allocate a “Link-Local Scope Multicast Address” from the “IPv6 Multicast Address Space Registry”, which you can find here:  https://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml#link-local.  If so, you should say that :-).  Even if I am wrong about what you are trying to allocate, though, you need to list a specific IANA registry in this section, and be clearer about exactly what you are asking them to allocate.

In Section 4:  I would leave out the bandwidth licensing and power level details, as they are regional regulatory requirements and subject to change outside the scope of this document.  In other words, I would remove the whole “Frequency Range” bullet item.

Also in Section 4:  The bullet about privacy concerns me, as it points out a “strong need” for privacy mechanisms, but it doesn’t specify any.  Should it state that one of the two IEEE functions cited MUST be implemented when using IPv6 over 802.11-OCB?  Would those sufficiently address the concern?

Section 5.6 notes that a “prefix exchange mechanism could be needed”, but doesn’t define one.  Is that statement actually pertinent to IPv6 over OCB?  If not, I would remove the sentence.

Margaret

> On Sep 23, 2017, at 2:42 PM, Carlos Jesús Bernardos Cano <[email-masked]> wrote:
> 
> Hi,
> 
> Hereby we are issuing a WGLC for draft-ietf-ipwave-ipv6-over-80211ocb-
> 08. 
> 
> If you have no comments and think the document is ready, please do send
>         Title           : Transmission of IPv6 Packets over IEEE 802.11
>    outside the context of a basic service set (OCB, earlier "802.11p")
>    others.  This document describes these parameters for IPv6 and IEEE
>    802.11-OCB networks; it portrays the layering of IPv6 on 802.11-OCB
>    (802.11p) links compared to more 'traditional' 802.11a/b/g/n links,
> https://datatracker.ietf.org/doc/draft-ietf-ipwave-ipv6-over-80211ocb/
> 
> https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-ipv6-over-80211
> ocb-08
> 
> https://www.ietf.org/rfcdiff?url2=draft-ietf-ipwave-ipv6-over-80211ocb-
> 08
>

---

From: François Simon <[email-masked]>
Date: Tue, 3 Oct 2017 08:08:52 -0400

Sir,

As for IEEE 802.11 OCB, I believe the document to be correct.  However, I have a general question which pertains to U.S and perhaps other countries as well.  While we progress with IPv6 over IEEE 802.11 OCB, does anyone have given any thoughts what type of applications that this service (IPv6 OCB) would support? 

In the US when the 5.9 GHz spectrum was allocated back in early 2000's, the standard was intended to be an "approach that is often regarded as necessary for effective public safety communications." [FCC 03-324 – February 2004].  Unless there have been relaxation of the rules, the 5.9 GHz allocation is for safety applications.  So far in the US, all V2V and initial V2I efforts are related to safety applications.

Sincerely,

Francois Simon
Lojik Technologies

-----Original Message-----
From: its [mailto:[email-masked]] On Behalf Of Carlos Jesús Bernardos Cano
Sent: Monday, October 02, 2017 9:38 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [ipwave] WGLC for draft-ietf-ipwave-ipv6-over-80211ocb-08

Hi,

Let me state the obvious. Without a number of response supporting the document progressing, we will not be able to move it to the IESG.

Thanks,

Carlos

On Sat, 2017-09-23 at 20:42 +0200, Carlos Jesús Bernardos Cano wrote:
> send a note stating that to the WG ML.
> 

_______________________________________________
its mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/its

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Tue, 03 Oct 2017 14:41:20 +0200

Hi Margaret,

Thanks a lot for your very good comments. As an individual I tend to
agree with most of it. One part that I really share your concern is on
the repetition of information that is already available elsewhere. I
see this document as the very baseline for IPv6 over 802.11-OCB (I'm
sure there are plenty of optimizations/adjustments that could then be
done afterwards), and as such I think we better keep it focus on the
basics and remove information that is not needed. I think it would not
be bad if we end up with a 2-page (just to say a number) document that
really goes into the point.

Authors: please address Margaret's points.

Thanks,

Carlos

On Mon, 2017-10-02 at 12:50 -0400, Margaret Cullen wrote:
> Hi Carlos,
> 
> Sorry for the relatively late feedback on this document...  This is
> the first time I’ve noticed this document, and (having worked on
> multiple IP over Foo efforts) I thought I might be able to offer some
> useful feedback.
> 
> General Comments:
> Section 1 says:  "The IPv6 network layer operates on 802.11-OCB in
> the same manner as it operates on 802.11 WiFi, with a few particular
> exceptions.”  The document then goes on to duplicate a lot of
> information that is already included in other RFCs (such as a
> description of the 802.11 Ethernet Adaptation Layer, the frame format
> for transmitting IPv6 packets over Ethernet, and the format of the
> Source/Target Link-Layer address option, etc.).  I checked a lot of
> that information against the original RFCs to see if there were any
> changes specific to OCB, and there weren’t any in the sections I
> checked.  I am not sure what advantage there is to repeating all of
> that information here, and I think it makes it harder to pick out the
> 802.11-OCB-specific information.  Sections 2, 3, 4, part of 5.5, 5.6
> and 6 seems to contain most of the information that is specific to
> 802.11-OCB.  IMO, that is the sort of information that should be
> included in this document, rather than the duplication of packet and
> option formats from other RFCs.  
> 
> I am concerned about the fact that running IPv6 over 802.11-OCB is
> substantially less secure than running it over standard 802.11.  The
> document lists options to address this, but none of them are
> mandatory to implement.  Should they be?  For instance, should we say
> that when IPv6 is run over 802.11-OCB the “relative function” from
> the IEEE (IEEE 1609.3-2016 [IEEE-1609.3], clause 5.5.1 and IEEE
> 1609.4-2016 [IEEE-1609.4], clause 6.7) MUST be implemented?  Would
> that resolve the security issues raised in Section 6?
> 
> If I am understanding correctly, there will be no global address
> allocation on these networks, only link-local address allocation.  Is
> that correct?  If so, this document should probably mention that.  If
> I am wrong, then where would the global subnet prefix(es) come from?
> 
> Specific Comments:
> 
> In Section 7:  I think you are attempting to allocate a “Link-Local
> Scope Multicast Address” from the “IPv6 Multicast Address Space
> Registry”, which you can find here:  https://www.iana.org/assignments
> /ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml#link-local. 
>  If so, you should say that :-).  Even if I am wrong about what you
> are trying to allocate, though, you need to list a specific IANA
> registry in this section, and be clearer about exactly what you are
> asking them to allocate.
> 
> In Section 4:  I would leave out the bandwidth licensing and power
> level details, as they are regional regulatory requirements and
> subject to change outside the scope of this document.  In other
> words, I would remove the whole “Frequency Range” bullet item.
> 
> Also in Section 4:  The bullet about privacy concerns me, as it
> points out a “strong need” for privacy mechanisms, but it doesn’t
> specify any.  Should it state that one of the two IEEE functions
> cited MUST be implemented when using IPv6 over 802.11-OCB?  Would
> those sufficiently address the concern?
> 
> Section 5.6 notes that a “prefix exchange mechanism could be needed”,
> but doesn’t define one.  Is that statement actually pertinent to IPv6
> over OCB?  If not, I would remove the sentence.
> 
> Margaret
> 
>

---

From: Tony Li <[email-masked]>
Date: Tue, 3 Oct 2017 08:30:25 -0700

I agree completely and urge the WG to extract anything that is not essential.

Experimental evidence suggests that it turns out to be about 12 pages. ;-)

Tony

> On Oct 3, 2017, at 5:41 AM, Carlos Jesús Bernardos Cano <[email-masked]> wrote:
> 
> Hi Margaret,
>

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Tue, 3 Oct 2017 16:03:44 +0000

I think that is a good question and I spent some time thinking about this as well.

I tend to think our goal at IETF should be to make IP protocols work on 802.11-OCB as in any other link-layer technology. That include ND, DHCPv6, SLAAC ..etc.

All though the current specifications around safety messaging (such WSMP) are specified as a link-layer protocols, there may be value in making them work over IP.

The application(s) that will be carried on IP over 802.11-OCB will still be safety specific application, as the band is specific to safety, per regulation.

Sri

From: its <[email-masked]<mailto:[email-masked]>> on behalf of François Simon <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, October 3, 2017 at 5:08 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [ipwave] WGLC for draft-ietf-ipwave-ipv6-over-80211ocb-08

Sir,

Asfor IEEE 802.11 OCB, I believe the document to be correct.  However, I have a general question which pertains to U.S and perhaps other countries as well.  While we progress with IPv6 over IEEE 802.11 OCB, does anyone have given anythoughtswhat type of applications that this service (IPv6 OCB)would support?

In the US when the5.9 GHz spectrum was allocated back in early 2000's, thestandard was intended to be an "approach that is often regarded as necessary for effective public safety communications."[FCC 03-324– February2004].  Unless there have beenrelaxation of the rules, the5.9 GHz allocation is for safety applications.  So far in the US,all V2V and initial V2I efforts are related to safety applications.

Sincerely,

Francois Simon

Lojik Technologies

-----Original Message-----
From: its [mailto:[email-masked]] On Behalf Of Carlos Jesús Bernardos Cano
Sent: Monday, October 02, 2017 9:38 AM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [ipwave] WGLC for draft-ietf-ipwave-ipv6-over-80211ocb-08

Hi,

Thanks,

Carlos

its mailing list

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

---

From: Tony Li <[email-masked]>
Date: Tue, 3 Oct 2017 09:17:19 -0700

> The application(s) that will be carried on IP over 802.11-OCB will still be safety specific application, as the band is specific to safety, per regulation.  

Who or what is going to enforce this?

Once IP runs over a media, any and every Internet application will work there and there’s not much that anyone can do about it at that point.

Beyond keeping IP on the applications channels, is there anything else that we can realistically do?

Tony

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Tue, 3 Oct 2017 16:29:24 +0000

The question is about the assumption on the operating band for 802.11-OCB.

5.9GHz band (with 75 MHz allocation) is specific to vehicle safety. We cannot run any applications that want in that band. They have to be strictly for vehicular safety.

This is a regulatory restriction; FCC in United States and others in other areas. There are discussions on sharing this band for other applications, but I do not think its approved.

Sri

From: its <[email-masked]<mailto:[email-masked]>> on behalf of Tony Li <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, October 3, 2017 at 9:17 AM
To: Sri Gundavelli <[email-masked]<mailto:[email-masked]>>
Cc: François Simon <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [ipwave] WGLC for draft-ietf-ipwave-ipv6-over-80211ocb-08

Once IP runs over a media, any and every Internet application will work there and there's not much that anyone can do about it at that point.

Tony

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Tue, 3 Oct 2017 16:34:58 +0000

I have reviewed this document and I have provided detailed feedback some
time back. With each version the document has improved greatly and I
appreciate the author¹s efforts around that. This is good work. Now, some
high-level comments:

1. The document is well written and has lot of good information,
especially around the IEEE standardization/references .etc. The document
also still has some unnecessary information and can afford to loose some
more weight :); I suggest authors to think about this and remove some more
text. Remember, ³less is more².

2. The issue that concerns me is still around lack of complete
specification from a system point of view. System here in this context is
a IPv6 routed network. Where the document fails is on providing sufficient
details on how IPv6 ND/routing/IP addressing/prefix exchange/route
lookups/link models work. Mapping functions, details on transmit/receiving
functions and the special considerations/implications around SCH/CCH
channels is all good and in scope.  So, we have two options, drop every
think around those aspects and put an explicit disclaimer that all that is
out of scope for this document, or do a complete job and specify all
details. My view is that we should put an explicit disclaimers that the
focus of this document is strictly about transmitting/receiving of IPv6
packet on the 802.11-OCB media.

Sri

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Tue, 3 Oct 2017 19:38:04 +0000

Sorry, I was not clear. Aspects specific to link-layer/media are relevant
and are in scope. Focus is only on the media, link-layer support and the
mapping of IPv6 fields to L2 fields.

Other topics related to ND/routing/IP addressing/prefix exchange/route
lookups/link models ..etc can be out of scope. My suggestion is for
including explicit statement on this point and so you don’t have to have
answer on how ND works. Otherwise, there is a good chance your draft will
not pass IPv6 reviews, IMO.

Sri

On 10/3/17, 11:19 AM, "Dick Roy" <[email-masked]> wrote:

>I'm slightly confused by your comment 2).  On the one hand, you state:
>
>"Mapping functions, details on transmit/receiving
>channels is all good and in scope"
>
>seems to state that details of L2 functionality and below are in scope,
>but
>the very next sentence
>
>" So, we have two options, drop every
>details."
>explicitly claims they are out of scope.  I happen to believe
>wholeheartedly
>with this assessment and don't believe any of this belongs in the
>document.
>Furthermore, narrowing the scope to simply IPv6 over 802.11 OCB also makes
>no sense, since the details of OCB operation are completely irrelevant to
>IPv6 functionality or any other L3 technology for that matter. To
>paraphrase
>your last sentence:
>
>My view is that you should remove anything not related to the
>transmitting/receiving of IPv6 packets over media in which the network
>topology is rapidly varying (e.g. IEEE 802.11 communication interfaces in
>vehicles) and simply state that as the focus of the work.
>
>Cheers,
>
>RR
>
>From: its [mailto:[email-masked]] On Behalf Of Sri Gundavelli
>(sgundave)
>Sent: Tuesday, October 3, 2017 9:35 AM
>To: [email-masked]; [email-masked]

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Tue, 3 Oct 2017 19:42:20 +0000

I struggled with this question how to decouple this discussion and make it more widely applicable to a media with no band specific restriction.   I love to see IPv6 applicable for any application when operating on 802.11-OCB link-layer.  But, as I understand the IEEE definition of 802.11-OCB is not allowing that.  When we IPv6 over 802.11-OCB, we are operating IPv6 on a link-layer qualified by IEEE with the name 802.11-OCB and which is explicitly tied to 5.9GHz band.  So, its not what we mention on not, but the OCB mode brings that restriction. May be IEEE experts can explain how its applicable to other bands, or to general applications.  We can surely hide it, but the argument has to hold.

> 5.9GHz band in the US may change designation from sole use for ITS to a shared band.

The proposal is for sharing with 802.11 ac radios operating in the normal mode (not the OCB mode).

https://ecfsapi.fcc.gov/file/10727211758581/Cisco_Extension%20Request%20(ET%20Docket%2013-49).pdf

Sri

From: Dick Roy <[email-masked]<mailto:[email-masked]>> on behalf of Dick Roy <[email-masked]<mailto:[email-masked]>>
Organization: SRA
Reply-To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, October 3, 2017 at 11:33 AM
To: Microsoft Office User <[email-masked]<mailto:[email-masked]>>, 'Tony Li' <[email-masked]<mailto:[email-masked]>>
Cc: 'François Simon' <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [ipwave] WGLC for draft-ietf-ipwave-ipv6-over-80211ocb-08

Again, I highly recommend the group stop even mentioning IEEE 802.11 OCB or the 5.9GHz band currently allocated to ITS in the US (and partially in Europe).  None of that is/should be relevant to the work of the group.  That particular set of lower layer specifications and regulations is simply one "use case" for IPv6 networking in rapidly varying (network) topological environments.  There are others, and more to come!   Furthermore, the particular set of applications is also irrelevant and out of scope.  The group can safely assume that flows of all classes and types should be supported where possible, and move on with the effort.

As was pointed out, there is a possibility that the 5.9GHz band in the US may change designation from sole use for ITS to a shared band.  As unfortunate as this outcome would be, this too is irrelevant to the work of the group.  Tying the work statement to any frequency band that may be reallocated is simply a bad idea, first and foremost because it is totally unnecessary to do so.

Cheers,

RR

________________________________
From: its [mailto:[email-masked]] On Behalf Of Sri Gundavelli (sgundave)
Sent: Tuesday, October 3, 2017 9:29 AM
To: Tony Li
Cc: François Simon; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [ipwave] WGLC for draft-ietf-ipwave-ipv6-over-80211ocb-08

Sri

Tony

---

From: Rex Buddenberg <[email-masked]>
Date: Tue, 03 Oct 2017 13:02:40 -0700

Sri,

Which IEEE?

IEEE 802.11 or IEEE 1609?

On Tue, 2017-10-03 at 19:42 +0000, Sri Gundavelli (sgundave) wrote:
> I struggled with this question how to decouple this discussion and
> make it more widely applicable to a media with no band specific
> restriction.   I love to see IPv6 applicable for any application when
> operating on 802.11-OCB link-layer.  But, as I understand the IEEE
> definition of 802.11-OCB is not allowing that.  When we IPv6 over
> 802.11-OCB, we are operating IPv6 on a link-layer qualified by IEEE
> with the name 802.11-OCB and which is explicitly tied to 5.9GHz band.
>  So, its not what we mention on not, but the OCB mode brings that
> restriction. May be IEEE experts can explain how its applicable to
> other bands, or to general applications.  We can surely hide it, but
> the argument has to hold.
> 
> 
> 
> From: Dick Roy <[email-masked]> on behalf of Dick Roy <dickroy@
> alum.mit.edu>
> Organization: SRA
> Reply-To: "[email-masked]" <[email-masked]>
> To: Microsoft Office User <[email-masked]>, 'Tony Li' <tony.li@to
> ny.li>
> Cc: 'François Simon' <[email-masked]>, "[email-masked]" <cjbc@it
> .uc3m.es>, "[email-masked]" <[email-masked]>
> Again, I highly recommend the group stop even mentioning IEEE 802.11
> OCB or the 5.9GHz band currently allocated to ITS in the US (and
> partially in Europe).  None of that is/should be relevant to the work
> of the group.  That particular set of lower layer specifications and
> regulations is simply one “use case” for IPv6 networking in rapidly
> varying (network) topological environments.  There are others, and
> more to come!   Furthermore, the particular set of applications is
> also irrelevant and out of scope.  The group can safely assume that
> flows of all classes and types should be supported where possible,
> and move on with the effort.  
>  
> As was pointed out, there is a possibility that the 5.9GHz band in
> the US may change designation from sole use for ITS to a shared band.
>  As unfortunate as this outcome would be, this too is irrelevant to
> the work of the group.  Tying the work statement to any frequency
> band that may be reallocated is simply a bad idea, first and foremost
> because it is totally unnecessary to do so.
>  
> Cheers,
> 
> RR
>  
> Cc: François Simon; [email-masked]; [email-masked]
> 5.9GHz band (with 75 MHz allocation) is specific to vehicle safety.
> We cannot run any applications that want in that band. They have to
> be strictly for vehicular safety.
>  
> This is a regulatory restriction; FCC in United States and others in
> other areas. There are discussions on sharing this band for other
> applications, but I do not think its approved.
>  
>  
>  
> Sri
>  
> From: its <[email-masked]> on behalf of Tony Li <[email-masked]
> i>
> To: Sri Gundavelli <[email-masked]>
> Cc: François Simon <[email-masked]>, "[email-masked]" <[email-masked]
> >, "[email-masked]" <[email-masked]>
> > The application(s) that will be carried on IP over 802.11-OCB will
> > still be safety specific application, as the band is specific to
> > safety, per regulation.  
>  
>  
> Once IP runs over a media, any and every Internet application will
> work there and there’s not much that anyone can do about it at that
> point.
>

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Tue, 3 Oct 2017 21:24:46 +0000

Rex,

I am referring to 1609 specification set and also the 802.11p. I do not
want to give an impression that I have a  clear understanding of those
specs, or that I follow them closely, but let me point to few things.

As I understand, the MAC layer is designee for vehicular safety
application, operating in 5.9 GHz band and so the restrictions around
CCH/SCH channel usage.

There is a clear linkage between the Mac layer in 802.11p, WSMP in 1609.x
and the SAE documents for safety.

I might be violating some rules around IEEE text duplication, so let me
just point to one or two lines around document description.  Let me know
if believe one can operate 802.11-OCB in other bands, say 2.4 G.Hz, or 5
G.Hz bands?

‹
802.11p:
"5.9 GHz Band Wireless Access in Vehicular Environments (WAVE)/Dedicated
Short Range
Communications (DSRC) Medium Access Control (MAC) and Physical Layer (PHY)
Specifications²

1609.2
5.9 GHz Dedicated Short Range Communications for Wireless Access in
Vehicular Environments
(DSRC/WAVE, hereafter simply WAVE), as specified in a range of standards
including those generated by
the IEEE P1609 working group, enables vehicle-to-vehicle (V2V) and
vehicle-to-infrastructure (V2I)
wireless communication
---

Sri

On 10/3/17, 1:02 PM, "Rex Buddenberg" <[email-masked]> wrote:

>> regulations is simply one ³use case² for IPv6 networking in rapidly
>> work there and there¹s not much that anyone can do about it at that
>> point.
>>

---

From: John Kenney <[email-masked]>
Date: Tue, 3 Oct 2017 15:39:01 -0700

Hi All:

Actually, my understanding of the FCC DSRC regulations is that they do not
limit DSRC to safety services, though of course that's where most of the
interest is.  For example, CFR 47 §95.1511(d)
<https://www.gpo.gov/fdsys/pkg/CFR-2010-title47-vol5/pdf/CFR-2010-title47-vol5-sec95-1511.pdf>
indicates that DSRC communications other than for "safety/public safety"
are permitted on a "non-priority" basis.

This non-priority communication is still a licensed DSRC service, and has
to conform with all FCC DSRC regulations. It is distinct from unlicensed
communication (U-NII, e.g. Wi-Fi) in the 5.9 GHz band, which is the subject
of an open FCC proceeding.

Best Regards,
John

On Tue, Oct 3, 2017 at 9:29 AM, Sri Gundavelli (sgundave) <
[email-masked]> wrote:

> 5.9GHz band (with 75 MHz allocation) is specific to vehicle safety. We
> cannot run any applications that want in that band. They have to be
> strictly for vehicular safety.
>
> This is a regulatory restriction; FCC in United States and others in other
> areas. There are discussions on sharing this band for other applications,
> but I do not think its approved.
>
>
>
> Sri
>
> From: its <[email-masked]> on behalf of Tony Li <[email-masked]>
> Cc: François Simon <[email-masked]>, "[email-masked]" <[email-masked]>, "
> [email-masked]" <[email-masked]>
> The application(s) that will be carried on IP over 802.11-OCB will still
> be safety specific application, as the band is specific to safety, per
> regulation.
>
>
>
> Once IP runs over a media, any and every Internet application will work
> there and there’s not much that anyone can do about it at that point.
>

-- 
John Kenney
Director and Principal Researcher
Toyota InfoTechnology Center, USA
465 Bernardo Avenue
Mountain View, CA 94043
Tel: 650-694-4160. Mobile: 650-224-6644

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Tue, 3 Oct 2017 23:36:22 +0000

Thanks John . Not my area of expertise, but I can ask the spectrum policy experts in my company to enlighten me. I thought, "non-priority" classification, is more about marking messages involving "safety to life", vs. all other vehicular safety related communication data.

- Priority communications - "Communications involving the safety of life have access priority over all other DSRCS communications;"
- Non-Priority Communications - "DSRCS communications not listed in paragraph (c) of this section, are non- priority communications."

If it turns out that the operator managing this band can run other applications in the DSRC band, then it will be good.

I think we just need to make sure the IP layer we are defining has to conform to the assumptions made in the link-layer.

Sri

From: John Kenney <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, October 3, 2017 at 3:39 PM
To: Microsoft Office User <[email-masked]<mailto:[email-masked]>>
Cc: Tony Li <[email-masked]<mailto:[email-masked]>>, François Simon <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [ipwave] WGLC for draft-ietf-ipwave-ipv6-over-80211ocb-08

Hi All:

Actually, my understanding of the FCC DSRC regulations is that they do not limit DSRC to safety services, though of course that's where most of the interest is.  For example, CFR 47 §95.1511(d)<https://www.gpo.gov/fdsys/pkg/CFR-2010-title47-vol5/pdf/CFR-2010-title47-vol5-sec95-1511.pdf> indicates that DSRC communications other than for "safety/public safety" are permitted on a "non-priority" basis.

This non-priority communication is still a licensed DSRC service, and has to conform with all FCC DSRC regulations. It is distinct from unlicensed communication (U-NII, e.g. Wi-Fi) in the 5.9 GHz band, which is the subject of an open FCC proceeding.

Best Regards,
John

On Tue, Oct 3, 2017 at 9:29 AM, Sri Gundavelli (sgundave) <[email-masked]<mailto:[email-masked]>> wrote:
The question is about the assumption on the operating band for 802.11-OCB.

Sri

Tony

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Wed, 4 Oct 2017 00:06:39 +0000

From: Dick Roy <[email-masked]<mailto:[email-masked]>> on behalf of Dick Roy <[email-masked]<mailto:[email-masked]>>
Organization: SRA
Reply-To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, October 3, 2017 at 4:55 PM
To: Microsoft Office User <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [ipwave] WGLC for draft-ietf-ipwave-ipv6-over-80211ocb-08

[RR] If all the group is concerned with is MTUs and mapping of IPv6 fields to L2 header fields, then I suggest there is not much for the group to do. This is child's play in comparison to the work necessary to set up an IPv6 network when the topology is rapidly changing.  In fact, ISO has several standards that do just the mapping you mention above already for various L1/L2 communication interfaces. See ISO 21218 and friends.  The IEF really has naught to do with it, and shouldn't really.

[Sri]  Nope. Not about what should be done in ITS group. Its more about what should be in this document, vs in other ITS documents. In the current form its incomplete.  There is no discussion on how the node generates addresses, or about routers, hosted prefixes ... but claim that ND works. BTW, it does work, if you run it in a lab with no mobility, but not when vehicles are moving at 65mph.

including explicit statement on this point and so you don't have to have

[RR] Fair, but unless the current IPv6 protocol/functions work "out of the box" in rapidly varying topological environments such as those found on US freeways and motorways in Europe, I sure hope you are wrong, because having IPv6 protocols work in those environments is the ITS community's ONLY concern.  That community presumes IPv6 is working/will work in (quasi-)static environments!

[Sri] We can have a long discussion on this, but I am fairly positive ND in the current form will have issues in this environment. Better to keep that out of scope and let it pass IESG. You are welcome to keep it in the document and try, but the document will come back to WG.

Sri

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Wed, 4 Oct 2017 00:09:46 +0000

> [RR] Sure, but that’s just what you’d like to see.  If for some reason the “system” decides to use a different networking protocol, that’s really of no consequence to the work of the group, and MUST be allowed BTW.

You guys are already doing this in 1609.3, with WSMP over L2 :)

Sri

From: Dick Roy <[email-masked]<mailto:[email-masked]>> on behalf of Dick Roy <[email-masked]<mailto:[email-masked]>>
Organization: SRA
Reply-To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, October 3, 2017 at 4:47 PM
To: Microsoft Office User <[email-masked]<mailto:[email-masked]>>, 'Tony Li' <[email-masked]<mailto:[email-masked]>>
Cc: 'François Simon' <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [ipwave] WGLC for draft-ietf-ipwave-ipv6-over-80211ocb-08

See comments inline …

________________________________
From: its [mailto:[email-masked]] On Behalf Of Sri Gundavelli (sgundave)
Sent: Tuesday, October 3, 2017 12:42 PM
To: [email-masked]<mailto:[email-masked]>; 'Tony Li'
Cc: 'François Simon'; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [ipwave] WGLC for draft-ietf-ipwave-ipv6-over-80211ocb-08

I struggled with this question how to decouple this discussion and make it more widely applicable to a media with no band specific restriction.   I love to see IPv6 applicable for any application when operating on 802.11-OCB link-layer.
[RR] Sure, but that’s just what you’d like to see.  If for some reason the “system” decides to use a different networking protocol, that’s really of no consequence to the work of the group, and MUST be allowed BTW.  The group should only be concerned with flow types (plan for all types) and rapid reconfiguration of network topologies and all that entails (ND, routing tables, etc.), and be prepared to handle a ranage of MTUs below L3!
 But, as I understand the IEEE definition of 802.11-OCB is not allowing that.  When we IPv6 over 802.11-OCB, we are operating IPv6 on a link-layer qualified by IEEE with the name 802.11-OCB and which is explicitly tied to 5.9GHz band.
[RR] Not true at all.  I know because I wrote much of the spec.  OCB is a mode that is not tied to any particular band.  OCB operational mode allows ANYTHING except those management frames related to sync, auth, and assoc. ! You can use OCB any time, anywhere, just don’t expect a non-OCB device (AP or STA) to respond:^)))  .  In the 5.9GHz bands in the US and the EU, dot11OCBActivated is to be set to true according to the IEEE 802.11 spec.  NOTHING prevents another standard or a regulation or a system specification from overriding this, however.  To date, none have, but it is possible!
So, its not what we mention on not, but the OCB mode brings that restriction.
[RR] Nope. And even if it did, that would be yet another reason for not mentioning any specific L1/L2 technology!
May be IEEE experts can explain how its applicable to other bands, or to general applications.  We can surely hide it, but the argument has to hold.
[RR] OCB can be used any time, anywhere! It’s used in test labs all the time.  It’s used in scanners all the time. The fact that those devices don’t set an internal variable to some value that is NEVER transmitted over the air does not matter.  They are operating as a fully compliant 802.11 tx and rx device w/o having sync’ed, authenticated or associated!  That’s all OCB is. It’s really very simple!

https://ecfsapi.fcc.gov/file/10727211758581/Cisco_Extension%20Request%20(ET%20Docket%2013-49).pdf
[RR] Today, yes, but just wait a week or two.  LTE V2X will be rearing its ugly head and you’ll have another MAC/PHY to contend with assuming you continue to insist on worrying about particular MACs and PHYs.  Again, there is a solution.  Remember when the patient proclaimed to his doctor, “Doc, every time I beat myself over the head with a hammer, it hurts like hell! What should I do???” and the doctor replied “Well then, stop doing it!”

RR

Sri

Again, I highly recommend the group stop even mentioning IEEE 802.11 OCB or the 5.9GHz band currently allocated to ITS in the US (and partially in Europe).  None of that is/should be relevant to the work of the group.  That particular set of lower layer specifications and regulations is simply one “use case” for IPv6 networking in rapidly varying (network) topological environments.  There are others, and more to come!   Furthermore, the particular set of applications is also irrelevant and out of scope.  The group can safely assume that flows of all classes and types should be supported where possible, and move on with the effort.

Cheers,

RR

Sri

Tony

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Wed, 4 Oct 2017 01:40:41 +0000

> [RR] I trust what you say since I have no reason not to (I am not an IETF member or participant other than on this list, trying to help).  I suspect ND in it’s current form will not suffice, which is the main reason we (at ISO) went to the IETF to get this BoF off the ground.  Just ask Thierry, he’ll give you all the gory details you want:^)))

> If what you say is true, and again I don’t doubt you, I  must admit that I am now confused as to what, if anything, the work of the group would actually do for us ITS folks.  We know how to send IPv6 packets over ANY medium, even those with MTUs less than 1500 bytes, and are even working the 6LoWPAN problem for small MTUs.  What we need is for the networking protocols to work properly when the network topology is rapidly varying (and here rapidly varying means varying faster than the current protocols can handle!), and there we were/are relying on the IETF to help out. We know the problem is hard, which is why we turned it over to the experts!

My point is not that it cannot be made to work. But, there are more details needed on how it works, or any special considerations that implementations should take aware of (if any). Those details are missing from the spec.

My suggestion is to have a separate document which focusses on the ND/link layer/addressing and other aspects.   This document has done a good job explaining all the IEEE standards and in setting the overall context. It also covered the details around IPv6 packet transmission/reception on this link-layer. Now, a new document on “ND Considerations for Vehicular Environments”, or as you say, “ND for rapidly changing link-layer environments”,  can fill the gap, IMO.

Sri

Date: Tuesday, October 3, 2017 at 6:04 PM

________________________________
From: Sri Gundavelli (sgundave) [mailto:[email-masked]]
Sent: Tuesday, October 3, 2017 5:07 PM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [ipwave] WGLC for draft-ietf-ipwave-ipv6-over-80211ocb-08

[RR] If all the group is concerned with is MTUs and mapping of IPv6 fields to L2 header fields, then I suggest there is not much for the group to do. This is child’s play in comparison to the work necessary to set up an IPv6 network when the topology is rapidly changing.  In fact, ISO has several standards that do just the mapping you mention above already for various L1/L2 communication interfaces. See ISO 21218 and friends.  The IEF really has naught to do with it, and shouldn’t really.

[Sri]  Nope. Not about what should be done in ITS group. Its more about what should be in this document, vs in other ITS documents. In the current form its incomplete.  There is no discussion on how the node generates addresses, or about routers, hosted prefixes … but claim that ND works. BTW, it does work, if you run it in a lab with no mobility,
[RR] Yes, I know and it’s great that it does!
but not when vehicles are moving at 65mph.
[RR] Yes, I know, and it’s sad that it doesn’t.  In fact, this is what needs addressing.

[RR] Fair, but unless the current IPv6 protocol/functions work “out of the box” in rapidly varying topological environments such as those found on US freeways and motorways in Europe, I sure hope you are wrong, because having IPv6 protocols work in those environments is the ITS community’s ONLY concern.  That community presumes IPv6 is working/will work in (quasi-)static environments!

[Sri] We can have a long discussion on this, but I am fairly positive ND in the current form will have issues in this environment. Better to keep that out of scope and let it pass IESG. You are welcome to keep it in the document and try, but the document will come back to WG.
[RR] I trust what you say since I have no reason not to (I am not an IETF member or participant other than on this list, trying to help).  I suspect ND in it’s current form will not suffice, which is the main reason we (at ISO) went to the IETF to get this BoF off the ground.  Just ask Thierry, he’ll give you all the gory details you want:^)))

If what you say is true, and again I don’t doubt you, I  must admit that I am now confused as to what, if anything, the work of the group would actually do for us ITS folks.  We know how to send IPv6 packets over ANY medium, even those with MTUs less than 1500 bytes, and are even working the 6LoWPAN problem for small MTUs.  What we need is for the networking protocols to work properly when the network topology is rapidly varying (and here rapidly varying means varying faster than the current protocols can handle!), and there we were/are relying on the IETF to help out. We know the problem is hard, which is why we turned it over to the experts!

RR

Sri

---

From: Tony Li <[email-masked]>
Date: Tue, 3 Oct 2017 23:50:50 -0700

> [RR] I trust what you say since I have no reason not to (I am not an IETF member or participant other than on this list, trying to help).  I suspect ND in it’s current form will not suffice, which…

Being on this mailing list officially makes you an IETF member. ;-)

> If what you say is true, and again I don’t doubt you, I  must admit that I am now confused as to what, if anything, the work of the group would actually do for us ITS folks.  We know how to send IP…

I still would like to see some hard evidence of these alleged ‘problems’. We’ve run IP over some very flaky links before without terrible problems. Yes, there is packet loss.  IP largely works up until about 10% and then it’s just hopeless. Not much we can do about that unless folks want to add reliability underneath IP.

My own experience with DSRC is that it works just fine for IP.

Tony

---

From: Jérôme Härri <[email-masked]>
Date: Wed, 4 Oct 2017 12:07:45 +0200

Dear All,

Well, each state will need to enforce it. At least in EU, the ECC will need to do it (or delegate this enforcement - but as deployment has not started yet, and so far, most ETSI day 1 are safety-related, the issue is not raised yet..)…

The true question is ‘what safety-related’ truly means...maybe I am sending a packet to reserve a parking lot and by doing so, I will help safety of others…as you see, the debate is (and will remain) complex and if we enter this debate, we will still be discussing this in a decate…other people are doing it now, we do not need to do it again. What we seems to need a L3 mechanism indicating if the type of traffic is Safety-related or not…(how the Application will select it, or how a L1/L2 will restrict it is out of scope). 

My point is: this is out of scope of IP and IETF. I think (my humble proposal) is  to be candid and simply say: our scope is to provide guidelines for IPv6 over OCB at the L3 and not beyond…what happens below and above (what kind of band, what kind of restrictions, how applications will ‘claim’ to be safety-related), is not in the scope of IETF…we might just refer to specific documents mentioning the restrictions (and therefore the required enforcement, like the ETSI harmonized standard EN 302 663), but not to let us being ‘distracted’ by these debates…

Maybe that is where this document might be ambiguous (and we might improve it as such): it provides OCB-related specifications and requirements/limitations as information (which is valuable to understand IPv6 restrictions on OCB), but is in a normative document…maybe we could have one informative RFC on OCB-related aspects (including all the spectrum restrictions…) and have a normative RFC that only expose L3 issues and propose mechanisms and values to operate them…

BR,

Jérôme

From: its [mailto:[email-masked]] On Behalf Of Tony Li
Sent: Tuesday 03 October 2017 18:17
To: Sri Gundavelli
Cc: François Simon; [email-masked]; [email-masked]
Subject: Re: [ipwave] WGLC for draft-ietf-ipwave-ipv6-over-80211ocb-08

 

Tony

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 4 Oct 2017 13:31:41 +0200

Hi Margaret,

We will try to address the comments in the draft.

Here are some answers.

Le 02/10/2017 à 18:50, Margaret Cullen a écrit :
[...]
> General Comments: Section 1 says:  "The IPv6 network layer operates 
> on 802.11-OCB in the same manner as it operates on 802.11 WiFi, with
>  a few particular exceptions.”

Yes, it says so.

> The document then goes on to duplicate a lot of information that is 
> already included in other RFCs

True, it does duplicate some text from other RFC, most notably from
RFC2464.  I think this kind of duplication is not forbidden.

However, at some points the duplicated text is further refined.  Some of
the refinements are about, for example, references to new privacy RFCs.

> (such as a description of the 802.11 Ethernet Adaptation Layer,

The 802.11 Ethernet Adaptation Layer is not described anywhere else.

It is a new concept proposed in this draft.

An Ethernet Adaptation Layer is also used in 802.11 _not_ OCB (like
WiFi, that does have BSS context).

> the frame format for transmitting IPv6 packets over Ethernet, and the
> format of the Source/Target Link-Layer address option, etc.).

Yes, that is mostly duplicated text from RFC2464.

But there is a refinement in the frame format explanation: the field
containing the value "1 0 0 0 0 1 1 0 1 1 0 1 1 1 0 1" is explicitly now
saying it is the binary representation of the EtherType 0x86DD.
(RFC2464 is not explicit about this value).  This text clarification was
made here in this draft.

> I checked a lot of that information against the original RFCs to see 
> if there were any changes specific to OCB, and there weren’t any in 
> the sections I checked.

IP-over-OCB specific information that is relevant to IP and that is not
present in RFC2464 nor in other RFCs:
- the Ethernet Adaptation Layer (please double check whether it exists
   in other RFCs - I dont think it does)
- the references to the privacy RFCs
- the multicast Group ID named "All 80211OCB Interfaces Address"
- in the MTU section there is the "Sequence number" increase; this was
   observed during 802.11-OCB experimentation, although it may exist in
   other 802.11 non-OCB (i.e. _inside_ the context of a BSS, like WiFi).

> I am not sure what advantage there is to repeating all of that
> information here,

There are some advantages: while repeating we can improve it.

> and I think it makes it harder to pick out the 802.11-OCB-specific
> information.

I can agree.

However, IP-over-OCB does have some particularities compared to RFC2464.
  At the same time RFC2464 is lacking much implemented information, 
especially when compared to WiFi.

> Sections 2, 3, 4, part of 5.5, 5.6 and 6 seems to contain most of
> the information that is specific to 802.11-OCB.  IMO, that is the
> sort of information that should be included in this document, rather
> than the duplication of packet and option formats from other RFCs.

I agree with you, but I would like to let you know the following.

Currently the text strategy with respect to RFC2464 is the following:
duplicate and refine where necessary.

RFC2464 is an old document, outdated at a few places.  For example this 
IID generation mechanisms lacking privacy, the lack of WiFi details and 
even some typos.

There is an individual submission called 2464bis; but it is not an 
adopted item in any WG at this time.

It is mainly because of this situation of RFC2464 that we went 
duplicating and refining where necessary.

> that resolve the security issues raised in Section 6?

This is being discussed.

In my humble oppinion the current Security Considerations section is
sufficient.

> allocation on these networks, only link-local address allocation.

There will be both.

A fixed Road-Side Unit may send IPv6 Router Advertisements to a car, or
even provide DHCPv6 Prefix Delegation Service.

In RSU-less car-to-car communications the link-local addresses may be
used between cars.  It is in these these kinds of places, where it may
be difficult to decide that one car is the default router of another
car; or that one car is the DHCPv6 Server whereas the other is not.

Also in places where the RSUs may string cars together, but RSUs are
disconnected from the Internet.

> Is that correct?  If so, this document should probably mention that.
>  If I am wrong, then where would the global subnet prefix(es) come 
> from?

That is a very good question.  It has something to do with addressing
architecture for vehicular communications.

Alex
[...]

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 4 Oct 2017 16:04:43 +0200

Dick,

I take advantage of your email from Sri's reply,

Le 04/10/2017 à 03:40, Sri Gundavelli (sgundave) a écrit :
>  > */[RR] I trust what you say since I have no reason not to (I am not 
> an IETF member or participant other than on this list, trying to help). 
>   I suspect ND in it’s current form will not suffice, which is the main 
> reason we (at ISO) went to the IETF to get this BoF off the ground. 
>   Just ask Thierry, he’ll give you all the gory details you want:^)))/*

I will ask Thierry Ernst separately.

On this occasion, I learned yesterday that certain simple tests did 
happen during a plug test about one year ago, with IPv6-over-OCB.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 4 Oct 2017 16:08:00 +0200

Sri,

Le 03/10/2017 à 18:34, Sri Gundavelli (sgundave) a écrit :
[...]
> Where the document fails is on providing sufficient details on how
> IPv6 ND/routing/IP addressing/prefix exchange/route lookups/link
> models work. Mapping functions, details on transmit/receiving 
> channels is all good and in scope.  So, we have two options, drop
> every think around those aspects and put an explicit disclaimer that
> all that is out of scope for this document, or do a complete job and
> specify all details. My view is that we should put an explicit
> disclaimers that the focus of this document is strictly about
> transmitting/receiving of IPv6 packet on the 802.11-OCB media.

I agree.

We will  put explicit short phrase saying that this document is strictly 
about transmitting of IPv6 packets on the 802.11-OCB media.

I also agree that the way ND/routing/IP addressing/prefix exchange/link 
models work can be addressed in more detail in a separate document.

Currently there is a section 5.6 "Subnet Structure".  Maybe remove it?

Alex

>> Let me state the obvious. Without a number of response supporting
>> the document progressing, we will not be able to move it to the
>> IESG.
>> 
>>> 80211ocb- 08.
>>> The WGLC will be open till the 8th of October to give enough time
>>> for people to review. We kindly ask the WG to review the document
>>> and provide comments.
>>> 
>>> If you have no comments and think the document is ready, please
>>> do send a note stating that to the WG ML.
>>> 
>>> Networks operating in mode Outside the Context of a Basic Service
>>> Set (IPv6-over-80211-OCB) Authors         : Alexandre Petrescu 
>>> Nabil Benamar Jérôme Härri Christian Huitema Jong-Hyouk Lee 
>>> Thierry Ernst Tony Li Filename        :
>>> draft-ietf-ipwave-ipv6-over-80211ocb-08.txt Pages           : 38 
>>> Date            : 2017-09-19
>>> 
>>> Abstract: In order to transmit IPv6 packets on IEEE 802.11
>>> networks running 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.
>>> 
>>> links, where IPv6 protocols operate without issues.  Most
>>> notably, the operation outside the context of a BSS (OCB) impacts
>>> IPv6 handover behaviour and IPv6 security.
>>> 
>>> 
/
>>> 11 ocb-08
b-
>> _______________________________________________ its mailing list 
>> [email-masked] https://www.ietf.org/mailman/listinfo/its
> 
> _______________________________________________ its mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/its
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 4 Oct 2017 16:19:05 +0200

Mr. Simon,

In one particular ambition use-case, a car may perform some IP exchanges 
with traffic light controller.  I hope it will work, simultaneously with
the other non-IP messages, because they have distinct EtherTypes.

I need this document to go forth, because the RSU implementer must agree
with the OBU implementer about the format.  IP-over-OCB is probably the
only format that allows to write easily applications that carry an
application-layer data between RSU and OBU.

Other than easiness of app writing, there are many other advantages of
using the TCP/IP family of protocols (as opposed to not using them).

Alex

Le 03/10/2017 à 14:08, François Simon a écrit :
> Sir,
> 
> Asfor IEEE 802.11 OCB, I believe the document to be correct.However, 
> I have a general question which pertains to U.S and perhaps other 
> countries as well.  While we progress with IPv6over IEEE 802.11 OCB, 
> does anyone have given anythoughtswhat type of applications that this
> service(IPv6OCB)wouldsupport?
> 
> In the US when the5.9 GHz spectrum was allocated back in early 
> 2000's, thestandardwas intended to bean "/approach that is often 
> regarded as necessary for effective/*/public 
> safety/*/communications./"[FCC 03-324–February2004].  Unless there 
> have beenrelaxation of the rules, the5.9 GHz allocation is for
> safety applications.  So far in the US,all V2V and initial V2I
> efforts are related to safety applications.
> 
> Sincerely,
> 
> Francois Simon
> 
> Lojik Technologies

---

From: François Simon <[email-masked]>
Date: Wed, 4 Oct 2017 10:20:36 -0400

Here is a brief summary of the 5.9 GHz band US regulations related to channels and applications [Source: Code of Federal Regulations (CFR) – Title 47 - Telecommunications]

a)                   Device types: OBU and RSU

b)                  May provide communication for:

                                                               i.      Public safety application (e.g., government or government sponsored activity). The Safety Applications are prioritized:

a.       Public safety applications involving safety of life and property have the highest priority

b.     Other safety applications have a lower priority

c.     Public safety have access priority over all other communications (i.e., non-priority communications)

Note: OBUs and RSUs operated by state or local governmental entities are presumptively engaged in public safety priority communications.

                                         ii.    Private applications (e.g., individual or businesses) are “Non-priority communications”

c)                   The 5.9 GHz spectrum in the US is divided into channels identified by their respective channel number:

                                                               i.      Channels are classified in a single Control Channel (CCH) and Service Channels (SCH)

                                                             ii.      Spectrum is divided in one reserved 5 MHz channel, 7 * 10 MHz channels, (# 172, 174, 176, 178 (CCH), 180, 182, and 184) or optionally  3 * 10 MHz ( # 172, 178, 184) and 2 * 20 MHz (# 175 and 181) channels. Channel # 178 is the CCH.

                                                           iii.      Safety applications may use any channels

                                        iv.    Channels 172 and 184 are designated for public safety applications involving safety of life and property. There are RSU eligibility requirements to operate on Channel 184 (e.g., any territory, possession, state, city, county, town or similar governmental entity) Note: Other eligibility requirements are defined in 47 CFR §90.373.

d.	References: 47 CFRs: §90.371, §90.373, §90.375, §90.377, §90.379, §90.383, §95.1501, §95.1509, and 95.1511.

This is the simple version.

Fygs

From: Tony Li [mailto:[email-masked]] 
Sent: Tuesday, October 03, 2017 11:33 AM
To: François Simon <[email-masked]>
Subject: Re: [ipwave] WGLC for draft-ietf-ipwave-ipv6-over-80211ocb-08

[Off-list]

 

As with all things IP, this implies that anything and everything will end up running over OCB. The trick then is to not run v6 over the safety channels, which is what I believe we’re trying to do here.

If this is a violation of some mandate, I (and the group) don’t know about it and you should raise it more specifically.  References?

Tony

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Wed, 4 Oct 2017 14:54:07 +0000

Hi Alex,

> Currently there is a section 5.6 "Subnet Structure".  Maybe remove it?

Let me go through the doc once and make specific recommendations on what
sections to touch. Will try to close it by Monday.

Sri

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Wed, 4 Oct 2017 15:48:24 +0000

>      ii.    Private applications (e.g., individual or businesses) are "Non-priority communications"

Yes. I missed that clause.

I now understand from my colleague who deals with FCC maters that, FCC does allow the use of DSRC radios for private communications (still as a  licensed a service). The example he cited was on the "movie ticket sale over DSRC radio at gas stations". This confirms what John and Dick have said and so thanks for the clarification on this point.

Sri

From: its <[email-masked]<mailto:[email-masked]>> on behalf of François Simon <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, October 4, 2017 at 7:20 AM
To: 'Tony Li' <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [ipwave] WGLC for draft-ietf-ipwave-ipv6-over-80211ocb-08

Here is a brief summary of the 5.9 GHz band US regulations related to channels and applications [Source: Code of Federal Regulations (CFR) - Title 47 - Telecommunications]

                                         ii.    Private applications (e.g., individual or businesses) are "Non-priority communications"

  1.  References: 47 CFRs: §90.371, §90.373, §90.375, §90.377, §90.379, §90.383, §95.1501, §95.1509, and 95.1511.

From: Tony Li [mailto:[email-masked]]
Sent: Tuesday, October 03, 2017 11:33 AM
To: François Simon <[email-masked]<mailto:[email-masked]>>
Subject: Re: [ipwave] WGLC for draft-ietf-ipwave-ipv6-over-80211ocb-08

[Off-list]

As with all things IP, this implies that anything and everything will end up running over OCB. The trick then is to not run v6 over the safety channels, which is what I believe we're trying to do here.

If this is a violation of some mandate, I (and the group) don't know about it and you should raise it more specifically.  References?

Tony

---

From: Tony Li <[email-masked]>
Date: Wed, 4 Oct 2017 08:14:02 -0700

> RFC2464.  I think this kind of duplication is not forbidden.

It’s also not helpful and it detracts value from the document. It would be far preferable to add a reference to relevant sections of 2464, or a blanket reference and then elide the replicated text.

Replication typically causes ambiguity because if you haven’t directly quoted the document, any wording differences between documents leads to confusion of interpretations and precedence.

Tony

---

From: Abdussalam Baryun <[email-masked]>
Date: Thu, 5 Oct 2017 05:55:02 +0200

Hi Alex,

I thank the authors for their hard work and hope we can work together to
make the doc best. I don't think it is ready for submission. I am still
reviewing but I give now some comments.

Ethernet is defined by IEEE as IEEE802.3. However, I think the document
should not mention IEEE802.11 protocol (some name WiFi) as similar protocol
like IEEE802.3 ( Ethernet) protocol, one is wireless protocol and the other
is wired. The transmissions are different, I don't see that they are
similar even their frames are not similar. So it is not correct in section
5.2 mentioned that:

IP packets are transmitted over 802.11-OCB as standard Ethernet

packets.

IMO even the document RFC2464, should have been (more technical focus)
referencing the protocol IEEE802.3, instead of naming that may change by
time.

Regarding the figures it needs to be numbered and I suggest removing the
word WiFi from the figures.

My comments below as [AB]:

On Wed, Oct 4, 2017 at 1:31 PM, Alexandre Petrescu <
[email-masked]> wrote:

>> General Comments: Section 1 says:  "The IPv6 network layer operates on
>> 802.11-OCB in the same manner as it operates on 802.11 WiFi, with

[AB] I agree with Margaret questions, maybe authors can explain WiFi, or
delete it. Is IEEE802.11-WiFi explained/defied/discriminated? is there an
RFC discussing WiFi or IP packet over WiFi? if not then we should not say
this is similar to something not described in IETF.

> RFC2464.  I think this kind of duplication is not forbidden.

[AB] I don't agree with duplication while not necessary because it
confuses. Maybe we need to focus on our document objectives by less
duplications. IMHO, the introduction is very long and doc sections are not
much focused. Don't forget that RFC2464 talks aboy Ethernet, which is
IEEE802.3 protocol.

> It is a new concept proposed in this draft.

[AB] please change the name from Ethernet Adaptation TO: IPWAVE adaptation
or anything other than Ethernet, because we are not doing IEEE802.3

[AB] How can it be used by IPv6?

> I checked a lot of that information against the original RFCs to see if
>> there were any changes specific to OCB, and there weren’t any in the
>> sections I checked.
>>
>

[AB]  I think we can have to version-draft (but not all) , one with the
repeats and one without and then we do a third that is our last draft which
has only needed texts. In English writing they don't repeat information,
but referring to what was mentioned or referencing.

> duplicate and refine where necessary.

[AB]  They are different protocols the Ethernet and the Wireless LAN in
their frame format and also in their method of transmission. If not please
explain/reference?

> There is an individual submission called 2464bis; but it is not an adopted
> item in any WG at this time.
>

[AB]   Please delete those documents which are not ietf-wg-adopted or
maybe have many errors (there are errors in some RFCs but they are very few
because many discussions and reviews). I think we adopted this document and
we need to delete documents that are not even adopted. However, 2464 is not
for wireless communications.

>
> It is mainly because of this situation of RFC2464 that we went duplicating
> and refining where necessary.

[AB]  It is ok that we duplicated in some drafts, but it is important now
we write a new version with what we need only without confusions.

Thanks
AB

---

From: Tony Li <[email-masked]>
Date: Wed, 4 Oct 2017 21:47:41 -0700

> Ethernet is defined by IEEE as IEEE802.3. However, I think the document should not mention IEEE802.11 protocol (some name WiFi) as similar protocol like IEEE802.3 ( Ethernet) protocol, one is wireless protocol and the other is wired. The transmissions are different, I don't see that they are similar even their frames are not similar. So it is not correct in section 5.2 mentioned that:
> IP packets are transmitted over 802.11-OCB as standard Ethernet packets.
> 

Well, to us L3-heads, it’s all Ethernet framing (DIX encapsulation). This is one of the things that has made Wi-Fi successful. If we were unable to bridge between Ethernet and Wi-Fi, things would have been much, much less successful.

> [AB] I agree with Margaret questions, maybe authors can explain WiFi, or delete it. Is IEEE802.11-WiFi explained/defied/discriminated? is there an RFC discussing WiFi or IP packet over WiFi? if not then we should not say this is similar to something not described in IETF.

No, there is no such RFC.  Why? Because we’ve never needed one. Once you ignore all of the (albeit extremely important) L2 mechanisms that go on behind the scenes, 802.11 looks just like an Ethernet interface. If we do it right, 802.11-OCB will too. That’s the whole point of this document.

> [AB] How can it be used by IPv6?

What does “it” refer to?

> [AB]   Please delete those documents which are not ietf-wg-adopted or maybe have many errors (there are errors in some RFCs but they are very few because many discussions and reviews). I think we adopted this document and we need to delete documents that are not even adopted. However, 2464 is not for wireless communications.

Please do not delete the references.  We welcome references to other documents, whether or not they are IETF documents.

Tony

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 5 Oct 2017 16:01:30 +0200

Le 04/10/2017 à 17:14, Tony Li a écrit :
> 
>> True, it does duplicate some text from other RFC, most notably
>> from RFC2464.  I think this kind of duplication is not forbidden.
> 
> 
> It’s also not helpful and it detracts value from the document. It
> would be far preferable to add a reference to relevant sections of
> 2464, or a blanket reference and then elide the replicated text.
> 
> Replication typically causes ambiguity because if you haven’t
> directly quoted the document, any wording differences between
> documents leads to confusion of interpretations and precedence.

I propose the following "Frame Format" section which does not replicate. 
  It only refers, and adds a new explanation which is missing in 
RFC2464.  Do you agree with this text?

> 5.2.  Frame Format
>    packets.  As with all 802.11 frames, an Ethernet adaptation layer is
>    used with 802.11-OCB as well.  This Ethernet Adaptation Layer
>    performing 802.11-to-Ethernet is described in Section 5.2.1.  The
>    Ethernet Type code (EtherType) for IPv6 is 0x86DD (hexadecimal 86DD,
>    or otherwise #86DD).
> 
>    The Frame format for transmitting IPv6 on 802.11-OCB networks is the
>    same as transmitting IPv6 on Ethernet networks, and is described in
>    section 3 of [RFC2464].
> 
>    1 0 0 0 0 1 1 0 1 1 0 1 1 1 0 1
>       is the binary representation of the EtherType value 0x86DD.

Alex

---

From: Abdussalam Baryun <[email-masked]>
Date: Thu, 5 Oct 2017 17:33:59 +0200

Hi Tony,

On Thu, Oct 5, 2017 at 6:47 AM, Tony Li <[email-masked]> wrote:

> Well, to us L3-heads, it’s all Ethernet framing (DIX encapsulation). This
> is one of the things that has made Wi-Fi successful. If we were unable to
> bridge between Ethernet and Wi-Fi, things would have been much, much less
> successful.
>

[AB] Why will WG choose only the Ethernet framing in WAVE? or why we need
to force all IP packets to be encapsulated by Ethernet? Why not an
adaptation for one general framing related to IPWAVE applications and
enviroments?

[AB] The answer for the above seems to me like, it is easier for design,
but is it efficient for WAVE new generations?

[AB]  If we say let us look into bridging wireless and wired (which is not
this document objective), we can have bridging Ethernet and WiFi, but is
that most available WAVE protocols in the wired networks?

> No, there is no such RFC.  Why? Because we’ve never needed one.
>

[AB]  I think there is/was a need, but IETF still may ignore wireless MAC
protocols, it depends on the WG participants. Yes, the participants decide
the need, and also they can use MAC with less care.

> Once you ignore all of the (albeit extremely important) L2 mechanisms that
> go on behind the scenes, 802.11 looks just like an Ethernet interface. If
> we do it right, 802.11-OCB will too. That’s the whole point of this
> document.
>

So is the point to ignore that we have a wireless network, so we assume our
network is wired. That was many old approaches in IPv4 networks, we need to
move on to better approaches for IPv6. This sounds like we assume what is
not true to be true, so that means BAD service. IMHO, those assumptions in
the old days of IPv4 and now in many IPv4 networks can work ok because they
are fixed-wireless, they have no WAVE scenarios, now I think our WG are
required to look into transmitting IP packets into real scenarios of WAVE.

[AB] Why will we ignore L2 mechanism (which is 802.11 in our doc title as
an objective) but still the main objective is to transmit over it? I think
we need to be clear in the document of such assumption or ignorance.
However, I am not in favour to ignore the 802.11 mechanisms just to make
things simple.

> [AB] How can it be used by IPv6?

The layer of adaptation mentioned in the doc.

> Please do not delete the references.  We welcome references to other
> documents, whether or not they are IETF documents.
>

Yes we may welcome when needed, but I think the doc is referencing as a
survey but please note this is not a survey/informational doc.  I recommend
that we focus on our doc objectives, so if this is a standard we don't need
many referencing to docs that are not adopted by any group in any
standard-organisation.

AB

---

From: Tony Li <[email-masked]>
Date: Thu, 5 Oct 2017 08:56:46 -0700

Hi,

> [AB] Why will WG choose only the Ethernet framing in WAVE? or why we need to force all IP packets to be encapsulated by Ethernet? Why not an adaptation for one general framing related to IPWAVE applications and enviroments?
> 
> [AB] The answer for the above seems to me like, it is easier for design, but is it efficient for WAVE new generations?
> 
> [AB]  If we say let us look into bridging wireless and wired (which is not this document objective), we can have bridging Ethernet and WiFi, but is that most available WAVE protocols in the wired networks?  

If you haven’t noticed, the document doesn’t talk about using IP over WAVE. That’s already been defined elsewhere and isn’t relevant to our work. The goal for this document is to establish and document framing for IP over 802.11-OCB. 

> Once you ignore all of the (albeit extremely important) L2 mechanisms that go on behind the scenes, 802.11 looks just like an Ethernet interface. If we do it right, 802.11-OCB will too. That’s the whole point of this document.
> 
> So is the point to ignore that we have a wireless network, so we assume our network is wired. That was many old approaches in IPv4 networks, we need to move on to better approaches for IPv6. This sounds like we assume what is not true to be true, so that means BAD service. IMHO, those assumptions in the old days of IPv4 and now in many IPv4 networks can work ok because they are fixed-wireless, they have no WAVE scenarios, now I think our WG are required to look into transmitting IP packets into real scenarios of WAVE.
> 
> [AB] Why will we ignore L2 mechanism (which is 802.11 in our doc title as an objective) but still the main objective is to transmit over it? I think we need to be clear in the document of such assumption or ignorance.
> However, I am not in favour to ignore the 802.11 mechanisms just to make things simple.

That’s a bold claim, and one that I can’t agree with. My work with DSRC shows that it works just fine without any special considerations. To the host, it looks like an Ethernet. If you have evidence to the contrary, please put it on the table. Until then, please stop spreading Fear, Uncertainty and Doubt.

We will ignore the L2 mechanisms because they are out of scope. It is not in the IETF’s purview to document or change L2 mechanisms. We can, of course, use documented mechanisms.

> The layer of adaptation mentioned in the doc.

Very simple: it allows the host layer to see a simple Ethernet encapsulation. It’s a wee bit of complexity in the device driver, to be sure, but above that layer, the rest of the host just sees Ethernet.

I did this for my implementation and ARP and IPv4 just worked. It makes implementation trivial.

Tony

---

From: William Whyte <[email-masked]>
Date: Thu, 5 Oct 2017 12:29:06 -0400

Hi Tony,

>> If you haven’t noticed, the document doesn’t talk about using IP over
WAVE. That’s already been defined elsewhere and isn’t relevant to our work.
The goal for this document is to establish and document framing for IP over
802.11-OCB.

What does IP over WAVE mean other than IP over 802.11-OCB? Once you get
above the PHY and MAC (and the LLC which we've basically removed), the next
thing is the IP Ethertype, isn't it? Honest question.

Cheers,

William

On Thu, Oct 5, 2017 at 11:56 AM, Tony Li <[email-masked]> wrote:

> If you haven’t noticed, the document doesn’t talk about using IP over
> WAVE. That’s already been defined elsewhere and isn’t relevant to our work.
> The goal for this document is to establish and document framing for IP over
> 802.11-OCB.
>
>
> So is the point to ignore that we have a wireless network, so we assume
> our network is wired. That was many old approaches in IPv4 networks, we
> need to move on to better approaches for IPv6. This sounds like we assume
> what is not true to be true, so that means BAD service. IMHO, those
> assumptions in the old days of IPv4 and now in many IPv4 networks can work
> ok because they are fixed-wireless, they have no WAVE scenarios, now I
> think our WG are required to look into transmitting IP packets into real
> scenarios of WAVE.
>
>
> That’s a bold claim, and one that I can’t agree with. My work with DSRC
> shows that it works just fine without any special considerations. To the
> host, it looks like an Ethernet. If you have evidence to the contrary,
> please put it on the table. Until then, please stop spreading Fear,
> Uncertainty and Doubt.
>
> We will ignore the L2 mechanisms because they are out of scope. It is not
> in the IETF’s purview to document or change L2 mechanisms. We can, of
> course, use documented mechanisms.
>
>
> Very simple: it allows the host layer to see a simple Ethernet
> encapsulation. It’s a wee bit of complexity in the device driver, to be
> sure, but above that layer, the rest of the host just sees Ethernet.
>

-- 

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

---

From: [email-masked]
Date: Thu, 5 Oct 2017 09:34:28 -0700

> What does IP over WAVE mean other than IP over 802.11-OCB? Once you get above the PHY and MAC (and the LLC which we've basically removed), the next thing is the IP Ethertype, isn't it? Honest question.

WAVE is IEEE 1609.

Tony

---

From: William Whyte <[email-masked]>
Date: Thu, 5 Oct 2017 12:50:48 -0400

I know that, I'm vice chair of the 1609 working group :-)

But 1609.4 just defines channel switching and 1609.3 defines WSMP and WSA,
which you don't run IP over. Specifically, when you say IP over WAVE, what
parts of the 1609 standards are you talking about using?

Cheers,

William

--

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 6 Oct 2017 13:01:42 +0200

Le 05/10/2017 à 18:29, William Whyte a écrit :
> Hi Tony,
> 
>>> If you haven’t noticed, the document doesn’t talk about using IP
>>> 
> over WAVE. That’s already been defined elsewhere and isn’t relevant 
> to our work. The goal for this document is to establish and document 
> framing for IP over 802.11-OCB.
> 
> What does IP over WAVE mean other than IP over 802.11-OCB?

IP-over-WAVE can mean that an IP packet is prepended by a WSMP header
(WAVE Short Message protocol, P1609.3).  Further, the WSMP message can
be prepended by an LLC header.

In this case, the Type field in the LLC header (aka EtherType field)
contains the value 0x88DC.

On another hand, an IPv6-over-OCB packet is not prepended by a
WSMP header, even though there is an LLC header.
The EtherType in LLC is 0x86DD for IPv6-over-OCB,
           distinct than 0x88DC for IPv6-over-WAVE.

> Once you get above the PHY and MAC (and the LLC which we've
> basically removed), the next thing is the IP Ethertype, isn't it?
> Honest question.

The EtherType is a field in LLC.  If LLC is removed, as implied above,
then is it the EPD ("Ethernet Protocol Discrimination") Layer that
carries an EtherType?

I am asking because I have not seen EPD in packet dumps, but I have seen
LLC in packet dumps.

Alex

> 
> Cheers,
> 
> William
> 
> 
> 
> 
> On Thu, Oct 5, 2017 at 11:56 AM, Tony Li <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
> 
> Hi,
> 
>> [AB] Why will WG choose only the Ethernet framing in WAVE? or why 
>> we need to force all IP packets to be encapsulated by Ethernet?
>> Why not an adaptation for one general framing related to IPWAVE 
>> applications and enviroments?
>> 
>> [AB] The answer for the above seems to me like, it is easier for 
>> design, but is it efficient for WAVE new generations?
>> 
>> [AB]  If we say let us look into bridging wireless and wired
>> (which is not this document objective), we can have bridging
>> Ethernet and WiFi, but is that most available WAVE protocols in the
>> wired networks?
> 
> 
> 
> If you haven’t noticed, the document doesn’t talk about using IP
> over WAVE. That’s already been defined elsewhere and isn’t relevant
> to our work. The goal for this document is to establish and document
> framing for IP over 802.11-OCB.
> 
> 
>> Once you ignore all of the (albeit extremely important) L2 
>> mechanisms that go on behind the scenes, 802.11 looks just like an 
>> Ethernet interface. If we do it right, 802.11-OCB will too. That’s 
>> the whole point of this document.
>> 
>> 
>> So is the point to ignore that we have a wireless network, so we 
>> assume our network is wired. That was many old approaches in IPv4 
>> networks, we need to move on to better approaches for IPv6. This 
>> sounds like we assume what is not true to be true, so that means 
>> BAD service. IMHO, those assumptions in the old days of IPv4 and 
>> now in many IPv4 networks can work ok because they are 
>> fixed-wireless, they have no WAVE scenarios, now I think our WG
>> are required to look into transmitting IP packets into real
>> scenarios of WAVE.
>> 
>> [AB] Why will we ignore L2 mechanism (which is 802.11 in our doc 
>> title as an objective) but still the main objective is to transmit
>>  over it? I think we need to be clear in the document of such 
>> assumption or ignorance. However, I am not in favour to ignore the 
>> 802.11 mechanisms just to make things simple.
> 
> 
> That’s a bold claim, and one that I can’t agree with. My work with 
> DSRC shows that it works just fine without any special 
> considerations. To the host, it looks like an Ethernet. If you have 
> evidence to the contrary, please put it on the table. Until then, 
> please stop spreading Fear, Uncertainty and Doubt.
> 
> We will ignore the L2 mechanisms because they are out of scope. It
> is not in the IETF’s purview to document or change L2 mechanisms. We
>  can, of course, use documented mechanisms.
> 
> 
> encapsulation. It’s a wee bit of complexity in the device driver, to
>  be sure, but above that layer, the rest of the host just sees 
> Ethernet.
> 
> <https://www.ietf.org/mailman/listinfo/its>
> 
> 
> 
> 
> --
> 
> 
> [email-masked] <mailto:[email-masked]>

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 6 Oct 2017 13:21:06 +0200

I looked at 1609.3-2016 and indeed there is no IPv6-over-WSMP.

1609.3-2016 says that IPv6 can be carried straight, with EtherType 0x86DD.

When the EtherType is 0x88DC the payload is WSMP, not IPv6.

Alex

Le 06/10/2017 à 13:01, Alexandre Petrescu a écrit :
>> over WAVE. That’s already been defined elsewhere and isn’t relevant to 
>> our work. The goal for this document is to establish and document 
>>> [AB] Why will WG choose only the Ethernet framing in WAVE? or why we 
>>> need to force all IP packets to be encapsulated by Ethernet?
>>> Once you ignore all of the (albeit extremely important) L2 mechanisms 
>>> that go on behind the scenes, 802.11 looks just like an Ethernet 
>>> interface. If we do it right, 802.11-OCB will too. That’s the whole 
>>> point of this document.
>>>
>>>
>>> sounds like we assume what is not true to be true, so that means BAD 
>>> service. IMHO, those assumptions in the old days of IPv4 and now in 
>>> many IPv4 networks can work ok because they are fixed-wireless, they 
>>> have no WAVE scenarios, now I think our WG
>> DSRC shows that it works just fine without any special considerations. 
>> To the host, it looks like an Ethernet. If you have evidence to the 
>> contrary, please put it on the table. Until then, please stop 
>> spreading Fear, Uncertainty and Doubt.
>>
>>  be sure, but above that layer, the rest of the host just sees Ethernet.
>>

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 6 Oct 2017 13:38:26 +0200

On my side, when I say IP-over-WSMP it may mean the 1609.3 parts which 
are IPv6-ish, yet are different than IPv6.

For example, the 1609.3-2016 fact that WRA may play the role of an IPv6 
RA to help the node to form IPv6 addresses, learn DNS resolvers' 
addresses and default gateways.

At some point the 1609.3 document motivates the use of WRA instead of RA 
by a phrase "[to] reduce the need for neighbor and router discovery with 
their associated overhead and latency".  But there are some means to 
reduce that in IPv6 RFCs as well.

Alex

Le 05/10/2017 à 18:50, William Whyte a écrit :
> But 1609.4 just defines channel switching and 1609.3 defines WSMP and 
> WSA, which you don't run IP over. Specifically, when you say IP over 
> WAVE, what parts of the 1609 standards are you talking about using?
> 
> Cheers,
> 
> William
> 
> On Thu, Oct 5, 2017 at 12:34 PM, <[email-masked] 
>>     What does IP over WAVE mean other than IP over 802.11-OCB? Once
>>     you get above the PHY and MAC (and the LLC which we've basically
>>     removed), the next thing is the IP Ethertype, isn't it? Honest
>>     question.
> 
> 
>     WAVE is IEEE 1609.
> 
>     Tony
> 
> 
> 
> 
> -- 
> 
>

---

From: Jérôme Härri <[email-masked]>
Date: Fri, 6 Oct 2017 13:54:41 +0200

Dear Alex, All,

Let me add a few background details on WAVE and ETSI. First, the IPv6-over-WSMP indeed does not exist...this is a concept from ETSI...

IEEE 1609.3 allows to use plain IPv6. BUT, the whole access to the 5.9Ghz band (in particular on IP, as IPv6 is restricted and cannot be used on CCH in the US) is the concept of 'WAVE Service Announcement', said differently, most of the weaknesses of IPv6 over OCB is 'solved' by IPv6 still relying on the WAVE stack through the WSA.  

One of the procedure (I am sure there are more) is for a WAVE stack to send a WSA on the CCH to indicate a IPv6 service (including the channel, the type of traffic, the priority, and security credentials). Within the WSA a lot of details (security, mechanisms, parameters) are negotiated (there is an IPv6 profile that is provided in the WSA for IPv6 services). Security and privacy is maintained thanks to this mechanism. 

In ETSI, there is no Service announcements (yet), so the strategy ETSI proposed is to encapsulate IPv6 packets in ETSI ITS (non-IP) packets. This is mostly done to guarantee security and privacy.

What we try to do in this draft is different: we propose to use IPv6 without the help of other (any) stack, so plain IPv6-over-OCB...then we need to propose solutions that are solved by ETSI and IEEE WAVE for IPv6 by using their stack...   

Hoping it helps,

BR,

Jérôme
-----Original Message-----
From: its [mailto:[email-masked]] On Behalf Of Alexandre Petrescu
Sent: Friday 06 October 2017 13:38
To: William Whyte; Tony Li
Cc: Margaret Cullen; its; Abdussalam Baryun
Subject: Re: [ipwave] WGLC for draft-ietf-ipwave-ipv6-over-80211ocb-08

On my side, when I say IP-over-WSMP it may mean the 1609.3 parts which are IPv6-ish, yet are different than IPv6.

For example, the 1609.3-2016 fact that WRA may play the role of an IPv6 RA to help the node to form IPv6 addresses, learn DNS resolvers' 
addresses and default gateways.

At some point the 1609.3 document motivates the use of WRA instead of RA by a phrase "[to] reduce the need for neighbor and router discovery with their associated overhead and latency".  But there are some means to reduce that in IPv6 RFCs as well.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 6 Oct 2017 14:01:28 +0200

Hi Abdussalam,

Le 05/10/2017 à 05:55, Abdussalam Baryun a écrit :
> Hi Alex,
> 
> I thank the authors for their hard work and hope we can work together
> to make the doc best. I don't think it is ready for submission. I am
> still reviewing but I give now some comments.
> 
> Ethernet is defined by IEEE as IEEE802.3. However, I think the
> document should not mention IEEE802.11 protocol (some name WiFi) as 
> similar protocol like IEEE802.3 ( Ethernet) protocol, one is wireless
>  protocol and the other is wired. The transmissions are different, I
>  don't see that they are similar even their frames are not similar.

It depends where from you look at it.

IPv6-over-Ethernet is the same as IPv6-over-11, because it just works.
IPv6-over-Ethernet is different than IPv6-over-11, in that there is an
Ethernet Adaptation Layer.

An Ethernet Adaptation Layer converts between 802.3 headers and 802.11
headers.  An Ethernet Adaptation Layer is not used if packets are
transmitted on Ethernet cables.  But an EAL _is_ used if packets are
transmitted on WiFi.

There is no IPv6-over-802.11 RFC, although an EAL is present in all stacks.

> So it is not correct in section 5.2 mentioned that:
> 

Well, they are transmitted as standard Ethernet packets, and then 
adapted by EAL into WiFi packets.

> IMO even the document RFC2464, should have been (more technical
> focus) referencing the protocol IEEE802.3, instead of naming that may
> change by time.

That is a comment to RFC2464.  There is an individual submission for 
2464bis.  You can also write a 2464bis.  At some point some document 
would be adopted and worked on.

> Regarding the figures it needs to be numbered and I suggest removing
> the word WiFi from the figures.

Err.  Why do you think the figures should be numbered?  Have you seen it 
in other RFCs?

Do you know an xml2rfc tag to number figures?

[...]
> Le 02/10/2017 à 18:50, Margaret Cullen a écrit : [...]
> 
> [AB] I agree with Margaret questions, maybe authors can explain WiFi,
> or delete it.

I can add a term in the terminology section that says "WiFi - Wireless 
Fidelity".

> Is IEEE802.11-WiFi explained/defied/discriminated? is
> there an RFC discussing WiFi or IP packet over WiFi? if not then we
> should not say this is similar to something not described in IETF.

But we dont want to block advancement of this document just because 
IPv6-over-WiFi RFC does not exist.   Maybe someone will write such.

[...]

> [AB] please change the name from Ethernet Adaptation TO: IPWAVE 
> adaptation or anything other than Ethernet, because we are not doing
>  IEEE802.3

But it is an Ethernet Adaptation Layer because it adapts WiFi to Ethernet.

The same Ethernet Adaptation Layer is also used by WiFi.

If we call it IPWAVE Adaptation Layer then it means that WiFi does not 
use it.

The behaviour of the Ethernet Adapatation Layer is the same for WiFi and 
for OCB.

> [AB] How can it be used by IPv6?

It is a "layer" in terms of software layers, not in terms of protocol 
layers in a stack.

The Ethernet Adaptation Layer is used by IPv6 software in the kernel. 
You can look at the kernel and see how it is used.

[...]
> Currently the text strategy with respect to RFC2464 is the
> following: duplicate and refine where necessary.
> 
> 
> [AB]  They are different protocols the Ethernet and the Wireless LAN
> in their frame format and also in their method of transmission. If
> not please explain/reference?

YEs, they are different.

[...]
> [AB]   Please delete those documents which are not ietf-wg-adopted

I keep this in mind.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 6 Oct 2017 16:58:00 +0200

Margaret,

> those sufficiently address the concern?

I would disagree to make a MUST for IEEE documents.  We could MUST RFCs.

At the same time, I suggest we move that entire Section 4 into an 
appendix.  It is more tutorial in nature.  Do you disagree?

Alex

---

From: Nabil Benamar <[email-masked]>
Date: Fri, 6 Oct 2017 16:10:32 +0100

I definitely agree with you Alex. No mention of  "MUST" for non RFC
documents.

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

---

From: Nabil Benamar <[email-masked]>
Date: Fri, 6 Oct 2017 16:27:49 +0100

No objection to moving section 4 into an appendix. It is exclusively
related to IEEE 802.11-OCB.

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

---

From: William Whyte <[email-masked]>
Date: Fri, 6 Oct 2017 11:31:21 -0400

I don't see a reason to avoid MUSTing documents from other SDOs. Using
documents from other SDOs as normative references happens all the time. For
example, in the Connected Vehicle setting, both ETSI and SAE documents have
normative references to IEEE standards. It may not be appropriate in this
particular case for technical reasons, but I don't think it should be a
principle.

Cheers,

William

--

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 6 Oct 2017 17:37:52 +0200

When MUST-ing an IEEE document I would like to make sure I take shortest 
paths.  For example, if IPv6-over-OCB MUSTs 1609.x document which then 
MUSTs an RFC in return about privacy identifiers, I would prefer the 
IP-OCB draft to rather MUST directly that RFC, instead of the 1609.x 
document.

Second, the MUST statement is relatively strong.  I would like to make 
sure that software is available easily, IPR is IETF conditions, etc, 
before saying MUST.

There may be other conditions.

But I agree with you it should not be a blind principle.

Le 06/10/2017 à 17:31, William Whyte a écrit :
> documents from other SDOs as normative references happens all the time. 
> For example, in the Connected Vehicle setting, both ETSI and SAE 
> documents have normative references to IEEE standards. It may not be 
> appropriate in this particular case for technical reasons, but I don't 
> think it should be a principle.
> 
> Cheers,
> 
> William
> 
> On Fri, Oct 6, 2017 at 11:10 AM, Nabil Benamar <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     On Fri, Oct 6, 2017 at 3:58 PM, Alexandre Petrescu
>     <[email-masked] <mailto:[email-masked]>>
>     wrote:
> 
>         Margaret,
> 
>         At the same time, I suggest we move that entire Section 4 into
>         an appendix.  It is more tutorial in nature.  Do you disagree?
> 
>         Alex
>

---

From: François Simon <[email-masked]>
Date: Fri, 6 Oct 2017 12:02:14 -0400

Perhaps I miss the point here but.  But my understanding of the IETF ipwave effort is: " The goal for this document is to establish and document framing for IP over 802.11-OCB." Interpreted as IPv6, LLC, MAC OCB, and PHY.  If this is the case, why are we keep bringing back the IEEE 1609? 1609 is out-of-scope.  If indeed we do need some type of service advertisement on the Control Channel (or any other channel), then why not fall back on IEEE 1609.3 which do provide IPv6 over 802.11 OCB?

Fygs  

-----Original Message-----
From: its [mailto:[email-masked]] On Behalf Of Jérôme Härri
Sent: Friday, October 06, 2017 7:55 AM
To: 'Alexandre Petrescu' <[email-masked]>; 'William Whyte' <[email-masked]>; 'Tony Li' <[email-masked]>
Cc: 'Margaret Cullen' <[email-masked]>; 'its' <[email-masked]>; 'Abdussalam Baryun' <[email-masked]>
Subject: Re: [ipwave] WGLC for draft-ietf-ipwave-ipv6-over-80211ocb-08

Dear Alex, All,

Hoping it helps,

BR,

Jérôme
-----Original Message-----
From: its [mailto:[email-masked]] On Behalf Of Alexandre Petrescu
Sent: Friday 06 October 2017 13:38
To: William Whyte; Tony Li
Cc: Margaret Cullen; its; Abdussalam Baryun
Subject: Re: [ipwave] WGLC for draft-ietf-ipwave-ipv6-over-80211ocb-08

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 6 Oct 2017 18:40:16 +0200

> Registry”, which you can find here:
> https://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml#link-local.

We are asking a Group ID, see the IANA Considerations section.

This Group ID can then be used to form multicast addresses of various 
scopes, including the Link-Local scope.

I prefer to be silent at this time about which scope will be used, 
unless you disagree.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 6 Oct 2017 18:47:40 +0200

> words, I would remove the whole “Frequency Range” bullet item.

I moved that entire section in an appendix.

Alex

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Fri, 6 Oct 2017 16:50:45 +0000

Hi Alex,

I remember asking one question on why we need this?  Sorry, I may have
missed the response.

If there is already ALL_NODES_MULTICAST GROUP (FF02::1), which all OBY¹s
and RSU¹s participate, why do we need a new group?

>A Group ID named TBD, of length 112bits is requested to IANA; this Group
>ID signifies ³All 80211OCB Interfaces Address".

Regards
Sri

On 10/6/17, 9:40 AM, "its on behalf of Alexandre Petrescu"
<[email-masked] on behalf of [email-masked]> wrote:

>> In Section 7:  I think you are attempting to allocate a ³Link-Local
>> Scope Multicast Address² from the ³IPv6 Multicast Address Space
>> Registry², which you can find here:
>>

---

From: Tony Li <[email-masked]>
Date: Fri, 6 Oct 2017 09:50:51 -0700

> On Oct 6, 2017, at 9:40 AM, Alexandre Petrescu <[email-masked]> wrote:
> 
> This Group ID can then be used to form multicast addresses of various scopes, including the Link-Local scope.
> 
> I prefer to be silent at this time about which scope will be used, unless you disagree.

Well, I would like to certainly understand more of the motivation behind this request. What is the purpose for this?

You’ll note the there’s no such thing as a group for “All Ethernet interfaces” or “All Wi-Fi interfaces”.

And we already have a plethora of link local addresses.

The draft seems a tad short on motivation here.

Tony

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 6 Oct 2017 18:51:57 +0200

Le 06/10/2017 à 18:02, François Simon a écrit :
> Perhaps I miss the point here but.  But my understanding of the IETF 
> ipwave effort is: " The goal for this document is to establish and 
> document framing for IP over 802.11-OCB." Interpreted as IPv6, LLC, 
> MAC OCB, and PHY.  If this is the case, why are we keep bringing
> back the IEEE 1609? 1609 is out-of-scope.  If indeed we do need some
> type of service advertisement on the Control Channel (or any other 
> channel),

I do not oppose that discussion.

> then why not fall back on IEEE 1609.3 which do provide IPv6 over
> 802.11 OCB?

I would avoid thinking 1609.3 provides IPv6 over 802.11 OCB.  It does
not.

Yes, it does allow running IPv6 over 802.11-OCB because it accepts the
EtherType 0x86DD.

But (1) it lacks many IPv6 features that are possible by using RFCs that
1609.3 does not use and (2) it proposes an alternative yet non standard
way to do address autoconfiguration.

Were 1609.3 to provide IPv6-over-OCB then it would refer to this draft.

Alex

> 
> Fygs
> 
> -----Original Message----- From: its [mailto:[email-masked]]
> On Behalf Of Jérôme Härri Sent: Friday, October 06, 2017 7:55 AM To: 
> 'Alexandre Petrescu' <[email-masked]>; 'William Whyte' 
> <[email-masked]>; 'Tony Li' <[email-masked]> Cc: 
> 'Margaret Cullen' <[email-masked]>; 'its' <[email-masked]>; 
> 'Abdussalam Baryun' <[email-masked]> Subject: Re: 
> [ipwave] WGLC for draft-ietf-ipwave-ipv6-over-80211ocb-08
> 
> Dear Alex, All,
> 
> Let me add a few background details on WAVE and ETSI. First, the 
> IPv6-over-WSMP indeed does not exist...this is a concept from 
> ETSI...
> 
> IEEE 1609.3 allows to use plain IPv6. BUT, the whole access to the 
> 5.9Ghz band (in particular on IP, as IPv6 is restricted and cannot
> be used on CCH in the US) is the concept of 'WAVE Service
> Announcement', said differently, most of the weaknesses of IPv6 over
> OCB is 'solved' by IPv6 still relying on the WAVE stack through the
> WSA.
> 
> One of the procedure (I am sure there are more) is for a WAVE stack 
> to send a WSA on the CCH to indicate a IPv6 service (including the 
> channel, the type of traffic, the priority, and security 
> credentials). Within the WSA a lot of details (security, mechanisms, 
> parameters) are negotiated (there is an IPv6 profile that is
> provided in the WSA for IPv6 services). Security and privacy is
> maintained thanks to this mechanism.
> 
> In ETSI, there is no Service announcements (yet), so the strategy 
> ETSI proposed is to encapsulate IPv6 packets in ETSI ITS (non-IP) 
> packets. This is mostly done to guarantee security and privacy.
> 
> What we try to do in this draft is different: we propose to use IPv6 
> without the help of other (any) stack, so plain IPv6-over-OCB...then 
> we need to propose solutions that are solved by ETSI and IEEE WAVE 
> for IPv6 by using their stack...
> 
> Hoping it helps,
> 
> BR,
> 
> Jérôme -----Original Message----- From: its 
> [mailto:[email-masked]] On Behalf Of Alexandre Petrescu Sent: 
> Friday 06 October 2017 13:38 To: William Whyte; Tony Li Cc: Margaret 
> Cullen; its; Abdussalam Baryun Subject: Re: [ipwave] WGLC for 
> draft-ietf-ipwave-ipv6-over-80211ocb-08
> 
> On my side, when I say IP-over-WSMP it may mean the 1609.3 parts 
> which are IPv6-ish, yet are different than IPv6.
> 
> For example, the 1609.3-2016 fact that WRA may play the role of an 
> IPv6 RA to help the node to form IPv6 addresses, learn DNS resolvers'
> At some point the 1609.3 document motivates the use of WRA instead
> of RA by a phrase "[to] reduce the need for neighbor and router 
> discovery with their associated overhead and latency".  But there
> are some means to reduce that in IPv6 RFCs as well.
> 
> Alex
> 
> 
>> But 1609.4 just defines channel switching and 1609.3 defines WSMP 
>> and WSA, which you don't run IP over. Specifically, when you say
>> IP over WAVE, what parts of the 1609 standards are you talking
>> about using?
>> 
>> Cheers,
>> 
>> William
>>

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 6 Oct 2017 18:56:50 +0200

> I remember asking one question on why we need this?  Sorry, I may have

BEcause it is one possible way of implementing IP multicast.  IP 
multicast is absolutely necessary for IP.

> and RSU¹s participate, why do we need a new group?

Because the subnet structure in WiFi is different than on Ethernet. 
There is a draft explaining that I-D.perkins-intarea-multicast-ieee802.

Further, because the subnet structure in OCB mode is different than the 
subnet structure in WiFi.

In an ALL_NODES group ff02::1 one is sure that whoever subscribed to 
that group will receive whatever message is sent to that group.  By 
extension, an ALL_NODES group in WiFi is relatively similar, although 
even there there are adifferences.

In OCB mode that is not assured - there is no link-layer mechanism to 
make sure that whoever joined that subnet is still there.

Can I ask you in return: why does the Babel routing protocol have its 
own multicast group(s)?

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 6 Oct 2017 18:59:43 +0200

Le 06/10/2017 à 18:50, Tony Li a écrit :
> 
>> On Oct 6, 2017, at 9:40 AM, Alexandre Petrescu 
> Well, I would like to certainly understand more of the motivation behind 
> this request. What is the purpose for this?
> 

That's a problem of WiFi.  But no-one bothers to write an RFC about 
IP-over-WiFi, because the common wisdom is "IP works on WiFi just like 
on Ethernet" - it's not true.

It does not mean that "all-nodes" group which works fine on Ethernet 
also works fine on WiFi.  There are many problems of multicast on WiFi.

> The draft seems a tad short on motivation here.

There was a long discussion about this on v6ops some time ago.

We could re-iterate it here if you wish.

Alex

---

From: Tony Li <[email-masked]>
Date: Fri, 6 Oct 2017 10:01:37 -0700

> On Oct 6, 2017, at 9:59 AM, Alexandre Petrescu <[email-masked]> wrote:
> 

Not necessary, but inserting something into the draft seems quite logical.  I’d welcome a reference or search terms...

Tony

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 6 Oct 2017 19:01:52 +0200

> Authors: please address Margaret's points.

I believe we addressed all Margaret's points in -09.

Alex

>>> for
>>> Set

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 6 Oct 2017 19:08:02 +0200

Le 06/10/2017 à 19:01, Tony Li a écrit :
> 
>> On Oct 6, 2017, at 9:59 AM, Alexandre Petrescu 
> Not necessary, but inserting something into the draft seems quite 
> logical. 

I added something in the introduction.
Since the subnet structure is different in OCB mode then a new Group ID 
makes sense.

This Group ID is still something theoretical at this stage, but I think 
it could be implemented.

> I’d welcome a reference or search terms...

Subject line "MAC and IP multicast addresses in vehicular networks" in 
v6ops WG email list ietf.org/mailman/listinfo date approx July 4th, 2016.

Alex

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Fri, 6 Oct 2017 17:25:23 +0000

I will check draft-perkins to see what I am missing. But given the nature
of this 802-11-OCB-link, I do not understand why all OBU/RSU nodes in
vicinity will not receive a packet sent to ALL_NODES_MULTIGROUP.

I realize, you are dealing with too many questions and so we can discuss
this after you resolve your other issues. But, I do not believe we need to
register a new group, but we can discuss that later.

Sri

On 10/6/17, 9:56 AM, "Alexandre Petrescu" <[email-masked]>
wrote:

>>>>https://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicas
>>>>t-
>>>> addresses.xhtml#link-local.

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 6 Oct 2017 19:29:42 +0200

Le 05/10/2017 à 17:33, Abdussalam Baryun a écrit :
[...]
>>     or maybe have many errors (there are errors in some RFCs but they
>>     are very few because many discussions and reviews). I think we
>>     adopted this document and we need to delete documents that are not
>>     even adopted. However, 2464 is not for wireless communications.
> 
> 
> survey but please note this is not a survey/informational doc.

I am still not convinced about removing that.  That survey/informational 
is looking at joining with the problem statement drafts.  At that point 
it would make sense to refer to them, unless you disagree.

in -09 we say:
> In the published literature, many documents describe aspects and
> problems related to running IPv6 over 802.11-OCB:
> [I-D.ietf-ipwave-vehicular-networking-survey].

Additionally,

There are a three other individual submission documents that we refer 
to.  I believe they are necessary at this time.

draft-perkins-intarea-multicast-ieee802: a good starting point for WiFi 
problems on multicast.  If no other reference, then I keep i.

draft-petrescu-its-scenarios-reqs: it's because we need to tell in this 
draft what kinds of scenarios we look at (the vehicular scenarios).  If 
there is some other RFC or draft that describes the scenarios then I can 
put that instead.

draft-hinden-6man-rfc2464bis: it's because it's the only little try to 
update rfc2464 at this time.  If it gets adopted in 6man then it will be 
fine.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 6 Oct 2017 19:50:21 +0200

Dick,

Le 06/10/2017 à 19:39, Dick Roy a écrit :
> There is NO such thing as an 80211OCB Interface!

In the computers I work with there is a clear distinction between OCB
interfaces and the WiFi interfaces.  Some times people call them "11p"
interfaces rather than "OCB" interfaces.  Is that better?

Moreover, on some computers, people go as far as calling entire boards
on which the OCB modules sits (not just the interface) as the "11p"
part.  In some trials there are entire boxes that are called "11p", or
G5, or DSRC.

Many manufacturers sell them as "11p interfaces".  Is that any more
legitimate.

I am not sure why you think there are no OCB interfaces.

> Creating a multicast group address for a non-existent entity is a 
> waste of an address and simply a bad idea!

We can discuss that.

> OCB is a "mode" of a standard Wi-Fi interface, and "mode" in which 
> data frames can be sent without first TSF syncing, authenticating and
> associating.  The data frames are INDISTINGUISHABLE from any valid
> 802.11 data frame! Upon reception of such a frame, there is no way of
> knowing that the source had sent that frame prior to sync, auth and
> assoc., because there is no field in the header indicating OCBmode!
> Having the addressing of a node depend on the mode it is operating in
> is technically unsound to say the least, and a "recipe for
> disaster".

Well, but only the interfaces that were set on a particular frequency
will receive them.

We can also talk about a "5875-5885"MHz group of interfaces, instead of
"All OCB interfaces".

> This insistence on 802.11OCB is taking the group place it does not 
> want to go.  I will continue to recommend that OCB is dropped from 
> the document altogether. It is a "red herring"!

Er, that's strange.  I think it's too late to drop OCB altogether.
Unless of course, IEEE 802.11 drops "OCB" and comes back to "11p"?  Not
sure what you  mean.

Alex

> On Behalf Of Sri Gundavelli (sgundave) Sent: Friday, October 6, 2017 
> 9:51 AM To: Alexandre Petrescu; [email-masked] Subject: Re: [ipwave] 
> WGLC for draft-ietf-ipwave-ipv6-over-80211ocb-08 - multicast request
> 
> Hi Alex,
> 
> I remember asking one question on why we need this?  Sorry, I may 
> have missed the response.
> 
> If there is already ALL_NODES_MULTICAST GROUP (FF02::1), which all 
> OBY¹s and RSU¹s participate, why do we need a new group?
> 
> 
> 
>> A Group ID named TBD, of length 112bits is requested to IANA; this 
>> Group ID signifies ³All 80211OCB Interfaces Address".
> 
> 
> 
> 
> 
> 
> Regards Sri
> 
> 
> 
> 
>>> In Section 7:  I think you are attempting to allocate a 
>>> ³Link-Local Scope Multicast Address² from the ³IPv6 Multicast 
>>> Address Space Registry², which you can find here:
>>> 
>>> https://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-
>>>
>>>
>>> 
>>> If so, you should say that :-).  Even if I am wrong about what 
>>> you are trying to allocate, though, you need to list a specific 
>>> IANA registry in this section, and be clearer about exactly what 
>>> you are asking them to allocate.
>> 
>> This Group ID can then be used to form multicast addresses of 
>> various scopes, including the Link-Local scope.
>>

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Fri, 6 Oct 2017 18:02:55 +0000

In one sense, we are back to the question of “link models”. If you look at
RFC2461/4861, starting point for IPv6/ND, is a link. There are a notion of
link, a router, a hosted prefix and a set of IPv6 nodes which are integral
to that link.  When a packet is sent to a ALL_NODES group, every node in
that link will receive it. When a packet is sent to ALL_ROUTERS group, all
routers will receive it. In 802.11 infra mode, all of that is somewhat
preserved with the AP acting as a switch and preserving all the semantics
needed for the IPv6 link model.  But, here its somewhat vague and because
we never closed that discussion on link models properly. May be its all
clear especially for the IEEE 1609 guys (as you have built L1/L2 ..), but
for me, its bit hazy; each of us with a different understanding and so
these debates.

I understand the comments, that we should ignore the lower-layers and just
focus on IP, but I am having hard time building a second floor, without
making sure how the first floor looks.

Sri

On 10/6/17, 10:39 AM, "Dick Roy" <[email-masked]> wrote:

>There is NO such thing as an 80211OCB Interface!  Creating a multicast
>group
>address for a non-existent entity is a waste of an address and simply a
>bad
>idea!
>
>OCB is a "mode" of a standard Wi-Fi interface, and "mode" in which data
>frames can be sent without first TSF syncing, authenticating and
>associating.  The data frames are INDISTINGUISHABLE from any valid 802.11
>data frame! Upon reception of such a frame, there is no way of knowing
>that
>the source had sent that frame prior to sync, auth and assoc., because
>there
>is no field in the header indicating OCBmode!  Having the addressing of a
>node depend on the mode it is operating in is technically unsound to say
>the
>least, and a "recipe for disaster".
>
>This insistence on 802.11OCB is taking the group place it does not want to
>go.  I will continue to recommend that OCB is dropped from the document
>altogether. It is a "red herring"!
>
>Cheers,
>
>RR    
>
>Sent: Friday, October 6, 2017 9:51 AM
>To: Alexandre Petrescu; [email-masked]
>Subject: Re: [ipwave] WGLC for draft-ietf-ipwave-ipv6-over-80211ocb-08 -
>multicast request
>
>Hi Alex,
>

---

From: Abdussalam Baryun <[email-masked]>
Date: Sun, 8 Oct 2017 23:56:22 +0200

Hi Alex,

I know the referencing is a minor issue, but it did confuse my reading and
understanding of objectives.

On Fri, Oct 6, 2017 at 7:29 PM, Alexandre Petrescu <
[email-masked]> wrote:

> is looking at joining with the problem statement drafts.  At that point it
> would make sense to refer to them, unless you disagree.
>

any way that was my opinion to remove any extra and not needed info and non
adopted drafts. I respect your opinion. However, we need to focus our draft
to its objective with less as possible literature overview.

> There are a three other individual submission documents that we refer to.
> I believe they are necessary at this time.
>
> problems on multicast.  If no other reference, then I keep I.
>

I agree its ok,

> there is some other RFC or draft that describes the scenarios then I can
ok

> This I disagree to include because not necessary,

---

From: Abdussalam Baryun <[email-masked]>
Date: Mon, 9 Oct 2017 02:46:34 +0200

Hi Alex

For authors information, we need to consider rfc3967, so there are some
informational RFCs in normative, that may need change to informative
reference, and regarding I-D.ietf-tsvwg-ieee-802-11, I suggest to make it
informative. However, I am not expert in rfc3967 but if our
draft-09 follows the rfc then ok.

AB

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 9 Oct 2017 11:16:44 +0200

Sri,

IMHO, in 802.11-OCB a link is made by an emitter, an appoximate distance
and a frequency.  For example, a link is 500m around a car at
5875-5885MHz.  In such a link ND works fine.

The precise definition of a link proper is not agreed.  This is a
wireless issue, more generally.  There is a document approaching this
discussion draft-ietf-intarea-adhoc-wireless-com-02

I am not sure we want to condition the IPv6-over-OCB draft advancement
on the definition of a link.  RFC2464 advances well without a definition
of Ethernet cable length or repeaters.  These are however very important
to an Ethernet link as well.

Le 06/10/2017 à 20:02, Sri Gundavelli (sgundave) a écrit :
> 
> In one sense, we are back to the question of “link models”. If you 
> look at RFC2461/4861, starting point for IPv6/ND, is a link. There 
> are a notion of link, a router, a hosted prefix and a set of IPv6 
> nodes which are integral to that link.  When a packet is sent to a 
> ALL_NODES group, every node in that link will receive it. When a 
> packet is sent to ALL_ROUTERS group, all routers will receive it.

I agree.  But it is no normally only the Nodes or the Routers that have
subscribed to that group.  The subscription method happens with MLDv2.
The success and reliability of the subscription depends on the viability
of the link concept.

> In 802.11 infra mode, all of that is somewhat preserved with the AP 
> acting as a switch and preserving all the semantics needed for the 
> IPv6 link model.

Even then, there are multiple multicast problems, due to the fact that
the AP is the sole having super-control (the STAs have less control).
On another hand, the IP multicast is not relying on a super-control:
anybody could join or leave, and the Router can be distinct from the AP.

> But, here its somewhat vague and because we never closed that
> discussion on link models properly. May be its all clear especially
> for the IEEE 1609 guys (as you have built L1/L2 ..), but for me, its
> bit hazy; each of us with a different understanding and so these
> debates.

I agree with you.  But I am afraid that clarifying a link model for 
wireless 802.11 here may take too much time.

Alex

> I understand the comments, that we should ignore the lower-layers
> and just focus on IP, but I am having hard time building a second
> floor, without making sure how the first floor looks.
> 
> 
> Sri
> 
> 
> 
> 
> 
>> There is NO such thing as an 80211OCB Interface!  Creating a 
>> multicast group address for a non-existent entity is a waste of an 
>> address and simply a bad idea!
>> 
>> data frames can be sent without first TSF syncing, authenticating 
>> and associating.  The data frames are INDISTINGUISHABLE from any 
>> valid 802.11 data frame! Upon reception of such a frame, there is 
>> no way of knowing that the source had sent that frame prior to 
>> sync, auth and assoc., because there is no field in the header 
>> indicating OCBmode!  Having the addressing of a node depend on the 
>> mode it is operating in is technically unsound to say the least, 
>> and a "recipe for disaster".
>> 
>> On Behalf Of Sri Gundavelli (sgundave) Sent: Friday, October 6, 
>> 2017 9:51 AM To: Alexandre Petrescu; [email-masked] Subject: Re: 
>> [ipwave] WGLC for draft-ietf-ipwave-ipv6-over-80211ocb-08 - 
>> multicast request
>> 
>> Hi Alex,
>> 
>>> A Group ID named TBD, of length 112bits is requested to IANA; 
>>> this Group ID signifies ³All 80211OCB Interfaces Address".
>> 
>> 
>> 
>> 
>> 
>> 
>> Regards Sri
>> 
>> 
>> 
>> 
>>>> https://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast
>>>>
>>>>
>>>> 
-
>>>> addresses.xhtml#link-local. If so, you should say that :-). 
>>>> Even if I am wrong about what you are trying to allocate, 
>>>> though, you need to list a specific IANA registry in this 
>>>> section, and be clearer about exactly what you are asking them 
>>>> to allocate.
>>>

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Mon, 09 Oct 2017 16:32:33 +0200

Hi,

Sorry to jumping late on this but I tend to agree on the point make by
some people that we need to properly justify why we need an "All
80211OCB Interfaces Address".

I know that we cannot expect the same behavior from wireless links than
from wired ones. And I know the issues of IEEE 802.11 with multicast
addresses, but I'm not convinced about creating multicast groups
specific to a type of physical interface.

Thanks,

Carlos

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Mon, 09 Oct 2017 16:32:37 +0200

Hi,

> Do you know an xml2rfc tag to number figures?

I agree figures should be numbered. I think adding the "anchor" tag
makes the trick, e.g.:

<figure anchor="fig:figure_foo" title="Caption of figure foo" >
...
</figure>

Then you can cross-ref with: 

<xref target="fig:figure_foo" />

Kind Regards,

Carlos

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Mon, 09 Oct 2017 16:36:13 +0200

Hi,

> about transmitting of IPv6 packets on the 802.11-OCB media.

I agree and support this.

> models work can be addressed in more detail in a separate document.

With current charter scope, this is out of IPWAVE at this point. In the
future, once our currently chartered documents are done, then we could
discuss about this with our AD. But for now, I'd prefer to focus on the
main chartered items. That does not mean people can work on this, but
let's try to keep the WG energy focused on finishing the main docs. And
we know from past autoconf experience, that this separate document is
not trivial to write.

Thanks!

Carlos

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Mon, 09 Oct 2017 16:36:22 +0200

Hi,

I echo Tony's comment. I think we should try to minimize duplication.
If really needed for the sake of readability, I think it'd be good to
explicitly mention that this is text taken from REF X for
informative/illustration purposes.

Thanks,

Carlos

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Mon, 9 Oct 2017 15:24:08 +0000

Hi Dick,

I agree with you on the design principles of layering and the need for
lower-layers to be hidden from the higher-layers. I absolutely agree with
it. But, the minimal requirement from IP perspective is to ensure the
services provided by the lower-layers are consistent. The question here
and largely the key theme in all the current discussions in this group is
just about that. So, the key question is the following:

Will an 802.11 node (with the flag dot11OCBActivated set to TRUE), aka
802-11-OCB node provide the same set of layer-2/lower level services as
any other 802.11 (dot11OCBActivated set to FALSE) node with Ethernet
adaptation layer, to the upper IPv6 layer?  If there is no difference,
then all the discussion on special multicast groups/security/radio
characteristics is largely irrelevant for this specification. We certainly
may have to optimize ND for certain reasons, or have special
considerations for security to meet the link characteristics, but from IP
operation perspective we should not require any special semantics here for
IPv6 operation. An IPv6 node operating on this type of radio link should
behave the same way as in any other link-layer technology/media.

Sri

On 10/6/17, 12:39 PM, "Dick Roy" <[email-masked]> wrote:

>Sri,
>
>I feel your pain:^))) People are using terms that have different meaning
>depending on the layer one comes from! L3 links are not the same as L2
>links, and that can and does cause confusion.  When I use the term link, I
>try to preface it with the layer if it is not clear from the context, e.g.
>use L2 link or L3 link to be clear.
>
>As for " having hard time building a second floor, without
>making sure how the first floor looks", I can sympathize somewhat.  It's
>always a bit easier designing to something concrete.  However, the beauty
>and utility of the OSI (7-layer) Model is that knowledge of the details of
>how the lower layers function is not/should not be necessary/critical in
>designing a protocol that makes use of the services provided by those
>lower
>layers. It's the generic properties of the lower layer protocols instead
>that can be of interest, things such as acknowledged versus
>unacknowledged,
>fragmentation and reassembly (FAR) versus no-FAR, etc..
>
>Cheers,
>
>RR 
>
>Sent: Friday, October 6, 2017 11:03 AM
>To: [email-masked]; 'Alexandre Petrescu'; [email-masked]
>>>>t

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Mon, 9 Oct 2017 15:25:18 +0000

Hi Alex,

I agree with you this is a special type of wireless link and you need to
characterize it. But, I am not so sure about the assumptions that we need
special multicast groups. A node operating in this media has to confirm to
the standard IPv6 operation and in that sense its like any other IPv6 node.

It is mandatory for IPv6 nodes to participate in certain default multicast
groups, such as ALL_NODES, SOLICITED_NODES ..etc, which are essential for
Neighbor Solicitation/Neighbor Advertisement messages used in DAD and
other operations. Note that even if you define a new MC group, one can
give the same argument on non-participation of the node in that group.

With regards, to the success/reliability, there is no guarantee that there
is no loss on other types of links either. You  may have to optimize some
timers/parameters, but it may not be good idea to start treating them as
special nodes from IP perspective.

Sri

---

From: Jérôme Härri <[email-masked]>
Date: Mon, 9 Oct 2017 18:24:55 +0200

Hi Sri,

Following your e-mail, listing the OCB services absent from the WiFi
services is quite simply (I might not be exhaustive) and could emphasize a
bit more the contribution of this document...

1) no authentication connection (any packet coming from the lower layer has
not be authenticated) - any layer above IPv6 cannot assume the legitimacy of
an IPv6-over-OCB packet as such...e.g. any higher layer IPv6-based service
should start with an authentication of the transaction (opposed to the
authentication of the link)...

2) no beacon (BSS), which implies a lot of absent services that might be
important to upper layers
    - no power management  -  I guess not important to IP...
 
   - no time synchronization - we might need to explicitly ask to use OCB
TSF message, or evaluate the impact of an IPv6 packet with non-coherent (a
neighbor with a timer ahead of yours) timing in any of the IPv6 stack  
    - no channel 'quality' report - L2 congestion control is not done, so
IPv6-based services should do this...IPv6 packets should therefore report L2
channel quality in some ways...
	- btw, ETSI enforces that access to ITS-G5 band has 'some kind of'
distributed congestion control (no matter at which level)...
    
    - no indication when an L2 'link' is established (which would trigger a
L3 mechanism...in WiFi: Association Response - Success) - impact on IPv6?
Maybe IPv6 should then be proactive, e.g. with a triggered Neighbor
Solicitation (might be simple, but might be worth explicitly mentioning it)

    - no QoS parameters (EDCA queues parameters per channel) - a default can
be provided, but IPv6 should allow such dynamic configuration; I think the
IPv6 traffic profile can include such information, but that could require
some kind of service negotiation

    - ...(certainly more that I missed)

Would it help to be more explicit as such? 

BR,

Jérôme

-----Original Message-----
From: its [mailto:[email-masked]] On Behalf Of Sri Gundavelli
(sgundave)
Sent: Monday 09 October 2017 17:24
To: [email-masked]; 'Alexandre Petrescu'; [email-masked]
Subject: Re: [ipwave] WGLC for draft-ietf-ipwave-ipv6-over-80211ocb-08 -
multicast request

Hi Dick,

I agree with you on the design principles of layering and the need for
lower-layers to be hidden from the higher-layers. I absolutely agree with
it. But, the minimal requirement from IP perspective is to ensure the
services provided by the lower-layers are consistent. The question here and
largely the key theme in all the current discussions in this group is just
about that. So, the key question is the following:

Will an 802.11 node (with the flag dot11OCBActivated set to TRUE), aka
802-11-OCB node provide the same set of layer-2/lower level services as any
other 802.11 (dot11OCBActivated set to FALSE) node with Ethernet adaptation
layer, to the upper IPv6 layer?  If there is no difference, then all the
discussion on special multicast groups/security/radio characteristics is
largely irrelevant for this specification. We certainly may have to optimize
ND for certain reasons, or have special considerations for security to meet
the link characteristics, but from IP operation perspective we should not
require any special semantics here for
IPv6 operation. An IPv6 node operating on this type of radio link should
behave the same way as in any other link-layer technology/media.

Sri

On 10/6/17, 12:39 PM, "Dick Roy" <[email-masked]> wrote:

>Sri,
>
>I feel your pain:^))) People are using terms that have different 
>meaning depending on the layer one comes from! L3 links are not the 
>same as L2 links, and that can and does cause confusion.  When I use 
>the term link, I try to preface it with the layer if it is not clear from
the context, e.g.
>As for " having hard time building a second floor, without making sure 
>how the first floor looks", I can sympathize somewhat.  It's always a 
>bit easier designing to something concrete.  However, the beauty and 
>utility of the OSI (7-layer) Model is that knowledge of the details of 
>how the lower layers function is not/should not be necessary/critical 
>in designing a protocol that makes use of the services provided by 
>those lower layers. It's the generic properties of the lower layer 
>protocols instead that can be of interest, things such as acknowledged 
>versus unacknowledged, fragmentation and reassembly (FAR) versus 
>no-FAR, etc..
>
>Cheers,
>
>RR
>
>- multicast request
>In one sense, we are back to the question of link models. If you look 
>at RFC2461/4861, starting point for IPv6/ND, is a link. There are a 
>notion of link, a router, a hosted prefix and a set of IPv6 nodes which 
>are integral to that link.  When a packet is sent to a ALL_NODES group, 
>every node in that link will receive it. When a packet is sent to 
>ALL_ROUTERS group, all routers will receive it. In 802.11 infra mode, 
>all of that is somewhat preserved with the AP acting as a switch and 
>preserving all the semantics needed for the IPv6 link model.  But, here 
>its somewhat vague and because we never closed that discussion on link 
>models properly. May be its all clear especially for the IEEE 1609 guys 
>(as you have built L1/L2 ..), but for me, its bit hazy; each of us with 
>a different understanding and so these debates.
>
>I understand the comments, that we should ignore the lower-layers and 
>just focus on IP, but I am having hard time building a second floor, 
>without making sure how the first floor looks.
>
>
>Sri
>
> 
>
>
>
>>group address for a non-existent entity is a waste of an address and 
>>simply a bad idea!
>>
>>is technically unsound to say the least, and a "recipe for disaster".
>>
>>want to go.  I will continue to recommend that OCB is dropped from the 
>>document altogether. It is a "red herring"!
>>
>>Cheers,
>>
>>RR    
>>
>>- multicast request
>>OBY9s and RSU9s participate, why do we need a new group?
>>
>>
>>
>>>Group ID signifies 3All 80211OCB Interfaces Address".
>>
>>
>>
>>
>>
>>
>>Regards
>>Sri
>>
>>
>>
>>
>>>Le 02/10/2017 ` 18:50, Margaret Cullen a icrit :
>>>[...]
>>>
>>>> In Section 7:  I think you are attempting to allocate a 3Link-Local 
>>>> Scope Multicast Address2 from the 3IPv6 Multicast Address Space 
>>>> Registry2, which you can find here:
>>>>

---

From: Abdussalam Baryun <[email-masked]>
Date: Mon, 9 Oct 2017 22:30:44 +0200

> for me, its bit hazy; each of us with a different understanding and so

I agree totally

> making sure how the first floor looks.

It was ok in past to do ignorance but not for ITS medias,

---

From: Abdussalam Baryun <[email-masked]>
Date: Mon, 9 Oct 2017 23:19:50 +0200

On Mon, Oct 9, 2017 at 4:32 PM, Carlos Jesús Bernardos Cano <[email-masked]

> 80211OCB Interfaces Address".

We need it for ipwave nodes or ITS/ipwave interfaces, we don't need to
consider mac protocol types,

> specific to a type of physical interface.

Yes not specific to a type of interface but specific to the type of
ITS-services such interfaces are working on. You may have two-same ITS
interfaces with one-diff-interface in your car and I have three
diff-interface in my car. The wireless connections in ITS mobile
environment is not stable, so you MUST use two different interfaces to make
better connection with me and also better quality of service (while we have
similar different interfaces).

---

From: Russ Housley <[email-masked]>
Date: Mon, 9 Oct 2017 17:24:35 -0400

AB:

> We need it for ipwave nodes or ITS/ipwave interfaces, we don't need to consider mac protocol types, 

I do not understand the point you are trying to make.

The only thing we need to handle in this specification is IPv6 datagrams over IEEE 802.11-OCB.  It seems to me that an Ethertype is an very reasonable approach to distinguishing IPv6 datagrams from any other traffic that might be using the same MAC protocol.

Russ

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Tue, 10 Oct 2017 02:31:03 +0000

Hi Jerome,

Thanks for capturing these key points. Please see inline on my comments:

On 10/9/17, 9:24 AM, "Jérôme Härri" <[email-masked]<mailto:[email-masked]>> wrote:

Hi Sri,

The vulnerability that this specific issue brings is around Mac spoofing / IP hijacking.  The protocol that is impacted with this issue is truly Neighbor Discovery Protocol (NDP) and not IPv6. IPv6 relies on NDP for discovery of other IPv6 nodes on the link, for resolving link-layer addresses and performing other operations such as duplicate address detection & router discovery.

Generally, this issue is not unique to this specification, as a classic Wi-Fi client attached to an open access Wi-Fi network (with no auth) will have the same issue as any node attached to that access network can spoof the Mac/IP and hijack the session.

The review comment that I provided for the Security Section was to include some discussion on Mac Spoofing / IP address hijacking. I think that should be sufficient, IMO.

None of the above aspects has any impact on IPv6 protocol operation.

This has an impact on number of protocols including IPv6, socket interfaces, router discovery (RS/RA), address configuration/roaming (DHCP), Mobile IP/IPSec and on other protocols. If I remember correctly, the initial Wi-Fi implementations suffered from similar issues. IPv6 roaming in many implementations did not work for a long time, as the drivers were not getting triggers when the client moves between AP’s. If the L2 “link established” trigger is not seen by IPv6, then it will not know when to send the RS message to discover the routers/prefixes on the link. We also need to identify all the protocols that are impacted with this issue.

No specific impact to IPv6, but I guess, this pretty much takes away the WMM/WMM-AC support. IMO, the QoS study is a separate topic.

If these are the only issues, we should easily be able to close this spec. As I suggested many times, ND / link-models / address configuration ..etc is out of scope for this draft. That pretty much makes even the ND multicast group allocation discussion out of scope for this document as that is ND discussion. However, this spec does need to talk about how the stack maps an  IPv6 address to a multicast destination (in an IPv6 packet) to the link-layer multicast/unicast address. That general explanation needs to be present. Other than that, we hide all lower layer discussions from this spec.

Regards
Sri

BR,

Jérôme

-----Original Message-----
From: its [mailto:[email-masked]] On Behalf Of Sri Gundavelli
(sgundave)
Sent: Monday 09 October 2017 17:24
To: [email-masked]<mailto:[email-masked]>; 'Alexandre Petrescu'; [email-masked]<mailto:[email-masked]>
Subject: Re: [ipwave] WGLC for draft-ietf-ipwave-ipv6-over-80211ocb-08 -
multicast request

Hi Dick,

Sri

On 10/6/17, 12:39 PM, "Dick Roy" <[email-masked]<mailto:[email-masked]>> wrote:

Sri,

Cheers,

RR

-----Original Message-----
From: Sri Gundavelli (sgundave) [mailto:[email-masked]]
Sent: Friday, October 6, 2017 11:03 AM
To: [email-masked]<mailto:[email-masked]>; 'Alexandre Petrescu'; [email-masked]<mailto:[email-masked]>
Subject: Re: [ipwave] WGLC for draft-ietf-ipwave-ipv6-over-80211ocb-08
- multicast request

In one sense, we are back to the question of ?link models?. If you look

Sri

On 10/6/17, 10:39 AM, "Dick Roy" <[email-masked]<mailto:[email-masked]>> wrote:

Cheers,

RR

-----Original Message-----
From: its [mailto:[email-masked]] On Behalf Of Sri Gundavelli
(sgundave)
Sent: Friday, October 6, 2017 9:51 AM
To: Alexandre Petrescu; [email-masked]<mailto:[email-masked]>
Subject: Re: [ipwave] WGLC for draft-ietf-ipwave-ipv6-over-80211ocb-08
- multicast request

Hi Alex,

Regards
Sri

On 10/6/17, 9:40 AM, "its on behalf of Alexandre Petrescu"
<[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

https://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multi
cas

Alex

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Tue, 10 Oct 2017 02:52:08 +0000

Hi Dick,

> layer 3 functions should not and logically can not “ensure” anything about the lower layer services.

I am  not so sure about this.  QoS may not be such a good example here.  Lets take another example.

Any time a client attaches to a new link, there is desire for the node to quickly discover the routers, prefixes on the link. So, it can configure a link-local address, a global address and assert its ownership on that address. This is key consideration from the point of view of roaming, address configuration latency  and other aspects. Now, if the layer below does not send a trigger when the link comes up (per Jerome’s comment), that has an impact to the base IPv6 protocol and number of other protocols. So, in that sense we need to know any “special” behavior that the layer below brings which IPv6 layer was not designed for. The document is expected to identify those aspects, IMO. All other discussions on lower-layers can be hidden and I agree with you.

> That said, the only real difference between the two modes you cite above is that in OCB-mode there is no TSF sync, authentication or association which in turn means that 802.11 security functions (WPA, etc.)are not available.

These aspects should not impact IPv6 operation (keeping NDP out).

> As for security, since use cases for MAC-SEC have yet to be developed (application security is deemed sufficient and more appropriate), the lack of MAC-SEC does not seem to be important.

Ok. We just need to capture this aspect in the security section on the vulnerability that this brings to IPv6 and specifically to NDP. But, I agree this has no impact to IPv6 operation (ignoring NDP).

> [RR] Not sure what you mean here.  I can easily imagine that an IPv6 node on a fixed, wired LAN (e.g. Ethernet) executes (possibly) different IPv6 functions at different rates in order to maintain connectivity than the same node in an OBU flying down the freeway.

My comment was more on how to optimize ND for this environment. For example, protocol settings in RFC 4861, Section 10, are they applicable here, or we need to change the default values?

            MAX_INITIAL_RTR_ADVERT_INTERVAL  16 seconds

            MAX_INITIAL_RTR_ADVERTISEMENTS    3 transmissions

            MAX_FINAL_RTR_ADVERTISEMENTS      3 transmissions

            MAX_ANYCAST_DELAY_TIME            1 second

            MAX_NEIGHBOR_ADVERTISEMENT        3 transmissions

Regards
Sri

From: Dick Roy <[email-masked]<mailto:[email-masked]>> on behalf of Dick Roy <[email-masked]<mailto:[email-masked]>>
Organization: SRA
Reply-To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Monday, October 9, 2017 at 2:27 PM
To: Sri Gundavelli <[email-masked]<mailto:[email-masked]>>, 'Alexandre Petrescu' <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [ipwave] WGLC for draft-ietf-ipwave-ipv6-over-80211ocb-08 - multicast request

-----Original Message-----
From: its [mailto:[email-masked]] On Behalf Of Sri Gundavelli (sgundave)
Sent: Monday, October 9, 2017 8:24 AM
To: [email-masked]<mailto:[email-masked]>; 'Alexandre Petrescu'; [email-masked]<mailto:[email-masked]>
Subject: Re: [ipwave] WGLC for draft-ietf-ipwave-ipv6-over-80211ocb-08 - multicast request

Hi Dick,

services provided by the lower-layers are consistent.

[RR] Not to pick nits, but layer 3 functions should not and logically can not “ensure” anything about the lower layer services.  They can “request” a certain QoS, but they can not “ensure” it.  From the IP perspective, the layer 3 services it provides to layer 4 can in some sense be conditioned upon the lower layers providing a specified level of service, and upper layers can either accept the problems when the occur, or do something to address those problems.  This is how the layered model functions.

The question here

adaptation layer, to the upper IPv6 layer?

[RR] There is no “Ethernet adaptation layer”.  There is an LLC sublayer in which currently, according to 802 specs, either LPD or EPD is used.  Perhaps you mean EPD in the LLC sublayer, or you mean the requirement to translate from LPD to EPD and vice versa when 802.11 links are used in conjunction with Ethernet links in mixed LANs.  Either way, it’s not relevant to the current discussion.

That said, the only real difference between the two modes you cite above is that in OCB-mode there is no TSF sync, authentication or association which in turn means that 802.11 security functions (WPA, etc.)are not available.

If there is no difference,

characteristics is largely irrelevant for this specification.

[RR] Not sure about special multicast groups since that IS in the purview of IP(v6).  As for security, since use cases for MAC-SEC have yet to be developed (application security is deemed sufficient and more appropriate), the lack of MAC-SEC does not seem to be important.  As for radio characteristics, they are largely responsible for the rapidly changing network topology, and as such, determine to some extent the performance requirements of the L3 IPv6 functions required to maintain connectivity so I am not sure what you mean by them being irrelevant.

We certainly

[RR] Not sure what you mean here.  I can easily imagine that an IPv6 node on a fixed, wired LAN (e.g. Ethernet) executes (possibly) different IPv6 functions at different rates in order to maintain connectivity than the same node in an OBU flying down the freeway.

RR

Sri

>>This insistence on 802.11OCB is taking the group place it does not want

>>to

its mailing list

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 10 Oct 2017 12:57:08 +0200

Le 10/10/2017 à 04:52, Sri Gundavelli (sgundave) a écrit :
[...]
> This is key consideration from the point of view of roaming, address
> configuration latency  and other aspects. Now, if the layer below
> does not send a trigger when the link comes up (per Jerome’s
> comment), that has an impact to the base IPv6 protocol and number of
> other protocols. So, in that sense we need to know any “special”
> behavior that the layer below brings which IPv6 layer was not 
> designed for. The document is expected to identify those aspects,
> IMO.

Sri,

About the need of triggers when link comes up.  This is the handover 
discussion.  It is about TSA (an 802.11 message), RA, WRA and 802.21. 
We said earlier we are not going to include the handover discussion in 
this IPv6-over-OCB draft.  One can see that handover text in an earlier 
version of the draft:

https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-00#page-15

Alex

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Tue, 10 Oct 2017 13:11:26 +0000

Hi Alex,

Ok!

In addition to roaming/handover, it affects the base ND/IPv6 operation.
The stack will have no trigger on when to send a RS message on the link,
as there is no If-UP event.

IMO, this document should point out to some of the key differences/missing
features in the lower-layers when compared to the classic 802.11 based
stack (with the flag OFF). You should keep ND/MIPv6 and other protocol
discussion out of scope, but those aspects around feature differences are
in scope, IMO. 

Regards
Sri

On 10/10/17, 3:57 AM, "Alexandre Petrescu" <[email-masked]>
wrote:

>> does not send a trigger when the link comes up (per Jerome¹s
>> other protocols. So, in that sense we need to know any ³special²

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 12 Oct 2017 14:08:37 +0200

Sri,

Le 09/10/2017 à 17:25, Sri Gundavelli (sgundave) a écrit :
> special multicast groups.

Given the current discussion I will remove the multicast group request 
in the version -10 of the draft.

> A node operating in this media has to confirm to

I agree with you.

A computer with OCB interface must be able to use the existing groups 
like any other IPv6 node.

But, again, have you looked at Babel, or at DHCPv6-PD?

These protocols are run on Routers.  These Routers do not use 
"All-Routers" multicast addresses, but rather "All-DHCPV6-Servers" or 
"All-Babel-Routers".

If in the future we define some protocol for prefix exchange between two 
cars, then it could make sense to define also "All-OCB-interfaces".

So at this time I set this aside for future discussion, unless someone 
complains.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 12 Oct 2017 14:40:24 +0200

> <xref target="fig:figure_foo" />

Thanks for this hint, I included details for figures.

Alex

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Thu, 12 Oct 2017 14:43:57 +0000

Hi Alex,

Ok! Thanks for removing that multicast discussion.

>like any other IPv6 node.

Yes.

>“All-Routers” multicast addresses, but rather "All-DHCPV6-Servers" or
>"All-Babel-Routers".

I have not looked Babel and I do not know the operating environment of
Babel. But, regards to DHCP-PD and the question on why there is
“All-DHCPv6-Server group”, I think it is needed because we do not make any
assumption that DHCPv6 server can only run on IPv6 routers, it can be run
on an IP host with a single interface and with IP Routing turned off.

The same argument does not apply to 802.11-OCB group. OCB is not a
service, its a type of media and when IPv6 is enabled on a node with
802-11-OCB interface, the base IPv6 property is not going away and all the
currently defined groupings are sufficient. Also, I cannot imagine a
scenario where a group of nodes with 802-11-OCB interface and a group of
nodes with classic 802-11 interface co-exist on the same IPv6 Layer-2
segment (aka link). If such a possibility exists, then I can understand
the need for such special groups, but I do not see such a requirement here.

Sri

On 10/12/17, 5:08 AM, "its on behalf of Alexandre Petrescu"
<[email-masked] on behalf of [email-masked]> wrote:

>>>>>>>ca
>>>>>>> st

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 12 Oct 2017 16:48:24 +0200

Hi Abdussalam,

I moved the reference to the tsvwg draft to the Informative References 
section.

It will appear in the future -11 version of the draft.

Alex

Le 09/10/2017 à 02:46, Abdussalam Baryun a écrit :
> reference, and regarding I-D.ietf-tsvwg-ieee-802-11, I suggest to make 
> it informative. However, I am not expert in rfc3967 but if our

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 12 Oct 2017 16:53:17 +0200

Le 08/10/2017 à 23:56, Abdussalam Baryun a écrit :
> Hi Alex,
> 
> I know the referencing is a minor issue, but it did confuse my reading 
> and understanding of objectives.
> 
> On Fri, Oct 6, 2017 at 7:29 PM, Alexandre Petrescu 
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> 
>         Yes we may welcome when needed, but I think the doc is
>         referencing as a survey but please note this is not a
>         survey/informational doc.
> 
> 
>     I am still not convinced about removing that.  That
>     survey/informational is looking at joining with the problem
>     statement drafts.  At that point it would make sense to refer to
>     them, unless you disagree.
> 
> 
> any way that was my opinion to remove any extra and not needed info and 
> non adopted drafts. I respect your opinion. However, we need to focus 
> our draft to its objective with less as possible literature overview.

I agree with you.

However, the references that are individual submissions are not 
literature overview.  The literature overview is just one part of one of 
the references, which is now a WG item 
(draft-ietf-ipwave-vehicular-networking-survey); despite the filename 
that suggests "survey" I think it will also contain problem statement, 
scenarios, and probably more.

The individual submission drafts are now two: draft-perkins and 
draft-hinden.

The draft-perkins is probably the only place that could help clarifying 
with the multicast discussion.  Until that is clarified I removed the 
request for a new multicast group.

The draft-hinden is probably the only place that could help clarifying 
the fe80::/10 vs fe80::/64 nit.  Until that is clarified I propose we 
discuss on this email list about this nit.  Can you help?

Alex

>     There are a three other individual submission documents that we
>     refer to.  I believe they are necessary at this time.
> 
>     draft-perkins-intarea-multicast-ieee802: a good starting point for
>     WiFi problems on multicast.  If no other reference, then I keep I.
> 
> 
> I agree its ok,
> 
> 
>     draft-petrescu-its-scenarios-reqs: it's because we need to tell in
>     this draft what kinds of scenarios we look at (the vehicular
>     scenarios).  If there is some other RFC or draft that describes the
>     scenarios then I can put that instead.
> 
> ok
> 
> 
>     draft-hinden-6man-rfc2464bis: it's because it's the only little try
>     to update rfc2464 at this time.  If it gets adopted in 6man then it
>     will be fine.
>

---

From: Russ Housley <[email-masked]>
Date: Thu, 12 Oct 2017 15:27:03 -0400

Alex:

> If in the future we define some protocol for prefix exchange between two cars, then it could make sense to define also "All-OCB-interfaces".
> 
> So at this time I set this aside for future discussion, unless someone complains.

If we were to assign such a multicast group, it should be All-IPv6-over-OCB.  There are obviously other protocols using the OCB interface in other ways.

Russ

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 13 Oct 2017 15:52:00 +0200

Le 12/10/2017 à 16:43, Sri Gundavelli (sgundave) a écrit :
>> A computer with OCB interface must be able to use the existing
>> groups like any other IPv6 node.
> 
> Yes.
> 
> 
>> But, again, have you looked at Babel, or at DHCPv6-PD? These
>> protocols are run on Routers.  These Routers do not use 
>> “All-Routers” multicast addresses, but rather "All-DHCPV6-Servers"
>> or "All-Babel-Routers".
> 
> 
> I have not looked Babel and I do not know the operating environment
> of Babel. But, regards to DHCP-PD and the question on why there is 
> “All-DHCPv6-Server group”, I think it is needed because we do not
> make any assumption that DHCPv6 server can only run on IPv6 routers,
> it can be run on an IP host with a single interface and with IP
> Routing turned off.

Sri, your reasoning does not hold.

You are saying that DHCPv6 Servers could be Hosts, instead of Routers.
But there is already a multicast group with link scope called
"all-hosts".  Why DHCPv6 is not using it?  Why DHCPv6 creates a new
group called "all-dhcpv6-servers"?

Alex

---

From: Tony Li <[email-masked]>
Date: Fri, 13 Oct 2017 07:29:36 -0700

> On Oct 13, 2017, at 6:52 AM, Alexandre Petrescu <[email-masked]> wrote:
> 

Because the all-hosts group might not encompass routers that are providing DHCP.

Again, the best reason to assign a group is when a subset of the nodes on the media are providing a service. Then a group makes sense as it can help delineate the receivers for requests for the service.

If the set of nodes being addressed is “everything on the media” then you might as well just broadcast. If the set of nodes being addressed matches one of the other existing groups, then there’s no point in not using one of the existing groups.

Tony

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 13 Oct 2017 19:00:57 +0200

Le 13/10/2017 à 16:29, Tony Li a écrit :
> 
>> On Oct 13, 2017, at 6:52 AM, Alexandre Petrescu 
>> <[email-masked]
>> <mailto:[email-masked]>> wrote:
>> 
>> You are saying that DHCPv6 Servers could be Hosts, instead of
>> Routers. But there is already a multicast group with link scope
>> called "all-hosts".  Why DHCPv6 is not using it?  Why DHCPv6
>> creates a new group called "all-dhcpv6-servers"?
> 
> 

But for that there is the "all-routers" group.

And, there is also the "all-nodes" group; it means both Hosts and
Routers.  Why DHCPv6 does not use the "all-nodes" group?

Do you think there can be a DHCPv6 Server that is not an IPv6 Node?

> Again, the best reason to assign a group is when a subset of the
> nodes on the media are providing a service. Then a group makes sense
> as it can help delineate the receivers for requests for the service.

I can agree.

> If the set of nodes being addressed is “everything on the media” then
>  you might as well just broadcast.

But we cant use broadcast in IPv6.  Only multicast.

Alex

> If the set of nodes being addressed matches one of the other existing
> groups, then there’s no point in not using one of the existing
> groups.
> 
> Tony
>

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Fri, 13 Oct 2017 17:06:38 +0000

Alex:

There are many good people (both men and women), but not ALL men are good
and not ALL women are good. So, we need a ³Good people² group, which has
both men and women and that is ³All DHCP Server² group :)

I am sure, IETF police will ticket me for this. But, its Friday and so its
fine..

On serious note, we may need that special OCB-Only group, if we can think
of heterogeneous links with OCB and non-OCB nodes. But, we need to close
link model and other discussions first. For now, we can park this, IMO.

Sri

On 10/13/17, 10:00 AM, "Alexandre Petrescu" <[email-masked]>
wrote:

>> If the set of nodes being addressed is ³everything on the media² then
>> groups, then there¹s no point in not using one of the existing
>> groups.
>> 
>> Tony
>>

---

From: Tony Li <[email-masked]>
Date: Fri, 13 Oct 2017 10:07:29 -0700

> But for that there is the "all-routers" group.

There’s no guarantee that all of the routers are providing DHCP either.

> Routers.  Why DHCPv6 does not use the "all-nodes" group?

The whole point is to get the mcast packet to the nodes where it’s supposed to go and ONLY the nodes where it’s supposed to go.

> But we cant use broadcast in IPv6.  Only multicast.

Please speak to the v6 people about the bug. ;-)

Tony

---

From: Sara el hamdani <[email-masked]>
Date: Tue, 17 Oct 2017 11:15:53 +0100

Dear Carlos, ALL

I support this draft in its current form.

-- 
*Best regards*

*Sara EL HAMDANI*
*Phd student -Umi University.*

---

From: Abdussalam Baryun <[email-masked]>
Date: Fri, 20 Oct 2017 08:20:02 +0200

> discussion out of scope, but those aspects around feature differences are

+1

AB

> >https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-
> 80211ocb-00#page-1
> >5
> >
> >Alex
>

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Mon, 23 Oct 2017 16:09:57 +0200

Hi,

The WGLC of this document is now over. We got good support from the WG
on progressing the document, but we also received quite a lot of good
feedback on it. Therefore, we would like the authors to provide a
comprehensive summary on the mailing list with all the
comments/suggestions received, together with a response on how these
have been addressed, highlighting any points that are still unresolved.

Thanks!

Carlos and Russ

P.S.: We have updated the status of the document in the datatracker.