On Sun, Feb 12, 2012 at 04:34:40PM -0500, Noel Chiappa wrote:
> From: Nilsson <mansaxel(_at_)besserwisser(_dot_)org>
> 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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf