Subject: Re: [Int-area] discussion of the ISP shared address idea

From: Alan DeKok <[email-masked]>
Date: Thu, 31 Jul 2008 18:00:03 +0200

Brian E Carpenter wrote:
> I don't understand why a customer using Net 10 can't be NATted (at the CPE)
> into an ISP using Net 10. Since NATs completely separate two address
> realms, I can't see any reason this would work any differently than
> by inventing Net10bis.

  The same thing happens when companies buy other companies.  The worst
I've seen (so far) is 3 layers of NAT, all using Net 10.  It works, and
it plays hob with equipment trying to have "internal" IP addresses.  But
hacking selected server equipment is usually cheaper than changing
hundreds of switches and thousands of end hosts.

  Alan DeKok.
_______________________________________________
Int-area mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/int-area

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 03 Aug 2008 12:40:53 +1200

>From Shin's answer, it seems that many cheap CPE NATs are broken
in this respect.

However, an ISP that already has a /8 could use it twice in Shin's
scheme, I think, with the CGN between the two instantiations. I don't
see that as more risky than defining a new 'Net 10'. In either case,
leakage has to be prevented by configuration, but in the case I suggest,
the ISP causing a leakage would be the only one to suffer.

   Brian

    Brian

---

From: Jari Arkko <[email-masked]>
Date: Sun, 03 Aug 2008 09:57:58 +0300

Shin is saying that current CPE equipment does not handle this right. 
Can we get some actual data on this? E.g., most devices do not do it, 
some particular vendor's don't do it, N/M tested devices do not do it, etc.

Jari

---

From: Shin Miyakawa <[email-masked]>
Date: Mon, 04 Aug 2008 11:09:34 +0900 (JST)

As far as we know, Linksys can not do this and Even Cisco IOS can not assign 
same address range for different interfaces. 
So I still can not understand why it should be said as "BROKEN".

But anyway.......

Brian, please explain, where does a packet from PC1 for 10.0.0.12 go 
in the following settings ? PC3 ? or CGN ?

[PC1]-----------+
10.0.0.10       |
                |
[PC2]-----------+-----------[NAT]--------------------------[CGN]----------------
10.0.0.11       |  10.0.0.1       10.0.0.20       10.0.0.12      Global Address
                |
[PC3]-----------+
10.0.0.12

I still can not understand why this can work well...

Best regards,

Shin Miyakawa

---

From: Shin Miyakawa <[email-masked]>
Date: Mon, 04 Aug 2008 11:17:43 +0900 (JST)

oops. Let me correct.
Our Linksys box can assign same address for WAN and LAN interfaces. 
But anyway ... Still I am wondering what's happening in this case...

Shin

---

From: "Gregory M. Lebovitz" <[email-masked]>
Date: Sun, 03 Aug 2008 22:25:23 -0700

> > in the following settings ? PC3 ? or CGN ?

Shin,
Assuming
  -that I've understood your question, and
  -that PC1, 2, & 3 are all in the same subnet...

Unless I am missing something, according to basic host processing, a 
packet from PC1 to 10.0.0.12 will be sent directly to PC3 by PC1. The 
host processing should look like this:
  - PC1 IP stack receives datagram from upper layer, destined for 10.0.0.12
  - DST IP in same subnet as local interface
  - check local MAC learning table for entry associated with 10.0.0.12.
     - If entry, then create frame for that MAC and send frame on segment.
     - If no entry, then ARP for 10.0.0.12. Upon receiving MAC 
response, create frame for that MAC and send frame on segment.

Did I understand your question?

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 05 Aug 2008 14:48:41 +1200

On 2008-08-04 17:25, Gregory M. Lebovitz wrote:
>     - If no entry, then ARP for 10.0.0.12. Upon receiving MAC response,
> create frame for that MAC and send frame on segment.

Exactly. Perhaps another way to look at it, remembering that RFC 1918
introduced ambiguous address spaces that can *only* be distinguished
by context, is to label the contexts:

   ADDRESS CONTEXT A          :   ADDRESS CONTEXT B          : ADDRESS CONTEXT C
                              :                              :
[PC1]-----------+             :                              :
10.0.0.10A      |             :                              :
                |             :                              :
[PC2]-----------+-----------[NAT]--------------------------[CGN]----------------
10.0.0.11A      |  10.0.0.1A  :   10.0.0.20B      10.0.0.12B :   Global Address
                |             :                              :
[PC3]-----------+             :                              :
10.0.0.12A                    :                              :

A NAT that doesn't treat the two address contexts as logically
disjoint is broken IMHO. Of course, 10.0.0.12B (like every
address in Context B) is totally inaccessible from Context A.
But the Context B side of the CPE NAT will use 10.0.0.12B
as its default router.

It's certainly horrible, but when you run out of addresses,
what else can you expect?

    Brian

---

From: Shin Miyakawa <[email-masked]>
Date: Tue, 05 Aug 2008 12:52:52 +0900 (JST)

First of all, thank you very much Gregory and Brian for your good clarifications.

From: Brian E Carpenter <[email-masked]>
Subject: Re: [Int-area] discussion of the ISP shared address idea
Date: Tue, 05 Aug 2008 14:48:41 +1200

> But the Context B side of the CPE NAT will use 10.0.0.12B

Yep. That's what I'd like to say exactly. 

> what else can you expect?

Yes, this is certainly horrible. That's also what I'd like to repeat too.

So, That's the reason why we should have another address space 
to be shared by ISPs which are going to introduce CGN in their networks 
to ease the pain.

Otherwise, every ISP may be going to RIR to get another space for each for this purpose
(simply because they can not remove global Pv4 assignment off from exisiting customers),
and IPv4 is running out very quickly in this case.

As one of strong IPv6 promotors on the Earth, maybe I should push this 
way to complete IPv4 address assignment as soon as possible, 
but, still we need to gain some period to let vendors complete CGN implementation.

Best regards,

Shin Miyakawa