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

From: "Kevin Smith" <[email-masked]>
Date: Fri, 16 Mar 2018 10:34:30 -0700

Hi Alex,

Thanks for the feedback. I have a few comments - but please keep in mind
that these comments and opinions are my own and not necessarily those of the
1609 WG at large. I do not have the authority for speak for the WG, I'm just
the editor. ;)

My comments are inline denoted by [KS]. And please also seem some *new
comments* below regarding EAL and "standard Ethernet packets".

Best regards,
Kevin

-----Original Message-----
From: its [mailto:[email-masked]] On Behalf Of Alexandre Petrescu
Sent: Thursday, March 15, 2018 11:23 AM
To: Kevin Smith <[email-masked]>
Cc: Tijink Jasja <[email-masked]>; [email-masked]
Subject: Re: [ipwave] ipwave - comments and concerns - 1609 WAVE, EPD -
towards resolution

Hi Kevin,

Kevin wrote recently:
> Dear IETF ipwave working group,
> 
> 
> 
> My name is Kevin Smith, I am the technical editor for IEEE Std 1609.3 
> and a few others in the 1609 family of standards. I have some concerns 
> regarding ipwave's interoperability with 1609 WAVE, and a question 
> regarding the need or purpose for ipwave.

Generally speaking, the purpose of ipwave WG is set in the Charter.
(https://datatracker.ietf.org/wg/ipwave/about/)

> 1.       If ipwave is intended to be interoperable with 1609 WAVE, 
> then ipwave must specify the use of EtherType Protocol Discrimination
> (EPD) in the LLC sublayer header, i.e., EPD is mandatory.

We should interoperate to a maximum.
[KS]: Agreed!

I suggest that in section 4.2.1 "Ethernet Adaptation Layer" we add the
following paragraph:

> The IPv6 packet transmitted on 802.11-OCB MUST be immediately preceded 
> by a Logical Link Control (LLC) header and an 802.11 header.
> In the LLC header, and in accordance with the EtherType Protocol 
> Discrimination (EPD), the value of the Type field MUST be set to 
> 0x86DD (IPv6).  In the 802.11 header, the value of the Subtype 
> sub-field in the Frame Control field MUST be set to 8 (i.e. 'QoS 
> Data'); the value of the Traffic Identifier (TID) sub-field of the QoS 
> Control field of the 802.11 header MUST be set to binary 001 (i.e.
> User Priority 'Background', QoS Access Category 'AC_BK').
> 
> In the Ethernet II header, the value of the Type field MUST be set to 
> 0x86DD (IPv6).

Do you agree with this text?

[KS]: I agree with the part that addresses the LLC header. I don't disagree
with the part addressing the 802.11 header, I'm just not an expert in this
area and so defer to others. I believe that others in the 1609 WG have been
discussing this with the ipwave list? 

> I note that ipwave mentions EPD, but also SNAP and does not specify 
> which method to use.

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

Do you agree?

[KS]: Yes.

> Moreover ipwave discusses an abstract "Ethernet Adaptation Layer"
> but does not specify a header format, and this further confuses the 
> question for deployers - what should we implement?

The Ethernet Adaptation Layer (more precisely 802.11-to-Ethernet AL) is not
so abstract, because it is widely implemented. This layer does conversion
between headers: at reception from the network it transforms a .11/LLC
header into an EthernetII header; reversely, at sending it transforms an
EthernetII header into a .11/LLC header. This is shown in Figure 1.

The EAL does not intend to specify a header format. The header formats
involved are the IEEE 802.11, LLC and EthernetII. The fields in these
headers are specified by IEEE.

[KS]: I don't understand why the EAL is relevant to "Transmission of IPv6
Packets over IEEE 802.11 Networks operating in mode Outside the Context of a
Basic Service Set". If I want to write software that sends IPv6 packets over
802.11 OCB, all I need to know is how to construct the LLC sublayer header,
etc. The EAL sounds like a "bridge", and perhaps belongs in a separate
document (and perhaps has already been addressed in some existing document?)
Regardless, including a description of the EAL does not violate anything in
1609.3, as it is out of scope with 1609.3. 

Some *new comments* from my side:

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

- ipwave 4.2 it states "IP packets are transmitted over 802.11-OCB as
standard Ethernet packets. As with all 802.11 frames, an Ethernet adaptation
layer MUST be used with 802.11-OCB as well." Again EAL is stipulated as a
requirement. And I'm not sure about the stipulation that packets are
transmitted as "standard Ethernet packets", is this accurate? Does this mean
that 802.3 headers are included? This is definitely not stipulated in
1609.3. Packets transmitted over OCB by a WAVE device using 1609.3 are well
formed IPv6 packets, but not "Ethernet packets", i.e., no 802.3 headers are
included. This seems like an interoperability problem between ipwave and
1609 WAVE.

> 2.       It is not clear that ipwave provides any functionality that
>  1609 WAVE does not already provide.

Well, 1609 WAVE does not specify the conversion between .11/LLC headers and
EthernetII headers, right?

[KS]: Correct it does not, as this topic is out of scope for 1609 WAVE
(e.g., we don't specify the other interfaces such as Ethernet that may be
present in the device). Also see my comments above regarding the EAL.

1609 WAVE does not specify the MTU size for IPv6, right?

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

1609 WAVE does not specify that IPv6 must be preceded by .11 QoSData (not
just .11 Data), and BACKGROUND, right?

[KS]: Certainly 1609 does not. 1609 only restricts IPv6 packets to the SCH
(they are not allowed on the CCH). 802.11 specifies defaults for all UP and
AC parameters, indicates which frame types are allowed, etc. But as far as I
can tell the stipulation that IPv6 use QoSData and AC_BK is new and
something that ipwave introduces? Again, I'm not an expert on this topic and
I believe others in the 1609 WG have been discussing this with the ipwave
list. Regardless, this additional restriction does not violate 1609.3.

1609 WAVE does not recommend in particular RFC8064 to form semantically
opaque Interface Identifiers, right?

[KS]: 1609 does not recommend anything like this, but on the other hand 1609
does not prohibit it either. 1609 does not generally speaking "recommend",
rather it "specifies" and leaves all else up to the system
designer/implementer/deployer. And as mentioned previously, 1609 allows any
and all IETF protocols to be implemented. Regardless, this recommendation
does not violate anything in 1609.3.

(and a few others).

> 1609 WAVE includes a number of mechanisms that enable IPv6 networks to 
> be configured. In addition to the WSA/WRA mechanism, 1609.3 allows any 
> IETF protocols to be implemented, e.g., IETF RFC 4861, Neighbor 
> Discovery for IP Version 6 (IPv6) (which is listed as a normative 
> reference in 1609.3). Helpful would be some example use-cases that 
> illustrate problems to be solved, and how ipwave will solve those 
> problems (i.e., that 1609 WAVE does not already solve).

There is a draft that describes some use-cases of IPv6 in vehicular
networks: draft-ietf-ipwave-vehicular-networking-02

[KS]: Thanks for pointing me to that, lots of info there! I'll spend some
time reviewing that when I can.

I think some parts of 1609 WAVE, in particular WRA, are not used in Europe.
Whereas this IPv6-over-OCB draft is used the same wherever Internet is
present (Europe, America, Continents).

[KS]: 1609 went to great lengths to harmonize WSM and WSA frame formats with
ISO/ETSI standards, these harmonized frames are included in all of the -2016
revisions to 1609. So for example the 1609.3 WSA is interoperable with the
service advertisement used in Europe. See ISO 16460, and see also ETSI TS
102 890-1.

> My concern is that the IETF ipwave document may cause significant 
> confusion among deployers, and possibly lead to a lack of 
> interoperability. Thank you for the opportunity to comment, I look 
> forward to the discussion.

I would like to help with clarification. Let us discuss this.

[KS]: Sounds good! 

Alex

> Best regards,
> Kevin

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

---

From: Tijink Jasja <[email-masked]>
Date: Fri, 16 Mar 2018 18:02:10 +0000

Hello Alex,

in addition to Kevin's points, I  would like to mention that:

1. I welcome your proposal for the additional text that specifies QoS. This is necessary for operation in Europe (the specification for the access layer can be found in ETSI EN 302 663, where clause 4.6 says that QoS shall be used).

2. My understanding of the discussion below is that draft-ietf-ipwave-ipv6-over-80211ocb-21 is "based on" IEEE 1609.3 in that it is compliant with it (I didn't find any "violation of IEEE 1609.3), and adds additional restrictions and /or specifications (such a MTU size, AC_BK, RFC8064, etc.). In that sense draft-ietf-ipwave-ipv6-over-80211ocb-21 is a profile of IEEE 1609.3. I would suggest making that very clear, with a short sentence/paragraph in draft-ietf-ipwave-ipv6-over-80211ocb-21 that explains it to the reader. If you disagree, I would like to hear your view on the relation of IEEE 1609.3 and draft-ietf-ipwave-ipv6-over-80211ocb-21.

Best regards Jasja

-----Ursprüngliche Nachricht-----
Von: Kevin Smith [mailto:[email-masked]] 
Gesendet: Freitag, 16. März 2018 18:35
An: Alexandre PETRESCU <[email-masked]>
Cc: Tijink Jasja <[email-masked]>; [email-masked]
Betreff: FW: [ipwave] ipwave - comments and concerns - 1609 WAVE, EPD - towards resolution

Hi Alex,

Thanks for the feedback. I have a few comments - but please keep in mind that these comments and opinions are my own and not necessarily those of the
1609 WG at large. I do not have the authority for speak for the WG, I'm just the editor. ;)

Best regards,
Kevin

-----Original Message-----
From: its [mailto:[email-masked]] On Behalf Of Alexandre Petrescu
Sent: Thursday, March 15, 2018 11:23 AM
To: Kevin Smith <[email-masked]>
Cc: Tijink Jasja <[email-masked]>; [email-masked]
Subject: Re: [ipwave] ipwave - comments and concerns - 1609 WAVE, EPD - towards resolution

Hi Kevin,

[KS]: I agree with the part that addresses the LLC header. I don't disagree with the part addressing the 802.11 header, I'm just not an expert in this area and so defer to others. I believe that others in the 1609 WG have been discussing this with the ipwave list? 

Do you agree?

[KS]: Yes.

> question for deployers - what should we implement?

The Ethernet Adaptation Layer (more precisely 802.11-to-Ethernet AL) is not so abstract, because it is widely implemented. This layer does conversion between headers: at reception from the network it transforms a .11/LLC header into an EthernetII header; reversely, at sending it transforms an EthernetII header into a .11/LLC header. This is shown in Figure 1.

The EAL does not intend to specify a header format. The header formats involved are the IEEE 802.11, LLC and EthernetII. The fields in these headers are specified by IEEE.

[KS]: I don't understand why the EAL is relevant to "Transmission of IPv6 Packets over IEEE 802.11 Networks operating in mode Outside the Context of a Basic Service Set". If I want to write software that sends IPv6 packets over
802.11 OCB, all I need to know is how to construct the LLC sublayer header, etc. The EAL sounds like a "bridge", and perhaps belongs in a separate document (and perhaps has already been addressed in some existing document?) Regardless, including a description of the EAL does not violate anything in 1609.3, as it is out of scope with 1609.3. 

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

- ipwave 4.2 it states "IP packets are transmitted over 802.11-OCB as standard Ethernet packets. As with all 802.11 frames, an Ethernet adaptation layer MUST be used with 802.11-OCB as well." Again EAL is stipulated as a requirement. And I'm not sure about the stipulation that packets are transmitted as "standard Ethernet packets", is this accurate? Does this mean that 802.3 headers are included? This is definitely not stipulated in 1609.3. Packets transmitted over OCB by a WAVE device using 1609.3 are well formed IPv6 packets, but not "Ethernet packets", i.e., no 802.3 headers are included. This seems like an interoperability problem between ipwave and
1609 WAVE.

>  1609 WAVE does not already provide.

Well, 1609 WAVE does not specify the conversion between .11/LLC headers and EthernetII headers, right?

[KS]: Correct it does not, as this topic is out of scope for 1609 WAVE (e.g., we don't specify the other interfaces such as Ethernet that may be present in the device). Also see my comments above regarding the EAL.

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

1609 WAVE does not specify that IPv6 must be preceded by .11 QoSData (not just .11 Data), and BACKGROUND, right?

[KS]: Certainly 1609 does not. 1609 only restricts IPv6 packets to the SCH (they are not allowed on the CCH). 802.11 specifies defaults for all UP and AC parameters, indicates which frame types are allowed, etc. But as far as I can tell the stipulation that IPv6 use QoSData and AC_BK is new and something that ipwave introduces? Again, I'm not an expert on this topic and I believe others in the 1609 WG have been discussing this with the ipwave list. Regardless, this additional restriction does not violate 1609.3.

1609 WAVE does not recommend in particular RFC8064 to form semantically opaque Interface Identifiers, right?

[KS]: 1609 does not recommend anything like this, but on the other hand 1609 does not prohibit it either. 1609 does not generally speaking "recommend", rather it "specifies" and leaves all else up to the system designer/implementer/deployer. And as mentioned previously, 1609 allows any and all IETF protocols to be implemented. Regardless, this recommendation does not violate anything in 1609.3.

(and a few others).

[KS]: Thanks for pointing me to that, lots of info there! I'll spend some time reviewing that when I can.

I think some parts of 1609 WAVE, in particular WRA, are not used in Europe.
Whereas this IPv6-over-OCB draft is used the same wherever Internet is present (Europe, America, Continents).

[KS]: 1609 went to great lengths to harmonize WSM and WSA frame formats with ISO/ETSI standards, these harmonized frames are included in all of the -2016 revisions to 1609. So for example the 1609.3 WSA is interoperable with the service advertisement used in Europe. See ISO 16460, and see also ETSI TS
102 890-1.

[KS]: Sounds good! 

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Sat, 17 Mar 2018 12:22:51 +0100

Hello Jasja,

Le 16/03/2018 à 19:02, Tijink Jasja a écrit :
> 1. I welcome your proposal for the additional text that specifies 
> QoS. This is necessary for operation in Europe (the specification for
> the access layer can be found in ETSI EN 302 663, where clause 4.6
> says that QoS shall be used).

Noted.

> 2. My understanding of the discussion below is that 
> draft-ietf-ipwave-ipv6-over-80211ocb-21 is "based on" IEEE 1609.3 in
>  that it is compliant with it (I didn't find any "violation of IEEE 
> 1609.3), and adds additional restrictions and /or specifications 
> (such a MTU size, AC_BK, RFC8064, etc.). In that sense 
> draft-ietf-ipwave-ipv6-over-80211ocb-21 is a profile of IEEE 1609.3.
>  I would suggest making that very clear, with a short 
> sentence/paragraph in draft-ietf-ipwave-ipv6-over-80211ocb-21 that 
> explains it to the reader. If you disagree, I would like to hear your
> view on the relation of IEEE 1609.3 and 
> draft-ietf-ipwave-ipv6-over-80211ocb-21.

I dont really disagree, just where to put it.

The draft does refer to 1609.3, in Appendix C "aspects introduced by OCB
to 802.11".  The vehicular networking draft
(draft-ietf-ipwave-vehicular-networking-01) also refers to it right at
the beginning.

IPv6-over-OCB sounds like an explanation.  As such, I suggest we first
write more precisely that "IPv6-over-OCB is a profile of 1609.3" and
then put it into the vehicular networking draft.

How could that be written?

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Sat, 17 Mar 2018 13:10:07 +0100

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

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

Noted.

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

>> I note that ipwave mentions EPD, but also SNAP and does not
>> specify which method to use.
> 

Noted.

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

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

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

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

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

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

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

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

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

Noted.

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

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

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

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

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

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

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

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

YEs.

I verify it this way:

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

> Does this mean that 802.3 headers are included?

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

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

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

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

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

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

Noted.

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

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

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

It seems so.  People agree with it.

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

Noted.

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

I agree harmonization is good and needed.

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

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

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

Thank you for the comments.

Alex

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

---

From: Tijink Jasja <[email-masked]>
Date: Sat, 17 Mar 2018 12:22:31 +0000

Hello Alex,

Can we put something at the beginning of draft-ietf-ipwave-ipv6-over-80211ocb-21, maybe in the introduction?
I suggest some language like the following:

This document is a profile based on IEEE 1609.3: it introduces additional requirements and specifications that do not violate that base standard.

Regards Jasja

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

Hello Jasja,

Le 16/03/2018 à 19:02, Tijink Jasja a écrit :
> 1. I welcome your proposal for the additional text that specifies QoS. 
> This is necessary for operation in Europe (the specification for the 
> access layer can be found in ETSI EN 302 663, where clause 4.6 says 
> that QoS shall be used).

Noted.

> 1609.3), and adds additional restrictions and /or specifications (such 
> a MTU size, AC_BK, RFC8064, etc.). In that sense

The draft does refer to 1609.3, in Appendix C "aspects introduced by OCB to 802.11".  The vehicular networking draft
(draft-ietf-ipwave-vehicular-networking-01) also refers to it right at the beginning.

IPv6-over-OCB sounds like an explanation.  As such, I suggest we first write more precisely that "IPv6-over-OCB is a profile of 1609.3" and then put it into the vehicular networking draft.

Alex

---

From: Tijink Jasja <[email-masked]>
Date: Sat, 17 Mar 2018 12:37:01 +0000

Hi Alex,

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

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

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

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

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

Regards Jasja

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

>> preceded by a Logical Link Control (LLC) header and an 802.11 header. 
>> sub-field in the Frame Control field MUST be set to 8 (i.e.
>> 001 (i.e. User Priority 'Background', QoS Access Category 'AC_BK').
>> 

Noted.

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

Noted.

> is not so abstract, because it is widely implemented. This layer does 
> conversion between headers: at reception from the network it 

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

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

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

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

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

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

Noted.

> over OCB, and does not require "bridging", then how do I reconcile 

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

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

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

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

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

> standard Ethernet packets. As with all 802.11 frames, an Ethernet  

YEs.

I verify it this way:

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

> Does this mean that 802.3 headers are included?

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

> seems like an interoperability problem between ipwave and 1609 WAVE.

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

> (e.g., we don't specify the other interfaces such as Ethernet that may 
> be present in the device). Also see my comments above regarding the 
> EAL.

Noted.

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

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

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

> the system designer/implementer/deployer. And as mentioned previously, 
> 1609 allows any and all IETF protocols to be implemented.

Noted.

>> to be configured. In addition to the WSA/WRA mechanism, 1609.3 allows 
>> any IETF protocols to be implemented, e.g., IETF RFC 4861, Neighbor 

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

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

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

Alex

---

From: Tony Li <[email-masked]>
Date: Sat, 17 Mar 2018 12:50:56 +0000

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

I suspect that we’ll also get some push back on this sentence because it is implied to be normative.  Since the EAL doesn’t actually affect the bits on the air, this is simply an implementation choice and not strictly mandatory.

It would probably be easier if we relaxed the wording to make this informative or recommended instead.

Tony

---

From: Tijink Jasja <[email-masked]>
Date: Sat, 17 Mar 2018 12:54:40 +0000

I agree with Tony.

Regards Jasja

-----Ursprüngliche Nachricht-----
Von: Tony Li [mailto:[email-masked]] Im Auftrag von Tony Li
Gesendet: Samstag, 17. März 2018 13:51
An: Tijink Jasja <[email-masked]>
Cc: Alexandre Petrescu <[email-masked]>; Kevin Smith <[email-masked]>; [email-masked]
Betreff: Re: [ipwave] FW: ipwave - comments and concerns - 1609 WAVE, EPD - towards resolution

Tony

---

From: "Kevin Smith" <[email-masked]>
Date: Sat, 17 Mar 2018 12:25:55 -0700

Hi Alex,

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

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

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

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

Regards,
Kevin

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

Hi Alex,

Regards Jasja

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

Noted.

Noted.

Noted.

YEs.

I verify it this way:

Noted.

Noted.

Alex

---

From: "Kevin Smith" <[email-masked]>
Date: Sat, 17 Mar 2018 12:56:41 -0700

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

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

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

I appreciate the discussion.

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

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

Hi Alex,

Regards,
Kevin

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

Hi Alex,

Regards Jasja

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

Noted.

Noted.

Noted.

YEs.

I verify it this way:

Noted.

Noted.

Alex

---

From: "Kevin Smith" <[email-masked]>
Date: Sat, 17 Mar 2018 13:05:58 -0700

Hi Alex,

Thanks for the responses. I've responded separately regarding the "standard Ethernet packets" text, but had some other comments.

Additional comments follow denoted with *****[KS] to help you find them (as this email getting quite long). 

Thanks,
Kevin

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

Noted.

Noted.

*****[KS]: OK thanks for the explanation.

Noted.

*****[KS]: Sure, but if developers are re-using existing implementations they don't really need a standard, except to perhaps explain how it should have been implemented. The primary reason to have standards is to enable interoperability, and instructs those developing new (or perhaps debugging old) implementations as to how to create (or maintain) products that play well with others. 

*****[KS]: Bridging, is as you describe, e.g., bridging two distinct physical interfaces. What confuses me is your statement: "Here we would 'bridge' Ethernet and 802.11 on the same interface." This seems contradictory. The term "Ethernet" is widely used to describe wired Ethernet as described in IEEE 802.3. So "Ethernet" is one physical interface, and 802.11 is a different physical interface. But I'm starting to believe that this may be where we are crossing our wires, so to speak. 

***** What I'm gathering is that ipwave assumes that an Ethernet II frame will be received, and need to be "adapted" to an 802.11 frame format so that it may be transmitted 802.11-OCB. If this is the case, then perhaps the ipwave document is not clear enough about this. And again, I'm making an assumption here, but should the name of the document be titled something like "Adaptation of Ethernet II frames for Transmission of IPv6 Packets over IEEE 802.11 Networks operating in mode Outside the Context of a Basic Service Set"?

YEs.

I verify it this way:

*****[KS]: I've read that packet captures from Wireshark and tcpdump display frames received from 802.11 adapters this way, and they are referred to as "fake Ethernet" frames. This is a function of the software drivers apparently, and for some reason they deliver these "fake Ethernet" frames to capture software like Wireshark. If you use monitor mode then you get the "true" 802.11 frame representation of received frames, not the "fake Ethernet" frames. Monitor mode will show how the frames are actually received over the 802.11 interface, i.e., as 802.11 frames and not as Ethernet II frames.

*****[KS]: I understand, and this is good! But I think the current text is confusing things by stating that "standard Ethernet packets" are transmitted over 802.11-OCB (as I wrote about in a separate email).

Noted.

*****[KS]: Yes sounds like it, all good!

Noted.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Sun, 18 Mar 2018 17:15:33 +0100

Hi IPWAVErs,

Do you disagree we add this phrase in the Introduction:

> This document is a profile based on IEEE 1609.3: it introduces 
> additional requirements and specifications that do not violate that 
> base standard.

For my part I find addition of this text neutral and ok, although I am
not sure what is a profile for 1609 WAVE.  In Bluetooth, a 'profile' is
something very much precise, like 'LAN profile', etc.

Alex

Le 17/03/2018 à 13:22, Tijink Jasja a écrit :
> Hello Alex,
> 
> Can we put something at the beginning of 
> draft-ietf-ipwave-ipv6-over-80211ocb-21, maybe in the introduction?
> This document is a profile based on IEEE 1609.3: it introduces 
> additional requirements and specifications that do not violate that 
> base standard.
> 
> Regards Jasja
> 
> 
> -----Ursprüngliche Nachricht----- Von: Alexandre Petrescu 
> [mailto:[email-masked]] Gesendet: Samstag, 17. März 
> 2018 12:23 An: Tijink Jasja <[email-masked]> Cc: Kevin
> Smith <[email-masked]>; [email-masked] Betreff: Re: [ipwave]
> ipwave - comments and concerns - 1609 WAVE, EPD - towards resolution
> 
> Hello Jasja,
> 
>> QoS. This is necessary for operation in Europe (the specification 
>> for the access layer can be found in ETSI EN 302 663, where clause 
>> 4.6 says that QoS shall be used).
> 
> Noted.
> 
>> draft-ietf-ipwave-ipv6-over-80211ocb-21 is "based on" IEEE 1609.3 
>> in that it is compliant with it (I didn't find any "violation of 
>> IEEE 1609.3), and adds additional restrictions and /or 
>> specifications (such a MTU size, AC_BK, RFC8064, etc.). In that 
>> sense draft-ietf-ipwave-ipv6-over-80211ocb-21 is a profile of IEEE 
>> 1609.3. I would suggest making that very clear, with a short 
>>  explains it to the reader. If you disagree, I would like to hear 
>> your view on the relation of IEEE 1609.3 and 
> The draft does refer to 1609.3, in Appendix C "aspects introduced by 
> OCB to 802.11".  The vehicular networking draft 
> IPv6-over-OCB sounds like an explanation.  As such, I suggest we 
> first write more precisely that "IPv6-over-OCB is a profile of 
> 1609.3" and then put it into the vehicular networking draft.
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Sun, 18 Mar 2018 17:22:28 +0100

Le 17/03/2018 à 13:37, Tijink Jasja a écrit :
> I understand the second sentence is a requirement you put to
> implementations that feature an ethernet interface and an 802.11
> interface.

Well no, I do not want it to be understood that way.

"are transmitted" means: the packets are transmitted by the IPv6 stack 
to the driver.  In a computer there is userland, protocol stack, and driver.

But I agree with you it can be read as you say.

> But the first sentence: that one seems not true to me according to
> what you report of your own tests - 802.11 packets do not have
> ethernet headers. So the first sentence is incorrect, right? Or do I
> simply misunderstand it and what you want to say is:
> 
> "IP packets are transmitted over 802.11-OCB as over standard
> Ethernet:  as with all 802.11 frames, an Ethernet adaptation layer

I agree with you, it is the same misunderstanding.  It should be better 
written, without being too descriptive and still be normative.

Alex

> 2018 13:10 An: Kevin Smith <[email-masked]> Cc: Tijink Jasja
> <[email-masked]>; [email-masked] Betreff: Re: FW: [ipwave]
> Le 16/03/2018 à 18:34, Kevin Smith a écrit : [...]
> 
>>> Protocol Discrimination (EPD), the value of the Type field MUST
>>> be  set to 0x86DD (IPv6).  In the 802.11 header, the value of the
>>> Subtype sub-field in the Frame Control field MUST be set to 8
>>> (i.e. 'QoS Data'); the value of the Traffic Identifier (TID)
>>> sub-field of the QoS Control field of the 802.11 header MUST be
>>> set to binary 001 (i.e. User Priority 'Background', QoS Access
>>> Category 'AC_BK').
>>> 
>>> In the Ethernet II header, the value of the Type field MUST be
>>> set to 0x86DD (IPv6).
>> 
>> disagree with the part addressing the 802.11 header, I'm just not
>> an expert in this area and so defer to others. I believe that
>> others in the 1609 WG have been discussing this with the ipwave
>> list?
> 
> Noted.
> 
>>> Moreover ipwave discusses an abstract "Ethernet Adaptation
>>> Layer" but does not specify a header format, and this further
>>> confuses the question for deployers - what should we implement?
>> 
>> The Ethernet Adaptation Layer (more precisely 802.11-to-Ethernet
>> AL) is not so abstract, because it is widely implemented. This
>> layer does conversion between headers: at reception from the
>> network it transforms a .11/LLC header into an EthernetII header;
>> reversely, at sending it transforms an EthernetII header into a
>> .11/LLC header. This is shown in Figure 1.
>> 
>> formats involved are the IEEE 802.11, LLC and EthernetII. The
>> fields  in these headers are specified by IEEE.
>> 
>> [KS]: I don't understand why the EAL is relevant to "Transmission
>> of IPv6 Packets over IEEE 802.11 Networks operating in mode Outside
>> the Context of a Basic Service Set". If I want to write software
>> that sends IPv6 packets over 802.11 OCB, all I need to know is how
>> to construct the LLC sublayer header, etc. The EAL sounds like a 
>> "bridge", and perhaps belongs in a separate document (and perhaps
>> has already been addressed in some existing document?)
> 
> In implementations, that's how IPv6 works: whenever IPv6 stack wants
> to sit on a link layer (802.15.4, WiFi, LTE) it actually sits on an
> Whenever a new link layer technology appears, people struggle to make
> it first look like Ethernet.  Only then does IPv6 run easily on it.
> 
> It would take so long to create a new IPv6-over-.11 document, and
> only then to advance the IPv6-over-OCB draft.
> 
> An additional reason as to why it would take long is that the mapping
> of IPv6 fields on 802.11 fields is not straightforward at all.  (QoS
> is one aspect, but there is also frag fields, security and more).
> 
>> - ipwave 4.2.1 it states "An 'adaptation' layer is inserted between
>> a MAC layer and the Networking layer." This sounds like a
>> requirement. If I am developing a product that is only concerned
>> with sending IPv6 over OCB, and does not require "bridging", then
>> how do I reconcile this requirement?
> 
> If one develops a new product, one is likely to use existing kernels
> - they do include EAL, even though they dont call it so.
> 
> bridging is a tool called 'brctl'.  It bridges two distinct
> interfaces, e.g. an Ethernet interface to a WiFi interface.  Here we
> would 'bridge' Ethernet and 802.11 on the same interface.  It's not
> 'bridging', it's 'adaptation'.
> 
> Worse: 'brctl' does not work when we want to 'bridge' a OCB interface
> to an Ethernet interface.  I do not why.  I guess the 802. groups
> will figure it out one day and fix it.
> 
>> as standard Ethernet packets. As with all 802.11 frames, an
>> Ethernet adaptation layer MUST be used with 802.11-OCB as well."
>> Again EAL is stipulated as a requirement. And I'm not sure about
>> the stipulation that packets are transmitted as "standard Ethernet
>> packets", is this accurate?
> 
> YEs.
> 
> I verify it this way:
> 
> computer, and dump some IPv6 packets.  They all have EthernetII
> headers, rather than LLC and 802.11 headers.  Then capture the same
> in 'monitor' mode, or 'mon' interface in 802.11 OCB, and the .11/LLC
> headers will show instead.
> 
> included in the processing during the execution of this EAL.  But
> these EthernetII headers are not sent on the 802.11 air.
> 
>> This is definitely not stipulated in 1609.3. Packets transmitted
>> over OCB by a WAVE device using 1609.3 are well formed IPv6
>> packets, but not "Ethernet packets", i.e., no 802.3 headers are
>> included. This seems like an interoperability problem between
>> ipwave and 1609 WAVE.
> 
> draft do not include EthernetII headers.  SO I do not think there is
> an interop problem 1609 WAVE with IPv6-over-OCB draft.
> 
>> 
>> specified explicitly, but I don't know if some other RFCs related
>> to IPv6 over 802.11 already do that? Regardless, stipulating a
>> default value of 1500 for MTU size does not violate anything in
>> 1609.3.
> 
> Noted.
> 
> implementations inheriting from old Ethernet behaviour.  We dont want
> to break that.  Moreover, it is compatible with RFC8200 (IPv6) which
> MTU.  I heard of 10000bytes for some core links.  Yet the
> IPv6-over-foo for these links do not require the MTU 10000bytes.
> 
> 
>> 
>> 1609 WAVE does not specify that IPv6 must be preceded by .11
>> QoSData (not just .11 Data), and BACKGROUND, right?
>> 
>> the SCH (they are not allowed on the CCH). 802.11 specifies
>> defaults  for all UP and AC parameters, indicates which frame types
>> are allowed, etc. But as far as I can tell the stipulation that
>> IPv6 use  QoSData and AC_BK is new and something that ipwave
>> introduces?
> 
>> 1609 WG have been discussing this with the ipwave list.
>> Regardless, this additional restriction does not violate 1609.3.
>> 
>> speaking "recommend", rather it "specifies" and leaves all else up
>> to the system designer/implementer/deployer. And as mentioned
>> previously, 1609 allows any and all IETF protocols to be
>> implemented. Regardless, this recommendation does not violate
>> anything in 1609.3.
> 
> Noted.
> 
>> 
>> (and a few others).
>> 
>>> 1609 WAVE includes a number of mechanisms that enable IPv6
>>> networks to be configured. In addition to the WSA/WRA mechanism,
>>> 1609.3 allows any IETF protocols to be implemented, e.g., IETF
>>> RFC 4861, Neighbor Discovery for IP Version 6 (IPv6) (which is
>>> listed as a normative reference in 1609.3). Helpful would be some
>>> example use-cases that illustrate problems to be solved, and how
>>> ipwave will solve those problems (i.e., that 1609 WAVE does not
>>> already solve).
>> 
>> There is a draft that describes some use-cases of IPv6 in
>> vehicular networks: draft-ietf-ipwave-vehicular-networking-02
>> 
>> [KS]: Thanks for pointing me to that, lots of info there! I'll
>> spend some time reviewing that when I can.
>> 
>> I think some parts of 1609 WAVE, in particular WRA, are not used
>> in Europe. Whereas this IPv6-over-OCB draft is used the same
>> wherever Internet is present (Europe, America, Continents).
>> 
>> formats with ISO/ETSI standards, these harmonized frames are
>> included in all of the -2016 revisions to 1609. So for example the
>> 1609.3 WSA is interoperable with the service advertisement used in
>> Europe. See ISO 16460, and see also ETSI TS 102 890-1.
> 
> particular server ("ITS-S": station).  For particular servers, one
> may use RFC4191 instead, for "more specific routes" or, the routes
> known as 'host-based routes'.
> 
>>> My concern is that the IETF ipwave document may cause
>>> significant confusion among deployers, and possibly lead to a
>>> lack of interoperability. Thank you for the opportunity to
>>> comment, I look forward to the discussion.
>>

---

From: Jerome Haerri <[email-masked]>
Date: Sun, 18 Mar 2018 16:24:19 +0000

Dear All,

I disagree for two reasons: 
First this is not a profile, but an alternative operation of IP without relying on WSM.
Second, this document will also apply outside of the US, and then IEEE 1609.3 does not apply and thus would make this document confusing.

Best Regards,

Jérôme

Envoyé de mon iPhone

> Le 18 mars 2018 à 16:15, Alexandre Petrescu <[email-masked]> a écrit :
> 
> Hi IPWAVErs,
> 
>> -----Ursprüngliche Nachricht----- Von: Alexandre Petrescu [mailto:[email-masked]] Gesendet: Samstag, 17. März 2018 12:23 An: Tijink Jasja <[email-masked]> Cc: Kevin
>>> 2. My understanding of the discussion below is that draft-ietf-ipwave-ipv6-over-80211ocb-21 is "based on" IEEE 1609.3 in that it is compliant with it (I didn't find any "violation of IEEE 1609.3), and adds additional restrictions and /or specifications (such a MTU size, AC_BK, RFC8064, etc.). In that sense draft-ietf-ipwave-ipv6-over-80211ocb-21 is a profile of IEEE 1609.3. I would suggest making that very clear, with a short sentence/paragraph in draft-ietf-ipwave-ipv6-over-80211ocb-21 that
>>> explains it to the reader. If you disagree, I would like to hear your view on the relation of IEEE 1609.3 and draft-ietf-ipwave-ipv6-over-80211ocb-21.
>> The draft does refer to 1609.3, in Appendix C "aspects introduced by OCB to 802.11".  The vehicular networking draft (draft-ietf-ipwave-vehicular-networking-01) also refers to it right at the beginning.

---

From: Tijink Jasja <[email-masked]>
Date: Sun, 18 Mar 2018 16:45:03 +0000

Hello Jerome,

i am not sure that I understand your reasons.

First of all I am not sure why you state "alternative operation without relying on WSM". In which way 1609.3's IP mode relies on WSM?

Secondly, just to make an example IEEE 1609.2 (WAVE security standard) is used in Europe since ETSI TS 103 097 makes a profile out of it.

Anyhow, even if you don't like the sentence can your answer our original question: what functionality does the draft provide that  1609 WAVE does not already provide (except for the EAL aspect, which seems more an implementation requirement)?

Regards Jasja

-----Ursprüngliche Nachricht-----
Von: its [mailto:[email-masked]] Im Auftrag von Jerome Haerri
Gesendet: Sonntag, 18. März 2018 17:24
An: Alexandre Petrescu <[email-masked]>
Cc: Tijink Jasja <[email-masked]>; Kevin Smith <[email-masked]>; [email-masked]
Betreff: Re: [ipwave] [ipwaveî] IPv6-over-OCB as a profile of 1609 WAVE

Dear All,

Best Regards,

Jérôme

Envoyé de mon iPhone

> not sure what is a profile for 1609 WAVE.  In Bluetooth, a 'profile' 
> is something very much precise, like 'LAN profile', etc.
> 
> Alex
> 
> 
>> 2018 12:23 An: Tijink Jasja <[email-masked]> Cc: Kevin Smith 
>> <[email-masked]>; [email-masked] Betreff: Re: [ipwave] ipwave - 
>> comments and concerns - 1609 WAVE, EPD - towards resolution Hello 
>> Jasja,
>>> draft-ietf-ipwave-ipv6-over-80211ocb-21 is "based on" IEEE 1609.3 in that it is compliant with it (I didn't find any "violation of IEEE 1609.3), and adds additional restrictions and /or specifications (such a MTU size, AC_BK, RFC8064, etc.). In that sense draft-ietf-ipwave-ipv6-over-80211ocb-21 is a profile of IEEE 1609.3. I would suggest making that very clear, with a short sentence/paragraph in draft-ietf-ipwave-ipv6-over-80211ocb-21 that explains it to the reader. If you disagree, I would like to hear your view on the relation of IEEE 1609.3 and draft-ietf-ipwave-ipv6-over-80211ocb-21.

---

From: [email-masked]
Date: Sun, 18 Mar 2018 16:49:58 +0000

> Anyhow, even if you don't like the sentence can your answer our original question: what functionality does the draft provide that  1609 WAVE does not already provide (except for the EAL aspect, whi…

The point is not to provide functionality. Rather, the point is to document an agreement on what implementations should do if they want to be interoperable. As noted, there are many conceivable ways of transmitting IPv6 over OCB. We want to agree on just one.  That’s necessary and sufficient for this document.

Tony

---

From: Tijink Jasja <[email-masked]>
Date: Sun, 18 Mar 2018 17:08:00 +0000

…so if we put it that way:

Is it possible to explain how an implementation of this draft interoperates with an implementation of IEEE 1609.3?

Regards Jasja

Von: Tony Li [mailto:[email-masked]] Im Auftrag von [email-masked]
Gesendet: Sonntag, 18. März 2018 17:50
An: Tijink Jasja <[email-masked]>
Cc: Jerome Haerri <[email-masked]>; Alexandre Petrescu <[email-masked]>; Kevin Smith <[email-masked]>; [email-masked]
Betreff: Re: [ipwave] [ipwaveî] IPv6-over-OCB as a profile of 1609 WAVE

Tony

---

From: Alexandre Petrescu <[email-masked]>
Date: Sun, 18 Mar 2018 18:24:40 +0100

Le 17/03/2018 à 20:25, Kevin Smith a écrit :
[...]

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

At the risk of being called provokative: can one think there is another
version of IP that deserves being described? If not, the only version
that can be understood when reading "IP" is "IPv6".

I do not see why being explicit and say v6, when IP is sufficient and
shorter.

Alex
[...]

---

From: Alexandre Petrescu <[email-masked]>
Date: Sun, 18 Mar 2018 18:26:38 +0100

I suggest this clarification of the EAL text.

OLD:
> IP packets are transmitted over 802.11-OCB as standard Ethernet 

NEW:
> Within an IP-RSU, or within an IP-OBU, the IP packets are communicated
> by the IP stack to and from the 802.11-OCB driver as standard Ethernet
> II frames.  IP packets MUST be transmitted over 802.11-OCB media as
> QoS Data frames whose format is specified in IEEE Std 802.11.
> 
> Before sending the IP packets on the 802.11 media, and after receiving
> packets from the 802.11 media, the use of an adaptation layer that
> adapts between the frame formats of 802.11 and of Ethernet II is
> RECOMMENDED.  The Ethernet II headers MUST NOT be transmitted on
> 802.11 media.

Alex

Le 17/03/2018 à 13:50, Tony Li a écrit :
> I suspect that we’ll also get some push back on this sentence
> because it is implied to be normative.  Since the EAL doesn’t
> actually affect the bits on the air, this is simply an implementation
> choice and not strictly mandatory.
>

---

From: "Kevin Smith" <[email-masked]>
Date: Sun, 18 Mar 2018 10:34:40 -0700

Alex,

As the title of the document is " Transmission of *IPv6* Packets over ...", it seems to me that the scope is restricted to IPv6. Also note that IPv6 (along with WSMP) are the only L3 protocols allowed by 1609 WAVE, i.e., IPv4 is not allowed.

Best,
Kevin

-----Original Message-----
From: its [mailto:[email-masked]] On Behalf Of Alexandre Petrescu
Sent: Sunday, March 18, 2018 10:25 AM
To: Kevin Smith <[email-masked]>; 'Tijink Jasja' <[email-masked]>
Cc: [email-masked]
Subject: Re: [ipwave] IP or IPv6

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

At the risk of being called provokative: can one think there is another version of IP that deserves being described? If not, the only version that can be understood when reading "IP" is "IPv6".

I do not see why being explicit and say v6, when IP is sufficient and shorter.

Alex
[...]

---

From: "Kevin Smith" <[email-masked]>
Date: Sun, 18 Mar 2018 10:40:04 -0700

Hello Jerome and all,

As Dick points out, IPv6 does not in any way rely on WSMP. 

IPv6 packets are NOT encapsulated by WSM. WSMP and IPv6 are two completely
separate protocols.

Best,

Kevin

From: Dick Roy [mailto:[email-masked]] 
Sent: Sunday, March 18, 2018 9:44 AM
To: 'Jerome Haerri' <[email-masked]>; 'Alexandre Petrescu'
<[email-masked]>
Cc: 'Tijink Jasja' <[email-masked]>; 'Kevin Smith'
<[email-masked]>; [email-masked]
Subject: RE: [ipwave] [ipwaveî] IPv6-over-OCB as a profile of 1609 WAVE

-----Original Message-----
From: its [mailto:[email-masked]] On Behalf Of Jerome Haerri
Sent: Sunday, March 18, 2018 5:24 PM
To: Alexandre Petrescu
Cc: Tijink Jasja; Kevin Smith; [email-masked] <mailto:[email-masked]> 
Subject: Re: [ipwave] [ipwaveî] IPv6-over-OCB as a profile of 1609 WAVE

Dear All,

First this is not a profile, but an alternative operation of IP without
relying on WSM.

[RR] WSMP is a networking (and transport) protocol just like IP.  The above
statement makes no sense in that respect. One network layer protocol never
"relies on another".  That said, if IPv6-over-OCB is a profile of some other
set of standards, then you are wasting your time.  What is needed are
modifications to IPv6 to handle rapidly varying network topologies.  Where
have you heard that before?? ^)))  We don't need or want the IETF to specify
how lower layers MUST behave when sending IP packets.  Naturally if there
are recommendations for lower layer performance that will make the IP
functions perform better, make those recommendations.  Just NO SHALLs or
MUSTs on any lower layer protocols please! Stick to IPv6 funtionality.

Second, this document will also apply outside of the US, and then IEEE
1609.3 does not apply and thus would make this document confusing.

[RR] Not so.  IEEE 1609 is an international set of standards, and in
particular, IEEE 1609.3 is over the air interoperable with ISO 29281-2 FNTP
and therefore can operate anywhere FNTP operates around the world. 

Best Regards,

Jérôme

Envoyé de mon iPhone

> Le 18 mars 2018 à 16:15, Alexandre Petrescu <[email-masked]
<mailto:[email-masked]> > a écrit :

>> This document is a profile based on IEEE 1609.3: it introduces additional
requirements and specifications that do not violate that base standard.

>> This document is a profile based on IEEE 1609.3: it introduces additional
requirements and specifications that do not violate that base standard.

>> -----Ursprüngliche Nachricht----- Von: Alexandre Petrescu
[mailto:[email-masked]] Gesendet: Samstag, 17. März 2018 12:23
An: Tijink Jasja <[email-masked] <mailto:[email-masked]> >
Cc: Kevin

>> Smith <[email-masked] <mailto:[email-masked]> >;
[email-masked] <mailto:[email-masked]>  Betreff: Re: [ipwave]

>>> 1. I welcome your proposal for the additional text that specifies QoS.
This is necessary for operation in Europe (the specification for the access
layer can be found in ETSI EN 302 663, where clause 4.6 says that QoS shall
be used).

>>> 2. My understanding of the discussion below is that
draft-ietf-ipwave-ipv6-over-80211ocb-21 is "based on" IEEE 1609.3 in that it
is compliant with it (I didn't find any "violation of IEEE 1609.3), and adds
additional restrictions and /or specifications (such a MTU size, AC_BK,
RFC8064, etc.). In that sense draft-ietf-ipwave-ipv6-over-80211ocb-21 is a
profile of IEEE 1609.3. I would suggest making that very clear, with a short
sentence/paragraph in draft-ietf-ipwave-ipv6-over-80211ocb-21 that

to 802.11".  The vehicular networking draft
(draft-ietf-ipwave-vehicular-networking-01) also refers to it right at the
beginning.

>> IPv6-over-OCB sounds like an explanation.  As such, I suggest we first
write more precisely that "IPv6-over-OCB is a profile of 1609.3" and then
put it into the vehicular networking draft.

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

its mailing list

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

---

From: Alexandre Petrescu <[email-masked]>
Date: Sun, 18 Mar 2018 18:42:15 +0100

Le 18/03/2018 à 18:34, Kevin Smith a écrit :
> Alex,
> 
> As the title of the document is " Transmission of *IPv6* Packets
> over ...",

Maybe we should change the title to just say "IP".

> it seems to me that the scope is restricted to IPv6.

Yes.

> Also note that IPv6 (along with WSMP) are the only L3 protocols
> allowed by 1609 WAVE, i.e., IPv4 is not allowed.

In a world where IPv4 is not allowed, not specified, etc., IP can only 
mean IPv6.

Alex

> 
> Best, Kevin
> 
> -----Original Message----- From: its [mailto:[email-masked]]
> On Behalf Of Alexandre Petrescu Sent: Sunday, March 18, 2018 10:25 AM
>  To: Kevin Smith <[email-masked]>; 'Tijink Jasja' 
> <[email-masked]> Cc: [email-masked] Subject: Re: [ipwave] IP 
> or IPv6
> 
> 
> 
> Le 17/03/2018 à 20:25, Kevin Smith a écrit : [...]
> 
> At the risk of being called provokative: can one think there is 
> another version of IP that deserves being described? If not, the
> only version that can be understood when reading "IP" is "IPv6".
> 
> Alex [...]

---

From: Alexandre Petrescu <[email-masked]>
Date: Sun, 18 Mar 2018 18:52:54 +0100

Le 18/03/2018 à 18:08, Tijink Jasja a écrit :
> Is it possible to explain how an implementation of this draft 
> interoperates with an implementation of IEEE 1609.3?

To me, 1609.3 should just refer to IETF, this draft, abunch of other 
RFCs, and have no normative text about what IP should or should not do.

At some points where 1609.3 feels inclined and tempted to do IP, could 
copy paste some parts of this draft, reflect some values.  E.g. 1609.3 
should also say "IP on OCB as QoSData with BK and MTU1500".

Then we are sure to have interoperability between an IPv6-over-OCB 
computer and an 1609.3 computer.

But an 1609.3 document that says SLAAC uses WRA is a risk to 
interoperability.

Alex

> 
> Regards Jasja
> 
> *Von:*Tony Li [mailto:[email-masked]] *Im Auftrag von 
> [email-masked]
> *Gesendet:* Sonntag, 18. März 2018 17:50
> *An:* Tijink Jasja <[email-masked]>
> *Cc:* Jerome Haerri <[email-masked]>; Alexandre Petrescu 
> <[email-masked]>; Kevin Smith <[email-masked]>; 
> [email-masked]
> *Betreff:* Re: [ipwave] [ipwaveî] IPv6-over-OCB as a profile of 1609 WAVE
> 
>     Anyhow, even if you don't like the sentence can your answer our
>     original question: what functionality does the draft provide that
>       1609 WAVE does not already provide (except for the EAL aspect,
>     which seems more an implementation requirement)?
> 
> The point is not to provide functionality. Rather, the point is to 
> document an agreement on what implementations should do if they want to 
> be interoperable. As noted, there are many conceivable ways of 
> transmitting IPv6 over OCB. We want to agree on just one.  That’s 
> necessary and sufficient for this document.
> 
> Tony
>

---

From: Nabil Benamar <[email-masked]>
Date: Sun, 18 Mar 2018 17:59:44 +0000

Hi All,

Let me remind you that we have already had this discussion and we agreed
that this document is for IPv6 ONLY.

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

On Sun, Mar 18, 2018 at 5:42 PM, Alexandre Petrescu <
[email-masked]> wrote:

>>  To: Kevin Smith <[email-masked]>; 'Tijink Jasja' <
>> [email-masked]> Cc: [email-masked] Subject: Re: [ipwave] IP or
>> IPv6
>>
>>
>>
>> version of IP that deserves being described? If not, the

---

From: Alexandre Petrescu <[email-masked]>
Date: Sun, 18 Mar 2018 19:06:29 +0100

Le 18/03/2018 à 18:53, Dick Roy a écrit :
> Making requirements on MAC sublayer protocols is WAY out of scope.  Of
> course bridges translate between 802.11 and 802.3 

EAL is not a bridge, it is an adaptation layer.

Alex

> It's NOT up to the IETF
> to tell them how to do it! And once more, if some implementation wants to ue
> data frames, that's up to them.  They will simply ignore any QoS
> requirements.
> 
> 
> Sent: Sunday, March 18, 2018 6:27 PM
> To: undisclosed-recipients:
> Cc: Tijink Jasja; Kevin Smith; Tony Li; [email-masked]
> Subject: Re: [ipwave] clarification of EAL text
> 
>> I suspect that we'll also get some push back on this sentence
>> because it is implied to be normative.  Since the EAL doesn't

---

From: "Kevin Smith" <[email-masked]>
Date: Sun, 18 Mar 2018 11:11:40 -0700

Hello All,

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

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

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

Best,
Kevin

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

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

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

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

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

RR

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

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

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

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

Regards,
Kevin

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

Hi Alex,

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

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

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

Regards,
Kevin

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

Hi Alex,

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

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

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

Regards Jasja

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

Noted.

Noted.

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

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

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

Noted.

> over OCB, and does not require "bridging", then how do I reconcile 

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

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

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

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

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

YEs.

I verify it this way:

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

> seems like an interoperability problem between ipwave and 1609 WAVE.

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

Noted.

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

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

Noted.

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

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

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Sun, 18 Mar 2018 19:13:39 +0100

Le 18/03/2018 à 18:40, Kevin Smith a écrit :
> IPv6 packets are NOT encapsulated by WSM. WSMP and IPv6 are two 
> completely separate protocols.

I tend to agree IPv6 is not encapsulated by WSM.

But, IPv6 means more things than just the way packets are encapsulated.
In particular IPv6 also means SLAAC. SLAAC is a mandatory part of IPv6.

SLAAC is an IPv6 protocol and uses IPv6 Router Advertisements. SLAAC
does not use WRAs.

In this sense, WSMP specifying that SLAAC uses WRA, can be read as IPv6
relying on WSMP.

Alex

> 
> Best,
> 
> Kevin
> 
> *From:*Dick Roy [mailto:[email-masked]]
> *Sent:* Sunday, March 18, 2018 9:44 AM
> *To:* 'Jerome Haerri' <[email-masked]>; 'Alexandre Petrescu' 
> *Cc:* 'Tijink Jasja' <[email-masked]>; 'Kevin Smith' 
> *Subject:* RE: [ipwave] [ipwaveî] IPv6-over-OCB as a profile of 1609 WAVE
> 
> [RR] WSMP is a networking (and transport) protocol just like IP.  The 
> above statement makes no sense in that respect. One network layer 
> protocol never "relies on another".  That said, if IPv6-over-OCB is a 
> profile of some other set of standards, then you are wasting your time. 
>   What is needed are modifications to IPv6 to handle rapidly varying 
> network topologies.  Where have you heard that before?? ^)))  We don't 
> need or want the IETF to specify how lower layers MUST behave when 
> sending IP packets.  Naturally if there are recommendations for lower 
> layer performance that will make the IP functions perform better, make 
> those recommendations.  Just NO SHALLs or MUSTs on any lower layer 
> protocols please! Stick to IPv6 funtionality.
> 
> particular, IEEE 1609.3 is over the air interoperable with ISO 29281-2 
> FNTP and therefore can operate anywhere FNTP operates around the world.
> 
> Best Regards,
> 
> Jérôme
> 
> Envoyé de mon iPhone
> 
>  > Le 18 mars 2018 à 16:15, Alexandre Petrescu 
> <[email-masked] <mailto:[email-masked]>> a 
> écrit :
> 
>  >
> 
>  > Hi IPWAVErs,
> 
>  >
> 
> additional requirements and specifications that do not violate that base 
> standard.
> 
>  >
> 
> additional requirements and specifications that do not violate that base 
> standard.
> 
>  >> Regards Jasja
> 
> [mailto:[email-masked]] Gesendet: Samstag, 17. März 2018 
> 12:23 An: Tijink Jasja <[email-masked] 
> <mailto:[email-masked]>> Cc: Kevin
> 
>  >> Smith <[email-masked] <mailto:[email-masked]>>; 
> the access layer can be found in ETSI EN 302 663, where clause 4.6 says 
> that QoS shall be used).
> 
>  >> Noted.
> 
> 1609.3), and adds additional restrictions and /or specifications (such a 
> MTU size, AC_BK, RFC8064, etc.). In that sense 
> draft-ietf-ipwave-ipv6-over-80211ocb-21 is a profile of IEEE 1609.3. I 
> would suggest making that very clear, with a short sentence/paragraph in 
> draft-ietf-ipwave-ipv6-over-80211ocb-21 that
> 
> first write more precisely that "IPv6-over-OCB is a profile of 1609.3" 
> and then put it into the vehicular networking draft.
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Sun, 18 Mar 2018 19:17:16 +0100

