[Softwires] IPv4 address exhaustion: Issues and Solutions for ISPs (P1952 Eurescom study)
Hi all, You may be interested in the document P1952 Eurescom study results summary that can be retrieved at: http://www.eurescom.de/~pub/deliverables/documents/P1900-series/P1952/D2 bis/P1952-D2bis.pdf The P1952 Eurescom study has investigated approaches to mitigate the problem of IPv4 address exhaustion. The objective of this study was to inform ISPs about the impact of the IPv4 address shortage, and to provide some recommendations and guidelines that help to identify solutions that best fit concrete network scenarios and business plans. This memo provides a summary of selected results of the P1952 study. Eurescom, the European Institute for Research and Strategic Studies in Telecommunications, was founded in 1991 by major European telecommunication network operators as a platform for collaborative RD. The following ISPs participated in the P1952 study: Deutsche Telekom Eircom France Telecom Portugal Telecom Extract, quoted from Section6: NAT444 The P1952 study admits that the NAT444 approach may be a viable solution under proper circumstances. Nevertheless, the P1952 study does not encourage the implementation of the NAT444 approach: * In many cases NAT444 forces the ISP to manage overlapping IPv4 private address zones * NAT444 provides no synergy with IPv6 deployment DS-lite The P1952 study recommends deploying DS-lite if a solution has to be provided now, or within a short time range: * DS-lite is available (regarding standardisation and implementation) * DS-lite allows a high multiplicative factor * DS-lite is in complete synergy with IPv6 deployment A+P The P1952 study encourages continuing work on A+P: * A+P is not available yet (no standardisation and no operational implementation) * A+P is considered to be less harmful to applications than CGN-based solutions * A+P avoids CGNs that are complex and expensive devices * In that direction the broad range of A+P's flavours to investigate should be narrowed to flavours that: * are in complete synergy with IPv6 deployment * are seen as an evolution of a DS-lite architecture (at least for fixed broadband access) Best Regards Pierre ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] GI-DS-lite as working group item?
Dear Alain, all, Please see inline. Cheers, Med -Message d'origine- De : Alain Durand [mailto:adur...@juniper.net] Envoyé : vendredi 7 mai 2010 18:19 À : Behcet Sarikaya Cc : BOUCADAIR Mohamed NCPI/NAD/TIP; softwires@ietf.org Objet : Re: [Softwires] GI-DS-lite as working group item? On May 7, 2010, at 10:55 AM, Behcet Sarikaya wrote: (c) N:1 model: a single CGN serve a group of PGW/GGSN. Indeed, having +16M of customers is a valid case. **BUT** which Service Provider will accept to service this huge amount of UEs with the same node (if we suppose that a mega centralised CGN implementation is found in the market)? This is single point of failure design which SHOULD NOT BE RECOMMENDED. IMHO it is N:1 and that's why GI-DS lite is interesting to the operators. I agree with you that having 16M+ MNs NAT'ed by a single CGN is something I have not heard of, yes there there is a problem. co-chair hat off: This is the N:P aspect that I find interesting in GI-DS-lite. And it does not have to be limited to 16M+ address being concentrated... nor be limited to wireless. Med: I have several questions here: 1- What do you mean by N:P? (In my first e-mail N refers to the number of gws and 1 is number of CGNs). 2- If applied to fixed networks, (*) this would lead to NAT444 design model since nothing prevent to embed a NAT function in the AD. (*) IPv6 is not a MANDATORY building block of the solution. (*) What is then the recommendation of the WG: use DS-Lite? Or GI-DS-Lite? Etc. (*) A last comment, since GI-DS-Lite is a request from the 3GPP which recommends DS and IPv6-only models, this solution SHOULD be part of that package. Think about an ISP with a number of access router and a number of centralized NATs. Each customer connected to an access router is Med: Even if centralised, having several millions of customers behind the same stateful device is not a viable approach: this node needs to support logging, LI, NAT, ALG, etc. using his own version of RFC1918. Med: Yes, I agree with this point. What GI-DS-lite enable is to implement the NAT function in a different box that potentially has different scaling properties than the access router. Med: Yes but GI-DS-Lite is not the ONLY solution which allows this. You may rely on simple routing configuration from the gateway to its associated NAT(s), use DS-Lite ;-), or use A+P to avoid having any stateful device in the core network, etc. * This message and any attachments (the message) are confidential and intended solely for the addressees. Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration. France Telecom Group shall not be liable for the message if altered, changed or falsified. If you are not the intended addressee of this message, please cancel it immediately and inform the sender. ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] GI-DS-lite as working group item?
Hi Med, As I understand, N:P means you don't need to have a single NAT box in the network, some network partitioning can be done possibly geographically to allow more than one NAT boxes and then it becomes a matter of configuration to connect them to the GWs. I agree with you on the applicability of GI DS-Lite in ISP networks. Regards, Behcet From: mohamed.boucad...@orange-ftgroup.com mohamed.boucad...@orange-ftgroup.com To: Alain Durand adur...@juniper.net; Behcet Sarikaya sarik...@ieee.org Cc: softwires@ietf.org softwires@ietf.org Sent: Mon, May 10, 2010 1:37:12 AM Subject: RE: [Softwires] GI-DS-lite as working group item? Dear Alain, all, Please see inline. Cheers, Med -Message d'origine- De : Alain Durand [mailto:adur...@juniper.net] Envoyé : vendredi 7 mai 2010 18:19 À : Behcet Sarikaya Cc : BOUCADAIR Mohamed NCPI/NAD/TIP; softwires@ietf.org Objet : Re: [Softwires] GI-DS-lite as working group item? On May 7, 2010, at 10:55 AM, Behcet Sarikaya wrote: (c) N:1 model: a single CGN serve a group of PGW/GGSN. Indeed, having +16M of customers is a valid case. **BUT** which Service Provider will accept to service this huge amount of UEs with the same node (if we suppose that a mega centralised CGN implementation is found in the market)? This is single point of failure design which SHOULD NOT BE RECOMMENDED. IMHO it is N:1 and that's why GI-DS lite is interesting to the operators. I agree with you that having 16M+ MNs NAT'ed by a single CGN is something I have not heard of, yes there there is a problem. co-chair hat off: This is the N:P aspect that I find interesting in GI-DS-lite. And it does not have to be limited to 16M+ address being concentrated... nor be limited to wireless. Med: I have several questions here: 1- What do you mean by N:P? (In my first e-mail N refers to the number of gws and 1 is number of CGNs). 2- If applied to fixed networks, (*) this would lead to NAT444 design model since nothing prevent to embed a NAT function in the AD. (*) IPv6 is not a MANDATORY building block of the solution. (*) What is then the recommendation of the WG: use DS-Lite? Or GI-DS-Lite? Etc. (*) A last comment, since GI-DS-Lite is a request from the 3GPP which recommends DS and IPv6-only models, this solution SHOULD be part of that package. Think about an ISP with a number of access router and a number of centralized NATs. Each customer connected to an access router is Med: Even if centralised, having several millions of customers behind the same stateful device is not a viable approach: this node needs to support logging, LI, NAT, ALG, etc. using his own version of RFC1918. Med: Yes, I agree with this point. What GI-DS-lite enable is to implement the NAT function in a different box that potentially has different scaling properties than the access router. Med: Yes but GI-DS-Lite is not the ONLY solution which allows this. You may rely on simple routing configuration from the gateway to its associated NAT(s), use DS-Lite ;-), or use A+P to avoid having any stateful device in the core network, etc. * This message and any attachments (the message) are confidential and intended solely for the addressees. Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration. France Telecom Group shall not be liable for the message if altered, changed or falsified. If you are not the intended addressee of this message, please cancel it immediately and inform the sender. ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
