Reply inline
Le 9 oct. 2014 à 13:03, Ole Troan <[email protected]> a écrit : > Pierre, > > I certainly understand your argument, and we don't disagree on the technical > merit. > >> I’m proposing this change then. >> >> 1. In case the provided prefix is 64, the default consist in assigning >> prefixes of length 64 first. >> 2. I’m adding a reference to 6man-why64. >> >> When the algorithm decides to make a new assignment, it first needs >> to specify the desired size of the assigned prefix. Although this >> algorithm intends to remain generic, it was observed in >> [I-D.ietf-6man-why64] that hosts may malfunction when the prefix >> length is not 64. Therefore, prefixes of length 64 are RECOMMENDED. >> The following table MAY be used as default values, where X is the >> length of the delegated prefix. >> >> If X <= 64: Prefix length = 64 > > the "may malfunction" is not the reason for why the IPv6 address is classful, > so please don't put that as justification for a default of 64. I’ll change that into something more generic like: « Because of all the reasons listed in [I-D.ietf-6man-why64], prefixes of length 64 are RECOMMENDED. ». > > I would like this document to say as little as possible about the boundary. > RFC6204 says: > L-2: The IPv6 CE router MUST assign a separate /64 from its > delegated prefix(es) (and ULA prefix if configured to provide > ULA addressing) for each of its LAN interfaces. > > which you could tweak to fit this document as well. have text like that in > one place, and then all other places threat it as an arbitrary length. > > please remove the table with the description of what to do for various values > of X. The algorithm treats IPv4 and IPv6 the same way, as well as any prefix lengths. That table is important for IPv4 support. > I'd be happy with a statement like in RFC6204: > WPD-3: ...If the > delegated prefix is too small to address all of its > interfaces, the IPv6 CE router SHOULD log a system management > error. > >> Processes proposed in the appendix are optional. >> Our implementation supports some part of it, and it works fine in our >> test-cases. >> I’d rather have a /80 than no connectivity at all (And it just works.). >> IMO, why64 is way too pessimistic on the current implementation state and >> even more when it comes to the progress implementations will do in the >> coming years. >> >> And we either do that or let people do NAT66. ;) >> >> >> Is it OK for you Ole ? > > I'd also remove the appendix. > it doesn't make sense to specify something that breaks SLAAC. But you think it makes sense to specify something that breaks the network instead. That is, IMO, a curious tradeoff. > > protocol design is politics. we want to make it clear to the address > delegation authorities that not delegating a large enough address block will > lead to breakage. It’s not only about the size of the prefix. It’s about all the variety of situations we will encounter. Before the first homenet router is shipped, Hipnet-like routers (Those who do PD sub delegation) will be there. Mostly as CPE routers. If the ISP is kind enough to give you a /56, they will probably give you a /60. If the ISP provides a /60, they will provide a /64. The customer will buy a *homenet enabled* router. Put it behind one of these CPEs, and won’t be able to provide a prefix on both wifi and wired networks. That works in ISP—Homenet—SubDelegation—Homenet situations too. And broadband ISPs are not the only kind of uplinks you will have to deal with. - VPN service that provides you with a /64 only - Virtualized networks - Tethering with your phone… They are not going to provide a /56 for that (Or at least not soon enough). - Electrical Company will probably not start giving 56s. - etc… And on top of that, you’ll have all the devices that require /64 prefixes and cut work without it. The algorithm is able to provide them with /64s and deal with smaller prefixes on the rest of the network. Let’s dream about a world where every device will talk Homenet, but waiting for that time, we’ll have to deal with hundreds of devices that behave differently. > > in my view, if we let this principle slide, then the risk isn't that the > delegations are /80s, but that they will be /128s. and you're back to IPv6 > NAT anyhow. > If that really is a valuable argument, we should start breaking IPv4 so that ISPs deploy IPv6 faster. Cheers, - Pierre _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