> frames whose format is specified in IEEE Std 802.11."

We agree on the list that 802.11 document allows IPv6 be transmitted as 
QoSData, or Data.

We also agree (roughly 6 to 3) that in OCB mode, for vehicles it is best 
QoSData and BACKGROUND (not Data, not QoSData and VOICE, or any other).

This text will be on the slide tomorrow.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Sun, 18 Mar 2018 19:20:18 +0100

Le 18/03/2018 à 19:01, Dick Roy a écrit :
> The WRA in a WSA optionally contains a local IPv6 prefix so that SLAAC can
> be performed in the receiver of the WSA/WRA.  It does not state how.  That
> is left to the IETF RFCs naturally.

Is there a requirement from IEEE to IETF to develop a SLAAC with WRAs 
instead of RAs?  Or is it just a writer musings about how it could work?

Is there an implementation of SLAAC with WRAs?

Alex

> More below ...
> Sent: Sunday, March 18, 2018 6:53 PM
> To: Tijink Jasja; [email-masked]
> Cc: Kevin Smith; Jerome Haerri; [email-masked]
>> .so if we put it that way:
>>
> [RR] That is exactly what it does.  Where did you get any ideas to the
> contrary
> 
> [RR] See above. You have it backwards.
> 
> Alex
> 
>>
>> Regards Jasja
>>
>> transmitting IPv6 over OCB. We want to agree on just one.  That's

