Subject: Re: [v6ops] [OPSAWG] comments on draft-weil-shared-transition-space-request-07

From: Tina TSOU <[email-masked]>
Date: Tue, 11 Oct 2011 00:10:54 +0000

Bill,
One reply from my co-author Qiong SUN from China Telecom “Well, I think this is a common problem for VPN support in address sharing environment, even for existing home network where customers have their own NAT with private IPv4 address. Since nowadays, customers would usually use 192.168/16 address space, most VPN operators have already made use of 10/8 address space to avoid address confliction. I think this model can still be followed in our approach.”

Best Regards,
Tina TSOU
http://tinatsou.weebly.com/contact.html

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of William Herrin
Sent: Wednesday, October 05, 2011 3:19 PM
To: Tina TSOU
Cc: [email-masked]
Subject: Re: [OPSAWG] comments on draft-weil-shared-transition-space-request-07
On Wed, Oct 5, 2011 at 1:46 PM, Tina TSOU <[email-masked]> wrote:
> Bill,
> Good question.
> Would you show us a picture for precise understanding of this use case?
http://bill.herrin.us/network/cgn-example.gif
Regards,
Bill Herrin
--
William D. Herrin ................ [email-masked]  [email-masked]
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of William Herrin
Sent: Wednesday, October 05, 2011 10:04 AM
To: Tina TSOU
Cc: [email-masked]
Subject: Re: [OPSAWG] comments on draft-weil-shared-transition-space-request-07
On Tue, Oct 4, 2011 at 9:21 PM, Tina TSOU <[email-masked]> wrote:
> In some cases, if we use
> https://datatracker.ietf.org/doc/draft-tsou-pcp-natcoord/
> https://datatracker.ietf.org/doc/draft-zhou-softwire-b4-nat/
> https://datatracker.ietf.org/doc/draft-cui-softwire-b4-translated-ds-lite/
>
> draft-weil-shared-transition-space-request-07 seems not absolutely necessary.
Hi Tina,
Thanks for the references!
One common residential Internet use case where the reuse of RFC1918
for CGNs may fail without recourse is this:
1. Home user on CGN using RFC1918 space
2. Establishes VPN to workplace
3. Workplace uses RFC1918 inside its network overlapping the CGN IP
address assignment.
For example, Home User is assigned 10.1.2.3 with a gateway of
10.1.2.1. Establishes VPN from 10.1.2.3 to 192.51.100.1 (10.1.2.3
translated to 203.0.113.4 by the CGN). VPN client assigns 192.168.1.55
and reroutes the default through the VPN. Home user then attempts to
connect to the company Intranet server at 10.1.2.3. This collides with
the 10.1.2.3 assignment on the local ethernet interface.
How does the equipment in the referenced drafts react in that scenario?
Regards,
Bill Herrin
--
William D. Herrin ................ [email-masked]  [email-masked]
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004

---

From: Joel jaeggli <[email-masked]>
Date: Mon, 10 Oct 2011 22:07:22 -0700

On 10/10/11 17:10 , Tina TSOU wrote:
> Bill,
> 
> One reply from my co-author Qiong SUN from China Telecom “Well, I think
> this is a common problem for VPN support in address sharing environment,
> even for existing home network where customers have their own NAT with
> private IPv4 address. Since nowadays, customers would usually use
> 192.168/16 address space, most VPN operators have already made use of
> 10/8 address space to avoid address confliction. I think this model can
> still be followed in our approach.”

 generally doesn't matter if you have routes inside your vpn that
conflict with your upstream providers blanket use of space so long as
your default route isn't one of the conflicts and or it's short enough
to win.

if this weren't the case mobile vpn clients (which are legion) would
never work on 3/4/g networks.

verizon example:

Zorch:~ jjaeggli$ netstat -rn |grep en2
default            10.183.226.129     UGSc          559        0     en2
10.183.226.128/29  link#11            UCS             0        0     en2
10.183.226.129     4c:47:45:56:44:58  UHLS          561       18     en2
169.254            link#11            UCS             0        0     en2
default                                 fe80::16:c39c:1540%en2
UGSc            en2
fe80::%en2/64                           link#11
UC              en2
fe80::16:c39c:1540%en2                  0:1:83:aa:bb:cc
UHLW            en2
fe80::6699:5dff:fefd:b2d4%en2           64:99:5d:fd:b2:d4
UHL             lo0
ff02::/32                               link#11
UmC             en2

> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Tina TSOU <[email-masked]>
Date: Tue, 11 Oct 2011 17:32:26 +0000

Bill,
As the figure shows, my personal opinion is that if the user allocated private address is 192.168.0/24, the user can not access 192.168.0/24 in the VPN network 192.168/16.

Unless, user allocated private address and network segment do not overlap with VPN’s address segment.
Now for private address, there is only RFC1918 to comply, so two of them overlapping are possible.

Draft-weil-shared-transition-space-request-07 arranges one address segment to all the users behind CGN, to assure the network segment of VPN will not overlap with users’ address, so it solves the problem.

And the 3 reference drafts, do not set users’ private address, and let CPE to allocate. If it can set, the solution is to set a segment not overlapping with the address of RFC 1918, which same as draft-weil.

From this sense, the 3 reference drafts and draft-weil are complementary to each other.

[http://www.nimlabs.org/~nim/orig.png]

Best Regards,
Tina TSOU

From: Tina TSOU
Sent: Monday, October 10, 2011 5:11 PM
To: [email-masked]'
Cc: 'sunqiong'; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [OPSAWG] comments on draft-weil-shared-transition-space-request-07

Bill,

Best Regards,
Tina TSOU

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of William Herrin
Sent: Wednesday, October 05, 2011 10:04 AM
To: Tina TSOU
Cc: [email-masked]
Subject: Re: [OPSAWG] comments on draft-weil-shared-transition-space-request-07
Hi Tina,