Subject: Re: [ipwave] I-D Action: draft-ietf-ipwave-ipv6-over-80211ocb-01.txt - Ethernet Adaptation Layer

From: Alexandre Petrescu <[email-masked]>
Date: Sun, 12 Mar 2017 17:57:04 +0100

Dick,

I hope now your postings will show up on the email list.

Le 21/02/2017 à 03:47, Dick Roy a écrit :
> Alex,
>
> Attached is a doc with some of my initial comments. I thought I
> should get it to you ASAP as there are significant issues surrounding
> the LLC sublayer and EPD operation throughout the draft that should
> be fixed.  In particular, the Ethernet Adaptation Layer doesn't
> really exist above the 802.11 MAC sublayer ... anywhere.  It's all
> LLC sublayer operation.  The adaptation to which you refer happens in
> bridges that connect 802.11 links to Ethernet-based LANs.

The "Ethernet Adaptation Layer" I am describing is a new name.  But the 
behaviour is there for many years in implementations.

Implementations adapt between 802.11 Headers and Ethernet II Headers.

This adaptation is not only happening in a bridge.  It als happening in 
a computer with a single WiFi interface: the Ethernet Adaptation Layer 
adapts between 802.11 Headers and EthernetII Headers in that computer.

The IP stack sees only the EthernetII Headers.  This is illustrated in 
the following figure copied from the draft.

Do you agree with this concept of "Ethernet Adaptation Layer"?

            +--------------------+-------------+-------------+---------+
            | 802.11 Data Header | LLC Header  | IPv6 Header | Payload |
            +--------------------+-------------+-------------+---------+
                             ^
                             |
                             802.11-to-Ethernet Adaptation Layer
                             |
                             v

            +---------------------+-------------+---------+
            | Ethernet II Header  | IPv6 Header | Payload |
            +---------------------+-------------+---------+

Alex

>
> Cheers,
>
> RR
>
> -----Original Message----- From: its [mailto:[email-masked]] On
> Behalf Of Alexandre Petrescu Sent: Monday, February 20, 2017 8:41 AM
> To: [email-masked] Subject: Re: [ipwave] I-D Action:
> draft-ietf-ipwave-ipv6-over-80211ocb-01.txt
>
> Hello IPWAVErs,
>
> I submitted this -01 version addressing comments we received so far:
> https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-01
>
> Please comment.  We could still discuss and make a better -02 before
> the deadline for Chicago.
>
> This is the changelog: o Introduced message exchange diagram
> illustrating differences between 802.11 and 802.11 in OCB mode. o
> Introduced an appendix listing for information the list of 802.11
> messages that may be transmitted in OCB mode. o Removed appendix
> sections "Privacy Requirements", "Authentication Requirements" and
> "Security Certificate Generation". o Removed appendix section "Non IP
> Communications". o Introductory phrase in the Security Considerations
> section. o Improved the definition of "OCB". o Introduced theoretical
> stacked layers about IPv6 and IEEE layers including EPD. o Removed
> the appendix describing the details of prohibiting IPv6 on certain
> channels relevant to 802.11-OCB. o Added a brief reference in the
> privacy text about a precise clause in IEEE 1609.3 and .4. o
> Clarified the definition of a Road Side Unit. o Removed the
> discussion about security of WSA (because is non-IP). o Removed
> mentioning of the GeoNetworking discussion. o Moved references to
> scientific articles to a separate 'overview' draft, and referred to
> it.
>
> Alex
>
> Le 20/02/2017 à 17:29, [email-masked] a écrit :
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>> This draft is a work item of the IP Wireless Access in Vehicular
> Environments of the IETF.
>>
>> Title           : Transmission of IPv6 Packets over IEEE 802.11
> Networks in mode Outside the Context of a Basic Service Set
> (IPv6-over-80211ocb)
>> Authors         : Alexandre Petrescu Nabil Benamar Jérôme Härri
>> Christian Huitema Jong-Hyouk Lee Thierry Ernst Tony Li Filename
>> : draft-ietf-ipwave-ipv6-over-80211ocb-01.txt Pages           : 32
>> Date            : 2017-02-20
>>
>> Abstract: In order to transmit IPv6 packets on IEEE 802.11 networks
>> run outside the context of a basic service set (OCB, earlier
>> "802.11p") there is a need to define a few parameters such as the
>> recommended Maximum Transmission Unit size, the header format
>> preceding the IPv6 header, the Type value within it, and others.
>> This document describes these parameters for IPv6 and IEEE 802.11
>> OCB networks; it portrays the layering of IPv6 on 802.11 OCB
>> similarly to other known 802.11 and Ethernet layers - by using an
>> Ethernet Adaptation Layer.
>>
>> In addition, the document attempts to list what is different in
>> 802.11 OCB (802.11p) compared to more 'traditional' 802.11a/b/g/n
>> layers, layers over which IPv6 protocols operates without issues.
>> Most notably, the operation outside the context of a BSS (OCB) has
>> impact on IPv6 handover behaviour and on IPv6 security.
>>
>> An example of an IPv6 packet captured while transmitted over an
>> IEEE 802.11 OCB link (802.11p) is given.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-ipwave-ipv6-over-80211ocb/
>>
>>
>>
There's also a htmlized version available at:
>> https://tools.ietf.org/html/draft-ietf-ipwave-ipv6-over-80211ocb-01
>>
>>
>>
A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-ipwave-ipv6-over-80211ocb-01
>>
>>
>>
>>
Please note that it may take a couple of minutes from the time of
> submission
>> until the htmlized version and diff are available at
>> tools.ietf.org.
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> _______________________________________________ I-D-Announce
>> mailing list [email-masked]
>> https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft
>> directories: http://www.ietf.org/shadow.html or
>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Sun, 12 Mar 2017 18:04:24 +0100

