On 11/14/11 11:52 PM, Nick Hilliard wrote:
On 14/11/2011 21:55, Leo Vegoda wrote:
Where does the /26 come from? Or to put it another way, assuming the basis for allocation policy is justified need, what need is considered so universal that no justification is required?
apparently 6rd. Or the latest transition mechanism, except that it's such a good address justification mechanism that you don't even need to mention which transition mechanism you're planning to use, or even if you are planning to use a transition mechanism at all.
Dear Nick, Yes, exactly. Many "early" adopters knew no better and got their /32 in order to start testing IPv6 and today they would need much more to take advantage of some addressing ways that IPv6 can offer - and we had some of them expressing this thought at RIPE62, RIPE63 and here on list. I know I'm repeating myself, but probably we should try to "unlearn" all the speed-bumps we put into IPv4 addressing policy in order to slow down depletion and start distributing IPv6 space as needed, adapting the defaults to the feedback from operational environment and community.
I'm struggling to understand how this proposal meets the Conservation section of the RIPE IPv6 allocation policy:
"Although IPv6 provides an extremely large pool of address space, address policies should avoid unnecessarily wasteful practices. Requests for address space should be supported by appropriate documentation and stockpiling of unused addresses should be avoided."
I would understand this as "do not give /20 to a LIR with 10 users." Note the word "should", therefore this must be taken just as a guidance, not a must.
It hardly takes much effort to mention to the RIPE NCC that your LIR is applying for a /29 instead of a /32 because it intends to implement 6rd, does it?
Then everybody can mention that they are about to deploy 6RD ;) We thought of this, but this just introduces unnecessary cycle in the process.
While I don't have a major problem with giving 3 extra bits of space to implement 6rd, I do have a major problem with:
1. making this the default configuration, even for those LIRs who have no intention of ever deploying 6rd or any other equivalent transition mechanism,
/29 for legacy allocations is reserved. Some LIRs would lower operational costs if they could use it (as nobody else could use that space). For latest allocations on binary chops, large quantities of space are in between allocations and likely in our lifetime we will not come to less than /24 or /25 in between the allocations. Fail to see the problem giving LIRs more space by default.
2. removal of the requirement to specify 6rd/other mechanism to justify the extra space, and
Yes, removing extra cycle...
3. allocating /26 by default. 102 bits of address space is obscenely wasteful because it is very significantly more than most LIRs will ever require in the lifetime of the universe (yes, I have worked out the scales here).
Agree.
Look, I don't mean to sound like a party pooper, but let's not lose the run of ourselves here. 6rd has very limited deployment at present, and while it shows a lot of promise as a potentially useful transition mechanism, it's not yet at the stage where we should feel tempted to shower LIRs with ridiculous quantities of address bits just because we're feeling a bit inadequate about current ipv6 uptake.
Broadcom revealed that in new chipset for CPE IPv6 and 6RD are HW accelerated. Major vendors are offering 6RD core boxes and many operators are testing them. Let's do that properly, if it's unavoidable. 6RD is not the best mechanism ever invented, but making it more complicated and expensive with multiple-6rd-domains because of lack of IPv6 space makes operational life even more complicated.
I'd like to suggest that 2011-04 be changed so that LIRs can expand their default /32 to a /29 iff they document a requirement for providing 6rd / {another specified ipv6 transition mechanism which requires similar bits of address space} to end-users. Otherwise, a /32 will be assigned by default, and the RIPE NCC can continue on with their current binary chop allocation strategy.
Again, so everybody can write into their request "we'll deploy 6RD". This is not solving anything. Please, start unthinking IPv4... RIPE-NCC can continue with exactly the same binary chop even if 2011-04 gets implemented. Cheers, Jan