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