Subject: Re: Consensus Call: draft-weil-shared-transition-space-request

From: [email-masked] (Noel Chiappa)
Date: Sat, 3 Dec 2011 20:36:40 -0500 (EST)

> From: Doug Barton <[email-masked]>

    > This argument has been raised before, but IMO the value is exactly
    > zero. The fact that you have a finger to wag at someone doesn't make
    > the costs of dealing with the conflict any smaller.

Perhaps. But I don't know the ISPs' business as well as they do. So I'd like
to hear their views on this point. (They may well have considered this point
before deciding to ask for CGN space, and decided the space was still enough
use to be worth it.)

	Noel

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 3 Dec 2011 20:54:19 -0500

Almost all residential customers will use a standard home router; as long as that home router does not make the new space available to customers, it will not be used. Almost all residential users get their home NAT box either from the ISP (who obviously won't ship such a box) or from one of a handful of retail consumer equipment vendors, who won't suddenly switch from RFC 1918 addresses, either (because they don't want to get the support calls).

I don't think your consumer ISP will have much sympathy if you call them up and tell them that you decided to use 128.59.x.x internally, reconfigured the gateway and can no longer get to Columbia University.

This is an economics issue: If one big corporate customer with a too-creative sysadmin calls up after "finding" this new address space, this can be dealt with.  (Indeed, that large corporate customer probably has non-1918 outward-facing addresses to begin with and will keep them, so they are the least likely target of CGNs.) If 10,000 consumer customers call up because their Intertubes aren't working, the ISP has a problem.

Thus, I'm having a hard time believing in the theory that the new space will be immediately appropriated for consumer ISPs. By whom, exactly, and on what scale and with what motivation?

Henning

On Dec 3, 2011, at 8:36 PM, Noel Chiappa wrote:

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

---

From: Doug Barton <[email-masked]>
Date: Sat, 03 Dec 2011 18:13:13 -0800

On 12/3/2011 5:54 PM, Henning Schulzrinne wrote:
> Almost all residential customers will use a standard home router; as
> long as that home router does not make the new space available to
> customers, it will not be used. Almost all residential users get
> their home NAT box either from the ISP (who obviously won't ship such
> a box) or from one of a handful of retail consumer equipment vendors,
> who won't suddenly switch from RFC 1918 addresses, either (because
> they don't want to get the support calls).

I think you're right about that, however it's also true that almost all
of those devices use 192.168.[01]/24. So for that market you can easily
avoid the problem on the CGN side by using a different 1918 block.

> I don't think your consumer ISP will have much sympathy if you call
> them up and tell them that you decided to use 128.59.x.x internally,
> reconfigured the gateway and can no longer get to Columbia
> University.

Apples and cumquats. "Hijacking space that is allocated on the public
Internet" is an entirely different situation than "Using space that's
not supposed to be public for a different purpose than it was intended
for." Yes, I realize that both are technically "wrong" in the sense that
they are against the rules, but I can easily predict the arguments of
the sysadmin responsible for the latter ... "We never thought we'd be
behind a CGN, so we figured it was Ok to do it." "Our old provider
didn't use that range for CGN, so we thought it would be Ok if we did." Etc.

> This is an economics issue: If one big corporate customer with a
> too-creative sysadmin calls up after "finding" this new address
> space, this can be dealt with.  (Indeed, that large corporate
> customer probably has non-1918 outward-facing addresses to begin with
> and will keep them, so they are the least likely target of CGNs.) If
> 10,000 consumer customers call up because their Intertubes aren't
> working, the ISP has a problem.
> 
> Thus, I'm having a hard time believing in the theory that the new
> space will be immediately appropriated for consumer ISPs. By whom,
> exactly, and on what scale and with what motivation?

Actually I think your analysis is 100% accurate, it's just your
conclusions that are faulty. :)  This is a 90/10 problem. 90% of the
problem can be addressed by simply using a 1918 block that is not one of
192.168.[01]/24. (Where 90% is a WAG of course, but you get the idea.)
However, the enterprises that are the most likely to have exhausted, or
nearly exhausted 1918 space already are, for that exact reason, the same
ones who are most likely to (mis-)appropriate the new space for their
own 1918'ish needs.

So the vast majority of the problem can be solved easily with 1918
space. The rest of the problem is incredibly likely to cause pain no
matter what block is chosen for CGN space. So, there's no point to doing
the allocation.

Doug

-- 

		"We could put the whole Internet into a book."
		"Too practical."

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

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 3 Dec 2011 21:28:21 -0500

The same thought occurred to me.  A very large enterprise will not utilize this /10 on a whim; they'd talk to their ISP first.  A consumer is unlikely to modify the settings of their home router, except if they download malware that does it for them :) and a consumer router vendor has such a low margin that the last thing they want is to utilize this forbidden /10, generating thousands of tech support calls they can't afford to answer.

---

From: Victor Kuarsingh <[email-masked]>
Date: Sat, 03 Dec 2011 23:25:42 -0500

Noel,

Opinion from an operator.  There is a difference, and the reality is that
the space is unlikely to be used by enterprises and consumers.

Here is the difference.  RFC1918 has been out (defined) for a long time,
so it's well know by operators, enterprise folks and some consumers.
There is a possibility that some "smart" netadmins may try and use the
space, but nothing stops them form squatting on non-RFC1918 today anyway
(and dealing with any conflicts that arise).

There is a big difference if a consumer and an ISP has a conflict because
both are [validly] using the same RFC1918 space vs. if a Consumer and an
ISP conflict using special assigned space.

Regards,

Victor K

---

From: "C. M. Heard" <[email-masked]>
Date: Sat, 3 Dec 2011 20:42:41 -0800 (PST)

I've followed the discussion, both on the OPSAWG list and on the 
IETF list, and I have to say that I agree with the comments below by 
Henning Schulzrinne and Bernard Aboba.

One question, though, that I wish to address to the authors of 
draft-weil-shared-transition-space-request and perhaps others: why 
would not an allocation from 240/4 (the former Class E address 
space) work for CGN space?  I'm well aware that it would be very 
difficult to use this as ordinary IPv4 address space because of the 
long history of treating it as a "Martian" address range.  It seems 
to me, however, that this would NOT be an issue for CGN boxes -- 
those being new equipment, the software can be upgraded to treat 
this address range differently than it traditionally has been.  It 
would be more difficult for CPE equipment to use -- especially stuff 
that's already deployed -- but that's actually an ADVANTAGE since 
such devices are not supposed to use CGN space.  And an allocation 
from 240/4 would not use up scarce global IPv4 space, which is one 
of the main objections I've been hearing to this allocation.

So ... to the authors of draft-weil-shared-transition-space-request 
and other advocates of this allocation : please tell us whether an 
allocation from 240/4 would work for CGN space, and if not, why not.

To the IESG: please require the authors and/or other advocates of 
the propsed allocation to answer the above question before approving 
the allocation request.  If they agree that it will do, approve an 
allocation from that space.  If they provide a cogent argument as to 
why 240/4 won't work, then I advise (reluctantly) approving the 
allocation from the remaining IPv4 global space.

Thanks for listening.

//cmh

On Sat, 3 Dec 2011, Bernard Aboba wrote:
> The same thought occurred to me.  A very large enterprise will not 
> utilize this /10 on a whim; they'd talk to their ISP first.  A 
> consumer is unlikely to modify the settings of their home router, 
> except if they download malware that does it for them :) and a 
> consumer router vendor has such a low margin that the last thing 
> they want is to utilize this forbidden /10, generating thousands 
> of tech support calls they can't afford to answer.
> 
> 
> > Almost all residential customers will use a standard home 
> > router; as long as that home router does not make the new space 
> > available to customers, it will not be used. Almost all 
> > residential users get their home NAT box either from the ISP 
> > (who obviously won't ship such a box) or from one of a handful 
> > of retail consumer equipment vendors, who won't suddenly switch 
> > from RFC 1918 addresses, either (because they don't want to get 
> > the support calls).
> > 
> > I don't think your consumer ISP will have much sympathy if you 
> > call them up and tell them that you decided to use 128.59.x.x 
> > internally, reconfigured the gateway and can no longer get to 
> > Columbia University.
> > 
> > customer probably has non-1918 outward-facing addresses to begin 
> > with and will keep them, so they are the least likely target of 
> > CGNs.) If 10,000 consumer customers call up because their 
> > Intertubes aren't working, the ISP has a problem.
> > 
> > Thus, I'm having a hard time believing in the theory that the 
> > new space will be immediately appropriated for consumer ISPs. By 
> > whom, exactly, and on what scale and with what motivation?
> > 
> > Henning
> >

---

From: Victor Kuarsingh <[email-masked]>
Date: Sat, 03 Dec 2011 23:50:17 -0500

CM

>of the main objections I've been hearing to this allocation.

It may be possible to use 240/4 on the CGN box (code upgrade), but the
CPEs would have a problem.  These CPEs are a key part of the problem. The
space would need to work with what's in the field.  The CGN space would be
assigned the the CGN zone which may be configured on the internal
interface of the CGN box, but would absolutely be configured on the CPE
WAN interface. Numbering tens of CGN boxes is not the issue, numbering
thousands to millions of CPEs is.

240/4 would require firmware upgrades to many (if not all) CPEs, of which
many are not under the control of the operator (home user bought and
controlled).  It is not feasible to upgrade the entire CPE base.

This is one of the key issues with 240/4.

Regards,

Victor K

---

From: Mark Andrews <[email-masked]>
Date: Sun, 04 Dec 2011 17:17:17 +1100

In message <[email-masked]>, "C. M. Heard
> of the main objections I've been hearing to this allocation.

The CGN boxes are new.  The customer boxes which are being allocated
the addresses are old.   Lots of these boxes will not work with a
240/4 address.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Hadriel Kaplan <[email-masked]>
Date: Sun, 4 Dec 2011 15:04:56 +0000

I have a question to the authors and ISPs as well, which may help explain why using RFC 1918 and Class-E address space can't be done; or it may not if the answer is different.

The question: could this new address space be used *without* a NATing CPE being provided by the ISP?  In other words, could an ISP using CGNs deploy this new address space such that the address is used all the way to the consumer's interface, and the consumer can either buy a home NAT box or even not do so?  An example would be a 3GPP/LTE provider could use this space all the way to the mobile-phone/laptop-3G-card, or a broadband cable/DSL provider could use this space through their cable-modem/DSL-modem and the customer in the home would get one or more addresses from the space in DHCP (and they could buy a home NAT or not do so).

It seems to me that is possible - cable-modems/dsl-modems today don't normally NAT afaik, and there's no consumer CPE in-between in 3GPP/LTE cases. (and 3GPP/LTE is where most of the address growth is)

If that's a legit use-case, then no RFC 1918 address space nor 240/Class-E space could possibly be used.  The reason for that is the address goes to a device the ISP is not in control of, and cannot reasonably mandate changes to.  ISPs can't mandate all consumer NATs purchased in retail stores change overnight, nor can they mandate all consumers use home NATs, nor can they expect all consumer laptops/3g-phones change.

For RFC 1918 space, the problem with picking it isn't so much that the ISP can't pick one that consumer NATs don't use - it's that they can't pick one that no Enterprise on a *different* ISP uses.  For example, assume my employer used 10.64.0.0/10 (they probably do somewhere), and connected to ISP-A.  I connect to ISP-B using a 3GPP laptop-card, and get the same 10.64.0.0/10 address space.  I now cannot use a VPN to my employer, because of the resulting conflict in the routing table in my laptop.  But there's nothing I nor my *ISP-B* can do about this, because my employer has been using that address for a long time (legitimately) and is connected to *ISP-A*. 

-hadriel

---

From: Victor Kuarsingh <[email-masked]>
Date: Sun, 04 Dec 2011 10:27:46 -0500

Hadreil,

I will try and summarize the information in response to your query as best
as possible.  I have left your your text below (for future readers), and
will discuss address assignment behaviours in both Mobile (3GPP) and
Wireline (Cable).  I will let someone discuss DSL (which will have similar
options).  I note mobile/cable since this is what I operate now (by virtue
of my employer which I am not speaking on behalf of).

Mobile:  There are two general addressing usage cases that we see here.
Although they type of device is relevant here, I will try and not go down
too many rat holes.  I will also stick to IPv4 for now (IPv6 differs a bit
more).

The first case is where the IP address is assigned directly to the UE
(User Equipment) which has the end user's applications running with direct
access to the IP assigned.  This is normally the case with Smartphones and
computing devices with an Aircard. In this case, the stack would need to
support the address space and any upstream application (NO NAT).  In this
case, the UE/apps would see and utilize the CGN zone IPs.

The second case where the IP address is assigned to a network facing
interface (still a mobile interface) but the computing devices which have
the applications are behind a NAT and are normally assigned RFC-1918
space.  This is commonly the case with a Smartphone which is not tethering
(sharing it's radio connection) and mobile Gateway way devices.

Wireline (Cable):  There are also two general use cases here.

The first case is where only a modem (CM) is used to terminate the
"Home/Customer" connection with not router or gateway in the middle.  IN
this case, the customers' computer (normally the case here) would acquire
the IP from the ISP.  In the case of CGN, it would get the CGN zone IP.
The modem in this case is effectively bridging the connection (it's not
actually bridging and there are a lot of DOCSIS characteristics involved,
but from an IP service perspective this is what it looks like to the end
station).

The second case is where a home gateway is use (or router).  In this case,
the home network is normally RFC1918 (of some flavour) and the WAN facing
interface of the gateway(router) receives the ISP IP (so in our case if
CGN, the CGN zone IP).

In General:  So in general, it should be noted (as you brought up), that
the CGN zone IP range (whatever it is) is assigned to both gateways which
will NAT and directly to end stations which represent the client's
computing device and applications.

Does this help?

Regards,

Victor K

>
>I have a question to the authors and ISPs as well, which may help explain
>why using RFC 1918 and Class-E address space can't be done; or it may not
>if the answer is different.
>
>The question: could this new address space be used *without* a NATing CPE
>being provided by the ISP?  In other words, could an ISP using CGNs
>deploy this new address space such that the address is used all the way
>to the consumer's interface, and the consumer can either buy a home NAT
>box or even not do so?  An example would be a 3GPP/LTE provider could use
>this space all the way to the mobile-phone/laptop-3G-card, or a broadband
>cable/DSL provider could use this space through their
>cable-modem/DSL-modem and the customer in the home would get one or more
>addresses from the space in DHCP (and they could buy a home NAT or not do
>so).
>
>It seems to me that is possible - cable-modems/dsl-modems today don't
>normally NAT afaik, and there's no consumer CPE in-between in 3GPP/LTE
>cases. (and 3GPP/LTE is where most of the address growth is)
>
>If that's a legit use-case, then no RFC 1918 address space nor
>240/Class-E space could possibly be used.  The reason for that is the
>address goes to a device the ISP is not in control of, and cannot
>reasonably mandate changes to.  ISPs can't mandate all consumer NATs
>purchased in retail stores change overnight, nor can they mandate all
>consumers use home NATs, nor can they expect all consumer
>laptops/3g-phones change.
>
>For RFC 1918 space, the problem with picking it isn't so much that the
>ISP can't pick one that consumer NATs don't use - it's that they can't
>pick one that no Enterprise on a *different* ISP uses.  For example,
>assume my employer used 10.64.0.0/10 (they probably do somewhere), and
>connected to ISP-A.  I connect to ISP-B using a 3GPP laptop-card, and get
>the same 10.64.0.0/10 address space.  I now cannot use a VPN to my
>employer, because of the resulting conflict in the routing table in my
>laptop.  But there's nothing I nor my *ISP-B* can do about this, because
>my employer has been using that address for a long time (legitimately)
>and is connected to *ISP-A*.
>
>-hadriel
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Sun, 4 Dec 2011 16:48:39 +0000

Hi Victor,
Yes that helps, thanks - it confirms what I had always assumed was the case but could not grok from the discussions on this list nor the draft.

Because the new address space is actually seen/used by the consumer's interface, we cannot possibly pick a "safe" RFC 1918 address nor 240/experimental space, for the reasons I stated in my email.  We *have* to allocate a new space.

Furthermore, I would suggest the draft include the following in section 4:
"Administrative entities other than Service Providers MUST NOT use the IPv4 address space reserved for this use.  An example of why this would be a problem is if an Enterprise's internal private network used this address space and the Enterprise someday wanted to provide remote employees with VPN access to the private network, then any employees connected to any Service Provider anywhere using the same address space would not be able to VPN in to the local Enterprise because of the resulting overlap in their local device's routing table."

-hadriel

---

From: Joel jaeggli <[email-masked]>
Date: Sun, 04 Dec 2011 10:39:55 -0800

On 12/4/11 08:48 , Hadriel Kaplan wrote:
> Hi Victor, Yes that helps, thanks - it confirms what I had always
> assumed was the case but could not grok from the discussions on this
> list nor the draft.
> 
> Because the new address space is actually seen/used by the consumer's
> interface, we cannot possibly pick a "safe" RFC 1918 address nor
> 240/experimental space, for the reasons I stated in my email.  We
> *have* to allocate a new space.

It's an absurdity that the clearly impossible is in fact the defacto
deployment model.

this is a verizon 4g card...

en3: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1428
	ether 64:99:5d:fd:b2:d4
	inet6 fe80::6699:5dff:fefd:b2d4%en3 prefixlen 64 scopeid 0xc
	inet6 2600:1010:b005:c97d:6699:5dff:fefd:b2d4 prefixlen 64 autoconf
	inet6 2600:1010:b005:c97d:b963:23e7:3ae1:e287 prefixlen 64 autoconf
temporary
	inet 10.170.127.207 netmask 0xffffffe0 broadcast 10.170.127.223
	media: autoselect (1000baseT <full-duplex>)
	status: active

10.170.127.192/27  link#12            UCS             2        0     en3
10.170.127.193     4c:47:45:56:44:58  UHLWIi        422       34     en3
  1197
10.170.127.207     127.0.0.1          UHS             0        0     lo0

> Furthermore, I would suggest the draft include the following in
> section 4: "Administrative entities other than Service Providers MUST
> NOT use the IPv4 address space reserved for this use.  An example of
> why this would be a problem is if an Enterprise's internal private
> network used this address space and the Enterprise someday wanted to
> provide remote employees with VPN access to the private network, then
> any employees connected to any Service Provider anywhere using the
> same address space would not be able to VPN in to the local
> Enterprise because of the resulting overlap in their local device's
> routing table."
> 
> -hadriel

---

From: Cameron Byrne <[email-masked]>
Date: Sun, 4 Dec 2011 10:50:28 -0800

> 10.170.127.207     127.0.0.1          UHS             0        0     lo0

An additional fact is that Verizon reuses 10/8 across their network, 10/8
per region.

Net net, rfc1918 is used in cgn today. Squat space is also used in cgn
today. Making an allocation creates another permutation of how cgns are
deployed.

Furthermore, a /10 is not a large enough allocation to be the one solution
everyone can converge on.

Cb

---

From: Victor Kuarsingh <[email-masked]>
Date: Sun, 04 Dec 2011 14:01:07 -0500

Joel

>It's an absurdity that the clearly impossible is in fact the defacto

This is the case for this specific Wireless provider and the particular
APN you are connected to.  The sum of all Wireless providers do not use
RFC1918 (some do, and some do not, and some use both RFC1918 and squat).

Your provider is welcome to choose any space they want at this point.
But, if given a choice I wonder if they would switch to help eliminate
challenges.

I can say that it is in fact very very challenging keeping RFC1918 space
negotiated cleanly (avoid overlap) in the Wireless space.

Other representatives from other Wireless providers have also stated that
they use Squat.  I would suggest that the defacto is a range of address
blocks which at times includes RFC1918, squat in other cases and public
IPs as well (not common, but used at times).

On a side note (upshot), it's nice to see IPv6 on your LTE (real 4G)
connection.

Regards,

Victor K

---

From: Hadriel Kaplan <[email-masked]>
Date: Sun, 4 Dec 2011 19:06:39 +0000

Yes, I know that mobile networks have started going that way - which is why I asked the question.  The reason we (the IETF) cannot possibly pick the same RFC1918 address space is because those mobile networks now have the problem I described: when you try to run your VPN client on that laptop, if your employer's Enterprise private network happens to use the same private address space as the mobile provider, it no workie. (assuming the VPN connection succeeds to begin with, of course)

There is nothing the mobile provider can reasonably do about that, short of charging more money for "VPN-capable" connections as some hotels and access spots do.  Some providers would probably be fine with such a charging model, but some providers I've talked to don't want to have such a charging model and don't want to use the 10.x.x.x address space, but don't have much choice since we haven't allocated a different one. 

-hadriel
p.s. I didn't mean "cannot possibly" in the sense of it being technically impossible, I meant it in the sense of it being a very bad idea. :)

---

From: Joel jaeggli <[email-masked]>
Date: Sun, 04 Dec 2011 11:26:41 -0800

On 12/4/11 11:06 , Hadriel Kaplan wrote:
> 
> Yes, I know that mobile networks have started going that way - which
> is why I asked the question.

It's not a question of starting. outside of some small number of
developed economies mobile carriers and a number of wireline providers
were always depolyed that way, or out of squat space however bad an idea
that may have been.

>  The reason we (the IETF) cannot
> possibly pick the same RFC1918 address space is because those mobile
> networks now have the problem I described: when you try to run your
> VPN client on that laptop, if your employer's Enterprise private
> network happens to use the same private address space as the mobile
> provider, it no workie. (assuming the VPN connection succeeds to
> begin with, of course)

the vpn connection is going to work, it's being established against a
public endpoint. the risk for a collision between the resulting routing
tables is scoped to the netmask of that outside interface.

enterprises have a lot of experience with this, it's a necessary
consequence of supporting mobile users whether they are wireless or in
hotels.

> There is nothing the mobile provider can reasonably do about that,
> short of charging more money for "VPN-capable" connections as some
> hotels and access spots do.  Some providers would probably be fine
> with such a charging model, but some providers I've talked to don't
> want to have such a charging model and don't want to use the 10.x.x.x
> address space, but don't have much choice since we haven't allocated
> a different one.
> 
> -hadriel p.s. I didn't mean "cannot possibly" in the sense of it
> being technically impossible, I meant it in the sense of it being a
> very bad idea. :)
> 
> 
>>> Hi Victor, Yes that helps, thanks - it confirms what I had
>>> always assumed was the case but could not grok from the
>>> discussions on this list nor the draft.
>>> 
>>> Because the new address space is actually seen/used by the
>>> consumer's interface, we cannot possibly pick a "safe" RFC 1918
>>> address nor 240/experimental space, for the reasons I stated in
>>> my email.  We *have* to allocate a new space.
>> 
>> It's an absurdity that the clearly impossible is in fact the
>> defacto deployment model.
>> 
>> en3: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu
>> 1428 ether 64:99:5d:fd:b2:d4 inet6 fe80::6699:5dff:fefd:b2d4%en3
>> prefixlen 64 scopeid 0xc inet6
>> 2600:1010:b005:c97d:6699:5dff:fefd:b2d4 prefixlen 64 autoconf inet6
>> 2600:1010:b005:c97d:b963:23e7:3ae1:e287 prefixlen 64 autoconf 
>> temporary inet 10.170.127.207 netmask 0xffffffe0 broadcast
>> 10.170.127.223 media: autoselect (1000baseT <full-duplex>) status:
>> active
>> 
>> 
>> 10.170.127.192/27  link#12            UCS             2        0
>> en3 10.170.127.193     4c:47:45:56:44:58  UHLWIi        422
>> 34     en3 1197 10.170.127.207     127.0.0.1          UHS
>> 0        0     lo0
>> 
>>> section 4: "Administrative entities other than Service Providers
>>> MUST NOT use the IPv4 address space reserved for this use.  An
>>> example of why this would be a problem is if an Enterprise's
>>> internal private network used this address space and the
>>> Enterprise someday wanted to provide remote employees with VPN
>>> access to the private network, then any employees connected to
>>> any Service Provider anywhere using the same address space would
>>> not be able to VPN in to the local Enterprise because of the
>>> resulting overlap in their local device's routing table."
>>> 
>>> -hadriel
> 
>

