Subject: Re: [6lo] Request for Ethertype for 6lowpan-encoded IPv6

From: Don Sturek <[email-masked]>
Date: Tue, 23 Feb 2016 13:02:58 -0800

Hi Pascal,

For the past several IEEE 802 meetings, the IEEE 802.15 group has held a
joint meeting with IEEE 802.1 (who seem to be the main point of contact
for EtherTypes).  This topic of a 6LoWPAN EtherType has been one of the
points of discussion (along with IEEE 802.15's proposal to finally create
a link layer interface over IEEE 802.15.4)

Here is what IEEE 802.1 told us with regard to an EtherType for 6LoWPAN
(which we asked for via IEEE 802.15 and were turned down, asked for from
Wi-SUN and were turned down then were told to ask IETF to request it):
1.   They won't allocate one unless your protocol provides for sub-typing
(e.g. The dispatch code in 6LoWPAN/6lo)
2.   They have very few so they really no longer allocate EtherTypes easily
3.   If they were to allocate an EtherType, they want the receiving
organization to be able to cover some clearly defined set of uses (e.g.
Existing 6LoWPAN, 6lo as it is currently defined plus some idea of how to
extend it assuming you are unlikely to get other EtherTypes).

I just scanned your 6loRH draft.  Do you re-use the RFC 4944/RFC 6282
Protocol Dispatch?  Is it possible to just use a new Dispatch from
4944/6282 along with a 6LoWPAN/6lo EtherType to cover what you want?

Feel free to propose 2 EtherTypes but you might want to attend an upcoming
IEEE 802 meeting to defend that decision.   I think with Ralph's draft
there will be clear reasons to provide a 6LoWPAN/6lo EtherType. If that
can be made to cover what you need that would the best solution that is
the ideal situation (and if not, we should discuss since that means the
dispatch mechanism in 4944/6282 should be re-thought to ensure we have
enough expansion capability going forward)

One concern I have on your draft is the intermingling of 6lo and RPL by
the way.  Not having read the draft in detail it could be that a
6loWPAN/6lo EtherType really doesn't well cover what you are trying to do
here anyway.

Don

On 2/23/16 12:31 PM, "6lo on behalf of Pascal Thubert (pthubert)"
<[email-masked] on behalf of [email-masked]> wrote:

>I'm not following you Paul
>
>In one hand you claim that an ethertype is hard to get and in the other
>you are asking to use that bullet with an incomplete scope? What will the
>next protocol that needs this new work do?
>
>Pascal
>
>> Le 23 févr. 2016 à 21:27, Paul Duffy (paduffy) <[email-masked]> a
>>écrit :
>> 
>>> On 2/23/2016 3:20 PM, Pascal Thubert (pthubert) wrote:
>>> Hello Ralph
>>> 
>>> The 6LoRH work is getting ready for last call.
>>> 
>>> If the demand comes from environments that use RPL, It should most
>>>certainly be included.
>>> 
>>> What is the requirement in terms of time frame?
>> 
>> Immediate if possible.    This request is coming after months of false
>>starts with IEEE.
>> 
>> 6LoRH is not in scope of the impacted effort.
>> 
>> 
>>> 
>>> Pascal
>>> 
>>>> Le 22 févr. 2016 à 16:15, Ralph Droms (rdroms) <[email-masked]> a
>>>>écrit :
>>>> 
>>>> 
>>>>> On Feb 22, 2016, at 7:59 AM 2/22/16, Pascal Thubert (pthubert)
>>>>><[email-masked]> wrote:
>>>>> 
>>>>> Hello Ralph and Paul:
>>>>> 
>>>>> Substantive:
>>>>> -----------------
>>>>> The draft is specific that the ethertype means what it names 6loENC.
>>>>> 
>>>>> 1) What would be the position of new work such as
>>>>> - https://tools.ietf.org/html/draft-ietf-6lo-routing-dispatch and
>>>>> - https://tools.ietf.org/html/draft-thubert-6lo-inner-compression ?
>>>> I would consider those documents to be out of scope of this document
>>>>as "future work".  One way to handle those extensions would be to have
>>>>them include explicit text about applying to IPv6 as carried by the
>>>>Ethertype assigned through draft-droms-6lo-ethertype-request.
>>>> 
>>>>> 2) The group flirted with Jonathan's idea of having more than one
>>>>>ethertype. For instance, we could have an ethertype that is more
>>>>>specific than "anything 6loENC can encode with paging" to more
>>>>>specific stuff that could be even better compressed. An example that
>>>>>was discussed was a route-over ethertype and a mesh-under ethertype
>>>>>so for instance page 1 does not have to be signaled in a route-over
>>>>>ethertype.
>>>>> Could that be envisioned?
>>>> I could imagine defining additional Ethertypes but I would consider
>>>>those extensions to be out of scope of this document, as well.
>>>> 
>>>> - Ralph
>>>> 
>>>>> Typos:
>>>>> ---------
>>>>> Datatgrams
>>>>> 
>>>>> Cheers,
>>>>> 
>>>>> Pascal
>>>>> 
>>>>>> -----Original Message-----
>>>>>> From: Ralph Droms (rdroms)
>>>>>> Sent: vendredi 19 février 2016 20:55
>>>>>> To: [email-masked] WG <[email-masked]>
>>>>>> Subject: Request for Ethertype for 6lowpan-encoded IPv6
>>>>>> 
>>>>>> (BCC: [email-masked])
>>>>>> 
>>>>>> Paul Duffy and I recently published
>>>>>>draft-droms-6lo-ethertype-request-00.
>>>>>> The purpose of this document is to demonstrate IETF consensus for
>>>>>> requesting an Ethertype to be used with IPv6 datagrams encoded
>>>>>>according
>>>>>> to RFC 4944/6282, in L2 protocols that have a protocol switch.
>>>>>> 
>>>>>> We'd like to move this document along quickly, because Wi-SUN
>>>>>>Alliance
>>>>>> would like to specify the Ethertype in the Wi-SUN FAN
>>>>>>specification.  Please
>>>>>> take a look at the document (it's barely over 3 pages, including
>>>>>>all the
>>>>>> boilerplate) and respond to the 6lo WG mailing list with comments.
>>>>>> 
>>>>>> - Ralph
>>> .
>> 
>
>_______________________________________________
>6lo mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/6lo

---

From: Gabriel Montenegro <[email-masked]>
Date: Tue, 23 Feb 2016 23:29:37 +0000

No hats opinion.

I'm with Robert and others: one Ethertype is enough.  

The rest are editorial comments:

Title: Don't like citing RFC's in the title. Just give the indication that it is the 6lo adaptation/encapsulation layer (or simply "6lo" layer).

As for the fact that there is ongoing work on this adaptation layer: we did discuss this with Ralph and he added "... may be extended and modified by future IETF standards document[s]".

I think that's enough. No need to mention IANA dispatch or the paging document, as both of these will indicate that they modify RFC4944 eventually. Even if those are mentioned, there's no need to mention 6loRH as that is once removed from the paging document.

Thanks,

Gabriel

