Re: I-D Action: draft-ietf-6man-default-iids-04.txt

[Kerry Lynn <[e-mail]>]

On Tue, Jul 14, 2015 at 3:24 PM, Christian Huitema <[e-mail]>
wrote:

> > "Future specifications SHOULD NOT specify IPv6 address generation
> schemes that
> > embed the underlying link-layer address in the IID. In some cases,
> embedding the
> > link-layer address in the IID may reduce resource requirements such as
> energy,
> > bandwidth and packet transmission by facilitating header compression in
> constrained
> > devices. In such cases, future specifications MAY include address
> generation schemes
> > that embed the link-layer address in the IID, but MUST also specify an
> alternative
> > address generation scheme.”
>
> That's too weak a restriction. It does not include the part about "MUST
> NOT embed a globally unique identifier," which is the core of the issue.
>
> I would rather go for:
>
> "Future specifications SHOULD NOT specify IPv6 address generation schemes
> that
> embed the underlying link-layer address in the IID. There MAY be some
> exceptions
> in cases where network technologies works under very restrictive
> constraints.
> These exceptions MUST be reviewed on a case by case basis. Specifications
> allowing address generation schemes that embed the link-layer address in
> the IID
> under such exceptions MUST also specify an alternative address generation
> scheme.”
>
> I strongly disagree; I think Ralph's wording more closely reflects the
consensus
that has developed over several meetings now.  As I understand that
consensus,
the directive is SHOULD NOT embed L2 addresses in IIDs and MUST specify a
scheme by which privacy IIDs can be generated.  At that point, it seems to
be a
local matter whether privacy IIDs are configured or not.  The simplest IoT
devices
will probably not have a UI nor a good source of entropy, so injecting
secret keys
into these devices becomes an operational consideration.

I also do not agree that every new IP-over-6lo proposal should need to
repeat the
same arguments ("We'd really like to be able to use RFC 6282 compression"),
subject to the constitution of the IESG at the time.  Instead, I think it
would be
helpful for those who understand the issue best (the I-D authors and other
subject matter experts) to agree on language that could be included in
future
proposals as BCP to implementers.  Something like:

   A 64-bit privacy IID is RECOMMENDED for routable addresses and SHOULD
   be locally generated according to [I-D.ietf-6man-default-iids
<https://tools.ietf.org/html/draft-ietf-6lo-6lobac-02#ref-I-D.ietf-6man-default-iids>].
A
   node that generates a 64-bit privacy IID MUST register it with its
   local router(s) by sending a Neighbor Solicitation (NS) message with
   the Address Registration Option (ARO) and process Neighbor
   Advertisements (NA) according to [RFC6775
<https://tools.ietf.org/html/rfc6775>].


The acceptable alternatives (including managed opaque DHCPv6 addresses)
would
be spelled out in ID-ietf-6man-default-iids.  This statement would be
something like
the Surgeon General's warning that appears on every pack of cigs in the US;
we
can't stop you from smoking, but we want you to know it's a very bad idea.

Regards, Kerry Lynn

-- Christian Huitema
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>