Re: I-D Action: draft-ietf-6man-rfc6434-bis-01.txt

[Tim Chown <[e-mail]>]

Hi,

In-line...

> On 16 Jul 2017, at 09:25, Timothy Winters <[e-mail]> wrote:
> 
> Hi Brian,
> 
> On Sun, Jul 16, 2017 at 12:06 AM, Brian E Carpenter <[e-mail]> wrote:
> Hi,
> 
> Some comments, but not a full review:
> 
> >    -  IPv6 over ATM Networks [RFC2492]
> 
> Is this still worth mentioning?
> 
> Probably not, we'll remove this in the next draft.  How do you feel about Frame Relay?

At present it seems we’ll leave that in.

> >    -  IP version 6 over PPP [RFC5072]
> >
> >    In addition to traditional physical link-layers, it is also possible
> >    to tunnel IPv6 over other protocols.  Examples include:
> 
> Shouldn't PPP be in this list, not the previous list?
> Yes. 
> 
> >    -  Teredo: Tunneling IPv6 over UDP through Network Address
> >       Translations (NATs) [RFC4380]
> >
> >    -  Section 3 of "Basic Transition Mechanisms for IPv6 Hosts and
> >       Routers" [RFC4213]
> >
> >    **BIS Do we want a small section somewhere on UDP IPv6 tunneling, and
> >    issues like RFC 6935, or 6936?**
> 
> Maybe. But the field is evolving: Teredo is surely obsolescent, there's
> also TSP (RFC5572), and draft-ietf-intarea-gue is in progress. So I wonder
> what you can really say.

So I think we’ll not ad text here.

> > 5.1.  Internet Protocol Version 6 - RFC 2460
> >
> >    The Internet Protocol Version 6 is specified in [RFC2460].  This
> >    specification MUST be supported.
> >
> >    **BIS Again, update for RFC 2460 -bis **
> >
> >    Any unrecognized extension headers or options MUST be processed as
> >    described in RFC 2460.
> 
> As well as s/2460/8200/, I suggest s/processed/treated/ to avoid another
> debate about the meaning of 'processed' ;-).
> 
> (And don't forget s/1981/8201/.)
> Thanks, we'll make all those updates. 
> 
> > 5.7.  IPv6 Jumbograms - RFC 2675
> ...
> >     and there is essentially no reported experience from usage.
> >    Consequently, IPv6 Jumbograms [RFC2675] remain optional at this time.
> >
> >    **BIS Are these used?  Do we need to modify the text for that? **
> 
> I don't think so. They appear to be harmless and maybe somebody will
> need them one day, so there is no obvious argument for deprecation.
> K, we'll remove the note. 
> 
> > 5.10.  First-Hop Router Selection - RFC 8028
> ...
> >    Hosts that may be deployed in such multihomed environments SHOULD
> >    follow the guidance given in [RFC8028].
> 
> Which should therefore be listed as a Normative reference.
> Thanks, we'll update that to Normative. 
> 
> > 6.1.  IP Version 6 Addressing Architecture - RFC 4291
> >
> >    The IPv6 Addressing Architecture [RFC4291] MUST be supported.
> >
> >    **BIS Update to 4291-bis **
> 
> Maybe not :-(
> I still have hope..... 
> 
> >    **BIS Add note on Why /64?  RFC 7421, after the conclusion of the
> >    RFC4291-bis (lengthy!!!) discussions on the 64-bit IID topic.  But no
> >    need for /127 p2p text RFC 6164.  And no need for note on IID
> >    significance, as per RFC 7136. **
> 
> I'm not sure we need to mention RFC 7421 here at all. If 4291bis gets
> published, it will be mentioned there. If it doesn't get published,
> 64 remains fixed anyway.
> Thanks for the feedback. 

Yes, we’ll leave it a little while to see how 4291-bis pans out.

> > 6.3.  IPv6 Stateless Address Autoconfiguration - RFC 4862
> >
> >    Hosts MUST support IPv6 Stateless Address Autoconfiguration as
> >    defined in either [RFC4862] or [RFC7217].
> 
> That's wrong, surely? SLAAC is defined in 4862, and 7217 doesn't even
> formally update it. I think you should simply delete 'or [RFC7217]'.
> 
> >                                              It is recommended that,
> >    unless there is a specific requirement for MAC addresses to be
> >    embedded in an IID, nodes follow the procedure in RFC7217 to generate
> >    SLAAC-based addresses.
> 
> That only applies if a stable IID is wanted.  I would suggest:
> 
> It is recommended that,
> unless there is a specific requirement for MAC addresses to be
> embedded in an IID, nodes follow the procedures in [RFC7217]
> or [RFC4941] (see below) to generate SLAAC-based addresses.
> 
> (I think we've already established that it's possible to operate
> a node that has no stable global-scope address.)
> OK, this text looks fine to me. 

Or we could just point at RFC8064?

> > 6.6.  Default Address Selection for IPv6 - RFC 6724
> >
> >    IPv6 nodes will invariably have multiple addresses configured
> >    simultaneously, and thus will need to choose which addresses to use
> >    for which communications.  The rules specified in the Default Address
> >    Selection for IPv6 [RFC6724] document MUST be implemented.
> 
> I am concerned about the famous rule 5.5 in RFC6724. It's optional there,
> but elsewhere you have a SHOULD for RFC8028, whose section 3.3 in turn
> promotes rule 5.5 to a SHOULD. Could we add that promotion here
> too? Otherwise there is a complicated trail for implementers to follow.
> I like this idea, how about.
> 
> Since RFC 8028 updates rule 5.5 from RFC 6724 implementations SHOULD implement this rule. 
> 
> > 14.  Router-Specific Functionality
> 
> I think you should require BCP198 (RFC7068) support.
> Interesting thought (should be RFC7608).   I don't have a problem adding this, I'll check with the co-authors. 

No preference either way here.

Thanks Brian,
Tim

> 
> Regards
>      Brian
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 
> 
> 
> -- 
> Now offering testing for SDN applications and controllers in our SDN switch test bed. Learn more today http://bit.ly/SDN_IOLPR
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------