---

From: Cameron Byrne <[email-masked]>
Date: Sun, 4 Dec 2011 11:27:21 -0800

On Dec 4, 2011 11:06 AM, "Hadriel Kaplan" <[email-masked]> wrote:
>
>
> Yes, I know that mobile networks have started going that way - which is
why I asked the question.  The reason we (the IETF) cannot possibly pick
the same RFC1918 address space is because those mobile networks now have
the problem I described: when you try to run your VPN client on that
laptop, if your employer's Enterprise private network happens to use the
same private address space as the mobile provider, it no workie. (assuming
the VPN connection succeeds to begin with, of course)

Started?  I would say most mobile data networks started with rfc1918 at the
inception of WAP mobile data services nearly 10 years ago and have stayed
that way, replacing WAP proxies with CGN 5 years ago.  This is not a novel
problem.

Regarding enterprise vpns, the client VPN abstracts the host routing to
make this work.  I am not sure which part you don't understand.  You do
know 1918 is in most home networks and most enterprises and it just works,
right ?

Sorry if I misunderstand your concern.

Cb

> There is nothing the mobile provider can reasonably do about that, short
of charging more money for "VPN-capable" connections as some hotels and
access spots do.  Some providers would probably be fine with such a
charging model, but some providers I've talked to don't want to have such a
charging model and don't want to use the 10.x.x.x address space, but don't
have much choice since we haven't allocated a different one.

