On 28 Oct 2015, at 13:07, Juliusz Chroboczek <j...@pps.univ-paris-diderot.fr> wrote: > >>> (2) SHOULD RFC 6126, IPv4 subset; > >> Why not MUST? [...] I don't think the prodding should be done by causing >> unnecessary pain for average consumers. > > Fully agreed, but I'm not sure what is the WG's thinking about IPv4. RFC > 7368 (Homenet arch) is conveniently vague about IPv4. My reading is that > the authors of RFC 7368 expected that router vendors will use multiple NAT > for IPv4, and that they will ignore whatever we mandate.
Well, it was simply written as per directed by the WG chairs to not explicitly consider IPv4. The focus was on IPv6 home networking. As it says in the intro: "The architectural constructs in this document are focused on the problems to be solved when introducing IPv6, with an eye towards a better result than what we have today with IPv4, as well as aiming for a more consistent solution that addresses as many of the identified requirements as possible. This document aims to provide the basis and guiding principles for how standard IPv6 mechanisms and addressing [RFC2460] [RFC4291] can be employed in home networking, while coexisting with existing IPv4 mechanisms. In emerging dual- stack home networks, it is vital that introducing IPv6 does not adversely affect IPv4 operation. We assume that the IPv4 network architecture in home networks is what it is and cannot be modified by new recommendations. This document does not discuss how IPv4 home networks provision or deliver support for multiple subnets. It should not be assumed that any future new functionality created with IPv6 in mind will be backward compatible to include IPv4 support. Further, future deployments, or specific subnets within an otherwise dual-stack home network, may be IPv6-only, in which case considerations for IPv4 impact would not apply.” Or in other words, IPv4 is as it is. In practice, many home networks will be dual-stack for some time, so deployments need to consider IPv4. The hipnet work, for example, which was strongly compliant with RFC 7368, included IPv4 delegations within the home net, so avoided multiple NATs. > OTOH, the HNCP draft does (mostly) the right thing wrt. IPv4, so I guess > we could ignore RFC 7368's lack of assertiveness here and say that RFC 6126 > style IPv4 is MUST, except if IPv4 is not supported at all. (I'm not > overly keen on the "MUST implement, SHOULD deploy" style of compromise.) My understanding is that RFC7368 basically leaves you free to do as you will with IPv4. >> It's ok for vendors to ship with IPv4 disabled by default > > That's policy, in my opinion it's HNCP's job, not Babel's. Babel should > run with IPv4 unconditionally enabled, if HNCP chooses to publish an IPv4 > prefix, who is Babel to disagree? > > I guess we're in full agreement here, just looking for the right wording. RFC 7368 does not mandate disabling IPv4, nor does it require IPv4 to be enabled :) Tim > > -- Juliusz > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