> From: 6lo [mailto:[email-masked]] On Behalf Of Don Sturek
> Sent: Tuesday, February 23, 2016 13:03
> To: Pascal Thubert (pthubert) <[email-masked]>; Paul Duffy (paduffy)
> <[email-masked]>
> Cc: Ralph Droms (rdroms) <[email-masked]>; [email-masked]
> Subject: Re: [6lo] Request for Ethertype for 6lowpan-encoded IPv6
> 
> Hi Pascal,
> 
> joint meeting with IEEE 802.1 (who seem to be the main point of contact for
> EtherTypes).  This topic of a 6LoWPAN EtherType has been one of the points
> of discussion (along with IEEE 802.15's proposal to finally create a link layer
> interface over IEEE 802.15.4)
> 
> there will be clear reasons to provide a 6LoWPAN/6lo EtherType. If that can
> be made to cover what you need that would the best solution that is the
> ideal situation (and if not, we should discuss since that means the dispatch
> mechanism in 4944/6282 should be re-thought to ensure we have enough
> expansion capability going forward)
> 
> One concern I have on your draft is the intermingling of 6lo and RPL by the
> way.  Not having read the draft in detail it could be that a 6loWPAN/6lo
> EtherType really doesn't well cover what you are trying to do here anyway.
> 
> Don
> 
> 
> 
> >you are asking to use that bullet with an incomplete scope? What will
> >the next protocol that needs this new work do?
> >
> >Pascal
> >
> >>>>> -
> >>>>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ft
> >>>>> ools.ietf.org%2fhtml%2fdraft-ietf-6lo-routing-dispatch&data=01%7c0
> >>>>>
> 1%7cGabriel.Montenegro%40microsoft.com%7c7fcf05135273416a120408d33
> >>>>>
> c94bdaa%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=Vfu5oRzfV%2b
> h
> >>>>> q3g1y%2bTYd1Lu8xx3nBokd6sjECuL8XC8%3d and
> >>>>> -
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.iet
> f.org%2fhtml%2fdraft-thubert-6lo-inner-
> compression&data=01%7c01%7cGabriel.Montenegro%40microsoft.com%7c7f
> cf05135273416a120408d33c94bdaa%7c72f988bf86f141af91ab2d7cd011db47
> %7c1&sdata=mZgsMUUC8rd7GgexuTOgPMNFZUXvssy9ycXIhYukRFc%3d ?
> >>>> I would consider those documents to be out of scope of this
> >>>>document as "future work".  One way to handle those extensions would
> >>>>be to have them include explicit text about applying to IPv6 as
> >>>>carried by the Ethertype assigned through draft-droms-6lo-ethertype-
> request.
> >>>>
> >>>>>specific stuff that could be even better compressed. An example
> >>>>>that was discussed was a route-over ethertype and a mesh-under
> >>>>>ethertype so for instance page 1 does not have to be signaled in a
> >>>>>route-over ethertype.
> >>>>>>according  to RFC 4944/6282, in L2 protocols that have a protocol
> >>>>>>switch.
> >>>>>>
> >>>>>>Alliance  would like to specify the Ethertype in the Wi-SUN FAN
> >>>>>>specification.  Please  take a look at the document (it's barely
> >>>>>>over 3 pages, including all the
> >https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ie
> >tf.org%2fmailman%2flistinfo%2f6lo&data=01%7c01%7cGabriel.Montenegro
> %40m
> >icrosoft.com%7c7fcf05135273416a120408d33c94bdaa%7c72f988bf86f141af9
> 1ab2
> >d7cd011db47%7c1&sdata=joGEwHNx0QVSwb1E7KkvEiYHBHrP7cedS7FNT16
> w8%2bw%3d
> 
> 
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.iet
> f.org%2fmailman%2flistinfo%2f6lo&data=01%7c01%7cGabriel.Montenegro%4
> 0microsoft.com%7c7fcf05135273416a120408d33c94bdaa%7c72f988bf86f141a
> f91ab2d7cd011db47%7c1&sdata=joGEwHNx0QVSwb1E7KkvEiYHBHrP7cedS7F
> NT16w8%2bw%3d

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 24 Feb 2016 08:23:09 +0000

Hello Don:

> 4944/6282 along with a 6LoWPAN/6lo EtherType to cover what you want?

It appears that finding encoding space is a lot harder and longer than describing the encoding itself. 6LoRH uses encoding space that is taken from the 6LoWPAN dispatch space and is declared in https://www.ietf.org/id/draft-ietf-6lo-paging-dispatch-01.txt. It took the group more than one year to reach that point and I would not reopen that box.

>From what I'm reading below, I gather that 6lo should be free to extend what it does within its dispatch space, and that should still be valid within the ethertype. I also read that we need to declare to the IEEE what our process is. In this particular case, I think that the IEEE understands very well how the IETF updates RFCs with other RFCs, the IANA registry, etc...

Do I have it right?

Pascal

> From: Don Sturek [mailto:[email-masked]]
> Sent: mardi 23 février 2016 22:03
> Cc: [email-masked]; Ralph Droms (rdroms) <[email-masked]>

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 24 Feb 2016 09:28:13 +0100

RFC 4944 has the dispatch code registry as an extension point.
Anything registered there will be covered by the Ethertype we are
discussing.

Grüße, Carsten

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 24 Feb 2016 08:42:09 +0000

Hello Carsten:

This mail crossed with my response to Ralph. This is exactly what I wish the text in the draft would say.
At the moment, I read it as restrictive to RFC 4944 and RFC 6282, and objected.

Cheers,

Pascal

> From: Carsten Bormann [mailto:[email-masked]]
> Sent: mercredi 24 février 2016 09:28
> To: Pascal Thubert (pthubert) <[email-masked]>
> Cc: Don Sturek <[email-masked]>; Paul Duffy (paduffy)
> <[email-masked]>; Ralph Droms (rdroms) <[email-masked]>;
> [email-masked]
> Anything registered there will be covered by the Ethertype we are discussing.
> 
> Grüße, Carsten
> 
> 
> > It appears that finding encoding space is a lot harder and longer than
> describing the encoding itself. 6LoRH uses encoding space that is taken from
> the 6LoWPAN dispatch space and is declared in
> https://www.ietf.org/id/draft-ietf-6lo-paging-dispatch-01.txt. It took the
> group more than one year to reach that point and I would not reopen that
> box.
> >
> >>From what I'm reading below, I gather that 6lo should be free to extend
> what it does within its dispatch space, and that should still be valid within
> the ethertype. I also read that we need to declare to the IEEE what our
> process is. In this particular case, I think that the IEEE understands very well
> how the IETF updates RFCs with other RFCs, the IANA registry, etc...
> >
> > Do I have it right?
> >
> > Pascal
> >
> >> To: Pascal Thubert (pthubert) <[email-masked]>; Paul Duffy
> >> (paduffy) <[email-masked]>
> >> For the past several IEEE 802 meetings, the IEEE 802.15 group has
> >> held a joint meeting with IEEE 802.1 (who seem to be the main point
> >> of contact for EtherTypes).  This topic of a 6LoWPAN EtherType has
> >> been one of the points of discussion (along with IEEE 802.15's
> >> proposal to finally create a link layer interface over IEEE 802.15.4)
> >>
> >> Here is what IEEE 802.1 told us with regard to an EtherType for
> >> 6LoWPAN (which we asked for via IEEE 802.15 and were turned down,
> >> asked for from Wi-SUN and were turned down then were told to ask IETF
> to request it):
> >> Existing 6LoWPAN, 6lo as it is currently defined plus some idea of
> >> how to extend it assuming you are unlikely to get other EtherTypes).
> >>
> >> there will be clear reasons to provide a 6LoWPAN/6lo EtherType. If
> >> that can be made to cover what you need that would the best solution
> >> that is the ideal situation (and if not, we should discuss since that
> >> means the dispatch mechanism in 4944/6282 should be re-thought to
> >> ensure we have enough expansion capability going forward)
> >>
> >> One concern I have on your draft is the intermingling of 6lo and RPL
> >> by the way.  Not having read the draft in detail it could be that a
> >> 6loWPAN/6lo EtherType really doesn't well cover what you are trying to
> do here anyway.
> >>
> >> Don
> >>
> >>
> >>
> >>> In one hand you claim that an ethertype is hard to get and in the
> >>> other you are asking to use that bullet with an incomplete scope?
> >>> What will the next protocol that needs this new work do?
> >>>
> >>> Pascal
> >>>
> >>>> Le 23 févr. 2016 à 21:27, Paul Duffy (paduffy) <[email-masked]>
> >>>> a écrit :
> >>>>
> >>>>>> Le 22 févr. 2016 à 16:15, Ralph Droms (rdroms) <[email-masked]>
> >>>>>> a écrit :
> >>>>>>
> >>>>>>
> >>>>>> document as "future work".  One way to handle those extensions
> >>>>>> would be to have them include explicit text about applying to
> >>>>>> IPv6 as carried by the Ethertype assigned through
> >>>>>> draft-droms-6lo-ethertype-
> >> request.
> >>>>>>> 2) The group flirted with Jonathan's idea of having more than
> >>>>>>> one ethertype. For instance, we could have an ethertype that is
> >>>>>>> more specific than "anything 6loENC can encode with paging" to
> >>>>>>> more specific stuff that could be even better compressed. An
> >>>>>>> example that was discussed was a route-over ethertype and a
> >>>>>>> mesh-under ethertype so for instance page 1 does not have to be
> >>>>>>> signaled in a route-over ethertype.
> >>>>>> I could imagine defining additional Ethertypes but I would
> >>>>>> consider those extensions to be out of scope of this document, as
> well.
> >>>>>>
> >>>>>> - Ralph
> >>>>>>
> >>>>>>> Typos:
> >>>>>>> ---------
> >>>>>>> Datatgrams
> >>>>>>>
> >>>>>>> Cheers,
> >>>>>>>
> >>>>>>> Pascal
> >>>>>>>
> >>>>>>>> The purpose of this document is to demonstrate IETF consensus
> >>>>>>>> for requesting an Ethertype to be used with IPv6 datagrams
> >>>>>>>> encoded according  to RFC 4944/6282, in L2 protocols that have
> >>>>>>>> a protocol switch.
> >>>>>>>>
> >>>>>>>> specification.  Please  take a look at the document (it's
> >>>>>>>> barely over 3 pages, including all the

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 24 Feb 2016 10:15:11 +0100

> At the moment, I read it as restrictive to RFC 4944 and RFC 6282, and objected.

There are certainly different ways to read this.

The Ethertype for IPv6 is allocated to RFC 2460.  This doesn't mean that
no transport protocols that didn't happen to exist at that time can be
used over Ethernet -- that's what the Internet Protocol registry is
there for.  The situation here is exactly the same: whatever plugs into
4944 using 4944's extension points, *is* 4944 (which happens to include
6282), and the text should reflect that if it currently doesn't.