Dick,

Please refer to this document when commenting:
draft-ietf-ipwave-ipv6-over-80211ocb-01.txt

If I understand your Word correctly, you propose the addition of the
following paragraph at the end of the introduction section.

> [RR1]There are currently no specifications for handover between OCB
> links since these are currently specified as LLC-1 links (i.e.
> connectionless).  Any handovers must be performed above the Data
> Link Layer.  Also, while there is no encryption applied below the
> network layer using 802.11p, 16092 does provide security services
> for applications to use so that there can easily be data security
> over the air w/o invoking IPsec.

If yes, then I will add it after this existing paragraph in the
Introduction:
> However, there may be some deployment considerations helping
> optimize the performances of running IPv6 over 802.11-OCB (e.g. in
> the case of handovers between 802.11 OCB-enabled access routers, or
> the consideration of using the IP security layer).

And remember that the "handover" description was moved out of the document.

Yours,

Alex

Le 21/02/2017 à 03:47, Dick Roy a écrit :
> should get it to you ASAP as there are significant issues
> surrounding the LLC sublayer and EPD operation throughout the draft
> that should be fixed.  In particular, the Ethernet Adaptation Layer
> doesn't really exist above the 802.11 MAC sublayer ... anywhere.
> It's all LLC sublayer operation.  The adaptation to which you refer
> happens in bridges that connect 802.11 links to Ethernet-based LANs.
>
> Cheers,
>
> RR
>
> -----Original Message----- From: its [mailto:[email-masked]]
> On Behalf Of Alexandre Petrescu Sent: Monday, February 20, 2017 8:41
> AM To: [email-masked] Subject: Re: [ipwave] I-D Action:
> "Security Certificate Generation". o Removed appendix section "Non
> IP Communications". o Introductory phrase in the Security
> Considerations section. o Improved the definition of "OCB". o
> Introduced theoretical stacked layers about IPv6 and IEEE layers
> including EPD. o Removed the appendix describing the details of
> prohibiting IPv6 on certain channels relevant to 802.11-OCB. o Added
> a brief reference in the privacy text about a precise clause in IEEE
> 1609.3 and .4. o Clarified the definition of a Road Side Unit. o
> Removed the discussion about security of WSA (because is non-IP). o
> Removed mentioning of the GeoNetworking discussion. o Moved
> references to scientific articles to a separate 'overview' draft, and
> referred to it.
>
> Alex
>
>> Christian Huitema Jong-Hyouk Lee Thierry Ernst Tony Li Filename :
>> draft-ietf-ipwave-ipv6-over-80211ocb-01.txt Pages           : 32
>> Date            : 2017-02-20
>>
>> Abstract: In order to transmit IPv6 packets on IEEE 802.11
>> networks run outside the context of a basic service set (OCB,
>> earlier "802.11p") there is a need to define a few parameters such
>> as the recommended Maximum Transmission Unit size, the header
>> format preceding the IPv6 header, the Type value within it, and
>> others. This document describes these parameters for IPv6 and IEEE
>> 802.11 OCB networks; it portrays the layering of IPv6 on 802.11
>> OCB similarly to other known 802.11 and Ethernet layers - by using
>> an Ethernet Adaptation Layer.
>>

---

From: Alexandre Petrescu <[email-masked]>
Date: Sun, 12 Mar 2017 18:43:03 +0100

Michelle,

I copy the list on this conversation.

Following your questioning, I propose to remove the following paragrap
from the introduction, since it is too much detail for an Introduction:

> The values of these parameters are precisely the same as IPv6 over
> Ethernet [RFC2464]: the recommended value of MTU to be 1500 octets,
> the Frame Format containing the Type 0x86DD, the rules for forming
> an Interface Identifier, the Address Mapping mechanism and the
> Stateless Address Auto-Configuration.

This paragraph stays in the introduction:
> The document then concentrates on the parameters of layering IP over
> 802.11 OCB as over Ethernet: value of MTU, the contents of Frame
> Format, the rules for forming Interface Identifiers, the mechanism
> for Address Mapping and for State-less Address Auto-configuration.
> These are precisely the same as IPv6 over Ethernet <xref
> target="RFC2464"/>.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Sun, 12 Mar 2017 18:56:31 +0100

Michelle,