> -hadriel
> p.s. I didn't mean "cannot possibly" in the sense of it being technically
impossible, I meant it in the sense of it being a very bad idea. :)

---

From: Hadriel Kaplan <[email-masked]>
Date: Sun, 4 Dec 2011 19:49:53 +0000

> were always depolyed that way, or out of squat space however bad an idea

OK, yeah "started" is not a good word.  It's been that way for a good while.

> tables is scoped to the netmask of that outside interface.

Nope.  The VPN transport layer connection works of course - the resulting internal routes learned inside it break.  Obviously if the netmask/subnets work out right you're ok.  But that's the rub - how do we know what they could be?
This isn't just some simple model of a single corporate 10.x.x.x subnet you're reaching through a VPN; big/medium companies have multiple internal private networks, including labs and remote branches and such. 

> consequence of supporting mobile users whether they are wireless or in

And it actually breaks in practice.  I'm not speaking of hypotheticals - it's happened to me, at more than one employer.
I don't disagree similar problems happen in hotel networks (that's happened to me too, at an IETF meeting hotel years ago if I recall right)... but do we want to say the ISPs have to use a hotel model of "click this and pay more for a VPN-capable connection" instead of allocating them a /10?  [note: I realize hotels do this to also make legacy unencapsulated IPsec vpn's work, but I'm not talking about that]

-hadriel

---

From: Pete Resnick <[email-masked]>
Date: Mon, 5 Dec 2011 09:51:31 -0600

On 12/4/11 9:04 AM, Hadriel Kaplan wrote:
> For RFC 1918 space, the problem with picking it isn't so much that the ISP can't pick one that consumer NATs don't use - it's that they can't pick one that no Enterprise on a*different*  ISP uses.  For example, assume my employer used 10.64.0.0/10 (they probably do somewhere), and connected to ISP-A.  I connect to ISP-B using a 3GPP laptop-card, and get the same 10.64.0.0/10 address space.  I now cannot use a VPN to my employer, because of the resulting conflict in the routing table in my laptop.  But there's nothing I nor my*ISP-B*  can do about this, because my employer has been using that address for a long time (legitimately) and is connected to*ISP-A*.
>    

Doesn't this same problem exist if I'm currently attached to a CPE NAT 
that provides me with a 10.64.0.0/10 address and my VPN uses the same 
space? Are you saying that VPN software does not already deal with this?

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

---

From: Joel jaeggli <[email-masked]>
Date: Mon, 05 Dec 2011 08:08:45 -0800

> space? Are you saying that VPN software does not already deal with this?

Some vpn clients will split the routing table to isolate vpn routes from
external routes which copes just fine with this case, much as does VRF
on a router.

> pr
> 
> -- 
> Pete Resnick <http://www.qualcomm.com/~presnick/>

---

From: "George, Wes" <[email-masked]>
Date: Mon, 5 Dec 2011 12:04:16 -0500

