On Sun, Feb 12, 2012 at 04:34:40PM -0500, Noel Chiappa wrote: > > From: Nilsson <mansaxel@xxxxxxxxxxxxxxxx> > > > there _is_ a cost, the cost of not being able to allocate unique > > address space when there is a more legitimate need than the proposed > > wasting of an entire /10 to please those who did not do the right > > thing. > > On the contrary, denying this block is likely to _accelerate_ usage of > what space remains, thereby penalizing the 'other users' whose interests > you _claim_ to be protecting. What happened to - See CGN deployed using various hacks (e.g. squatting on space) - See CGN deployed using a block of space allocated for that purpose ...that were the ONLY two choices we have? Suddenly, you introduce a third. Maybe there is more to this... > If an ISP can't use a shared block, they'll go ask their RIR for a block - > and given that they demonstrably have the need (lots of customers), they > will get it. Multiply than by N providers. Not any more. Let me quote from RIPE-530, the in-force allocation policy document for RIPE NCC: Allocations for LIRs from the last /8 On application for IPv4 resources LIRs will receive IPv4 addresses according to the following: LIRs may only receive one allocation from this /8. The size of the allocation made under this policy will be exactly one /22. LIRs receive only one /22, even if their needs justify a larger allocation. LIRs may apply for and receive this allocation once they meet the criteria to receive IPv4 address space according to the allocation policy in effect in the RIPE NCC service region at the time of application. Allocations will only be made to LIRs if they have already received an IPv6 allocation from an upstream LIR or the RIPE NCC. RIPE-530, section 5.6 (as copied from http://www.ripe.net/ripe/docs/ripe-530) > Again, denying this block is just an attempt to punish ISPs who aren't > doing what you want - nothing else. There is _no_ good engineering reason > to deny this request. How about "there are no addresses left"? > >> Allocate, or don't allocate. That's the only choice. > > > This sounds like a bullying ultimatum. > > Not intended to be; I am not a provider, and have no connection to any > provider. This is just my take on what the reality of the situation is. > > > The choice is and was between "do CGN using RFC1918" and "build a > > network that takes advantage of the latest 15 years of developement > > in networking". > > Don't you think any network that was going to do the second would have > already decided that? The ones who are going to do CGN are going to do CGN > - the only question is what block of address space they are going to use. > Denying them a block is not going to stop CGN. ...which means that the allocation is unecessary ;-) Seriously, Doug Barton pointed out (and I agree) that 99% of the issues with RFC1918 space usage in CGN will be dealt with by using a suitably obscure part of 10/8 or simply 172.16/12. FWIW, most of Asia has been running with layers of NAT for years. Using 1918. Which stinks. That is why we have IPv6. I fully appreciate the need for some legacy connectivity; even though this email conversation is made (from my point of view) fully using IPv6, there are lots of other things needing v4. Running v4 services in NAT and dual-stacking with global scope v6 will give a good incitament to migrate important and E2E-sensitive applications to v6, while preserving some kind of pseudo-reachability for v4 services. -- Måns _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf