Hi Ole.
Thanks for the review!
> I'm on the fence with regards to this document. if this document is
> meant to be the RFC1122/1812 document for IPv6, I think we are too
> early in the deployment of IPv6 to have gathered enough experience
> with what works and what doesn't. as a profile of an IPv6 node
> though, it isn't too far off.
As Bob says, this is a revision of an existing document. Its a much
more current set of recommendations than RFC 4294.
> a couple of comments:
> * section 5.3. Default Router Preferences and More-Specific Routes - RFC 4191
> this is a "MAY wish" and in conflict with RFC6204, L-3.
> please make this a SHOULD or even a MUST (as hosts not supporting it will
> not be able to interoperate on networks behind
> RFC6204 routers.
I'm not entirely sure what to do here. RFC 4191 is not widely
implemented, AFAIK. It's in Windows Vista (and onwards) and also
Linux. Not sure where else (I'm guessing not on Macs?)
So, I'm not at all sure we should recommend it as a SHOULD. IMO, its
not a crucial document, and its not widely implemented.
Can someone explain to me the rationale for mandating 4191 in 6204?
What was the scenario that was envisioned that necessitates 4191?
> * RFC2675: I would just remove that.
The docuent currently says:
IPv6 Jumbograms [RFC2675] MAY be supported.
How about I replace that with:
IPv6 Jumbograms [RFC2675] are an optional extension that allow
the sending of IP datagrams larger than 65.535 bytes. IPv6
Jumbograms make use of IPv6 hop-by-hop options and are only
suitable on paths in which every hop and link are capable of
supporting Jumbograms (e.g., within a campus or datacenter). To
date, few implementations exist and there is essentially no
reported experience from usage. Consequently, IPv6 Jumbograms
[RFC2675] remain optional at this time.
(key change is "MAY" to just lower case "optional").
> * 5.9.4 Default Address Selection
> As RFC3484 generates IPv6 brokenness. I think we should change
> this reference to RFC3484bis.
Can't do that. That would delay publication of the RFC.
BTW, you could make the same arguement w.r.t. the Flow Label. And
possibly other things that are still in revision...
> * 5.9.5. Stateful Address Autoconfiguration
> I still disagree with the MAY for DHCP. I don't think we should
> state the 'at the present time SLAAC'.
Note: full quote is:
At the present time, the configuration of stateless address
autoconfiguration is more widely implemented in hosts than
address configuration through DHCP.
This would appear to be statement of fact. (And on rereading it, I
would suggestion changing the sentence to:
At the present time, the configuration of addresses via
stateless autoconfiguration is more widely implemented in hosts
than address configuration via DHCP.
> hosts that cannot do DHCP for address assignment may not be able
> to connect to many cable networks (see DOCSIS 3)
Is this true for *end user* hosts at behind a DOCSYS modem? I believe
not.
> and access networks specified by the BBF.
IMO, the day of having CPE devices support bridging are gone. It is
perfectly fine to require the use of a router rather than allowing end
clients to connect directly. Such routers could be required to
implement DHC. But you can't reasonably expect all client end devices
to support it. We missed the boat on that years ago.
> * 6 DHCP vs. Router Advertisement Options for Host Configuration
> I don't understand the purpose of this section.
It is a bit of history/background.
> it should include text explaining how to handle conflicts between
multiple mechanisms if anything.
The existing specifications already address this. This document has
nothing to add.
> and make it clear that every node has to implement all
> mechanisms. that's the natural consequence of designing multiple
> ways of doing the same thing.
The WG has not been willing to do that. Unless something has changed
recently, I do not see support for elevating DHC support beyond MAY
(for addresses anyway).
> * 8.1. Transition Mechanisms
> Just remove the section. it doesn't add value.
I agree there isn't much there, but for completeness, I think it
should stay.
> * 12.1.1 Router Alert
> not just acknowledge that the HBH option was a bad idea and nuke it?
Not sure what your point is here. HBH options are mandatory to
implement at this time. Way to late to deprecate them. Neighbor
Discovery depends on it (i.e., MLD mandates it, and you need MLD for
ND).
Thomas
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
