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

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


On Dec 4, 2011, at 10:27 AM, Victor Kuarsingh wrote:

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


_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf