Re: [Softwires] WG last call on draft-ietf-softwire-stateless-4v6-motivation-01
Hi Dapeng, A state maintained in the endpoint does not make the solution stateful, see this excerpt from RFC1958: This principle has important consequences if we require applications to survive partial network failures. An end-to-end protocol design should not rely on the maintenance of state (i.e. information about the state of the end-to-end communication) inside the network. Such state should be maintained only in the endpoints, in such a way that the state can only be destroyed when the endpoint itself breaks (known as fate-sharing). I didn't considered your last proposed changes for the reason mentioned above. Thank you for your help. Cheers, Med -Message d'origine- De : liu dapeng [mailto:maxpass...@gmail.com] Envoyé : lundi 11 juin 2012 05:47 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : Yong Cui; softwires@ietf.org Objet : Re: [Softwires] WG last call on draft-ietf-softwire-stateless-4v6-motivation-01 Hi Med: 2012/6/8, mohamed.boucad...@orange.com mohamed.boucad...@orange.com: Dear Dapeng, Please see inline. Cheers, -Message d'origine- De : liu dapeng [mailto:maxpass...@gmail.com] Envoyé : vendredi 8 juin 2012 13:49 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : Yong Cui; softwires@ietf.org Objet : Re: [Softwires] WG last call on draft-ietf-softwire-stateless-4v6-motivation-01 Med: We have already this text in the introduction: Current standardization effort that is meant to address this IPv4 service continuity issue focuses mainly on stateful mechanisms that assume the sharing of any global IPv4 address that is left between several customers, based upon the deployment of NAT (Network Address Translation) capabilities in the network. Because of some caveats of such stateful approaches the Service Provider community feels that a companion effort is required to specify stateless IPv4 over IPv6 approaches. This document provides elaboration on such need. Isn't this text sufficient enough? If not, it would helpful to propose a sentence you want to be added to the introduction. How about adding the following sentences: --- In many networks today, NAT44 functions is equipped on customer-edge device. It may impact IPv4 over IPv6 solution to be a stateful solution from end-to-end perspectives. The stateless solution also may subject to NAT44 state. In this document, we mainly refer this stateless paradigm to large-scale address Sharing, i.e. carrier-side stateless IPv4 over IPv6, which resolve the concern of stateless terminology. This document provides elaboration on such need. --- Med: Thanks for the proposal. I shortened your proposal and updated the text to: Current standardization effort that is meant to address this IPv4 service continuity issue focuses mainly on stateful mechanisms that assume the sharing of any global IPv4 address that is left between several customers, based upon the deployment of NAT (Network Address Translation) capabilities in the network. Because of some caveats of such stateful approaches the Service Provider community feels that a companion effort is required to specify stateless IPv4 over IPv6 approaches. Note stateless IPv4 over IPv6 solutions may be enabled in conjunction with a port-restricted NAT44 function located in the customer premises. This document provides elaboration on the need for carrier-side stateless IPv4 over IPv6 solution. Are you OK with this new text? [Dapeng]== I make a minor change of the last two sentences: - Because of some caveats of such stateful approaches the Service Provider community feels that a companion effort is required to specify carrier-side stateless IPv4 over IPv6 approaches. Note carrier-side stateless IPv4 over IPv6 solutions may be enabled in conjunction with a port-restricted NAT44 function located in the customer premises or port translation in the host and that is still stateful in the whole. - Besides, how about changing all the terminology stateless to carrier-side stateless in the document? Thanks, Best Regards, Dapeng Liu -- -- Best Regards, Dapeng Liu ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] WG last call ondraft-ietf-softwire-stateless-4v6-motivation-01
I would prefer IETF more strict about what accurate terminology we are using other than favorite. At this moment this document go through working group last call which I have reviewed, and believe it should be Revised for not misleading other people. Thanks for your suggestion. Regards, Dapeng Liu 2012/6/11, Rajiv Asati (rajiva) raj...@cisco.com: I am not fond of the proposed change. After all, most of the other documents refer to stateful without taking a side (e.g. carrier-side), and so this document should state stateless in the same regard. Of course, where it makes sense to clarify, it must be clarified that stateless is in the carrier-side, with or without stateful NAT44 in the customer-side. We must not make the assumption that stateless and stateful go together, though they will likely. Cheers, Rajiv -Original Message- From: softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] On Behalf Of liu dapeng Sent: Sunday, June 10, 2012 11:47 PM To: mohamed.boucad...@orange.com Cc: softwires@ietf.org; Yong Cui Subject: Re: [Softwires] WG last call ondraft-ietf-softwire-stateless-4v6- motivation-01 Hi Med: 2012/6/8, mohamed.boucad...@orange.com mohamed.boucad...@orange.com: Dear Dapeng, Please see inline. Cheers, -Message d'origine- De : liu dapeng [mailto:maxpass...@gmail.com] Envoyé : vendredi 8 juin 2012 13:49 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : Yong Cui; softwires@ietf.org Objet : Re: [Softwires] WG last call on draft-ietf-softwire-stateless-4v6-motivation-01 Med: We have already this text in the introduction: Current standardization effort that is meant to address this IPv4 service continuity issue focuses mainly on stateful mechanisms that assume the sharing of any global IPv4 address that is left between several customers, based upon the deployment of NAT (Network Address Translation) capabilities in the network. Because of some caveats of such stateful approaches the Service Provider community feels that a companion effort is required to specify stateless IPv4 over IPv6 approaches. This document provides elaboration on such need. Isn't this text sufficient enough? If not, it would helpful to propose a sentence you want to be added to the introduction. How about adding the following sentences: --- In many networks today, NAT44 functions is equipped on customer-edge device. It may impact IPv4 over IPv6 solution to be a stateful solution from end-to-end perspectives. The stateless solution also may subject to NAT44 state. In this document, we mainly refer this stateless paradigm to large-scale address Sharing, i.e. carrier-side stateless IPv4 over IPv6, which resolve the concern of stateless terminology. This document provides elaboration on such need. --- Med: Thanks for the proposal. I shortened your proposal and updated the text to: Current standardization effort that is meant to address this IPv4 service continuity issue focuses mainly on stateful mechanisms that assume the sharing of any global IPv4 address that is left between several customers, based upon the deployment of NAT (Network Address Translation) capabilities in the network. Because of some caveats of such stateful approaches the Service Provider community feels that a companion effort is required to specify stateless IPv4 over IPv6 approaches. Note stateless IPv4 over IPv6 solutions may be enabled in conjunction with a port-restricted NAT44 function located in the customer premises. This document provides elaboration on the need for carrier-side stateless IPv4 over IPv6 solution. Are you OK with this new text? [Dapeng]== I make a minor change of the last two sentences: - Because of some caveats of such stateful approaches the Service Provider community feels that a companion effort is required to specify carrier-side stateless IPv4 over IPv6 approaches. Note carrier-side stateless IPv4 over IPv6 solutions may be enabled in conjunction with a port-restricted NAT44 function located in the customer premises or port translation in the host and that is still stateful in the whole. - Besides, how about changing all the terminology stateless to carrier-side stateless in the document? Thanks, Best Regards, Dapeng Liu -- -- Best Regards, Dapeng Liu ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires -- -- Best Regards, Dapeng Liu ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02
Hi Behcet, I failed to understand the point you are trying to make. The current situations is: * this document provides multicast extension to deliver multicast to DS-Lite serviced customers * we rely on multicast capabilities, as such no AMT-like considerations are included * the proposed solution is generic and can be deployed in any 4-6-4 use case What should be revised? Thanks for your help. Cheers, Med -Message d'origine- De : Behcet Sarikaya [mailto:sarikaya2...@gmail.com] Envoyé : vendredi 8 juin 2012 17:35 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : Wojciech Dec; Stig Venaas; softwires@ietf.org; Yong Cui Objet : Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02 Hi Med, I agree with Woj. I do not favor moving this draft to somewhere else. Instead this draft should be revised to make it Multicast extensions to DS-Lite as in the charter. There is enough time to do it. Regards, Behcet On Fri, Jun 8, 2012 at 3:43 AM, mohamed.boucad...@orange.com wrote: Hi Woj, Your comment is valid. The point I wanted to make is to recall the initial motivation of this draft: solve an issue raised by DS-Lite people. Evidently, the proposed approach can be deployed in any 4-6-4 scenario. This will be reflected in the updated version of the draft. Cheers, Med De : Wojciech Dec [mailto:wdec.i...@gmail.com] Envoyé : vendredi 8 juin 2012 09:57 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : sarik...@ieee.org; Stig Venaas; softwires@ietf.org; Yong Cui Objet : Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02 Hello Med, there is no dependency here on ds-lite, ie This has all the hallmarks of a standalone solution, which will almost certainly be implemented as such, and one that will work with or without ds-lite for unicast. Regards, Woj. On 8 June 2012 07:48, mohamed.boucad...@orange.com wrote: Re-, May I re-iterate: * The draft is designed to allow the delivery of multicast services to DS-Lite serviced customers. * The draft proposes multicast extensions and not unicast ones. Cheers, Med -Message d'origine- De : Behcet Sarikaya [mailto:sarikaya2...@gmail.com] Envoyé : jeudi 7 juin 2012 20:20 À : Stig Venaas Cc : BOUCADAIR Mohamed OLNC/NAD/TIP; softwires@ietf.org; Yong Cui Objet : Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02 On Thu, Jun 7, 2012 at 12:48 PM, Stig Venaas s...@venaas.com wrote: On 6/7/2012 10:08 AM, Behcet Sarikaya wrote: On Thu, Jun 7, 2012 at 8:07 AM,mohamed.boucad...@orange.com wrote: So you are saying that this draft does not correspond to Multicast extensions for DS-Lite? I sent a separate review, but anyway, it is not an extension to DS-Lite as I see it. It is a completely generic approach for tunneling v6 through v4. It can certainly be deployed in DS-Lite scenarios, but it is much more generic. I would like the title and the text to reflect that. So it means that this draft does not correspond to Softwire charter item and we discover this quite late in the process. My recommendation to the chairs is to read and double check the draft before making an adoption call, especially if there is choice. As I mentioned in my mboned mail, in multicast transition I think the right approach is to agree to the fact that most of the host's communication will be unicast. For unicast, v4-v6 transition has already been well analyzed and several protocols have been specified. Multicast extensions to those protocols are what we need. Regards, Behcet ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] WG last call on draft-ietf-softwire-stateless-4v6-motivation-01
Re-, I was answering to your last proposed wording to include the port translation in the host. Except that change, all your proposed changes are included in my local copy: * The title has been updated as your requested * The introduction has been updated. Cheers, Med -Message d'origine- De : liu dapeng [mailto:maxpass...@gmail.com] Envoyé : lundi 11 juin 2012 09:11 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : Yong Cui; softwires@ietf.org Objet : Re: [Softwires] WG last call on draft-ietf-softwire-stateless-4v6-motivation-01 Hi Med, end to end argument is different from stateful/stateless principally, end to end argument recommend state in the end point(host), but it doesn't say it is stateless, it is still stateful. Based on this, I still believe that we need update the current document with the last comment. Regards, Dapeng Liu 2012/6/11, liu dapeng maxpass...@gmail.com: Hi Med: 2012/6/8, mohamed.boucad...@orange.com mohamed.boucad...@orange.com: Dear Dapeng, Please see inline. Cheers, -Message d'origine- De : liu dapeng [mailto:maxpass...@gmail.com] Envoyé : vendredi 8 juin 2012 13:49 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : Yong Cui; softwires@ietf.org Objet : Re: [Softwires] WG last call on draft-ietf-softwire-stateless-4v6-motivation-01 Med: We have already this text in the introduction: Current standardization effort that is meant to address this IPv4 service continuity issue focuses mainly on stateful mechanisms that assume the sharing of any global IPv4 address that is left between several customers, based upon the deployment of NAT (Network Address Translation) capabilities in the network. Because of some caveats of such stateful approaches the Service Provider community feels that a companion effort is required to specify stateless IPv4 over IPv6 approaches. This document provides elaboration on such need. Isn't this text sufficient enough? If not, it would helpful to propose a sentence you want to be added to the introduction. How about adding the following sentences: --- In many networks today, NAT44 functions is equipped on customer-edge device. It may impact IPv4 over IPv6 solution to be a stateful solution from end-to-end perspectives. The stateless solution also may subject to NAT44 state. In this document, we mainly refer this stateless paradigm to large-scale address Sharing, i.e. carrier-side stateless IPv4 over IPv6, which resolve the concern of stateless terminology. This document provides elaboration on such need. --- Med: Thanks for the proposal. I shortened your proposal and updated the text to: Current standardization effort that is meant to address this IPv4 service continuity issue focuses mainly on stateful mechanisms that assume the sharing of any global IPv4 address that is left between several customers, based upon the deployment of NAT (Network Address Translation) capabilities in the network. Because of some caveats of such stateful approaches the Service Provider community feels that a companion effort is required to specify stateless IPv4 over IPv6 approaches. Note stateless IPv4 over IPv6 solutions may be enabled in conjunction with a port-restricted NAT44 function located in the customer premises. This document provides elaboration on the need for carrier-side stateless IPv4 over IPv6 solution. Are you OK with this new text? [Dapeng]== I make a minor change of the last two sentences: - Because of some caveats of such stateful approaches the Service Provider community feels that a companion effort is required to specify carrier-side stateless IPv4 over IPv6 approaches. Note carrier-side stateless IPv4 over IPv6 solutions may be enabled in conjunction with a port-restricted NAT44 function located in the customer premises or port translation in the host and that is still stateful in the whole. - Besides, how about changing all the terminology stateless to carrier-side stateless in the document? Thanks, Best Regards, Dapeng Liu -- -- Best Regards, Dapeng Liu -- -- Best Regards, Dapeng Liu ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] WG last call on draft-ietf-softwire-stateless-4v6-motivation-01
Hello Med, Yes, we are almost converged on this final update. As you said here, there still need port translation in the host, that still state in the host. we need clarify that in this document for other readers. Best Regards, Dapeng Liu 2012/6/11, mohamed.boucad...@orange.com mohamed.boucad...@orange.com: Re-, I was answering to your last proposed wording to include the port translation in the host. Except that change, all your proposed changes are included in my local copy: * The title has been updated as your requested * The introduction has been updated. Cheers, Med -Message d'origine- De : liu dapeng [mailto:maxpass...@gmail.com] Envoyé : lundi 11 juin 2012 09:11 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : Yong Cui; softwires@ietf.org Objet : Re: [Softwires] WG last call on draft-ietf-softwire-stateless-4v6-motivation-01 Hi Med, end to end argument is different from stateful/stateless principally, end to end argument recommend state in the end point(host), but it doesn't say it is stateless, it is still stateful. Based on this, I still believe that we need update the current document with the last comment. Regards, Dapeng Liu 2012/6/11, liu dapeng maxpass...@gmail.com: Hi Med: 2012/6/8, mohamed.boucad...@orange.com mohamed.boucad...@orange.com: Dear Dapeng, Please see inline. Cheers, -Message d'origine- De : liu dapeng [mailto:maxpass...@gmail.com] Envoyé : vendredi 8 juin 2012 13:49 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : Yong Cui; softwires@ietf.org Objet : Re: [Softwires] WG last call on draft-ietf-softwire-stateless-4v6-motivation-01 Med: We have already this text in the introduction: Current standardization effort that is meant to address this IPv4 service continuity issue focuses mainly on stateful mechanisms that assume the sharing of any global IPv4 address that is left between several customers, based upon the deployment of NAT (Network Address Translation) capabilities in the network. Because of some caveats of such stateful approaches the Service Provider community feels that a companion effort is required to specify stateless IPv4 over IPv6 approaches. This document provides elaboration on such need. Isn't this text sufficient enough? If not, it would helpful to propose a sentence you want to be added to the introduction. How about adding the following sentences: --- In many networks today, NAT44 functions is equipped on customer-edge device. It may impact IPv4 over IPv6 solution to be a stateful solution from end-to-end perspectives. The stateless solution also may subject to NAT44 state. In this document, we mainly refer this stateless paradigm to large-scale address Sharing, i.e. carrier-side stateless IPv4 over IPv6, which resolve the concern of stateless terminology. This document provides elaboration on such need. --- Med: Thanks for the proposal. I shortened your proposal and updated the text to: Current standardization effort that is meant to address this IPv4 service continuity issue focuses mainly on stateful mechanisms that assume the sharing of any global IPv4 address that is left between several customers, based upon the deployment of NAT (Network Address Translation) capabilities in the network. Because of some caveats of such stateful approaches the Service Provider community feels that a companion effort is required to specify stateless IPv4 over IPv6 approaches. Note stateless IPv4 over IPv6 solutions may be enabled in conjunction with a port-restricted NAT44 function located in the customer premises. This document provides elaboration on the need for carrier-side stateless IPv4 over IPv6 solution. Are you OK with this new text? [Dapeng]== I make a minor change of the last two sentences: - Because of some caveats of such stateful approaches the Service Provider community feels that a companion effort is required to specify carrier-side stateless IPv4 over IPv6 approaches. Note carrier-side stateless IPv4 over IPv6 solutions may be enabled in conjunction with a port-restricted NAT44 function located in the customer premises or port translation in the host and that is still stateful in the whole. - Besides, how about changing all the terminology stateless to carrier-side stateless in the document? Thanks, Best Regards, Dapeng Liu -- -- Best Regards, Dapeng Liu -- -- Best Regards, Dapeng Liu -- -- Best Regards, Dapeng Liu ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] WG last call on draft-ietf-softwire-public-4over6-01
On 9 June 2012 05:35, Qi Sun sunqi.csnet@gmail.com wrote: Hi Ole, In your previous Email you wrote, in MAP you do all of that with one single DHCPv6 option... IMHO, that's because the one DHCPv6 option contains so many KINDS of information (e.g. PSID, BR's prefix or address, see draft of map-dhcp-option ). And with separate provisoning processes , it's easier to detect problems if the whole process fails. Disagree: Figuring out what went wrong in DHCPv6 acquisition followed by DNS resolution to get the DHCPv4 server address, followed by DHCPv4 relaying, followed by DHCPv4 acquisition, has multiple levels of not easy to detect failuires. -Woj. Best Regards! Qi Sun On 6/8/12, Ole Trøan otr...@employees.org wrote: Peng, Now there are actually 3 directions for IPv4-over-IPv6 mechanisms, they have respective application scenarios, pros and cons. 1)stateless, 4rd, MAP 2)per-flow stateful: DS-Lite 3)per-user stateful: public 4over6, lightweight 4over6 As Ole said, the problem is that, do we want serveral simple mechanisms, or one super-compatible mechanism with different modes. Now Given that a) the WG has accomplished DS-lite; b)MAP follows the stateless motivation all along the way; c)The signifcant changes to make MAP super-compatible, I vote for we define the third type, per-user stateful mechanisms independently. actually there are no significant changes to the MAP specification, the per-user stateful mechanism is just intrinsically supported by MAP. it is a corner case, and it would be more work in the specification to ban this operational mode, than to support it. btw, one thing that appears most complicated is provisioning; currently it looks like L4over6 suggests using 2 DHCP sessions and 3 DHCP options to get provisioned. firstly a RFC6334 exchange to get the DS-lite tunnel up, then a DHCPv6 option for the DHCPv4 server address, and then a DHCPv4 exchange to get the IPv4 address, and then a new DHCPv4 option to get the port set. that seems to me to be quite a few moving parts, and quiet a few corner cases to be specified when one or more of the above fails. in MAP you do all of that with one single DHCPv6 option... cheers, Ole ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] WG last call on draft-ietf-softwire-stateless-4v6-motivation-01
2012/6/11, Rémi Després despres.r...@laposte.net: Le 2012-06-11 à 09:32, liu dapeng a écrit : Hello Med, Yes, we are almost converged on this final update. As you said here, there still need port translation in the host, that still state in the host. Note that these states are per-connection, not per customer. Even a host without NAT has to maintain per-connection states for its sockets. The state you mentioned here is for application, but we are talking about state on the network layer, they are different. I don't see why we resist on clarifying and helping reader better understanding. Besides, I guess the state referred in this document is not specific to either per-connection or per customer . AFTR also hold a per-connection state, which is treated as a stateful in the document. Best Regards, Dapeng Liu In this respect, the draft is I think acceptable, and hopefully can now proceed quickly. Regards, RD we need clarify that in this document for other readers. Best Regards, Dapeng Liu 2012/6/11, mohamed.boucad...@orange.com mohamed.boucad...@orange.com: Re-, I was answering to your last proposed wording to include the port translation in the host. Except that change, all your proposed changes are included in my local copy: * The title has been updated as your requested * The introduction has been updated. Cheers, Med -Message d'origine- De : liu dapeng [mailto:maxpass...@gmail.com] Envoyé : lundi 11 juin 2012 09:11 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : Yong Cui; softwires@ietf.org Objet : Re: [Softwires] WG last call on draft-ietf-softwire-stateless-4v6-motivation-01 Hi Med, end to end argument is different from stateful/stateless principally, end to end argument recommend state in the end point(host), but it doesn't say it is stateless, it is still stateful. Based on this, I still believe that we need update the current document with the last comment. Regards, Dapeng Liu 2012/6/11, liu dapeng maxpass...@gmail.com: Hi Med: 2012/6/8, mohamed.boucad...@orange.com mohamed.boucad...@orange.com: Dear Dapeng, Please see inline. Cheers, -Message d'origine- De : liu dapeng [mailto:maxpass...@gmail.com] Envoyé : vendredi 8 juin 2012 13:49 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : Yong Cui; softwires@ietf.org Objet : Re: [Softwires] WG last call on draft-ietf-softwire-stateless-4v6-motivation-01 Med: We have already this text in the introduction: Current standardization effort that is meant to address this IPv4 service continuity issue focuses mainly on stateful mechanisms that assume the sharing of any global IPv4 address that is left between several customers, based upon the deployment of NAT (Network Address Translation) capabilities in the network. Because of some caveats of such stateful approaches the Service Provider community feels that a companion effort is required to specify stateless IPv4 over IPv6 approaches. This document provides elaboration on such need. Isn't this text sufficient enough? If not, it would helpful to propose a sentence you want to be added to the introduction. How about adding the following sentences: --- In many networks today, NAT44 functions is equipped on customer-edge device. It may impact IPv4 over IPv6 solution to be a stateful solution from end-to-end perspectives. The stateless solution also may subject to NAT44 state. In this document, we mainly refer this stateless paradigm to large-scale address Sharing, i.e. carrier-side stateless IPv4 over IPv6, which resolve the concern of stateless terminology. This document provides elaboration on such need. --- Med: Thanks for the proposal. I shortened your proposal and updated the text to: Current standardization effort that is meant to address this IPv4 service continuity issue focuses mainly on stateful mechanisms that assume the sharing of any global IPv4 address that is left between several customers, based upon the deployment of NAT (Network Address Translation) capabilities in the network. Because of some caveats of such stateful approaches the Service Provider community feels that a companion effort is required to specify stateless IPv4 over IPv6 approaches. Note stateless IPv4 over IPv6 solutions may be enabled in conjunction with a port-restricted NAT44 function located in the customer premises. This document provides elaboration on the need for carrier-side stateless IPv4 over IPv6 solution. Are you OK with this new text? [Dapeng]== I make a minor change of the last two sentences: - Because of some caveats of such stateful approaches the Service Provider community feels that a companion effort is required to specify carrier-side stateless IPv4 over IPv6 approaches. Note carrier-side stateless IPv4 over IPv6 solutions may be enabled in conjunction with a port-restricted NAT44 function
Re: [Softwires] I-D Action: draft-ietf-softwire-map-00.txt
Ole, Thank you for this update on what is meant by MAP today. Which parameters are advertised to CEs will be completely clear, I suppose, when the DHCPv6 document is also available, but the draft contains IMHO useful clarifications. Two immediate points: - Last sentence of page 8 is DNS64 [RFC6147] become required only when IPv6 servers in the MAP-T domain are expected themselves to initiate communication to external IPv4-only hosts. IPv4 is AFAIK a typo (should be IPv6). - A co-author of the 4rd proposal is still listed as main contributor to this new version. This could mislead readers to believe he renounced to recommend 4rd. Since AFAIK this isn't the case, a solution should be found so that, in a next edition, one better knows who recommends what. Also, since some evolutions of substance have been introduced, a list of these would be highly appreciated, preferably with brief justifications. Cheers, RD After a quick look at the draft 2012-06-08 à 23:30, internet-dra...@ietf.org: A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Softwires Working Group of the IETF. Title : Mapping of Address and Port (MAP) Author(s) : Ole Troan Wojciech Dec Xing Li Congxiao Bao Yu Zhai Satoru Matsushima Tetsuya Murakami Filename: draft-ietf-softwire-map-00.txt Pages : 33 Date: 2012-06-01 This document describes a mechanism for transporting IPv4 packets across an IPv6 network, and a generic mechanism for mapping between IPv6 addresses and IPv4 addresses and transport layer ports. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-softwire-map-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-softwire-map-00.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-softwire-map/ ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] WG last call on draft-ietf-softwire-stateless-4v6-motivation-01
Hi Yiu, Works for me. Thanks. Cheers, Med -Message d'origine- De : Lee, Yiu [mailto:yiu_...@cable.comcast.com] Envoyé : lundi 11 juin 2012 16:54 À : BOUCADAIR Mohamed OLNC/NAD/TIP; liu dapeng Cc : softwires@ietf.org; Yong Cui Objet : Re: [Softwires] WG last call on draft-ietf-softwire-stateless-4v6-motivation-01 Hi Med and Dapeng, In order to close the gap, I suggest a slight modification: Current standardization effort that is meant to address this IPv4 service continuity issue focuses mainly on stateful mechanisms that sharing of global IPv4 addresses between Customers is based upon the deployment of NAT (Network Address Translation) capabilities in the network. Because of some caveats of such stateful approaches the Service Provider community feels that a companion effort is required to specify stateless IPv4 over IPv6 approaches. Note that the stateless solution elaborated in this document focuses on the carrier-side stateless IPv4 over IPv6 solution. States may still exist in other equipments such as customer-premises equipment. Thanks, Yiu On 6/8/12 8:12 AM, mohamed.boucad...@orange.com mohamed.boucad...@orange.com wrote: Med: Thanks for the proposal. I shortened your proposal and updated the text to: Current standardization effort that is meant to address this IPv4 service continuity issue focuses mainly on stateful mechanisms that assume the sharing of any global IPv4 address that is left between several customers, based upon the deployment of NAT (Network Address Translation) capabilities in the network. Because of some caveats of such stateful approaches the Service Provider community feels that a companion effort is required to specify stateless IPv4 over IPv6 approaches. Note stateless IPv4 over IPv6 solutions may be enabled in conjunction with a port-restricted NAT44 function located in the customer premises. This document provides elaboration on the need for carrier-side stateless IPv4 over IPv6 solution. ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02
Hi Med, Thanks for your kind reply. I was talking about http://tools.ietf.org/html/draft-sarikaya-softwire-dslite6rdmulticast-00 (which is now expired, I'll explain why below) Profiting the occasion, let me clarify that the chairs, Alain initially asked the two drafts to be merged. We favored the merger but Med was against. draft-ietf-softwire-dslite-multicast-02 presents a generic v4 to v6 multicast translation technique and as has been indicated such an approach has nothing to do with DS-Lite, i.e. DS-Lite does not translate unicast v4 packets into unicast v6 packets. I hope this is well understood. As such, draft-ietf-softwire-dslite-multicast-02 is suitable for NAT64, (remind you that there is already a multicast solution draft for NAT64). Regards, Behcet On Mon, Jun 11, 2012 at 1:15 AM, mohamed.boucad...@orange.com wrote: Hi Behcet, I failed to understand the point you are trying to make. The current situations is: * this document provides multicast extension to deliver multicast to DS-Lite serviced customers * we rely on multicast capabilities, as such no AMT-like considerations are included * the proposed solution is generic and can be deployed in any 4-6-4 use case What should be revised? Thanks for your help. Cheers, Med -Message d'origine- De : Behcet Sarikaya [mailto:sarikaya2...@gmail.com] Envoyé : vendredi 8 juin 2012 17:35 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : Wojciech Dec; Stig Venaas; softwires@ietf.org; Yong Cui Objet : Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02 Hi Med, I agree with Woj. I do not favor moving this draft to somewhere else. Instead this draft should be revised to make it Multicast extensions to DS-Lite as in the charter. There is enough time to do it. Regards, Behcet On Fri, Jun 8, 2012 at 3:43 AM, mohamed.boucad...@orange.com wrote: Hi Woj, Your comment is valid. The point I wanted to make is to recall the initial motivation of this draft: solve an issue raised by DS-Lite people. Evidently, the proposed approach can be deployed in any 4-6-4 scenario. This will be reflected in the updated version of the draft. Cheers, Med De : Wojciech Dec [mailto:wdec.i...@gmail.com] Envoyé : vendredi 8 juin 2012 09:57 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : sarik...@ieee.org; Stig Venaas; softwires@ietf.org; Yong Cui Objet : Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02 Hello Med, there is no dependency here on ds-lite, ie This has all the hallmarks of a standalone solution, which will almost certainly be implemented as such, and one that will work with or without ds-lite for unicast. Regards, Woj. On 8 June 2012 07:48, mohamed.boucad...@orange.com wrote: Re-, May I re-iterate: * The draft is designed to allow the delivery of multicast services to DS-Lite serviced customers. * The draft proposes multicast extensions and not unicast ones. Cheers, Med -Message d'origine- De : Behcet Sarikaya [mailto:sarikaya2...@gmail.com] Envoyé : jeudi 7 juin 2012 20:20 À : Stig Venaas Cc : BOUCADAIR Mohamed OLNC/NAD/TIP; softwires@ietf.org; Yong Cui Objet : Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02 On Thu, Jun 7, 2012 at 12:48 PM, Stig Venaas s...@venaas.com wrote: On 6/7/2012 10:08 AM, Behcet Sarikaya wrote: On Thu, Jun 7, 2012 at 8:07 AM,mohamed.boucad...@orange.com wrote: So you are saying that this draft does not correspond to Multicast extensions for DS-Lite? I sent a separate review, but anyway, it is not an extension to DS-Lite as I see it. It is a completely generic approach for tunneling v6 through v4. It can certainly be deployed in DS-Lite scenarios, but it is much more generic. I would like the title and the text to reflect that. So it means that this draft does not correspond to Softwire charter item and we discover this quite late in the process. My recommendation to the chairs is to read and double check the draft before making an adoption call, especially if there is choice. As I mentioned in my mboned mail, in multicast transition I think the right approach is to agree to the fact that most of the host's communication will be unicast. For unicast, v4-v6 transition has already been well analyzed and several protocols have been specified. Multicast extensions to those protocols are what we need. Regards, Behcet ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] WG last call on draft-ietf-softwire-public-4over6-01
Woj, On Mon, Jun 11, 2012 at 5:10 PM, Wojciech Dec wdec.i...@gmail.com wrote: There is basic question regarding this draft, one that has also been raised at previous WG meetings: why is it needed?. It's actually written in section 4 of the draft. There is a deeper issue here: This draft seems to give the impression that running such a regular public addressed DHCPv4 based overlay on IPv6 is a simple idea, as opposed to native dual stack. It is anything but, given that Why is it opposed to native dual-stack? It's IPv4-over-IPv6, similar to scenario of DS-Lite and MAP/4rd. I thought the assumption of IPv4-over-IPv6 is that you cannot/do not want to provision native dual-stack? a) it it requires changes to DHCPv4 processing b) it introduces non trivial dependencies between DHCPv6 and DHCPv4 and tunnelling c) requires changes to CPE d) makes life really a mess if we consider a real dual stack CPE. a) Simply make DHCPv4 work with IPv6 as underlying transport. No essential changes to protocol processing. b) What really matters here is provisioning the IPv4 address through DHCPv4. Just like in MAP/4rd, you provision the address through DHCPv6. In pb4over6 DHCPv6 is only an *option* to provide the concentrator address. You have similar logic too in MAP. So I don't think it's non trivial dependancy. They are similar functions for all IPv4-over-IPv6 mechanisms that need provisioning, only different technical paths. c) Any IPv4-over-IPv6 mechanism requires change to CPE ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02
On 6/10/2012 11:15 PM, mohamed.boucad...@orange.com wrote: Hi Behcet, I failed to understand the point you are trying to make. The current situations is: * this document provides multicast extension to deliver multicast to DS-Lite serviced customers But not only DS-Lite. * we rely on multicast capabilities, as such no AMT-like considerations are included * the proposed solution is generic and can be deployed in any 4-6-4 use case Agree it is generic, and I think the draft should be revised to reflect that. Stig What should be revised? Thanks for your help. Cheers, Med -Message d'origine- De : Behcet Sarikaya [mailto:sarikaya2...@gmail.com] Envoyé : vendredi 8 juin 2012 17:35 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : Wojciech Dec; Stig Venaas; softwires@ietf.org; Yong Cui Objet : Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02 Hi Med, I agree with Woj. I do not favor moving this draft to somewhere else. Instead this draft should be revised to make it Multicast extensions to DS-Lite as in the charter. There is enough time to do it. Regards, Behcet On Fri, Jun 8, 2012 at 3:43 AM,mohamed.boucad...@orange.com wrote: Hi Woj, Your comment is valid. The point I wanted to make is to recall the initial motivation of this draft: solve an issue raised by DS-Lite people. Evidently, the proposed approach can be deployed in any 4-6-4 scenario. This will be reflected in the updated version of the draft. Cheers, Med De : Wojciech Dec [mailto:wdec.i...@gmail.com] Envoyé : vendredi 8 juin 2012 09:57 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : sarik...@ieee.org; Stig Venaas; softwires@ietf.org; Yong Cui Objet : Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02 Hello Med, there is no dependency here on ds-lite, ie This has all the hallmarks of a standalone solution, which will almost certainly be implemented as such, and one that will work with or without ds-lite for unicast. Regards, Woj. On 8 June 2012 07:48,mohamed.boucad...@orange.com wrote: Re-, May I re-iterate: * The draft is designed to allow the delivery of multicast services to DS-Lite serviced customers. * The draft proposes multicast extensions and not unicast ones. Cheers, Med -Message d'origine- De : Behcet Sarikaya [mailto:sarikaya2...@gmail.com] Envoyé : jeudi 7 juin 2012 20:20 À : Stig Venaas Cc : BOUCADAIR Mohamed OLNC/NAD/TIP; softwires@ietf.org; Yong Cui Objet : Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02 On Thu, Jun 7, 2012 at 12:48 PM, Stig Venaas s...@venaas.com wrote: On 6/7/2012 10:08 AM, Behcet Sarikaya wrote: On Thu, Jun 7, 2012 at 8:07 AM,mohamed.boucad...@orange.comwrote: So you are saying that this draft does not correspond to Multicast extensions for DS-Lite? I sent a separate review, but anyway, it is not an extension to DS-Lite as I see it. It is a completely generic approach for tunneling v6 through v4. It can certainly be deployed in DS-Lite scenarios, but it is much more generic. I would like the title and the text to reflect that. So it means that this draft does not correspond to Softwire charter item and we discover this quite late in the process. My recommendation to the chairs is to read and double check the draft before making an adoption call, especially if there is choice. As I mentioned in my mboned mail, in multicast transition I think the right approach is to agree to the fact that most of the host's communication will be unicast. For unicast, v4-v6 transition has already been well analyzed and several protocols have been specified. Multicast extensions to those protocols are what we need. Regards, Behcet ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02
On 6/11/2012 1:21 PM, Tina TSOU wrote: If we r looking for a generic encapsulation for multicast transition, here it is. http://datatracker.ietf.org/doc/draft-tsou-softwire-encapsulated-multicast/ In a way, your draft is even more generic Tina. There are also some differences. You're talking about a stateful mapping function and a protocol for requesting mappings. This is avoided here by using a stateless mapping. But roughly speaking, I think your general description Tina, may also include what this draft does. Stig Tina 408-859-4996 On Jun 11, 2012, at 12:08 PM, Stig Venaass...@venaas.com wrote: On 6/10/2012 11:15 PM, mohamed.boucad...@orange.com wrote: Hi Behcet, I failed to understand the point you are trying to make. The current situations is: * this document provides multicast extension to deliver multicast to DS-Lite serviced customers But not only DS-Lite. * we rely on multicast capabilities, as such no AMT-like considerations are included * the proposed solution is generic and can be deployed in any 4-6-4 use case Agree it is generic, and I think the draft should be revised to reflect that. Stig What should be revised? Thanks for your help. Cheers, Med -Message d'origine- De : Behcet Sarikaya [mailto:sarikaya2...@gmail.com] Envoyé : vendredi 8 juin 2012 17:35 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : Wojciech Dec; Stig Venaas; softwires@ietf.org; Yong Cui Objet : Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02 Hi Med, I agree with Woj. I do not favor moving this draft to somewhere else. Instead this draft should be revised to make it Multicast extensions to DS-Lite as in the charter. There is enough time to do it. Regards, Behcet On Fri, Jun 8, 2012 at 3:43 AM,mohamed.boucad...@orange.com wrote: Hi Woj, Your comment is valid. The point I wanted to make is to recall the initial motivation of this draft: solve an issue raised by DS-Lite people. Evidently, the proposed approach can be deployed in any 4-6-4 scenario. This will be reflected in the updated version of the draft. Cheers, Med De : Wojciech Dec [mailto:wdec.i...@gmail.com] Envoyé : vendredi 8 juin 2012 09:57 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : sarik...@ieee.org; Stig Venaas; softwires@ietf.org; Yong Cui Objet : Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02 Hello Med, there is no dependency here on ds-lite, ie This has all the hallmarks of a standalone solution, which will almost certainly be implemented as such, and one that will work with or without ds-lite for unicast. Regards, Woj. On 8 June 2012 07:48,mohamed.boucad...@orange.com wrote: Re-, May I re-iterate: * The draft is designed to allow the delivery of multicast services to DS-Lite serviced customers. * The draft proposes multicast extensions and not unicast ones. Cheers, Med -Message d'origine- De : Behcet Sarikaya [mailto:sarikaya2...@gmail.com] Envoyé : jeudi 7 juin 2012 20:20 À : Stig Venaas Cc : BOUCADAIR Mohamed OLNC/NAD/TIP; softwires@ietf.org; Yong Cui Objet : Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02 On Thu, Jun 7, 2012 at 12:48 PM, Stig Venaas s...@venaas.com wrote: On 6/7/2012 10:08 AM, Behcet Sarikaya wrote: On Thu, Jun 7, 2012 at 8:07 AM,mohamed.boucad...@orange.com wrote: So you are saying that this draft does not correspond to Multicast extensions for DS-Lite? I sent a separate review, but anyway, it is not an extension to DS-Lite as I see it. It is a completely generic approach for tunneling v6 through v4. It can certainly be deployed in DS-Lite scenarios, but it is much more generic. I would like the title and the text to reflect that. So it means that this draft does not correspond to Softwire charter item and we discover this quite late in the process. My recommendation to the chairs is to read and double check the draft before making an adoption call, especially if there is choice. As I mentioned in my mboned mail, in multicast transition I think the right approach is to agree to the fact that most of the host's communication will be unicast. For unicast, v4-v6 transition has already been well analyzed and several protocols have been specified. Multicast extensions to those protocols are what we need. Regards, Behcet ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
[Softwires] I-D Action: draft-ietf-softwire-stateless-4v6-motivation-02.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Softwires Working Group of the IETF. Title : Motivations for Carrier-side Stateless IPv4 over IPv6 Migration Solutions Author(s) : Mohamed Boucadair Satoru Matsushima Yiu Lee Olaf Bonness Isabel Borges Gang Chen Filename: draft-ietf-softwire-stateless-4v6-motivation-02.txt Pages : 16 Date: 2012-06-11 Abstract: IPv4 service continuity is one of the most pressing problems that must be resolved by Service Providers during the IPv6 transition period - especially after the exhaustion of the public IPv4 address space. Current standardization effort that addresses IPv4 service continuity focuses on stateful mechanisms. This document elaborates on the motivations for the need to undertake a companion effort to specify stateless IPv4 over IPv6 approaches. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-softwire-stateless-4v6-motivation There's also a htmlized version available at: http://tools.ietf.org/html/submission.filename }}-02 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=draft-ietf-softwire-stateless-4v6-motivation-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
