Re: [6lo] Generation of IPv6 IIDs

[Fernando Gont <[e-mail]>]

Hi, Eric,

On 05/01/2014 02:42 PM, Erik Nordmark wrote:
> On 4/30/14, 6:42 PM, Fernando Gont wrote:
>> Folks,
>>
>> We recently contacted the 6lo chairs asking whether there were any
>> 6lo-related documents that should be mentioned in the "Updates" of our
>> I-D: <http://tools.ietf.org/html/draft-ietf-6man-default-iids>.
> 
> Fernando,
> 
> Are you planning on specifying all the possible protocols tweaks that
> might be needed to existing RFCs in draft-ietf-6man-default-iids?

Are you referring to the corresponding 6lo documents, or the "ipv6 over
foo" documents we currently have in the "Updates" metadata?



> Unless you do you can't claim that it updates those RFCs.
> And that would be completely unwieldy.
> 
> I think it would be better to progress default-iids with
>  - SHOULD implement stable-privacy
>  - SHOULD use stable-privacy as default where it works (such as Ethernet)

Why not explicitly updating the "ipv6 over foo" documents in those cases
where stable-privacy does work?

FWIW, I believe the "Updates" tag is important, such that folks
implementing "ipv6 over foo" are somehow directed to default-iids...


>  - state that some issues have been identified in RFC X, Y, Z, as as
> those get addressed the SHOULD use will be applied to those as well.

I believe the only "issue" has been that related with header compression
in 6lo.

I gues one possible option is simply to not reference the aforementioned
RFC ni the "Updates", or maybe even do reference it, but consider such
case as a valid reason to go against the "SHOULD"/"SHOULD NOT" in
default-iids..

Thoughts? (i.e., take the above as brain-storming, rather than as a
strong statement)



> That way you avoid having to design all the solutions before
> default-iids can be progressed in 6man.

I certainly think that deafult-iids should wait for other work to be
progressed. If anything, it should be the other way around.


> 
> RFC 6775 (6lowpan-nd) makes the assumption that the host always has a
> link-local address configured with the EUI-64 of the host.
> That assumption is used in section 6.5.2 to send errors back to hosts.
> Note that we already know of a solution, which is local to the router
> implementation, which is already captured in section 9.7 in
> draft-chakrabarti-nordmark-6man-efficient-nd. 6lo might consider taking
> that suggestion and having either a short document which updates 6775 or
> doing a 6775-bis if there are other desirable updates (I think a
> transaction ID in the ARO is such another desirable update).
> 
> But IMHO we shouldn't have any such work hold up
> draft-ietf-6man-default-iids.

Agreed.

Thanks so much! (your comments and feedback are always very appreciated)

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492