Subject: Re: Last Call: <draft-weil-shared-transition-space-request-14.txt> (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP

From: [email-masked] (Noel Chiappa)
Date: Sun, 12 Feb 2012 16:34:40 -0500 (EST)

> From: Nilsson <[email-masked]>

    > 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.

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.

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.

    >> 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.

	Noel

---

From: Måns Nilsson <[email-masked]>
Date: Sun, 12 Feb 2012 23:29:14 +0100

> 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... 
 
> 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)

> doing what you want - nothing else. There is _no_ good engineering reason

How about "there are no addresses left"? 
 
> 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

---

From: Doug Barton <[email-masked]>
Date: Mon, 13 Feb 2012 12:34:17 -0800

> will get it. Multiply than by N providers.

If the RIRs do not deny these requests there is likely to be a revolt.
OTOH that may be a good thing ....

As for your other 2 options:

> But it is. As I said before, the IETF has precisely two choices:
>

Incredibly unlikely to happen. The ISPs are smart enough to know that
this will cause them more headaches than its worth.

> - See CGN deployed using a block of space allocated for that purpose

If the IETF rightly denies this request then the ISPs are going to be
forced to use the proper option, 1918 space. Whatever customer support
costs they have to bear for the small percentage of customers that
actually manage to overlap will rightly be borne by the people who
created their own problems. Everyone wins.

Doug

-- 

	It's always a long day; 86400 doesn't fit into a short.

	Breadth of IT experience, and depth of knowledge in the DNS.
	Yours for the right price.  :)  http://SupersetSolutions.com/

---

From: David Conrad <[email-masked]>
Date: Mon, 13 Feb 2012 12:45:22 -0800

> OTOH that may be a good thing ....

What grounds would an RIR have to deny this request?

> this will cause them more headaches than its worth.

You're joking, right?

> forced to use the proper option, 1918 space.

No.  ISPs will do what makes business sense for them.  Some of these ISPs have already indicated that RFC 1918 won't work for them.  As such, they'll take whatever steps they feel is in their best interests.  Whether this is choosing some large block of (currently) unadvertised space or requesting a large block from their RIR (while they still can) is a decision they will make.

Regards,
-drc

---

From: Doug Barton <[email-masked]>
Date: Mon, 13 Feb 2012 12:57:52 -0800

On 02/13/2012 12:45, David Conrad wrote:
>>> 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.
>> 
>> If the RIRs do not deny these requests there is likely to be a
>> revolt. OTOH that may be a good thing ....
> 

I haven't kept up to date on all of the RIRs' policies for granting
requests, but I don't recall seeing "give me a huge block so that I can
do CGN" as one of the established criteria.

>> Incredibly unlikely to happen. The ISPs are smart enough to know
>> that this will cause them more headaches than its worth.
> 
> You're joking, right?

Ok, let's assume I'm wrong. Then there are 2 options:

1. They squat on space that causes them (and their customers) pain. I'm
fine with that. Hopefully it will encourage their customers to move
away, thus causing more pain for the ISP.
2. They squat on space that doesn't cause pain. I don't like that
option, but it solves the problem, right?

>> If the IETF rightly denies this request then the ISPs are going to
>> be forced to use the proper option, 1918 space.
> 
> No.  ISPs will do what makes business sense for them.  Some of these
> ISPs have already indicated that RFC 1918 won't work for them. 

I've already covered all the reasons I don't buy this in detail.

Doug

--

---

From: Roger Jørgensen <[email-masked]>
Date: Mon, 13 Feb 2012 22:37:08 +0100

On Mon, Feb 13, 2012 at 9:34 PM, Doug Barton <[email-masked]> wrote:
>>     > From: Nilsson <[email-masked]>
>>
>>     > 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.
>>

+1 :-)

I did original think it was the lesser evil to support this draft, but
I have now changed my mind. Plenty of arguments from so many on so
many points that I can't really see any reason anymore to support it.

So, no I don't support this draft.

-- 

Roger Jorgensen           |
[email-masked]          | - IPv6 is The Key!
http://www.jorgensen.no   | [email-masked]