---

From: "Kevin Smith" <[email-masked]>
Date: Sun, 18 Mar 2018 12:28:09 -0700

Hi Alex,

I think the NEW proposed text has resolved a few of the issues I've been concerned about. However the statement "Within an IP-RSU, or within an IP-OBU, the IP packets are communicated  by the IP stack to and from the 802.11-OCB driver as standard Ethernet II frames." seems to make some assumptions about implementations.

As data travels up the layered protocol stack, headers are processed and stripped off, payloads delivered to the next higher layer. It seems like an assumption to say that an 802.11-OCB driver will receive Ethernet II frames. It might instead receive IPv6 packets and use some mechanism (implementation dependent) to determine that the packet needs to be routed over 802.11-OCB. 

A system diagram showing typical IP-RSU/IP-OBU communication flow would be helpful, to identify system architecture assumptions being made by ipwave.

Best,
Kevin

-----Original Message-----
From: its [mailto:[email-masked]] On Behalf Of Alexandre Petrescu
Sent: Sunday, March 18, 2018 10:27 AM
Cc: Tijink Jasja <[email-masked]>; Kevin Smith <[email-masked]>; Tony Li <[email-masked]>; [email-masked]
Subject: Re: [ipwave] clarification of EAL text

OLD:
> packets.  As with all 802.11 frames, an Ethernet adaptation layer MUST 
> be used with 802.11-OCB as well."

