Subject: Re: [ipwave] Shepherd review of draft-ietf-ipwave-ipv6-over-80211ocb-12

From: François Simon <[email-masked]>
Date: Fri, 2 Feb 2018 05:23:36 -0500

Mr. Petrescu,

Let's try one more time to clarify the FCC DSRC (in US only) issue.

FCC – DSRC
Background:

-	The US Federal Communications Commission (FCC) Dedicated Short Range Communication (DSRC) is defined in the Code of Federal Regulations (CFR) 47 mainly Parts 90 and 95. The last update is dated October 1st, 2010;
-	This includes the ASTM E 2213-03 standard: “Standard Speciﬁcation for Telecommunications and Information Exchange Between Roadside and Vehicle Systems — 5 GHz Band Dedicated Short Range Communications (DSRC) Medium Access Control (MAC) and Physical Layer (PHY) Speciﬁcations”; approved July 10, 2003. The standard is derived from IEEE 802.11a and, in most part, is equivalent to IEEE 802.11 OCB. To date, the DSRC CFRs do not specify IEEE 802.11 OCB.
-	The related CFRs state that DSRC shall comply with the ASTM E 2213-03.

Overview of DSRC functions:

The functions listed in DSRC related CFRs are, in general, specified in the ASTM E 2213-03 and IEEE 802.11 OCB:
-	MAC service definition, frame format, and procedures;
-	PHY Orthogonal frequency division multiplexing (OFDM); 
-	PHY Service Data Unit format and modulations (data rates):
-	5.9 GHz band allocated channels, frequency, max. EIRP, and spectrum mask;
-	Individual Channel use: Safety applications, non-safety applications, and priorities. 

Protocols

DSRC being uniquely a MAC and PHY communications service, there here no restriction on Transport and Network protocols that can be used (except for the LCC specified by reference in IEEE 802.11 OCB). In the US, the WAVE standards (IEEE 1609 series) specify these protocols when using DSRC as the communication service.

OBU / RSU

The CFR (FCC) definitions are:

Roadside unit (RSU). A Roadside Unit is a DSRC transceiver that is mounted along a road or pedestrian passageway. An RSU may also be mounted on a vehicle or is hand carried, but it may only operate when the vehicle or hand- carried unit is stationary. Furthermore, an RSU operating under this part is restricted to the location where it is licensed to operate. However, portable or hand-held RSUs are permitted to operate where they do not interfere with a site-licensed operation. A RSU broadcasts data to OBUs or exchanges data with OBUs in its communications zone. An RSU also provides channel assignments and operating instructions to OBUs in its communications zone, when required. - [CFR 90.7 - Definitions] - Revised as October 2010.

On-Board unit (OBU). An On-Board Unit is a DSRCS transceiver that is normally mounted in or on a vehicle, or which in some instances may be a portable unit. An OBU can be operational while a vehicle or person is either mobile or stationary. The OBUs receive and contend for time to transmit on one or more radio frequency (RF) channels. Except where specifically excluded, OBU operation is permitted wherever vehicle operation or human passage is permitted. The OBUs mounted in vehicles are licensed by rule under part 95 of this chapter and communicate with Roadside Units (RSUs) and other OBUs. Portable OBUs are also licensed by rule under part 95 of this chapter. OBU operations in the Unlicensed National Information Infrastructure (UNII) Bands follow the rules in those bands. - [CFR 90.7 - Definitions] - October 2010

IPWAVE Issue

“The problem with the FCC definition of OBU is that it has no relationship to IP.  Worse, that FCC definition has no indication that it MAY use IP somehow.  And here we say that all OBUs must use IP.  Do you see what I mean?”

Correct; the OBU has no relationship with IP and is not intended to. IP is a network protocol.  If an On-Board Unit (OBU) device is required to exchange IP, it needs to be dealt in protocol(s) and/or Management in higher layers similar to WAVE within the On-Board Equipment (OBE) .

“Do you think FCC will mind if we use the term OBU in this draft to mean something else?  I, and a colleague, think that FCC would not mind.”

Depending of the reader. If one is familiar with DSRC, OBU and RSU as defined by FCC will come in mind. As far as I know, “OBU” and “RSU” are not registered and could be used for other definitions (something like “ATM”: Asynchronous Transfer Mode and Automatic Teller Machine 😊). My suggestion to the IPWAVE team is to use “OBE and RSE”.

This is my personal view as I do not represent any involved interest.  If any one has questions, let me know.

Francois Simon
Lojik Technologies

-----Original Message-----
From: its [mailto:[email-masked]] On Behalf Of Alexandre Petrescu
Sent: Monday, January 29, 2018 10:08 AM
To: [email-masked]
Subject: Re: [ipwave] Shepherd review of draft-ietf-ipwave-ipv6-over-80211ocb-12

Le 29/01/2018 à 15:52, François Simon a écrit :
> My comments arewithin the text*[Fygs.......]*.
[...]

> In the terminology section, the OBU term is mentioned to be defined 
> outside the IETF. This is fine, but we have to provide a reference.
> And even with that, it would not harm to include some short definition 
> to provide context. The RSU term is also defined outside the IETF and 
> there is quite a lot of text provided (I think the relevant part is 
> the last sentence, the one starting with "The difference between..."). 
> Both terms should be handled in the same way.
> 
> *[Fygs: The**definitions**was issued by the FCC 20 years ago.  I have  
> already provided that information**and references multiple
> times.]***

The problem with the FCC definition of OBU is that it has no relationship to IP.  Worse, that FCC definition has no indication that it MAY use IP somehow.  And here we say that all OBUs must use IP.  Do you see what I mean?

Do you think FCC will mind if we use the term OBU in this draft to mean something else?  I, and a colleague, think that FCC would not mind.

Alex

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

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 2 Feb 2018 15:29:45 +0100

Le 02/02/2018 à 11:23, François Simon a écrit :
> *FCC – DSRC*
> *Background:***
> **
> -** The US Federal Communications Commission (FCC) Dedicated Short Range 
> Communication (DSRC) is defined in the Code of Federal Regulations (CFR) 
> 47 mainly Parts 90 and 95. The last update is dated October 1st, 2010;
> 
> -This includes the ASTM E 2213-03 standard: “Standard Speciﬁcation for 
> Telecommunications and Information Exchange Between Roadside and Vehicle 
> Systems — 5 GHz Band Dedicated Short Range Communications (DSRC) Medium 
> Access Control (MAC) and Physical Layer (PHY) Speciﬁcations”; approved 
> July 10, 2003. The standard is derived from IEEE 802.11a and, in most 
> part, is equivalent to IEEE 802.11 OCB. To date, the DSRC CFRs do not 
> specify IEEE 802.11 OCB.
> 
> -The related CFRs state that DSRC shall comply with the ASTM E 2213-03.
> 
> *Overview of DSRC functions:***
> 
> **
> 
> -MAC service definition, frame format, and procedures;
> 
> -PHY Orthogonal frequency division multiplexing (OFDM);
> 
> -PHY Service Data Unit format and modulations (data rates):
> 
> -5.9 GHz band allocated channels, frequency, max. EIRP, and spectrum mask;
> 
> -Individual Channel use: Safety applications, non-safety applications, 
> and priorities.
> 
> *Protocols***
> 
> **
> 
> DSRC being uniquely a MAC and PHY communications service, there here no 
> restriction on Transport and Network protocols that can be used (except 
> for the LCC specified by reference in IEEE 802.11 OCB). In the US, the 
> WAVE standards (IEEE 1609 series) specify these protocols when using 
> DSRC as the communication service.
> 
> *OBU / RSU***
> 
> **
> 
> /Roadside unit (RSU). A Roadside Unit is a DSRC transceiver that is 
> mounted along a road or pedestrian passageway. An RSU may also be 
> mounted on a vehicle or is hand carried, but it may only operate when 
> the vehicle or hand- carried unit is stationary. Furthermore, an RSU 
> operating under this part is restricted to the location where it is 
> licensed to operate. However, portable or hand-held RSUs are permitted 
> to operate where they do not interfere with a site-licensed operation. A 
> RSU broadcasts data to OBUs or exchanges data with OBUs in its 
> communications zone. An RSU also provides channel assignments and 
> operating instructions to OBUs in its communications zone, when 
> required./- [CFR 90.7 - Definitions] - Revised as October 2010.
> 
> /On-Board unit (OBU). An On-Board Unit is a DSRCS transceiver that is 
> normally mounted in or on a vehicle, or which in some instances may be a 
> portable unit. An OBU can be operational while a vehicle or person is 
> either mobile or stationary. The OBUs receive and contend for time to 
> transmit on one or more radio frequency (RF) channels. Except where 
> specifically excluded, OBU operation is permitted wherever vehicle 
> operation or human passage is permitted. The OBUs mounted in vehicles 
> are licensed by rule under part 95 of this chapter and communicate with 
> Roadside Units (RSUs) and other OBUs. Portable OBUs are also licensed by 
> rule under part 95 of this chapter. OBU operations in the Unlicensed 
> National Information Infrastructure (UNII) Bands follow the rules in 
> those bands./- [CFR 90.7 - Definitions] - October 2010
> 
> *IPWAVE Issue***
> 
> **
> 
> /“The problem with the FCC definition of OBU is that it has no 
> relationship to IP.  Worse, that FCC definition has no indication that 
> it MAY use IP somehow.  And here we say that all OBUs must use IP.  Do 
> you see what I mean?”///
> 
> //
> 
> Correct; the OBU has no relationship with IP and is not intended to. IP 
> is a network protocol.  If an On-Board Unit (OBU) device is required to 
> exchange IP, it needs to be dealt in protocol(s) and/or Management in 
> higher layers similar to WAVE within the On-Board Equipment (OBE) .
> 
> /“Do you think FCC will mind if we use the term OBU in this draft to 
> mean something else?  I, and a colleague, think that FCC would not mind.”///
> 
> //
> 
> Depending of the reader. If one is familiar with DSRC, OBU and RSU as 
> defined by FCC will come in mind. As far as I know, “OBU” and “RSU” are 
> not registered and could be used for other definitions (something like 
> “ATM”: Asynchronous Transfer Mode and Automatic Teller Machine😊). My 
> suggestion to the IPWAVE team is to use “OBE and RSE”.
> 
> This is my personal view as I donot represent any involved interest.  If 
> any one has questions, let me know.

If we want to go with OBE instead of OBU then we must be ready to defend 
it in our respective contexts.  Are we ready to?

(I already have a hard time with telling people "802.11p" no longer 
exists, especially to those who are afraid I want to use LTE to 'kill' 
802.11p; and now to tell them to use "OBE" instead of "OBU" just in 
order to use IP seems like an additional effort).

All the OBUs I use do run IP.

Can FCC change their definition to include a reference to this IP draft?

Alex

> The problem with the FCC definition of OBU is that it has no 
> relationship to IP.  Worse, that FCC definition has no indication that 
> it MAY use IP somehow.  And here we say that all OBUs must use IP.  Do 
> you see what I mean?
> 
> Do you think FCC will mind if we use the term OBU in this draft to mean 
> something else?  I, and a colleague, think that FCC would not mind.
> 
> Alex
>

---

From: Tony Li <[email-masked]>
Date: Fri, 2 Feb 2018 08:07:27 -0800

>> Depending of the reader. If one is familiar with DSRC, OBU and RSU as defined by FCC will come in mind. As far as I know, “OBU” and “RSU” are not registered and could be used for other definitions (something like “ATM”: Asynchronous Transfer Mode and Automatic Teller Machine😊). My suggestion to the IPWAVE team is to use “OBE and RSE”.
>> This is my personal view as I donot represent any involved interest.  If any one has questions, let me know.
> 
> If we want to go with OBE instead of OBU then we must be ready to defend it in our respective contexts.  Are we ready to?

Might I suggest that we use IP-OBU? This would make it obvious that it is an OBU speaking IP.

Tony

---

From: John Kenney <[email-masked]>
Date: Fri, 2 Feb 2018 11:12:17 -0800

> Absolutely not. Let's kill this idea as quickly as possible.  The FCC is
intentionally agnostic about what comes above the MAC layer of DSRC.  There
is no reason why they should mention IP or any other higher layer protocol,
and the lack of mention of such protocols should be understood to mean
there are no regulatory requirements with respect to them.

Also, please do not re-use the terms OBU and RSU with different meanings
than given by the FCC. That's asking for trouble. Please don't create new
definitions of OBE and RSE either. Tony Li's suggestion for an IP-specific
label seems like a good way to proceed.

I also mention that the IEEE 802.11p, 1609.2, 1609.3 and 1609.4 standards
do not use either of those terms.  In other words, from a WAVE standards
point of view, there is no distinction between an OBU and an RSU.  I
haven't been following this IETF work very closely, but it may be worth
re-examining whether any such distinctions are necessary for you as well.

Best Regards,
John

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

---

From: François Simon <[email-masked]>
Date: Sat, 3 Feb 2018 09:29:28 -0500

Gentlemen,

Mr. Petrescu responded to my email with:

1.	" If we want to go with OBE instead of OBU then we must be ready to defend it in our respective contexts.  Are we ready to?"

	Argument: From the FCC is concerned, the term "Roadside Equipment" is not defined. Its purpose was to allocated 75 MHz within the 5.9 GHz spectrum, define a channel plan, and define application priorities (emphasis on safety applications) in the use of the allocated channels (mainly for government entities).  However, The US DOT defines OBE and RSE:

-	On-Board Equipment (OBE) - Term refers to the compliment of equipment located in the vehicle for the purpose of supporting the vehicle side of the applications. It is likely to include the DSRC radios, other radio equipment, message processing, driver interface, and other applications to support the use cases described herein [see Reference]. It is also referred to as the Vehicle ITS Station. When referring to the DSRC radio alone, the correct term is OBU.”
	
-	Roadside Equipment (RSE) - Term used to describe the compliment of equipment to be located at the roadside; the RSE will prepare and transmit messages to the vehicles and receive messages from the vehicles for the purpose of supporting the V2I applications. This is intended to include the DSRC radio, traffic signal controller where appropriate, interface to the backhaul communications network necessary to support the applications, and support such functions as data security, encryption, buffering, and message processing. When speaking of the DSRC radio alone, the correct term is RSU.”.
		
			Reference: 2015 FHWA Vehicle to Infrastructure Deployment Guidance and Products.

2.	“(I already have a hard time with telling people "802.11p" no longer exists,…”

	Argument:  You have made the point (justification) once. In verbal discussion, let the member refer it as they wish. As an editor of IPWAVE documents, mention the rational once in the introduction and insure that “IEEE 802.11p” is replaced by “802.11 OCB” in the remaining text.

3.	“….especially to those who are afraid I want to use LTE to 'kill' 802.11p…”

	Argument:  If this is yours and your organization goal, you are not the only one. This has been debated for few years already.  This is not a technical argument, therefore I will not address it. 

4.	“…and now to tell them to use "OBE" instead of "OBU" just in order to use IP seems like an additional effort).”

	Argument:  I am not suggesting to do a “global” change of “OBU / RSU” with “OBE / RSE”.  “Unit” and “Equipment” have their own context.  However, “Unit” is the radio included in “Equipment” and by itself does not make a system enabling the transportation of IP as defined by IETF.  I am suggesting the use of OBU/OBE and RSU/RSE within their appropriate context.

5.	“All the OBUs I use do run IP.”

	Argument: It depends of your definition of “run”. The OBU (radio) does nothing with IP (or any other network protocols). The OBU exchange MAC protocol data units (MPDU) with its peer(s) via a wireless media channel.  The Internet Protocol (IP) is the payload  of the MPDU.