You are questioning what does "1000011011011101" mean in the EthernetII 
Header.  The other fields deserve explanation, too.

I propose the following text:

>    Ethernet II Fields:
>
>    o  Destination Ethernet Address: the MAC destination address.
>
>    o  Source Ethernet Address: the MAC source address.
>
>    o  "1 0 0 0 0 1 1 0 1 1 0 1 1 1 0 1": binary representation of the
>       EtherType value 0x86DD.
>
>    o  IPv6 header and payload: the IPv6 packet containing IPv6 header
>       and payload.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Sun, 12 Mar 2017 19:09:29 +0100

Michelle,

You are pointing that we talk twice about apparently the same thing:
increasing the "Seq number" field of the 802.11 Header when the MTU is
smaller than the IP packet to be sent.

The paragraphs in question are:
> The default MTU for IP packets on 802.11p is 1500 octets.  It is the
>  same value as IPv6 packets on Ethernet links, as specified in
> [RFC2464].  This value of the MTU respects the recommendation that
> every link in the Internet must have a minimum MTU of 1280 octets
> (stated in [RFC2460], and the recommendations therein, especially
> with respect to fragmentation).  If IPv6 packets of size larger than
>  1500 bytes are sent on an 802.11-OCB interface 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.

and

> When the MTU value is smaller than the size of the IP packet to be
> sent, the IP layer fragments the packet into multiple IP fragments.
> During this operation, the "Sequence number" field of the 802.11 Data
> Header is increased.

I propose to replace the latter with a brief explanation:

> The Ethernet Adaptation Layer performs operations in relation to IP
> fragmentation and MTU.  One of these operations is briefly described
> in section <xref target="MTU"/>.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Sun, 12 Mar 2017 19:31:21 +0100

Michelle,

You are pointing that the section 5.4 "Address Mapping -- Unicast" 
section is empty.

I will explain why.

This section is one of the most difficult sections to write.

The original intention was that be precisely the same as section 6 
"Address Mapping -- Unicast" of RFC2464.

But process: IETF 6MAN WG committed on a path of updating the status of 
'core' IPv6 specs, including RFC 2464.  A promising document in that 
direction is draft-hinden-6man-rfc2464bis-01. This document is an 
individual proposal at this time.  Maybe soon there will be a call for 
adoption as WG item.  Until that's done, it's hard to say whether it's 
legitimate or not to copy something from it.

The text in question, that should come into our draft, in section 
"Address Mapping -- Unicast", is the following:
>    The procedure for mapping IPv6 unicast addresses into Ethernet link-
>    layer addresses is described in [DISC].  The Source/Target Link-layer
>    Address option has the following form when the link layer is
>    Ethernet.
>
>                     0                   1
>                     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
>                    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>                    |     Type      |    Length     |
>                    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>                    |                               |
>                    +-          Ethernet           -+
>                    |                               |
>                    +-           Address           -+
>                    |                               |
>                    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>    Option fields:
>
>    Type                1 for Source Link-layer address.
>                        2 for Target Link-layer address.
>
>    Length              1 (in units of 8 octets).
>
>    Ethernet Address    The 48 bit Ethernet IEEE 802 address, in
>                        canonical bit order.  This is the address the
>                        interface currently responds to, and may be
>                        different from the built-in address used to
>                        derive the Interface Identifier.

You will notice that text has a number of issues, that I list here for 
information:

- the [DISC] reference is RFC4861.  That text uses terms 'mapping' and 
'resolving' alternatively.  Whereas here we only say 'mapping'. 
'Mapping' is ambiguous in that it some times involve a message exchange 
like ND, other times not like when following a pre-written rule.  I 
would prefer to use 'resolve'.  But will that make it different from 
RFC2464?  Too big difference?

- the text seems to recommend to have a direct relationship between an 
Ethernet Address and an IP address.  This is an old formulation that 
IETF is trying to move away from; many RFCs were issued recently about 
these Interface IDs ensuring privacy.

Overall, this text deserves much clarification that I am not able to 
propose right now.

This should be further discussed before having text there.

What do you think?

What do WG members think?

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Sun, 12 Mar 2017 20:50:43 +0100

Michelle,

You are pointing that the text about privacy risks is more about
"tracking".  As such I propose the following.

OLD:
> As with all Ethernet and 802.11 interface identifiers ([RFC7721]),
> the identifier of an 802.11p interface may involve privacy risks.  A
> vehicle embarking an On-Board Unit whose egress interface is 802.11p
> may expose itself to eavesdropping and subsequent correlation of
> data; this may reveal data considered private by the vehicle owner.

NEW:
> As with all Ethernet and 802.11 interface identifiers ([RFC7721]),
> the identifier of an 802.11-OCB interface may involve privacy risks.
> A vehicle embarking an On-Board Unit whose egress interface is
> 802.11-OCB may expose itself to eavesdropping and subsequent
> correlation of data; this may reveal data considered private by the
> vehicle owner; there is a risk fo being tracked; see the privacy
> considerations described in <xref target="design-considerations"/>.

Alex