Do you have specific wording proposals?

Grüße, Carsten

---

From: Robert Cragie <[email-masked]>
Date: Wed, 24 Feb 2016 12:56:05 +0000

+1

Robert

On 23 February 2016 at 23:29, Gabriel Montenegro <
[email-masked]> wrote:

> Title: Don't like citing RFC's in the title. Just give the indication that
> it is the 6lo adaptation/encapsulation layer (or simply "6lo" layer).
>
> As for the fact that there is ongoing work on this adaptation layer: we
> did discuss this with Ralph and he added "... may be extended and modified
> by future IETF standards document[s]".
>
> I think that's enough. No need to mention IANA dispatch or the paging
> document, as both of these will indicate that they modify RFC4944
> eventually. Even if those are mentioned, there's no need to mention 6loRH
> as that is once removed from the paging document.
>
> Thanks,
>
> Gabriel
>
> for
> can
> the

---

From: Don Sturek <[email-masked]>
Date: Wed, 24 Feb 2016 05:13:34 -0800

+1

The note just below from Carsten is exactly what the IEEE 802.1 folks want
to hear.  This would then cover RFCs 4944, 6282 and any later extensions
that are made that re-use the dispatch code these RFCs share (presumably
embodied in new RFCs)

Don

On 2/24/16 12:28 AM, "6lo on behalf of Carsten Bormann"
<[email-masked] on behalf of [email-masked]> wrote:

>>describing the encoding itself. 6LoRH uses encoding space that is taken
>>from the 6LoWPAN dispatch space and is declared in
>>https://www.ietf.org/id/draft-ietf-6lo-paging-dispatch-01.txt. It took
>>the group more than one year to reach that point and I would not reopen
>>that box.
>> 
>>>what it does within its dispatch space, and that should still be valid
>>>within the ethertype. I also read that we need to declare to the IEEE
>>>what our process is. In this particular case, I think that the IEEE
>>>understands very well how the IETF updates RFCs with other RFCs, the
>>>IANA registry, etc...
>> 
>> Do I have it right?
>> 
>> Pascal
>> 
>>>that can
>>>by the
>>>>other
>>>>>>>would

---

From: "Ralph Droms (rdroms)" <[email-masked]>
Date: Wed, 24 Feb 2016 13:16:02 +0000

> On Feb 24, 2016, at 3:28 AM 2/24/16, Carsten Bormann <[email-masked]> wrote:
> 

As Gabriel pointed out, the current document includes this text:

   6loENC as defined in RFC 4944 and
   RFC 6282 may be extended and modified by future IETF standards
   document.

which is intended as a general statement allowing extension to the use of the new Ethertype in the future.  Please suggest specific alternative text, either here or elsewhere in the document, if you don't think the current text is adequate.

- Ralph

---

From: Don Sturek <[email-masked]>
Date: Wed, 24 Feb 2016 05:17:41 -0800

Hi Pascal,

Disclaimer:  I am not an expert (and not even a regular atendee) of IEEE
802.1.  My main focus has been IEEE 802.15.

That said, we have now held 3-4 of these joint meetings with IEEE 802.1
over the past year and their message has been clear.   The RFC 4944/6282
Dispatch and the existing use cases covered by our EtherType request are
key.   They will be happy to hear that we can cover new use cases using
the same Dispatch code and without a new EtherType request.   Many of the
regular IEEE 802.1 attendees are active in IETF so they already know the
process.

Don

---

From: Michael Richardson <[email-masked]>
Date: Wed, 24 Feb 2016 09:52:06 -0500

Carsten Bormann <[email-masked]> wrote:
    >> This mail crossed with my response to Ralph. This is exactly what I
    >> wish the text in the draft would say.  At the moment, I read it as
    >> restrictive to RFC 4944 and RFC 6282, and objected.

    > The Ethertype for IPv6 is allocated to RFC 2460.  This doesn't mean
    > that no transport protocols that didn't happen to exist at that time
    > can be used over Ethernet -- that's what the Internet Protocol registry
    > is there for.  The situation here is exactly the same: whatever plugs
    > into 4944 using 4944's extension points, *is* 4944 (which happens to
    > include 6282), and the text should reflect that if it currently
    > doesn't.

Then I propose that 6282 be removed from the title, and specification.

Perhaps it is the explicit mention of 6282 that makes it seem like the
specification is exhaustive and prescriptive in which updates the ethertype
covers.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 24 Feb 2016 11:51:53 -0600

Hi all,

While reading the Ethertype discussions, I happened to remember one
thing from the past, maybe about 8-10 years ago.

There were discussions of how to transport EAP for secure
bootstrapping. We considered PANA and 802.1X and PANA was selected.
You know why?
Because they said 802.15 does not have an Ethertype and PANA was doing
everything in IP.
At that time I was on the 802.1X side.

I think Paul will remember this.

What happened since then that we needed an Ethertype so urgently,
while it seems like Ethertypes are being depleted?

I am curious on this from a historical point of view.

Regards,

Behcet

---

From: Paul Duffy <[email-masked]>
Date: Wed, 24 Feb 2016 13:02:57 -0500

Hi Bechet

Are you referring to Zigbee IP related discussions?

---

