Re: [6lo] Generation of IPv6 IIDs

[Dave Thaler <[e-mail]>]

> -----Original Message-----
> From: Fernando Gont [mailto:[e-mail]]
> Sent: Saturday, May 3, 2014 2:23 AM
> To: Erik Nordmark; [e-mail]
> Cc: [e-mail]; [e-mail];
> Dave Thaler
> Subject: Re: [6lo] Generation of IPv6 IIDs
> 
> 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...


Agree with Fernando.  Anything that is an RFC and "just works" with
stable-privacy should be listed with Updates.

> 
> 
> >  - 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)

My slight preference is to not mention it in default-iids itself.
However, I'm also ok with saying the 6lo issue is left for future work.
In my opinion, though, default-iids should NOT list anything as 
"a valid reason to go against the SHOULD/SHOULD NOT".

-Dave

> 
> 
> 
> > 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.

Agree.

> 
> 
> >
> > 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
> 
> 
>