Subject: Re: [its] Submitted new version of draft-petrescu-ipv6-over-80211p-05.txt

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 8 Nov 2016 15:26:37 +0100

Hello IPWAVErs,

This merge brought in one particular aspect: IPv4.  For example, the 
draft now mentions the use of an IPv4 Ethertype if carrying an IPv4 
packet (in addition to the IPv6 Ethertype when carrying an IPv6 packet).

Another example is that the title now says
"IP over ..." instead of
"IPv6 over..."

I would like to ask participants to the IPWAVE WG - what do you think 
about inclusion of IPv4 aspects in this draft?  We need your comments in 
order to improve this draft.

Yours,

Alex

Le 31/10/2016 à 21:38, Alexandre Petrescu a écrit :
> Hello IPWAVErs,
>
> We submitted a new version of draft-petrescu-ipv6-over-80211p-05.txt.
> This is a merge including draft-ernst-its-ipv6-over-80211ocb-00,
> draft-haerri-ipv6-over-80211OCB-00 and
> draft-lee-its-ipv6-over-80211ocb-00.  The new document contains a few
> other improvements.  Notably, the comments received during the BoF were
> addressed.
>
> Comments are welcome.
>
> https://tools.ietf.org/html/draft-petrescu-ipv6-over-80211p-05
>
> Alex
>
>
>
> _______________________________________________
> its mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/its
>

---

From: "Kedalagudde, Meghashree Dattatri" <[email-masked]>
Date: Thu, 10 Nov 2016 22:42:36 +0000

Hello IPWAVErs,

 Alex: Thank you for sharing the draft. I read through the new version and had a clarification question.
 
 Including support for IPv4 over 802.11OCB. Can you elaborate on the use case or example for IPv4 support on 802.11OCB?
 
 My understanding is IEEE 1609.x (0/3/4) documents mention only about IPv6 on 802.11OCB. I think it is important to understand why IPv4 support and optimizations is required in the draft.
 
 In addition, with reference to the IAB statement on IPv6: https://www.iab.org/2016/11/07/iab-statement-on-ipv6/   'Next -gen' standards and industry development needs to see increase in IPv6 deployments.  
 I still think the challenges/issues to support IPv6 over 802.11OCB should be the focus here, unless there is an absolute need to support IPv4 over 802.11OCB. 
 
 Please share your thoughts. 
 
 Thank you 
 Megha

-----Original Message-----
From: its [mailto:[email-masked]] On Behalf Of Alexandre Petrescu
Sent: Tuesday, November 08, 2016 6:27 AM
To: [email-masked]
Subject: Re: [its] Submitted new version of draft-petrescu-ipv6-over-80211p-05.txt

Hello IPWAVErs,

This merge brought in one particular aspect: IPv4.  For example, the draft now mentions the use of an IPv4 Ethertype if carrying an IPv4 packet (in addition to the IPv6 Ethertype when carrying an IPv6 packet).

Another example is that the title now says "IP over ..." instead of
"IPv6 over..."

I would like to ask participants to the IPWAVE WG - what do you think about inclusion of IPv4 aspects in this draft?  We need your comments in order to improve this draft.

Yours,

Alex

Le 31/10/2016 à 21:38, Alexandre Petrescu a écrit :
> other improvements.  Notably, the comments received during the BoF 
> were addressed.
>
> Comments are welcome.
>

---

From: Tony Li <[email-masked]>
Date: Thu, 10 Nov 2016 15:18:36 -0800

Hi there,

> Including support for IPv4 over 802.11OCB. Can you elaborate on the use case or example for IPv4 support on 802.11OCB?

We have a proprietary application that has V2I, V2V, and V2V2I requirements. The V2I portion of the requirement makes use of non-802.11OCB wireless infrastructure (e.g. Wi-Fi) that may not be under our direct control and that is located opportunistically (e.g., a Starbucks hotspot). We cannot expect IPv6 to be ubiquitously available and thus for maximum connectivity, we must have IPv4 support. Given this, when we require V2V2I connectivity, it makes sense for us to have IPv4 for the V2V portion as well.  Thus, we will be using IPv4 over 802.11OCB.

> My understanding is IEEE 1609.x (0/3/4) documents mention only about IPv6 on 802.11OCB. I think it is important to understand why IPv4 support and optimizations is required in the draft.

Our application does not require IEEE 1609. At all. ;-)

You should not that draft-petrescu doesn’t require IEEE 1609 either.

> I still think the challenges/issues to support IPv6 over 802.11OCB should be the focus here, unless there is an absolute need to support IPv4 over 802.11OCB. 

There is an absolute need. The IPv4 Internet is not going away. While we may dream of a brave new world where IPv6 is ubiquitous, we are not there yet. The choice is to speak v4 sometimes or to be disconnected.