Alex

Le 17/03/2018 à 13:50, Tony Li a écrit :
> I suspect that we’ll also get some push back on this sentence because 
> it is implied to be normative.  Since the EAL doesn’t actually affect 
> the bits on the air, this is simply an implementation choice and not 
> strictly mandatory.
>

---

From: Jérôme Härri <[email-masked]>
Date: Sun, 18 Mar 2018 21:19:51 +0100

Dear Kevin,

I never mentioned that IPv6 was encapsulated by WSM, it clearly does
not…only the ETSI does that. 

However, the IEEE 1609.3, section 5.1 and 6.4.3 shows that IPv6 requires WME
for configuring its IP flow, and that the dynamic addressing is done from
receiving a WSA. This is what I meant by IPv6 relying on WSMP (here a WSA).
So, indeed two different protocols, but interlinked. 

I agree with Dick and others that providing a way to do enhanced IPv6 in
dynamic environment is the major task of this group…there will be some
interesting presentation on this tomorrow. 

Now, I am still skeptical to make an ‘restrictive’ mention of the ID to be a
profile to IEEE 1609.3, as it would be correct in the US, but it would give
the impression that the ID would not apply to EU. 

If the group opts to keep this sentence, then maybe we should add something
like: “In Regions operating IEEE 1609.x set of standards, this document is a
profile based on…” 

BR,

Jérôme

From: Kevin Smith [mailto:[email-masked]] 
Sent: Sunday 18 March 2018 18:40
To: [email-masked]; 'Jerome Haerri'; 'Alexandre Petrescu'
Cc: 'Tijink Jasja'; [email-masked]
Subject: RE: [ipwave] [ipwaveî] IPv6-over-OCB as a profile of 1609 WAVE

Hello Jerome and all,

Best,

Kevin

 

-----Original Message-----
From: its [mailto:[email-masked]] On Behalf Of Jerome Haerri
Sent: Sunday, March 18, 2018 5:24 PM
To: Alexandre Petrescu
Cc: Tijink Jasja; Kevin Smith; [email-masked]
Subject: Re: [ipwave] [ipwaveî] IPv6-over-OCB as a profile of 1609 WAVE

Dear All,

 

Best Regards,

Jérôme

Envoyé de mon iPhone

[mailto:[email-masked]] Gesendet: Samstag, 17. März 2018 12:23
An: Tijink Jasja <[email-masked]> Cc: Kevin

its mailing list

[email-masked]

---

From: [email-masked]
Date: Sun, 18 Mar 2018 21:02:38 +0000

Yes, we agreed in the charter that we are standardizing on IPv6 only and that IPv4 is out of scope.

I’ll also remind folks that there is another draft that already documents IPv4 over OCB.

Tony

> On Mar 18, 2018, at 5:59 PM, Nabil Benamar <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Hi All,
> 
> Let me remind you that we have already had this discussion and we agreed that this document is for IPv6 ONLY.
> 
> 
> 
> Best regards
> Nabil Benamar
> -------------------
> نبيل بنعمرو
> 
> 
> 
> 
> 
> 
> On Sun, Mar 18, 2018 at 5:42 PM, Alexandre Petrescu <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> In a world where IPv4 is not allowed, not specified, etc., IP can only mean IPv6.
> 
> Alex
> 
> 
> 
> Best, Kevin
> 
> -----Original Message----- From: its [mailto:[email-masked] <mailto:[email-masked]>]
>  To: Kevin Smith <[email-masked] <mailto:[email-masked]>>; 'Tijink Jasja' <Jasja.Tijink@kapsch..net <mailto:[email-masked]>> Cc: its@ietf..org <mailto:[email-masked]> Subject: Re: [ipwave] IP or IPv6
> 
> 
> 
> At the risk of being called provokative: can one think there is another version of IP that deserves being described? If not, the
> _______________________________________________ its mailing list [email-masked] <mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/its <https://www.ietf.org/mailman/listinfo/its>
> 
> 
> 
> https://www.ietf.org/mailman/listinfo/its <https://www.ietf.org/mailman/listinfo/its>
>

---

From: [email-masked]
Date: Sun, 18 Mar 2018 21:11:14 +0000

> On Mar 18, 2018, at 5:47 PM, Dick Roy <[email-masked]> wrote:
> 
> RR] That may be where the situation has degraded to, however that was never the original intent.  The original intent, the reason the BoF was created in the first place, was because ISO people went to the IETF (Thierry and a few others) to see if they would look into modifications to the IPv6 protocols so that it could function in rapidly varying network topologies (aka vehicular environments).  We were not asking for the IETF to specify what implementations at the lower layers should do, ONLY what network layer functionalities needed to be implemented.  Any and ALL talk of what lower layers would be required to do was originally way out of scope.  Any requirements the IETF makes on lower layer will w.p.1 fall on deaf ears … aka are a waste of time and effort.

Interesting.

There has been little discussion of situations that are not handled adequately today.

My experience suggests that no modifications are necessary at the network layer.

Specifying which aspects of the lower layers to use have always been the key point of the charter:

"This group's primary deliverable (and the only Standards track
item) will be a document that will specify the mechanisms for
transmission of IPv6 datagrams over IEEE 802.11-OCB mode.”

Tony

---

From: [email-masked]
Date: Sun, 18 Mar 2018 21:18:42 +0000

I continue to object to this text.

Again, we should only be standardizing (normative text) on the bits as they appear on the air.

The interface between the driver and the operating system is an API that is wholly out of scope for our charter.

I can accept including some informative text in this regard, but it should not be normative.

I’d like to propose alternate text:

	IP packets MUST be transmitted over 802.11-OCB media as
	QoS Data frames whose format is specified in IEEE Std 802.11.

	To simplify the API between the operating system and the 802.11-OCB media, device drivers MAY implement an Ethernet Adaptation Layer that translates Ethernet II frames to the 802.11 format and vice versa.

Tony

> On Mar 18, 2018, at 5:26 PM, Alexandre Petrescu <[email-masked]> wrote:
> 
>> IP packets are transmitted over 802.11-OCB as standard Ethernet packets.  As with all 802.11 frames, an Ethernet adaptation layer MUST be used with 802.11-OCB as well."
> 
> NEW:
>>> " IP packets are transmitted over 802.11-OCB as standard Ethernet packets.  As with all 802.11 frames, an Ethernet adaptation layer MUST be used with 802.11-OCB as well."

---

From: [email-masked]
Date: Sun, 18 Mar 2018 21:55:08 +0000

> [RR] This text should be removed in its entirety. There is absolutely no valid technical reason for making such a requirement, AND it is out of scope for the IETF to do so. If I want to send an IPv6 packet over 802.11 in OCB mode using Data fraes, I will and the IETF can not stop me. 

That’s true.  You just won’t interoperate with the rest of us.  

> [RR] APIs are Application Programming Interfaces that exist ABOVE the communications stack, i.e. ABOVE the Application Layer!  They have absolutely nothing to do with implementing MAC SAPs. Once more, functions/software that perform a translation between to MAC sublayer protocols are 1) out of scope of the IETF for darn sure, and 2) are layer-internal translation functions that reside in bridges, NOT an adaptation layer of any kind. 
>  
> I would not use either of these sentences.  They are both wrong on many counts.

Sorry you don’t like the wording, but ‘API' has been applied to many interfaces, not just to applications. Whether it’s bridging or adaptation layer is a matter of wordsmithing. The semantics remains the same.

Tony

---

From: Tijink Jasja <[email-masked]>
Date: Mon, 19 Mar 2018 05:59:05 +0000

Good morning,

