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

[Brian E Carpenter <[e-mail]>]

Hi,

Some comments, but not a full review:

>    -  IPv6 over ATM Networks [RFC2492]

Is this still worth mentioning?

>    -  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?
 
>    -  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/.)

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

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

> 6.1.  IP Version 6 Addressing Architecture - RFC 4291
> 
>    The IPv6 Addressing Architecture [RFC4291] MUST be supported.
> 
>    **BIS Update to 4291-bis **

Maybe not :-(

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

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

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

> 14.  Router-Specific Functionality

I think you should require BCP198 (RFC7068) support.

Regards
     Brian