Hi Yiu, Yes, I understand that point. My comment was related to the claim that GI-DS-Lite allows to "migrate" to IPv6...which I still don't agree with.
What you mentioned is valid for any NAT-based solution. My concerns are as follows: (1) Since it seems that 3GPP is interested in this proposal and the 3GPP recommends DS and IPv6-only, the scope of the document should be restricted to that context. (Need to check if the GI-ds-lite has been moved to the main document of the TR of the IPv6 SI) (2) No Fixed network considerations should be elaborated in the document (3) The problem statement should be clarified for IETF. Is there any issue with depletion of private IPv4 addresses? Clarify why this is a problem and for what deployment context? I still don't encourage centralise NAT approach. (4) Ensure that the proposed solution is not another showstopper for the deployment of IPv6. This is for consistency of the overall IETF work. This does not prevent any SP to do whatever it wants, but from a standardisation perspective alternative solutions to delay IPv6 should be avoided. Gi-Ds-lite for me is one of these category of solutions. It can even lead to NAT444 since the AD can embed a NAT function. I had other concerns with the procedure of the adoption of this document: - It seems to me that the current charter does not allow for adopting it. I asked the chair to clarify but with no answer. Cheers, Med -----Message d'origine----- De : Lee, Yiu [mailto:[email protected]] Envoyé : mardi 18 mai 2010 03:07 À : BOUCADAIR Mohamed NCPI/NAD/TIP; Sri Gundavelli Cc : [email protected] Objet : Re: [Softwires] GI-DS-lite as working group item? Hi Med, > > Med: If the network is IPv6-only (likely the major base of UEs would be > IPv6-enabled, right?), the use of NAT64 would be more appropriate (hence > avoiding tunnelling) that crossing a NAT44 device. No? > For some operators, NAT64 may make more sense; for others, GI-DS-lite may be more useful. In this end, GI-DS-lite just provides a simple way to address the IPv4 exhaustion issue w/o change in the MH. I think there is value for IETF to work on it. Cheers, Yiu ********************************* 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 [email protected] https://www.ietf.org/mailman/listinfo/softwires
