Re: [6lo] Generation of IPv6 IIDs

On Thu, Jul 24, 2014 at 1:25 AM, Jonathan Hui (johui) <johui@cisco.com>
wrote:

>
> On Jul 23, 2014, at 6:05 PM, Erik Nordmark <nordmark@acm.org> wrote:
>
> > On 7/23/14, 5:57 PM, Fernando Gont wrote:
> >>
> >> On 07/22/2014 12:41 PM, Samita Chakrabarti wrote:
> >>> Based on the discussions at the 6lo list regarding the impact of
> >>> default-iid draft on 6lo/6lowpan documents and future ipv6-over-foo
> >>> 6lo documents, Ulrich, Ralph and myself had a discussion and our
> >>> recommendation to default-iid co-authors are to either list 6lo
> >>> specific RFCs or make a general statement about 6lo/6lowpan documents
> >>> for exceptions from default-iid  mandate. The future documents in 6lo
> >>> WG  would consider the default-iid recommendations when applicable.
> >>> But note that 6lo deals with  constrained nodes and
> >>> RFC6282/RFC4944/RFC6755 do require using IID bits for efficiency over
> >>> privacy in a constrained network environment that can be isolated
> >>> from the rest of the Internet.
> >> The question here maybe is whether we want to flag these documents as
> >> "exceptions", or whether we want to flag them as "these documents rely
> >> on MAC-address-based IIDs. They may continue to employ such IIDs while a
> >> solution that does not rely on such IIDs is generated".
> >
> > I think we should assume that those documents will be updated in the
> future to provide the option to work with other IIDs even if that comes
> with lower efficiency.
>
> Note that RFC 6282 already provides the option:
> - If the IID can be derived from MAC address, great.
> - If not, things will still work just with reduced efficiency.
>
> To recap, re-using the L2 addresses for IIDs contributes to the efficiency
of
IPHC [RFC 6282].  Using locally-assigned short MACs provides the greatest
efficiency.

Requiring randomly assigned IIDs can have a significant impact on 6lo
networks
with short frames, which already have reduced payloads due to security and
other
headers.  In some cases, random IIDs might necessitate an additional frame
per
message.

> Section 10 of RFC 4944 also provides the same option, but has since been
> replaced by the encoding specified in RFC 6282.
>
> Also note that 802.15.4 interfaces have both a stable MAC address (EUI-64)
> and a locally-significant, dynamic MAC address (Short Address).  Many of
> the arguments against MAC-address-based IIDs may not apply when using Short
> Addresses.
>
> I'm not sure that any of the arguments do apply when using locally assigned
short MAC addresses.  Please note that draft-ietf-6lo-6lobac *only* uses
locally
assigned short MAC addresses.

Kerry Lynn

> —
> Jonathan Hui
>
> _______________________________________________
> 6lo mailing list
> 6lo@ietf.org
> https://www.ietf.org/mailman/listinfo/6lo
>