6.	“Can FCC change their definition to include a reference to this IP draft?:”

	Argument: NO.  FCC is an independent agency of the US government. For some of you who remember the PTTs in Europe, it is somewhat similar; two to three years to fulfill a simple residence telephone request; should I say more? 😉 
	
I hope this help somewhat but do remember this comments apply to US only.  If you have any comments and/or questions, let me know.

Sincerely,

Francois Simon
Lojik Technologies

-----Original Message-----
From: François Simon [mailto:[email-masked]] 
Sent: Friday, February 02, 2018 2:14 PM
To: [email-masked]
Subject: FW: [ipwave] Shepherd review of draft-ietf-ipwave-ipv6-over-80211ocb-12

-----Original Message-----
From: Alexandre Petrescu [mailto:[email-masked]] 
Sent: Friday, February 02, 2018 9:30 AM
To: François Simon <[email-masked] <mailto:[email-masked]> >
Cc: [email-masked] <mailto:[email-masked]> 
Subject: Re: [ipwave] Shepherd review of draft-ietf-ipwave-ipv6-over-80211ocb-12

Le 02/02/2018 à 11:23, François Simon a écrit :
> -** The US Federal Communications Commission (FCC) Dedicated Short 
> Range Communication (DSRC) is defined in the Code of Federal 
> Regulations (CFR)
> Telecommunications and Information Exchange Between Roadside and 
> Vehicle Systems — 5 GHz Band Dedicated Short Range Communications 
> (DSRC) Medium Access Control (MAC) and Physical Layer (PHY) 
> Speciﬁcations”; approved July 10, 2003. The standard is derived from 
> IEEE 802.11a and, in most part, is equivalent to IEEE 802.11 OCB. To 
> date, the DSRC CFRs do not specify IEEE 802.11 OCB.
> 
> The functions listed in DSRC related CFRs are, in general, specified 
> in the ASTM E 2213-03 and IEEE 802.11 OCB:
> 
> DSRC being uniquely a MAC and PHY communications service, there here 
> no restriction on Transport and Network protocols that can be used 
> (except for the LCC specified by reference in IEEE 802.11 OCB). In the 
> US, the WAVE standards (IEEE 1609 series) specify these protocols when 
> using DSRC as the communication service.
> 
> *OBU / RSU***
> 
> **
> 
> to operate where they do not interfere with a site-licensed operation. 
> A RSU broadcasts data to OBUs or exchanges data with OBUs in its 
> normally mounted in or on a vehicle, or which in some instances may be 
> a portable unit. An OBU can be operational while a vehicle or person 
> is either mobile or stationary. The OBUs receive and contend for time 
> to transmit on one or more radio frequency (RF) channels. Except where 
> are licensed by rule under part 95 of this chapter and communicate 
> with Roadside Units (RSUs) and other OBUs. Portable OBUs are also 
> licensed by rule under part 95 of this chapter. OBU operations in the 
> Unlicensed National Information Infrastructure (UNII) Bands follow the 
> rules in those bands./- [CFR 90.7 - Definitions] - October 2010
> 
> *IPWAVE Issue***
> 
> **
> 
> Correct; the OBU has no relationship with IP and is not intended to. 
> IP is a network protocol.  If an On-Board Unit (OBU) device is 
> required to exchange IP, it needs to be dealt in protocol(s) and/or 
> Management in higher layers similar to WAVE within the On-Board Equipment (OBE) .
> 
> defined by FCC will come in mind. As far as I know, “OBU” and “RSU” 
> are not registered and could be used for other definitions (something 
> like

(I already have a hard time with telling people "802.11p" no longer exists, especially to those who are afraid I want to use LTE to 'kill' 
802.11p; and now to tell them to use "OBE" instead of "OBU" just in order to use IP seems like an additional effort).

Alex

> To: [email-masked] <mailto:[email-masked]> 
> 
> Do you think FCC will mind if we use the term OBU in this draft to 
> mean something else?  I, and a colleague, think that FCC would not mind.
> 
> Alex
> 
> [email-masked] <mailto:[email-masked]> 
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Sun, 4 Feb 2018 16:48:41 +0100

> -The related CFRs state that DSRC shall comply with the ASTM E 2213-03.

Thank you for the explanation.  It is useful to understand that DSRC is 
related to ASTM E 2213-03 and that neither refers to 802.11 OCB.

I think in works related to standards and products it is advantageous if 
there is correlation.

For example, in an ideal world, standards talk about "A" and the 
regulation also about "A" and the products and sofware are also labelled 
"A".

In our context, software is labelled "OCB" (kernel drivers), regulation 
talks "DSRC" and standards "802.11p" and "802.11 OCB".
> DSRC being uniquely a MAC and PHY communications service,

I thought "DSRC" is also about Applications and Use-cases.

> there here no 

It is one thing to have no restrictions, and another thing to reckon 
that IP is the networking layer.

> /Roadside unit (RSU). A Roadside Unit is a DSRC transceiver

Sigh, it is way different.

An RSU product has many transceivers inside.

> that is 

I think it should be updated to refer to this document.

> those bands./- [CFR 90.7 - Definitions] - October 2010

Thanks for the definitions.

They are far different from what we need in this draft.

I will see the other suggestions.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Sun, 4 Feb 2018 16:50:59 +0100

Le 02/02/2018 à 20:12, John Kenney a écrit :
> intentionally agnostic about what comes above the MAC layer of DSRC.  
> There is no reason why they should mention IP or any other higher layer 
> protocol, and the lack of mention of such protocols should be understood 
> to mean there are no regulatory requirements with respect to them.
> 
> than given by the FCC. That's asking for trouble. Please don't create 
> new definitions of OBE and RSE either. Tony Li's suggestion for an 
> IP-specific label seems like a good way to proceed.

Noted.

> 
> I also mention that the IEEE 802.11p, 1609.2, 1609.3 and 1609.4 
> standards do not use either of those terms.  In other words, from a WAVE 
> standards point of view, there is no distinction between an OBU and an 
> RSU.  I haven't been following this IETF work very closely, but it may 
> be worth re-examining whether any such distinctions are necessary for 
> you as well.

Noted.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Sun, 4 Feb 2018 17:07:44 +0100

I am adding this OBU ref for reference but I have a question:

> /On-Board unit (OBU). An On-Board Unit is a DSRCS transceiver that is 

Is DSRCS a typo? (correct DSRC).

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Sun, 4 Feb 2018 17:10:31 +0100

Le 29/01/2018 à 10:24, Carlos Jesús Bernardos Cano a écrit :
[...]

> - The use of MAY (to be interpreted as in RFC2119) in the terminology
> section does not seem appropriate to me. I don't think normative text
> applies to whether an OBRU may be ab IP router.

Following suggestions I propose we use "IP-OBU" instead of OBRU, and 
remove the MAY, if you do not mind.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Sun, 4 Feb 2018 18:07:36 +0100

> - The abstract mentions that in order to transmit IPv6 packets on IEEE
> 802.11-OCB, "there is a need to define a few parameters such as the
> supported Maximum Transmission Unit size on the 802.11-OCB link, the
> header format preceding the IPv6 header, the Type value within it, and
> others". But the MTU part of the draft does not use any normative text,
>   the header format is exactly the same than for IEEE 802.11, as the
> type value.

The MTU text currently says:
> The default MTU for IP packets on 802.11-OCB is 1500 octets.

I modify it to say:
 > The default MTU for IP packets on 802.11-OCB MUST be 1500 octets.

> - Section 1 lists two exceptions for 802.11-OCB compared to Ethernet.
> The first one is not different from regular 802.11,

I dont understand you.

The first one says that there are differences between IP-over-WiFi and 
IP-over-Ethernet.  These differences are in the headers.  To adapt to 
these differences an Ethernet Adaptation Layer is proposed.

Does this explain better?

Do I understand the worry correctly?

> but for the second
> one, the document only provides recommendations.

Should it provide something else?

> - I always thought that "WiFi" does not stand for "Wireless Fidelity".
> See https://boingboing.net/2005/11/08/wifi-isnt-short-for.html

Other persons commented, so at this time I propose to leave the def 
unchanged.

[...]
> 
> - In section 3, it is mentioned that "the operating environment
> (vehicular networks) brings in new perspectives" --> which are those
> (that are covered/tackled by the document?

The document does not cover these new 'perspectives'.  The 
'perspectives' are the ND operation, the handovers for Mobile IP, the 
security - the 3 perspectives are difference in OCB than in WiFi.  We 
dont describe any here.

Maybe new work is needed for ND-over-OCB, or Mobile IP with OCB access, 
or Security for OCB.

> - In section 4.1, does the text mean that the MTU SHOULD/MUST be 1500
> octects. If that is what is meant, this is really a normative thing
> that should be written using normative text. If it is just a
> recommendation, then this should be clearly written as such.

MUST be.

> - All the text of section 4.2.1 is not normative, but more a report of
> what is done today in existing implementations.

YEs, it is done today in existing WiFi implementations (not Ethernet).

> Is there any different
> there that is specific of 802.11-OCB?

No, there is nothing different.

I can change the text, but not sure what would be ok.

Should I move section 4.2.1 in an Appendix?

> - All subsections 4.x seem informative, not normative.

Similar to MTU, I could write in the 4.2 "Frame Format" that the 
EtherType MUST be 0x86DD (instead of just "is").  Would this make it 
more Normative?

In section 4.3 "LL Addresses" I could put "it is RECOMMENDED" instead of 
"it is recommended".

Sections 4.4. "Address Mapping" and 4.4.1 "Address Mapping -- Unicast" I 
could remove.

Section 4.4.2 "Address Mapping - Multicast" could be removed.

Section 4.5 "Stateless Autoconf" - I could write "the u/g bits MUST be 
opaque" instead of "are significant".

Section 4.6 "Subnet Structure" - could be removed altogether.

Are these ok with you?

> - The privacy part of section 5 is important, as it impacts the
> operation of IPv6 over this type of networks, so I think this deserves
> more attention.

Should I make a subsection called "Privacy Considerations" within the 
SEcurity considerations?

> - In section, H.1, more details about how the captures were obtained
> should be provided (HW, SW, etc.).

We added this if sounds ok:
> 	The packet is captured on the Host.  The Host is an IP-OBU
> 	containing an 802.11 interface in format PCI express (an ITRI
> 	product).  The kernel runs the ath5k software driver with
> 	modifications for OCB mode.  The capture tool is Wireshark.
> 	The file format for save and analyze is 'pcap'.  The packet is
> 	generated by the Router.  The Router is an IP-RSU (ITRI
> 	product).

> Authors, please respond to my questions/comments and address them in a
> new version of the document.

We submitted a new version, but please reply to my comments so I fully 
address the comments.

https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-13

Alex

---

From: François Simon <[email-masked]>
Date: Sun, 4 Feb 2018 12:56:13 -0500

I am not sure this was sent.  I apologize.  Fygs

From: François Simon [mailto:[email-masked]] 
Sent: Saturday, February 03, 2018 9:29 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: FW: [ipwave] Shepherd review of draft-ietf-ipwave-ipv6-over-80211ocb-12

Gentlemen,

Sincerely,

Francois Simon

Lojik Technologies

-----Original Message-----
From: François Simon [mailto:[email-masked]]
Sent: Friday, February 02, 2018 2:14 PM
To: [email-masked] <mailto:[email-masked]> 
Subject: FW: [ipwave] Shepherd review of draft-ietf-ipwave-ipv6-over-80211ocb-12

-----Original Message-----

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

> -5.9 GHz band allocated channels, frequency, max. EIRP, and spectrum 

> mask;

> mean something else?  I, and a colleague, think that FCC would not 

> mind.”///

> This is my personal view as I donot represent any involved interest.  

> If any one has questions, let me know.

Alex

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

> Petrescu

> Subject: Re: [ipwave] Shepherd review of

> draft-ietf-ipwave-ipv6-over-80211ocb-12

>> And even with that, it would not harm to include some short 

>> definition

---

From: Russ Housley <[email-masked]>
Date: Sun, 4 Feb 2018 14:56:08 -0500

> /“The problem with the FCC definition of OBU is that it has no relationship to IP.  Worse, that FCC definition has no indication that it MAY use IP somehow.  And here we say that all OBUs must use IP.  Do you see what I mean?”///
> //
> /“Do you think FCC will mind if we use the term OBU in this draft to mean something else?  I, and a colleague, think that FCC would not mind.”///
> //

I think it should be fairly easy to use the term OBU properly.  Some OBUs will make use of IP, and when they do, they MUST follow the guidance in this document.

Russ

---

From: François Simon <[email-masked]>
Date: Sun, 4 Feb 2018 21:59:13 -0500

> The default MTU for IP packets on 802.11-OCB MUST be 1500 octets.
-	The MTU text currently says: > The default MTU for IP packets on 802.11-OCB is 1500 octets. [Fygs: IEEE 802.11 OCB - MSDU size 2304]
-	I modify it to say:  > The default MTU for IP packets on 802.11-OCB MUST be 1500 octets. [Fygs: “is” was correct]

-----Original Message-----
From: its [mailto:[email-masked]] On Behalf Of Alexandre Petrescu
Sent: Sunday, February 04, 2018 12:08 PM
To: [email-masked]
Subject: Re: [ipwave] Shepherd review of draft-ietf-ipwave-ipv6-over-80211ocb-12

I dont understand you.

The first one says that there are differences between IP-over-WiFi and IP-over-Ethernet.  These differences are in the headers.  To adapt to these differences an Ethernet Adaptation Layer is proposed.

> See https://boingboing.net/2005/11/08/wifi-isnt-short-for.html

Other persons commented, so at this time I propose to leave the def unchanged.

[...]
> (that are covered/tackled by the document?

The document does not cover these new 'perspectives'.  The 'perspectives' are the ND operation, the handovers for Mobile IP, the security - the 3 perspectives are difference in OCB than in WiFi.  We dont describe any here.

Maybe new work is needed for ND-over-OCB, or Mobile IP with OCB access, or Security for OCB.

MUST be.

> - All subsections 4.x seem informative, not normative.

Similar to MTU, I could write in the 4.2 "Frame Format" that the EtherType MUST be 0x86DD (instead of just "is").  Would this make it more Normative?

In section 4.3 "LL Addresses" I could put "it is RECOMMENDED" instead of "it is recommended".

Sections 4.4. "Address Mapping" and 4.4.1 "Address Mapping -- Unicast" I could remove.

Section 4.5 "Stateless Autoconf" - I could write "the u/g bits MUST be opaque" instead of "are significant".

Are these ok with you?

> operation of IPv6 over this type of networks, so I think this deserves 

Should I make a subsection called "Privacy Considerations" within the SEcurity considerations?

> new version of the document.

We submitted a new version, but please reply to my comments so I fully address the comments.

Alex

---

From: François Simon <[email-masked]>
Date: Sun, 4 Feb 2018 22:30:47 -0500

Mr. Petrescu,

" I thought "DSRC" is also about Applications and Use-cases."
-	No; It is a Dedicated Short Range Communication service.  I believe that SAE DSRC Technical Committee (US) is defining applications and use-cases.

“It is one thing to have no restrictions, and another thing to reckon that IP is the networking layer.”
-	Layer 3 (Network Layer)
*	CLNP <https://en.wikipedia.org/wiki/CLNP>  Connectionless Networking Protocol
*	EGP <https://en.wikipedia.org/wiki/Exterior_Gateway_Protocol>  Exterior Gateway Protocol
*	EIGRP <https://en.wikipedia.org/wiki/EIGRP>  Enhanced Interior Gateway Routing Protocol
*	ICMP <https://en.wikipedia.org/wiki/Internet_Control_Message_Protocol>  Internet Control Message Protocol
*	IGMP <https://en.wikipedia.org/wiki/IGMP>  Internet Group Management Protocol
*	IGRP <https://en.wikipedia.org/wiki/IGRP>  Interior Gateway Routing Protocol
*	IPv4 <https://en.wikipedia.org/wiki/IPv4>  Internet Protocol version 4
*	IPv6 <https://en.wikipedia.org/wiki/IPv6>  Internet Protocol version 6
*	IPSec <https://en.wikipedia.org/wiki/IPSec>  Internet Protocol Security
*	IPX <https://en.wikipedia.org/wiki/IPX>  Internetwork Packet change
*	NAT <https://en.wikipedia.org/wiki/Network_address_translation>  Network Address Translation
*	Routed-SMLT <https://en.wikipedia.org/wiki/R-SMLT> 
*	SCCP <https://en.wikipedia.org/wiki/Signalling_Connection_Control_Part>  Signalling Connection Control Part
*	AppleTalk DDP
*	GRE <https://en.wikipedia.org/wiki/Generic_Routing_Encapsulation>  Generic Routing Encapsulation for tunneling
*	OSPF <https://en.wikipedia.org/wiki/OSPF>  Open Shortest Path First
*	RIP <https://en.wikipedia.org/wiki/Routing_Information_Protocol>  Routing Information Protocol
*	HSRP <https://en.wikipedia.org/wiki/Hot_Standby_Router_Protocol>  Hot Standby Router protocol
*	VRRP <https://en.wikipedia.org/wiki/Virtual_Router_Redundancy_Protocol>  Virtual Router Redundancy Protocol
“An RSU product has many transceivers inside.”
-	An RSE may have multiple transceivers.

-----Original Message-----
From: Alexandre Petrescu [mailto:[email-masked]] 
Sent: Sunday, February 04, 2018 10:49 AM
To: François Simon <[email-masked]>
Cc: [email-masked]
Subject: Re: [ipwave] Shepherd review of draft-ietf-ipwave-ipv6-over-80211ocb-12

> -The related CFRs state that DSRC shall comply with the ASTM E 2213-03.

Thank you for the explanation.  It is useful to understand that DSRC is related to ASTM E 2213-03 and that neither refers to 802.11 OCB.

I think in works related to standards and products it is advantageous if there is correlation.

For example, in an ideal world, standards talk about "A" and the regulation also about "A" and the products and sofware are also labelled "A".

In our context, software is labelled "OCB" (kernel drivers), regulation talks "DSRC" and standards "802.11p" and "802.11 OCB".

> there here no
> restriction on Transport and Network protocols that can be used 

It is one thing to have no restrictions, and another thing to reckon that IP is the networking layer.

Alex

---

From: Tony Li <[email-masked]>
Date: Sun, 4 Feb 2018 20:33:34 -0800

François,

> -       The MTU text currently says: > The default MTU for IP packets on 802.11-OCB is 1500 octets. [Fygs: IEEE 802.11 OCB - MSDU size 2304]

Be that as it may, we really need 802.11-OCB to have an MTU of 1500. 

> -       I modify it to say:  > The default MTU for IP packets on 802.11-OCB MUST be 1500 octets. [Fygs: “is” was correct]

If you want us to use normative language, then per RFC 2119, we need to use MUST. The word “is” has no normative connotations.

Tony

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 5 Feb 2018 08:52:02 +0100

Le 05/02/2018 à 03:59, François Simon a écrit :
> /The MTU text currently says:/
> 
> /> The default MTU for IP packets on 802.11-OCB is 1500 octets./
> 
> /I modify it to say:/
> 
> / > The default MTU for IP packets on 802.11-OCB MUST be 1500 octets.///
> 
> -// The MTU text currently says:> The default MTU for IP packets on 
> 802.11-OCB is 1500 octets.*[Fygs: IEEE****802.11 OCB -****MSDU size 
> 2304****]*

It is good to know the MSDU size.  However, here we talk about MTU, not 
MSDU.

The 'MTU' is what one sees when typing 'ifconfig'.

> -I modify it to say:> The default MTU for IP packets on 802.11-OCB MUST 
> be 1500 octets.*[Fygs: “is” was correct]*

"Is" may have been correct as English expression, but if we want to make 
it Normative text then we must use normative words such as MUST, SHOULD, 
MAY, in capitals.

Alex

>   > The default MTU for IP packets on 802.11-OCB MUST be 1500 octets.
> 
>> Seehttps://boingboing.net/2005/11/08/wifi-isnt-short-for.html
> 
> [email-masked]<mailto:[email-masked]>
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 5 Feb 2018 09:07:32 +0100

Le 05/02/2018 à 04:30, François Simon a écrit :
> Mr. Petrescu,
> 
> /"//I thought "DSRC" is also about Applications and Use-cases.//"///
> 
> -// No; It is a Dedicated Short Range Communication service.  
> IbelievethatSAE DSRCTechnical Committee (US) is defining applicationsand 
> use-cases.//
> 
> //
> 
> “/It is one thing to have no restrictions, and another thing to reckon 
> that IP is the networking layer.//”///
> 
> -//Layer 3 (Network Layer)

Well, I am happy you list all these network layer protocols.

As a side note, it would be good to let know wikipedia to refer here. 
(there are details that situate the listed protocols to be a little bit 
above network layer, not right at the network layer).

Among the listed protocols the ones precisely at networking layer are: 
IPv4, IPv6 and IPX.  All the others are a little bit above.

I have seen IPv4 and IPv6 over 802.11 OCB, but I have not seen IPX run 
on 802.11 OCB.

Stating that IPX _could_ run on 802.11 OCB is a theoretical assumption, 
but in practice you never know.

There is a huge difference between stating IP runs on 802.11 OCB and 
stating that IPX runs on 802.11 OCB.

The protocols I have seen running on 802.11 OCB are IP, ETSI 
geonetworking and BSM.

I think it would be good that DSRC said "802.11 OCB supports 
network-layer  protocols such as IP, ETSI geonetworking and BSM", rather 
than saying "802.11 OCB supports _any_ network layer parotocols".

> ·___CLNP_<https://en.wikipedia.org/wiki/CLNP>Connectionless Networking 
> Protocol
> 
> ·___EGP_<https://en.wikipedia.org/wiki/Exterior_Gateway_Protocol>Exterior Gateway 
> Protocol
> 
> ·___EIGRP_<https://en.wikipedia.org/wiki/EIGRP>Enhanced Interior Gateway 
> Routing Protocol
> 
> ·___ICMP_<https://en.wikipedia.org/wiki/Internet_Control_Message_Protocol>Internet 
> Control Message Protocol
> 
> ·___IGMP_<https://en.wikipedia.org/wiki/IGMP>Internet Group Management 
> Protocol
> 
> ·___IGRP_<https://en.wikipedia.org/wiki/IGRP>Interior Gateway Routing 
> Protocol
> 
> ·___IPv4_<https://en.wikipedia.org/wiki/IPv4>Internet Protocol version 4
> 
> ·___IPv6_<https://en.wikipedia.org/wiki/IPv6>Internet Protocol version 6
> 
> ·___IPSec_<https://en.wikipedia.org/wiki/IPSec>Internet Protocol Security
> 
> ·___IPX_<https://en.wikipedia.org/wiki/IPX>Internetwork Packet change
> 
> ·___NAT_<https://en.wikipedia.org/wiki/Network_address_translation>Network 
> Address Translation
> 
> ·___Routed-SMLT_<https://en.wikipedia.org/wiki/R-SMLT>
> 
> ·___SCCP_<https://en.wikipedia.org/wiki/Signalling_Connection_Control_Part>Signalling 
> Connection Control Part
> 
> ·AppleTalk DDP
> 
> ·___GRE_<https://en.wikipedia.org/wiki/Generic_Routing_Encapsulation>Generic 
> Routing Encapsulation for tunneling
> 
> ·___OSPF_<https://en.wikipedia.org/wiki/OSPF>Open Shortest Path First
> 
> ·___RIP_<https://en.wikipedia.org/wiki/Routing_Information_Protocol>Routing 
> Information Protocol
> 
> ·___HSRP_<https://en.wikipedia.org/wiki/Hot_Standby_Router_Protocol>Hot 
> Standby Router protocol
> 
> ·___VRRP_<https://en.wikipedia.org/wiki/Virtual_Router_Redundancy_Protocol>Virtual 
> Router Redundancy Protocol
> 
> “/An RSU product has many transceivers inside.//”///
> 
> -// An RSE may have multiple transceivers.

I think there is a huge terminology issue here.

"RSE" is not used, I never heard it.

Most people say "RSU" to mean a "box" whereas the FCC term RSU seem to 
mean just a "transceiver".  A "transceiver" is typically a "modem".

Products are marketed as "RSU" and they are boxes.  They have much more 
inside than just the "transceiver".  What could be understood as 
'transceiver' (transmitter/receiver) is the modem 
(modulator/demodulator) or 'baseband' processor, that sits on an 
extension board that itself sits on a motherboard.  There is power 
supply too.  All these make an "RSU".  Some RSUs have even more devices 
like solar panels, mechanical hooks, sophisticated antennas, EV charge 
stations, LTE modems, optical backhaul and more.

BEcause of this discrepancy, I prefer to forget use his "RSU" term in 
this IP-over-OCB document just as for information.  RAther, use the 
"IP-RSU" to mean what we want it to mean.

Alex

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

---

From: François Simon <[email-masked]>
Date: Mon, 5 Feb 2018 10:10:37 -0500

"Is DSRCS a typo? (correct DSRC)."
-	No typo. DSRCS stands for “Dedicated Short Range Communication Service”

-----Original Message-----
From: Alexandre Petrescu [mailto:[email-masked]] 
Sent: Sunday, February 04, 2018 11:08 AM
To: François Simon <[email-masked]>
Cc: [email-masked]
Subject: Re: [ipwave] Shepherd review of draft-ietf-ipwave-ipv6-over-80211ocb-12

Alex

---

From: François Simon <[email-masked]>
Date: Mon, 5 Feb 2018 10:36:56 -0500

“I think it should be fairly easy to use the term OBU properly.  Some OBUs will make use of IP, and when they do, they MUST follow the guidance in this document.”

*	An OBU does not use IP; It provide the service to transport a MPDU (MAC) which contains the IPv6 frame (Network Layer).

From: its [mailto:[email-masked]] On Behalf Of Russ Housley
Sent: Sunday, February 04, 2018 2:56 PM
To: [email-masked]
Subject: Re: [ipwave] Shepherd review of draft-ietf-ipwave-ipv6-over-80211ocb-12

Russ

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 5 Feb 2018 16:40:40 +0100

Le 05/02/2018 à 16:10, François Simon a écrit :
> /"//Is DSRCS a typo? (correct DSRC).//"///
> 
> -// No typo. DSRCS stands for “Dedicated Short Range Communication Service”

So, in order to define OBU in terms of DSRCS one has to define first 
DSRCS, all while caring to avoid loops.  I think it can become too lengthy.

Alex

---

From: [email-masked]
Date: Mon, 5 Feb 2018 17:13:38 -0800

Hi Dick,

> [RR] Not true. You may want to require it when using 802.11 as a first hop on an ethernet LAN, however no such requirement is necessary for example when broadcasting BSMs or SPaT/MAP ADUs. 

AFAIK, those have nothing to do with IP.  What you wanna do with your OBU that is NOT IP is completely outside of the scope of this document, working group, and mailing list.

> [RR] Don’t make such blanket normative statements without qualifiers.

Sorry, but that’s just the basics of working with RFC 2119.

> You might also note that in 1609.3 you will find the following interesting ASN.1:
> “dot3WsmMaxLength OBJECT-TYPE
> SYNTAX INTEGER (1..2302)
> MAX-ACCESS read-write
> STATUS current
> DESCRIPTION
> "Maximum size in octets of the variable length portion
> of a WSM, including data.
> The default value is 1400. Max value is
> 802.11 MAC MSDU size minus EtherType size (2304 minus
> 2 = 2302)."
> ::= { dot3LocalInfo 4”

That’s very unfortunate and unsuitable for IP over 802.11-OCB.

The default 1500 byte MTU is pretty much a necessity for inter-operation with the rest of the Internet. We’ve done other media with other MTUs before and been repeatedly bitten by fragmentation. Yes, you can use other MTUs in limited settings, but it requires careful site engineering and planning.  Dissimilar MTUs on the same media cause all sorts of black-hole problems. The best solution is to simply start everyone off at 1500.

Tony

---

From: François Simon <[email-masked]>
Date: Mon, 5 Feb 2018 21:25:09 -0500

" So, in order to define OBU in terms of DSRCS one has to define first DSRCS, all while caring to avoid loops.  I think it can become too lengthy."
-	Dedicated Short-Range Communications Services (DSRCS). - The use of radio techniques to transfer data over short distances between roadside and mobile
		units, between mobile units, and between portable and mobile units to perform operations related to the improvement of traffic flow, traffic safety,
		and other intelligent transportation service applications in a variety of environments. DSRCS systems may also transmit status and instructional
		messages related to the units involved. [ Ref. 47 CFR 90.7 – Definitions]

-----Original Message-----
From: Alexandre Petrescu [mailto:[email-masked]] 
Sent: Monday, February 05, 2018 10:41 AM
To: François Simon <[email-masked]>
Cc: [email-masked]
Subject: Re: [ipwave] Shepherd review of draft-ietf-ipwave-ipv6-over-80211ocb-12

> -// No typo. DSRCS stands for “Dedicated Short Range Communication Service”

So, in order to define OBU in terms of DSRCS one has to define first DSRCS, all while caring to avoid loops.  I think it can become too lengthy.

Alex

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

---

From: [email-masked]
Date: Mon, 5 Feb 2018 21:07:59 -0800

Hi Dick,

> What you wanna do with your OBU that is NOT IP is completely outside of the scope of this document, working group, and mailing list.
> [RR] Agreed. I’m just looking to make sure that the “requirements on OBUs” coming from the IETF are conditioned on the use of IP and 802.11 5.9GHz.    

I don’t think that there are any requirements that the IETF can place on an OBU at all. Obviously, they should only apply to IP-OBUs.

> [RR] I suspect even RFC 2119 allows for conditionally mandatory requirements such as “when A is true, then B shall be …”.   

True, but there’s no qualification necessary here.  The default MTU for 802.11-OCB should be 1500.

>  
> The default 1500 byte MTU is pretty much a necessity for inter-operation with the rest of the Internet. 
> [RR] By Internet, I assume you mean 802.3 (bridged ) LANs (aka ethernet), and yes, such LANs dominate the Internet landscape. 

Not just those, but all other media that we use, admittedly in rapidly declining population, but it include HFC, SONET, ATM, FR, FDDI, ….  (Yes, I’m dating myself).

> Dissimilar MTUs on the same media cause all sorts of black-hole problems. 
> [RR] Not sure what you mean by “same medium” (media is plural).  I’m guessing the point was that problems occur when the path between source and destination contains links with (wildly) different MTUs which most people would agree with.  

The big problem is hosts that are prepared to only receive packets at a smaller MTU when the transmitter is configured for a larger MTU.  The receiver simply has no buffer adequate and ends up dropping frames.

> The best solution is to simply start everyone off at 1500.
> [RR] Agreed, assuming that at some point an 802.3 LAN will be part of the transmission infrastructure, and that’s a real good bet most of the time.  

P = 0.99999

Tony

---

From: Abdussalam Baryun <[email-masked]>
Date: Tue, 6 Feb 2018 09:30:35 +0200

On Tue, Feb 6, 2018 at 3:13 AM, <[email-masked]> wrote:

>
> Hi Dick,
>
> * > The default MTU for IP packets on 802.11-OCB MUST be 1500 octets.*
> -       The MTU text currently says: > The default MTU for IP packets on
> 802.11-OCB is 1500 octets. *[Fygs: IEEE **802.11 OCB - **MSDU size 2304]*
>
>
> *[RR] Not true. You may want to require it when using 802.11 as a first
> hop on an ethernet LAN, however no such requirement is necessary for
> example when broadcasting BSMs or SPaT/MAP ADUs. *
>
>
>
> AFAIK, those have nothing to do with IP.  What you wanna do with your OBU
> that is NOT IP is completely outside of the scope of this document, working
> group, and mailing list.
>

I don't agree to use 'out of scope', it was used before many times in this
list, and it is not true, I asked the WG chair and no respond, even the AD
did not answer. I believe that said that there was NO REQUIREMENT, so the
respond needs to say there is a requirement because ,,,,,,,,,,,,,,,,,,(your
reason ),,,,,,, but you want to use the words ' OUT OF SCOPE', as some used
before which was not helpful in discussions,

AB

---

From: Abdussalam Baryun <[email-masked]>
Date: Tue, 6 Feb 2018 09:38:30 +0200

On Tue, Feb 6, 2018 at 7:07 AM, <[email-masked]> wrote:

>
> Hi Dick,
>
>
> What you wanna do with your OBU that is NOT IP is completely outside of
> the scope of this document, working group, and mailing list.
> *[RR] Agreed. I’m just looking to make sure that the “requirements on
> OBUs” coming from the IETF are conditioned on the use of IP and 802.11
> 5.9GHz.    *
>
>
>
> I don’t think that there are any requirements that the IETF can place on
> an OBU at all. Obviously, they should only apply to IP-OBUs.
>
> *[RR] I suspect even RFC 2119 allows for conditionally mandatory
> requirements such as “when A is true, then B shall be …”.   *
>
>
>
> *[RR] By Internet, I assume you mean 802.3 (bridged ) LANs (aka ethernet),
> and yes, such LANs dominate the Internet landscape. *
>
>
>
> Not just those, but all other media that we use, admittedly in rapidly
> declining population, but it include HFC, SONET, ATM, FR, FDDI, ….  (Yes,
> I’m dating myself).
>
>
> *[RR] Not sure what you mean by “same medium” (media is plural).  I’m
> guessing the point was that problems occur when the path between source and
> destination contains links with (wildly) different MTUs which most people
> would agree with.  *
>
>
>
> The big problem is hosts that are prepared to only receive packets at a
> smaller MTU when the transmitter is configured for a larger MTU.  The
> receiver simply has no buffer adequate and ends up dropping frames.
>
>
> *[RR] Agreed, assuming that at some point an 802.3 LAN will be part of the
> transmission infrastructure, and that’s a real good bet most of the time.  *
>
>
If that is the assumption, then the WG MUST write it into the draft, it is
an important assumption for such requirement. I preferred no such
assumption, but some want the easy way.

AB

---

From: François Simon <[email-masked]>
Date: Tue, 6 Feb 2018 05:21:37 -0500

" The protocols I have seen running on 802.11 OCB are IP, ETSI geonetworking and BSM."
-	BSM is not a protocol. The Basic Safety Message (BSM) is a message used in V2V applications and is defined in SAE j2735 standard -   “Dedicated Short Range Communications (DSRC) Message Set Dictionary”.

-----Original Message-----
From: Alexandre Petrescu [mailto:[email-masked]] 
Sent: Monday, February 05, 2018 3:08 AM
To: François Simon <[email-masked]>
Cc: [email-masked]
Subject: Re: [ipwave] Shepherd review of draft-ietf-ipwave-ipv6-over-80211ocb-12

Le 05/02/2018 à 04:30, François Simon a écrit :
> IbelievethatSAE DSRCTechnical Committee (US) is defining 
> applicationsand use-cases.//
> 
> //
> 

As a side note, it would be good to let know wikipedia to refer here. 
(there are details that situate the listed protocols to be a little bit above network layer, not right at the network layer).

I have seen IPv4 and IPv6 over 802.11 OCB, but I have not seen IPX run on 802.11 OCB.

Stating that IPX _could_ run on 802.11 OCB is a theoretical assumption, but in practice you never know.

There is a huge difference between stating IP runs on 802.11 OCB and stating that IPX runs on 802.11 OCB.

The protocols I have seen running on 802.11 OCB are IP, ETSI geonetworking and BSM.

I think it would be good that DSRC said "802.11 OCB supports network-layer  protocols such as IP, ETSI geonetworking and BSM", rather than saying "802.11 OCB supports _any_ network layer parotocols".

> ·___EGP_<https://en.wikipedia.org/wiki/Exterior_Gateway_Protocol>Exter
> ior Gateway Protocol
> 
> ·___EIGRP_<https://en.wikipedia.org/wiki/EIGRP>Enhanced Interior 
> Gateway Routing Protocol
> 

Most people say "RSU" to mean a "box" whereas the FCC term RSU seem to mean just a "transceiver".  A "transceiver" is typically a "modem".

Products are marketed as "RSU" and they are boxes.  They have much more inside than just the "transceiver".  What could be understood as 'transceiver' (transmitter/receiver) is the modem
(modulator/demodulator) or 'baseband' processor, that sits on an extension board that itself sits on a motherboard.  There is power supply too.  All these make an "RSU".  Some RSUs have even more devices like solar panels, mechanical hooks, sophisticated antennas, EV charge stations, LTE modems, optical backhaul and more.

BEcause of this discrepancy, I prefer to forget use his "RSU" term in this IP-over-OCB document just as for information.  RAther, use the "IP-RSU" to mean what we want it to mean.

Alex

> Thank you for the explanation.  It is useful to understand that DSRC 
> is related to ASTM E 2213-03 and that neither refers to 802.11 OCB.
> 
> regulation also about "A" and the products and sofware are also 
> labelled "A".
> 
> In our context, software is labelled "OCB" (kernel drivers), 
> regulation talks "DSRC" and standards "802.11p" and "802.11 OCB".
>

---

From: <[email-masked]>
Date: Tue, 6 Feb 2018 11:47:23 +0000

Hi,
perhaps this was just a typo meaning Basic Transport Protocol (BTP) running over geonetworking in ETSI ITS?
Best Regards
Dirk

From: its [mailto:[email-masked]] On Behalf Of François Simon
Sent: Dienstag, 6. Februar 2018 11:22
To: 'Alexandre Petrescu' <[email-masked]>
Cc: [email-masked]
Subject: Re: [ipwave] Shepherd review of draft-ietf-ipwave-ipv6-over-80211ocb-12

•       BSM is not a protocol. The Basic Safety Message (BSM) is a message used in V2V applications and is defined in SAE j2735 standard -   “Dedicated Short Range Communications (DSRC) Message Set Dictionary”.

-----Original Message-----
From: Alexandre Petrescu [mailto:[email-masked]]
Sent: Monday, February 05, 2018 3:08 AM
To: François Simon <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [ipwave] Shepherd review of draft-ietf-ipwave-ipv6-over-80211ocb-12

> ·___ICMP_<https://en.wikipedia.org/wiki/Internet_Control_Message_Proto

> col>Internet

> ·___IPv4_<https://en.wikipedia.org/wiki/IPv4>Internet Protocol version

> 4

> ·___IPv6_<https://en.wikipedia.org/wiki/IPv6>Internet Protocol version

> 6

> ·___IPSec_<https://en.wikipedia.org/wiki/IPSec>Internet Protocol

> Security

> ·___NAT_<https://en.wikipedia.org/wiki/Network_address_translation>Net

> work

> ·___SCCP_<https://en.wikipedia.org/wiki/Signalling_Connection_Control_

> Part>Signalling

> ·___GRE_<https://en.wikipedia.org/wiki/Generic_Routing_Encapsulation>G

> eneric

> ·___RIP_<https://en.wikipedia.org/wiki/Routing_Information_Protocol>Ro

> uting

> ·___HSRP_<https://en.wikipedia.org/wiki/Hot_Standby_Router_Protocol>Ho

> t

> ·___VRRP_<https://en.wikipedia.org/wiki/Virtual_Router_Redundancy_Prot

> ocol>Virtual

Alex

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

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

>> 47 mainly Parts 90 and 95. The last update is dated October 1st,

>> 2010;

>> -This includes the ASTM E 2213-03 standard: “Standard Speciﬁcation

>> for

> I think in works related to standards and products it is advantageous

> if there is correlation.

>> -Individual Channel use: Safety applications, non-safety

>> applications,

>> (except for the LCC specified by reference in IEEE 802.11 OCB). In

>> the

>> US, the WAVE standards (IEEE 1609 series) specify these protocols

>> when

>> licensed to operate. However, portable or hand-held RSUs are

>> permitted

>> normally mounted in or on a vehicle, or which in some instances may

>> be

>> to transmit on one or more radio frequency (RF) channels. Except

>> where

>> Unlicensed National Information Infrastructure (UNII) Bands follow

>> the

>> relationship to IP.  Worse, that FCC definition has no indication

>> that

>> it MAY use IP somehow.  And here we say that all OBUs must use IP.

>> Do

>>> to provide context. The RSU term is also defined outside the IETF

>>> and

>>> *[Fygs: The**definitions**was issued by the FCC 20 years ago.  I

>>> have

>> relationship to IP.  Worse, that FCC definition has no indication

>> that

>> it MAY use IP somehow.  And here we say that all OBUs must use IP.

>> Do

>>[email-masked]<mailto:[email-masked]<mailto:[email-masked]%3cmailto:[email-masked]>>

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 6 Feb 2018 16:40:02 +0100

Le 06/02/2018 à 01:32, Dick Roy a écrit :
> ------------------------------------------------------------------------
> 
> *From:*its [mailto:[email-masked]] *On Behalf Of *Tony Li
> *Sent:* Sunday, February 4, 2018 8:34 PM
> *To:* François Simon
> *Cc:* Alexandre Petrescu; [email-masked]
> *Subject:* Re: [ipwave] Shepherd review of 
> / > The default MTU for IP packets on 802.11-OCB MUST be 1500 octets./
> 
> -The MTU text currently says: > The default MTU for IP packets on 
> 802.11-OCB is 1500 octets.***[Fygs: IEEE **802.11 OCB - **MSDU size 2304]*
> 
> */[RR] Not true. You may want to require it when using 802.11 as a first 
> example when broadcasting BSMs or SPaT/MAP ADUs. /*

I agree.

These non-IP ADUs have other requirements.

When these ADUs are transmitted over 802.11 OCB they must respect the 
802.11 OCB MTU.  That is not a problem, because the MTU of 802.11 in OCB 
mode is much larger than typical BSM messages (1500 bytes vs 400 bytes, 
or so).

So we stay that way th 1500 bytes.

Alex
> 
> 
> 
> -I modify it to say: > The default MTU for IP packets on 802.11-OCB MUST 
> be 1500 octets.***[Fygs: “is” was correct]*
> 
> If you want us to use normative language, then per RFC 2119, we need to 
> use MUST. The word “is” has no normative connotations.
> 
> */[RR] Don’t make such blanket normative statements without qualifiers. 
> You might also note that in 1609.3 you will find the following 
> interesting ASN.1:/*
> 
> */“/*dot3WsmMaxLength OBJECT-TYPE
> 
> SYNTAX INTEGER (1..2302)
> 
> MAX-ACCESS read-write
> 
> STATUS current
> 
> DESCRIPTION
> 
> ::= { dot3LocalInfo 4”*//*
> 
> Tony
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 6 Feb 2018 16:41:29 +0100

If I add DSRCS, and DSRC, and OBU - it makes for 3 terms only 
tangentially relevant.

I find it too much.

There are two very relevant terms: IP-OBU and IP-RSU.

We need to have more relevant terms than tangentially relevant terms.

Le 06/02/2018 à 03:25, François Simon a écrit :
> /"//So, in order to define OBU in terms of DSRCS one has to define first 
> DSRCS, all while caring to avoid loops.  I think it can become too 
> lengthy.//"///
> 
> -///Dedicated Short-Range Communications////Services (DSRCS)/.-The use 
> of radio techniquesto transfer data over short distancesbetween roadside 
> and mobile
> 
>         units, between mobile units, and betweenportable and mobile
>         units to performoperations related to the improvementof traffic
>         flow, traffic safety,
> 
>         and other intelligent transportationservice applications in a
>         varietyof environments. DSRCS systems mayalso transmit status
>         and instructional
> 
>         messages related to the units involved.[ Ref. 47 CFR90.7 –
>         Definitions]
> 
>> Cc:[email-masked]<mailto:[email-masked]>
> 
>>>[email-masked]<mailto:[email-masked]<mailto:[email-masked]<mailto:[email-masked]>>
> 
>> 
> 
>>> 
> 
>> 
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 6 Feb 2018 16:45:54 +0100

> running over geonetworking in ETSI ITS?

Perhaps.

This comes from a larger problem: the way we talk about protocols with 
programmers is some times in terms of what wireshark shows.

The dissectors for ETSI ITS (BTP, CAM, DENM, more) are not integrated in 
the main wireshark.  So, depending on the wireshark version, depending 
on the ETSI ITS standard version so depending on the dissectors version, 
the programmers see different protocols on the screen.

But yes, I wanted indeed to say ETSI ITS protocols (presumably BTP).

Alex

> 
> Best Regards
> Dirk
> 
> *From:*its [mailto:[email-masked]] *On Behalf Of *François Simon
> *Sent:* Dienstag, 6. Februar 2018 11:22
> *To:* 'Alexandre Petrescu' <[email-masked]>
> *Cc:* [email-masked]
> "///The protocols I have seen running on 802.11 OCB are IP, ETSI 
> geonetworking and BSM."/
> 
> -BSM is not a protocol. The Basic Safety Message (BSM) is amessage used 
> in V2V applications and is defined in SAE j2735 standard - “Dedicated 
> Short Range Communications (DSRC) Message Set Dictionary”.
> 
> To: François Simon <[email-masked] <mailto:[email-masked]>>
>> To: François Simon <[email-masked] <mailto:[email-masked]>>
> 
>> Cc:[email-masked] <mailto:[email-masked]>
> 
>>>[email-masked]<mailto:[email-masked] 
> <mailto:[email-masked]%3cmailto:[email-masked]>>
> 
>> 
> 
>>> 
> 
>> 
>

---

From: François Simon <[email-masked]>
Date: Tue, 6 Feb 2018 11:40:19 -0500

Mr. Petrescu,

“There are two very relevant terms: IP-OBU and IP-RSU.”
-	If the Working Group thinks these terms are relevant, then so bid. I respectfully disagree. Furthermore, I have nothing more to add to this discussion; I have provided all US relevant definitions.

Sincerely,

Francois Simon
Lojik Technologies

-----Original Message-----
From: Alexandre Petrescu [mailto:[email-masked]] 
Sent: Tuesday, February 06, 2018 10:41 AM
To: François Simon <[email-masked]>
Cc: [email-masked]
Subject: Re: FW: [ipwave] Shepherd review of draft-ietf-ipwave-ipv6-over-80211ocb-12

If I add DSRCS, and DSRC, and OBU - it makes for 3 terms only tangentially relevant.

I find it too much.

Le 06/02/2018 à 03:25, François Simon a écrit :
> /"//So, in order to define OBU in terms of DSRCS one has to define 
> first DSRCS, all while caring to avoid loops.  I think it can become 
> too lengthy.//"///
> 
> of radio techniquesto transfer data over short distancesbetween 
> roadside and mobile
> 
>> To: François Simon <[email-masked]<mailto:[email-masked] <mailto:[email-masked]<mailto:[email-masked]> >>
> 
>>>[email-masked]<mailto:[email-masked]<mailto:[email-masked]<mailto:its@ietf <mailto:[email-masked]<mailto:[email-masked]<mailto:[email-masked]<mailto:its@ietf> .
>>>org>>
> 
>> 
> 
>>> 
> 
>> 
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 6 Feb 2018 17:47:37 +0100

Le 06/02/2018 à 17:40, François Simon a écrit :
> Mr. Petrescu,
> 
> /“//There are two very relevant terms: IP-OBU and IP-RSU.//”///
> 
> -// IftheWorkingGroupthinksthese terms are relevant, thenso 
> bid.Irespectfully disagree.Furthermore,I have nothing more to add to 
> this discussion;I have provided allUS relevant definitions.

I thank you for the definitions.

I propose we go this way:

Copy the definitions from your emails for DSRCS, and then DSRC and then 
OBU and RSU in terms of DSRCS and of DSRC.

But have these definitions (DSRCS, DSRC, OBU and RSU) in an Appendix, 
not in the Terminology section.

The Terminology section would list IP-OBU and IP-RSU and refer to the 
Appendix.

Alex

>>> To: François Simon <[email-masked]<mailto:[email-masked]<mailto:[email-masked]<mailto:[email-masked]>>>
> 
>> 
> 
>>>> /On-Board unit (OBU). An On-Board Unit is a DSRCS transceiver that 
> 
>>>> is
> 
>> 
> 
>>> 
> 
>> 
> 
>>>> is either mobile or stationary. The OBUs receive and contend for 
> 
>>>> time
> 
>> 
> 
>>> 
> 
>> 
> 
>>>> operation or human passage is permitted. The OBUs mounted in 
> 
>>>> vehicles
> 
>> 
> 
>>> 
> 
>> 
> 
>>>> licensed by rule under part 95 of this chapter. OBU operations in 
> 
>>>> the
> 
>> 
> 
>>> 
> 
>> 
> 
>>>> Depending of the reader. If one is familiar with DSRC, OBU and RSU 
> 
>>>> as
> 
>> 
> 
>>> 
> 
>> 
> 
>>>> are not registered and could be used for other definitions 
> 
>>>> (something
> 
>> 
> 
>>> 
> 
>> 
> 
>>>> like
> 
>> 
> 
>>> 
> 
>> 
> 
>>>> “ATM”: Asynchronous Transfer Mode and Automatic Teller Machine😊).
> 
>>>> My
> 
>> 
> 
>>> 
> 
>> 
> 
>>>>[email-masked]<mailto:[email-masked]<mailto:[email-masked]<mailto:its@ietf<mailto:[email-masked]<mailto:[email-masked]<mailto:[email-masked]<mailto:its@ietf>.
> 
>>>>org>>
> 
>> 
> 
>>> 
> 
>> 
> 
>>>> 
> 
>> 
> 
>>> 
> 
>> 
>

---

From: Abdussalam Baryun <[email-masked]>
Date: Tue, 6 Feb 2018 19:40:20 +0200

Hi Alex and Francois,

I don't mind putting any clear definition in terms but should be used in
the body consistently within the draft. Also we need to try to make the
definition short and to the point. I am not very interested in this IP-xxx,
however, I like the terminology used in RFC8200. so we should mention that
our IP-units are nodes or routers, in terminology the definition word
'computer' used is not consistent with other ietf RFCs.

AB

On Tue, Feb 6, 2018 at 6:47 PM, Alexandre Petrescu <
[email-masked]> wrote:

>> bid.Irespectfully disagree.Furthermore,I have nothing more to add to this
>> discussion;I have provided allUS relevant definitions.
>>
>
> But have these definitions (DSRCS, DSRC, OBU and RSU) in an Appendix, not
> in the Terminology section.
>
>>> lengthy.
>> To: François Simon <[email-masked]<mailto:[email-masked]<mailto:
>>>> [email-masked]<mailto:[email-masked]>>>
>>>>
>>>
>>
>>>

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 6 Feb 2018 19:06:05 +0100

Le 06/02/2018 à 18:40, Abdussalam Baryun a écrit :
> the body consistently within the draft.

IP-OBU and IP-RSU are used in the text.  We are not using DSRC, DSRCS, 
OBU nor RSU in the text.

> Also we need to try to make the 
> definition short and to the point. I am not very interested in this 
> IP-xxx, however, I like the terminology used in RFC8200. so we should 
> mention that our IP-units are nodes or routers,

Noted.

> in terminology the 
> definition word 'computer' used is not consistent with other ietf RFCs.

'computer' is generic enough to not need a definition.

I used 'computer' to solve the problem of saying 'Host' vs saying 
'Router'.  That debate is not solved and we wont solve it here.

Alex

> 
> AB
> 
> On Tue, Feb 6, 2018 at 6:47 PM, Alexandre Petrescu 
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> 
>         bid.Irespectfully disagree.Furthermore,I have nothing more to
>         add to this discussion;I have provided allUS relevant definitions.
> 
> 
>     Copy the definitions from your emails for DSRCS, and then DSRC and
>     then OBU and RSU in terms of DSRCS and of DSRC.
> 
>     But have these definitions (DSRCS, DSRC, OBU and RSU) in an
>     Appendix, not in the Terminology section.
> 
>     The Terminology section would list IP-OBU and IP-RSU and refer to
>     the Appendix.
> 
>     Alex
> 
> 
>         Sincerely,
> 
>         Francois Simon
> 
>         Lojik Technologies
> 
>         From: Alexandre Petrescu [mailto:[email-masked]
>         <mailto:[email-masked]>]
>             From: Alexandre Petrescu
>             [mailto:[email-masked]
>             <mailto:[email-masked]>]
> 
> 
>             To: François Simon <[email-masked]
>             <mailto:[email-masked]><mailto:[email-masked]
>             <mailto:[email-masked]>>>
> 
> 
>             Cc:[email-masked]
>             <mailto:[email-masked]><mailto:[email-masked]
>             <mailto:[email-masked]>>
> 
> 
>                 From: Alexandre Petrescu
>                 [mailto:[email-masked]
>                 <mailto:[email-masked]>]
> 
> 
> 
> 
>                 To: François Simon <[email-masked]
>                 <mailto:[email-masked]><mailto:[email-masked]
>                 <mailto:[email-masked]><mailto:[email-masked]
>                 <mailto:[email-masked]><mailto:[email-masked]
>                 <mailto:[email-masked]>>>>
> 
> 
> 
> 
>                 Cc:[email-masked]
>                 <mailto:[email-masked]><mailto:[email-masked]
>                 <mailto:[email-masked]>>
> 
> 
> 
> 
>                     From: its [mailto:[email-masked]
>                     <mailto:[email-masked]>] On Behalf Of Alexandre
> 
> 
> 
> 
> 
> 
> 
> 
>                     Petrescu
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>                     To:[email-masked]
>                     <mailto:[email-masked]><mailto:[email-masked]
>                     <mailto:[email-masked]>>
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 6 Feb 2018 19:08:42 +0100

Le 06/02/2018 à 19:04, Dick Roy a écrit :
> *From:*its [mailto:[email-masked]] *On Behalf Of *Abdussalam Baryun
> *Sent:* Tuesday, February 6, 2018 9:40 AM
> *To:* Alexandre Petrescu
> *Cc:* François Simon; its
> *Subject:* Re: [ipwave] FW: Shepherd review of 
> */[RR] While certainly not an expert on this, I was under the impression 
> any entity on an IP network was a node, and that there are two types of 
> functionality: host and router.  A node can implement host 
> functionality, router functionality, or both. If that’s the case, this 
> ought to be clearly stated somewhere./*

You see, people already say 'Host vs Router' and 'Node vs Router'. 
There are a few IPv6 related RFCs that disagree on it.

Here we say 'IP-OBU' and 'IP-RSU' and 'computer'.

Alex

> 
> */
> RR/*
> 
> in terminology the definition word 'computer' used is not consistent 
> with other ietf RFCs.
> 
> AB
> 
>     Cc:[email-masked] <mailto:[email-masked]><mailto:[email-masked]
>     <mailto:[email-masked]>>
> 
>         Cc:[email-masked] <mailto:[email-masked]><mailto:[email-masked]
>         <mailto:[email-masked]>>
>

---

From: Abdussalam Baryun <[email-masked]>
Date: Wed, 7 Feb 2018 11:07:47 +0200

I don't mind. Thanks,

AB

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Wed, 07 Feb 2018 12:26:38 +0100

Hi Alex,

> Do I understand the worry correctly?

My point is that there is no difference from how IPv6 works over
regular WiFi. The adaptation layer is not something IETF can do
normative specs.

> Should it provide something else?

My comment relates again to the point that this document is aimed to be
normative, but we are mostly providing guidelines/recommendations.

> Other persons commented, so at this time I propose to leave the def 

OK, but I still feel that this definition is wrong, but this is rough
consensus :D

> Maybe new work is needed for ND-over-OCB, or Mobile IP with OCB

Agree. I think it is worth to list/mention this. I agree that the
document does not tacklke them, but since we mention 'new
perspectives', I think the reader may expect an explanation of what
those are.

> Should I move section 4.2.1 in an Appendix?

Not sure at this point. Let's think about that possibility.

> EtherType MUST be 0x86DD (instead of just "is").  Would this make it 

Yes, but it would anyway be exactly the same as with IPv6-over-
Ethernet. My concern is that there seem to be nothing really new of
IPv6-over-802.11-OCB compared to IPv6-over-Ethernet/IEEE 802.11.
 
> Section 4.6 "Subnet Structure" - could be removed altogether.

Yes.

> Should I make a subsection called "Privacy Considerations" within

That's an option, but what I'd like is to have a bit more text about
privacy.

> > 	generated by the Router.  The Router is an IP-RSU (ITRI

OK, thanks. That's is fine.

Carlos

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 7 Feb 2018 13:33:52 +0100

Hi Carlos,

Le 07/02/2018 à 12:26, Carlos Jesús Bernardos Cano a écrit :
> regular WiFi.

I agree, but there is no RFC for IPv6 over regular WiFi.

There is an IPv6-over-Ethernet, but not for IPv6-over-WiFi.

When run over WiFi, there is a need of Adaptation Layer.

This Adaptation Layer has direct impact on how fragmentation is 
performed: the field "Sequence number" of the 802.11 Data header is 
increased when the IP MTU is overcome.  This behavior does not exist in 
Ethernet.

> The adaptation layer is not something IETF can do
> normative specs.

Excuse me Carlos, I dont understand this?  There is this RFC4919 section 
5 "LowPAN Adaptation Layer and Frame Format" of RFC 4919 "IPv6 over 
802.15.4".  There are other Adaptation Layers defined in other RFCs on 
the Standards Track.

Or maybe I dont understand what do you mean by "the adaptation layer is 
not something IETF can do normative specs".

> normative, but we are mostly providing guidelines/recommendations.

We strived to the best of our wit to move most of 
guidelines/recommendations into Appendixes.  Maybe more should be done.

> OK, but I still feel that this definition is wrong, but this is rough

Maybe we can say: "WiFi - it is believed, in general, that WiFi stands 
for [...]".

> perspectives', I think the reader may expect an explanation of what

I agree.  I will write something.

> IPv6-over-802.11-OCB compared to IPv6-over-Ethernet/IEEE 802.11.

IPv6-over-Ethernet should not be conflated with IPv6-over-802.11.  They 
are not the same.  There is an Adaptation Layer.  The 802.11 field 
"Sequence number" exists in 802.11 but not in Ethernet.

There is nothing new between IPv6-over-OCB and IPv6-over-80211.

There is something IP new between IPv6-over-80211 and IPv6-over-Ethernet.

There is no RFC for IPv6-over-80211.

As a consequence, there is something new between IPv6-over-OCB and 
IPv6-over-Ethernet that deserves be agreed.

> That's an option, but what I'd like is to have a bit more text about

I will ask my co-authors.

> OK, thanks. That's is fine.

Ok, I am happy.

Alex

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Wed, 07 Feb 2018 14:54:09 +0100

Hi Alex,

On Wed, 2018-02-07 at 13:33 +0100, Alexandre Petrescu wrote:
> > > > - The abstract mentions that in order to transmit IPv6 packets
> > > > on
> > > > IEEE
> > > > supported Maximum Transmission Unit size on the 802.11-OCB
> > > > link,
> > > > the
> > > > header format preceding the IPv6 header, the Type value within
> > > > it,
> > > > and
> > > > others". But the MTU part of the draft does not use any
> > > > normative
> > > > text,
> > > >    the header format is exactly the same than for IEEE 802.11,
> > > > as
> > > > the
> > > > type value.
> > > 
> > > The first one says that there are differences between IP-over-
> > > WiFi
> > > and
> > > IP-over-Ethernet.  These differences are in the headers.  To
> > > adapt
> > > to

But this does not affect the way IPv6 works, does it? This is something
 taken care by the IEEE 802.11 data header, no?

> not something IETF can do normative specs".

But the adaptation layer you refer to in the ipwave draft is already
defined by IEEE 802.11, right? I mean that it is not something the IETF
will define. It is already there. The LoWPAN adaptation layer is
something defined by IETF to allow IPv6 over IEEE 802.15.4 frame. But
in the case of OCB, there is no _additional_ adaptation layer defined
in the document (the one documented is the one provided by IEEE 802.11,
and this cannot be specified by the IETF). This is what I meant. Not
sure if now is more clear.

> guidelines/recommendations into Appendixes.  Maybe more should be

Thanks! I'll check and comment back.

> Maybe we can say: "WiFi - it is believed, in general, that WiFi

Well, I don't want to make something big of this. If people are happy
with the way it is, keep it. It is something very minor anyway.

> > > > - In section 4.1, does the text mean that the MTU SHOULD/MUST
> > > > be
> > > > 1500
> > > > - All the text of section 4.2.1 is not normative, but more a
> > > > report
> > > > of

But nothing needed to be done for that, right? You might argue that the
effort going on in intarea and mboned/pim on multicast over IEEE 802.11
might have something to do with this, but it is mostly about
optimizations, no mandatory things required to make IPv6 over 802.11
work.
 
> IPv6-over-Ethernet that deserves be agreed.

I'm not arguing against that. Just saying that this was not completely
clear in the draft.

> 
> > > In section 4.3 "LL Addresses" I could put "it is RECOMMENDED"
> > > instead
> > > of
> > > "it is recommended".
> > > 
> > > Section 4.5 "Stateless Autoconf" - I could write "the u/g bits
> > > MUST
> > > be

Thanks a lot for all the efforts!

Carlos

> 
> Alex
> 
> > 
> > Carlos
> > 
> > > > Authors, please respond to my questions/comments and address
> > > > them
> > > > in a

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 7 Feb 2018 15:18:43 +0100

>   taken care by the IEEE 802.11 data header, no?

At sending, the IP stack decides whether it fragments and then tells the 
MAC layer to increase its seqno.  At reception, vice-versa.

IPv6 Fragment Header also has an Identification field.

The two fields (Id field in IPv6 header and seqno in 802.11 MAC header) 
are correlated.

That's pretty much it.

It could be the same with QoS (TCLASS field in 802.11 header, and 
Traffic Class field in 802.11 Header); but at this time there's no work 
on this.

> defined by IEEE 802.11, right?

No, Ethernet Adaptation Layer is not defined anywhere.  It is just 
implemented.

Now it is defined in this ipwave Internet Draft.

> I mean that it is not something the IETF
> will define. It is already there.

It is there implemented but there is no spec, neither at IEEE nor at 
IETF.  Now it is in this ipwave draft, if we want it.

> The LoWPAN adaptation layer is
> something defined by IETF to allow IPv6 over IEEE 802.15.4 frame.

Yes.

In their case too, IPv6 worked fine over some kind of 802.15.4, there 
was no need of new RFC.  Yet they felt there was a need of an Adaptation 
Layer.  But they went way too far with that Adaptation Layer: instead of 
just reproducing how IP-over-15.4 works fine they felt like creating new 
functionalities; yet these added parts is what they make it incompatible 
with how "IPv6 works ok over 15.4".

I believe in our case, the IPv6-over-OCB reflects precisely how IPv6 
works ok over OCB.  There is no new things added.

I also want to tell about implementation: the OCB mode evolved from 
driver patches maintained by various individuals to more and more 
integration into the streamline kernel.  Nowadays only a few changes are 
needed to the streamline kernel, the OCB is there almost entirely.

The ipwave draft is in conformance with this OCB mode in the linux kernel.

> But

I understand better what you meant, thank you, but I disagree.

I agree.

> But nothing needed to be done for that, right?

See above; if one wants to make IPv6-over-WiFi to work then one needs an 
RFC (as one has an RFC for IPv6-over-Etherent).  That RFC tells that 
everything is the same as on Ethernet, except Fragmentation.

IPv6-over-Ethernet has nothing about Fragmentation.  YEt IPv6-over-WiFi 
does implement matters related to Fragmentation.  You can check it 
yourself: set the MTU on the interface to 500 ('ifconfig mtu') and then 
ping 1000byte packets (ping -s 1000), you will see packet captures with 
Wireshark in monitor mode illustrative how Fragmentation at IP and MAC 
layer is performed.

But, I agree with you, and we can also say that IPv6 works fine over 
802.11 OCB and leave it there, no need of RFC.  (the issue I have with 
this is that people say that if you want to use OCB then you must use 
BSM or CAM, because there is a standard for that BSM or CAM).

> You might argue that the

If there are no mandatory things, then there is no RFC, right?

> I'm not arguing against that. Just saying that this was not completely

We tried to explain it in section 1 "Introduction" and in section 4.2.1 
"Ethernet Adaptation Layer".

Maybe I need to add a statement that says that this Ethernet Adaptation 
Layer is not defined at IEEE?

Alex

---

From: Tony Li <[email-masked]>
Date: Wed, 7 Feb 2018 08:49:13 -0800

Hi all,

Combined reply….

>>> When run over WiFi, there is a need of Adaptation Layer.

I think we’re somehow confusing 802.11-OCB with Wi-Fi. They are not the same. The encapsulations are very different.

The encapsulations permitted by IEEE for 802.11-OCB don’t allow for traditional DIX encoding as we use for IP over Ethernet, so the additional adaptation is useful so that the device driver can present DIX encoded frames to the rest of the operating system and applications. This is the primary point of this document and this Working Group.

> At sending, the IP stack decides whether it fragments and then tells the MAC layer to increase its seqno.  At reception, vice-versa.
> 
> The two fields (Id field in IPv6 header and seqno in 802.11 MAC header) are correlated.

Please note that that’s your opinion. 

One might also point out that fragmentation is just a bad idea to begin with and should not ever happen. Therefore, what happens after you make the mistake of fragmenting is irrelevant. :-)

Tying the L2 header to the L3 fragmentation process is, IMHO, another mistake. It increases complexity, is a layering violation, and things would operate just fine even if we did nothing special. If and when L3 decides to fragment, the resulting fragments are simply separate packets.  L2 doesn’t need to know that they have an L3 relationship.

> No, Ethernet Adaptation Layer is not defined anywhere.  It is just implemented.
> 

The IEEE defines a set of permissible encapsulations.  They do not mandate how IP should be encapsulated and there are, in fact, multiple ways that we could transmit IP over 802.11-OCB.

It is within the IETF’s purview and charter to specify how IP over 802.11-OCB should be encapsulated.  Specifying that is the purpose of this Working Group and this document.

> See above; if one wants to make IPv6-over-WiFi to work then one needs an RFC (as one has an RFC for IPv6-over-Etherent).  That RFC tells that everything is the same as on Ethernet, except Fragmentation.

We already have IPv6 fully functional over Wi-Fi (and let’s be specific, I mean 802.11b,g,a,n,ac, …. ). There’s a huge installed base. That’s not changing.

802.11-OCB is a slightly different beast and it bears documenting how we are doing the encapsulation on the wire and the adaptation that we will do to present DIX encapsulation upwards.

> If there are no mandatory things, then there is no RFC, right?

There are many RFCs that are purely informational.

> Maybe I need to add a statement that says that this Ethernet Adaptation Layer is not defined at IEEE?

That would seem to be a necessary clarification.

Tony

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Wed, 07 Feb 2018 23:14:17 +0100

Hi Tony,

Trying to close this thread.

I mostly concur with what Tony has said in this e-mail.

Alex: I (wrongly) assumed that the adaptation layer for IPv6 over IEEE
802.11 was actually specified outside IETF. In any case, my point was
more on that there is nothing that needs to be specified there (IPv6
over IEEE 802.11 works), and that we have to focus in draft-ietf-
ipwave-ipv6-over-80211ocb on what is new that is needed. Sorry if I
created more confusion.

Then, to summarize on the key points (that I believe remains):

- Let's make use of normative text for the what the document actually
specifies.

- If the document only includes recommendations, then we can evaluate
making it Informational or BCP.

Thanks,

Carlos

On Wed, 2018-02-07 at 08:49 -0800, Tony Li wrote:
> Hi all,
> 
> Combined reply….
> 
> > > > > > > - Section 1 lists two exceptions for 802.11-OCB compared
> > > > > > > to
> > > > > > > Ethernet.
> I think we’re somehow confusing 802.11-OCB with Wi-Fi. They are not
> the same. The encapsulations are very different.
> 
> The encapsulations permitted by IEEE for 802.11-OCB don’t allow for
> traditional DIX encoding as we use for IP over Ethernet, so the
> additional adaptation is useful so that the device driver can present
> DIX encoded frames to the rest of the operating system and
> applications. This is the primary point of this document and this
> Working Group.
> 
> 
> > > > increased when the IP MTU is overcome.  This behavior does not
> > > > exist
> > > > in
> > > > Ethernet.
> > > 
> > At sending, the IP stack decides whether it fragments and then
> > tells the MAC layer to increase its seqno.  At reception, vice-
> > versa.
> > 
> One might also point out that fragmentation is just a bad idea to
> begin with and should not ever happen. Therefore, what happens after
> you make the mistake of fragmenting is irrelevant. :-)
> 
> Tying the L2 header to the L3 fragmentation process is, IMHO, another
> mistake. It increases complexity, is a layering violation, and things
> would operate just fine even if we did nothing special. If and when
> L3 decides to fragment, the resulting fragments are simply separate
> packets.  L2 doesn’t need to know that they have an L3 relationship.
> 
> 
> > > > Excuse me Carlos, I dont understand this?  There is this
> > > > RFC4919
> > > > section
> > > > 802.15.4".  There are other Adaptation Layers defined in other
> > > > RFCs
> > > > on
> > > > the Standards Track.
> > > > 
> > > > Or maybe I dont understand what do you mean by "the adaptation
> > > > layer
> > > > is
> The IEEE defines a set of permissible encapsulations.  They do not
> mandate how IP should be encapsulated and there are, in fact,
> multiple ways that we could transmit IP over 802.11-OCB.
> 
> It is within the IETF’s purview and charter to specify how IP over
> 802.11-OCB should be encapsulated.  Specifying that is the purpose of
> this Working Group and this document.
> 
> 
> > See above; if one wants to make IPv6-over-WiFi to work then one
> > needs an RFC (as one has an RFC for IPv6-over-Etherent).  That RFC
> > tells that everything is the same as on Ethernet, except
> > Fragmentation.
> 
> 
> We already have IPv6 fully functional over Wi-Fi (and let’s be
> specific, I mean 802.11b,g,a,n,ac, …. ). There’s a huge installed
> base. That’s not changing.
> 
> 802.11-OCB is a slightly different beast and it bears documenting how
> we are doing the encapsulation on the wire and the adaptation that we
> will do to present DIX encapsulation upwards.
> 
>

---

From: [email-masked]
Date: Wed, 7 Feb 2018 15:26:08 -0800

> making it Informational or BCP.

This document MUST specify the encapsulation and MTU for 802.11-OCB and it MUST be normative.

Apologies if this seems like shouting, I’m just complying with 2119. ;-)

Tony

---

From: Alexandre Petrescu <[email-masked]>
Date: Sun, 11 Feb 2018 18:01:20 +0100

> I mostly concur with what Tony has said in this e-mail.

I replied to his message at the end of this email.

> - Let's make use of normative text for the what the document actually

Right now there is this MUST for MTU.

There is more relatively normative text in section 4.5 "Stateless 
Autoconfiguration".  This recommends the use of RFC7136 (ug bits) and 
RFC 8064 (stable ids) and RFC 7217 (opaque ids).  These recommendations 
dont exist in RFC2464 (IPv6-over-Ethernet) and they dont exist in any 
IPv6-over-WiFi document because such IPv6-over-WiFi does not exist.

I hope this qualifies as 'specification'.

> making it Informational or BCP.

Hm, I thought IPv6-over-foo documents are never Info or BCP.  But yes, 
let us evaluate.

>> That would seem to be a necessary clarification.

I have tried to clarify it, but it seems difficult to write for me.

Maybe those who state that the WiFi-to-Ethernet Adaptation Layer is 
defined at IEEE should provide a reference.

(and I do not know what is DIX, never encountered it).

Alex

---

From: Abdussalam Baryun <[email-masked]>
Date: Mon, 12 Feb 2018 00:18:10 +0200

On Sun, Feb 11, 2018 at 7:01 PM, Alexandre Petrescu <
[email-masked]> wrote:

> [.......]

I was not with this transmission over Ethernet-layer from the first time I
seen it [1], but some replies were against, and the authors/WG wanted that.
I suggested we needed an adaptation for ipwave, but the wg say no we cannot
defined under ip which I don't believe. So IMO the majority-wg/authors can
find a reference.

AB

[1]  http://www.ietf.org/mail-archive/web/its/current/msg01889.html

---

From: [email-masked]
Date: Sun, 11 Feb 2018 15:40:50 -0800

> There is more relatively normative text in section 4.5 "Stateless Autoconfiguration".  This recommends the use of RFC7136 (ug bits) and RFC 8064 (stable ids) and RFC 7217 (opaque ids).  These recommendations dont exist in RFC2464 (IPv6-over-Ethernet) and they dont exist in any IPv6-over-WiFi document because such IPv6-over-WiFi does not exist.
> 
> I hope this qualifies as 'specification’.

It qualifies as a recommendation for right now. If you want it to be mandatory, you need to specifically use RFC 2119 terminology.

> (and I do not know what is DIX, never encountered it).

DIX is another name for Ethertype encapsulation. AFAIK, it has never been ratified by the IEEE.

Tony

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 12 Feb 2018 11:59:49 +0100

Le 11/02/2018 à 23:18, Abdussalam Baryun a écrit :
> 
> 
> On Sun, Feb 11, 2018 at 7:01 PM, Alexandre Petrescu 
> I was not with this transmission over Ethernet-layer from the first time 
> I seen it [1], but some replies were against, and the authors/WG wanted 
> that. I suggested we needed an adaptation for ipwave, but the wg say no 
> we cannot defined under ip which I don't believe. So IMO the 
> majority-wg/authors can find a reference.

I have tried to find a reference to an IEEE document that describes an 
"Ethernet Adaptation Layer".

I have not found it.

1. I do have some access to some IEEE documents, but not all.

2. The name "802.11-to-Ethernet Adaptation Layer", and "Ethernet 
Adaptation Layer" is a name I came up with.  It is derived from 
"WiFi-to-Ethernet" and from "Adaptation Layer".  The term "Adaptation 
Layer" is used by other IPv6-over-foo documents at IETF.

This "Ethernet Adaptation Layer" does what section 4.2.1 specifies it to 
do.  This is what the implementations do.

Because of these two reasons, I do not think there is any IEEE document 
that describes "Ethernet Adaptation Layer".

This the best I can do to find a reference.

Maybe there is an IEEE document that describes how comes that WiFi looks 
like Ethernet to IP?

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 13 Feb 2018 11:36:09 +0100

Hi Carlos,

> what is done today in existing implementations.

I propose the following improvement.

OLD:
>    The Receiver and Transmitter Address fields in the 802.11 Data Header
>    contain the same values as the Destination and the Source Address
>    fields in the Ethernet II Header, respectively.  The value of the
>    Type field in the LLC Header is the same as the value of the Type
>    field in the Ethernet II Header.

NEW:
>    The Receiver and Transmitter Address fields in the 802.11 Data
>    Header MUST contain the same values as the Destination and the
>    Source Address fields in the Ethernet II Header, respectively.  The
>    value of the Type field in the LLC Header MUST be the same as the
>    value of the Type field in the Ethernet II Header.

Do you agree?

> there that is specific of 802.11-OCB?

This is specific to 802.11 (compared to Ethernet), including 802.11-OCB 
(compared to Ethernet).

Alex

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Tue, 13 Feb 2018 14:21:24 +0100

Hi Alex,

Thanks. That works for me.

Please submit a new version, that I can check and then proceed with the
next steps in the publication request.

Thanks!

Carlos

On Tue, 2018-02-13 at 11:36 +0100, Alexandre Petrescu wrote:
> > Header

---

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

Hi Carlos,

Thanks for the reply.

I submitted a new version for that.

There are a few more places in section 4 that could contain normative terms.

These places correspond to what implementation does.

What do you think about these suggestions?

OLD:

    with respect to fragmentation).  If IPv6 packets of size larger than
    1500 bytes are sent on an 802.11-OCB interface card then the IP stack
    will fragment.  In case there are IP fragments, the field "Sequence
    number" of the 802.11 Data header containing the IP fragment field is
    increased.

NEW:

    with respect to fragmentation).  If IPv6 packets of size larger than
    1500 bytes are sent on an 802.11-OCB interface card then the IP stack
    MUST fragment.  In case there are IP fragments, the field "Sequence
    number" of the 802.11 Data header containing the IP fragment field
    MUST be increased.

OLD:

    Non-IP packets such as WAVE Short Message Protocol (WSMP) can be
    delivered on 802.11-OCB links.  Specifications of these packets are

NEW:

    Non-IP packets such as WAVE Short Message Protocol (WSMP) MAY be
    delivered on 802.11-OCB links.  Specifications of these packets are

OLD:

    performing 802.11-to-Ethernet is described in Section 4.2.1.  The
    Ethernet Type code (EtherType) for IPv6 is 0x86DD (hexadecimal 86DD,
    or otherwise #86DD).

NEW:

    performing 802.11-to-Ethernet is described in Section 4.2.1.  The
    Ethernet Type code (EtherType) for IPv6 MUST be 0x86DD (hexadecimal
    86DD, or otherwise #86DD).

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 14 Feb 2018 09:51:54 +0100

Le 13/02/2018 à 20:14, Dick Roy a écrit :
 > Comments inline below ...
 >
 > Sent: Tuesday, February 13, 2018 2:36 AM
 > To: [email-masked]
 > Cc: [email-masked]; Russ Housley;
 > [email-masked]; [email-masked]
 > draft-ietf-ipwave-ipv6-over-80211ocb-12 - Normative text in Ethernet
 > Adaptation Layer
 >
 > Hi Carlos,
 >
Header
 > [RR] I do not understand the intent here.  What Ethernet header is being
 > referred to?

It is the Ethernet II header.  This is what Wireshark displays. Please 
see attached a packet dump of an UDP IPv6 packet over 802.11OCB captured 
in nrmal mode (it's a CAM but that's not important).  Wireshark is a 
freely available open-source tool in widespread use which understands 
very many protocols, among which Ethernet and 802.11.

 > This presumes there is an associated Ethernet frame in the
 > picture somewhere.  What if there isn't? For example, V2V or V2I with no
 > Ethernet LAN involved.

Well, do you imply that some IP packet could be sent on something which 
is not 802.3?  Which is further not converted to an 802.11 frame?  I 
have never seen such thing, but I am curious what do you mean?

 > Secondly, 802.11 MAC headers have both a 3 and 4
 > address format depending on values of the ToDS and FromDS bits in the 
frame
 > control field in the MAC header.

The To DS and From DS flag bits in the frame control field are 0, 
because the DS status is 'network operating in ad-hoc mode'.
If needed I can provide a packet capture showing this.

 > The source and destination MAC addresses
 > are not necessarily the rx and tx MAC addresses in those cases. Now it is
 > true that accoding to the latest 802.11 spec, ToDS and FromDS are to 
be 0 if
 > OCBSctivated is true, however that requirement is unnecessary, and should
 > not have been put in place (it's a long story :^((().

The requirement unnecessary... Let us tell that to IEEE and remove it.  
Until then let us stay this way :-)

 >  It will likely be
 > ignored going forward because there are many uses for the 4-address 
format
 > in ITS

I could agree the use of 4 addresses (Source, Destination, Transmiter, 
Receiver) in the 802.11 Data header could be used in the future for 
ITS.  Then maybe write another Internet Draft to obsolete this one.

But I dont think the future use of 4 addresses in the 802.11 Data header 
will prevent mapping the Source to Source and the Destination to 
Destination (802.11 to Ethernet II headers).  Because if they do, that 
will break many other things, like RFC2464 and potentially others.

That will be a significant departure needing much agreement.

 > and there is NOTHING preventing its use other than the thoughts of a
 > few people.  I suggest you NOT make any requirements such as the ones 
above.
 > Implementers know how to map these addresses; they've been doing it for
 > years.  Trust them to do it right and don't constrain them unnecessarily.
 >
 > Do you agree?

Sounds like a speculation about what the future may holds (use the 4 
addresses in the 802.11 Header in ITS).

If there is an example where the Source address or the Destination 
address in the 802.11 Data header are different than the Source address 
or the Destination address in the Ethernet II header (respectively) then 
I may change my mind.

The examples that I see all act the way written in this draft (Source 
and Destination are same in 802.11 Data header and in Ethernet II 
header, respectively).

DEpending on this, I may change the text, or not. (write the normative 
'MUST' or 'MAY' or the non-normative 'is').

 > [RR] I don't understand the question or the answer.  That said, there is
 > nothing

I think the question was whether there is anything specific in 802.11 
OCB Headers that is different than Ethernet.  My answer was that yes, 
there is something specific in 802.11 OCB Headers compared to Ethernet.  
The formats are different.

Alex

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Wed, 14 Feb 2018 10:23:27 +0100

Hi Alex,

See inline below.

>     number" of the 802.11 Data header containing the IP fragment

Fine with me.

>     delivered on 802.11-OCB links.  Specifications of these packets

Not sure we need to use normative text here. This is more descriptive
(it has nothing to do with IP over 802.11-OCB, no?

>     86DD, or otherwise #86DD).

Fine with me.

Thanks!

Carlos

> > > >     fields in the Ethernet II Header, respectively.  The value
> > > > of
> > > > the
> > > >     Type field in the LLC Header is the same as the value of
> > > > the
> > > > Type
> > > >     value of the Type field in the LLC Header MUST be the same
> > > > as
> > > > the
> > > This is specific to 802.11 (compared to Ethernet), including
> > > 802.11-
> > > OCB
> > > (compared to Ethernet).
> > > 
> > > Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 14 Feb 2018 10:49:58 +0100

Le 14/02/2018 à 10:23, Carlos Jesús Bernardos Cano a écrit :
[...]

> Not sure we need to use normative text here. This is more
> descriptive (it has nothing to do with IP over 802.11-OCB, no?

I agree, it is more descriptive.  Maybe in the future someone would like 
to send an WSMP over IPv6 over 802.11 OCB, or not.

Hoping for that in the futhre, right now I will not use the MAY.

Alex

[...]

---

From: Tony Li <[email-masked]>
Date: Wed, 14 Feb 2018 08:38:24 -0800

> Well, do you imply that some IP packet could be sent on something which is not 802.3?  Which is further not converted to an 802.11 frame?  I have never seen such thing, but I am curious what do you mean?

There are MANY historical media that are not Ethernet/802.3/802.11.  SLIP, PPP, SONET, ATM, etc….

802.3 is not a strict requirement, it’s just become the de-facto standard since just about everything else has aged out. 

Doing something else would require a truly compelling reason, and that’s not at all visible. Until then, let’s do the obvious thing, please.

> But I dont think the future use of 4 addresses in the 802.11 Data header will prevent mapping the Source to Source and the Destination to Destination (802.11 to Ethernet II headers).  Because if they do, that will break many other things, like RFC2464 and potentially others.
> 

Concur.  Please stick with 2 addresses for now.

Tony

---

From: Tony Li <[email-masked]>
Date: Wed, 14 Feb 2018 08:45:22 -0800

>   In case there are IP fragments, the field "Sequence

I’d like to renew my objection to this. It’s a layering violation. It’s painful to implement. And we haven’t documented any technical need for this.

Tony

---

From: Nabil Benamar <[email-masked]>
Date: Wed, 14 Feb 2018 16:49:43 +0000

+1

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

On Wed, Feb 14, 2018 at 4:38 PM, Tony Li <[email-masked]> wrote:

> is not 802.3?  Which is further not converted to an 802.11 frame?  I have
> never seen such thing, but I am curious what do you mean?
>
>
> 802.3 is not a strict requirement, it’s just become the de-facto standard
> since just about everything else has aged out.
>
> Doing something else would require a truly compelling reason, and that’s
> not at all visible. Until then, let’s do the obvious thing, please.
>
>
> Destination (802.11 to Ethernet II headers).  Because if they do, that will
> break many other things, like RFC2464 and potentially others.
> >

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Wed, 14 Feb 2018 18:01:58 +0100

Hi,

I have to admit that I read this too quickly and I also think this
should not be done. So I agree with Tony.

Carlos

On Wed, 2018-02-14 at 08:45 -0800, Tony Li wrote:
> I’d like to renew my objection to this. It’s a layering violation.
> It’s painful to implement. And we haven’t documented any technical
> need for this.
> 
> Tony
> 
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 15 Feb 2018 13:06:05 +0100

Le 14/02/2018 à 17:45, Tony Li a écrit :
> 
>> In case there are IP fragments, the field "Sequence number" of the
>> 802.11 Data header containing the IP fragment field MUST be
>> increased.
> 
> 

Layering violation: it is an interface, not a violation.

Painful to implement: yes.  But it is implemented widely, you can check 
it on your computer: ping -s 2000 (size 2000) and wireshark in monitor mode.

Technical need undocumented: I agree.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 15 Feb 2018 13:07:13 +0100

Le 14/02/2018 à 18:30, Dick Roy a écrit :
> From: its [mailto:[email-masked]] On Behalf Of Tony Li
> Sent: Wednesday, February 14, 2018 8:45 AM
> To: Alexandre Petrescu
> [email-masked]; [email-masked]; [email-masked]
> draft-ietf-ipwave-ipv6-over-80211ocb-12 - Normative terms
> 
> 
> I'd like to renew my objection to this. It's a layering violation. It's
> painful to implement. And we haven't documented any technical need for this.
> [RR] Agreed!  The real point is that fragmentation at the MAC layer is
> handled by the MAC. If the network layer delivers NPDUs that don't require
> fragmentation, they won't be fragmented ... nuff said.

Given that there are three persons opposing this I will revert back the 
fragmentation MUST into an 'is' and submit a new version.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 15 Feb 2018 14:52:24 +0100

Le 14/02/2018 à 18:12, Dick Roy a écrit :
> FYI ... in 802.11 data frames w/ ToDS and FromDS = 0, the 3 address format
> is used and there is NO source or destination address.  They are tx and rx
> addresses.

I dont understand what you mean by 3-address format.

In the packet dumps, the Source and Destination addresses in the 802.11 
Header are equal to the Transmitter (your 'tx'?) and Receiver (your 
'rx'?) addresses in that header, respectively.  And the ToDS and FromDS 
flags in that header are both reset.

Further, the Ethernet II header obtained after adaptation also has these 
two tx and rx addresses despite FromDS and ToDS being reset.

> So the comment "But I dont think the future use of 4 addresses
> in the 802.11 Data header will prevent mapping the Source to Source and the
> Destination to Destination (802.11 to Ethernet II headers)." is strange to
> say the least  Source and destination addresses only appear in the 802.11
> header when using the 4-address format with both ToDS and FromDS = 1!

Well, again, the Source and Destination addresses in the 802.11 Header 
appear also when ToDS and FromDS are = 0.  Anyone can check that.

> Secondly, the only time mapping to 802.3 headers is done is when the DS
> (Distribution Service in an AP) is sending a MAC frame to an 802.3 LAN.

Yes, and each time we use IPv6 we use 802.3 LAN.  Be it over 802.11 or 
over  802.11 OCB, it's always an 802.3 LAN.  Because there is an 
adaptation layer.

Were IPv6 to _not_ go through the 802.3 LAN before arriving to 802.11 
then we'd have some new IPv6 Neighbor Discovery protocol that would take 
all these 4-addresses into account and why not the ESSID, and all the 
other fields in 802.11, without caring about 802.3.

Alex

> RR
> Sent: Wednesday, February 14, 2018 8:38 AM
> To: Alexandre Petrescu
> Cc: [email-masked]; [email-masked]; Russ
> Housley; Carlos Jesús Bernardos Cano; Dick Roy; [email-masked]
>> Well, do you imply that some IP packet could be sent on something which is
> not 802.3?  Which is further not converted to an 802.11 frame?  I have never
> seen such thing, but I am curious what do you mean?
> 
> 
> There are MANY historical media that are not Ethernet/802.3/802.11.  SLIP,
> PPP, SONET, ATM, etc..
> 
> 802.3 is not a strict requirement, it's just become the de-facto standard
> Doing something else would require a truly compelling reason, and that's not
> at all visible. Until then, let's do the obvious thing, please.
> 
> 
> will prevent mapping the Source to Source and the Destination to Destination
> (802.11 to Ethernet II headers).  Because if they do, that will break many
> other things, like RFC2464 and potentially others.
>>

---

From: [email-masked]
Date: Thu, 15 Feb 2018 08:28:17 -0800

Alex,

> Layering violation: it is an interface, not a violation.

Sorry, but this definitely counts as a layering violation. You’re requiring the 802.11 device driver header to look up into the layer 3 packet header and determine if a fragment header is present. That has to happen for each and every packet transmitted by the IP-OBU.  Why is a layer 2 driver digging around in L3 details?

As written, this applies to ANY fragmented packet coming through the IP-OBU, so even if the packet was fragmented on the other side of the Internet, it’s got to be examined so that we can bump the sequence number.  So this isn’t simply something that can be passed down from the local IP stack.

> Painful to implement: yes.  But it is implemented widely, you can check it on your computer: ping -s 2000 (size 2000) and wireshark in monitor mode.

I’ll stipulate that IPv4 fragmentation is widely implemented. In fact, I’ve helped write and debug a couple of implementations of it. IPv6 fragmentation is, IMHO, a mistake that should have never propagated into the protocol. I certainly haven’t seen a lot of it.  I’ll take your word that that part is implemented.

However, the fragmentation part is completely separate from the request that you’re making of the device driver writer.  I certainly haven’t seen anyone implement this particular hack in their driver. In the one driver that I’ve seen in detail, this is NOT done.

AFAICT, this is still exceedingly painful.

> Technical need undocumented: I agree.

Ok, so why are we doing this then?  

Tony

---

From: François Simon <[email-masked]>
Date: Thu, 15 Feb 2018 12:13:11 -0500

"There are four address fields in the MAC frame format. These fields are used to indicate the basic service set identifier (BSSID), source address (SA), destination address (DA), transmitting STA address (TA), and receiving STA address (RA). Certain frames might not contain some of the address fields."

In OCB:
Address field 1 = Receiver Address (RA)
Address field 2 = Transmitter Address (TA) (MAC address)
Address field 3 = BSSID (all '1s')
Address field 4 = Source Address (SA) Source Address (omitted) 

3 address fields (1, 2, and 3) are used.
ToDS and FromDS = 0b0

Fygs

-----Original Message-----
From: its [mailto:[email-masked]] On Behalf Of Alexandre Petrescu
Sent: Thursday, February 15, 2018 8:52 AM
To: [email-masked]; 'Tony Li' <[email-masked]>
Cc: [email-masked]; 'Russ Housley' <[email-masked]>; 'Carlos Jesús Bernardos Cano' <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [ipwave] Shepherd review of draft-ietf-ipwave-ipv6-over-80211ocb-12 - Normative text in Ethernet Adaptation Layer

Le 14/02/2018 à 18:12, Dick Roy a écrit :
> FYI ... in 802.11 data frames w/ ToDS and FromDS = 0, the 3 address 
> format is used and there is NO source or destination address.  They 
> are tx and rx addresses.

In the packet dumps, the Source and Destination addresses in the 802.11 Header are equal to the Transmitter (your 'tx'?) and Receiver (your
'rx'?) addresses in that header, respectively.  And the ToDS and FromDS flags in that header are both reset.

Further, the Ethernet II header obtained after adaptation also has these two tx and rx addresses despite FromDS and ToDS being reset.

> So the comment "But I dont think the future use of 4 addresses in the 
> 802.11 Data header will prevent mapping the Source to Source and the 
> Destination to Destination (802.11 to Ethernet II headers)." is 
> strange to say the least  Source and destination addresses only appear 
> in the 802.11 header when using the 4-address format with both ToDS and FromDS = 1!

Well, again, the Source and Destination addresses in the 802.11 Header appear also when ToDS and FromDS are = 0.  Anyone can check that.

> Secondly, the only time mapping to 802.3 headers is done is when the 
> DS (Distribution Service in an AP) is sending a MAC frame to an 802.3 LAN.

Yes, and each time we use IPv6 we use 802.3 LAN.  Be it over 802.11 or over  802.11 OCB, it's always an 802.3 LAN.  Because there is an adaptation layer.

Were IPv6 to _not_ go through the 802.3 LAN before arriving to 802.11 then we'd have some new IPv6 Neighbor Discovery protocol that would take all these 4-addresses into account and why not the ESSID, and all the other fields in 802.11, without caring about 802.3.

Alex

> Cc: [email-masked] <mailto:[email-masked]> ; [email-masked] <mailto:[email-masked]> ; Russ 
> Housley; Carlos Jesús Bernardos Cano; Dick Roy; [email-masked] <mailto:[email-masked]> 
>>> This presumes there is an associated Ethernet frame in the picture 
>>> somewhere.  What if there isn't? For example, V2V or V2I with no 
>>> Ethernet LAN involved.
>>
> not 802.3?  Which is further not converted to an 802.11 frame?  I have 
> There are MANY historical media that are not Ethernet/802.3/802.11.  
> SLIP, PPP, SONET, ATM, etc..
> 
> 802.3 is not a strict requirement, it's just become the de-facto 
> standard since just about everything else has aged out.
> 
> Doing something else would require a truly compelling reason, and 
> that's not at all visible. Until then, let's do the obvious thing, please.
> 
> 
> Destination
> (802.11 to Ethernet II headers).  Because if they do, that will break 
> many other things, like RFC2464 and potentially others.
>>

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 15 Feb 2018 18:50:12 +0100

Mr. Simon,

In all cases, the doubts here seem to be about what goes in the 802.11 
Header, not about the mapping between 802.11 header and Ethernet II header.

IPv6-over-OCB cares about the EthernetII Header.  That has only 2 
addresses.  One of these is mapped into Destination address, and the 
other into the Source Address of the 802.11 header.  That is what our 
IPv6-over-OCB draft says.

The IPv6 layer ignores completely the BSSID value.  I am not sure we 
want to write this aspect at all.

BEsides, OCB driver implementations ignore this BSSID field as well.  We 
say in standards its value should be "all ffs" but it works if one sets 
it to "fe:ff:ff:ff:ff:ff" too.

Le 15/02/2018 à 18:13, François Simon a écrit :
> "/There are four address fields in the MAC frame format. These fields 
> are used to indicate the basic service set identifier (BSSID), source 
> address (SA), destination address (DA), transmitting STA address (TA), 
> and receiving STA address (RA). Certain frames might not contain some of 
> the address fields.//"/

It says there are four fields and then lists five(?)

If it is a quote from an IEEE standard please suggest IEEE to clarify 
the phrase.

> 3 address fields (1, 2, and 3) are used.

The BSSID is a 5th field.

In dumps it looks like this:
Receiver address,
Destination address,
Transmitter address,
Source address,
BSS Id.

They are 5 distinct fields containing 5 distinct values.  The respective 
values are:
33:33::1, (the link layer multicast address for 'all-nodes' IIRC)
33:33::1,
30:14:pr:iv:ac:y, (a MAC address)
30:14:pr:iv:ac:y,
ff:ff:ff:ff:ff:ff:ff.

Alex

> Cc: [email-masked]; 'Russ Housley' 
> <[email-masked]>; 'Carlos Jesús Bernardos Cano' <[email-masked]>; 
> [email-masked]; [email-masked]
>> Cc:[email-masked]<mailto:[email-masked]>;[email-masked]<mailto:[email-masked]>; 
> Russ
> 
>> Housley; Carlos Jesús Bernardos Cano; Dick Roy;[email-masked]<mailto:[email-masked]>
> 
>>> Well, do you imply that some IP packet could be sent on something 
> 
>>> which is
> 
>>> But I dont think the future use of 4 addresses in the 802.11 Data 
> 
>>> header
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 15 Feb 2018 19:35:40 +0100

Allow me to top post here to try to converge.

The hex dump of one 802.11 header shows two addresses and a BSS Id.  One
such address is called "Receiver Address" and "Destination Address" at
the same time.  Another such address is called "Transmitter address" and
"Source address" at the same time.  There are only three 48bit values in
there (two addresses and a BSS Id).

The hex dump of the corresponding Ethernet II header shows two
addresses.  One is called "Destination" and the other is called
"Source".  There are only two 48bit values in there (no BSS Id).

The current text in the draft says:
> Header contain the same values as the Destination and the Source
> Address fields in the Ethernet II Header, respectively.

This text still seems correct to me.

It could be improved along two directions: (1) use "MUST contain"
instead of "contain" if we wanted to make it more normative and (2) use 
"Receiver or Destination" instead of just "Receiver" and "Transmitter or 
Source" instead of just "Transmitter".

The NEW text could look like this:
> The Receiver or Destination address, and the Transmitter or Source
> address in the 802.11 Data Header MUST contain the same values as the
> Destination and the Source fields in the Ethernet II Header,
> respectively.

Alex

Le 15/02/2018 à 18:13, François Simon a écrit :
>  are used to indicate the basic service set identifier (BSSID),
> source address (SA), destination address (DA), transmitting STA
> address (TA), and receiving STA address (RA). Certain frames might
> not contain some of the address fields.//"/
> 
> In OCB:
> 
> -----Original Message----- From: its [mailto:[email-masked]] On
> Behalf Of Alexandre Petrescu Sent: Thursday, February 15, 2018 8:52
> AM To: [email-masked]; 'Tony Li' <[email-masked]> Cc:
> [email-masked]; 'Russ Housley' 
> <[email-masked]>; 'Carlos Jesús Bernardos Cano'
> <[email-masked]>; [email-masked]; [email-masked] Subject: Re:
> [ipwave] Shepherd review of draft-ietf-ipwave-ipv6-over-80211ocb-12 -
> Normative text in Ethernet Adaptation Layer
> 
> In the packet dumps, the Source and Destination addresses in the
> 802.11 Header are equal to the Transmitter (your 'tx'?) and Receiver
> (your
> 
> 'rx'?) addresses in that header, respectively.  And the ToDS and
> FromDS flags in that header are both reset.
> 
> Further, the Ethernet II header obtained after adaptation also has
> these two tx and rx addresses despite FromDS and ToDS being reset.
> 
> Well, again, the Source and Destination addresses in the 802.11
> Header appear also when ToDS and FromDS are = 0.  Anyone can check
> that.
> 
> Yes, and each time we use IPv6 we use 802.3 LAN.  Be it over 802.11
> or over  802.11 OCB, it's always an 802.3 LAN.  Because there is an 
> adaptation layer.
> 
>  then we'd have some new IPv6 Neighbor Discovery protocol that would
> take all these 4-addresses into account and why not the ESSID, and
> all the other fields in 802.11, without caring about 802.3.
> 
> Alex
> 
>> 
> 
>> RR
> 
>> 
> 
>> Housley; Carlos Jesús Bernardos Cano; Dick
>> Roy;[email-masked]<mailto:[email-masked]>
> 
>>>> picture

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 15 Feb 2018 19:51:11 +0100

Le 15/02/2018 à 19:28, Dick Roy a écrit :
> Behalf Of Alexandre Petrescu Sent: Thursday, February 15, 2018 9:50
> AM To: François Simon; [email-masked]; 'Tony Li' Cc:
> [email-masked]; 'Russ Housley'; 
> [email-masked]; 'Carlos Jesús Bernardos Cano'; [email-masked] 
> */[RR] No. There is no doubt about what is in the 802.11 header.  In
>  OCB, with ToDS and FromDS = 0, there are only 3 address fields.  The
>  first contains the rx address, the second the tx address, and the
> third, the broadcast MAC address/wildcard BSSID of 0xFFFFFF.  This is
> NOT up for debate (at this time:^))./*

I agree.

> IPv6-over-OCB cares about the EthernetII Header.
> 
> */[RR] No. It cares NOTHING about ANY 802.3 MAC header. There is not
> an 802.11 OCB transmission that knows ANYTING about 802.3!  You are 
> confusing how TPDUs (segments) get from source to destination using
> an IP network layer, with what happens over the various LANs that may
> be in the path, and this problem is throughout the draft I suspect.
> /*

No.

This EthernetII header is there whenever a computer sends a packet on
WiFi.  The captures are performed on the computer connected exclusively
on WiFi, there is no wired LAN.

> 
> That has only 2
> 
> addresses.
> 
> */[RR] Yes, the 802.3 header has only a source and destination MAC 
> address.

YEs.  _And_ an EtherType.

> At the equivalent to an 802.1Q conformant bridge (cf. 802.11ak for
> details), the appropriate mapping from 802.11 address fields to 802.3
> addresses takes place,

No, there is no 802.1q bridge on this computer where there is this
mapping between 802.11 and 802.3 happens.

I do not understand why you pretend there to be a bridge.  We discussed 
this several times.  If I were not sure about it I would not put in the 
draft this "Ethernet Adaptation Layer".

> ALL unbeknownst to the IP layer.  I have absolutely NO clue why all
> you IETFers are so wrapped around the axle about all this.  Yes,
> attention to MTU sizes makes a lot of sense when trying to do QoS
> across disparate LANs, such as 802.11 and 802.3 LANs, but that’s NOT
> YOUR PROBLEM!  IMO you should stick to the network (and transport)
> layer, and let the DLL guys do their job. /*

> One of these is mapped into Destination address, and the
> 
> other into the Source Address of the 802.11 header.
> 
> */[RR] This mapping happens in bridges whose functionality is out of
>  IETF scope/control./*

It could be out of scope but it seems it is out of scope of everybody 
including IEEE.  Otherwise I cant explain why this bridging (that you 
call) happens without having a bridge software on the computer. 
Usually, the bridge software is called brconf, and there is a knob in 
the kernel called 1q.  They are both absent, yet this 'bridging' that 
you call _is_ happening.  I just call it "Adaptation Layer".

> That is what our
> */[RR] If you really care about this, then change the text to get it
>  right otherwise people who read the draft will be of the opinion we
>  don’t know what we are talking about./*
> 
> */[RR] The network layer doesn’t ignore it, it NEVER sees it! Any
> such conversation in the draft will surely indicate to people that we
> don’t know what we are doing./*

I agree, there is nothing about BSSID in the draft.

In the future, maybe we should look at it though.  It's something that 
could be useful in handovers.

> */[RR] Such drivers are technically NOT OCB conformant, but that
> really doesn’t matter either.  OCB should NEVER have restricted the
> BSSID field to be the wildcard value, but I couldn’t get people to
> move off such restrictive thinking, so it’s in the standard today.
> The value of the BSSID field currently has NO impact on the protocol
> at all!  It could have been used for some interesting functionality,
> however I lost that battle:^(((( /*
> 
>> source
> */[RR] Yes. You need to read clause 9 in 802.11 revmd (9.2.4.1.4,
> Table 9-3, and 9.2.4.3 in particular) and you will see what I told
> you in the previous posting. /

It's a cumbersome phrase.

> */[RR] NO! There are ONLY 3 or 4 “address” fields, not 5.  It’s a bit
>  confusing; if you want to know the details, read clause 9! /*

There are only 3 fields that go on wire (src dst and BSSID).  All the 
rest is virtual fields and notation.

> */[RR] Yes, because wireshark can dump whatever it wants in whatever
>  order it wants. /*

I agree.  Sometimes it displayes a certain "interpretation" where some 
fields can be duplicated.

But it also displays a 'hex dump' and that does not lie.

> */[RR] These seem to be IPv6 addresses, not MAC addresses./*

No, it is a common notation for MAC addresses as well; not only IPv6 
notation has the benefit of reducing many 0s to just ::.  It is a 48bit 
value that contains a MAC multicast address.  It is an abbreviation of 
33:33:00:00:00:1.

There is an RFC for this.

> */[RR] That’s NOT a MAC address; it’s only 44 bits assuming the
> strange code in the last four octets are really octets. /*

Right, I meant privacy0.

> 30:14:pr:iv:ac:y,
> 
> ff:ff:ff:ff:ff:ff:ff.
> 
> */[RR] Not sure what this is??? Too many bits for a broadcast MAC 
> address. Don’t confuse wireshark output with the order of fields in a
>  protocol header.  It’s obviously not meant to be that either./*

RIght, it's a 48bt all set.  My copy was wrong.

Alex

> *//*
> */RR/*
>> <[email-masked]>;
>> 802.11
>> FromDS
>> these
>>> in the

---

From: [email-masked]
Date: Thu, 15 Feb 2018 11:32:42 -0800

> On Feb 15, 2018, at 10:28 AM, Dick Roy <[email-masked]> wrote:
> 
> IMO you should stick to the network (and transport) layer, and let the DLL guys do their job.

Just to be clear: the purpose of trying to provide an adaptation layer is so that we can simply reference RFC 2464 (and friends) "Transmission of IPv6 Packets over Ethernet Networks” and be done.

Tony

---

From: Abdussalam Baryun <[email-masked]>
Date: Fri, 16 Feb 2018 03:22:00 +0200

On Thu, Feb 15, 2018 at 9:32 PM, <[email-masked]> wrote:

> *IMO you should stick to the network (and transport) layer, and let the
> DLL guys do their job.*
>
>
The problem is that their  job is not done, they are still amending to get
better performance (from ieee802.11p to ieee802.11px). IMO we can consider
performance when we transmit IPv6 over such job. Additionally, recommend
for better transmission quality.

>
> Just to be clear: the purpose of trying to provide an adaptation layer is
> so that we can simply reference RFC 2464 (and friends) "Transmission of
> IPv6 Packets over Ethernet Networks” and be done.
>

In wireless communication increasing frames header size decreases
performance. Using easy ways have always overheads. Ethernet is wired
network high speed and it is with very lower noise compared with wireless.
We should not forget mobility in our use case.

We need to reduce the overhead, and consider performance when transmitting
IPv6 over ieee802.11-ocb

AB

---

From: Tony Li <[email-masked]>
Date: Thu, 15 Feb 2018 17:26:59 -0800

> The problem is that their  job is not done, they are still amending to get better performance (from ieee802.11p to ieee802.11px). IMO we can consider performance when we transmit IPv6 over such job. Additionally, recommend for better transmission quality.

I’m gonna guess that it’s very unlikely that they will significantly change header formats when they do so. So I suspect that we’re quite safe in proceeding as is.

> In wireless communication increasing frames header size decreases performance. Using easy ways have always overheads. Ethernet is wired network high speed and it is with very lower noise compared with wireless. We should not forget mobility in our use case.
> 
> We need to reduce the overhead, and consider performance when transmitting IPv6 over ieee802.11-ocb

Well, I don’t see how we would go about changing the 802.11 headers, and changing IPv6 is out of the question, so I don’t understand your point.

Now, if you really wanna reduce overhead, we could talk about using IPv4 instead.  :-) :-) :-)

Tony

---

From: Abdussalam Baryun <[email-masked]>
Date: Fri, 16 Feb 2018 05:13:07 +0200

>> Address fields in the Ethernet II Header, respectively.
I checked the ieee802.11 -2016 doc it shows no RA and TA fields. The
Field-names are: Address 1 Field and Address 2 Field, as mentioned by Simon
below.
So as Simon mentioned only three address fields in this OCB data frame.

> This text still seems correct to me.

We can amend the words related to fields in the frame, to make it easier to
understand,

> NEW>
The Address 1 and Address 2 fields in the 802.11 Data
Header contain the same addresses as the Destination and the Source
Address fields in the Ethernet II Header, respectively.

While address 3 field that contains all binary 1s

AB