From: Robert Cragie <[email-masked]>
Date: Wed, 24 Feb 2016 18:32:13 +0000

Hi Behcet,

This is going somewhat offtopic but I will respond anyway.

There is no doubt that some sort of protocol discriminator (i.e. Ethertype)
would have been useful in 802.15.4. My guess is (and it is a guess) that it
wasn't included in the beginning is because, with 127 byte packets, you
want to strip out as much as possible. Generally speaking up to now it
hasn't proved too problematic because WPANs tend to be closed systems. The
only point it did become a pain IIRC was the inability to distinguish
ZigBee NWK and 6LoWPAN frames as the first byte of a ZigBee NWK frame was
not NALP - mainly because ZigBee NWK frames were there before 6LoWPAN.

The EAP/802.1X argument is totally different. For ZigBee IP (which used
802.15.4-2006), we did indeed look at all options and I distinctly remember
a proposal which we called EAPOLP (EAP over LoWPAN) that used the 6LoWPAN
dispatch space to indicate an equivalent EAPOL frame. The issue for ZigBee
IP is that it is a route-over network and you still have to route the EAP
message through the mesh - not so easy with EAPOL, which is a link-layer
protocol. We looked at using RADIUS (an EAP transport) but that is really
designed for dial-up modems. PANA (an EAP transport) fitted at the time
because we a) didn't have to design EAPOLP and b) as an EAP transport
worked fine single hop and subsequently relayed through the mesh - a single
authentication transport.

Things have moved on with later versions of 802.15.4 with the inclusion of
IEs so there is certainly scope to carry EAP comfortably within an IE now,
which is presumably what is in 802.15.9 (I haven't been involved in IEEE
for some time). There still needs to be a defined solution for carrying the
EAP through a route-over mesh though, although I am sure that has been
developed for alternative networks as well.

Robert

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 24 Feb 2016 13:43:35 -0600

Hi Robert,

Ethertype is what the protocol field in IP header, it identifies the
higher later protocol in the Ethernet frame that is being carried.

I think Ethernet is the key word here. 802.15 for long time wished to
stay away from Ethernet.

It seems like recently this is started to change, 802.15 now has
mesh-under protocol 802.15.10 and KMP 802.15.9.

Looking back I believe that 802.1X should have been chosen.

Regards,

Behcet

On Wed, Feb 24, 2016 at 12:32 PM, Robert Cragie
<[email-masked]> wrote:
> wasn't included in the beginning is because, with 127 byte packets, you want
> to strip out as much as possible. Generally speaking up to now it hasn't
> proved too problematic because WPANs tend to be closed systems. The only
> point it did become a pain IIRC was the inability to distinguish ZigBee NWK
> and 6LoWPAN frames as the first byte of a ZigBee NWK frame was not NALP -
> mainly because ZigBee NWK frames were there before 6LoWPAN.
>
> because we a) didn't have to design EAPOLP and b) as an EAP transport worked
> fine single hop and subsequently relayed through the mesh - a single
> which is presumably what is in 802.15.9 (I haven't been involved in IEEE for
> some time). There still needs to be a defined solution for carrying the EAP
> through a route-over mesh though, although I am sure that has been developed
> for alternative networks as well.
>
> Robert
>
>> > do

---

From: Don Sturek <[email-masked]>
Date: Wed, 24 Feb 2016 12:12:42 -0800

Hi Behcet,

The soon-to-be-published IEEE 802.15.9 will support 802.1X as a key
management protocol.

Don

On 2/24/16 11:43 AM, "Behcet Sarikaya" <[email-masked]> wrote:

>>want
>>worked
>>>held a
>>>6LoWPAN
>>>how
>>> > to
>>>that
>>>by
>>>a
>>>https://tools.ietf.org/html/draft-thubert-6lo-inner-compression ?
>>>document
>>>one
>>>that
>>>consider

---

From: Paul Duffy <[email-masked]>
Date: Wed, 24 Feb 2016 15:48:52 -0500

