> What I do hear is that giving out /48 to everyone is simply > profligately wasteful. And unjustified. And repeats the early mistakes > of IPv4 where people didn't think about managing resources prudently. > The people at the RIRs might genuinely feel this way, but I suggest that they're not really in a position to evaluate whether this is wasteful. When making decisions like this, where there's a tradeoff to be made between competing concerns, everybody tends to optimize for the concern(s) with which he is most familiar. Because the RIRs have borne much of the burden of conserving IPv4 addresses, it's hardly surprising that the RIRs would be concerned about the ability to conserve IPv6 addresses. OTOH, I am more sympathetic with the application and user side of things, so I want to preserve flexibility in that area. Assumptions of the form "256 subnets will always be enough" strike me as extremely shortsighted, especially because it implicitly assumes a single level of delegation inside the home. What we should know by now is that the fundamental constraint on use of addresses typically isn't 2**<number of bits available> but rather, the number of levels of delegation. That's why arguments of the form "2**32 addresses will always be enough" didn't turn out to be valid. The argument is no more valid if you substitute a different exponent, unless you evaluate that number in terms of delegation levels. Basically I view the IPv6 address as a variable length address, with an upper limit of 128 bits, and the "unused" bits in the portion between the length of the subnet mask assigned to the customer and the 64 bit boundary. Really a variable length address is what we need, but we have a large fixed length address as a design compromise that gives us addresses at fixed offsets relative to the beginning of the packet. To take away 8 bits of that headroom really does limit the flexibility of what users can do with that address, and is a fundamental change to that design decision. > We shouldn't be surprised that a "one size fits all" approach (where > home users get the same amount of space by default as an IBM or > Microsoft) doesn't seem to make a lot of sense to some people. > No, it shouldn't be surprising. But then again, people who weren't there or aren't engineers themselves rarely understand the nature of the delicate compromises that go into such decisions. We don't do a good job of documenting them either. But this might in part be due to our processes - we have to get rough consensus on the decisions we make, but we don't have to get rough consensus on the reasons for those decisions (or document them). If we burdened ourselves with documenting our decision-making criteria, we might be able to better fend off late second-guessing. But we'd delay our own output even further, and none of us wants to do that. > It should be noted that the policy proposal being quoted here was > submitted even though RFC3177 is on the books. And that some RIRs have > already adopted the change to /56. Maybe what we need is an RFC explaining the reason for /48, or maybe just a note saying that we don't feel like the RIRs are in a position to second-guess IETF design decisions. Seems like that would be a good thing to say in general. Even if this decision is not so bad (and who knows what unintended consequences it will bring in the distant future?), it sets a dangerous precedent for the RIRs to be second-guessing IETF recommendations. > So, no, changing RFC 3177 isn't > (IMO) going to open the door (any wider) to such proposals. > > At the same time the continuing existance of RFC 3177 is not going to > stop RIRs from adopting policies that they think make sense. Leaving > 3177 on the books as it currently stands, strikes me as a form of > denial. It doesn't document existing practice, and at a minimum, we > should acknowledge that. > Pretending that the RIRs decision makes sense, when we had very good reasons for choosing /48, strikes me as a much more severe kind of denial. I cannot say this strongly enough. Our job is not to document existing practice. Our job is to make recommendations as to what we think will work best. Anytime someone in IETF insists that we should align our decision with somebody's notion of "existing practice" independently of whether or not that practice is sound, the suggestion should be immediately considered out of order and ignored. Keith _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf