Subject: Re: [6lo] 6tisch Digest, Vol 22, Issue 15

From: Martin Turon <[email-masked]>
Date: Tue, 7 Jul 2015 13:05:42 -0700

Hi Pascal,

> Please consider those options, and come discuss them at 6Lo:
>
>       Option 1 considers that a network where this specification applies
>       is physically separate from a network where the Mesh Header
>       defined in [RFC4944] is used.  With that assumption, the Mesh
>       Header dispatch space can be reused.  A variation is proposed
>       whereby the NALP pattern 00xxxxxx is reused instead of the Mesh
>       Header pattern.
>

The group has considered this option extensively, and there has been
consistent push-back, disapproval, and dissent.  Repurposing NALP (Not A
LowPan) is clearly problematic -- there MUST be a way for proprietary 15.4
(or other link) protocols to live in parallel with 6lo.  I'm not sure why
this repurposing proposal keeps coming back and getting characterized as
the "first option".  There are many other technical solutions, many quite
simple and natural extensions to 6lo architecture, that don't have the same
push back: defining a new compressed next header dispatch code for example.

Option 1 generally describes solutions that "fork 6lo" into two versions:
v1 (currently defined) and v2 (repurposed dispatch for RPL protocol) with
no way to discern which version is being used.  To the extent that 6lo is
an approved standard, forking it violates IETF conformance policy, unless
like IP, there is a version nibble, as IP uses to specify IPv4 or IPv6.  If
IPv4 and IPv6 had to be in physically separate networks that would be very
complex to manage, and arguably wouldn't work well.

Martin