No one is asking for a change of focus. All that is needed is a few words that document how IPv4 is to be encoded.  Since it is 100% consistent with the IPv6 encoding, this is hardly controversial. The additions to the existing document have been minimal.

Tony

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Mon, 14 Nov 2016 07:02:48 +0100

Hi Alex,

Thanks for the update. Please find below some comments (as individual,
co-chair hat off), in no particular order:

- The abstract says "the operation outside the context of a BSS (OCB)
has impact on IPv6 handover behaviour and on IPv6 security". Shouldn't
we mention there as well ND impacts?

- I think the section including the IPv6 packet capture should be moved
as an annex, as this is just an example. I'd also remove the mention of
the capture from the abstract (the key point/outcome of the document is
specifying how IPv6 over 802.11 OCB works).

- "Such a station, when it has the flag set, it uses" --> "Such a
station, when it has the flag set, uses"

- The document should focus on IPv6 only, as the WG is chartered to
work on IPv6 only.

- In Section 1, handovers between OCB links are highlighted as a key
aspect to be addressed. I think other (related) aspects, such as SLAAC,
router discovery, etc should be equally mentioned.

- WSMP is first mentioned in Section 1, but it is not expanded until
later in the document. Please expand and consider also to introduce
this to the Terminology section.

- Section 2 (Terminology): shouldn't it include OBU?

- Section 2 (Terminology): the OCB term appears twice.

- Section 4: "as opposed to an arbitrary BSSID value set by
administrator (e.g.  'My-Home-AccessPoint')" --> if I'm not mistaken, a
BSSID is a MAC address (e.g., the one of the AP), not a string. The
example used could be an ESSID, but not a BSSID.

- Section 4: it is mentioned that "as opposed to the non-
vehicular settings - real wall protection - where fixed MAC addresses
do not currently pose some privacy risks". I disagree that MAC
addresses do not pose privacy risks in non-vehicular environments.

- Section 5: the title of the section is "Design Considerations", of
what? Since the document is about IPv6 over 802.11-OCB, and this
section is about general design considerations of 802.11-OCB, I think
the title of the section should be more specific.

- Section 6.1: it is not completely clear how an MTU lower than 1280
bytes can be supported (500 bytes is mentioned as an example). Please
clarify how this would be compliant with RFC 2460.

- Section 6.1: not sure it is relevant to this document mentioning that
the MAC and application layers can fragment, as this would be
transparent to the IPv6 layer operation.

- Please add captions to all the figures.

- Section 6.2: in the figure before Section 6.2.1, please explain the
16 bit after the Source Address ("frame type" field of the Ethernet
header).

- Section 6.2.1: explain the differences between "IEEE 802.11 Data" and
"IEEE 802.11 QoS Data".

- Section 6.4: if informational text is finally kept in the draft about
geonetworking, please include some informative references.

- There has been discussion recently on the efficiency of multicast
over wireless, and how to optimize IPv6 multicast over 802.11 networks.
I think the issues considered are even more relevant for 802.11-OCB
networks (limited bandwidth, many vehicles, high mobility, etc.)

- Section 6.6: I'd avoid to tackle issues about subnet structure. We
may just refer to the autoconf RFC (as done already) and the document
being  discussed in intarea. There were quite a lot if discussions in
autoconf and this is a very controversial topic, which I think we
should stay away from.

- Section 7: "The process of movement detection" --> "The process of
IPv6 movement detection"

- Section 7: it is somehow recommended to increase the RA frequency as
a way to improve handover performance, but I guess sending too many RA
messages is actually an issue in 802.11-OCB networks, due to the
limited bandwidth, large number of vehicles and (again) multicast. I'd
suggest to include some analysis on the impact of RA frequency.

- I think the document could be shortened, as it is quite long and some
information is repeated several times (e.g., the last paragraph before
Section 8.2).

- Section 8.2: it says "this adaptation layer may consist in
elimination of the Radiotap", but the radiotap is not a real header
transmitted over the air, so I guess the adaptation layer does not need
to do anything about it, right?

- Section 9: "amd" --> "and".

- Appendix D: I think this is not in the scope of this document (IPv6
over 802.11-OCB).

Thanks,

Carlos

On Mon, 2016-10-31 at 21:38 +0100, Alexandre Petrescu wrote:
> Hello IPWAVErs,
> We submitted a new version of draft-petrescu-ipv6-over-80211p-
> 05.txt.  This is a merge including draft-ernst-its-ipv6-over-
> 80211ocb-00, draft-haerri-ipv6-over-80211OCB-00 and draft-lee-its-
> ipv6-over-80211ocb-00.  The new document contains a few other
> improvements.  Notably, the comments received during the BoF were
> addressed.
> Comments are welcome.