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

[Timothy Winters <[e-mail]>]

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?


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

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

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

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