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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf