[arin-ppml] [Fwd: Draft Policy 2011-5: Shared Transition Space for IPv4 Address Extension]

[Owen DeLong]

On Feb 22, 2011, at 3:19 PM, George, Wes E [NTK] wrote:

> -----Original Message-----
> From: Owen DeLong [mailto:owen at delong.com] 
> Sent: Tuesday, February 22, 2011 1:13 PM
> Subject: Re: [arin-ppml] [Fwd: Draft Policy 2011-5: Shared Transition Space for IPv4 Address
> Extension]
> 
>> Their 40 parallel RFC-1918 addressing domains are all under their control and can easily be
> coordinated by VZW.
> 
>> You're option 4 expands that to 100 million parallel addressing domains not managed by VZW + 40
> that are + some additional >number that are, but, by definition likely overlap the existing 40.
> 
> [WEG] Owen, this statement is mostly FUD, and I'll thank you to stop confusing the issue. 
> The original problem was "we don't want to use 1918 for outside CPE NAT interface because we're
> worried that it'll conflict with the address space assigned on the inside NAT by default". Somehow
> that has now morphed into 100 million parallel addressing domains and a concern about overlap
> between them because they're not all managed by the same entity. So now it's my turn to say, "Huh?"

He was positing that because VZW is able to maintain 40 parallel instances of 1918 space under
their control that it was the same problem as maintaining a CGN Intermediary address space
that overlapped the customer address spaces.

My statement wasn't FUD, it was taking his example to its logical conclusion when scaled to
the environment HE described. He is the one that came up with 100 million subscribers
as a number for the environment. He is the one that stated parallel instances of RFC-1918
were OK in the situation. I merely pointed out the difference between what he was saying
and what he was proposing as a viable solution.

> You're right that it's not a perfect justification for expecting to use 1918 space in a NAT without
> conflicting with CPE default config, because this CPE is centrally managed by the ISP, but that has
> nothing to do with how many places it is being used. 

Again, I was using his numbers to counter his example. If there's FUD here, it's his.

> It actually provides an excellent proof that RFC 1918 can be used in a Carrier NAT without
> conflicting with other networks' NAT and internal use of RFC1918 space, because it's not possible to
> route directly from your internal address behind $ISP's CGN to another company's internal address
> behind their NAT without traversing the externally routed public IPs between destinations, meaning
> that each sees a unique address that doesn't conflict.
> 
Let me try to explain the problem you seem to be missing here...

First, you have the following network zones: {A}, {B}, and {C}. {A} is the public internet with
globally unique addressing. {B} is the NAT444 intermediary zone that would be addressed
with the proposed numbers. {C} is the networks behind each customer's NAT.

If addresses conflict between {B} and {C}, the consumer's NAT box may send traffic
destined to its default gateway in zone {B} back into zone {C} because it may see
the gateway address as being within zone {C}. This would have the effect of taking
the user effectively off of the internet and moving them, instead, to the providers
support queue. Worse, it will be the telephone support queue because their unable
to reach their internet self-service options to resolve the problem.

> Address collision between NAT domains within a company that is repeatedly using the same block of
> addresses is a problem regardless of if you use 1918 or an ARIN-designated /10, assuming you need
> more than a /10 of addresses, so I don't see that as a valid justification for ignoring 1918 as a
> possible solution.
> 
Nobody is ignoring 1918 as a possible solution. They are considering the scale of the
difficulties created by specific types of colliding address ranges and realizing that
the scope of the problem exceeds practicability if the coordination of the intermediary
addressing has to include coordination with their customers LAN side addressing.

If you have separate intermediary zones that contain the same sets of NAT addresses
and don't talk directly to each other, that's not a problem. The problem occurs when
you have address collisions on opposite sides of the same NAT box without an
additional NAT in between. This would be the case encountered by large providers
deploying LSN using RFC-1918 to number the intermediary zone between the Consumer
and Carrier NATs.

> The point of contention that remains is exactly how much of a problem managing some minority of CPE
> devices that are configured to use the "wrong" portion of 1918 and have to be reconfigured (or
> better still, replaced with something that supports IPv6) to prevent that conflict. I maintain that
> CGN is going to cause enough support calls that it's overly simplistic to assume that just because
> you're not using 1918 it'll be orders of magnitude easier. But without real evidence, it's just one
> set of conjecture against another, and we're really not getting anywhere.
> 
No question that CGN will raise the support call level. That increase is acceptable
because the alternative is the even larger increase created by turning off IPv4
support altogether for at least some fraction of customers.

Nonetheless, that call volume is independent of and cumulative to the call volume
created by colliding address spaces. I would anticipate that you would be hard
pressed to find a sufficiently large RFC-1918 range to be practical (since your
choices in many cases are limited to 10.0/10, 10.4/10, 10.8/10, and 10.12/10)
that will not conflict with at least 1% of the subscriber configurations.

Yes, this is conjecture, but, given my experience dealing with various SOHO
and SMB configurations over the years, I think it's pretty reasonable conjecture.

Owen