in my opinion, IEEE 1609.3 allows dynamic addressing to be done using RAs and WRA. I do not see an obligation (read: requirement, or "shall") to "use" WRAs on receiver side and most importantly, I do not see a conflict between SLAAC using RA or WRA. The WRA is just another option provided to the device.

Coming back to my original proposal I would amend it to say:

This document is based on IEEE 1609.3 but does not require the sending/receiving of a WSA containing a WRA.

Is that acceptable?

Regards Jasja

Von: Jérôme Härri [mailto:[email-masked]]
Gesendet: Sonntag, 18. März 2018 21:20
An: 'Kevin Smith' <[email-masked]>; [email-masked]; 'Alexandre Petrescu' <[email-masked]>
Cc: Tijink Jasja <[email-masked]>; [email-masked]
Betreff: RE: [ipwave] [ipwaveî] IPv6-over-OCB as a profile of 1609 WAVE

Dear Kevin,

I never mentioned that IPv6 was encapsulated by WSM, it clearly does not...only the ETSI does that.

However, the IEEE 1609.3, section 5.1 and 6.4.3 shows that IPv6 requires WME for configuring its IP flow, and that the dynamic addressing is done from receiving a WSA. This is what I meant by IPv6 relying on WSMP (here a WSA). So, indeed two different protocols, but interlinked.

I agree with Dick and others that providing a way to do enhanced IPv6 in dynamic environment is the major task of this group...there will be some interesting presentation on this tomorrow.

Now, I am still skeptical to make an 'restrictive' mention of the ID to be a profile to IEEE 1609.3, as it would be correct in the US, but it would give the impression that the ID would not apply to EU.

If the group opts to keep this sentence, then maybe we should add something like: "In Regions operating IEEE 1609.x set of standards, this document is a profile based on..."

BR,

Jérôme

From: Kevin Smith [mailto:[email-masked]]
Sent: Sunday 18 March 2018 18:40
To: [email-masked]<mailto:[email-masked]>; 'Jerome Haerri'; 'Alexandre Petrescu'
Cc: 'Tijink Jasja'; [email-masked]<mailto:[email-masked]>
Subject: RE: [ipwave] [ipwaveî] IPv6-over-OCB as a profile of 1609 WAVE

Hello Jerome and all,

IPv6 packets are NOT encapsulated by WSM. WSMP and IPv6 are two completely separate protocols.

Best,
Kevin

From: Dick Roy [mailto:[email-masked]]
Sent: Sunday, March 18, 2018 9:44 AM
To: 'Jerome Haerri' <[email-masked]<mailto:[email-masked]>>; 'Alexandre Petrescu' <[email-masked]<mailto:[email-masked]>>
Cc: 'Tijink Jasja' <[email-masked]<mailto:[email-masked]>>; 'Kevin Smith' <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: [ipwave] [ipwaveî] IPv6-over-OCB as a profile of 1609 WAVE

-----Original Message-----
From: its [mailto:[email-masked]] On Behalf Of Jerome Haerri
Sent: Sunday, March 18, 2018 5:24 PM
To: Alexandre Petrescu
Cc: Tijink Jasja; Kevin Smith; [email-masked]<mailto:[email-masked]>
Subject: Re: [ipwave] [ipwaveî] IPv6-over-OCB as a profile of 1609 WAVE

Dear All,

[RR] WSMP is a networking (and transport) protocol just like IP.  The above statement makes no sense in that respect. One network layer protocol never "relies on another".  That said, if IPv6-over-OCB is a profile of some other set of standards, then you are wasting your time.  What is needed are modifications to IPv6 to handle rapidly varying network topologies.  Where have you heard that before?? ^)))  We don't need or want the IETF to specify how lower layers MUST behave when sending IP packets.  Naturally if there are recommendations for lower layer performance that will make the IP functions perform better, make those recommendations.  Just NO SHALLs or MUSTs on any lower layer protocols please! Stick to IPv6 funtionality.

[RR] Not so.  IEEE 1609 is an international set of standards, and in particular, IEEE 1609.3 is over the air interoperable with ISO 29281-2 FNTP and therefore can operate anywhere FNTP operates around the world.

Best Regards,

Jérôme

Envoyé de mon iPhone

> Le 18 mars 2018 à 16:15, Alexandre Petrescu <[email-masked]<mailto:[email-masked]>> a écrit :

>> -----Ursprüngliche Nachricht----- Von: Alexandre Petrescu [mailto:[email-masked]] Gesendet: Samstag, 17. März 2018 12:23 An: Tijink Jasja <[email-masked]<mailto:[email-masked]>> Cc: Kevin

>> Smith <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> Betreff: Re: [ipwave]

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

its mailing list

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

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 19 Mar 2018 09:16:53 +0100

Le 17/03/2018 à 21:05, Kevin Smith a écrit :
[...]

> *****[KS]: Sure, but if developers are re-using existing 
> implementations they don't really need a standard, except to perhaps
>  explain how it should have been implemented. The primary reason to 
> have standards is to enable interoperability, and instructs those 
> developing new (or perhaps debugging old) implementations as to how 
> to create (or maintain) products that play well with others.

There is a fine balance to be struck.  Because it is also hard to write
an IETF standard that is not implemented at all (running code is
necessary to make a standard at IETF), and it is easier to write a Best
Current Practice or INFORMATIONAL (not Standards Track) that documents
something that is already deployed.

[...]
> ***** What I'm gathering is that ipwave assumes that an Ethernet II 
> frame will be received, and need to be "adapted" to an 802.11 frame 
> format so that it may be transmitted 802.11-OCB. If this is the case,
> then perhaps the ipwave document is not clear enough about this. And

For clarification: ipwave is the name of the WG.  The short name of the
document discussed is more like "IPv6-over-80211-OCB", seen in the page
header.

The ipwave WG generates other documents like the vehicular-networking
document and maybe others in the future.

> again, I'm making an assumption here, but should the name of the 
> document be titled something like "Adaptation of Ethernet II frames 
> for Transmission of IPv6 Packets over IEEE 802.11 Networks operating
>  in mode Outside the Context of a Basic Service Set"?

The suggestion sounds reasonable, but it would break away from the
tradition of titleing IPv6-over-foo documents "Transmission of IPv6
over...".  All RFCs at IETF about IPv6-over-foo are titled that way.

[...]
> *****[KS]: I've read that packet captures from Wireshark and tcpdump
>  display frames received from 802.11 adapters this way, and they are
>  referred to as "fake Ethernet" frames.

Wireshark calls them "EthernetII" headers, not fake.

I think people do call them 'fake' but wireshark doesnt.

There are more headers in there that people call 'fake' even though
wireshark does not call them fake.  Even on the monitor
interface showing the 802.11 headers truly going on the wire, there are
other headers that people call 'fake' because they dont go on the wire
(in linux, e.g. the "Radiotap Header".)

In a sense, the normal capture shows the beautiful view of the world of
IPv6 and Ethernet and RFC2464, whereas the nitty-gritty details are in
monitor mode.

[...]

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 19 Mar 2018 09:17:44 +0100

Le 18/03/2018 à 21:12, Dick Roy a écrit :
> Sent: Sunday, March 18, 2018 7:06 PM
> To: [email-masked]
> Cc: 'Tijink Jasja'; 'Kevin Smith'; 'Tony Li'; [email-masked]
> EAL [RR] as was described below is not a bridge, it is an adaptation layer.
> [RR] If EAL takes an 802.11 MPDU and creates from it an 802.3 MPDU, then it
> is by definition performing the translation function of a bridge.  It's not
> a layer of any kind, nor a shim between layers of any kind.  It is a MAC
> protocol translator, and those are by definition bridge functions.

But many agreed RFCs outside IPWAVE WG say that's not bridging, and it 
is adaptation layer.  Do you have the energy to make these counter 
statements and persuade these other WGs that what they do is actually 
bridging?

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 19 Mar 2018 09:18:05 +0100

Le 18/03/2018 à 21:35, Dick Roy a écrit :
> Sent: Sunday, March 18, 2018 8:28 PM
> To: 'Alexandre Petrescu'
> Cc: 'Tijink Jasja'; 'Tony Li'; [email-masked]
> I think the NEW proposed text has resolved a few of the issues I've been 
> concerned about. However the statement "Within an IP-RSU, or within an 
> IP-OBU, the IP packets are communicated  by the IP stack to and from the 
> 802.11-OCB driver as standard Ethernet II frames." seems to make some 
> assumptions about implementations.
> 
> As data travels up the layered protocol stack, headers are processed and 
> stripped off, payloads delivered to the next higher layer. It seems like 
> an assumption to say that an 802.11-OCB driver will receive Ethernet II 
> frames.
> 
> */[RR] Any 802.11 driver that receives an 802.3 MPDU (from the PHY 
> layer) will pitch it in the waste can! 802.11 knows NOTHING about 802.3!/*
> 
> It might instead receive IPv6 packets and use some mechanism 
> (implementation dependent) to determine that the packet needs to be 
> routed over 802.11-OCB.
> 
> */[RR] This is a routing function and will only work if the unit has 
> implemented IPv6 routing.  If not, the packet will be pitched once again 
> because it is not intended for that host!/*

An adaptation layer is not a routing function.

Adaptation layers work ok in (the rare) systems where there is no 
routing implemented.

Alex
> 
> A system diagram showing typical IP-RSU/IP-OBU communication flow would 
> be helpful, to identify system architecture assumptions being made by 
> ipwave.
> 
> Best,
> 
> Kevin
> 
> Cc: Tijink Jasja <[email-masked]>; Kevin Smith 
> <[email-masked]>; Tony Li <[email-masked]>; [email-masked]
> 
>> It would probably be easier if we relaxed the wording to make this
> 
>> informative or recommended instead.
> 
>> 
> 
>> Tony
> 
>> 
> 
>> 
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 19 Mar 2018 09:18:38 +0100

Le 18/03/2018 à 21:08, Dick Roy a écrit :
> Sent: Sunday, March 18, 2018 7:14 PM
> To: Kevin Smith; [email-masked]; 'Jerome Haerri'
> */[RR] SLAAC does not USE RAs either.

Well, it does.

SLAAC Stateful Address Auto-Configuration is a common name for both 
RFC4862 using RAs and RFC2464 IPv6-over-Ethernet using a constant fe80.

>  SLAAC, unless I misunderstand it, 
> specifies how to take a local prefix, received somehow,

It's not a generic somehow, it is a precise RA per RFC4862:
>    Global addresses are formed by appending an interface identifier to a
>    prefix of appropriate length.  Prefixes are obtained from Prefix
>    Information options contained in Router Advertisements.

> and configure 
> locally valid IPv6 addresses that will be unique on the local network 
> (LAN).  Doesn’t matter how the prefix is obtained as far as the 
> configuration protocol is concerned./*

It does.

If there is no RA on the link then there is a big trouble.

I will save the DHCPv6 alternative details, but please be aware of this 
text in RFC4862 "SLAAC":
>  In this case [no RAs], the forwarding node's address must be manually
>    configured in hosts to be able to send packets off-link, since the
>    only mechanism to configure the default router's address
>    automatically is the one using Router Advertisements.

> */[RR] It’s better thought of as a necessary side channel for receiving 
> a local prefix than as “relying on a WRA”. /*

That side channel is ok as concept, but it is not SLAAC.

Alex

>>  > Le 18 mars 2018 à 16:15, Alexandre Petrescu 
> 
>>  >
>>  > Hi IPWAVErs,
>>  >
>>  > Do you disagree we add this phrase in the Introduction:
> 
>> 
> 
>>  >
> 
>> 
> 
>>  >> This document is a profile based on IEEE 1609.3: it  introduces
> 
>>  >
>>  > For my part I find addition of this text neutral and ok,  although I am
> 
>> 
> 
>>  > not sure what is a profile for 1609 WAVE.  In  Bluetooth, a 'profile' is
> 
>> 
> 
>>  > something very much precise, like 'LAN profile', etc.
> 
>> 
> 
>>  >
> 
>> 
> 
>>  > Alex
> 
>> 
> 
>>  >
> 
>> 
> 
>>  >
> 
>> 
> 
>>  >> Le 17/03/2018 à 13:22, Tijink Jasja a écrit :
> 
>> 
> 
>>  >> Hello Alex,
> 
>> 
> 
>>  >> Can we put something at the beginning of 
> 
>>  >> I suggest some language like the following:
> 
>> 
> 
>>  >> This document is a profile based on IEEE 1609.3: it  introduces
> 
>>  >> Regards Jasja
>>  >> -----Ursprüngliche Nachricht----- Von: Alexandre  Petrescu
> 
>>  >> Smith <[email-masked]  <mailto:[email-masked]>>;
> 
>>  >> ipwave - comments and concerns - 1609 WAVE, EPD -  towards resolution
> 
>> 
> 
>>  >> Hello Jasja,
> 
>> 
> 
>>  >>> Le 16/03/2018 à 19:02, Tijink Jasja a écrit :
> 
>> 
> 
>>  >>> Hello Alex,
> 
>> 
> 
>>  >>> in addition to Kevin's points, I  would like to  mention that:
> 
>> 
> 
>>  >>> 1. I welcome your proposal for the additional text  that specifies
> 
>>  >> Noted.
>>  >>> 2. My understanding of the discussion below is that 
> 
>>  >>> explains it to the reader. If you disagree, I would  like to hear
> 
>>  >> I dont really disagree, just where to put it.
> 
>> 
> 
>>  >> The draft does refer to 1609.3, in Appendix C  "aspects introduced by
> 
>>  >> IPv6-over-OCB sounds like an explanation.  As such,  I suggest we
> 
>>  >> How could that be written?
> 
>> 
> 
>>  >> Alex
> 
>> 
> 
>>  >
> 
>> 
> 
>>  > _______________________________________________
> 
>> 
> 
>>  > its mailing list
> 
>> 
> 
>>  > [email-masked] <mailto:[email-masked]>
> 
>> 
> 
>>  > https://www.ietf.org/mailman/listinfo/its
> 
>> 
>

---

From: [email-masked]
Date: Mon, 19 Mar 2018 09:33:52 +0000

> [RR] How the LANs below the IP network layer operate is of no concern to IP.

Sorry, but no.  We specify how we are going to use the LANs below IP.

>   Interoperability is ensured because only nodes on a given LAN will get a MAC frame containing the IP packet. If the IP packet is to be sent over several LANs, a bridge will take care of that.  The interoperability you seek is guaranteed by the system specifications of the deployer of the system.

The IETF specifies how IP packets are to be encapsulated. If it didn’t, we would see Data, QoS Data, and WSM encapsulation. Not to mention a variety of MTUs.  That’s proven to break interoperability.

Also, we do not change specifications for each and every different radio system. The point of having one so that we all interoperate by default.

>  If the specs state all nodes do QoS and Data frames at the MAC, or just QoS frames, then so be it.  It s NOT up to the IETF to make this decision, ever! The IP layer has NO business telling the lower layers what to do. It can “recommend”, but it MUST not mandate!:^))

Sorry, I disagree. It is the IETF’s job to standardize this. It has done so on each and every link layer up until now and will necessarily continue to do so.

Tony

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 20 Mar 2018 13:50:58 +0100

Le 18/03/2018 à 22:18, [email-masked] a écrit :
> The interface between the driver and the operating system is an API
> that is wholly out of scope for our charter.
> 
> IP packets MUST be transmitted over 802.11-OCB media as QoS Data
> frames whose format is specified in IEEE Std 802.11.
> 
> To simplify the API between the operating system and the 802.11-OCB
> media, device drivers MAY implement an Ethernet Adaptation Layer that
> translates Ethernet II frames to the 802.11 format and vice versa.

I agree.

Alex

>>> Within an IP-RSU, or within an IP-OBU, the IP packets are
>>> communicated by the IP stack to and from the 802.11-OCB driver as
>>> standard Ethernet II frames.  IP packets MUST be transmitted over
>>> 802.11-OCB media as QoS Data frames whose format is specified in
>>> IEEE Std 802.11. Before sending the IP packets on the 802.11
>>> media, and after receiving packets from the 802.11 media, the use
>>> of an adaptation layer that adapts between the frame formats of
>>> 802.11 and of Ethernet II is RECOMMENDED.  The Ethernet II
>>> headers MUST NOT be transmitted on 802.11 media.
>> 
>> Alex
>> 
>> 
>>>> on the EAL topic. Take again the following text from the
>>>> draft: " IP packets are transmitted over 802.11-OCB as standard
>>>> Ethernet packets.  As with all 802.11 frames, an Ethernet
>>>> adaptation layer MUST be used with 802.11-OCB as well." I
>>>> understand the second sentence is a requirement you put to
>>>> implementations that feature an ethernet interface and an
>>>> 802.11 interface.
>>> actually affect the bits on the air, this is simply an
>>> implementation choice and not strictly mandatory. It would
>>> probably be easier if we relaxed the wording to make this
>>> informative or recommended instead. Tony
> 
>

---

From: François Simon <[email-masked]>
Date: Tue, 20 Mar 2018 08:54:52 -0400

If ipwave is intended to be interoperable with 1609 WAVE,  then ipwave must
specify the use of EtherType Protocol Discrimination  (EPD) in the LLC
sublayer header, i.e., EPD is mandatory.

If interoperable with 1609 or not, EPD is mandatory in the 5.9 GHz band.

… the 802.11 header MUST be set to binary 001 (i.e.
> User Priority 'Background', QoS Access Category 'AC_BK').

"MUST" be AC_BK is too restrictive.  It should be left to be set according
to the application.

If my recollection is correct, the original document stated "IPv6 over the
data link layer;   DL = LLC + MAC.

General:

Since the first draft of the IPWAVE it was made clear the 1609 WAVE was out
of scope.

Fygs

-----Original Message-----
From: its <[email-masked]> On Behalf Of Kevin Smith
Sent: Friday, March 16, 2018 1:35 PM
To: Alexandre PETRESCU <[email-masked]>
Cc: 'Tijink Jasja' <[email-masked]>; [email-masked]
Subject: [ipwave] FW: ipwave - comments and concerns - 1609 WAVE, EPD -
towards resolution

Hi Alex,

Best regards,
Kevin

-----Original Message-----
From: its [mailto:[email-masked]] On Behalf Of Alexandre Petrescu
Sent: Thursday, March 15, 2018 11:23 AM
To: Kevin Smith <[email-masked] <mailto:[email-masked]> >
Cc: Tijink Jasja <[email-masked] <mailto:[email-masked]>
>; [email-masked] <mailto:[email-masked]> 

Hi Kevin,

Do you agree?

[KS]: Yes.

(and a few others).

[KS]: Sounds good! 

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 20 Mar 2018 14:24:13 +0100

Le 18/03/2018 à 20:28, Kevin Smith a écrit :
> Hi Alex,
> 
> I think the NEW proposed text has resolved a few of the issues I've
> been concerned about. However the statement "Within an IP-RSU, or
> within an IP-OBU, the IP packets are communicated  by the IP stack to
> and from the 802.11-OCB driver as standard Ethernet II frames." seems
> to make some assumptions about implementations.
> 
> As data travels up the layered protocol stack, headers are processed
> and stripped off, payloads delivered to the next higher layer. It
> seems like an assumption to say that an 802.11-OCB driver will
> receive Ethernet II frames. It might instead receive IPv6 packets and
> use some mechanism (implementation dependent) to determine that the
> packet needs to be routed over 802.11-OCB.
> 
> A system diagram showing typical IP-RSU/IP-OBU communication flow
> would be helpful, to identify system architecture assumptions being
> made by ipwave.

It is in Figure 1, 2 and 4.

Alex

> 
> Best, Kevin
> 
> -----Original Message----- From: its [mailto:[email-masked]] On
> Behalf Of Alexandre Petrescu Sent: Sunday, March 18, 2018 10:27 AM 
>> IEEE Std 802.11.
>> Before sending the IP packets on the 802.11 media, and after
>> receiving packets from the 802.11 media, the use of an adaptation
>> layer that adapts between the frame formats of 802.11 and of
>> Ethernet II is RECOMMENDED.  The Ethernet II headers MUST NOT be
>> transmitted on 802.11 media.
> 
> Alex
> 
> 
>>> " IP packets are transmitted over 802.11-OCB as standard
>>> adaptation layer MUST be used with 802.11-OCB as well."
>>> 
>> implementation choice and not strictly mandatory.
>>

---

From: François Simon <[email-masked]>
Date: Tue, 20 Mar 2018 09:37:44 -0400

This document is a profile based on IEEE 1609.3: it introduces additional requirements and specifications that do not violate that base standard.
Absolutely NOT. This IPWAVE document is NOT a profile of IEEE 1609.3. Framework and Taxonomy of International Standardized Profiles (somewhat paraphrased):  A profile identifies a set of base standards, together with appropriate options and parameters necessary to accomplish identified functions for purposes including: (a) interoperability, and (b) methodology for referencing the various uses of the base standards, meaningful both to users and suppliers. ISO TR 10000
Fygs

-----Original Message-----
From: its <[email-masked]> On Behalf Of Tijink Jasja
Sent: Saturday, March 17, 2018 8:23 AM
To: Alexandre Petrescu <[email-masked]>
Cc: Kevin Smith <[email-masked]>; [email-masked]
Subject: Re: [ipwave] ipwave - comments and concerns - 1609 WAVE, EPD - towards resolution

Hello Alex,

Regards Jasja

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

Hello Jasja,

Noted.

Alex

---

From: François Simon <[email-masked]>
Date: Tue, 20 Mar 2018 09:54:17 -0400

This document is a profile based on IEEE 1609.3: it introduces additional requirements and specifications that do not violate that  base standard.
For my part I find addition of this text neutral and ok, although I am not sure what is a profile for 1609 WAVE.  In Bluetooth, a 'profile' is something very much precise, like 'LAN profile', etc.

I am NOT ok with it:
1) - I did not think that IEEE 1609 Series was in scope of the document;
2) - OCB is NOT a profile of 1609 WAVE.  See previously sent definition.

Fygs
-----Original Message-----
From: its <[email-masked]> On Behalf Of Alexandre Petrescu
Sent: Sunday, March 18, 2018 12:16 PM
To: [email-masked]
Cc: Tijink Jasja <[email-masked]>; Kevin Smith <[email-masked]>
Subject: Re: [ipwave] [ipwaveî] IPv6-over-OCB as a profile of 1609 WAVE

Hi IPWAVErs,

> additional requirements and specifications that do not violate that 

For my part I find addition of this text neutral and ok, although I am not sure what is a profile for 1609 WAVE.  In Bluetooth, a 'profile' is something very much precise, like 'LAN profile', etc.

Alex

Le 17/03/2018 à 13:22, Tijink Jasja a écrit :
> 2018 12:23 An: Tijink Jasja <[email-masked] <mailto:[email-masked]> > Cc: Kevin Smith 
> <[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]>  Betreff: Re: [ipwave] ipwave - 
> comments and concerns - 1609 WAVE, EPD - towards resolution
> 
> Hello Jasja,
> 
>> the access layer can be found in ETSI EN 302 663, where clause

---

From: François Simon <[email-masked]>
Date: Tue, 20 Mar 2018 09:59:09 -0400

See ISO TR 10000 standard for profile definition.  BTW: I thought that 1609 is out of scope.

Fygs

-----Original Message-----
From: its <[email-masked]> On Behalf Of Tijink Jasja
Sent: Sunday, March 18, 2018 12:45 PM
To: Jerome Haerri <[email-masked]>; Alexandre Petrescu <[email-masked]>
Cc: Kevin Smith <[email-masked]>; [email-masked]
Subject: Re: [ipwave] [ipwaveî] IPv6-over-OCB as a profile of 1609 WAVE

Hello Jerome,

Regards Jasja

-----Ursprüngliche Nachricht-----
Von: its [mailto:[email-masked]] Im Auftrag von Jerome Haerri
Gesendet: Sonntag, 18. März 2018 17:24
An: Alexandre Petrescu <[email-masked]>
Cc: Tijink Jasja <[email-masked]>; Kevin Smith <[email-masked]>; [email-masked]
Betreff: Re: [ipwave] [ipwaveî] IPv6-over-OCB as a profile of 1609 WAVE

Dear All,

Best Regards,

Jérôme

Envoyé de mon iPhone

---

From: François Simon <[email-masked]>
Date: Tue, 20 Mar 2018 10:00:57 -0400

Nop!   

Fygs

From: its <[email-masked]> On Behalf Of Tijink Jasja
Sent: Sunday, March 18, 2018 1:08 PM
To: [email-masked]
Cc: Kevin Smith <[email-masked]>; Alexandre Petrescu <[email-masked]>; Jerome Haerri <[email-masked]>; [email-masked]
Subject: Re: [ipwave] [ipwaveî] IPv6-over-OCB as a profile of 1609 WAVE

Regards Jasja

Von: Tony Li [mailto:[email-masked]] Im Auftrag von [email-masked] <mailto:[email-masked]> 
Gesendet: Sonntag, 18. März 2018 17:50
An: Tijink Jasja <[email-masked] <mailto:[email-masked]> >
Cc: Jerome Haerri <[email-masked] <mailto:[email-masked]> >; Alexandre Petrescu <[email-masked] <mailto:[email-masked]> >; Kevin Smith <[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]> 
Betreff: Re: [ipwave] [ipwaveî] IPv6-over-OCB as a profile of 1609 WAVE

 

Tony

---

From: François Simon <[email-masked]>
Date: Tue, 20 Mar 2018 10:06:57 -0400

Only a 1609 restriction.
Fygs

-----Original Message-----
From: its <[email-masked]> On Behalf Of Kevin Smith
Sent: Sunday, March 18, 2018 1:35 PM
To: 'Alexandre Petrescu' <[email-masked]>; 'Tijink Jasja' <[email-masked]>
Cc: [email-masked]
Subject: Re: [ipwave] IP or IPv6

Alex,

Best,
Kevin

-----Original Message-----
From: its [mailto:[email-masked]] On Behalf Of Alexandre Petrescu
Sent: Sunday, March 18, 2018 10:25 AM
To: Kevin Smith <[email-masked]>; 'Tijink Jasja' <[email-masked]>
Cc: [email-masked]
Subject: Re: [ipwave] IP or IPv6

Alex
[...]

---

From: François Simon <[email-masked]>
Date: Tue, 20 Mar 2018 10:14:07 -0400

Absolutely agree with Dr. Roy.

Fygs

From: its <[email-masked]> On Behalf Of [email-masked]
Sent: Sunday, March 18, 2018 5:11 PM
To: [email-masked]
Cc: Tijink Jasja <[email-masked]>; Kevin Smith <[email-masked]>; Alexandre Petrescu <[email-masked]>; Jerome Haerri <[email-masked]>; [email-masked]
Subject: Re: [ipwave] [ipwaveî] IPv6-over-OCB as a profile of 1609 WAVE

On Mar 18, 2018, at 5:47 PM, Dick Roy <[email-masked] <mailto:[email-masked]> > wrote:

 

Interesting.

Tony

---

From: Abdussalam Baryun <[email-masked]>
Date: Wed, 21 Mar 2018 10:10:17 +0200

+1

AB

On Tue, Mar 20, 2018 at 3:54 PM, François Simon <[email-masked]> wrote:

> *This document is a profile based on IEEE 1609.3: it introduces additional
> requirements and specifications that do not violate that  base standard.*
>
> *For my part I find addition of this text neutral and ok, although I am
> something very much precise, like 'LAN profile', etc.*
>
> I am NOT ok with it:
>
> For my part I find addition of this text neutral and ok, although I am not
> sure what is a profile for 1609 WAVE.  In Bluetooth, a 'profile' is
> > [mailto:[email-masked] <[email-masked]>]
> Gesendet: Samstag, 17. März
>

---

From: Jérôme Härri <[email-masked]>
Date: Wed, 21 Mar 2018 11:19:23 +0100

Dear all,

I support the feedback from Mr. Simon and Baryun…As said before (but not loud enough) this document is not linked to IEEE 1609.3. Adding this would make it confusing.

However, we could add something like: “this document describes an alternative mechanism to the IPv6 configuration described in 1609.3”, if people really want to see 1609.3 stated in this work.

BR,

Jérôme

From: its [mailto:[email-masked]] On Behalf Of Abdussalam Baryun
Sent: Wednesday 21 March 2018 09:10
To: François Simon
Cc: Tijink Jasja; Kevin Smith; Alexandre Petrescu; its
Subject: Re: [ipwave] [ipwaveî] IPv6-over-OCB as a profile of 1609 WAVE

+1

AB

I am NOT ok with it:

Fygs

-----Original Message-----
From: its <[email-masked]> On Behalf Of Alexandre Petrescu
Sent: Sunday, March 18, 2018 12:16 PM
To: [email-masked]
Cc: Tijink Jasja <[email-masked]>; Kevin Smith <[email-masked]>
Subject: Re: [ipwave] [ipwaveî] IPv6-over-OCB as a profile of 1609 WAVE

Hi IPWAVErs,

Alex

> [ <mailto:[email-masked]> mailto:[email-masked]] Gesendet: Samstag, 17. März

> 2018 12:23 An: Tijink Jasja < <mailto:[email-masked]> [email-masked]> Cc: Kevin Smith 

> < <mailto:[email-masked]> [email-masked]>;  <mailto:[email-masked]> [email-masked] Betreff: Re: [ipwave] ipwave - 

its mailing list

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

 <https://www.ietf.org/mailman/listinfo/its> https://www.ietf.org/mailman/listinfo/its

---

From: [email-masked]
Date: Wed, 21 Mar 2018 10:22:04 +0000

> However, we could add something like: “this document describes an alternative mechanism to the IPv6 configuration described in 1609.3”, if people really want to see 1609.3 stated in this work.

I’m fine with this and would suggest that we use the word “replacement” rather than “alternative”.  We should not endorse two IPv6 encapsulations.

Tony

---

From: William Whyte <[email-masked]>
Date: Wed, 21 Mar 2018 06:26:13 -0400

Hi Tony -- it's an alternative mechanism for configuration, not for
encapsulation, so I think "alternative" is better than "replacement" here.

William

On Wed, Mar 21, 2018 at 6:22 AM, <[email-masked]> wrote:

>
>
> However, we could add something like: “this document describes an
> alternative mechanism to the IPv6 configuration described in 1609.3”, if
> people really want to see 1609.3 stated in this work.
>
>
>
> I’m fine with this and would suggest that we use the word “replacement”
> rather than “alternative”.  We should not endorse two IPv6 encapsulations.
>
> Tony
>
>
>

-- 

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

---

From: Tijink Jasja <[email-masked]>
Date: Wed, 21 Mar 2018 10:58:42 +0000

Hello,

thank you all for the feedback, at least I know what draft-ietf-ipwave-ipv6-over-80211ocb-22 is not. That is helpful at least partly…
I still wonder if somebody can explain to me what draft-ietf-ipwave-ipv6-over-80211ocb-22 really is intended to be and state this clearly in the document.
I am not trying to be provocative or obstructive, I just would like to see clarity. I see many  “similarities” of draft-ietf-ipwave-ipv6-over-80211ocb-22 with 1609.3, but still it is not a profile, it is not interoperable with it, and it is out of scope (whatever that means). That is confusing if you would like to be compliant to both standards.

I see at least three elements in draft-ietf-ipwave-ipv6-over-80211ocb-22. Please add more if you wish:

  1.  Over the air format of ipv6 over OCB.

To me it seems that draft-ietf-ipwave-ipv6-over-80211ocb-22 is compliant with or corresponding to the IEEE 1609.3 IPv6 mode, but restricts the frame options to QoS Data with AC_BK (this sounds like a profile to me).

  1.  Configuration of IPv6
Let’s consider the counterproposal: “this document describes an alternative mechanism to the IPv6 configuration described in 1609.3”. I am not sure why it is “alternative” (but it depends on how you interpret the word) . IEEE 1609.3 allows SLAAC using RA or WRA, so there is nothing alternative in draft-ietf-ipwave-ipv6-over-80211ocb-22, it is just more restrictive since it does not support WRA. (this sounds like a profile to me)

  1.  EAL. This is not specified by IEEE 1609.3 and to me is an implementation detail, not an over-the-air functionality.

Anything to add or change in this high level summary?

Regards Jasja

Von: Jérôme Härri [mailto:[email-masked]]
Gesendet: Mittwoch, 21. März 2018 11:19
An: 'Abdussalam Baryun' <[email-masked]>; 'François Simon' <[email-masked]>
Cc: Tijink Jasja <[email-masked]>; 'Kevin Smith' <[email-masked]>; 'Alexandre Petrescu' <[email-masked]>; 'its' <[email-masked]>
Betreff: RE: [ipwave] [ipwaveî] IPv6-over-OCB as a profile of 1609 WAVE

Dear all,

BR,

Jérôme

+1

AB

On Tue, Mar 20, 2018 at 3:54 PM, François Simon <[email-masked]<mailto:[email-masked]>> wrote:

I am NOT ok with it:

Fygs

-----Original Message-----
From: its <[email-masked]<mailto:[email-masked]>> On Behalf Of Alexandre Petrescu
Sent: Sunday, March 18, 2018 12:16 PM
To: [email-masked]<mailto:[email-masked]>
Cc: Tijink Jasja <[email-masked]<mailto:[email-masked]>>; Kevin Smith <[email-masked]<mailto:[email-masked]>>
Subject: Re: [ipwave] [ipwaveî] IPv6-over-OCB as a profile of 1609 WAVE

Hi IPWAVErs,

Alex

> 2018 12:23 An: Tijink Jasja <[email-masked]<mailto:[email-masked]>> Cc: Kevin Smith

> <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> Betreff: Re: [ipwave] ipwave -

its mailing list

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 21 Mar 2018 13:18:04 +0100

Jasja,

Le 21/03/2018 à 11:58, Tijink Jasja a écrit :
> Hello,
> 
> thank you all for the feedback, at least I know what 
> draft-ietf-ipwave-ipv6-over-80211ocb-22 is not. That is helpful at
> least partly…
> 
> I still wonder if somebody can explain to me what 
> draft-ietf-ipwave-ipv6-over-80211ocb-22 really is intended to be and
>  state this clearly in the document.
> 
> I am not trying to be provocative or obstructive, I just would like
> to see clarity. I see many  “similarities” of 
> draft-ietf-ipwave-ipv6-over-80211ocb-22 with 1609.3, but still it is
> not a profile, it is not interoperable with it, and it is out of
> scope (whatever that means). That is confusing if you would like to
> be compliant to both standards.
> 
> I see at least three elements in 
> draft-ietf-ipwave-ipv6-over-80211ocb-22. Please add more if you
> wish:
> 
> To me it seems that draft-ietf-ipwave-ipv6-over-80211ocb-22 is
> compliant with or corresponding to the IEEE 1609.3 IPv6 mode,

Noted.

> but restricts the frame options to QoS Data with AC_BK (this sounds
> like a profile to me).

1. if one wants to change that, one needs to persuade John Kenney, and
    Tony Li, first.

2. If 1609.3 WAVE IPv6 uses something else than QoSData with AC_BK (e.g.
    Data, or QoSData with AC_BE) then the local regulation in America and
    Europe might dislike it.  I am not sure, but one should double check.

> 2. Configuration of IPv6
> 
> Let’s consider the counterproposal: “this document describes an 
> alternative mechanism to the IPv6 configuration described in 1609.3”.
> I am not sure why it is “alternative” (but it depends on how you
> interpret the word) .

The -22 does not say that.

> IEEE 1609.3 allows SLAAC using RA or WRA, so there is nothing
> alternative in draft-ietf-ipwave-ipv6-over-80211ocb-22, it is just
> more restrictive since it does not support WRA. (this sounds like a 
> profile to me)

It is normal that draft-ietf-ipwave-ipv6-over-80211ocb-22 does not
support WRA, because WRA is not an IP message.

If one wants 1609.3-SLAAC to work with WRA (rather than RA) then there
are a few questions IMHO (In My Humble Oppinion).  None of these impacts
draft-ietf-ipwave-ipv6-over-80211ocb-22.

- decide whether only the prefix, or other parts from RA too need to be
   reflected in the WRA. (lifetimes, others, check RFC4862)
- decide whether in IEEE 1609.3 the default route comes from the WRA as
   well (not just the prefix).  If yes, decide whether the address of the
   default router comes from the src address of the WRA or from an SLLAO
   carried by the WRA.
- decide whether you want a system to work correctly while only WRA is
   present, both WRA and RA, or just RA.
- decide whether the prefix length in the WRA must be precisely 64, or
   can be of another length.
- decide whether the Interface ID definition in this draft can be used
   for the IEEE 1609.3-SLAAC.  I hope yes.
- others.

All these have no impact on draft-ietf-ipwave-ipv6-over-80211ocb-22.

> 3. EAL. This is not specified by IEEE 1609.3 and to me is an 
> implementation detail, not an over-the-air functionality.

Yes, EAL is an implementation detail, and not over-the-air functionality.

Do you think that the implementation detail of IEEE 1609.3 puts the IPv6
packets directly on 802.11, rather than on an adaptation layer?

Alex
[...]

---

From: Tony Li <[email-masked]>
Date: Wed, 21 Mar 2018 13:42:37 +0000

> On Mar 21, 2018, at 12:18 PM, Alexandre Petrescu <[email-masked]> wrote:
> 

Our draft really should say something about WRA, one way or another.

Lacking any compelling reason to use WRA, I would propose that we say that WRA should NOT be used.

Tony

---

From: William Whyte <[email-masked]>
Date: Wed, 21 Mar 2018 09:48:45 -0400

> I would propose that we say that WRA should NOT be used.

WRA is there and WAVE devices already support it; I don't see a reason to
rule it out, though I don't see a problem with specifying additional
mechanisms.

William

--

---

From: Tijink Jasja <[email-masked]>
Date: Wed, 21 Mar 2018 13:49:50 +0000

Hi Alex,

thanks this makes it much clearer to me.  
I would be happy to see this summary somewhere in the draft, either a paragraph or section on similarities or differences (you choose) with IEEE 1609.3.

Some answers in the text below
Regards Jasja

-----Ursprüngliche Nachricht-----
Von: Alexandre Petrescu [mailto:[email-masked]] 
Gesendet: Mittwoch, 21. März 2018 13:18
An: Tijink Jasja <[email-masked]>; Jérôme Härri <[email-masked]>; 'Abdussalam Baryun' <[email-masked]>; 'François Simon' <[email-masked]>
Cc: 'Kevin Smith' <[email-masked]>; 'its' <[email-masked]>
Betreff: Re: [ipwave] IPv6-over-OCB as a profile of 1609 WAVE

Jasja,

Le 21/03/2018 à 11:58, Tijink Jasja a écrit :
> I am not trying to be provocative or obstructive, I just would like to 
> see clarity. I see many  “similarities” of
> not a profile, it is not interoperable with it, and it is out of scope 
> (whatever that means). That is confusing if you would like to be 
> compliant to both standards.
> 

Noted.

[JT]: i know but it was a proposal on the list

> more restrictive since it does not support WRA. (this sounds like a 

It is normal that draft-ietf-ipwave-ipv6-over-80211ocb-22 does not support WRA, because WRA is not an IP message.

[JT]: noted

If one wants 1609.3-SLAAC to work with WRA (rather than RA) then there are a few questions IMHO (In My Humble Oppinion).  None of these impacts draft-ietf-ipwave-ipv6-over-80211ocb-22.

[JT]: interesting questions, noted

Do you think that the implementation detail of IEEE 1609.3 puts the IPv6 packets directly on 802.11, rather than on an adaptation layer?

[JT]: i think this is just out of scope of 1609.3 

Alex
[...]

---

From: [email-masked]
Date: Wed, 21 Mar 2018 13:58:12 +0000

> On Mar 21, 2018, at 1:48 PM, William Whyte <[email-masked]> wrote:
> 
> WRA is there and WAVE devices already support it; I don't see a reason to rule it out, though I don't see a problem with specifying additional mechanisms.
> 

As I mumbled previously, protocols to do with IP should be endorsed by the IETF. Unless this WG chooses to endorse WRA, we should preclude it.

Letting 1609 propose protocols for IP and not responding is worse than not responding to Liaison statements. 

Tony

---

From: William Whyte <[email-masked]>
Date: Wed, 21 Mar 2018 10:10:30 -0400

> Unless this WG chooses to endorse WRA, we should preclude it.

I would suggest endorsing it then :-)

William

On Wed, Mar 21, 2018 at 9:58 AM, <[email-masked]> wrote:

> As I mumbled previously, protocols to do with IP should be endorsed by the
> IETF. Unless this WG chooses to endorse WRA, we should preclude it.
>

--

---

From: [email-masked]
Date: Wed, 21 Mar 2018 17:18:33 +0000

> 
> You absolutely should NOT rule out the use of WRA, because it makes no sense to do so, and if you do, such statements will be ignored by those who see the value and choose to use the WRA.  For the IP networking people to be telling system deployers how they MUST deploy their services is simply wrong.  Stick to IP networking protocols; stay in layer 3; do not over step those boundaries … please … for the benefit of all of us! 

Perhaps you should start by asking 1609 to stay in Layer 2. ;-)

Tony

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 21 Mar 2018 18:42:26 +0100

Le 21/03/2018 à 18:26, Dick Roy a écrit :
[...]
> */[RR] 1609.3 clearly says implement IPv6 according to the RFCs.  There 
> is NO alternative at present!/*

But RFC4862 says SLAAC uses RA, not WRA.

Other RFCs say that the only means to obtain a default route is from an
RA (not from DHCP, not from something else like WRA).

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 21 Mar 2018 18:52:38 +0100

Le 21/03/2018 à 18:42, Dick Roy a écrit :
> “Do you think that the implementation detail of IEEE 1609.3 puts the 
> IPv6 packets directly on 802.11, rather than on an adaptation layer?“
> 
> 1609.3 takes ALL NPDUs and through a UNITDATA.request sends them ALL to 
> the DLL for handling on transmission. There is NEVER an adaptation layer 
> of ANY KIND! In 5.9GHz operation in the US, the LLC sublayer simply 
> appends an ethertype, the one for IPv6 in this case, and sends it to the 
> MAC for transmission. AGAIN, NO ADAPTATION LAYER!  Since the ONLY 
> MAC&PHY 1609.3 has chosen to recognize is 802.11, the MAC&PHY is 802.11, 
> and consequently 802.11 headers will are added.  There is NOTHING TO ADAPT!

That is the theory.  I asked about the implementation.

Alex

> From: its [mailto:[email-masked]] On Behalf Of Tijink Jasja
> Sent: Wednesday, March 21, 2018 2:50 PM
> To: Alexandre Petrescu; Jérôme Härri; 'Abdussalam Baryun'; 'François Simon'
> Cc: 'Kevin Smith'; 'its'
> Subject: Re: [ipwave] IPv6-over-OCB as a profile of 1609 WAVE
> 
> Hi Alex,
> 
> I would be happy to see this summary somewhere in the draft, either a 
> paragraph or section on similarities or differences (you choose) with 
> IEEE 1609.3.
> 
> An: Tijink Jasja <[email-masked]>; Jérôme Härri 
> <[email-masked]>; 'Abdussalam Baryun' 
> <[email-masked]>; 'François Simon' <[email-masked]>
>

---

From: [email-masked]
Date: Wed, 21 Mar 2018 18:01:02 +0000

> The problem ism1609 is NOT endorsing any protocols, even it’s own.  1609 simply says if you want to implement IP(v6), then you shall follow the IETF RFCs that specify how to do it!

1609 is proposing a protocol that happens to carry several IPish things. As previously mentioned, that oversteps our SDO gentlepeople’s agreement on division of responsibilities.  That is an issue that I’d like to see addressed.

In addition, the WRA description that I’ve been able to find is just plain broken. Now, that’s probably not current, but it does bear us looking at.  If it’s going to exist, let’s get it right.

> Now, if there is a side channel for getting a local prefix, that is out of scope of the IETF, and the IETF should not care!  How the information to perform SLAAC is obtained, as long as it is correct, is of NO CONSEQUENCE to the SLAAC procedure.  Telling someone they MUST receive an RA before they can do SLACC is simply a bad idea.  Providing them with a means for getting that information, via an RA, is a good idea, but NOT THE ONLY WAY!

The IETF cares. Trust me, the IEEE cares when the IETF wants to play at layer 2.  Ask me offline about jumbo frames.

Tony

---

From: [email-masked]
Date: Wed, 21 Mar 2018 18:28:05 +0000

> [RR] 1609.3 is a network (and transport layer) set of protocols. It would be inappropriate and simply wrong to say well …  you must stick to layer two. 

I see.  Well, that being the case, you’ll pardon me if reject the double standard.

> It added the WRA for efficiency purposes, and vetted its contents with IETF experts for what that’s worth:^)))  

Good to know.  Was this vetting done officially?  Documented? Or unofficially? Who looked at it?

If it wasn’t documented before, it should be…

Tony

---

From: Tony Li <[email-masked]>
Date: Wed, 21 Mar 2018 18:43:14 +0000

> Can the current IPv6 protocols handle rapidly varying network topologies (such as those in vehicular environments)?

Well, that depends on your definition of ‘handle’. In my experience, they certainly work, but to my level of expectations. If you’re expecting something else (and you probably are), the the answer may vary.

> Would the IETF be willing to develop new protocols or modify already existing ones to handle the situation?

That would be a ‘maybe'.  Depends on what needs changing.  If you want a change to the base IPv6 spec, that’s pretty much a no.  [Yes, I’ve tried…]. If you want to change BGP or DNS, that’s probably a no.

If you want to do something local to OCB, that’s more manageable.

So far, when I ask questions about what _doesn’t_ work already, I don’t seem to get specific use cases and problem statements. So the only problems that I see us needing to solve are encapsulation and MTU, as addressed by the draft.

> NOTICE:  Nowhere did we mention ANYTHING about layers below the network layer and we sure as heck didn’t mention 1609.anything!!!!

Well, it’s kinda hard to make progress without those.

> Instead, we got this!  Somehow, someway, the whole thing got WAY OFF TRACK.  It has now evolved into a useless and fruitless exercise of the IETF trying to tell implementers how to do their jobs.  This is a COMPLETE WASTE OF TIME.  They are not listening to any of your shalls or musts.  
>  
> I am retiring from this discussion until such time as you are prepared to answer the question posed above.  Anything else is again a complete waste of everyone’s time.

Standardization requires cooperation, which requires rough consensus, which requires discussion.

Sorry to see you go,  

Implementer Tony

---

From: [email-masked]
Date: Wed, 21 Mar 2018 18:50:54 +0000

> On Mar 21, 2018, at 6:35 PM, Dick Roy <[email-masked]> wrote:
> 
> “Good to know.  Was this vetting done officially?  Documented? Or unofficially? Who looked at it?”
>  
> You may know him?  His name is THIERRY ERNST.  If you don’t know him, allow me to introduce you to him.  He’s a really nice guy!:^))) and very knowledgeable in all matter IP-related!
> :^)))

Cool. Unofficially then.  

How about an upgrade to a broader audience?  More eyes catch more bugs...

Tony

---

From: [email-masked]
Date: Wed, 21 Mar 2018 18:54:24 +0000

> 1609 is proposing a protocol that happens to carry several IPish things. 
> [RR] You are confused.  It is NOT! 

I see a packet with a prefix, prefix length, default gateway, and primary DNS server.  I’d say that qualifies.

> As previously mentioned, that oversteps our SDO gentlepeople’s agreement on division of responsibilities.  That is an issue that I’d like to see addressed.
> [RR] THERE IS NOTHING TO ADDRESS other than the misunderstanding within the IETF of what 1609 really is.  To fix that, guess what, IETF people have to READ IT! I know that’s a tough pill to swallow, but c’est la vie!

Kinda hard to read when it’s behind a paywall.

Now I think I have a secret copy on backups at home, but I can’t get to it right now.

> [RR] Clearly indicates you and probably all the others as well have not read the spec.  My point is made.

I’d love to.  Please put a copy on the table.

> [RR] People want to overstep their bounds all the time; that doesn’t make it right, nor does it make it a good idea necessarily. There are times when it is called for; THIS IS NOT ONE OF THEM! 

And 1609 has overstepped its bounds. That doesn’t make it right.  And yelling louder at me isn’t going to change that.

Tony

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 21 Mar 2018 21:11:39 +0100

Le 21/03/2018 à 19:33, Dick Roy a écrit :
> When Thierry and I (and a few others) first decided to approach the IETF 
> years ago now, the goals were VERY SIMPLE.  Get the IETF to answer the 
> following very simple question:
> 
> Can the current IPv6 protocols handle rapidly varying network topologies 
> (such as those in vehicular environments)?

YEs, and we went through the questions many times during several BoFs.

If you want a simple answer to that simple question, it is something
like this: use MANET, Babel, Mobile IP, optimistic DAD, fast RAs (RFCs
exist for each) - it should work.

Why would one think they would not work?

> If the answer were NO, then the question was:
> 
> And we were hoping the answer would be “yes”!
> 
> NOTICE:  Nowhere did we mention ANYTHING about layers below the network 
> layer and we sure as heck didn’t mention 1609.anything!!!!
> 
> Instead, we got this!

I think IPv6-over-OCB is the right thing ISO TC204 should refer to, at 
this time.

For other things, we should ask ISO TC204 what kind of developments it sees.

>  Somehow, someway, the whole thing got WAY OFF 
> TRACK.  It has now evolved into a useless and fruitless exercise of the 
> IETF trying to tell implementers how to do their jobs.  This is a 
> COMPLETE WASTE OF TIME.  They are not listening to any of your shalls or 
> musts.

I dont know why you say so.  MTU 1500, QoSData AC_BK and Opaque IIDs are 
highly likely to be implemented as we speak.

MAC-based IIDs (as opposed to Opaque IIDs) are wrong for privacy.  MTU 
2300 is not respected by the IP stack (it starts fragmenting at 1500 by 
default).

Alex

> 
> I am retiring from this discussion until such time as you are prepared 
> to answer the question posed above.  Anything else is again a complete 
> waste of everyone’s time.
> 
> RR
> 
> ------------------------------------------------------------------------
> 
> *From:*its [mailto:[email-masked]] *On Behalf Of *Tony Li
> *Sent:* Wednesday, March 21, 2018 2:43 PM
> *To:* Alexandre Petrescu
> *Cc:* its; François Simon; Jérôme Härri; Tijink Jasja; Kevin Smith; 
> Abdussalam Baryun
> *Subject:* Re: [ipwave] IPv6-over-OCB as a profile of 1609 WAVE
> 
> 
> 
> On Mar 21, 2018, at 12:18 PM, Alexandre Petrescu 
> <[email-masked] <mailto:[email-masked]>> wrote:
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 21 Mar 2018 21:27:58 +0100

Le 21/03/2018 à 18:52, Dick Roy a écrit :
[...]
> */[RR] So what?  If I get a default route from divine intervention, 
> and it is correct, who the heck cares? For the RFCs to say that 
> something MUST be done in a particular way is simply bad standards 
> writing when it does not involve interoperability.  If I get valid 
> information I need from some other means, that should be allowed, 
> full stop! /*

Dick - I invite you to join the 6man and v6ops WGs and state there that
the default route might arrive correctly by other means than by RA. You
will hit opposition from many people of large companies considering
themselves to somehow know better what is best for Internet. People
trust them.

For my part, if you can persuade them, and consequently the IETF, that
the default route can come by something else, I might have a draft and
'running code' ready proposing to do it with DHCPv6 rather than with RA.
  Two or three other groups of people proposed same.  Still it cant
approach any measure of 'rough consensus' at IETF.

I dont know why WRA to deliver the default route can get any more
acceptance than what was proposed with DHCPv6.

Finally, the delivery of default route is not a matter that typical
IPv6-over-doo documents deal with.  As such, no need to write about it
in this draft.

(I gave presentations several times during IETF BoFs and IETF telcos
about what a typical IPv6-over-foo document does, and the audiences
ranged between 10 to 100: nobody complained, which is rare at IETF; the
presentations are available online).

Alex

> */[RR] Same as above!/*

---

From: Michelle Wetterwald <[email-masked]>
Date: Thu, 22 Mar 2018 00:00:50 +0100

I would like to come back on the initial topic of this discussion, i.e.
IPv6-over-OCB as a profile of 1609 WAVE . I would say that I agree with
Jerome, François, etc.. and don't see the reason why 1609 WAVE should be
mentioned as a basis for the present draft.

1609.3 has been referenced in the state of the art (SoA) draft "IP-based
Vehicular Networking: Use Cases, Survey and Problem Statement"
(draft-ietf-ipwave-vehicular-networking-02) as one standard that describes
how to use IPv6 in the 1609 WAVE environment. This standard is part of the
1609 set of standards. Other similar standards exist which are also listed
in that section of the SoA draft. I cannot see why implementers who are
willing to work in other frameworks should have to use the 1609 WAVE as a
basis when implementing this draft.
This draft references the SoA draft, which references the IEEE 1609.3
standard (section 5.2 + sections 4.1.1, 4.1.2) as one possible way to
implement vehicular networks. This is where it should stay, and we should
only make sure that no frontal contradiction exists that may confuse
implementers. From what I read in the past days, this is not the case.

BTW, as editor of the text in section 5.2 the SoA draft, I encourage people
from 1609 WAVE to check that is adequately summarizes the content of the
standard and to comment as necessary. We received the request for more
reviews of the SoA draft during the meeting on Monday morning.

BR, Michelle

2018-03-21 21:27 GMT+01:00 Alexandre Petrescu <[email-masked]>
:

>> */[RR] So what?  If I get a default route from divine intervention, and
>> it is correct, who the heck cares? For the RFCs to say that something MUST
>> be done in a particular way is simply bad standards writing when it does
>> not involve interoperability.  If I get valid information I need from some
>> other means, that should be allowed, full stop! /*
>>
>

-- 
Michelle Wetterwald
[email-masked]

---

From: Abdussalam Baryun <[email-masked]>
Date: Thu, 22 Mar 2018 01:07:08 +0200

+1
AB

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 22 Mar 2018 08:54:11 +0100

Dick,

Le 22/03/2018 à 00:01, Dick Roy a écrit :
> " Why would one think they would not work?"
> 
> Simply because our expert (Thierry Ernst) suggested they might not and it
> would be worth looking in to.  That's why we asked the question.  If you
> "believe" they will work, fine.  We will try them out (or not because WE
> know they won't work).  If that's the best response we can get from the

I am not saying that is the best response.  It is an _initial_ response 
from me as a participant to IETF, not representing IETF overaell.

Technically speaking, I have many reasons to believe why many existing 
IETF protocols dont work in _some_ particular use-cases.

We could discuss them, if you see it open minded.

> IETF, please STOP doing anything with the ITS effort.  The what that has
> been produced is of NO value to the ITS community.  You are wasting my time,
> your time, and everyone else's time.

"NO value" to the ITS community...

The ITS community has no Internet-scale interoperable way at this time 
about networking the automobiles.  There are very many closed settings, 
interoperating locally, but nothing to the scale of Internet.

For my part, up to now, I benefitted from these many things: open source 
availability for many specific use-cases, detailed IPR status, the 
making of distinct ethertypes for IPv6-vs-others, the AC_* distinctions, 
and more.

You may have not found benefit.  Then please express what would have 
been beneficial to you.  More detail than just dynamic network 
environments of vehicular networks.

Do you think the IPv6 ND protocol must satisfy some requirements on 
dynamicity?

> " I think IPv6-over-OCB is the right thing ISO TC204 should refer to, at
> this time."
> 
> You may think so, and you have every right to think it.  It's simply NOT
> GOING TO HAPPEN, PERIOD!

It would be strange ISO TC204 talks about IPv6, about 802.11 (expired), 
and not about IPv6-over-802.11-OCB.

> I have already stated so many reasons why your
> philosophy is wrong from our perspective, however you refuse to believe it
> and continue to try to tell us what to do WITHOUT HAVING READ any of our
> documents/standards.  No system designer is even going to read these RFCs.
> They know what they want and they know how to deploy it.  That's what will
> happen in spite of all your best efforts to the contrary.  I REPEAT, we did
> not come to the IETF asking for you to do OUR jobs, we came asking for you
> to do YOURS.  Unfortunately, that is not was has happened and as a
> consequence, to date, the IETF ITS effort has produced NOTHING of value for
> the ITS community. If there is ANYONE on this thread that believes
> otherwise, I am all ears.
> 
> " I dont know why you say so.  MTU 1500, QoSData AC_BK and Opaque IIDs are
> highly likely to be implemented as we speak."
> 
> Perhaps, however I can guarantee you it is NOT because the IETF mandated
> it!!!!!

Who mandated QoSData AC_BK for IP? (as opposed to Data for IP).

> " MAC-based IIDs (as opposed to Opaque IIDs) are wrong for privacy.  MTU
> default)."
> None of this is relevant to what we wanted from the IETF.  We can handle ALL
> THIS without your help!  This is NOTHING NEW!

Yes, you can handle.  But to obtain interoperability of Internet scale 
it's best to come to IETF.

Alex

> Sent: Wednesday, March 21, 2018 9:12 PM
> To: [email-masked]; 'Tony Li'
> Cc: 'its'; 'François Simon'; 'Jérôme Härri'; 'Tijink Jasja'; 'Kevin Smith';
> 'Abdussalam Baryun'
>> And we were hoping the answer would be "yes"!
>>
>> layer and we sure as heck didn't mention 1609.anything!!!!
>>
>> Instead, we got this!
> 
>> waste of everyone's time.
>>
>> RR
>>

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Thu, 22 Mar 2018 10:59:08 +0100

Hi,

The charter of IPWAVE is clear:

"This group's primary deliverable (and the only Standards track
item) will be a document that will specify the mechanisms for
transmission of IPv6 datagrams over IEEE 802.11-OCB mode."

So questions about "IPv6 protocols handling rapidly varying network
topologies (such as those in vehicular environments)" are out of the
scope.

Regarding the use of WRA, that is a mechanism defined outside IETF, it
is not an IP protocol and, unless proved to solve a problem that
current mechanisms defined by the IETF cannot cope with, I think the
document in our charter should not consider. I can only echo here what
Alex mentioned, 6man will not approve an IPv6-over-foo document relying
on WRA.

In relation to 1609, the charter says "Some aspects of the IPv6
over 802.11-OCB work have been already defined at IEEE 1609 and
the specification produced by this working group is expected be
compatible with these aspects". Our document is not a profile of IEEE
1609, it is expected that what the WG defines is compatible (though is
not a mandate). IETF is the responsible of defining IPv6-over-foo. The
decision of what technical solution to adopt has to be based on the
limits of the charter and the rough consensus of the WG. And the
consensus of the WG is on what Alex presented this Monday.

Thanks,

Carlos

On Wed, 2018-03-21 at 21:27 +0100, Alexandre Petrescu wrote:
> > Other RFCs say that the only means to obtain a default route is
> > from 
> > an
> >

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 22 Mar 2018 12:05:56 +0100

Le 22/03/2018 à 08:48, Dick Roy a écrit :
> For all you IETFer's who are experts in what you call EAL, and have been
> itching to explain to all those layer 2 guys how it's really to be done,
> here's your chance!  Join the following ballot pool at the IEEE.  I know,
> it's not a "real" standards organization like the IETF, but what the heck!
> It's all about helping out, right?
> 
> =================================
> 
> You have new myProject notifications - please log onto
> https://development.standards.ieee.org/my-site to read them.
> 
>    ----Message Boundary----
> 
> 
> To: undisclosed-recipients:;
> Cc: "C/LM/WG802.1 Project Staff Liaison" <[email-masked]>
> Subject: Sponsor Ballot Opening, P802.1AC-2016-Cor_1
> 
> 
> Dear IEEE P802.1AC-2016-Cor_1 Balloting Group Member:
> 
> This e-mail is to advise you of the opening of the IEEE Standards Sponsor
> Ballot for:
> 
> P802.1AC-2016-Cor_1
> 
> Title: Standard for Local and Metropolitan Area Networks -- Media Access
> Control (MAC) Service Definition - Corrigendum 1: Logical Link Control (LLC)
> Encapsulation EtherType
> 
> Scope: The scope of this standard is to define the Media Access Control
> (MAC) Service provided by all IEEE 802(R) MACs, and the Internal Sublayer
> Service (ISS) provided within MAC Bridges, in abstract terms of the
> following: a) Their semantics, primitive actions, and events; and b) The
> parameters of, interrelationship between, and valid sequences of these
> actions and events.

Maybe here is not the right place to ask because what follows is not an 
IP question: why is it not possible to bridge an 802.11 interface ran
in OCB mode to an Ethernet interface on the same computer?

(in linux the 'brctl' command fails when bridging OCB to Ethernet, I
checked recently; in my recollection it worked when bridging WiFi to
Ethernet, or WiFi to WiFi, or Ethernet to Ethernet).

_If_ this bridging worked it would save a lot of computing cycles
converting between the ASN.1 XER format of CAM-on-UDP-on-IP-on-Ethernet
inside the car and the ASN.1 UPER format of
CAM-on-BTP-on-GeoNetworking-on-802.11-OCB outside the car. With this
bridging, it would be possible to just use UPER
CAM-on-BTP-on-GeoNetworking both inside and outside the car.

(this 'bridging' is something else than what EAL does).

[...]
> ***** ACCESS THE DOCUMENT, SUBMIT YOUR VOTE, AND SUBMIT YOUR COMMENTS *****
> 
> Go directly to:
> 
> https://development.standards.ieee.org/my-site/ballot-activity
> (Note:  You may be prompted for your password if not already logged in).

What is the password?

Alex
[...]

---

From: Nabil Benamar <[email-masked]>
Date: Thu, 22 Mar 2018 19:17:18 +0000

+1 Carlos

Best regards
Nabil

---

From: Abdussalam Baryun <[email-masked]>
Date: Fri, 23 Mar 2018 22:20:53 +0200

On Wed, Mar 21, 2018 at 8:33 PM, Dick Roy <[email-masked]> wrote:

> *   Can the current IPv6 protocols handle rapidly varying network
> topologies (such as those in vehicular environments)?   If the answer were
> NO, then the question was:*
>

*Yes, check RFC6130, RFC5444, RFC5498, RFC7181, RFC7188, RFC7722,... etc.*

*   Would the IETF be willing to develop new protocols or modify already
> existing ones to handle the situation?   And we were hoping the answer
> would be “yes”!   *
>

*Yes the MANET WG is doing such work and they developed OLSRv2 RFC7181 (you
may interested to check RFC7722 for multi-topology) and if it is not good
performance for your cases, then you may propose in that WG a new
work/draft. The expert in IETF for ''IPv6 protocols handle rapidly varying
network topologies'' is Chris Dearlove, please contact him or discuss.  *

* I hope you discuss also at IETF MANET WG, or contact WG Chair: Justin
Dean and Stan Ratliff  both I think are US participants like you. This
message is CC to one WG chair.*

*Check the MANET WG: **https://datatracker.ietf.org/wg/manet/about/
<https://datatracker.ietf.org/wg/manet/about/>*

* NOTICE:  Nowhere did we mention ANYTHING about layers below the network
> layer and we sure as heck didn’t mention 1609.anything!!!!*
>

In IETF MANET we are doing now DLEP RFC8175, which is protocol between
the Mobile-PHY layer and Mobile-Routing layer, Yes we tell system designer
what to do, and they do listen. You need to understand that in dynamic
environment we need to have cross layering and any smart designer of any
system for ITS he/she needs to look into many layers up and down,

> * Instead, we got this!  Somehow, someway, the whole thing got WAY OFF
> IETF trying to tell implementers how to do their jobs.  This is a COMPLETE
> WASTE OF TIME.  They are not listening to any of your shalls or musts.  *
>

we cannot separate layers in the mobile networks, each layers exchanges
with others, so they need to work together. We do have cooperation with
IEEE and other SDOs, so we all listen to each other and some ietf
participants done efforts at other SDOs.

> * I am retiring from this discussion until such time as you are prepared
> waste of everyone’s time.*
>

Please don't retire participating, I get that feeling but there are nice
people in IETF. I suggest you discuss into MANET WG the email is
[email-masked], they will respond to you and to Mr.Thierry.

Take care,

AB

CC: MANET WG Chair

---

From: Abdussalam Baryun <[email-masked]>
Date: Fri, 23 Mar 2018 22:24:28 +0200

+1

AB