> 10.170.127.207     127.0.0.1          UHS             0        0     lo0
And "Cameron Byrne" <[email-masked]> wrote:
An additional fact is that Verizon reuses 10/8 across their network, 10/8 per region.
Net net, rfc1918 is used in cgn today. Squat space is also used in cgn today. Making an allocation creates another permutation of how cgns are deployed.
Furthermore, a /10 is not a large enough allocation to be the one solution everyone can converge on.

[WEG] I don't believe that anyone is suggesting that any one size of block fits all. I fully expect that networks of sufficient size would end up reusing the shared space multiple times for multiple NAT regions just like they would 1918 space.
I also don't believe that the IETF could ever formally recommend using squat space given the known breakage cases that exist, especially since the party subject to the breakage may not be involved in the discussion of the calculated risk being taken. Put another way, existence proofs don't make it any better of an idea or reduce the risk of breakage.
This leaves either GUA space, which we're ostensibly trying not to "waste" on things that shouldn't use up the precious  resource, or 1918.
I don't think that anyone on here is saying that it's completely impossible to use 1918 for CGN. I think they are saying that it has enough breakage cases that it's not possible to say that it's good enough for all cases by itself.
Just as you say above that the size isn't good for all, you have multiple operators saying that 1918 as a solution is not good enough for all, along with technical and operational justifications as to why, and it mainly sounds like this is a question of whether "IETF knows best" trumps those justifications in determining whether they're legitimate problems or not.

Also, independent of whether VPN works or does not work if the host is using 1918 space + NAT, there is an important distinction on the wireless CGN using 1918 example that covers the other breakage case:
It's NAT44 in wireless (device directly to CGN), and not NAT444 as it would be in most broadband applications. It's only when you start talking about using a mobile device for connection sharing (MiFi or Phone WiFi hotspots, routers with LTE cards in them instead of wired uplinks, etc) that you're really comparing the two in a way that's directly applicable, since then you could have:
[local 1918 segment] -LAN- <SOHO/res NAT router> -WAN- [CGN 1918 block] -- <CGN> -- [PublicIP]

If these hotspot devices are doing NAT444 with private space on both LAN and WAN, vs doing NAT444 using Squat space on the WAN side vs doing NAT44 with a public address on the WAN side, that'd be good information to have, as it may be an existence proof one way or the other regarding whether having 1918 on both sides of a CPE "router" actually works.
However, it's worth noting that in most cases, the mobile provider owns the device being used as that intermediary, so they can explicitly configure and test it to ensure that it functions correctly in the case where there is 1918 addresses on both LAN and WAN interface. There's no way to make that assumption with customer-provided CPE.

Wes George

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 05 Dec 2011 16:02:07 -0500

>>>>> "Pete" == Pete Resnick <[email-masked]> writes:
    >> For RFC 1918 space, the problem with picking it isn't so much
    >> that the ISP can't pick one that consumer NATs don't use - it's
    >> that they can't pick one that no Enterprise on a*different* ISP
    >> uses.  For example, assume my employer used 10.64.0.0/10 (they
    >> probably do somewhere), and connected to ISP-A.  I connect to
    >> ISP-B using a 3GPP laptop-card, and get the same 10.64.0.0/10
    >> address space.  I now cannot use a VPN to my employer, because of
    >> the resulting conflict in the routing table in my laptop.  But
    >> there's nothing I nor my*ISP-B* can do about this, because my
    >> employer has been using that address for a long time
    >> (legitimately) and is connected to*ISP-A*.

    Pete> Doesn't this same problem exist if I'm currently attached to a
    Pete> CPE NAT that provides me with a 10.64.0.0/10 address and my
    Pete> VPN uses the same space? Are you saying that VPN software does
    Pete> not already deal with this?

It's not an easily solved problem, particularly if the VPN software is
not provided by the creator of the TCP/IP stack.  Even when it is
solved, it's still a horrible hack.

Most NAT boxes are routers that twiddle addresses.  They are not double
stack application gateways.

-- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition.

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 5 Dec 2011 16:03:58 -0500

On Mon, Dec 05, 2011 at 04:02:07PM -0500, Michael Richardson wrote:

> Even when it is solved, it's still a horrible hack.

At last!  The slogan for this discussion!

A

-- 
Andrew Sullivan
[email-masked]