Thomas, > 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.
please let me withdraw that comment. off the cuff remark. >> 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? it was the only way we found to keep support for ULA prefixes. the scenario is if you have a home CPE with ULA enabled, but no upstream IPv6 connectivity. if that router advertises itself as a router for default, as opposed to router for ULA, host implementations that don't do 3484bis, and don't handle ICMPs, will contribute to IPv6 breakage. e.g. 75 second time outs per TCP connection. >> * 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"). I'm fine with that. the reason I brought it up is because we have people (aka customers) asking us for support for this. and it has so far in every case been either because of mixing it up with jumbo frames, or not understanding what it is. >> * 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... while it isn't correct to say that rfc3484 contributes to IPv6 breakage, I would very much like a reference to something that actually helps. is it urgent to get the node requirements document out? I thought 3484-revise was quiet far along in the process. chairs? >> * 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. that statement will be true as long as there exists a single host on the planet that doesn't do DHCPv6. assuming they all do SLAAC. ;-) >> 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. yes, it is. a DOCSIS modem is a bridge. with a router it is OK obviously. >> 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. I disagree. the consequence is that hosts that not support DHCP, will just not get service. that's pretty bad, and I think the prudent approach would be to have SLAAC as a MUST and stateful as a SHOULD. after all you have the following text that states: "However, some environments may require the use of DHCP and may not support the configuration of addresses via RAs." that is a pretty severe interoperability problem. I'm happy that 6106 is a SHOULD, but if you are looking for implementations for that option you have to look very hard "at the present time". basically I want the document to say that IETF has standardised two mechanisms to configure hosts. one using ND and one using DHCP. as they apply to different management models, nodes SHOULD implement both. (and add suitable apologies to the world for having messed this up badly. ;-)) >> * 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. I would be happier if it included text stating the above. >> 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. does it in the general case? i.e. that if you get one address from SLAAC and one from DHCPv6 the result is two addresses. same with DNS options and so on. do you have a reference? >> 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). we are making solutions depending on DHCP support: draft-ietf-mif-dhcpv6-route-option draft-ietf-6man-addr-select-opt ... >> * 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. OK. >> * 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). if ipv6->next_header == 0 plonk ? OK, I will not argue the point further. packets with HBH headers will be severely rated limited anyway... cheers, Ole -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