On 2/24/2016 1:32 PM, Robert Cragie wrote:
> There is no doubt that some sort of protocol discriminator (i.e. 
> Ethertype) would have been useful in 802.15.4. My guess is (and it is 
> a guess) that it wasn't included in the beginning is because, with 127 
> byte packets, you want to strip out as much as possible. Generally 
> speaking up to now it hasn't proved too problematic because WPANs tend 
> to be closed systems. The only point it did become a pain IIRC was the 
> inability to distinguish ZigBee NWK and 6LoWPAN frames as the first 
> byte of a ZigBee NWK frame was not NALP - mainly because ZigBee NWK 
> frames were there before 6LoWPAN.

Agree that lack of a protocol discriminator was short sighted.  15.9 now 
provides a solution.

A contrast in styles, LPWANs are addressing the protocol discriminator 
issue before the tech is deployed.   This is a good thing!

>
> The EAP/802.1X argument is totally different. For ZigBee IP (which 
> used 802.15.4-2006), we did indeed look at all options and I 
> distinctly remember a proposal which we called EAPOLP (EAP over 
> LoWPAN) that used the 6LoWPAN dispatch space to indicate an equivalent 
> EAPOL frame. The issue for ZigBee IP is that it is a route-over 
> network and you still have to route the EAP message through the mesh - 
> not so easy with EAPOL, which is a link-layer protocol. We looked at 
> using RADIUS (an EAP transport) but that is really designed for 
> dial-up modems. PANA (an EAP transport) fitted at the time because we 
> a) didn't have to design EAPOLP and b) as an EAP transport worked fine 
> single hop and subsequently relayed through the mesh - a single 

PANA was indeed chosen for ZIP.  Partly because it had spec sitting on 
the shelf ready to go (with the addition of a few supporting RFCs).

Though Cisco is an advocate of EAP/802.1X tactics, we did not at the 
time bring forth a public spec re: how one does this over 15.4e.

>
> Things have moved on with later versions of 802.15.4 with the 
> inclusion of IEs so there is certainly scope to carry EAP comfortably 
> within an IE now, which is presumably what is in 802.15.9 (I haven't 
> been involved in IEEE for some time). There still needs to be a 
> defined solution for carrying the EAP through a route-over mesh 
> though, although I am sure that has been developed for alternative 
> networks as well.
>
> Robert
>
> On 24 February 2016 at 17:51, Behcet Sarikaya <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi all,
>
>     On Tue, Feb 23, 2016 at 3:02 PM, Don Sturek <[email-masked]
>     <mailto:[email-masked]>> wrote:
>     > Hi Pascal,
>     >
>     > <[email-masked] <mailto:[email-masked]> on behalf of
>     [email-masked] <mailto:[email-masked]>> wrote:
>     >
>     >>> Le 23 févr. 2016 à 21:27, Paul Duffy (paduffy)
>     <[email-masked] <mailto:[email-masked]>> a
>     >>>écrit :
>     >>>
>     >>>>> Le 22 févr. 2016 à 16:15, Ralph Droms (rdroms)
>     <[email-masked] <mailto:[email-masked]>> a
>     >>>>>écrit :
>     >>>>>
>     >>>>>
>     >>>>>><[email-masked] <mailto:[email-masked]>> wrote:
>     >>>>>>
>     >>>>>> Hello Ralph and Paul:
>     >>>>>>
>     >>>>>> Substantive:
>     >>>>>> -----------------
>     https://tools.ietf.org/html/draft-ietf-6lo-routing-dispatch and
>     >>>>>> -
>     >>>>>>> To: [email-masked] <mailto:[email-masked]> WG <[email-masked]
>     <mailto:[email-masked]>>
>     >>>>>>> (BCC: [email-masked] <mailto:[email-masked]>)
>     >>>>>>>
>     >>[email-masked] <mailto:[email-masked]>
>     > [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>