Re: [Softwires] WG last call on draft-ietf-softwire-public-4over6-01
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
Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02
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.commailto: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.commailto:sarikaya2...@gmail.com] Envoyé : jeudi 7 juin 2012 20:20 À : Stig Venaas Cc : BOUCADAIR Mohamed OLNC/NAD/TIP; softwires@ietf.orgmailto: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.commailto: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.commailto: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.orgmailto: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
Ole, 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... Let me make it more precise. In lw 4over6, It's one DHCPv6 exchange and one DHCPv4 exchange. DHCPv6 exchange to get the concentrator address and DHCPv4 server address, two options at the same time. And of course the DHCPv4 server could be collocated with the concentrator. DHCPv4 exchange to retrieve the address and port-set at the same time. Now compared with MAP: 1) Concentrator address is also needed in provisioning. 2) DHCPv4 server address. This is only used when we want to separate DHCPv4 server from the concentrator (For HA, redundancy...). With MAP you cannot do this separation. 3) DHCPv4 is used to provision the address and port-set to the intiator. Now with MAP you provide this as a rule in DHCPv6. That's the most significant difference So, I don't see lw4over6 provisioning more complicated than MAP... ___ 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
Peng, On 8 June 2012 11:35, Peng Wu pengwu@gmail.com wrote: Ole, 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... Let me make it more precise. In lw 4over6, It's one DHCPv6 exchange and one DHCPv4 exchange. DHCPv6 exchange to get the concentrator address and DHCPv4 server address, two options at the same time. And of course the DHCPv4 server could be collocated with the concentrator. DHCPv4 exchange to retrieve the address and port-set at the same time. Now compared with MAP: 1) Concentrator address is also needed in provisioning. 2) DHCPv4 server address. This is only used when we want to separate DHCPv4 server from the concentrator (For HA, redundancy...). With MAP you cannot do this separation. Yes, because MAP doesn't require one to use another component like DHCPv4 which is in itself subject to failure. That said, MAP can also use DHCPv4, but quite honestly what's the point of running DHCPv4 when all the useful info is available via DHCPv6? 3) DHCPv4 is used to provision the address and port-set to the intiator. Now with MAP you provide this as a rule in DHCPv6. That's the most significant difference So, I don't see lw4over6 provisioning more complicated than MAP... Current MAP = operating DHCPv6 l24over6 = operating DHCPv4 and DHCPv6 + mechanisms to get to the DHCPv4 server over IPv6 There appears to be some evident complication there, for no clear benefit. -Woj. ___ 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/7, mohamed.boucad...@orange.com mohamed.boucad...@orange.com: Dear Dapeng, Please see inline. Cheers; Med -Message d'origine- De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la part de liu dapeng Envoyé : mardi 5 juin 2012 10:49 À : Yong Cui Cc : softwires@ietf.org Objet : Re: [Softwires] WG last call on draft-ietf-softwire-stateless-4v6-motivation-01 Hello all, I am not sure this version resolves my concerns regarding the possible misleading by the word stateless. To avoid this misleading, I suggest the following changes: 1. Change the title to Motivations for Carrier-side Stateless IPv4 over IPv6 Migration Solutions. Since this document is mainly about carrier-side stateless, the new title is more precise to reflect the content of this document. Med: Done. I updated my local copy with the proposed title. == Thanks 2. Add a subsection in introduction, clarify that this document is only about carrier side stateless. 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. --- Thanks, Best regards, Dapeng Liu I would like to support it if the document was updated accordingly. Thanks. -- -- 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
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? ___ 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
Peng, 2012-06-07 à 16:04, Peng Wu: Hi Ole and all, Thank you all for the discussions on this topic, as well as sharing your opinions during the offline discussions in the last couple of days. Let me try to summarize. I understand that we MAY adapt MAP to be 4over6-like, or even DS-lite with more changes. It's actually a very interesting proposal. However, in my understanding, the advantage of MAP is built on its statelessness, with of cost of v4-v6 address coupling. If we mandate MAP to further include the features of 4over6/DS-lite, we lose its original generality: it's no longer stateless, the motivation document won't work; GMA algorithm is no longer needed, no rule provisioning anymore; we enforce a big bindng table on MAP BR. These are somehow signifcant changes in implmentaton and deployement. Now there are actually 3 directions for IPv4-over-IPv6 mechanisms, they have respective application scenarios, pros and cons. 1)stateless, 4rd, MAP Thank you for having not forgotten that 4rd and MAP are on equal footing in Softwire, something that seems to be forgotten more than needed on this discussion thread. Incidentally, while the WG draft on 4rd has been available since May 16, the MAP specification, which was claimed in Paris to be well stabilized, already tested, and urgent to be published, is still not available as a WG draft. I therefore believe that discussing relationship between MAP and/or 4rd and 4over6 would be more useful when an up-to-date MAP specification is available. In any case, I renew my support for Public 4over6 to progress autonomously. Regards, RD 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. Cheers, Peng On Thu, Jun 7, 2012 at 4:48 PM, Ole Trøan otr...@employees.org wrote: Qiong, If public 4over6 is one extreme case of MAP, in which one subscriber represents one MAP domain, then should we also say that DS-Lite is another extreme case of MAP, where one application (session) represents one MAP domain ? a DS-lite AFTR could be represented by the combination of a MAP BR with per subscriber rules combined with a NAT44. there is a reason we started out calling MAP for Stateless DS-lite. I think we should still keep the initial feature of these solutions. all the proposed solutions, including DS-lite shares a large set of commonalities. where the differences are more operational considerations and deployment choices than technical differences. do we need a separate protocol specification for each deployment choice? 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-dslite-multicast-02
Re-,
On 6/5/2012 Tuesday 9:09 PM, Simon Perreault wrote:
On 2012-06-04 22:13, Jacni Qin wrote:
Section 6.1 introduces IGMP/MLD translation, but I fear it is very
underspecified. Our own effort at specifying IGMP/MLD translation is
in draft-perreault-mboned-igmp-mld-translation. I feel that DS-Lite
multicast would be better served by referencing our draft instead.
Thanks for your comments, while as stated in the text, the Interworking
function is a combination of proxying (RFC4605) and translation
(draft-ietf-mboned-64-multicast-address-format, sorry the reference was
lost, we'll fix it).
I understand that. But note that this is an important new function.
AFAIK IGMP/MLD translation doesn't exist in any other RFC. Your draft
would be underspecifying it IMHO, possibly leading to interoperability
issues.
To be honest, we've ever considered a separate draft to specify that
function, but we finally dropped it in the last moment before
submitting, since we realized during the preparation for the Demo in
Taipei that it's actually not a new function, nor needs to be
standardized anywhere, but more belongs to the scope of implementation.
The implements vary, one example could be: have both IPv4 and IPv6
membership database maintained, then just synchronize the two through
the address translation, all other things can be handled by the Proxying
functionality (RFC4605).
I don't think it's up to SOFTWIRE to standardize IGMP/MLD translation.
The implementations vary, and we are trying to avoid deeply diving into
that since it is sufficient for the implementers, and those should be
detailed in some deployment document if needed. Anyway, please list what
you think is missing, we can add more text to further clarify it. Thanks
a lot!
At IETF 83 I showed this list to the PIM working group to demonstrate
that IGMP/MLD translation is not as simple as people think it is. It's
a list of things our draft
(draft-perreault-mboned-igmp-mld-translation) specifies:
- Well-known multicast address equivalences between IPv4 and IPv6.
- Message type equivalences between IGMPv{1,2,3} and MLDv{1,2}.
- Translation needs to be performed logically on upstream interface of
proxy so as not to mess with Querier elections.
- Router Alert
- IPv4 option ? Hop-by-Hop IPv6 extension header
- Send on output IFF it was received on input.
- Set value to zero unconditionally.
- Reports with unspecified source address need to be handled
differently for IGMP vs MLD.
- Allocation of a Translated bit in IGMPv3 and MLDv2 Queries and
Reports.
- Formulas for the conversion of MRD?MRT with or without loss of
precision.
- Preservation of Additional and Auxiliary Data.
- MTU considerations... sigh
- Data plane handled according to RFC6145.
You are doing a protocol translation, which is just one possible kind of
implementations, and it's true that what you list above are required if
you want to go this way, IMHO it is a complicated one.
As mentioned earlier, RFC4605 plus the address translation can also do
that. And most columns you list will be avoid.
While I'm happy to see a deployment document to discuss the issues of
implementations.
Cheers,
Jacni
___
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, 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-dslite-multicast-02
On 6/8/2012 8:34 AM, Behcet Sarikaya wrote: 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. As this draft shows though, one can provide multicast in a DS-Lite environment in an entirely generic way. I think that is great. It's much better to have a general solution. But this means the draft should be modified to reflect that. It is great to have a draft describing this. Whether charter or not or where it belongs is something I'm sure can be figured out. Right now I'm more concerned about getting a good document. Stig 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 Venaass...@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 ___ 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
Med, I'm glad we are in synch. That's exactly what I suggested Peng to do it. We can a single sentence in L46 to the effect: If a full public IPv4 is given through DHCP no port set support is needed on CPE or concentrator. It is still up to the CPE if it wants to do NAT or not. Many DC scenarios use 1:1 NAT. Even DS-Lite can support public servers by using full port range port forwarding and disabling NAT. Thanks, Reinaldo On 6/7/12 10:58 PM, mohamed.boucad...@orange.com mohamed.boucad...@orange.com wrote: Hi Peng, I vote for having one single document which covers both shared and full IPv4 address. If you start for instance from draft-cui-softwire-b4-translated-ds-lite, what is needed is to add one sentence to say a full IPv4 address can be provisioned. Does this make draft-cui-softwire-b4-translated-ds-lite more complex? I don't think so. I really think we need all to do an effort of rationalizing the solutions space. Cheers, Med -Message d'origine- De : Peng Wu [mailto:pengwu@gmail.com] Envoyé : jeudi 7 juin 2012 18:31 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : Yong Cui; softwires@ietf.org Objet : Re: [Softwires] WG last call on draft-ietf-softwire-public-4over6-01 Med, From protocol level, the difference between public 4over6 and lightweight 4over6(b4-translated-ds-lite) lies in port-set support. The extra efforts of lw 4over6 are as follows: (1) port set support in DHCP provisioning; (2) NAT on the initiator side.(whose address pool is not a full address but only a port set) (3) port-set supporting in the cocentrator's binding table. While we may cover public 4over6 by lightweight 4over6 with a special port set format (2^16 size) for (3), (1) and (2) brings quite significant changes to the intiator side. If I'm only a pb 4over6 initiator, more typically a host initiator, all the complexity needed is to plant a CRA process on the host, which is basically an IPv4 IPv6 socket function, to support DHCPv4-over-IPv6. The rest is already there: we don't need to modify DHCP client, and IPv4-in-IPv6 tunnel is already supported in today's OS. No NAT is needed in host case, and full e2e transparency is guaranteed. If we support this by lw 4over6, we implemented extra complexity which is not needed at all by the initiator. We have deployement scenarios which probably don't require address sharing, such as CERNET, and I guess maybe the ISPs in USA also do not have an IPv4 address shortage problem? So, aside from the fact that the pb 4over6 draft starts earlier and its status has been a step furher, this is a problem of choice: do we want two clean, simple mechanisms, or one mechanism trying to be compatible with both. On Thu, Jun 7, 2012 at 9:11 PM, mohamed.boucad...@orange.com wrote: Dear all, I agree with Reinaldo. IMHO it makes sense to merge the two documents: either draft-ietf-softwire-public-4over6 be extended to cover draft-cui-softwire-b4-translated-ds-lite or add one or two sentences to draft-cui-softwire-b4-translated-ds-lite to mention a non-shared IPv4 address may be assigned. Doing so would help to rationalize the solution space and associated documents. We have the following main flavours: (1) Full stateful mode: DS-Lite (2) Full stateless mode: MAP (3) Per-customer state/binding mode: lw4o6 (draft-cui-softwire-b4-translated-ds-lite) All the three modes must support the ability to assign a full IPv4 address. Cheers, Med -Message d'origine- De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la part de Reinaldo Penno Envoyé : lundi 28 mai 2012 07:53 À : Sheng Jiang; Yong Cui; softwires@ietf.org Objet : Re: [Softwires] WG last call on draft-ietf-softwire-public-4over6-01 -1 In which significant way this document is different from http://tools.ietf.org/html/draft-cui-softwire-b4-translated-ds- lite-06 ? We can insert one paragraph in the above draft and allow public IPs since NAT is optional. The two documents even use DHCPv4ov6 as provisioning. On 5/27/12 6:32 PM, Sheng Jiang jiangsh...@huawei.com wrote: The document looks mature for being advanced. Sheng Jiang -Original Message- From: softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] On Behalf Of Yong Cui Sent: Sunday, May 27, 2012 10:31 PM To: softwires@ietf.org Cc: Yong Cui Subject: [Softwires] WG last call on draft-ietf-softwire-public-4over6- 01 Hi folks, This is a wg last call on draft-ietf-softwire-public-4over6-01. http://datatracker.ietf.org/doc/draft-ietf-softwire-public-4over6/ As usual, please send editorial comments to the authors and substantive comments to the mailing list. This wg last call will end on 2012 June 10 at 12pm EDT. Yong Alain ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org
Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02
On Fri, Jun 8, 2012 at 11:58 AM, Stig Venaas s...@venaas.com wrote: On 6/8/2012 8:34 AM, Behcet Sarikaya wrote: 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. As this draft shows though, one can provide multicast in a DS-Lite environment in an entirely generic way. I think that is great. It's much better to have a general solution. But this means the draft should be modified to reflect that. It is great to have a draft describing this. A general solution using translation won't simply cut it for DS-Lite which is a tunneling protocol. No matter how hard you try. Behcet ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
[Softwires] I-D Action: draft-ietf-softwire-map-00.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 : 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
Re: [Softwires] WG last call on draft-ietf-softwire-public-4over6-01
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. 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
Re: [Softwires] WG last call on draft-ietf-softwire-public-4over6-01
Hi Reinado, IMHO, both MAP(Mapping of Address and PORT ) and lw4over6 DO NOT design to deal with full Ipv4 address case originally. In many senarios, users(like campanies, governments, ICPs and so on ) JUST want full addresses instead of shared addresses. It is more reasonable to have Public 4over6 to handle this. And Public 4over6 is matual enough to step forward without technical changes. Best Regards! Qi Sun On 6/9/12, Reinaldo Penno repe...@cisco.com wrote: Med, I'm glad we are in synch. That's exactly what I suggested Peng to do it. We can a single sentence in L46 to the effect: If a full public IPv4 is given through DHCP no port set support is needed on CPE or concentrator. It is still up to the CPE if it wants to do NAT or not. Many DC scenarios use 1:1 NAT. Even DS-Lite can support public servers by using full port range port forwarding and disabling NAT. Thanks, Reinaldo On 6/7/12 10:58 PM, mohamed.boucad...@orange.com mohamed.boucad...@orange.com wrote: Hi Peng, I vote for having one single document which covers both shared and full IPv4 address. If you start for instance from draft-cui-softwire-b4-translated-ds-lite, what is needed is to add one sentence to say a full IPv4 address can be provisioned. Does this make draft-cui-softwire-b4-translated-ds-lite more complex? I don't think so. I really think we need all to do an effort of rationalizing the solutions space. Cheers, Med -Message d'origine- De : Peng Wu [mailto:pengwu@gmail.com] Envoyé : jeudi 7 juin 2012 18:31 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : Yong Cui; softwires@ietf.org Objet : Re: [Softwires] WG last call on draft-ietf-softwire-public-4over6-01 Med, From protocol level, the difference between public 4over6 and lightweight 4over6(b4-translated-ds-lite) lies in port-set support. The extra efforts of lw 4over6 are as follows: (1) port set support in DHCP provisioning; (2) NAT on the initiator side.(whose address pool is not a full address but only a port set) (3) port-set supporting in the cocentrator's binding table. While we may cover public 4over6 by lightweight 4over6 with a special port set format (2^16 size) for (3), (1) and (2) brings quite significant changes to the intiator side. If I'm only a pb 4over6 initiator, more typically a host initiator, all the complexity needed is to plant a CRA process on the host, which is basically an IPv4 IPv6 socket function, to support DHCPv4-over-IPv6. The rest is already there: we don't need to modify DHCP client, and IPv4-in-IPv6 tunnel is already supported in today's OS. No NAT is needed in host case, and full e2e transparency is guaranteed. If we support this by lw 4over6, we implemented extra complexity which is not needed at all by the initiator. We have deployement scenarios which probably don't require address sharing, such as CERNET, and I guess maybe the ISPs in USA also do not have an IPv4 address shortage problem? So, aside from the fact that the pb 4over6 draft starts earlier and its status has been a step furher, this is a problem of choice: do we want two clean, simple mechanisms, or one mechanism trying to be compatible with both. On Thu, Jun 7, 2012 at 9:11 PM, mohamed.boucad...@orange.com wrote: Dear all, I agree with Reinaldo. IMHO it makes sense to merge the two documents: either draft-ietf-softwire-public-4over6 be extended to cover draft-cui-softwire-b4-translated-ds-lite or add one or two sentences to draft-cui-softwire-b4-translated-ds-lite to mention a non-shared IPv4 address may be assigned. Doing so would help to rationalize the solution space and associated documents. We have the following main flavours: (1) Full stateful mode: DS-Lite (2) Full stateless mode: MAP (3) Per-customer state/binding mode: lw4o6 (draft-cui-softwire-b4-translated-ds-lite) All the three modes must support the ability to assign a full IPv4 address. Cheers, Med -Message d'origine- De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la part de Reinaldo Penno Envoyé : lundi 28 mai 2012 07:53 À : Sheng Jiang; Yong Cui; softwires@ietf.org Objet : Re: [Softwires] WG last call on draft-ietf-softwire-public-4over6-01 -1 In which significant way this document is different from http://tools.ietf.org/html/draft-cui-softwire-b4-translated-ds- lite-06 ? We can insert one paragraph in the above draft and allow public IPs since NAT is optional. The two documents even use DHCPv4ov6 as provisioning. On 5/27/12 6:32 PM, Sheng Jiang jiangsh...@huawei.com wrote: The document looks mature for being advanced. Sheng Jiang -Original Message- From: softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] On Behalf Of Yong Cui Sent: Sunday, May 27, 2012 10:31 PM To: softwires@ietf.org Cc: Yong Cui Subject: [Softwires] WG last call on draft-ietf-softwire-public-4over6- 01 Hi folks, This is a wg last call on draft-ietf-softwire-public-4over6-01.
