Re: [Softwires] Comment about draft-dhankins-softwire-tunnel-option
Dear Dave, all, I'm not talking about that, but when I don't want to add any entry to my DNS due to some reasons (avoid extra configuration task of DNS for instance.) Cheers, Med -Message d'origine- De : Dave Thaler [mailto:dtha...@microsoft.com] Envoyé : lundi 16 novembre 2009 23:54 À : BOUCADAIR Mohamed NCPI/NAD/TIP; softwires@ietf.org Objet : RE: Comment about draft-dhankins-softwire-tunnel-option You can resolve an FQDN to a list of IPv6 addresses, so it seems to already provide that ability just with an FQDN. -Dave -Original Message- From: softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] On Behalf Of mohamed.boucad...@orange-ftgroup.com Sent: Monday, November 16, 2009 5:34 AM To: softwires@ietf.org Subject: [Softwires] Comment about draft-dhankins-softwire-tunnel- option Dear authors, all, The current version of the draft defines a single option which is used to convey one FQDN pointing to a DS-lite CGN. The use of FQDN may have several advantages compared to a plain IPv6 address such as enabling DNS-based load distribution among a set of CGN devices. Nevertheless, this should not preclude to define an option to convey a (list) of IPv6 address instead of FQDN. It is up to the service providers to decide whether enclosing an IP address or a FQDN in the ds-lite DHCP option is more appropriate in their contexts. Is there any reason why the draft defines only the FQDN option? Cheers, Med * 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. * 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
[Softwires] Widthraw an AFTR from the path (draft-boucadair-softwire-cgn-bypass)
Dear all, Please find below a link to a new submitted draft which aims to avoid involving several AFTR devices in the path. A procedure is proposed to withdraw an AFTR from the path. Comments are more than welcome. Cheers, Med -Message d'origine- De : i-d-announce-boun...@ietf.org [mailto:i-d-announce-boun...@ietf.org] De la part de internet-dra...@ietf.org Envoyé : mercredi 16 décembre 2009 17:30 À : i-d-annou...@ietf.org Objet : I-D Action:draft-boucadair-softwire-cgn-bypass-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Procedure to bypass DS-lite AFTR Author(s) : M. Boucadair Filename: draft-boucadair-softwire-cgn-bypass-00.txt Pages : 16 Date: 2009-12-16 This document proposes a solution to avoid the use of two stateful CGN (a.k.a., AFTR in [I-D.ietf-softwire-dual-stack-lite]) devices when both participants (a.k.a., B4 element) are located behind different CGN devices. For this purpose a new IPv6 extension header, called Tunnel Endpoint Extension Header (TEEH), is defined. The proposed procedure encourages the use of IPv6 between AFTR nodes as a means to avoid the unnecessary crossing of AFTR devices. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-boucadair-softwire-cgn-bypass-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. * 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. message/external-body; name="draft-boucadair-softwire-cgn-bypass-00.url": Unrecognized ___ 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?
Dear Sri, Thank you for answers. Please see inline. Cheers, Med -Message d'origine- De : Sri Gundavelli [mailto:sgund...@cisco.com] Envoyé : mardi 11 mai 2010 23:31 À : BOUCADAIR Mohamed NCPI/NAD/TIP; Cameron Byrne Cc : softwires@ietf.org; BINET David NCPI/NAD/TIP Objet : Re: [Softwires] GI-DS-lite as working group item? Hi Mohamed: Sorry for the late response. We were not inclined to take the draft adoption call to a discussion thread and hence the silence. Please see below. You asked number of questions and all of those points were analyzed during the IPv6 migration discussions and surely not in isolation, this was attended by practically all the vendors and mobile operators. Two major workshops were conducted to discuss the IPv6 migration issues in mobile architectures. Its unfortunate, we missed you there. Med: Since the request come from 3GPP, the applicability of the solution SHOULD NOT be beyond that scope. Furthermore, the draft should at least provide a background on the main recommendations of 3GPP SI: DS and IPv6-only and that the proposal can be used in that context. GI-DS-LITE is not mentioned anywhere that it is a MANDATORY functional block. Please also see the report from the 3GPP-IETF workshop. The workshop identified GI-DS-lite as a useful tool in some configurations. Its not the only tool, but it is one of the tools along with NAT64, useful in the IPv6 migration toolkit. Med: Again, I would like to understand how this is a migration tool to IPv6. Migrate means moving to IPv6-only scheme? How this is supported in GI-DS-Lite? How you allow to offload NAT44 nodes and use IPv6? Now to this draft. The mechanism defined in GI-DS-lite draft allows us to apply dual-stack lite approach to mobile architectures, resulting in the following benefits. Med: The context SHOULD be mentioned clearly in the document: Mobile+DS. All fixed use case should be removed. 1.) Solves the IPv4 address exhaust issue in mobile networks. Med: Not specific to GI-DS-Lite 2.) Contains IPv4 to a state only in the end-point and in the CGN function. Still allowing the end-points to access IPv4 services Med: Not specific to GI-DS-Lite 3.) Provides the deployment option to move the CGN function from the gateway and move it to the edge of the SP network. Med: In some deployments, the NAT function is already provided in the edge of the PLMN not in the gateway. Usually, it is hosted together with a firewall device. Removing traces of IPv4 and allowing the gateway to perform packet forwarding without using IPv4 routing state. The side affect of this is that the operator is not required to segment IPv4 public address space across gateways and that is a key benefit with respect to provisioning and for efficient address space management. Med: This is an engineering option and not a STANDARD-in-the-stone issue. IPv4 address pools can be re-used per ggsn/pgw also and therefore, there is no modification required to the gateway, right? 4.) Allows the operator to migrate various parts of the mobile network to IPv6, in parts, EPC core, or the network Sgi. Med: How Gi-ds-lite allows for this? 5.) There are no changes to the end-point, unlike the other proposals that were discussed which provide the solution for the same problem set. No tunnel setup from the UE, no software grade and no additional overhead. Med: Again, this is not specific to GI-DS-Lite. Other ***configuration allows for this: * co-located NAT in the gw * dedicated NAT with routing/forwarding configuration in the gateway to reach its CGN * NAT in the boundary of the PLMN I don't have any issue with mentioning that gi-ds-lite is an option but I admit I'm not comfortable with seeing the IETF prefers a solution against other without any analysis of the alternative solutions. Please see below. On 5/7/10 2:24 AM, mohamed.boucad...@orange-ftgroup.com mohamed.boucad...@orange-ftgroup.com wrote: Dear Cameron, all, GI-DSLite does not define any protocol but an architecture where a tunnel is used together with a new enhanced NAT44 table (because more de-multiplexing information than for basic NAT44 table is required). So, what should be standardised there? (1) The behaviour of the gateway? Yes. The gateway is responsible for forwarding UE's IPv4 packets. It needs to ensure proper UE specific context identifiers are carried in the tunnel headers. The specifics on how the gateway handles this function, how it makes the forwarding decision needs to be standardized. Med: These modifs belong to 3GPP Specs and not the IETF. What is needed from the IETF? (2) The tunnel establishment procedure? This is an operational consideration as a matter of fact. In addition, the tunnel is not required in the majority of the scenarios. Normal routing actions can be done in the gateway to redirect the traffic to the appropriate CGN. I don't see a deployment context where more that +16M UEs (or Access Devices) will be serviced by
Re: [Softwires] GI-DS-lite as working group item?
Re-, Please see inline. Cheers; Med -Message d'origine- De : Sri Gundavelli [mailto:sgund...@cisco.com] Envoyé : mercredi 12 mai 2010 09:12 À : BOUCADAIR Mohamed NCPI/NAD/TIP Cc : softwires@ietf.org Objet : Re: [Softwires] GI-DS-lite as working group item? Hi Mohamed, Please see inline. Med: Since the request come from 3GPP, the applicability of the solution SHOULD NOT be beyond that scope. Furthermore, the draft should at least provide a background on the main recommendations of 3GPP SI: DS and IPv6-only and that the proposal can be used in that context. GI-DS-LITE is not mentioned anywhere that it is a MANDATORY functional block. This can be a compromise. Surely, the primary motivation is mobile architectures. We can discuss on the applicability note. Med: Ok. Please also see the report from the 3GPP-IETF workshop. The workshop identified GI-DS-lite as a useful tool in some configurations. Its not the only tool, but it is one of the tools along with NAT64, useful in the IPv6 migration toolkit. Med: Again, I would like to understand how this is a migration tool to IPv6. Migrate means moving to IPv6-only scheme? How this is supported in GI-DS-Lite? How you allow to offload NAT44 nodes and use IPv6? I think I've answered this question. UEPGWCGNinternet For a mobile operator to transition to IPv6-only core (both EPC and Sgi), there are three migration points. The 3GPP EPC architecture allows the UE-PGW to have IPv6-only support, the GI-DS-lite tunnel between the PGW and the CGN (IPv6-GRE encap) will allow IPv6-only transport network, still enabling access to IPv4 services. This will result in an operator network that is entire IPv6-only. So, this is the Migrate option that this mechanism allows, which leads to an IPv6 only operator network. 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? Now to this draft. The mechanism defined in GI-DS-lite draft allows us to apply dual-stack lite approach to mobile architectures, resulting in the following benefits. Med: The context SHOULD be mentioned clearly in the document: Mobile+DS. All fixed use case should be removed. 1.) Solves the IPv4 address exhaust issue in mobile networks. Med: Not specific to GI-DS-Lite It is GI-DS-lite that is allowing this configuration. Sure, the approach is based on DS-lite. GI-DS-lite is an extension to DS-lite applicable to tunnel-based access architectures. So, it is specific to GI-DS-lite in this context. Applying DS-lite as it is will result in additional tunnel, that is the optimization. Med: My point was that any NAT-based solution allows to mitigate the address shortage. 2.) Contains IPv4 to a state only in the end-point and in the CGN function. Still allowing the end-points to access IPv4 services Med: Not specific to GI-DS-Lite Same response as above. Med: See my answers above ;-) 3.) Provides the deployment option to move the CGN function from the gateway and move it to the edge of the SP network. Med: In some deployments, the NAT function is already provided in the edge of the PLMN not in the gateway. Usually, it is hosted together with a firewall device. That is going with the assumption that we are running IPv4 between the edge of the PLMN and the gateway. The GI-DS-lite tunnel allows an IPv6 only network between those points. Med: I understand that you are claiming that gi-ds-lite benefit is only when it is deployed with IPv6 tunnelling scheme. Right? Removing traces of IPv4 and allowing the gateway to perform packet forwarding without using IPv4 routing state. The side affect of this is that the operator is not required to segment IPv4 public address space across gateways and that is a key benefit with respect to provisioning and for efficient address space management. Med: This is an engineering option and not a STANDARD-in-the-stone issue. IPv4 address pools can be re-used per ggsn/pgw also and therefore, there is no modification required to the gateway, right? The same private address space can be used across gateways. But, that requires static provisioning of public address space. When you dont want to do that segmentation of public pools across gateways, this solution can be useful. Both the options are fine, based on the deployment choice. Med: You agree that this is an operational consideration. Why then this document is in the standard track? Information would be enough. 4.) Allows the operator to migrate various parts of the mobile network to IPv6, in parts, EPC core, or the network Sgi. Med: How Gi-ds-lite allows for this? Explained earlier with an illustration. Med: Your answer does not address this. Not sure I got how you can offload the traffic from NAT44 to a NAT64 for instance. What you are proposing can apply with the co-located model for
Re: [Softwires] GI-DS-lite as working group item?
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:yiu_...@cable.comcast.com] Envoyé : mardi 18 mai 2010 03:07 À : BOUCADAIR Mohamed NCPI/NAD/TIP; Sri Gundavelli Cc : softwires@ietf.org 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 Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] GI-DS-lite as working group item?
Hi Yiu, Please see inline. Cheers, Med -Message d'origine- De : Lee, Yiu [mailto:yiu_...@cable.comcast.com] Envoyé : mardi 18 mai 2010 21:58 À : BOUCADAIR Mohamed NCPI/NAD/TIP; Sri Gundavelli Cc : softwires@ietf.org Objet : Re: [Softwires] GI-DS-lite as working group item? Hi Med, I think we are on the same page. So your concern is the current draft didn't limit to the scale to 3gpp. IMHO, this draft suggests a way to use a tunnel-id to identify the client in AFTR. In this context, this doesn't limit the scale to 3gpp only. In theory any client using tunnel may use it (e.g. PPP). I don't now why IETF wants to limit it to 3gpp based deployment. Med: This is why I asked for a big picture view rather than a single solution. Please refer to my previous messages, I included links to http://tools.ietf.org/html/draft-miles-behave-l2nat-00 or http://tools.ietf.org/html/draft-arkko-dual-stack-extra-lite-00 for instance which are generic solutions. Should we define a generic table structure for all enhanced NAT tables? I don't see how this draft to suggest a centralized NAT. Can you show me any part in the draft may have suggested that? Med: This is the main argument of the draft: unavailability of sufficient private IPv4 addresses to service all UEs behind a CGN. The valid scenario for GI-DS-Lite is case (c) below which is a centralised model IMHO: (a) Co-located model: the NAT is co-located in the PGW/GGSN. No issue with private IPv4 addresses. GTP TID can be used as de-multiplexing factor if required. (b) 1:1 model: the CGN and the PGW/GGSN are not embedded in the same device. Each PGW/GGSN is configured how to reach its attached CGN. There is no private IPv4 @ depletion problem. (c) N:1 model: a single CGN serve a group of PGW/GGSN. Indeed, having +16M of customers is a valid case (centralised model) Does this make sense for you? Yes, if an operator wants to use a giant NAT, this draft won't stop it. But this draft doesn't suggest it either. Like what you said, this is deployment issue, not the spec enforcing it. As far as proposing IPv6, I agree the draft can put more words on it. I will try to work with the authors off-line to suggest some text to them. Med: Hope to see there how Gi-DS-lite is a migration tool for IPv6. Cheers, Yiu On 5/18/10 3:48 AM, mohamed.boucad...@orange-ftgroup.com mohamed.boucad...@orange-ftgroup.com wrote: 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:yiu_...@cable.comcast.com] Envoyé : mardi 18 mai 2010 03:07 À : BOUCADAIR Mohamed NCPI/NAD/TIP; Sri Gundavelli Cc : softwires@ietf.org 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,
[Softwires] RE : DNS question about DS-lite
Dear Jacni, Please see inline. Cheers, Med De : softwires-boun...@ietf.org [softwires-boun...@ietf.org] de la part de Jacni Qin [jac...@gmail.com] Date d'envoi : jeudi 27 mai 2010 17:54 À : Lee, Yiu Cc : Durand, Alain; softwires@ietf.org Objet : Re: [Softwires] DNS question about DS-lite On Thu, May 27, 2010 at 1:00 AM, Lee, Yiu yiu_...@cable.comcast.commailto:yiu_...@cable.comcast.com wrote: If the B4 is in the host, the B4 implementation should be able to proxy the v4 DNS request over v6. Or B4 tunnels the DNS message and sends to a v4 DNS server (less desirable). -- while as mentioned in the draft, currently there is no option defined for passing the v4 DNS server address to hosts. Med: If you really want to provision an IPv4 address of the DNS server, you can inspire from what we proposed for PCP: http://tools.ietf.org/html/draft-bpw-softwire-pcp-dhcp-01#section-3.1 and convey an IP4-mapped IPv6 address (representing the IPv4 address of your DNS server) in the DHCPv6 option. BTW, it is recommended to send DNS queries over IPv6 to avoid crossing the AFTR for various reasons (avoid nating DNS messages, better ports usage in the AFTR since DNS traffic represents an important amount of messages issued by various applications, incremental migration of network services to IPv6: DNS and NTP for instance). * 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
[Softwires] TR: I-D Action:draft-lee-6man-ra-dslite-00.txt
Dear all, FYI, we have submitted this new I-D. Comments, critiques, suggestions and questions are more than welcome. As mentioned in the draft, the provisioning of the AFTR is a very sensitive for the delivery of the IPv4 connectivity when DS-Lite is enabled. Any failure to provision such information means the failure for the delivery of IPv4 services. Furthermore, the availability of the IPv4 connectivity services does not depend on the availability of DHCPv6 or RADIUS servers. The draft includes in the appendix a use case for further discussion: distribute DS-Lite serviced customers among a set of deployed AFTRs. Provisioning the AFTR with an RA option simplifies this task and removes a constraint on DHCPv6 servers (no need to know where the customer is connected from). Off-line tools can be used instead for tuning the content of the information to be conveyed in an RA option. This use case has been included in the I-D to discuss whether it is a valid use case or not. We will move this use case to the core text if it is believed to be a valid scenario. Cheers, Med -Message d'origine- De : i-d-announce-boun...@ietf.org [mailto:i-d-announce-boun...@ietf.org] De la part de internet-dra...@ietf.org Envoyé : mardi 28 septembre 2010 08:00 À : i-d-annou...@ietf.org Objet : I-D Action:draft-lee-6man-ra-dslite-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IPv6 RA Option for DS-Lite AFTR Element Author(s) : Y. Lee, M. Boucadair Filename: draft-lee-6man-ra-dslite-00.txt Pages : 8 Date: 2010-09-27 This document specifies a new optional extension to IPv6 Router Advertisement to allow IPv6 routers to advertise DS-Lite AFTR addresses to IPv6 hosts. The provisioning of the AFTR information is crucial to access IPv4 connectivity services in a DS-Lite context. Means to ensure reliable delivery of this information to connecting hosts is a must. Furthermore, this RA option can be used as a means to distribute DS- Lite serviced customers among a set of deployed AFTRs without requiring a central knowledge of the underlying topology and deployed AFTRs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-lee-6man-ra-dslite-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. * 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. message/external-body; name="draft-lee-6man-ra-dslite-00.url": Unrecognized ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] DHCPv6 AFTR name option is needed
Dear Tomek, Thank you for this clarification. Providing the IP address in the option is not flexible enough and especially it may not be recommended to achieve load balancing. Otherwise the DHCPv6 server should act as a load balancer, which is not currently our preference. To illustrate more the usage with the domain name option: The scenario I mentioned (is similar to what currently done in some VoIP networks for distributing customers among SBC nodes or P-CSCFs): you provide a generic FQDN of the AFTR by the DHCP server together with a suffix in the dns serach list option. When the B4 receives these two options, it will form a the FQDN to use to resolve its AFTR. Then a query is sent to the DNS system (it can be dedicated to the service), and based on the load considerations, the requesting client is redirected to the appropriate AFTR nodes (i.e., an IP address is returned). With the sole IP address option we can not have such engineering flexibility for the provisioning of the AFTR. Having the two options allow for more flexibility for the engineering. IMHO, the IETF should not impose engineering choice to SPs. It will be up to each service provider to decide whether an IP address or a FQDN is more convenient in his deployment context. Hope this clarifies our concern. Cheers, Med De : Tomasz Mrugalski [mailto:tomasz.mrugal...@gmail.com] Envoyé : vendredi 8 octobre 2010 02:00 À : Softwires WG Cc : BOUCADAIR Mohamed NCPI/NAD/TIP; draft-ietf-softwire-ds-lite-tunnel-opt...@tools.ietf.org; Softwire Chairs; Ullio Mario; Jari Arkko; Ralph Droms; Maglione Roberta Objet : Re: [Softwires] DHCPv6 AFTR name option is needed Roberta, Mohamed, AFTR name option was removed as a result of a concerns raised by Jari Arkko and Ralph Droms during IESG review. They were very clear that defining two options to configure the same parameter is not acceptable. Regarding scenario mentioned by Mohamed, since you are already differentiating between different locations (as I understand in your scenario different locations provide different DNS addresses that resolve the same AFTR FQDN to different addresses, right?), you may do this explicitly and provide different AFTR addresses. Would that solve the problem? Hope that helps. Tomek On Thu, Oct 7, 2010 at 4:58 PM, Maglione Roberta roberta.magli...@telecomitalia.itmailto:roberta.magli...@telecomitalia.it wrote: Hello All, I fully agree with Med, both AFTR IP address and AFTR name options are needed, in order to be able to handle different scenarios. We really would like to see both of them back in the draft. Best regards, Roberta -Original Message- From: softwires-boun...@ietf.orgmailto:softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.orgmailto:softwires-boun...@ietf.org] On Behalf Of mohamed.boucad...@orange-ftgroup.commailto:mohamed.boucad...@orange-ftgroup.com Sent: giovedì 7 ottobre 2010 10.07 To: draft-ietf-softwire-ds-lite-tunnel-opt...@tools.ietf.orgmailto:draft-ietf-softwire-ds-lite-tunnel-opt...@tools.ietf.org; Softwire Chairs Cc: softwires@ietf.orgmailto:softwires@ietf.org Subject: [Softwires] DHCPv6 AFTR name option is needed Dear authors, chairs, We are surprised to see the AFTR name option being removed from the latest version of this draft: http://tools.ietf.org/rfcdiff?url2=draft-ietf-softwire-ds-lite-tunnel-option-05.txt Is there any reason why this option has been removed? We would like to see this option back to the draft and that *** both *** the AFTR IP address and the name options are defined. FWIW, one of the deployment use cases we are considering is the distribution of the DS-Lite serviced customers among several (geo distributed) AFTRs by combining the search domain name dhcpv6 option (Code 24) and a generic FQDN conveyed in the AFTR name option. This would allow for a more controlled load distribution among deployed AFTRs. Cheers, Med -Message d'origine- De : softwires-boun...@ietf.orgmailto:softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.orgmailto:softwires-boun...@ietf.org] De la part de internet-dra...@ietf.orgmailto:internet-dra...@ietf.org Envoyé : lundi 27 septembre 2010 21:30 À : i-d-annou...@ietf.orgmailto:i-d-annou...@ietf.org Cc : softwires@ietf.orgmailto:softwires@ietf.org Objet : [Softwires] I-D Action:draft-ietf-softwire-ds-lite-tunnel-option-05.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 : Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Option for Dual- Stack Lite Author(s) : D. Hankins, T. Mrugalski Filename: draft-ietf-softwire-ds-lite-tunnel-option-05.txt Pages : 6 Date: 2010-09-27 This document specifies single DHCPv6 option which is meant to be used by a Dual-Stack Lite client (Basic Bridging BroadBand
Re: [Softwires] DHCPv6 AFTR name option is needed
Hi Yiu, all, If there is a real issue with defining two DHCPv6 options (which I don't see), an alternative would be to define one option with a sub-code field. This field indicates whether the option carries an IP address or a name option. Cheers, Med De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la part de Yiu L. Lee Envoyé : vendredi 8 octobre 2010 16:55 À : Tomasz Mrugalski; Softwires WG Cc : draft-ietf-softwire-ds-lite-tunnel-opt...@tools.ietf.org; Softwire Chairs; Ullio Mario Objet : Re: [Softwires] DHCPv6 AFTR name option is needed How about define a new option just for FQDN? Will this address the IESG's concern? On 10/7/10 11:24 PM, Tomasz Mrugalski tomasz.mrugal...@gmail.com wrote: Roberta, Mohamed, AFTR name option was removed as a result of a concerns raised by Jari Arkko and Ralph Droms during IESG review. They were very clear that defining two options to configure the same parameter is not acceptable. Regarding scenario mentioned by Mohamed, since you are already differentiating between different locations (as I understand in your scenario different locations provide different DNS addresses that resolve the same AFTR FQDN to different addresses, right?), you may do this explicitly and provide different AFTR addresses. Would that solve the problem? Hope that helps. Tomek On Thu, Oct 7, 2010 at 11:58 AM, Maglione Roberta roberta.magli...@telecomitalia.it wrote: Hello All, I fully agree with Med, both AFTR IP address and AFTR name options are needed, in order to be able to handle different scenarios. We really would like to see both of them back in the draft. Best regards, Roberta -Original Message- From: softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] On Behalf Of mohamed.boucad...@orange-ftgroup.com Sent: giovedì 7 ottobre 2010 10.07 To: draft-ietf-softwire-ds-lite-tunnel-opt...@tools.ietf.org; Softwire Chairs Cc: softwires@ietf.org Subject: [Softwires] DHCPv6 AFTR name option is needed Dear authors, chairs, We are surprised to see the AFTR name option being removed from the latest version of this draft: http://tools.ietf.org/rfcdiff?url2=draft-ietf-softwire-ds-lite-tunnel-option-05.txt Is there any reason why this option has been removed? We would like to see this option back to the draft and that *** both *** the AFTR IP address and the name options are defined. FWIW, one of the deployment use cases we are considering is the distribution of the DS-Lite serviced customers among several (geo distributed) AFTRs by combining the search domain name dhcpv6 option (Code 24) and a generic FQDN conveyed in the AFTR name option. This would allow for a more controlled load distribution among deployed AFTRs. Cheers, Med -Message d'origine- De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la part de internet-dra...@ietf.org Envoyé : lundi 27 septembre 2010 21:30 À : i-d-annou...@ietf.org Cc : softwires@ietf.org Objet : [Softwires] I-D Action:draft-ietf-softwire-ds-lite-tunnel-option-05.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 : Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Option for Dual- Stack Lite Author(s) : D. Hankins, T. Mrugalski Filename: draft-ietf-softwire-ds-lite-tunnel-option-05.txt Pages : 6 Date: 2010-09-27 This document specifies single DHCPv6 option which is meant to be used by a Dual-Stack Lite client (Basic Bridging BroadBand element, B4) to discover its Address Family Transition Router (AFTR) address. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-softwire-ds-lite-tunnel-option-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. * 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 Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore
Re: [Softwires] DHCPv6 AFTR name option is needed
Dear Raplh, Do you suggest the I-D should elaborate further on the FQDN use cases so this to be acceptable by the IESG? Chairs, how should we proceed? The version which passed the WG LC is not the 05. Cheers, Med -Message d'origine- De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la part de Ralph Droms Envoyé : lundi 11 octobre 2010 20:46 À : draft-ietf-softwire-ds-lite-tunnel-opt...@tools.ietf.org Cc : Ullio Mario; Chairs Dhc; Softwire Chairs; Softwires Objet : Re: [Softwires] DHCPv6 AFTR name option is needed (Adding dhc WG chairs to the thread.) The client behavior in draft-ietf-softwire-ds-lite-tunnel-option-04 did not describe any mechanism in which the client would combine the FQDN from the tunnel option with a suffix in the search list option to form a new name to use as its AFTR, nor did it mention anything about the DNS system doing load balancing. Given the text in draft-ietf-softwire-ds-lite-tunnel-option-04, there is no advantage to sending an FQDN, so the spec should define only the IP address option. - Ralph On Oct 8, 2010, at 1:30 AM 10/8/10, mohamed.boucad...@orange-ftgroup.com mohamed.boucad...@orange-ftgroup.com wrote: Dear Tomek, Thank you for this clarification. Providing the IP address in the option is not flexible enough and especially it may not be recommended to achieve load balancing. Otherwise the DHCPv6 server should act as a load balancer, which is not currently our preference. To illustrate more the usage with the domain name option: The scenario I mentioned (is similar to what currently done in some VoIP networks for distributing customers among SBC nodes or P-CSCFs): you provide a generic FQDN of the AFTR by the DHCP server together with a suffix in the dns serach list option. When the B4 receives these two options, it will form a the FQDN to use to resolve its AFTR. Then a query is sent to the DNS system (it can be dedicated to the service), and based on the load considerations, the requesting client is redirected to the appropriate AFTR nodes (i.e., an IP address is returned). With the sole IP address option we can not have such engineering flexibility for the provisioning of the AFTR. Having the two options allow for more flexibility for the engineering. IMHO, the IETF should not impose engineering choice to SPs. It will be up to each service provider to decide whether an IP address or a FQDN is more convenient in his deployment context. Hope this clarifies our concern. Cheers, Med De : Tomasz Mrugalski [mailto:tomasz.mrugal...@gmail.com] Envoyé : vendredi 8 octobre 2010 02:00 À : Softwires WG Cc : BOUCADAIR Mohamed NCPI/NAD/TIP; draft-ietf-softwire-ds-lite-tunnel-opt...@tools.ietf.org; Softwire Chairs; Ullio Mario; Jari Arkko; Ralph Droms; Maglione Roberta Objet : Re: [Softwires] DHCPv6 AFTR name option is needed Roberta, Mohamed, AFTR name option was removed as a result of a concerns raised by Jari Arkko and Ralph Droms during IESG review. They were very clear that defining two options to configure the same parameter is not acceptable. Regarding scenario mentioned by Mohamed, since you are already differentiating between different locations (as I understand in your scenario different locations provide different DNS addresses that resolve the same AFTR FQDN to different addresses, right?), you may do this explicitly and provide different AFTR addresses. Would that solve the problem? Hope that helps. Tomek On Thu, Oct 7, 2010 at 4:58 PM, Maglione Roberta roberta.magli...@telecomitalia.it wrote: Hello All, I fully agree with Med, both AFTR IP address and AFTR name options are needed, in order to be able to handle different scenarios. We really would like to see both of them back in the draft. Best regards, Roberta -Original Message- From: softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] On Behalf Of mohamed.boucad...@orange-ftgroup.com Sent: giovedì 7 ottobre 2010 10.07 To: draft-ietf-softwire-ds-lite-tunnel-opt...@tools.ietf.org; Softwire Chairs Cc: softwires@ietf.org Subject: [Softwires] DHCPv6 AFTR name option is needed Dear authors, chairs, We are surprised to see the AFTR name option being removed from the latest version of this draft: http://tools.ietf.org/rfcdiff?url2=draft-ietf-softwire-ds-lite-tunnel-option-05.txt Is there any reason why this option has been removed? We would like to see this option back to the draft and that *** both *** the AFTR IP address and the name options are defined. FWIW, one of the deployment use cases we are considering is the distribution of the DS-Lite serviced customers among several (geo distributed) AFTRs by combining the search domain name dhcpv6 option (Code 24) and a generic FQDN conveyed in the AFTR name option. This would allow for a more controlled load distribution among deployed AFTRs. Cheers, Med
Re: [Softwires] DHCPv6 AFTR name option is needed
Dear Ted, The version which passed the Softwire LC is http://tools.ietf.org/html/draft-ietf-softwire-ds-lite-tunnel-option-04 which included both name and IP address options. After IESG review, 05 has been published but this version has significant changes. We are at least two service providers who are asking for the need to roll back to 04. If text is needed to justify the need of the name option, for sure we can help. Cheers, Med -Message d'origine- De : Ted Lemon [mailto:ted.le...@nominum.com] Envoyé : mardi 12 octobre 2010 15:50 À : BOUCADAIR Mohamed NCPI/NAD/TIP Cc : Ralph Droms; draft-ietf-softwire-ds-lite-tunnel-opt...@tools.ietf.org; Ullio Mario; Chairs Dhc; Softwire Chairs; Softwires; Maglione Roberta Objet : Re: [Softwires] DHCPv6 AFTR name option is needed On Oct 11, 2010, at 10:42 PM, mohamed.boucad...@orange-ftgroup.com wrote: Do you suggest the I-D should elaborate further on the FQDN use cases so this to be acceptable by the IESG? Chairs, how should we proceed? The version which passed the WG LC is not the 05. I'm confused. The current version of the draft is the -05 version, which makes no mention of FQDNs. You seem to be discussing the -04 version. Presumably the -05 version is the one that's meant to be published, so why are you discussing the -04 version? If the name option is needed, then the right thing to do is to issue a new draft. Since the draft would be substantially changed, and in a way that's contrary to the comments from the DHC working group, this would need to be re-reviewed by the DHC working group, and would need a new last call in the Softwires working group. It would be entirely inappropriate for such a substantial change to be made during IESG review without further review by the DHC and Softwires working groups, and without another last call. You would certainly need to explain the use case for the Name option--what value it adds that is missing from the address option. * 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] DHCP option for DS-lite
Dear Alain, all, I strongly object to define only a single AFTR address option. As I mentioned in previous e-mails, the FQDN name option is needed for some scenarios such as load balancing. Having DHCP server acting as a load balancer is not an option for us. If the problem is only with the language as mentioned by D. Hankins, then the spec should be clear enough. I hope the wg will re-consider this position and defines the name aftr option. Cheers, Med -Message d'origine- De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la part de Alain Durand Envoyé : mardi 12 octobre 2010 21:01 À : Softwires list Cc : Ralph Droms Objet : [Softwires] DHCP option for DS-lite Dear wg: draft-ietf-softwire-ds-lite-tunnel-optionmailto:draft-ietf-softwire-ds-lite-tunnel-opt...@tools.ietf.org has been reviewed by the IESG with input from the dhc wg. Their conclusion was that having both an IP option and an FQDN option to describe the tunnel-end-point was redundant. After many discussion between the IESG and the authors, the authors decided to remove the FQDN option, leaving only the IP address option in place. The rationale is that the B4 element should remain as simple as possible and presenting multiple tunnel-end point alternative would seriously complicate the implementation on the client side. For example, the client would have to keep track which end-point is currently the best alternative and we would have to develop a complex mechanism to do that. Load balancing is better achieve by the DHCP server sending the proper tunnel end-point to the B4 element. There are cases where more complex B4 elements could benefits from having multiple tunnel endpoint to choose from, but those are not expected to be the common case and they should be dealt with differently. Our AD, Ralph Droms, asked us to verify there is consensus in the wg to do this. David, Alain - The authors made a significant change to draft-ietf-softwire-ds-lite-tunnel-option, deleting the FQDN option based on IESG review and input from the dhc WG. The -05 rev is getting de facto review now, but you'll need to determine WG consensus for the changes in the -05 rev. - Ralph If you have a strong opinion that the decision of the authors is the wrong one, please speak up now. This window for comments will end in 7 days, on 10/19. - Alain. ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires * 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] DHCP option for DS-lite
David (document shepherd), Jari, all, In can answer to the technical questions, but before that let position this discussion in its context in the overall process (softwire should follow the ietf process). Below a reminder of the main steps for the adoption of this document: o First of all, this document is the proprietary of the working group and should reflect the consensus of the working group not the opinions of the authors neither the chairs. o The working group reached a consensus on the version, available at http://tools.ietf.org/html/ draft-ietf-softwire-ds-lite-tunnel-option-03. During the last call I didn't remember comments about the name option. o Dave Ward who is the document shepherd mentioned the following in his note (available on the tracker): (1) We saw evidence of extensive review on the mailing list. The documents has been presented in softwires, v6ops, and dhc working groups. (2) the document has strong support in the WG. (3) This is strictly a protocol specification. We believe that an operational document discussing some of the various tradeoffs and choices when deploying DS-Lite would be valuable. o According to the IETF tracker, a Go Ahead has been received from R. Droms on August, 5th. I understand this as Ralph has no technical issue with the content of the document. o According to the IETF tracker, Jari raised the following comment: This document is ready to move forward. However, there is one issue that I would like to briefly discuss before recommending the final approval of the RFC. We have been pushing back in other cases when people defined both FQDN and IP address information for the same configuration item in DHCP. Why are two options and configuration mechanisms absolutely necessary in this case? Wouldn't IP-address based configuration suffice? o The comment from Jari is valid and the document should justify why two options are needed. This is even surprising because D. Hankins is also the author of http://tools.ietf.org/html/draft-ietf-dhc-option-guidelines since 2007. This is issue in not new for him. o The authors on their own (or with the document shepherd, I don't know) decided to remove the name option **without** asking the working group's opinion. No notification has been sent on the mailing list to notify or to justify this IMPORTANT change to the document. At least two representatives of service providers reiterated the need of the name option for high availability and load balancing reasons. We can provide Jari with more details if required. Since the authors already maintained the IP address I believe they have strong arguments to maintain also the IP address option. The question should whether this feedback solves the issue raised by Jari during the IESG review. Jari, do you need more justification? Cheers, Med -Message d'origine- De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la part de Alain Durand Envoyé : jeudi 14 octobre 2010 18:59 À : Softwires list Cc : Ralph Droms Objet : Re: [Softwires] DHCP option for DS-lite I went back to the other thread on this topic DHCPv6 AFTR name option is needed. The only technical argument brought forward is that some ISPs would like to use a level of indirection via DNS to achieve load balancing (where the DNS has some form of measurement of the current load of the system). They point at VoIP for a precedent in that space. I would like to offer several remarks: 1) In the current DS-Lite model, the B4 element would only find out the tunnel end-point at config (boot) time. There is no provision in the spec to regularly refresh this information. This means that whatever is configured is going to stay that way for possibly a very long time. 2) It is unclear that the load information that the DNS was using at the time of the resolution is a good indicator of what the load will be hours or days later. 3) Thus, it is unclear that such a system provide any better load distribution that a simple round-robin that can trivially be implemented in a DHCP server 4) If one follows that logic, the DNS redirection just add a round trip time for no benefits. 5) The analogy with VoIP does not hold here because the VoIP client can do the query just before placing a call. The load information coming from the DNS has a better chance of being accurate for the next few minutes. I would like to invite the proponents of the DNS indirection to provide technical arguments as why the above remarks are incorrect. - Alain. On Oct 12, 2010, at 12:00 PM, Alain Durand wrote: Dear wg:
Re: [Softwires] Call for agenda items
Dear chairs, We would like to have a slot for (1) Draft name: http://tools.ietf.org/html/draft-boucadair-softwire-dslite-v6only-00 Time slot: 10 mins Presenter: Yiu Lee and for (2) Draft name: http://tools.ietf.org/html/draft-boucadair-softwire-cgn-bypass-03 Time slot: 10 mins Presenter: Christian Jacquenet Cheers, Med -Message d'origine- De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la part de Alain Durand Envoyé : vendredi 15 octobre 2010 01:32 À : Softwires list Objet : [Softwires] Call for agenda items This is a call for agenda items for the upcoming meeting in Beijing. Please send request directly the chairs. Alain David, co-chairs. ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires * 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] DHCP option for DS-lite
Dear Alain, all, In addition to the technical reasons mentioned in previous e-mails, I would like to raise that operational issues should be also taken into account for the provisioning of the DS-Lite AFTR reachability information. In particular, we are considering two levels of redirection: o The first level is national-wise is undertaken by the DHCP: a regional-specific FQDN will be returned; o The second level is done during the resolution of the regional- specific FQDN to redirect the customer to a regional CGN among a pool deployed regionally. Distinct operational teams are responsible for each of the above mentioned levels. A clear separation between the functional perimeter of each team is a sensitive task for the maintenance of the services we are running. In particular, regional teams will require to introduce new resources (e.g., new CGN devices) to meet an increase of customer base. The introduction of these new devices (addressing, redirection, etc.) is implemented locally. Having this regional separation provides flexibility to manage portions of network operated by dedicated teams. In order to be able to meet this operational constraint, the AFTR option name is part of our requirements. Cheers, Med -Message d'origine- De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la part de Alain Durand Envoyé : jeudi 14 octobre 2010 18:59 À : Softwires list Cc : Ralph Droms Objet : Re: [Softwires] DHCP option for DS-lite I went back to the other thread on this topic DHCPv6 AFTR name option is needed. The only technical argument brought forward is that some ISPs would like to use a level of indirection via DNS to achieve load balancing (where the DNS has some form of measurement of the current load of the system). They point at VoIP for a precedent in that space. I would like to offer several remarks: 1) In the current DS-Lite model, the B4 element would only find out the tunnel end-point at config (boot) time. There is no provision in the spec to regularly refresh this information. This means that whatever is configured is going to stay that way for possibly a very long time. 2) It is unclear that the load information that the DNS was using at the time of the resolution is a good indicator of what the load will be hours or days later. 3) Thus, it is unclear that such a system provide any better load distribution that a simple round-robin that can trivially be implemented in a DHCP server 4) If one follows that logic, the DNS redirection just add a round trip time for no benefits. 5) The analogy with VoIP does not hold here because the VoIP client can do the query just before placing a call. The load information coming from the DNS has a better chance of being accurate for the next few minutes. I would like to invite the proponents of the DNS indirection to provide technical arguments as why the above remarks are incorrect. - Alain. On Oct 12, 2010, at 12:00 PM, Alain Durand wrote: Dear wg: draft-ietf-softwire-ds-lite-tunnel-optionmailto:draft-ietf-softwire-ds-lite-tunnel-opt...@tools.ietf.org has been reviewed by the IESG with input from the dhc wg. Their conclusion was that having both an IP option and an FQDN option to describe the tunnel-end-point was redundant. After many discussion between the IESG and the authors, the authors decided to remove the FQDN option, leaving only the IP address option in place. The rationale is that the B4 element should remain as simple as possible and presenting multiple tunnel-end point alternative would seriously complicate the implementation on the client side. For example, the client would have to keep track which end-point is currently the best alternative and we would have to develop a complex mechanism to do that. Load balancing is better achieve by the DHCP server sending the proper tunnel end-point to the B4 element. There are cases where more complex B4 elements could benefits from having multiple tunnel endpoint to choose from, but those are not expected to be the common case and they should be dealt with differently. Our AD, Ralph Droms, asked us to verify there is consensus in the wg to do this. David, Alain - The authors made a significant change to draft-ietf-softwire-ds-lite-tunnel-option, deleting the FQDN option based on IESG review and input from the dhc WG. The -05 rev is getting de facto review now, but you'll need to determine WG consensus for the changes in the -05 rev. - Ralph If you have a strong opinion that the decision of the authors is the wrong one, please speak up now. This window for comments will end in 7 days, on 10/19. - Alain. ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
[Softwires] Per-interface NAT in mobile networks
Dear all, When per-interface NAT is applied to 3GPP networks, a NAT function can be embedded in the GGSN/PGW. The GTP tunnel identifier will be used as an identifier in the NAT table to identify sessions belonging to each UE. Packets are then translated and forwarded to their destination (either internal or external). Distinct IPv4 address pools may be configured on the GGSN/PGW depending on the APN. This procedure can be implemented in mono stack PDP context or in dual stack PDP contexts. Embedding a NAT in the PGW/GGSN is one of the scenarios we are considering to rationalise the use of IPv4 address in mobile networks, while promoting the invocation of IPv6 transfer capabilities whenever possible (our recommendation for mobile is to go for dual-stack connectivity). Unlike other solutions where the NAT is not embedded in the PGW, the activation of the per-interface NAT does not impact the network availability since no new nodes will be introduced to embed the NAT function. We think per-interface NAT (http://datatracker.ietf.org/doc/draft-arkko-dual-stack-extra-lite/ or http://tools.ietf.org/html/draft-miles-behave-l2nat-00) is a good place to describe this use case. Some vendors already support a NAT function in their PGW products, but for harmonising the behaviour of such implementations we think it would be valuable to see draft-arkko-dual-stack-extra-lite be adopted as a WG document in Behave or Softwire. Is there any plan to see this I-D progress as Softwire or Behave WG document? Cheers, Med * 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] Softwire agenda for IETF79
Dear Alain, I believe draft-cui-softwire-host-4over6 and draft-boucadair-softwire-dslite-v6only have the same scope: Provide IPv4 connectivity over an IPv6-only network. I would expect these I-Ds to be listed under the same category. Cheers, Med -Message d'origine- De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la part de Alain Durand Envoyé : jeudi 4 novembre 2010 02:03 À : Softwires list Objet : [Softwires] Softwire agenda for IETF79 Dear wg, Here is the tentative agenda for the softwire meeting at IETF79. As you see, there is an abundance of items that are neither on the current charter nor on the logical updates that we chairs have been discussing with our ADs. - Alain. IETF79 Softwire agenda Items in charter Multicast Mesh, Mingwei Xu, Chris Metz draft-dhankins-softwire-tunnel-option, David Hankins items in agreed evolution of the charter: draft-lee-softwire-dslite-deployment-00, Yiu Lee draft-qin-softwire-dslite-multicast-00, Jacni Qin draft-ietf-softwire-dslite-radius-ext-00, roberta Maglione draft-ietf-softwire-gateway-init-ds-lite-02, F. Brockners draft-cui-softwire-host-4over6, Yong Cui Items not in charter draft-guo-softwire-sc-discovery, Sheng Jiang draft-boucadair-softwire-dslite-v6only-00, Mohamed Boucadair draft-boucadair-softwire-cgn-bypass-03, Mohamed Boucadair draft-despres-softwire-6a44-01, Remi Despres draft-cui-softwire-pethttp://datatracker.ietf.org/doc/draft-cui-softwire-pet/, Peng Wu draft-templin-iron-13, Fred Templin draft-templin-intarea-seal-21, Fred Templin draft-tsou-softwire-gwinit-6rd. Tina Tsou draft-guo-softwire-6rd-radius-attrib-00, Sheng Jian draft-despres-softwire-4rd-00http://tools.ietf.org/id/draft-despres-softwire-4rd-00, Remi Despres draft-matsuhira-sa46t-as-00, Naoki Matsuhira ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires * 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] WG last call on draft-ietf-softwire-ds-lite-tunnel-option-07
Dear all, This version is almost Ok. I still have two comments: (1) Malformed DHCP answers sent by the DHCP Server: The I-D restricts the server to convey only on FQDN in the AFTR-Name. Then, it is coherent for the client to not accept an AFTR-Name which conveys several FQDN since this is a malformed message. I understand picking the first FQDN in the list is pragmatic but this is not coherent with the scope of this option: convey one single FQDN in one single option occurrence. I suggest to change It SHOULD NOT permit the configuration of multiple names within one AFTR-Name option. To It MUST NOT permit the configuration of multiple names within one AFTR-Name option. And If the client receives more than one AFTR-Name option, it MUST use only the first instance of that option. If the AFTR-Name option contains more than one FQDN, as distinguished by the presence of multiple root labels, the client MUST use only the first FQDN listed in configuration. To If the DHCP Client receives more than one AFTR-Name option or if the AFTR-Name option contains more than one FQDN, the DHCP Client MUST ignore the received AFTR-Name option(s)). (2) Multi-interface use case: this text has been introduced in 07: Note that a client may have multiple network interfaces, and these interfaces may be configured differently; some may be connected to networks that call for DS-Lite, and some may be connected to networks that are using normal dual stack or other means. The client should consider the above on an interface-by-interface basis. For example, if the client is attached to multiple networks that provide the AFTR Name option, then the client MUST configure a tunnel for each interface separately as each DS-Lite tunnel provides IPv4 connectivity for each distinct interface. The text does not elaborate on how an interface is identified and how the server/client will proceed to enforce the received configuration for the appropriate interface. BTW, this issue is not specific to DS-Lite and it is generic to any MIFed device. Other complications may raise in a multi-interface context. This is what is supposed to be solved by MIF WG. I suggest to remove this text from the I-D or to add a statement that multi-interface considerations are out of scope and are handled in MIF. Cheers, Med -Message d'origine- De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la part de Alain Durand Envoyé : vendredi 10 décembre 2010 21:15 À : softwires@ietf.org list Cc : Softwire Chairs Objet : [Softwires] WG last call on draft-ietf-softwire-ds-lite-tunnel-option-07 I'd like to start a one week wg last call on draft-ietf-softwire-ds-lite-tunnel-option-07. http://www.ietf.org/internet-drafts/draft-ietf-softwire-ds-lite-tunnel-option-07.txt History and rationale for a 1 week last call: The softwire wg had a regular 2 week wg last call on the -05 version. That version was sent to IESG, An issue was raised during IESG review: do we need to define 2 options for DS-Lite: one FQDN based and one IP based. -05 was defining both. As a response to IESG comments, -06 was published to removed the FQDN option. Further discussion followed, and the Softwire chairs declared a consensus to define only one option, but to choose the FQDN one instead of the IP option. The draft authors have reflected this change in the -07. In order to verify the above consensus, I am starting this one week-long wg last call. I'm also asking Ted Lemon, DHC workign group chair, Cc: here, to start a similar last call in the DHC wg. The Softwire last call will end on 12/17/2010. Alain Durand, Softwire co-chair. ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires * 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
[Softwires] DS-Lite I-D progress (was RE: dual-stack-lite-06 - Too biased against static port sharing)
Dear Alain, Yiu, Is there any plan to update the DS-Lite draft to take into account the comments received so far and to make this document progress? Cheers, Med -Message d'origine- De : francis.dup...@fdupont.fr [mailto:francis.dup...@fdupont.fr] Envoyé : mercredi 18 août 2010 21:48 À : BOUCADAIR Mohamed NCPI/NAD/TIP Cc : Rémi Després; Softwires; Ralph Droms Objet : Re: [Softwires] dual-stack-lite-06 - Too biased against static port sharing In your previous mail you wrote: We have raised this point during the last call which has been issued on version 03 of the draft and suggested to remove this section from the draft since it is not normative and also because this depends on the taste of each SP and their deployment context. A reference to http://tools.ietf.org/html/ draft-ietf-intarea-shared-addressing-issues-01#page-22 would be sufficient IMHO. Dynamic vs. Static and Port set vs. Individual ports discussion can be elaborated further in draft-intarea-shared-addressing-issues if required. = IMHO it is the best option (and to make the draft smaller is a good goal :-). Thanks francis.dup...@fdupont.fr IMPORTANT.Les informations contenues dans ce message electronique y compris les fichiers attaches sont strictement confidentielles et peuvent etre protegees par la loi. Ce message electronique est destine exclusivement au(x) destinataire(s) mentionne(s) ci-dessus. Si vous avez recu ce message par erreur ou s il ne vous est pas destine, veuillez immediatement le signaler a l expediteur et effacer ce message et tous les fichiers eventuellement attaches. Toute lecture, exploitation ou transmission des informations contenues dans ce message est interdite. Tout message electronique est susceptible d alteration. A ce titre, le Groupe France Telecom decline toute responsabilite notamment s il a ete altere, deforme ou falsifie. De meme, il appartient au destinataire de s assurer de l absence de tout virus. IMPORTANT.This e-mail message and any attachments are strictly confidential and may be protected by law. This message is intended only for the named recipient(s) above. If you have received this message in error, or are not the named recipient(s), please immediately notify the sender and delete this e-mail message. Any unauthorized view, usage or disclosure ofthis message is prohibited. Since e-mail messages may not be reliable, France Telecom Group shall not be liable for any message if modified, changed or falsified. Additionally the recipient should ensure they are actually virus free. ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] DS-lite update
Dear all, I have just read the new DS-Lite version and I have the following comments for Section 8: (1) 8.2. NAT conformance A dual-stack lite AFTR SHOULD implement behavior conforming to the best current practice, currently documented in [RFC4787] and [RFC5382]. Other discusions about carrier-grade NATs can be found in [I-D.nishitani-cgn]. * This text should be updated to something like: a DS-Lite AFTR MUST follow the requirements specified in [I-D.ietf-behave-lsn-requirements]. * In addition, [I-D.ietf-behave-lsn-requirements] is to be listed as a normative reference. (2) Section 8.3. Application Level Gateways (ALG) is to be removed since this can be covered in [I-D.ietf-behave-lsn-requirements]. Cheers, Med -Message d'origine- De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la part de Alain Durand Envoyé : jeudi 3 mars 2011 16:50 À : Jari Arkko; Ralph Droms Cc : softwires@ietf.org list; Yong Cui Objet : [Softwires] DS-lite update Dear ADs, New rev of the them main DS-lite doc (draft-ietf-softwire-dual-stack-lite-07) and the DHCP tunnel option (draft-ietf-softwire-ds-lite-tunnel-option-09) have been published. I believe they address all remaining comments. This should enable to restart the IESG process. - Alain. ___ 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] Motivation draft for stateless v4 over v6 solution
Dear Ole, For sure, the text can be shortened whenever possible. If you point me to sections you think it need to be re-worded, this would be appreciated. Thank you. Cheers, Med -Message d'origine- De : Ole Troan [mailto:ichiroumak...@gmail.com] De la part de Ole Troan Envoyé : jeudi 26 mai 2011 10:36 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : Rémi Després; Satoru Matsushima; Yiu Lee; Olaf Bonness; Isabel Borges; Softwires-wg Objet : Re: [Softwires] Motivation draft for stateless v4 over v6 solution I like the draft and I think it covers the motivational points well. as a general comment, I do think the document is too wordy. could the authors make the next revision terser or do you want me to propose text changes? I would also suggest that you reference the sections in rfc1958 on state. we don't have a good success record in gleaning state in the middle of the network (NAT, N:1 VLANs, DHCP...), since the protocols we 'glean' from aren't designed to maintain softstate in the network. I see no reason why this document shouldn't be adopted as a working group document immediately. cheers, Ole ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
[Softwires] Next step for Stateless Motivations I-D
Dear all, An updated version of the Motivations for Stateless IPv4 over IPv6 Migration Solutions I-D has been submitted. The document is available at: http://tools.ietf.org/html/draft-operators-softwire-stateless-4v6-motivation-02 This document has been largely reviewed and inputs from other contributors has been taken into account. Together with my co-authors, we ask the working group to consider the adoption of this document as a WG I-D. Comments and suggestions are more than welcome. Cheers, Med ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Yesterday's slides
Dear Dave, I would personally appreciate if you can draft your thoughts in form of an I-D before the meeting so that we can comment on them and discuss the points you are raising. FWIW, draft-operators-softwire-stateless-4v6-motivation does not argue against stateful but it elaborates on a set of motivations to explain why stateless is also needed. -00 and -01 of the draft includes a set of open issues. That section has been removed because of the comments received in this list. As for the point about failure modes, this is discussed in: draft-dec-stateless-4v6 Cheers, Med -Message d'origine- De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la part de Dave Thaler Envoyé : jeudi 28 juillet 2011 21:45 À : Satoru Matsushima; softwires@ietf.org list Objet : Re: [Softwires] Yesterday's slides Attaching here since they don't seem to be posted yet. -Dave -Original Message- From: softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] On Behalf Of Satoru Matsushima Sent: Thursday, July 28, 2011 1:29 PM To: softwires@ietf.org list Subject: [Softwires] Yesterday's slides Hi, Could someone tell me where is Dave Thaler's slides? Best regards, --satoru ___ 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] draft-operators-softwire-stateless-4v6-motivation
Hi Rémi, Yes, there was a vote in favour of adopting this document as a WG document but as you know this vote should be confirmed in the ML. A call for adoption should normally be issued by the chairs according to the IETF procedure. As for the content of the next iteration of the document, we have two options so far: (1) Put back some sections which have been removed in -02, add a new section to discuss dynamic vs. static, handle the comments received from J. Arkko, etc. Or 2) An alternative structure has been proposed off-line by A. Durand: discuss dynamic vs. static and stateful vs. dynamic. The analysis would elaborate the pros and cons of each solution (static stateless, static stateful, dynamic stateful,...). This document would be an analysis document and not a motivation document anymore. This document has no milestone in the charter IMHO. Note the charter mentions the following: Aug 2011 - Adopt stateless legacy IPv4 solution motivation document as a Working Group document I personally think the first option is straightforward but I'm open to the opinions of the working group members on how to proceed. Cheers, Med -Message d'origine- De : Rémi Després [mailto:despres.r...@laposte.net] Envoyé : mardi 16 août 2011 16:30 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : Nejc Škoberne; draft-operators-softwire-stateless-4v6-motivat...@tools.ietf.org; softwires@ietf.org Objet : Re: [Softwires] draft-operators-softwire-stateless-4v6-motivation Hi Med, At the last meeting, a vote was taken to decide whether this draft should become a WG draft. The answer has been a crystal clear yes, with the common understanding that, as such, it would have to be improved and competed based on WG reactions. IMHO, making it a WG document asap will facilitate discussions like this one: thet will point to the right document. Is there any sort term plan to do what was approved? Kind regards, RD Le 16 août 2011 à 13:48, mohamed.boucad...@orange-ftgroup.com mohamed.boucad...@orange-ftgroup.com a écrit : Dear Nejc, Thank you for the comments. Please see my answers inline. Cheers, Med -Message d'origine- De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la part de Nejc Škoberne Envoyé : mardi 16 août 2011 12:25 À : draft-operators-softwire-stateless-4v6-motivat...@tools.ietf.org Cc : softwires@ietf.org Objet : [Softwires] draft-operators-softwire-stateless-4v6-motivation Hello, I have some comments on your draft, see inline. Regards, Nejc --- 2. Terminology This document makes use of the following terms: Stateful 4/6 solution (or stateful solution in short): denotes a solution where the network maintains user-session states relying on the activation of a NAT function in the Service Providers' network [I-D.ietf-behave-lsn-requirements]. The NAT function is responsible for sharing the same IPv4 address among several subscribers and to maintain user-session state. Stateless 4/6 solution (or stateless solution in short): denotes a solution which does not require any user-session state (seeSection 2.3 of [RFC1958]) to be maintained by any IP address sharing function in the Service Provider's network. This category of solutions assumes a dependency between an IPv6 prefix and IPv4 address. In an IPv4 address sharing context, dedicated functions are required to be enabled in the CPE router to restrict the source IPv4 port numbers. Within this document, port set and port range terms are used interchangeably. [NS: If we consider a stateful A+P solution, we don't necessarily have a dependency between an IPv6 prefix and IPv4 address. Also, we don't have any user-session state in the Service Provider's network. Med: Fully agree. FWIW, this is what we called Binding Table A+P Mode in http://tools.ietf.org/html/draft-ymbk-aplusp-10#section-4.4. We do, however, have some user state (in order to do stateful tunneling, for example). Maybe this is included in user-session in your terminology, but then I think it would be appropriate to define the term user-session clearly.] Med: We assumed the definition of state as mentioned in RFC1958; but I agree the terminology should be much more clearer. ... 3.1.5. Bandwidth Saving In same particular network scenarios (e.g., wireless network ), spectrum is very valuable and scarce resource. Service providers usually wish to eliminate unnecessary overhead to save bandwidth consumption in such environment.
Re: [Softwires] draft-operators-softwire-stateless-4v6-motivation
Dear Qiong, Yes, port ranges can be used in a CGN-based architecture too to reduce log file volume as discussed in http://tools.ietf.org/html/draft-operators-softwire-stateless-4v6-motivation-02#section-3.1.3 but then you should be aware you loose a feature offered by the CGN which is: * The possibility to log the destination IP address for legal storage purposes in case the server does not implement RFC6302. If RFC6302 is largely deployed, then this feature is not needed. There are a lot of trade-offs and there is no universal answers to these trade-offs. Cheers, Med De : Qiong [mailto:bingxu...@gmail.com] Envoyé : mardi 16 août 2011 18:29 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : Nejc Škoberne; softwires@ietf.org; draft-operators-softwire-stateless-4v6-motivat...@tools.ietf.org Objet : Re: [Softwires] draft-operators-softwire-stateless-4v6-motivation Hi, Med, and Nejc, Please see inline. You indeed loose agressive sharnig ratio, but you have somewhat more flexible addressing. Also, the CPEs can be then really simple devices, excluding any of the NAPT functionality, doing only stateless encapsulation. However, what you loose/gain is irrelevant for my point. I think this section should be modified in a way like the logging section or any other appropriate way, which explains, that this is not the benefit of the stateless nature, but rather the benefit of the static port allocation. [Qiong]: +1 Agree. Med: Your point is valid and the text should be updated accordingly. My comment aims to show that the comparison is not so that trivial. We can claim the stateful with port ranges can provide similar features as the stateless or the binding mode but we always forget to mention this lead to loose one of the characteristics of the stateful. We captured a similar discussion in http://tools.ietf.org/html/draft-operators-softwire-stateless-4v6-motivation-01#section-4.2: [Qiong]: In our situation, we do not regard aggressive sharing ratio as a vital important feature since the static port multiplex ratio is already enough for us. Besides, even for session-based CGN like ds-lite, we would still prefer to pre-define port-range for customers because our centralized log server can not deal with massive session-based log events. So it seems more reasonable for us to adopt static port arrangement which can largely reduce the log volume. Best regards Qiong Sun 5.2. Port Utilisation Efficiency CGN-based solutions, because they can dynamically assign ports, provide better IPv4 address sharing ratio than stateless solutions (i.e., can share the same IP address among a larger number of customers). For Service Providers who desire an aggressive IPv4 address sharing, a CGN-based solution is more suitable than the stateless. If a Service Provider adopts an aggressive address sharing ratio, it is likely to be attempted by enforcing a NAT port overloading mode and as a consequence some applications will break. However, as more and more hosts become dual-stack enabled, the need for ports in IPv4 is likely to decrease. The insurance to have the full set of 64K ports per host will be one of the incentives to have them IPv6 capable. Moreover, Service Providers should offload some services to IPv6 (e.g., DNS, VoIP). ___ 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] Softwire Interim Meeting in Beijing
Dear all, I fully agree with Rajiv. I would like to add to the list of stateless solutions the proposal specified in: http://tools.ietf.org/html/draft-boucadair-behave-ipv6-portrange-04 and its companion I-D: http://tools.ietf.org/html/draft-boucadair-dhcpv6-shared-address-option-01. Cheers, Med -Message d'origine- De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la part de Rajiv Asati (rajiva) Envoyé : vendredi 19 août 2011 17:04 À : Alain Durand Cc : softwires@ietf.org; liziye; Yong Cui; iesg-secret...@ietf.org; Ralph Droms (rdroms) Objet : Re: [Softwires] Softwire Interim Meeting in Beijing It doesn't, IMO. In fact, I beg to say that it is unfair mention 'tunneling vs translating' as a blanket statement, since we have known all along that a sane 4v6 solution would likely involve translating (44), no matter what. Moreover, it is reasonable to call out all stateless 4v6 options, not just a particular solution. Cheers, Rajiv -Original Message- From: Alain Durand [mailto:adur...@juniper.net] Sent: Friday, August 19, 2011 9:44 AM To: Rajiv Asati (rajiva) Cc: Yong Cui; softwires@ietf.org; liziye; iesg-secret...@ietf.org; Ralph Droms (rdroms) Subject: Re: [Softwires] Softwire Interim Meeting in Beijing We mentioned 'tunneling vs translating'. This should cover it. Alain. Sent from my iPad On Aug 19, 2011, at 8:16 AM, Rajiv Asati (rajiva) raj...@cisco.com wrote: Yong, Why is dIVI not included In the discussion ? Could you please clarify? Cheers, Rajiv Sent from Phone On Aug 19, 2011, at 8:10 AM, Yong Cui cuiy...@tsinghua.edu.cn wrote: Hi folks, We, softwire wg chairs, in agreement with our ADs, are announcing an interim meeting in Beijing on September 26 27. The date has been chosen adjacent to the BBF meeting in Shangai to minimize travel and visa issues. The interim meeting will focus on 'stateless' solutions in general and 4rd in particular. Expected outcome includes progress on 4rd spec, packet format, where to put IPv4 bits, port indications, DHCP option, tunneling vs translation, coexistence with other technologies, etc... --- Meeting Location recommended hotels Meeting venue: FIT Building, Tsinghua University, Beijing FIT Building is the first left building inside of the East Gate of Tsinghua Univeristy http://maps.google.com/maps/ms?msid=202779846620144871057.0004aad8ce367b 982 9372msa=0ll=39.996906,116.331664spn=0.004044,0.008798 Recommended hotels: 1. Uniscenter (4 stars, 3 min walk) http://en.uniscenter.com/newEbiz1/EbizPortalFG/portal/html/index.html 2. Wenjin Hotel (5 stars, 10 min walk) http://www.wenjin.com.cn/ 3. Royal King Hotel (5 stars, 10 min by car) http://www.royalkinghotel.com/ Invitation letter If you need an invitation letter, please send the following info to Ms. Ziye Li: liz...@csnet1.cs.tsinghua.edu.cn. Surname: Given Name: Company: Address: Phone: Passport Number: Passport Exp. Date: Passport Issuing Country: - Further contact information Please contact Ms. Ziye Li if you have any question about Beijing/Tsinghua/Hotel/Meeting venue/visa/tour... liz...@csnet1.cs.tsinghua.edu.cn -- Alain, Yong ___ 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 mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04
Hi Tina, Thank you very much for reviewing carefully this document. Your editorial suggestions will be considered when we will generate the next revision of the I-D. As for the comment about the co-location of the MLD Querier and mAFTR, this is a deployment scenario among others. The I-D only discusses that case. Please keep in mind this I-D defines functional elements and not nodes. Cheers, Med -Message d'origine- De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la part de Tina TSOU Envoyé : mardi 23 août 2011 03:58 À : softwires@ietf.org Objet : [Softwires] Comments on draft-qin-softwire-dslite-multicast-04 Hi all, In IETF-81, the chairs asked the authors of different drafts on multicast sit together to discuss and compromise. So we did. Here are some comments on draft-qin-softwire-dslite-multicast-04. Overall: if this is to be a Standards Track document, the whole document has to be reviewed, the normative parts identified, and requirements language substituted for the current descriptive language. Section 1: Editorial: at the end of the second paragraph, vastly consumed reads better in English as: consumed in vast quantities. Substantive: add the following to the sentence making up the third paragraph: ..., which prevents these consequences by making use of the native multicast capabilities of the intervening IPv6 network. Section 2: Terminology: Multicast AFTR has connotations (IPv4 NAT) that simply aren't there. Suggestion: Multicast Transitional Border Gateway (mTBG). Substantive(?): In the description of the Multicast B4, it would make more sense to change ... which is able to enforce ... to ... which implements Section 3.2: Bullet 1: the second sentence jams two unrelated ideas together. It needs a little expansion to read properly. The next sentence doesn't make sense within the stated scope of the bullet and shouldn't be there. The suggested changed text is thus: A viable scenario for this use case in DS-Lite environment: customers with legacy receivers must continue to access the IPv4-enabled multicast services. This means the traffic should be accessed through IPv4 and additional functions are needed to traverse the operator's IPv6- enabled network. It is the purpose of this document to describe those functions. Refer to [I-D.jaclee-behave- v4v6-mcast-ps] for the deployment considerations. Final paragraph: don't you need a final sentence saying something like: Depending on the specific details of the contract, this may mean that the specific framing of the content packets (as IPv4 packets) must be preserved along with the content within that framing. Section 4: First paragraph: the following sentences need to be added after the first one to give a full picture of what is required for a solution: For multicast, in contrast, separate mechanisms are required to process the outgoing multicast signalling packets and the incoming packets of content. The multicast signalling needs to be interworked to IPv6 and processed as IPv6 signalling. For incoming multicast content, this document defines ... Middle paragraph: why doesn't it simply read: See Section 4.3 for multicast distribution tree establishment and Section 4.4 for multicast traffic forwarding. Section 4.2 Third paragraph typo: mPrefixe64 - mPrefix64 Section 4.3 Bullets: it makes no sense to embed the mAFTR in the MLD Querier. That would cause the native IPv6 multicast infrastructure to be bypassed. It is also inconsistent with the architectural figure. Delete the first bullet and merge the second one with the next paragraph, like this: The mAFTR should process the received PIMv6 Join message for the IPv4-embedded IPv6 group and send the corresponding IPv4 PIM Join message. It creates an entry for the IPv6 multicast group address in its multicast Routing Information Base. This entry is used to forward ... Section 4.5 It is not clear whether the final paragraph is talking about the mB4+B4 or the mAFTR+AFTR or both. In fact, it makes good sense to combine the mB4 and the B4, but combining the AFTR and mAFTR would be questionable for reasons of scalability. There may be routing issues to sort out regarding reachability of the IPv4 prefix that is shared by the source -- the multicast routers should choose the path leading through the mAFTR rather than the one going through the AFTR. No more comments up to section 7. Maybe more comments from section 7 onwards in a separate E-mail. Regards, Tina ___ 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] Comments on draft-qin-softwire-dslite-multicast-04
Hi Tina, Please see inline. Cheers, Med De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la part de Tina TSOU Envoyé : mercredi 24 août 2011 04:21 À : Jacni Qin Cc : softwires@ietf.org Objet : Re: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04 Hi Jacni, Thank you for your early reply. Have a good day. My replies are below. Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html From: Jacni Qin [mailto:jac...@gmail.com] Sent: Tuesday, August 23, 2011 6:09 PM To: Tina TSOU Cc: softwires@ietf.org Subject: Re: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04 hi, On Wed, Aug 24, 2011 at 8:02 AM, Tina TSOU tina.tsou.zout...@huawei.commailto:tina.tsou.zout...@huawei.com wrote: Hi all, Some more comments on draft-qin-softwire-dslite-multicast-04. #1 General comment: is there any consideration of interaction with unicast solutions, e.g., potential collocation or reuse of functions? Do we need some mapping or interaction table of the function elements or tunnels (IP-in-IP or IP-in-non-IP) to show the relationship with DS-Lite unicast solution? Jacni: As Yiu mentioned in another email, the co-location with unicast DS-Lite elements is more deployment specific, and I'm ok to remove the section 4.5. From the protocol perspective, I don't see there is necessary interaction with the unicast solution. [TT] Section 4.5 is good for the readers to understand the difference between unicast and multicast DS-Lite. I strongly suggest add some texts into this section like the co-location of multicast elements with unicast DS-Lite elements is more deployment specific. [Med] OK. We will do. #2 Section 6.2 Translation and encapsulation both uses the same mPrefix64 and uPrefix64, so mB4 could not determine whether to de-capsulate the packets only based on mPrefix64 and uPrefix64. Propose to change as it checks whether the group address is in the range of mPrefix64, the source address is in the range of uPrefix64 and whether the next header of IPv6 header is 4. Jacni:Currently, we only employ the encapsulation for date forwarding in the main text. [TT] I am not talking about translation solution in the main text. Even if in the encapsulation case, mB4 needs to determine whether to make de-capsulation or not. [Med] This excerpt from Section 6.2 explains the rule to follow: When the mB4 receives an IPv6 multicast packet, it checks whether the group address is in the range of mPrefix64 and the source address is in the range of uPrefix64. Does this answer your question? ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04
Hi Tina, I agree with Yiu. FYI, we had a discussion between co-authors of the draft whether we maintain http://tools.ietf.org/html/draft-qin-softwire-dslite-multicast-04#section-8 or remove it. You can read in that section: Additionally, mechanisms such as MLD Snooping, MLD Proxying, etc., can be introduced into the distributed Access Network Nodes (e.g., Aggregation Switches, xPON devices) which then could behave as MLD Querier and replicate multicast flows as appropriate. Thus, the multicast replication point is moved downward closer to the receivers, so that bandwidth consumption is optimized. What do you think is missing in that text? Cheers, Med De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la part de Lee, Yiu Envoyé : jeudi 25 août 2011 05:31 À : softwires@ietf.org Objet : Re: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04 Hi Tina, What do you see new here in this scenario? mAFTR is a logical function, it would perform MLD PIMv4-Join interworking. This has been captured. If a vendor wants to make mAFTR also a L2 device, it would perform standard MLD snooping. What else is missing? Thanks, Yiu From: Tina TSOU tina.tsou.zout...@huawei.commailto:tina.tsou.zout...@huawei.com Date: Thu, 25 Aug 2011 02:11:18 + To: softwires@ietf.orgmailto:softwires@ietf.org softwires@ietf.orgmailto:softwires@ietf.org Subject: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04 Hi all, One more comment on Section 7.4.2. This document only covers IGMP-MLD and PIMv6-PIMv4 scenarios. We also need to consider the scenario where it is layer 2 network between mAFTR and mB4. The architecture is as below: / \ | IPv4 network | \/ : | ^ IPv4 Multicast : | : PIMv4 Join v | : +-+ |mAFTR | +-+ |:| | ^ IPv6 Multicast |:| | : (MLD Report) (IPv4 embedded) |.| ... . +---+ | MLD proxy/| | snooping | +---+ |:| | : MLD Report |v| | : +---+ | mB4| +---+ : | ^ IPv4 Multicast : | : IGMP Report v | : +---+ | IPv4 | | Receiver | +---+ B. R. Tina ___ 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] Comments on draft-qin-softwire-dslite-multicast-04
Hi Tina, I agree with Yiu. FYI, we had a discussion between co-authors of the draft whether we maintain http://tools.ietf.org/html/draft-qin-softwire-dslite-multicast-04#section-8 or remove it. You can read in that section: Additionally, mechanisms such as MLD Snooping, MLD Proxying, etc., can be introduced into the distributed Access Network Nodes (e.g., Aggregation Switches, xPON devices) which then could behave as MLD Querier and replicate multicast flows as appropriate. Thus, the multicast replication point is moved downward closer to the receivers, so that bandwidth consumption is optimized. What do you think is missing in that text? Cheers, Med De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la part de Lee, Yiu Envoyé : jeudi 25 août 2011 05:31 À : softwires@ietf.org Objet : Re: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04 Hi Tina, What do you see new here in this scenario? mAFTR is a logical function, it would perform MLD PIMv4-Join interworking. This has been captured. If a vendor wants to make mAFTR also a L2 device, it would perform standard MLD snooping. What else is missing? Thanks, Yiu From: Tina TSOU tina.tsou.zout...@huawei.com Date: Thu, 25 Aug 2011 02:11:18 + To: softwires@ietf.org softwires@ietf.org Subject: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04 Hi all, One more comment on Section 7.4.2. This document only covers IGMP-MLD and PIMv6-PIMv4 scenarios. We also need to consider the scenario where it is layer 2 network between mAFTR and mB4. The architecture is as below: ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04
Hi Tina, Please see inline. Cheers Med De : Tina TSOU [mailto:tina.tsou.zout...@huawei.com] Envoyé : vendredi 26 août 2011 04:35 À : BOUCADAIR Mohamed OLNC/NAD/TIP; Jacni Qin Cc : softwires@ietf.org Objet : RE: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04 Hi Med, In line with [TT2]. Best Regards, [SNIP] [Med] Using the same mPrefix64 for both encap and translation is not recommended in draft-boucadair-* as you can read in the following excerpt: IPv4-IPv6 encapsulator and translator may be embedded in the same device or even implemented with the same software module. In order to help the function whether an encapsulated IPv6 multicast packets or translated IPv6 ones are to be transferred. It was tempting to define an S-bit for that purpose but this choice has been abandoned in favor of the recommendation to use distinct MPREFIX64 for each scheme. I don't see an issue here. [TT2] Since encapsulation and translation use different mPrefix64, it is not an issue in draft-qin-* now. But draft-boucadair-* does not specify how to make mPrefix64 different for encapsulation and translation. Do you think it is needed? Med: I confirm this is not an issue for draft-qin. In draft-boucadair, we can for sure clarify more and state the operator of the v4/v6 multicast intercinnection nodes configures two distinct mPREFIX64, ... ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04
Re-, L2-relatd considerations described in Section 8 of draft-qin does not require any specific behaviour from the mAFTR. I suggest we continue this thread off-line. Cheers, Med -Message d'origine- De : Tina TSOU [mailto:tina.tsou.zout...@huawei.com] Envoyé : vendredi 26 août 2011 04:31 À : BOUCADAIR Mohamed OLNC/NAD/TIP; Lee, Yiu; softwires@ietf.org Objet : RE: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04 Bonjour Med, Thank you for your comments. What Yiu said is not reflected in figure 3. In the current figure, mAFTR can receive (PIMv6 Join, PIMv6 Routers in between). However, if the IPv6 network is layer 2 network, mAFTR should be able to receive MLD report as well. mAFTR also performs MLD/PIMv4 interworking in this case. So I propose update figure 3 to be complete. Section 8 does not mention how mAFTR acts in this case. Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html -Original Message- From: softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] On Behalf Of mohamed.boucad...@orange-ftgroup.com Sent: Thursday, August 25, 2011 1:11 AM To: Lee, Yiu; softwires@ietf.org Subject: Re: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04 Hi Tina, I agree with Yiu. FYI, we had a discussion between co-authors of the draft whether we maintain http://tools.ietf.org/html/draft-qin-softwire-dslite-multicast-04#section-8 or remove it. You can read in that section: Additionally, mechanisms such as MLD Snooping, MLD Proxying, etc., can be introduced into the distributed Access Network Nodes (e.g., Aggregation Switches, xPON devices) which then could behave as MLD Querier and replicate multicast flows as appropriate. Thus, the multicast replication point is moved downward closer to the receivers, so that bandwidth consumption is optimized. What do you think is missing in that text? Cheers, Med De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la part de Lee, Yiu Envoyé : jeudi 25 août 2011 05:31 À : softwires@ietf.org Objet : Re: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04 Hi Tina, What do you see new here in this scenario? mAFTR is a logical function, it would perform MLD PIMv4-Join interworking. This has been captured. If a vendor wants to make mAFTR also a L2 device, it would perform standard MLD snooping. What else is missing? Thanks, Yiu From: Tina TSOU tina.tsou.zout...@huawei.com Date: Thu, 25 Aug 2011 02:11:18 + To: softwires@ietf.org softwires@ietf.org Subject: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04 Hi all, One more comment on Section 7.4.2. This document only covers IGMP-MLD and PIMv6-PIMv4 scenarios. We also need to consider the scenario where it is layer 2 network between mAFTR and mB4. The architecture is as below: ___ 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] Analysis of Port Indexing Algorithms (draft-bsd-softwire-stateless-port-index-analysis)
Dear all, We have just submitted an I-D analysing the port set algorithms we have on the table. A set of properties are used to characterize the port set algorithms. This is a call for review. In particular, we invite authors of the following proposals to review their section: o [I-D.boucadair-behave-ipv6-portrange] o [I-D.xli-behave-divi] o [I-D.murakami-softwire-4v6-translation] o [I-D.murakami-softwire-4rd] o [I-D.despres-softwire-4rd-addmapping] Questions, suggestions, corrections and contributions are more than welcome. Thank you. Cheers, Med -Message d'origine- De : i-d-announce-boun...@ietf.org [mailto:i-d-announce-boun...@ietf.org] De la part de internet-dra...@ietf.org Envoyé : lundi 5 septembre 2011 18:33 À : i-d-annou...@ietf.org Objet : I-D Action: draft-bsd-softwire-stateless-port-index-analysis-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Analysis of Port Indexing Algorithms Author(s) : Mohamed Boucadair Nejc Skoberne Wojciech Dec Filename: draft-bsd-softwire-stateless-port-index-analysis-00.txt Pages : 25 Date: 2011-09-05 This document analyzes various algorithm proposals for building port sets. These algorithms are used to encode the range of ports in an IPv6 address and prefix in the context of stateless solutions. The ultimate goal of this analysis is to converge on one or a set of algorithms to be used by all stateless solutions. This is a companion document to [I-D.boucadair-softwire-stateless-rfc6052-update]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-bsd-softwire-stateless-port-index-analysis-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-bsd-softwire-stateless-port-index-analysis-00.txt ___ I-D-Announce mailing list i-d-annou...@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Analysis of Port Indexing Algorithms (draft-bsd-softwire-stateless-port-index-analysis)
Hi Jacni, Please see inline. Cheers, Med De : Jacni Qin [mailto:ja...@jacni.com] Envoyé : mardi 6 septembre 2011 11:30 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : Wojciech Dec; softwires@ietf.org Objet : Re: [Softwires] Analysis of Port Indexing Algorithms (draft-bsd-softwire-stateless-port-index-analysis) hi Med, all, Thanks for writing this, it helps. A couple of quick comments below, *) Is the focus of the document (properties used) on the whole address architecture/format, or just on the algorithms to build port sets? As in some proposals, for example 4rd, the port indexing algorithm can be an independent part and decoupled from the address format. [Med] All port indexing schemes are independent of the address format itself, but we included some properties to reflect some design choices made my the authors of these solutions on the address format. FWIW, we will submit soon a list of requirements to be followed by stateless address/prefix format. *) o Multiple Port Ranges: Capability to assign multiple contiguous port ranges to a single PRD Jacni: I guess this only applies to portrange which offers contiguous port-set. So, I would suggest removing this property. [Med] Ok. *) For despres-4rd, Differentiated Port Sets Supported, through different piece of rules, delegated CPE prefixes of different length. [Med] the concern is more on the border router side, can you please check if the operations are still stateless at the border side? BTW, I'm envisaging having two properties here: (1) Differentiated Port Sets (network level) (2) Differentiated Port Sets (bound to the same shared address) IPv4 traffic Isolation supported [Med] Ok. This is supported by assigning two prefixes. Prefix Aggregation supported, since the IPv6 address planning is not affected. [Med] Ok. I'll come back to you later if I get more. Cheers, Jacni On Tuesday, September 06, 2011 12:44:48 AM, mohamed.boucad...@orange-ftgroup.commailto:mohamed.boucad...@orange-ftgroup.com wrote: Dear all, We have just submitted an I-D analysing the port set algorithms we have on the table. A set of properties are used to characterize the port set algorithms. This is a call for review. In particular, we invite authors of the following proposals to review their section: o [I-D.boucadair-behave-ipv6-portrange] o [I-D.xli-behave-divi] o [I-D.murakami-softwire-4v6-translation] o [I-D.murakami-softwire-4rd] o [I-D.despres-softwire-4rd-addmapping] Questions, suggestions, corrections and contributions are more than welcome. Thank you. Cheers, Med -Message d'origine- De : i-d-announce-boun...@ietf.orgmailto:i-d-announce-boun...@ietf.org [mailto:i-d-announce-boun...@ietf.org] De la part de internet-dra...@ietf.orgmailto:internet-dra...@ietf.org Envoyé : lundi 5 septembre 2011 18:33 À : i-d-annou...@ietf.orgmailto:i-d-annou...@ietf.org Objet : I-D Action: draft-bsd-softwire-stateless-port-index-analysis-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Analysis of Port Indexing Algorithms Author(s) : Mohamed Boucadair Nejc Skoberne Wojciech Dec Filename : draft-bsd-softwire-stateless-port-index-analysis-00.txt Pages : 25 Date : 2011-09-05 This document analyzes various algorithm proposals for building port sets. These algorithms are used to encode the range of ports in an IPv6 address and prefix in the context of stateless solutions. The ultimate goal of this analysis is to converge on one or a set of algorithms to be used by all stateless solutions. This is a companion document to [I-D.boucadair-softwire-stateless-rfc6052-update]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-bsd-softwire-stateless-port-index-analysis-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-bsd-softwire-stateless-port-index-analysis-00.txt ___ I-D-Announce mailing list i-d-annou...@ietf.orgmailto:i-d-annou...@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt ___ 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] Analysis of Port Indexing Algorithms (draft-bsd-softwire-stateless-port-index-analysis)
Hi Satoru, What I have done is I clarified the text as follows: o Complexity: Reflects the complexity level of understanding the algorithm and the expected complexity to configure an implementation. Is this fine or you think we need to elaborate further? Cheers, Med -Message d'origine- De : Satoru Matsushima [mailto:satoru.matsush...@gmail.com] Envoyé : mercredi 7 septembre 2011 09:03 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : GangChen; softwires@ietf.org; Wojciech Dec Objet : Re: [Softwires] Analysis of Port Indexing Algorithms (draft-bsd-softwire-stateless-port-index-analysis) Hi Med, 2011/9/7 mohamed.boucad...@orange-ftgroup.com: Dear Gang, As per the following property: o Complexity: Complexity level of the algorithm I agree this can be split into several sub items but in -00 we used it to reflect the level of complexity to understand the algorithm and to configure it. I know Nejc had some experience in configuring for instance Murakami's 4rd implementation. He found that it was much more complex to understand than the portrange algorithm and the modulo algorithm. The text will be clarified. Interesting discussion. It would be nice if you and us clarify that the complexity for what, and for who. cheers, --satoru ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
[Softwires] Requirements for extending IPv6 addresses with port range (draft-boucadair-softwire-stateless-rfc6052-update)
Dear all, We submitted a new I-D identifying the requirements to be met when designing the format of IPv4-embedded IPv6 addresses/prefixes enclosing the port information. The first list of requirements is available at: http://tools.ietf.org/html/draft-boucadair-softwire-stateless-rfc6052-update-00#section-3 Contributions, comments and suggestions on the requirements section are encouraged. Thanks. Cheers, Med -Message d'origine- De : i-d-announce-boun...@ietf.org [mailto:i-d-announce-boun...@ietf.org] De la part de internet-dra...@ietf.org Envoyé : mercredi 7 septembre 2011 13:56 À : i-d-annou...@ietf.org Objet : I-D Action: draft-boucadair-softwire-stateless-rfc6052-update-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Embedding Port Information in IPv4-Translatable IPv6 Prefixes and IPv4- Embedded IPv6 Addresses Author(s) : Mohamed Boucadair Congxiao Bao Nejc Skoberne Xing Li Filename: draft-boucadair-softwire-stateless-rfc6052-update-00.txt Pages : 10 Date: 2011-09-07 RFC6052 specifies the algorithmic translation of an IPv6 address to a corresponding IPv4 address, and vice versa. In particular, RFC6052 specifies the address format to build IPv4-converted and IPv4- translatable IPv6 addresses. In order to be deployed in the context of stateless 4/6 solutions, RFC6052 should be updated so that IPv4- embedded IPv6 addresses convey the port information. This document identifies a set of requirements to be taken into account when updating RFC6052 for that purpose. A companion effort, document at [I-D.bsd-softwire-stateless-port-index-analysis], is required to converge on one or a set of algorithms to be used by all stateless solutions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-boucadair-softwire-stateless-rfc6052-update-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-boucadair-softwire-stateless-rfc6052-update-00.txt ___ I-D-Announce mailing list i-d-annou...@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Analysis of Port Indexing Algorithms (draft-bsd-softwire-stateless-port-index-analysis)
Re-, Please see inline. Cheers, Med De : Jacni Qin [mailto:ja...@jacni.com] Envoyé : mercredi 7 septembre 2011 10:12 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : Wojciech Dec; softwires@ietf.org Objet : Re: [Softwires] Analysis of Port Indexing Algorithms (draft-bsd-softwire-stateless-port-index-analysis) Hi Med, More inline please, On 9/7/2011 1:22 PM, mohamed.boucad...@orange-ftgroup.commailto:mohamed.boucad...@orange-ftgroup.com wrote: *) Is the focus of the document (properties used) on the whole address architecture/format, or just on the algorithms to build port sets? As in some proposals, for example 4rd, the port indexing algorithm can be an independent part and decoupled from the address format. [Med] All port indexing schemes are independent of the address format itself, but we included some properties to reflect some design choices made my the authors of these solutions on the address format. FWIW, we will submit soon a list of requirements to be followed by stateless address/prefix format. Ok, and just FYI, there are some design objectives discussed in http://tools.ietf.org/html/draft-despres-softwire-4rd-addmapping-00#page-5 which may be useful to you. [Med] The document is now online, could you please check the list available at: http://tools.ietf.org/html/draft-boucadair-softwire-stateless-rfc6052-update-00#section-3. Do you see additional requirements to be inspired from the pointer you provided? thanks. ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Requirements for extending IPv6 addresses with port range (draft-boucadair-softwire-stateless-rfc6052-update)
Dear Maoke, Please see inline. Cheers, Med De : Maoke [mailto:fib...@gmail.com] Envoyé : mercredi 7 septembre 2011 15:43 À : BOUCADAIR Mohamed OLNC/NAD/TIP Objet : Re: [Softwires] Requirements for extending IPv6 addresses with port range (draft-boucadair-softwire-stateless-rfc6052-update) hi all, i'd like to commet on the interesting question after REQ#5 Do we allow the support of multiple algorithms?. my answer is NO. intuitively, it sounds ok if we allow multiple algorithms, as long as the algorithm type is also encoded in the IPv4-embedded IPv6 address together with the port index. however, it is only applied for the case of translating an IPv4-embedded IPv6 address to IPv4. for the reverse direction, the algorithm selection might be randomly decided by the translator devices. inconsistency of port indexing algorithm violates the end-to-end transparency. coordinating algorithm selection is possible but it might must costs. [Med] I see your point and it makes sense to me. There is also an underlying question we wanted to discuss: is it acceptable for the WG to specify several algorithms (see for instance RFC6056) but only one algorithm MUST be enabled in a network. btw, it looks the reference on port indexing algorithm analysis should be ...-bsd-... rather than ...-boucadair-... ;-) [Med] Fixed. Thanks. best, maoke 2011/9/7 mohamed.boucad...@orange-ftgroup.commailto:mohamed.boucad...@orange-ftgroup.com Dear all, We submitted a new I-D identifying the requirements to be met when designing the format of IPv4-embedded IPv6 addresses/prefixes enclosing the port information. The first list of requirements is available at: http://tools.ietf.org/html/draft-boucadair-softwire-stateless-rfc6052-update-00#section-3 Contributions, comments and suggestions on the requirements section are encouraged. Thanks. Cheers, Med -Message d'origine- De : i-d-announce-boun...@ietf.orgmailto:i-d-announce-boun...@ietf.org [mailto:i-d-announce-boun...@ietf.orgmailto:i-d-announce-boun...@ietf.org] De la part de internet-dra...@ietf.orgmailto:internet-dra...@ietf.org Envoyé : mercredi 7 septembre 2011 13:56 À : i-d-annou...@ietf.orgmailto:i-d-annou...@ietf.org Objet : I-D Action: draft-boucadair-softwire-stateless-rfc6052-update-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Embedding Port Information in IPv4-Translatable IPv6 Prefixes and IPv4- Embedded IPv6 Addresses Author(s) : Mohamed Boucadair Congxiao Bao Nejc Skoberne Xing Li Filename: draft-boucadair-softwire-stateless-rfc6052-update-00.txt Pages : 10 Date: 2011-09-07 RFC6052 specifies the algorithmic translation of an IPv6 address to a corresponding IPv4 address, and vice versa. In particular, RFC6052 specifies the address format to build IPv4-converted and IPv4- translatable IPv6 addresses. In order to be deployed in the context of stateless 4/6 solutions, RFC6052 should be updated so that IPv4- embedded IPv6 addresses convey the port information. This document identifies a set of requirements to be taken into account when updating RFC6052 for that purpose. A companion effort, document at [I-D.bsd-softwire-stateless-port-index-analysis], is required to converge on one or a set of algorithms to be used by all stateless solutions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-boucadair-softwire-stateless-rfc6052-update-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-boucadair-softwire-stateless-rfc6052-update-00.txt ___ I-D-Announce mailing list i-d-annou...@ietf.orgmailto:i-d-annou...@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt ___ Softwires mailing list Softwires@ietf.orgmailto:Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires -- Dr. Maoke CHEN, FreeBit Co., Ltd. 13F, 3-6 Maruyamacho, Shibuya-ku, Tokyo 150-0044 Japan Tel: +81 80 3930 1704 e-mail: m.c...@freebit.netmailto:m.c...@freebit.net -- ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Analysis of Port Indexing Algorithms (draft-bsd-softwire-stateless-port-index-analysis)
Hi Rémi, Please see inline. Cheers, Med -Message d'origine- De : Rémi Després [mailto:despres.r...@free.fr] Envoyé : mercredi 7 septembre 2011 10:56 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : GangChen; softwires@ietf.org; Wojciech Dec Objet : Re: [Softwires] Analysis of Port Indexing Algorithms (draft-bsd-softwire-stateless-port-index-analysis) Med, More comments in line. Le 7 sept. 2011 à 07:35, mohamed.boucad...@orange-ftgroup.com mohamed.boucad...@orange-ftgroup.com a écrit : Dear Gang, As per the following property: o Complexity: Complexity level of the algorithm I agree this can be split into several sub items but in -00 we used it to reflect the level of complexity to understand the algorithm and to configure it. These are two different subjects. Difficulty to understand can be due to insufficient quality of explanations. In this respect, I know what I have written in the past was quite perfectible. I expect the 4rd-addmapping draft to be clearer on several points, but it certainly can be clarified further. Questions raised in the WG are helpful for that. Med: This is IMHO an important aspect for the operational teams who are in charge of dimensioning the A+P space. Easiness of usability is important. Difficulty to configure is rather minimal with solutions that are completely stateless. Having High complexity for 4rd-addmapping can therefore be misleading. Med: Not all the port indexing schemes on the table have the same complexity level. As I mentioned earlier, we need to depict this somehow. I would really appreciate if you can evaluate other port algorithms and share your evaluation. (The Complexity criterion is also commented in my previous mail.) Cheers, RD I know Nejc had some experience in configuring for instance Murakami's 4rd implementation. He found that it was much more complex to understand than the portrange algorithm and the modulo algorithm. The text will be clarified. Cheers, Med -Message d'origine- De : GangChen [mailto:phdg...@gmail.com] Envoyé : mardi 6 septembre 2011 18:10 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : softwires@ietf.org; Wojciech Dec Objet : Re: [Softwires] Analysis of Port Indexing Algorithms (draft-bsd-softwire-stateless-port-index-analysis) Hello Authors, I think the draft did really good analysis on several mapping algorithm, especially properties evaluation part. One question for clarification: I saw several properties are COMPLEXITY related. Just wondering to know what kind of criteria you adopt to judge different levels(i.e. Low, Medium, High) ? I guess it would be beneficial if you could take some words to describe the criteria. Many thanks Gang 2011/9/6, mohamed.boucad...@orange-ftgroup.com mohamed.boucad...@orange-ftgroup.com: Dear all, We have just submitted an I-D analysing the port set algorithms we have on the table. A set of properties are used to characterize the port set algorithms. This is a call for review. In particular, we invite authors of the following proposals to review their section: o [I-D.boucadair-behave-ipv6-portrange] o [I-D.xli-behave-divi] o [I-D.murakami-softwire-4v6-translation] o [I-D.murakami-softwire-4rd] o [I-D.despres-softwire-4rd-addmapping] Questions, suggestions, corrections and contributions are more than welcome. Thank you. Cheers, Med -Message d'origine- De : i-d-announce-boun...@ietf.org [mailto:i-d-announce-boun...@ietf.org] De la part de internet-dra...@ietf.org Envoyé : lundi 5 septembre 2011 18:33 À : i-d-annou...@ietf.org Objet : I-D Action: draft-bsd-softwire-stateless-port-index-analysis-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Analysis of Port Indexing Algorithms Author(s) : Mohamed Boucadair Nejc Skoberne Wojciech Dec Filename: draft-bsd-softwire-stateless-port-index-analysis-00.txt Pages : 25 Date: 2011-09-05 This document analyzes various algorithm proposals for building port sets. These algorithms are used to encode the range of ports in an IPv6 address and prefix in the context of stateless solutions. The ultimate goal of this analysis is to converge on one or a set of algorithms to be used by all stateless solutions. This is a companion document to [I-D.boucadair-softwire-stateless-rfc6052-update]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-bsd-softwire-stateless-port-index-analysis-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-bsd-softwire-stateless-port-index-analysis-00.txt ___ I-D-Announce mailing list
Re: [Softwires] Analysis of Port Indexing Algorithms (draft-bsd-softwire-stateless-port-index-analysis)
Hi Rémi, Please see inline. Cheers, Med De : Rémi Després [mailto:despres.r...@laposte.net] Envoyé : mercredi 7 septembre 2011 14:06 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : Jacni Qin; Softwires-wg; Wojciech Dec Objet : Re: [Softwires] Analysis of Port Indexing Algorithms (draft-bsd-softwire-stateless-port-index-analysis) Oops, e) to be deleted from the list below (same feature as c)) Le 7 sept. 2011 à 11:02, Rémi Després a écrit : Hi Med, Thank you for the detailed analysis of our draft. Please see some first comments in line. Le 7 sept. 2011 à 07:22, mohamed.boucad...@orange-ftgroup.commailto:mohamed.boucad...@orange-ftgroup.com mohamed.boucad...@orange-ftgroup.commailto:mohamed.boucad...@orange-ftgroup.com a écrit : Hi Jacni, Please see inline. Cheers, Med De : Jacni Qin [mailto:ja...@jacni.com] Envoyé : mardi 6 septembre 2011 11:30 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : Wojciech Dec; softwires@ietf.orgmailto:softwires@ietf.org Objet : Re: [Softwires] Analysis of Port Indexing Algorithms (draft-bsd-softwire-stateless-port-index-analysis) hi Med, all, Thanks for writing this, it helps. A couple of quick comments below, *) Is the focus of the document (properties used) on the whole address architecture/format, or just on the algorithms to build port sets? As in some proposals, for example 4rd, the port indexing algorithm can be an independent part and decoupled from the address format. [Med] All port indexing schemes are independent of the address format itself, but we included some properties to reflect some design choices made my the authors of these solutions on the address format. FWIW, we will submit soon a list of requirements to be followed by stateless address/prefix format. IMHO, separating port-set indexing and IPv6 address format would be a clarification. [Med] OK, I will do. Here is a tentative contribution in this direction. Major criteria to evaluate port-indexing methods: [Med] In fact we are not evaluating the algorithm at this stage but only characterizing them with a set of properties. a) Fairness (no CPE gets well-known ports 0-1023) [Med] We indicate whether this range is excluded or not in the properties table. But, this can be seen also as a loss of port utilization efficiency. b) RTP/RTCP compatibility c) Stateless BR support of multiple CPE-port-set sizes [Med] As I mentioned in another e-mail, I added two properties in the table: o Differentiated Port Sets (Network Level): Capability to assign port sets of different sizes to customers attached to the same network. o Differentiated Port Sets (same IP address): Capability to assign port sets of different sizes to customers assigned with the same IPv4 address. d) UPnP friendliness (interleaved port sets) [Med] I guess you are referring to IGD:1. Difficult to assess for at least two reasons: (1) IGD:1 is broken and (2) implementations adopt several behaviour (incremental or random). e) Support of differentiated sharing ratios without per-CPE states in BRs Major criteria to evaluate IPv6 address formats of CPEs: i) Compatibility with IPv4 routes between CPEs as direct as IPv6 routes. (This implies A+P-IPv6 derivation without per-CPE state) j) No impact on the assignment plan of IPv6 prefixes to CPE's. (This excludes in particular full IPv4 addresses in CPE IPv6 prefixes.) k) Optional support of CPE cascades (the suffix field of the 4rd mapping proposals, explained in the 4rd-addmapping draft) OTOH, complexity comparisons, although worth keeping in mind at this stage, are premature (largely subjective before optimized codes have been worked on for stabilized methods). So far, making sure all methods have AFAIK O(1) complexity should IMHO be be sufficient. When clear about other criteria, thin optimization can become relevant. ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Analysis of Port Indexing Algorithms (draft-bsd-softwire-stateless-port-index-analysis)
Dear Gang, The logic we adopted for guessing complexity of a valid port and for the whole range is as mentioned in http://tools.ietf.org/html/draft-bsd-softwire-stateless-port-index-analysis-00#section-2: In each analyzed port derivation algorithm, an attacker may implement a redirection loop to detect a significant amount of allowed ports. For all monotonously scattered schemes, the whole Port-Set may be deduced by extrapolation while this is not applicable for contiguous port ranges (because no information about port bounds is leaked in the IPv4-translatable IPv6 address). Cheers, Med -Message d'origine- De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la part de GangChen Envoyé : jeudi 8 septembre 2011 18:19 À : Simon Perreault Cc : softwires@ietf.org Objet : Re: [Softwires] Analysis of Port Indexing Algorithms (draft-bsd-softwire-stateless-port-index-analysis) 2011/9/7, Simon Perreault simon.perrea...@viagenie.ca: mohamed.boucad...@orange-ftgroup.com wrote, on 09/07/2011 03:28 AM: What I have done is I clarified the text as follows: o Complexity: Reflects the complexity level of understanding the algorithm and the expected complexity to configure an implementation. A subjective criteria is not very useful for comparing algorithms. +1 Here's a suggestion: configuration complexity could be measured in terms of the number of parameters necessary. This is an objective criteria. Criteria should be as objective as possible, especially for Guessing Complexity of a Valid Port Not sure whether there are some mathematical guidance could help to evaluate computational complexity? Maybe time complexity is a candidate BRs Gang ___ 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] Requirements for extending IPv6 addresses with port range (draft-boucadair-softwire-stateless-requirements)
Dear all, To avoid confusion with address format discussion, we generated an document grouping a set of requirements to be met by stateless solutions. I know some of you have in mind a set of features to be supported. These features may be translated into requirements. Comments and inputs are welcome. The document is available at: http://tools.ietf.org/html/draft-boucadair-softwire-stateless-requirements-00 Cheers, Med ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
[Softwires] Stateless Motivations I-D: call for review
Dear all, A new version of the motivations I-D is available at: http://tools.ietf.org/html/draft-ietf-softwire-stateless-4v6-motivation-00 I updated the I-D according to the conclusions of this thread: http://www.ietf.org/mail-archive/web/softwires/current/msg02558.html. The changes since last version are as follows: (1) The terminology has been clarified: state, session state, user-session state, stateless, ... (2) Add a discussion about IPv4 port utilisation and IPv4 port randomization as per J. Arkko's review. (3) A synthesized list of motivations has been added This is a call for review, input, correction, etc. Your review is more than welcome. Cheers, Med ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Analysis of Port Indexing Algorithms (draft-bsd-softwire-stateless-port-index-analysis)
Hi Rémi, Thank you for this input. As for the differentiated port sets, I'm planning to add the following properties to -01 of draft-bsd-* (need to be discussed with my co-authors): o Differentiated Port Sets (Bound to the same IP address): Capability to assign port sets of different sizes to customers assigned with the same IPv4 address. o Differentiated Port Sets (Network Level): Capability to assign port sets of different sizes to customers attached to the same network. These properties aim to assess the ability of the solution to define different classes of customers having distinct port usage needs. This feature can be supported by dedicating distinct IPv4 address pools but this impacts route aggregation. To double check the ability of 4rd-addmapping algo to support differentiated port sets without any state on the BR, could you please provide some examples to show this behaviour? FWIW, below are listed some configuration proposals: (1) Differentiated port sets bound to distinct IPv4 address * Port sets of 4096 ports when the shared IPv4 belongs to POOL_IPv4@_1 * Port sets of 1024 ports when the shared IPv4 belongs to POOL_IPv4@_2 (2) Differentiated port sets bound to the same IPv4 address (Because 0-4095 range is excluded, (n+1)*4096 + m*1024 = 2^16)) * Port sets of 4096 ports assigned to n CPEs * Port sets of 1024 ports assigned to m CPEs Thanks. Cheers, Med -Message d'origine- De : Rémi Després [mailto:despres.r...@laposte.net] Envoyé : lundi 12 septembre 2011 12:01 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : Softwires-wg; Wojciech Dec Objet : Re: [Softwires] Analysis of Port Indexing Algorithms (draft-bsd-softwire-stateless-port-index-analysis) Hi Med, Here is an update concerning 4rd-addmapping in this draft (sec 2.1.6): +---+-+ | Property | Value | +---+-+ |Complexity | -- | | Address Sharing Ratio | 1:2^p, p up to 14 | | Number of ports in a Port-Set | 2^p * 15/16 | | Guessing Complexity of a Valid Port | -- | | Guessing Complexity of the whole Port-Set | -- | |Excluded ports | 0-4095, to be 0-1023| | Minimal Sharing Ratio | 1:1 | | Maximal Sharing Ratio | 1:16K | |Multiple Port Sets | Supported | | Differentiated Port Sets | Supported | | DomPref Flexibility | Supported | |IPv4 traffic Isolation | Supported | |Prefix Aggregation | Preserved | |Encode Routing Bits in 64 bits | Supported | | Compliancy with RTP/RTCP | Compliant | +---+-+ The line on Multiple Port Sets has been kept, but you announcement that it will be deleted is understood and approved. It is also understood that you intend to distinguish Differentiated port set sizes Per-customer from Per customer class (a clarifying distinction) A suggestion is to also distinguish between Per-customer with PRR states from Per customer without PRR states. (The new 4rd has been designed to support the latter, which is useful for direct CPE-CPE routes. This isn't the case of all proposals.) Another criterion that differentiates proposals is whether the port set derivation depends on Domain-specific parameters, or is purely algorithmic without parameter. As we discussed, I also work on tables listing differentiating features of proposed solutions. They distinguish functional features of: - port-set specifications - IPv6 address formats of CPEs and AFTRs - Packet formats for IPv6-domain traversal They are intended to be easily modifiable, so as to be a temporary tool to facilitate discussion. FYI, Alain having expressed interest in having them in draft form before the meeting, I plan to edit the draft this week. Cheers, RD Le 5 sept. 2011 à 18:44, mohamed.boucad...@orange-ftgroup.com mohamed.boucad...@orange-ftgroup.com a écrit : Dear all, We have just submitted an I-D analysing the port set algorithms we have on the table. A set of properties are used to characterize the port set algorithms. This is a call for review. In particular, we invite authors of the following proposals to review their section: o [I-D.boucadair-behave-ipv6-portrange] o [I-D.xli-behave-divi] o [I-D.murakami-softwire-4v6-translation] o [I-D.murakami-softwire-4rd] o [I-D.despres-softwire-4rd-addmapping] Questions, suggestions, corrections and
Re: [Softwires] Analysis of Port Indexing Algorithms (draft-bsd-softwire-stateless-port-index-analysis)
Hi Rémi, Thank you or your answer but my question was not on the CPE side but the operations at the border router side. Cheers, Med -Message d'origine- De : Rémi Després [mailto:despres.r...@laposte.net] Envoyé : lundi 12 septembre 2011 17:05 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : Softwires-wg Objet : Re: [Softwires] Analysis of Port Indexing Algorithms (draft-bsd-softwire-stateless-port-index-analysis) Le 12 sept. 2011 à 16:18, mohamed.boucad...@orange-ftgroup.com mohamed.boucad...@orange-ftgroup.com a écrit : ... To double check the ability of 4rd-addmapping algo to support differentiated port sets without any state on the BR, could you please provide some examples to show this behaviour? FWIW, below are listed some configuration proposals: With 4rd-addmapping, of port-set sizes are directly derived from lengths of delegated IPv6 prefixes. Thus, if CPEs A and B have IPv6 prefixes of respective lengths L and L+k, the port set of B is 2^k times smaller than that of A. Besides that, IPv6 prefixes are assigned without any constraint coming from IPv4. (1) Differentiated port sets bound to distinct IPv4 address * Port sets of 4096 ports when the shared IPv4 belongs to POOL_IPv4@_1 * Port sets of 1024 ports when the shared IPv4 belongs to POOL_IPv4@_2 (2) Differentiated port sets bound to the same IPv4 address (Because 0-4095 range is excluded, (n+1)*4096 + m*1024 = 2^16)) * Port sets of 4096 ports assigned to n CPEs * Port sets of 1024 ports assigned to m CPEs First, note that, because of privileged-port exclusion for fairness, port-set sizes of 4rd are 15/16 * 2^k. For (1): - POOL_IPv4@_1 has IPv6 prefixes having 4-bit Port-set IDs (and have 15/16*4096=3840 ports per CPE). - POOL_IPv4@_1 has IPv6 prefixes having 6-bit Port-set IDs (and have 15/16*1024=960 ports per CPE). For (2): Assign IPv6 prefixes of length L to n CPEs, and IPv6 prefixes of length L+2 to m CPEs. OK? Cheers, RD ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Analysis of Port Indexing Algorithms (draft-bsd-softwire-stateless-port-index-analysis)
Hi Rémi, I didn't get my answer yet. I'm looking for the explanation about the behaviour of an 6/4 interconnection node receiving IPv4 packets destined to CPEs assigned with port sets of different sizes. What is the configuration of that node? Cheers, Med -Message d'origine- De : Rémi Després [mailto:despres.r...@laposte.net] Envoyé : mardi 13 septembre 2011 19:42 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : Softwires-wg Objet : Re: [Softwires] Analysis of Port Indexing Algorithms (draft-bsd-softwire-stateless-port-index-analysis) Le 13 sept. 2011 à 18:08, mohamed.boucad...@orange-ftgroup.com a écrit : Hi Rémi, Thank you or your answer but my question was not on the CPE side but the operations at the border router side. The point is that, with the new 4rd, an AFTR that sends an IPv4 packet to a CPE doesn't need to know the length of the CPE IPv6 prefix of that BR. This is a major difference with the old 4rd where this length was a rule parameter. (It is now a parameter only with the CPE-cascade option, to be ignored for this discussion.) As detailed in Figure 2, the BR includes in the subnet prefix of the IPv6 address L bits from the A+P port. This length L is 14 bits unless it has to be limited for this prefix to fit into 64 bits. The result can be a subnet prefix that typically differs from the CPE IPv6 prefix, with some extra port bits after the CPE IPv6 prefix. However, because the subnet prefix does start with the CPE IPv6 prefix, the packet reaches the CPE. There, the 4rd IID is enough for the packet to be recognized as a 4rd packet. Is this, now, the explanation you were looking for? Cheers, RD Cheers, Med -Message d'origine- De : Rémi Després [mailto:despres.r...@laposte.net] Envoyé : lundi 12 septembre 2011 17:05 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : Softwires-wg Objet : Re: [Softwires] Analysis of Port Indexing Algorithms (draft-bsd-softwire-stateless-port-index-analysis) Le 12 sept. 2011 à 16:18, mohamed.boucad...@orange-ftgroup.com mohamed.boucad...@orange-ftgroup.com a écrit : ... To double check the ability of 4rd-addmapping algo to support differentiated port sets without any state on the BR, could you please provide some examples to show this behaviour? FWIW, below are listed some configuration proposals: With 4rd-addmapping, of port-set sizes are directly derived from lengths of delegated IPv6 prefixes. Thus, if CPEs A and B have IPv6 prefixes of respective lengths L and L+k, the port set of B is 2^k times smaller than that of A. Besides that, IPv6 prefixes are assigned without any constraint coming from IPv4. (1) Differentiated port sets bound to distinct IPv4 address * Port sets of 4096 ports when the shared IPv4 belongs to POOL_IPv4@_1 * Port sets of 1024 ports when the shared IPv4 belongs to POOL_IPv4@_2 (2) Differentiated port sets bound to the same IPv4 address (Because 0-4095 range is excluded, (n+1)*4096 + m*1024 = 2^16)) * Port sets of 4096 ports assigned to n CPEs * Port sets of 1024 ports assigned to m CPEs First, note that, because of privileged-port exclusion for fairness, port-set sizes of 4rd are 15/16 * 2^k. For (1): - POOL_IPv4@_1 has IPv6 prefixes having 4-bit Port-set IDs (and have 15/16*4096=3840 ports per CPE). - POOL_IPv4@_1 has IPv6 prefixes having 6-bit Port-set IDs (and have 15/16*1024=960 ports per CPE). For (2): Assign IPv6 prefixes of length L to n CPEs, and IPv6 prefixes of length L+2 to m CPEs. OK? Cheers, RD ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
[Softwires] RE : Analysis of Port Indexing Algorithms (draft-bsd-softwire-stateless-port-index-analysis)
Hi Behcet, This property aims to assess if the proposed algorithms: 1. Preserve the port parity as discussed in Section 4.2.2 of [RFC4787]. and 2. Preserve port contiguity as discussed in Section 4.2.3 of [RFC4787] (i.e., RTCP=RTP+1). An elaboration is also provided in: http://tools.ietf.org/html/draft-boucadair-softwire-stateless-requirements-00#section-2: REQ#8: Applications requiring even/odd and port contiguity (e.g., RTP/RTCP) SHOULD NOT be broken due to the port set assignment scheme. Traditionally the voice/video applications that use RTP and RTCP would specify only the RTP port that the application would use for streaming the RTP data. The inherent assumption is that the RTCP traffic will be sent on the next higher port. Even though RFC3605 defines a new attribute for explicitly specifying the RTCP attribute for the SDP-based applications, but since it is not a MUST to use this attribute, there are still applications that are not compliant with this RFC. There are also non-SDP based applications that use RTP/RTCP like H323, that make the assumption that RTCP streaming will happen on RTP+1 port. Cheers, Med De : Behcet Sarikaya [behcetsarik...@yahoo.com] Date d'envoi : mercredi 14 septembre 2011 17:32 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : Softwires-wg Objet : Re: [Softwires] Analysis of Port Indexing Algorithms (draft-bsd-softwire-stateless-port-index-analysis) Hi Med, Thanks for the analysis. I have a small question: Compliance with RTP/RTCP applications what does this mean? (BTW this is what my spell checker gave :-) ) Regards, Behcet Hi Rémi, Thank you or your answer but my question was not on the CPE side but the operations at the border router side. Cheers, Med -Message d'origine- De : Rémi Després [mailto:despres.r...@laposte.net] Envoyé : lundi 12 septembre 2011 17:05 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : Softwires-wg Objet : Re: [Softwires] Analysis of Port Indexing Algorithms (draft-bsd-softwire-stateless-port-index-analysis) Le 12 sept. 2011 à 16:18, mohamed.boucad...@orange-ftgroup.com mohamed.boucad...@orange-ftgroup.com a écrit : ... To double check the ability of 4rd-addmapping algo to support differentiated port sets without any state on the BR, could you please provide some examples to show this behaviour? FWIW, below are listed some configuration proposals: With 4rd-addmapping, of port-set sizes are directly derived from lengths of delegated IPv6 prefixes. Thus, if CPEs A and B have IPv6 prefixes of respective lengths L and L+k, the port set of B is 2^k times smaller than that of A. Besides that, IPv6 prefixes are assigned without any constraint coming from IPv4. (1) Differentiated port sets bound to distinct IPv4 address * Port sets of 4096 ports when the shared IPv4 belongs to POOL_IPv4@_1 * Port sets of 1024 ports when the shared IPv4 belongs to POOL_IPv4@_2 (2) Differentiated port sets bound to the same IPv4 address (Because 0-4095 range is excluded, (n+1)*4096 + m*1024 = 2^16)) * Port sets of 4096 ports assigned to n CPEs * Port sets of 1024 ports assigned to m CPEs First, note that, because of privileged-port exclusion for fairness, port-set sizes of 4rd are 15/16 * 2^k. For (1): - POOL_IPv4@_1 has IPv6 prefixes having 4-bit Port-set IDs (and have 15/16*4096=3840 ports per CPE). - POOL_IPv4@_1 has IPv6 prefixes having 6-bit Port-set IDs (and have 15/16*1024=960 ports per CPE). For (2): Assign IPv6 prefixes of length L to n CPEs, and IPv6 prefixes of length L+2 to m CPEs. OK? Cheers, RD ___ 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] Analysis of Port Indexing Algorithms (draft-bsd-softwire-stateless-port-index-analysis)
Dear Gang, Please see inline. Cheers, Med -Message d'origine- De : GangChen [mailto:phdg...@gmail.com] Envoyé : samedi 17 septembre 2011 10:29 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : Simon Perreault; softwires@ietf.org Objet : Re: [Softwires] Analysis of Port Indexing Algorithms (draft-bsd-softwire-stateless-port-index-analysis) Dear Med, The logic we adopted for guessing complexity of a valid port and for the whole range is as mentioned in http://tools.ietf.org/html/draft-bsd-softwire-stateless-port-index-analysis-00#section-2: In each analyzed port derivation algorithm, an attacker may implement a redirection loop to detect a significant amount of allowed ports. For all monotonously scattered schemes, the whole Port-Set may be deduced by extrapolation while this is not applicable for contiguous port ranges (because no information about port bounds is leaked in the IPv4-translatable IPv6 address). It seems same criteria applied for these two properties. But why would you get different complexity level for each property targeting to same algorithm? (e.g. For portrange judgment, Guessing Complexity of a Valid Port is low; Guessing Complexity of the whole Port-Set is Medium) Med: For a contiguous port range, if you know port N it is easy to guess the next port. This is why we indicated Low but since the port range bounds are not leaked in the port itself, it is not easy to guess the whole port (hence the Medium). But still the loop vector above applies for all port set allocation algorithms and under some conditions the server may by itself detects the whole port set. For me, the statement is more proper for whole Port-Set prediction. I guess we need to add texts for valid Port prediction? Med: any text proposal is welcome. ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] RE : Analysis of Port Indexing Algorithms (draft-bsd-softwire-stateless-port-index-analysis)
Hi Behcet, It is part of the service provider business to offer services which rely on the 0-1023 range even in a shared address environment (e.g., host an FTP server, etc.). Because statically not all subscribers use these features, the whole 0-1023 range may be assigned only to few subscribers (whether this is on-demand or during the service subscription, is out of scope of what we are doing here). As such, the ability to assign or not that port range should be left to each SP and not excluded by default. We analyzed two types of algorithms in draft-bsd: * algorithms which exclude by construction that range. * algorithms which leave excluding that range to the SP: i.e., the algorithm allows to generate a port range including the 0-1023 but the SP may decide to not assign it to any requesting user. This should be part of the SP policies. Cheers, Med De : Behcet Sarikaya [mailto:sarikaya2...@gmail.com] Envoyé : mardi 20 septembre 2011 08:36 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : Softwires-wg Objet : Re: RE : [Softwires] Analysis of Port Indexing Algorithms (draft-bsd-softwire-stateless-port-index-analysis) Hi Med, I thought excluding well known ports is good idea because all nodes need it. Below you seem to agree that sharing them may be useless. Why is it service provider issue? It seems like address sharing changes the basic characteristic of the port number space :-). Regards, Behcet On Mon, Sep 19, 2011 at 2:38 AM, mohamed.boucad...@orange.commailto:mohamed.boucad...@orange.com wrote: Hi Behcet, Excluding 0-4095 range is not justified in those documents. Excluding by default this range may be considered by some service providers as waste of ports. Excluding 0-1023 range may be understood by port utilisation fairness but still be considered as an inefficiency if it is excluded by the algorithm and not let to the taste of service providers to assign or not that range. Sharing the 0-1023 between several users may be useless (e.g. is valid scenario to assign port 80 without port 443?). Cheers, Med -Message d'origine- De : Behcet Sarikaya [mailto:behcetsarik...@yahoo.commailto:behcetsarik...@yahoo.com] Envoyé : vendredi 16 septembre 2011 17:02 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : Softwires-wg Objet : Re: RE : [Softwires] Analysis of Port Indexing Algorithms (draft-bsd-softwire-stateless-port-index-analysis) Hi Med, Another question: On page 19, you have: The limit of 0-4095 ports appears rather arbitrary and represents a likely waste of ports, if not more that an operator may be interested in utilizing. Why? Shouldn't they be excluded? Regards, Behcet ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Keeping support of CE IPv4 prefixes in the v4/v6 address mapping?
Hi Rémi, all, Since there is only an excerpt of e-mails, I lost the context. Could you please clarify what is the issue discussed here? Thanks. Cheers, Med -Message d'origine- De : Rémi Després [mailto:despres.r...@laposte.net] Envoyé : jeudi 3 novembre 2011 10:05 À : Jacni Qin Cc : Alain Durand; Ole Troan; BOUCADAIR Mohamed OLNC/NAD/TIP; Satoru Matsushima; Softwires WG Objet : Keeping support of CE IPv4 prefixes in the v4/v6 address mapping? Le 3 nov. 2011 à 09:50, Jacni Qin a écrit : if the MAP just covers shared address with one single sharing ratio for one domain, the design will be greatly simplified? Requiring ISPs to maintain IPv4 routing in their networks, just to serve the few users that need to keep IPv4 prefixes, seems to me a step backward. Besides, I have serious doubts about greatly simplified. I mean for the design of the address/port mapping algorithm, not the transport mechanism. Yes, but I don't see the great simplification of the algorithm. Keeping it general enough to support IPv4 prefixes is AFAIK easy. It doesn't prevent deployments where, IPv4 prefixes being not supported, fields can be at places that may be found more convenient. Maybe you can be more specific on your concern. Cheers, RD ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
[Softwires] Closing draft-ietf-softwire-stateless-4v6-motivation
Dear WG members, I would like to close this document so that we can meet the following item from the WG Charter: 4. Developments for stateless legacy IPv4 carried over IPv6 - develop a solution motivation document to be published as an RFC - develop a protocol specification response to the solution motivation document; this work item will not be taken through Working Group last call until the solution motivation document has been published or approved for publication Except the a comment asking to include a new section to compare stateful vs. stateless, no further comments have been received. I didn't considered adding the proposed new section because IMO it is out of scope of this document. That section can justify in its own a dedicated draft. As for the next step, I see two options: (1) Either issue a WG LC, or (2) Withdraw the document and update the WG charter. WG members, please advise. Cheers, Med ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Closing draft-ietf-softwire-stateless-4v6-motivation
Dear Cameron, Yes, I know it is tempting to have such section but it won't help in making a decision and, furthermore, it may maintain a tension between stateless and stateful camps. We tried in the document to be neutral as much as possible and avoid claiming stateless is superior to stateful or stateful is superior to stateless. I personally think both stateful and stateless solutions are needed. It is up to each service provider, taking into account its own environment and constraint, to select the flavour of solutions which fit its needs. The selection may even be complex given the diversity of networks and services managed by (large) service providers. Cheers, Med De : Cameron Byrne [mailto:cb.li...@gmail.com] Envoyé : samedi 11 février 2012 15:31 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : softwires@ietf.org Objet : Re: [Softwires] Closing draft-ietf-softwire-stateless-4v6-motivation On Feb 10, 2012 2:20 AM, mohamed.boucad...@orange.commailto:mohamed.boucad...@orange.com wrote: Dear WG members, I would like to close this document so that we can meet the following item from the WG Charter: 4. Developments for stateless legacy IPv4 carried over IPv6 - develop a solution motivation document to be published as an RFC - develop a protocol specification response to the solution motivation document; this work item will not be taken through Working Group last call until the solution motivation document has been published or approved for publication Except the a comment asking to include a new section to compare stateful vs. stateless, no further comments have been received. I didn't considered adding the proposed new section because IMO it is out of scope of this document. That section can justify in its own a dedicated draft. I find this omission disappointing. There is a common assumption that stateless is superior to stateful, but it is not quantified anywhere. It seems all this stateless work hinges on this assumption without any quantification. Honestly, the omission makes me believe the case of stateless being superior is dubious. Cb As for the next step, I see two options: (1) Either issue a WG LC, or (2) Withdraw the document and update the WG charter. WG members, please advise. Cheers, Med ___ 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] Closing draft-ietf-softwire-stateless-4v6-motivation
Dear chairs, WG members, The answers received so far are in favour of initiating a WG LC on this document. As an editor of the document, I would like to progress this document for the next IETF meeting. Chairs, could you please issue the WG LC? Thanks. Cheers, Med -Message d'origine- De : francis.dup...@fdupont.fr [mailto:francis.dup...@fdupont.fr] Envoyé : samedi 11 février 2012 09:30 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : softwires@ietf.org Objet : Re: [Softwires] Closing draft-ietf-softwire-stateless-4v6-motivation In your previous mail you wrote: (1) Either issue a WG LC, or +1 francis.dup...@fdupont.fr ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
[Softwires] draft-penno-softwire-sdnat vs. draft-cui-softwire-b4-translated-ds-lite
Hi Reinaldo, all, I read the updated version of draft-penno-softwire-sdnat. I like this new version. Below some questions for clarification: (1) draft-penno is converging to what is documented in draft-cui-softwire-b4-translated-ds-lite: (*) Question 1: It is not clear in text if there is a second NAT in the AFTR or not. Could you please confirm/infirm a second NAT is present? (*) Question 2: If yes, is there any reason why you want to maintain that second NAT? (*) Question 3: If the public IP address assigned by the AFTR is not known to the port-restricted CPE, some applications may fail (referral). How the CPE will make a distinction between the external IP address to be assigned in the WAN and the one used in the AFTR? If UPnP is used, the WAN IP address should not be returned. (2) Unlike draft-penno-*, draft-cui-* does not mandate any proffered provisioning means for port ranges; a list of alternatives is provided in draft-cui-* without any preference (this is deployment- specific): o DHCPv4: the DHCPv4 protocol should be extended to support port-set allocation [I-D.bajko-pripaddrassignhttp://tools.ietf.org/html/draft-cui-softwire-b4-translated-ds-lite-05#ref-I-D.bajko-pripaddrassign]. Besides, the DHCP message should send to the concentrator over IPv6. The concentrator can be the DHCP server or DHCP relay agent[I-D.ietf-dhc-dhcpv4-over-ipv6]. o PCP[I-D.ietf-pcp-base]: an initiator can launch multiple PCP requests simultaneously to acquire a number ports within the same IPv4 address, or use [I-D.tsou-pcp-natcoordhttp://tools.ietf.org/html/draft-cui-softwire-b4-translated-ds-lite-05#ref-I-D.tsou-pcp-natcoord] for one-time port-set allocation. o DHCPv6: the DHCPv6 protocol should be extended to support port-set allocation [I-D.boucadair-dhcpv6-shared-address-optionhttp://tools.ietf.org/html/draft-cui-softwire-b4-translated-ds-lite-05#ref-I-D.boucadair-dhcpv6-shared-address-option]. o IPCP: IPCP should be extended to carry the port-set. [RFC6431http://tools.ietf.org/html/rfc6431] gives an example. (*) Question 4: Given this list, is there really a need for the proposed ICMP-based solution? (*) Question 5: draft-penno-* says: A stateless DS-Lite CPE MUST implement the DHCPv4 client relay option defined in [I-D.ietf-dhc- dhcpv4-over-ipv6] to learn is external IPv4 address.. Question 5-1: Why MUST? IMHO, this is deployment-specific. Question 5-2: By external IPv4 address, do you mean the address to be assigned in the AFTR (if any)? or the one to be used in the WAN interface of the CPE? (3) draft-penno-* advocates it is deterministic but this feature can be enforced in any IPv4 address sharing technique: (*) Question 6: Is there any particular reason draft-penno-* does not mention draft-donley-behave-deterministic-cgn? Cheers, Med ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] draft-penno-softwire-sdnat vs. draft-cui-softwire-b4-translated-ds-lite
Hi Francis, Please see inline. Cheers, Med -Message d'origine- De : francis.dup...@fdupont.fr [mailto:francis.dup...@fdupont.fr] Envoyé : mardi 13 mars 2012 17:56 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : draft-penno-softwire-sd...@tools.ietf.org; Softwires WG; draft-cui-softwire-b4-translated-ds-lite Objet : Re: [Softwires] draft-penno-softwire-sdnat vs. draft-cui-softwire-b4-translated-ds-lite In your previous mail you wrote: (*) Question 1: It is not clear in text if there is a second NAT in the AFTR or not. Could you please confirm/infirm a second NAT is present? = there is one but: - it translates only port numbers following an algorithm Med: Ok, thanks. But this is not clear in the -02 of draft-penno-*. - the NAT is not strictly required: one can imagine to assign directly to a CPE its port range as it is visible from the Internet Med: Agree. (note: 1- it should be not what we want as it makes CPEs trivial to track, 2- it doesn't remove the mandatory check on source ports in the from CPE to the Internet way) Med: I failed to get your first point. Could you please clarify? Thanks. (*) Question 2: If yes, is there any reason why you want to maintain that second NAT? = I can see at least 2 reasons: - make CPE simplers (only applications which need to know what is a port number seen from the Internet side have to enter into the second NAT details, i.e., typically the PCP (/UPnP iGD/NAT-PMP/...) server on the CPE) Med: applications using referral need to know the external IP address. I failed to see why this is simpler compared to draft-cui-*. (*) Question 3: If the public IP address assigned by the AFTR is not known to the port-restricted CPE, some applications may fail (referral). How the CPE will make a distinction between the external IP address to be assigned in the WAN and the one used in the AFTR? If UPnP is used, the WAN IP address should not be returned. = my read of the SD-NAT mechanism is the public IP address is the same at each side of the SD-CGN. Med: This is not clear in -02 of the draft-penno-*. (2) Unlike draft-penno-*, draft-cui-* does not mandate any proffered provisioning means for port ranges; a list of alternatives is provided in draft-cui-* without any preference (this is deployment- specific): = but the ICMP-based solution is deeply broken so is it a real advantage? (*) Question 4: Given this list, is there really a need for the proposed ICMP-based solution? = see previous item (*) Question 5: draft-penno-* says: A stateless DS-Lite CPE MUST implement the DHCPv4 client relay option defined in [I-D.ietf-dhc- dhcpv4-over-ipv6] to learn is external IPv4 address.. Question 5-1: Why MUST? IMHO, this is deployment-specific. = no such specific: - it makes the reasonable assumption than IPv4 addresses are assigned using DHCPv4 Med: It is not reasonable when you don't have a DHCPv4 server but use PCP for instance. (*) Question 6: Is there any particular reason draft-penno-* does not mention draft-donley-behave-deterministic-cgn? = too many drafts...? Med: I think it is fair to cite draft-donley-*. More seriously I have more concerns about too simple algorithms deployed in the SD-CGN, for instance the: [1024...xxx] - [N...N-1024+xxx] where p' = p + N - 1024 is good for tests or demos but makes CPEs too easy to trace, I prefer what draft-tsou-softwire-port-set-algorithms-analysis calls GMA (still trivial to implement and to use but harder to trace). Med: We don't have the constraint of MAP so I would not exclude pseudo-random port set algos (see http://tools.ietf.org/html/draft-tsou-softwire-port-set-algorithms-analysis-01#section-3.3) ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] draft-penno-softwire-sdnat vs.draft-cui-softwire-b4-translated-ds-lite
Re-, Thanks Rajiv for the pointer. BTW unlike the constraints we have in MAP (e.g., the bits forming PSID must be adjacent), draft-cui-* and the like can use pseudo-random algorithms to generate port ranges. Cheers, Med -Message d'origine- De : Rajiv Asati (rajiva) [mailto:raj...@cisco.com] Envoyé : mardi 13 mars 2012 21:19 À : Francis Dupont; BOUCADAIR Mohamed OLNC/NAD/TIP; o...@cisco.com Cc : Softwires WG; draft-cui-softwire-b4-translated-ds-lite; draft-penno-softwire-sd...@tools.ietf.org Objet : RE: [Softwires] draft-penno-softwire-sdnat vs.draft-cui-softwire-b4-translated-ds-lite I prefer what draft-tsou-softwire-port-set-algorithms-analysis calls GMA (still trivial to implement and to use but harder to trace). I agree. GMA is defined here, btw - http://tools.ietf.org/html/draft-mdt-softwire-mapping-address- and-port-0 2#section-4.1 Cheers, Rajiv -Original Message- From: softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] On Behalf Of Francis Dupont Sent: Tuesday, March 13, 2012 12:56 PM To: mohamed.boucad...@orange.com Cc: Softwires WG; draft-cui-softwire-b4-translated-ds-lite; draft-penno- softwire-sd...@tools.ietf.org Subject: Re: [Softwires] draft-penno-softwire-sdnat vs.draft-cui-softwire-b4- translated-ds-lite In your previous mail you wrote: (*) Question 1: It is not clear in text if there is a second NAT in the AFTR or not. Could you please confirm/infirm a second NAT is present? = there is one but: - it translates only port numbers following an algorithm - the NAT is not strictly required: one can imagine to assign directly to a CPE its port range as it is visible from the Internet (note: 1- it should be not what we want as it makes CPEs trivial to track, 2- it doesn't remove the mandatory check on source ports in the from CPE to the Internet way) (*) Question 2: If yes, is there any reason why you want to maintain that second NAT? = I can see at least 2 reasons: - make CPE simplers (only applications which need to know what is a port number seen from the Internet side have to enter into the second NAT details, i.e., typically the PCP (/UPnP iGD/NAT-PMP/...) server on the CPE) (*) Question 3: If the public IP address assigned by the AFTR is not known to the port-restricted CPE, some applications may fail (referral). How the CPE will make a distinction between the external IP address to be assigned in the WAN and the one used in the AFTR? If UPnP is used, the WAN IP address should not be returned. = my read of the SD-NAT mechanism is the public IP address is the same at each side of the SD-CGN. (2) Unlike draft-penno-*, draft-cui-* does not mandate any proffered provisioning means for port ranges; a list of alternatives is provided in draft-cui-* without any preference (this is deployment- specific): = but the ICMP-based solution is deeply broken so is it a real advantage? (*) Question 4: Given this list, is there really a need for the proposed ICMP-based solution? = see previous item (*) Question 5: draft-penno-* says: A stateless DS-Lite CPE MUST implement the DHCPv4 client relay option defined in [I-D.ietf-dhc- dhcpv4-over-ipv6] to learn is external IPv4 address.. Question 5-1: Why MUST? IMHO, this is deployment-specific. = no such specific: - it makes the reasonable assumption than IPv4 addresses are assigned using DHCPv4 - it states DS-Lite so there is no direct IPv4 available - so IMHO the question is more about the DHCPv4-over-IPv6 application and is more for the DHC WG (BTW please don't bounce this issue between the two WGs, my idea is more to make a point about DHCPv4-over-IPv6 itself) Question 5-2: By external IPv4 address, do you mean the address to be assigned in the AFTR (if any)? or the one to be used in the WAN interface of the CPE? = if they are the same the answer is easy (3) draft-penno-* advocates it is deterministic but this feature can be enforced in any IPv4 address sharing technique: = BTW we need a better definition of deterministic. My proposal is it means the mapping follows an algorithm (and it is the case on the SD-CGN, BTW not on the SD-CPE). (*) Question 6: Is there any particular reason draft-penno-* does not mention draft-donley-behave-deterministic-cgn? = too many drafts...? More seriously I have more concerns about too simple algorithms deployed in the SD-CGN, for instance the: [1024...xxx] - [N...N-1024+xxx] where p' = p + N - 1024 is good for tests or demos but makes CPEs too easy to
Re: [Softwires] draft-penno-softwire-sdnat vs. draft-cui-softwire-b4-translated-ds-lite
Dear Qiong, Please see inline. Cheers, Med De : Qiong [mailto:bingxu...@gmail.com] Envoyé : mercredi 14 mars 2012 00:50 À : Francis Dupont Cc : BOUCADAIR Mohamed OLNC/NAD/TIP; Softwires WG; draft-cui-softwire-b4-translated-ds-lite; draft-penno-softwire-sd...@tools.ietf.org Objet : Re: [Softwires] draft-penno-softwire-sdnat vs. draft-cui-softwire-b4-translated-ds-lite (2) Unlike draft-penno-*, draft-cui-* does not mandate any proffered provisioning means for port ranges; a list of alternatives is provided in draft-cui-* without any preference (this is deployment- specific): = but the ICMP-based solution is deeply broken so is it a real advantage? [Qiong] In draft-cui-softwire-b4-translated-ds-lite, we have described the ICMP processing in section 10. And we have verified that it works fine in all ICMP-based protocols, e.g. ping, tracert, etc. There is no problem here. [Med] I know it is confusing but these are two distinct issues. draft-penno-* defines a new method using ICMP to learn ports. Please refer to http://tools.ietf.org/html/draft-penno-softwire-sdnat-02#section-5 ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] draft-penno-softwire-sdnat vs. draft-cui-softwire-b4-translated-ds-lite
Re-, Thanks Alain for the answers. Please see inline. Cheers, Med -Message d'origine- De : Alain Durand [mailto:adur...@juniper.net] Envoyé : mercredi 14 mars 2012 12:11 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : draft-penno-softwire-sd...@tools.ietf.org; Softwires WG; draft-cui-softwire-b4-translated-ds-lite Objet : Re: [Softwires] draft-penno-softwire-sdnat vs. draft-cui-softwire-b4-translated-ds-lite Hi Med, see inline response to your questions wrt sd-nat-02 On Mar 13, 2012, at 10:58 AM, mohamed.boucad...@orange.commailto:mohamed.boucadair@orange. com mohamed.boucad...@orange.commailto:mohamed.boucadair@orange. com wrote: (*) Question 1: It is not clear in text if there is a second NAT in the AFTR or not. Could you please confirm/infirm a second NAT is present? in sd-nat, packets originated by an sd-CPE will be 'shaped' to use the correct IPv4 address and port by the CPE before being encapsulated in IPv6. In that scenario, the AFTR decapsulate the traffic, check IPv4 address port range are indeed assigned to that IPv6 user, then forward the packet. There is only one level of NAT, done by the CPE Med: Ok, got it. This is the same as per draft-cui-*. In 'compatibility' mode, if the CPE fails to enforce the proper port range, the AFTR will perform a second level of NAT. Med: If the ultimate target is to remove the NAT module from the AFTR, I would see this compatibility mode as an implementation detail. BTW, why a CPE will fail to restrict the port? I see at least two cases: (1) want to grab more ports but this is not legitimate; I would vote for discarding those packets instead of NATing them. (2) the CPE does not support port-restriction: in that case why not use classic DS-Lite instead of NATing twice. (*) Question 3: If the public IP address assigned by the AFTR is not known to the port-restricted CPE, some applications may fail (referral). How the CPE will make a distinction between the external IP address to be assigned in the WAN and the one used in the AFTR? If UPnP is used, the WAN IP address should not be returned. In SD-Nat, the sd-CPE knows the external address via DHCPv4 over IPv6 Med: Ok, thanks. So for draft-penno-* two provisioning means are required (compared to basic DS-Lite) * DHCPv4 for IPv4 address allocation * ICMP for port range configuration. I must admit the rationale behind this choice is not clear to me. (*) Question 4: Given this list, is there really a need for the proposed ICMP-based solution? IMHO, not specifying the technology to get pot range and living this to implementation is a serious shortcoming. We need to standardize one method. Med: But the question is why ICMP-based method is needed? Why not using port-restricted DHCPv4 options for instance? ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] draft-penno-softwire-sdnat vs. draft-cui-softwire-b4-translated-ds-lite
Re-, Please see inline. Cheers, Med -Message d'origine- De : Alain Durand [mailto:adur...@juniper.net] Envoyé : jeudi 15 mars 2012 12:11 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : draft-penno-softwire-sd...@tools.ietf.org; Softwires WG; draft-cui-softwire-b4-translated-ds-lite Objet : Re: [Softwires] draft-penno-softwire-sdnat vs. draft-cui-softwire-b4-translated-ds-lite This is a deployment issue. You have 3 variants of DS-Lite CPEs: a) Basic 6333 DS-Lite, b) B4 translated DS-lite, and c) Stateless DS-Lite. You want to be able able to accommodate all 3 variants from the same AFTR. Re-Nating instead of dropping ensure that if a subscriber uses a variant b) when he is provisioned to use port restricted, then traffic still flows. Med: This is deployment-specific. The behaviour to follow when a port-restricted device issues port out of its allocated range should be IMO SP specific and can not be dictated by the specification. (*) Question 4: Given this list, is there really a need for the proposed ICMP-based solution? IMHO, not specifying the technology to get pot range and living this to implementation is a serious shortcoming. We need to standardize one method. Med: But the question is why ICMP-based method is needed? Why not using port-restricted DHCPv4 options for instance? 1) - we would have to define the DHCP port option. Not difficult but same amount of work as defining a new ICMP type. 2) - with the ICMP message, the ISP can change the port range without having to wait for the lease time of the DHCP option to expire. Med: Changing the size of the port range is part of planned operations. With DHCP, an SP can change the port range much in advance. This is nothing something which can be done without advanced planning. I don't see an advantage of ICMP here. This allows for more flexibility in micro-managing ports. Med: This is also doable with DHCP and PCP by tweaking the Lease and the Lifetime. 3) - if we use a DHCP option, the client has to proactively ask for it. If it does not, it will think it has the full IP address. That leads to situations that may be difficult to debug, as the customer will not understand why some TCP session works and some don't, the root cause being that the CPE does not have any feedback from the NAT in the AFTR Med: This doable with existing ICMP messages. Nothing prevent the AFTR to drop the packet and send back an ICMP Destination Unreachable message Code 3 Port unreachable error or Code 13 Communication administratively prohibited. 4) - so we'll need a new ICMP message anyway to signal the CPE that something is wrong if/when it sends packets outside of the range. Med: No need to define a new ICMP message for this. Why not using e.g. ICMP Type 3 Code 13? ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] draft-penno-softwire-sdnat vs. draft-cui-softwire-b4-translated-ds-lite
Hi Francis, Yes, you are right. There is no explicit method in PCP to get the external IP address. You know we have both asked for it in early days of PCP but the WG consensus was that we can mimic this by using MAP with short lifetime. As for your PS, this a discussion point for the PCP WG. Cheers, Med -Message d'origine- De : francis.dup...@fdupont.fr [mailto:francis.dup...@fdupont.fr] Envoyé : jeudi 15 mars 2012 19:22 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : draft-penno-softwire-sd...@tools.ietf.org; Softwires WG; draft-cui-softwire-b4-translated-ds-lite Objet : Re: [Softwires] draft-penno-softwire-sdnat vs. draft-cui-softwire-b4-translated-ds-lite In your previous mail you wrote: Med: Why you need an IPv4 address to run PCP? An implementation example would be as follows: * At bootstrap of the CPE, once an AFTR is discovered, use the Plain IPv6 PCP mode and the new opcode and options defined in http://tools.ietf.org/html/draft-tsou-pcp-natcoord-05#section-2 to retrieve an IPv4 address and set of port. = the retrieval of the external address is a function which was explicitely put out of PCP by the WG, for the second you'd like to use an extension which was never discussed. To finish there is a difference between discussing about getting the IPv4 address or getting it with other parameters as port ranges, and my comment is only about the first problem. Regards francis.dup...@fdupont.fr PS: I should add another dimension: do we want a solution for DS-Lite or a solution for DS-Lite, NAT44 or any other kind of IPv4 CGNs? ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] draft-penno-softwire-sdnat vs. draft-cui-softwire-b4-translated-ds-lite
Hi Yiu, Sending back an ICMP message when receiving a port out of range should be configurable IMHO. When receiving a port out of range, the behaviour of REQ#12 (A, B and C) of http://tools.ietf.org/html/draft-ietf-behave-lsn-requirements-05#section-3 can be followed by the AFTR. No need to define a new ICMP message for this; ICMP message Type 3 Code 13 is fine for this. Cheers, Med -Message d'origine- De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la part de Lee, Yiu Envoyé : mardi 20 mars 2012 16:39 À : Alain Durand; Qi Sun Cc : Softwires WG; draft-cui-softwire-b4-translated-ds-lite; draft-penno-softwire-sd...@tools.ietf.org Objet : Re: [Softwires] draft-penno-softwire-sdnat vs. draft-cui-softwire-b4-translated-ds-lite Today, if a user generates a packet using an illegal IPv4 source address, what would we do? We could drop the packet silently by doing source-verify. So, tomorrow if a user use illegal port, IMHO AFTR should drop the packet silently. On 3/20/12 9:06 AM, Alain Durand adur...@juniper.net wrote: It is necessary because the AFTR is the only place where we can enforce IPv4 ingress filtering, ie put ACLs to check that the incoming tunneled traffic from any given customer is using a legitimate IPv4 address and source port. When the incoming traffic does not match those ingress filtering rules, an ICMP error message must be returned. The idea in SD-NAT is to use this ICMP message to carry the information about the correct port range to use. ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] [MBONED] ask for adoption of draft-qin-softwire-multicast-prefix-option
Dear Stig, For sure mboned will had the opportunity to review it. No matter where the document is specified if a piece of work is needed. This is the kind of cross-WG documents that would require some flexibility form the IETF to make progress. Cheers, Med -Message d'origine- De : mboned-boun...@ietf.org [mailto:mboned-boun...@ietf.org] De la part de Stig Venaas Envoyé : mardi 20 mars 2012 21:45 À : sarik...@ieee.org Cc : Softwires-wg; MBONED WG; Softwire Chairs; Behcet Sarikaya Objet : Re: [MBONED] [Softwires] ask for adoption of draft-qin-softwire-multicast-prefix-option On 3/9/2012 9:30 AM, Behcet Sarikaya wrote: +1 I may be against adoption. This DHCPv6 option is needed, but it has nothing to do with ds-lite, and I'm not sure if this is the appropriate working group. This option has larger applicability than just encapsulation. If it is done here, it need to at least be reviewed and discussed in mboned. The options here are really based on draft-ietf-mboned-64-multicast-address-format-01.txt so mboned might be a better home. Copying mboned wg. Stig Behcet On Mon, Feb 6, 2012 at 10:30 PM, Qiongbingxu...@gmail.com wrote: +1 support On Mon, Feb 6, 2012 at 5:33 PM,christian.jacque...@orange.com wrote: Hi, I support the adoption of this draft as a softwire WG document. Cheers, Christian. -Message d'origine- De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la part de Yong Cui Envoyé : lundi 6 février 2012 01:57 À : Softwires WG Cc : Yong Cui Objet : [Softwires] ask for adoption of draft-qin-softwire-multicast-prefix-option Dear Softwires wg, As our WG discussed on DHCPv6 Options for IPv6 DS-Lite Multicast Prefix in Taipei meeting, the chairs would like to ask for WG adoption on the mailing list. Please review this document and send your comments (especially your opinion on the adoption with your reasons) to the mailing list by two weeks, i.e. Feb. 20. FYI: http://datatracker.ietf.org/doc/draft-qin-softwire-multicast-pr efix-option/ Yong Alain ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ __ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorization. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, France Telecom - Orange shall not be liable if this message was modified, changed or falsified. Thank you. ___ 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 ___ MBONED mailing list mbo...@ietf.org https://www.ietf.org/mailman/listinfo/mboned ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Fragmentation in sdnat-02
Dear Washam, This is an issue common to all stateless solutions, including deterministic NAT with (anaycast) IPv4 address pool. FWIW, we recorded this issue here: http://tools.ietf.org/html/draft-dec-stateless-4v6-04#section-5.15.2. As a solution to this issue, we proposed to implement the fragmentation-related function in one single node: any received fragment is redirected to a dedicated node which will be responsible for reassembly or forward the fragment to the appropriate CPE. This node must dedicate resources to handle out of order fragments. Saying that, I can not quantify the severity of this issue in all operational networks. Cheers, Med -Message d'origine- De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la part de Washam Fan Envoyé : mercredi 21 mars 2012 07:25 À : Softwires Objet : [Softwires] Fragmentation in sdnat-02 Hi Authors, In section 3.2, it states IPv4 address pool should be anycasted. This introduces a risk where different incoming fragments go to different AFTRs. Because one IPv4 address is shared between multiple subscribers, reassemly is needed on AFTRs when receiving fragments. If different fragments go thru different AFTRs, the reassmely process would fail and incur DoS. Thanks, washam ___ 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] Fragmentation in sdnat-02
Dear Gang, Thanks, but I failed to find the text describing how to handle two fragments received by two distinct BRs. Could you please point me to that text in case I miss it? Cheers, Med -Message d'origine- De : GangChen [mailto:phdg...@gmail.com] Envoyé : jeudi 22 mars 2012 08:33 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : Washam Fan; Softwires Objet : Re: [Softwires] Fragmentation in sdnat-02 2012/3/21, mohamed.boucad...@orange.com mohamed.boucad...@orange.com: Dear Washam, This is an issue common to all stateless solutions, including deterministic NAT with (anaycast) IPv4 address pool. FWIW, we recorded this issue here: http://tools.ietf.org/html/draft-dec-stateless-4v6-04#section-5.15.2. As a solution to this issue, we proposed to implement the fragmentation-related function in one single node: any received fragment is redirected to a dedicated node which will be responsible for reassembly or forward the fragment to the appropriate CPE. This node must dedicate resources to handle out of order fragments. FYI, I see another approach doing that with a entry table + redirection action, similarly like http://tools.ietf.org/html/draft-despres-softwire-4rd-u-05#sect ion-4.5.2. BRs Gang Saying that, I can not quantify the severity of this issue in all operational networks. Cheers, Med -Message d'origine- De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la part de Washam Fan Envoyé : mercredi 21 mars 2012 07:25 À : Softwires Objet : [Softwires] Fragmentation in sdnat-02 Hi Authors, In section 3.2, it states IPv4 address pool should be anycasted. This introduces a risk where different incoming fragments go to different AFTRs. Because one IPv4 address is shared between multiple subscribers, reassemly is needed on AFTRs when receiving fragments. If different fragments go thru different AFTRs, the reassmely process would fail and incur DoS. Thanks, washam ___ 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] Fragmentation in sdnat-02
Hi Rémi, This is well understood. The issue and the behaviour you are describing is common to all address sharing solutions with or without NAT; including all A+P flavours (MAP, 4rd, SDNAT). The point is: ** IF ** the issue raised by Washam is judged ** SEVERE ** issue, consider the solution presented in http://tools.ietf.org/html/draft-dec-stateless-4v6-04#section-5.15.2. Cheers, Med -Message d'origine- De : Rémi Després [mailto:despres.r...@laposte.net] Envoyé : vendredi 23 mars 2012 10:02 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : GangChen; Softwires Objet : Re: [Softwires] Fragmentation in sdnat-02 Hi, Med, Thanks for this question. 1. As we know, all fragments of a packet from a given off-domain host to a given in-domain IPv4 address usually enter the domain via the same BR. (Otherwise packet disordering would badly disrupt TCP). 2. When fragments of a packet enter a domain via distinct BRs (e.g. due to some change in routing or load balancing information bases), the algorithm of http://tools.ietf.org/html/draft-despres-softwire-4rd-u-05#sect ion-4.5.2. (3) is such that the packet will be lost: - A fragments going via a BR that didn't receive the first fragment is discarded by this BR. This results from the last column of the decision table. - Reassembly in the destination becomes therefore impossible. OK? Cheers, RD Le 2012-03-22 à 08:51, mohamed.boucad...@orange.com mohamed.boucad...@orange.com a écrit : Dear Gang, Thanks, but I failed to find the text describing how to handle two fragments received by two distinct BRs. Could you please point me to that text in case I miss it? Cheers, Med -Message d'origine- De : GangChen [mailto:phdg...@gmail.com] Envoyé : jeudi 22 mars 2012 08:33 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : Washam Fan; Softwires Objet : Re: [Softwires] Fragmentation in sdnat-02 2012/3/21, mohamed.boucad...@orange.com mohamed.boucad...@orange.com: Dear Washam, This is an issue common to all stateless solutions, including deterministic NAT with (anaycast) IPv4 address pool. FWIW, we recorded this issue here: http://tools.ietf.org/html/draft-dec-stateless-4v6-04#section-5.15.2. As a solution to this issue, we proposed to implement the fragmentation-related function in one single node: any received fragment is redirected to a dedicated node which will be responsible for reassembly or forward the fragment to the appropriate CPE. This node must dedicate resources to handle out of order fragments. FYI, I see another approach doing that with a entry table + redirection action, similarly like http://tools.ietf.org/html/draft-despres-softwire-4rd-u-05#sect ion-4.5.2. BRs Gang Saying that, I can not quantify the severity of this issue in all operational networks. Cheers, Med -Message d'origine- De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la part de Washam Fan Envoyé : mercredi 21 mars 2012 07:25 À : Softwires Objet : [Softwires] Fragmentation in sdnat-02 Hi Authors, In section 3.2, it states IPv4 address pool should be anycasted. This introduces a risk where different incoming fragments go to different AFTRs. Because one IPv4 address is shared between multiple subscribers, reassemly is needed on AFTRs when receiving fragments. If different fragments go thru different AFTRs, the reassmely process would fail and incur DoS. Thanks, washam ___ 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 mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Path to move forward with 4rd.
Dear WG members, I didn't had time to read the last version of 4rd-U but I read carefully -03 when it was published. I really appreciated the work done by Rémi to write down -03. The document is well written, easy to read and the requirements are clearly sketched. I really think this spirit should be adopted by MAP documents. As I already told Rémi, I would like if all proponents of stateless A+P converge and avoid wasting energies in comparing individual proposals. I thought this is what has been agreed during the softwire interim meeting: IMO, MAP effort meets the objective of group work. Some of the points raised by Rémi can be easily considered in the context of MAP; except the idea of unified header which is a step forward. Adopt a unified approach is exclusive to encapsulation and/or translation. The question now is: Does the unified approach bring new features + simplification compared to the normal IPv4-in-IPv6 encapsulation scheme (which I'm mainly interested in)? The answer is: No. Perhaps this is selfish but given what I mentioned above, I vote for the following: * Adopt the work of the MAP design team as the base specification for stateless A+P effort. * Make sure proposals from Rémi (except U) are discussed: e.g., Checksum neutrality (1) Share the archives of MAP Design Team discussion (2) Use IETF Issue Tracker to record the issues and the consensus/conclusion (3) Adopt a clear procedure within the Design Team to make decisions when there are conflicts * Reduce the amount of MAP documents: IMHO, three documents are needed (1) MAP Address Format (2) MAP Overall Architecture and Design Recommendations (3) MAP DHCPv6 Options Cheers, Med -Message d'origine- De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la part de Alain Durand Envoyé : mardi 20 mars 2012 00:39 À : Softwires WG Cc : Yong Cui; Ralph Droms Objet : [Softwires] Path to move forward with 4rd. Dear wg, After a number of discussions with my co-chair, our AD and various authors, here is how we would like to move forward wrt 4rd. 1) There is an observation that all the solutions on the table E, T U actually solve the stateless problem we started with. There are differences, but it is unclear if those differences are really significant. E and T are the original Encapsulation and Translation proposals, U is an hybrid unifying solution. 2) We have already agreed back in Beijing that we would publish all necessary documents. The issue here is the 'label' or 'status' those documents have at IETF. In particular, do we want to publish them as Experimental, Informational or Standard Track. We are at the point now where we need to make progress. In Paris, we would like to ask for presentations from the proponents of each candidate solution (E, T U). Each presentation should cover an overview of the proposed solution, explain how it compares to the others and make a case as why it should be the one on the Standard Track. We will allocate 20 minutes for each presentation. Then, we, chairs, would like to ask a series of questions to the working group. In order to make this process transparent, here is the list of questions we want to ask and their sequence. Q1: Without pre-supposing which one will be selected, do you agree to publish 1 of the 3 proposals on the Standard Track and publish the other(s) as Informational if still asked to? If the answer is NO, then the process stops and we will publish everything as Experimental and come back in 12-24 months to see what gets adopted by the market. If the answer is YES, we move to the next question. Q2: Do you believe that the WG should publish U as the one Standards Track document? If the answer is YES, the process stop, we put U on the Standard Track and publish E T as Informational. If the answer is NO, we are left with E T (U then might be abandoned or published as Historical/Informational) Q3: Which of E and T do you want to see moving on the standard track (you can only express support for one)? If there is a clear outcome from this question, we would publish that proposal on the Standard Track and the other one as Informational. If there is no clear consensus on this question, we will publish both E T as Experimental. In the meantime, we would like to encourage discussion on the mailing list to foster our common understanding of the various technologies and how they relate to each other. Alain Yong, wg co-chairs. ___ 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] Result from the consensus call on Map vs 4rd-U and official way forward
Dear all, I personally regret this decision and reject the justifications provided. If you don't want people to contribute and express their opinion, it is easy: make it a close community. If you insist to ignore what expressed the majority of individuals who participated to the poll, may I suggest: we stop all this stateless A+P work. It does not make sense at all to continue work on two parallel efforts having 90% of similarities. Cheers, Med -Message d'origine- De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la part de Alain Durand Envoyé : jeudi 26 avril 2012 03:41 À : softwires@ietf.org WG Objet : [Softwires] Result from the consensus call on Map vs 4rd-U and official way forward The chairs and ADs met to look at the results of the consensus call that ended Wednesday and decide the way forward. First, we would like to offer a couple observations on the raw results from the consensus call: - We had a number of people responding more than once, sometime with different email addresses. Having their name and affiliation in the response helped us removed those duplicate/triplicate/... - Number of unique response: 75 - Question 1: 75 yes, 0 No, few responded put both on experimental track - Question 2: 73 MAP 2 4rd-U This does not reflect at all the results we had in the Paris meeting (about 30 MAP and 20 4rd-U): a) It seems that some of the 4rd-U people who did express support for it in Paris when the same question was asked have not participated in this consensus call. b) the number of MAP responses seem to be inflated, we see a disproportionate number of response from some particular organizations. We also see a large number of responses coming from people who have not participated before in the working group. Also, it is apparent that a number of people have joined the mailing list for the sole purpose of expressing support for MAP. None of the above behaviors do any favors for the working group. We do need participation in the official call for consensus from all the active participants of the working group. As we mentioned before, in such calls, silence is consent. Also, the inflated participation in the consensus call from 'new' members that have never participate in the discussion before, creates noise that makes the results harder to read. Furthermore, we have observed that, even during the call, the analysis of both solutions did continue, and missing elements on both sides have been pointed out. We also observed a willingness of various participants to improve those specs to bring them to a level where we could start a working group last call. As a result, we have decided to approve both MAP and 4rd-U as working group work items. As work items, each document can be further refined until the working group reaches consensus about advancing the documents for IETF review. Because of the history of MAP and 4rd-U, we will designate independent teams of volunteer reviewers to advise the working group about the state of the document sets. Each set will be reviewed by an independent team who are not authors of the MAP and 4rd-U documents. Each review team will consist of three members and will determine when its document set is ready for working group last call. If you are interested in volunteering for one of the review teams, please respond directly to the chairs, indicating your preference for which document to review if you have one. The appointment of the review teams will be entirely up to the chairs. Aside from these appointed reviews, the chairs would naturally appreciate any and all reviews provided, regardless of whether the reviewer(s) participate on a review team. When the document sets are ready for working group last call, the working group will reconsider the question of the publication status: Proposed Standard or Experimental. We will try to consider all document sets for advancement at the same time, but we will not allow a delay in completing one document to hold up the working group indefinitely. - Alain Yong, WG co-chairs - Ralph Biran, ADs ___ 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
Hi Simon, We tried in this document to avoid as much as possible including implementation details but instead we focused on the external behaviour of the interworking functions. Let me recall there are already available implementations based on the specification of draft-ietf-softwire-dslite-multicast. A demo has been organized in one of the previous IETF meetings. Now for your comment, we can see the IGMP/MLD IWF is basically RFC4605 + address translation (draft-ietf-mboned-64-multicast-address-format). Among the use cases of high priority identified in http://tools.ietf.org/html/draft-ietf-mboned-v4v6-mcast-ps-00#section-3.6, the IGMP/MLD IWF is only required for the use case described in draft-ietf-softwire-dslite-multicast. As such, does-it really make sense to have a dedicated document for the IGMP/MLD IWF? Wouldn't be efficient to have this elaborated in draft-ietf-softwire-dslite-multicast? I personally vote for the second option. Of course, if this approach is maintained, the document should be LCed also in PIM and MBONED. Cheers, Med -Message d'origine- De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la part de Simon Perreault Envoyé : lundi 28 mai 2012 16:11 À : Yong Cui Cc : softwires@ietf.org Objet : Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02 On 2012-05-27 10:34, Yong Cui wrote: This is a wg last call on draft-ietf-softwire-dslite-multicast-02. 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. So I would suggest replacing section 6.1 by a reference to the draft above, which we hope to have adopted in the PIM WG shortly. Thanks, Simon -- DTN made easy, lean, and smart -- http://postellation.viagenie.ca NAT64/DNS64 open-source-- http://ecdysis.viagenie.ca STUN/TURN server -- http://numb.viagenie.ca ___ 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-, See inline. Cheers, Med -Message d'origine- De : Simon Perreault [mailto:simon.perrea...@viagenie.ca] Envoyé : jeudi 7 juin 2012 15:47 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : Yong Cui; softwires@ietf.org Objet : Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02 On 2012-06-07 08:51, mohamed.boucad...@orange.com wrote: Among the use cases of high priority identified in http://tools.ietf.org/html/draft-ietf-mboned-v4v6-mcast-ps-00#s ection-3.6, the IGMP/MLD IWF is only required for the use case described in draft-ietf-softwire-dslite-multicast. The DS-Lite case is one instance of the 4-6-4 use case where encapsulation is used. Another instance of the 4-6-4 use case makes use of translation instead. That is not covered by the softwire draft. Med: It was there; see http://tools.ietf.org/html/draft-ietf-softwire-dslite-multicast-00#appendix-A.1. I failed to find back why we removed it in -01 of the draft. BTW, this is not a diffrent use case, only the way data is handled differs. The 6-4-6-4 use case is also high priority, requires IGMP/MLD translation, and is not covered by the softwire draft. Med: I'm not sure there is a consenus about the urgency of 6-4-6-4 scenario. I knwo there is an operator representative voicing for it, but I always failed to understand that use case. So we're looking at at least three use cases of IGMP/MLD translation, possibly more, of which only one is covered by the softwire draft. Med: I failed to count the three use cases.. As such, does-it really make sense to have a dedicated document for the IGMP/MLD IWF? Wouldn't be efficient to have this elaborated in draft-ietf-softwire-dslite-multicast? I personally vote for the second option. Of course, if this approach is maintained, the document should be LCed also in PIM and MBONED. I think IGMP/MLD translation should stand on its own for the reasons above, and it should be a PIM document. Med: There is no PIM WG document to cite at this stage. What is wrong with LCing this in PIM and MBONED? ___ 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 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 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 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-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-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 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
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] I-D Action: draft-ietf-softwire-stateless-4v6-motivation-02.txt
Re-, Please see inline. Cheers, Med -Message d'origine- De : liu dapeng [mailto:maxpass...@gmail.com] Envoyé : mardi 12 juin 2012 11:49 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : softwires@ietf.org Objet : Re: [Softwires] I-D Action: draft-ietf-softwire-stateless-4v6-motivation-02.txt Ok, then we can make this more clear in our document. States still should be maintained in other equipments, Med: Why should? The NAT is not mandatory and even if port restriction is needed, a host may just restrict its port to be within the range. So, I don't see a reason to change may to should. e.g. customer premises equipment or host, in order to restrict IP address or port number information into the configured context except that a non-shared IPv4 address is assigned to a standalone host. Med: No need to elaborate what the state is about. You asked to add a sentence to say a state may exist in the LAN side, I updated the text to cover your comment: States may still exist in other equipments such as customer premises equipment. Best Regards, Dapeng Liu 2012/6/12, mohamed.boucad...@orange.com mohamed.boucad...@orange.com: Hi Dapeng, I can't add the port restriction because stateless IPv4/IPv6 solutions (e.g., MAP, 4RD) support also the ability to assign a full IP address. Cheers, Med -Message d'origine- De : liu dapeng [mailto:maxpass...@gmail.com] Envoyé : mardi 12 juin 2012 09:14 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : softwires@ietf.org Objet : Re: [Softwires] I-D Action: draft-ietf-softwire-stateless-4v6-motivation-02.txt Hi Med, Thanks for posting this new version but I guess it doesn't reflect all the discussion we had. I suggest to make following modifications. States still should be maintained in other equipments, e.g. customer premises equipment or host, in order to restrict port numbers within a dedicated range. Please be undestood all the efforts are for precise expression for the readers. Thanks, Best Regards, Dapeng Liu 2012/6/12, mohamed.boucad...@orange.com mohamed.boucad...@orange.com: Dear WG members, The new version includes the comments received during the WG LC (from Dapeng). A diff is available here: http://tools.ietf.org/rfcdiff?url2=draft-ietf-softwire-stateles s-4v6-motivation-02 Cheers, Med -Message d'origine- De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la part de internet-dra...@ietf.org Envoyé : mardi 12 juin 2012 07:43 À : i-d-annou...@ietf.org Cc : softwires@ietf.org Objet : [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-stateles s-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 ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires -- -- 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-dslite-multicast-02
Behcet, If you are suggesting we need get rid of multicast capabilities and use unicast between the AFTR and B4, I still claim this is a bad design choice. The rationale for the design documented in the draft is as follows (excerpt from the draft): If customers have to access IPv4 multicast-based services through DS- Lite environment, Address Family Transition Router (AFTR) devices will have to process all the IGMP Report messages [RFC2236] [RFC3376] that have been forwarded by the CPE into the IPv4-in-IPv6 tunnels. From that standpoint, AFTR devices are likely to behave as a replication point for downstream multicast traffic. And the multicast packets will be replicated for each tunnel endpoint where IPv4 receivers are connected to. This kind of DS-Lite environment raises two major issues: 1. The IPv6 network loses the benefits of the multicast traffic forwarding efficiency because it is unable to deterministically replicate the data as close to the receivers as possible. As a consequence, the downstream bandwidth in the IPv6 network will be vastly consumed by sending multicast data over a unicast infrastructure. 2. The AFTR is responsible for replicating multicast traffic and forwarding it into each tunnel endpoint connecting IPv4 receivers that have explicitly asked for the corresponding contents. This process may greatly consume AFTR's resources and overload the AFTR. This document specifies an extension to the DS-Lite model to deliver IPv4 multicast services to IPv4 clients over an IPv6 multicast- enabled network. For me, DS-Lite model is not only what is documented in RFC6333 but covers also stateless A+P including MAP and 4rd. Hope this clarifies your concern. Cheers, Med -Message d'origine- De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la part de Behcet Sarikaya Envoyé : mercredi 13 juin 2012 00:23 À : Lee, Yiu Cc : softwires@ietf.org Objet : Re: [Softwires] WG last call on draft-ietf-softwire-dslite-multicast-02 Hi Yiu, The solution in this draft is generic, it simply leaves DS-Lite aside and builds its own stuff. I think this fact has been alluded to by the co-authors. This should change. Saying that a solution that integrates with DS-Lite is technically poor solution is saying that DS-Lite is technically poor solution. Behcet On Tue, Jun 12, 2012 at 3:56 PM, Lee, Yiu yiu_...@cable.comcast.com wrote: Hi Behect, You confuse me. 4.3 said this: When the mAFTR receives an IPv4 multicast packet, it will encapsulate the packet into an IPv6 multicast packet using the IPv4-embedded IPv6 multicast address as the destination address and an IPv4-embedded IPv6 unicast address as the source address. The data packets are tunneled over IPv6 hub by hub. That said, the tunnel isn't end-to-end. Thanks, Yiu On 6/12/12 4:30 PM, Behcet Sarikaya sarikaya2...@gmail.com wrote: It is not the case in the draft currently, check Sections 4.3 6.2. 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
Re-, Did you read draft-ietf-softwire-dslite-multicast? I have some doubts given your message below. Cheers, Med -Message d'origine- De : Behcet Sarikaya [mailto:sarikaya2...@gmail.com] Envoyé : lundi 11 juin 2012 18:08 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : softwires@ietf.org; Yong Cui Objet : 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-dslite6rdmul ticast-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
Re: [Softwires] I-D Action: draft-ietf-softwire-stateless-4v6-motivation-02.txt
Re-, Please see inline. Cheers, Med -Message d'origine- De : liu dapeng [mailto:maxpass...@gmail.com] Envoyé : mercredi 13 juin 2012 12:09 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : softwires@ietf.org Objet : Re: [Softwires] I-D Action: draft-ietf-softwire-stateless-4v6-motivation-02.txt Dear Med: 2012/6/13, mohamed.boucad...@orange.com mohamed.boucad...@orange.com: Dear Dapeng, The current text says: * no state in the (provider) network side * state may exist in the customer premises side = I raised the concern yesterday for the term may But didn't get response so far: Med: Why should? The NAT is not mandatory =Current candidate solutions told me that the NAT44 is mandatory part i.e. The NAPT MUST in turn be connectedto a MAP aware forwarding function, that does encapsulation/decapsulation or translation to IPv6. http://www.ietf.org/mail-archive/web/softwires/current/msg04379.html please read that. Otherwise, I don't think we should move forward. Med: You didn't answered my question. Pointing to a particular candidate solution is not a justification per se. I can change may to should to please you but it really does make sense. NAT is an optional feature in stateless solutions (e.g., host assigned with port restricted IPv4 address, host assigned with a full IPv4 address, CPE assigned with pool of IPv4 addresses, etc.). * focus is on carrier-side stateless solutions ==Carrier side stateless solution doesn't mean solution doesn't cover CPE. We need to clarify definitely. Med: Clarify what? The document already says: carrier-side stateless IPv4 over IPv6 solution. States may still exist in other equipments such as customer premises equipment. Regards, Dapeng As an editor of the document, I believe the new version solves your concerns. Cheers, Med -Message d'origine- De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la part de liu dapeng Envoyé : mercredi 13 juin 2012 05:40 À : Lee, Yiu Cc : softwires@ietf.org Objet : Re: [Softwires] I-D Action: draft-ietf-softwire-stateless-4v6-motivation-02.txt As a reader of the document, not co-author any related document, I believe people who is not involved the whole process (e.g. edit the documents, design the solutions,etc) couldn't understand the story behind that. I personally have sincerely heard some people presenting and evaluating this technology incorrectly somewhere before because of ambiguous understanding on the term. My purpose is that IETF has the responsibility to clarify what we are documenting clearly to prevent from misleading. I'm thankful to your discussion that made all things clear than before. And I don't understand why we don't document something we already agreed on, but let the misleading to continue. Regards, Dapeng Liu 2012/6/13, Lee, Yiu yiu_...@cable.comcast.com: Hi Dapeng, This draft was written by operators, we do not have any problem understanding it. Besides, I disagree we intentionally hide the truth. Please explain to the WG what truth we are trying to hide in this draft? I am not convinced we need to say anymore than what we have stated in the new version. Thanks, Yiu On 6/12/12 11:45 AM, liu dapeng maxpass...@gmail.com wrote: 2012/6/12, Lee, Yiu yiu_...@cable.comcast.com: Hi Dapeng., This is not a specification draft. This is a draft to discuss the motivations. IMHO, people who are working in this area would be able to understand this draft. = I guess the audience is not only designer of protocol, but also operators who want to evaluate and adopt such technology. Intentional hiding the truth for me is really bad. The focus of it is about the carrier network, CPE is never the focal point. I think the current statement States may still exist in other equipments such as customer premises equipment. is enough. =Please see my reply in previous mail. may is not sufficient. Adding more text only causes confusion. =What I do is objectively to elaborate what we are. Why would that cause confusion? Regards, Dapeng Thanks, Yiu On 6/12/12 6:21 AM, liu dapeng maxpass...@gmail.com wrote: 2012/6/12, Ole Trøan otr...@employees.org: Ok, then we can make this more clear in our document. States still should be maintained in other equipments, e.g. customer premises equipment or host, in order to restrict IP address or port number information into the configured context except that a non-shared IPv4 address is assigned to a standalone host. I think this is just adding confusion. the NAT44 on the CPE already does this. =First off, we are not only talking about NAT44 here, but port translation and non-shared address. Secondly, NAT44 on the CPE is not doing what today NAT44 does. For example, override ID in ICMP with port information. that reminds me to update the proposed text a bit, States still should be maintained in other equipments, e.g. customer premises equipment or host, in order to restrict L3 or
Re: [Softwires] I-D Action: draft-ietf-softwire-stateless-4v6-motivation-02.txt
Hi Tom, Thank for the proposal. I can update the text with your proposed wording if Dapeng is OK. Dapeng, are you happy with the text proposed by Tom? Cheers, Med -Message d'origine- De : Tom Taylor [mailto:tom.taylor.s...@gmail.com] Envoyé : mercredi 13 juin 2012 17:44 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : liu dapeng; softwires@ietf.org Objet : Re: [Softwires] I-D Action: draft-ietf-softwire-stateless-4v6-motivation-02.txt I think what Dapeng wants to convey would be achieved if you changed the may to will typically: ... state will typically exist in the customer premises side Is this acceptable? On the second point, I agree with the existing text. Tom Taylor On 13/06/2012 7:42 AM, mohamed.boucad...@orange.com wrote: Re-, Please see inline. Cheers, Med -Message d'origine- De : liu dapeng [mailto:maxpass...@gmail.com] Envoyé : mercredi 13 juin 2012 12:09 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : softwires@ietf.org Objet : Re: [Softwires] I-D Action: draft-ietf-softwire-stateless-4v6-motivation-02.txt Dear Med: 2012/6/13, mohamed.boucad...@orange.commohamed.boucad...@orange.com: Dear Dapeng, The current text says: * no state in the (provider) network side * state may exist in the customer premises side = I raised the concern yesterday for the term may But didn't get response so far: Med: Why should? The NAT is not mandatory =Current candidate solutions told me that the NAT44 is mandatory part i.e. The NAPT MUST in turn be connectedto a MAP aware forwarding function, that does encapsulation/decapsulation or translation to IPv6. http://www.ietf.org/mail-archive/web/softwires/current/msg04379.html please read that. Otherwise, I don't think we should move forward. Med: You didn't answered my question. Pointing to a particular candidate solution is not a justification per se. I can change may to should to please you but it really does make sense. NAT is an optional feature in stateless solutions (e.g., host assigned with port restricted IPv4 address, host assigned with a full IPv4 address, CPE assigned with pool of IPv4 addresses, etc.). * focus is on carrier-side stateless solutions ==Carrier side stateless solution doesn't mean solution doesn't cover CPE. We need to clarify definitely. Med: Clarify what? The document already says: carrier-side stateless IPv4 over IPv6 solution. States may still exist in other equipments such as customer premises equipment. Regards, Dapeng As an editor of the document, I believe the new version solves your concerns. Cheers, Med -Message d'origine- De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la part de liu dapeng Envoyé : mercredi 13 juin 2012 05:40 À : Lee, Yiu Cc : softwires@ietf.org Objet : Re: [Softwires] I-D Action: draft-ietf-softwire-stateless-4v6-motivation-02.txt As a reader of the document, not co-author any related document, I believe people who is not involved the whole process (e.g. edit the documents, design the solutions,etc) couldn't understand the story behind that. I personally have sincerely heard some people presenting and evaluating this technology incorrectly somewhere before because of ambiguous understanding on the term. My purpose is that IETF has the responsibility to clarify what we are documenting clearly to prevent from misleading. I'm thankful to your discussion that made all things clear than before. And I don't understand why we don't document something we already agreed on, but let the misleading to continue. Regards, Dapeng Liu 2012/6/13, Lee, Yiuyiu_...@cable.comcast.com: Hi Dapeng, This draft was written by operators, we do not have any problem understanding it. Besides, I disagree we intentionally hide the truth. Please explain to the WG what truth we are trying to hide in this draft? I am not convinced we need to say anymore than what we have stated in the new version. Thanks, Yiu On 6/12/12 11:45 AM, liu dapengmaxpass...@gmail.com wrote: 2012/6/12, Lee, Yiuyiu_...@cable.comcast.com: Hi Dapeng., This is not a specification draft. This is a draft to discuss the motivations. IMHO, people who are working in this area would be able to understand this draft. = I guess the audience is not only designer of protocol, but also operators who want to evaluate and adopt such technology. Intentional hiding the truth for me is really bad. The focus of it is about the carrier network, CPE is never the focal point. I think the current statement States may still exist in other equipments such as customer premises equipment. is enough. =Please see my reply in previous mail. may is not sufficient. Adding more text only causes confusion. =What I do is objectively to elaborate what we are. Why would that cause confusion? Regards, Dapeng Thanks, Yiu On 6/12/12 6:21 AM, liu dapengmaxpass...@gmail.com wrote:
Re: [Softwires] [softwire] #10: Nothing in common with DS-Lite
Dear all, I really don't understand this issue. It is even misplaced to have this comment at this stage, since this is a document which has been adopted by the WG and the solution it specifies is the same as the one reviewed by the WG prior to its adoption (i.e., since April 2011). Anyway, below a tentative to explain the overall rationale: DS-Lite model can not be reduced to a CGN/AFTR + tunnel. DS-Lite should be first seen as an IP connectivity service. This service can be defined as follows: * delivery of IPv4 connectivity over an IPv6-capable network. * delivery of native IPv6 connectivity * DS-Lite serviced customers are assigned with IPv6 prefix and no IPv4 address. The unicast portion of the service is defined in RFC6333 and is implemented using a tunnel + CGN. The multicast portion of the service is defined in draft-ietf-softwire-dslite-multicast. This portion of the service can be defined as follows: * delivery of IPv4 multicast content using native IPv6 multicast capabilities * delivery of native IPv6 multicast content The solution proposed in draft-ietf-softwire-dslite-multicast is designed to allow DS-Lite serviced customers be delivered IPv4 multicast services. A side note, I agree with Stig and Woj the proposed solution can be generalized to cover any 4-6-4 scenario. This can be done easily by updating the draft (abstract and introduction) to reflect the change of scope of use cases. We didn't had the ambition to define a generic solution when we wrote this draft, we focused mainly on the DS-Lite context. If there is no objection from the WG, we can implement that change. Cheers, Med -Message d'origine- De : softwire issue tracker [mailto:trac+softw...@tools.ietf.org] Envoyé : vendredi 13 juillet 2012 23:55 À : draft-ietf-softwire-dslite-multic...@tools.ietf.org; sarik...@ieee.org Cc : softwires@ietf.org Objet : Re: [softwire] #10: Nothing in common with DS-Lite #10: Nothing in common with DS-Lite Changes (by sarikaya@.): * owner: sarikaya@. = draft-ietf-softwire-dslite-multicast@. -- -+- Reporter: sarikaya@. | Owner: draft-ietf-softwire-dslite- Type: defect | multicast@. Priority: major| Status: new Component: dslite- | Milestone: milestone1 multicast | Version: 2.0 Severity: In WG Last | Resolution: Call | Keywords: tunneling| -+- Ticket URL: http://trac.tools.ietf.org/wg/softwire/trac/ticket/10#comment:1 softwire http://tools.ietf.org/softwire/ ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] map-00: review on the mode 1:1
Woj, The argument you are raising applies also for (1) and (3): one can argue this justifies editing an RFC6333-bis to cover the per-subscriber state case ;-) As I mentioned in my first message, MAP can be extended to cover the per-subscriber case at the cost of adding confusion by abandoning the no state in the ISP network paradigm not to mention the incompatibility with the translation mode (part of the MAP suite), etc. IMO, the issue is not technical. It is more a matter of rationalizing the solution space. Having the three deployment options listed below is IMHO a good direction to take by the WG. Cheers, Med De : Wojciech Dec [mailto:wdec.i...@gmail.com] Envoyé : vendredi 27 juillet 2012 14:00 À : Maoke Cc : BOUCADAIR Mohamed OLNC/NAD/TIP; Softwires-wg Objet : Re: [Softwires] map-00: review on the mode 1:1 Med, 2) and 3) both require configuration and as has been amply discussed technically there is no issue with per subscriber rules in 2) or optimization applying to 3). As such, justifying three different solutions out of which two can technically have the same amount of configuration state and are almost the same appears illogical. From another perspective, defining a solution that by definition requires per subscriber configuration state and does not allow its optimization is highly questionable technically. Regards, Woj. On 26 July 2012 16:34, Maoke fib...@gmail.commailto:fib...@gmail.com wrote: 2012/7/26 mohamed.boucad...@orange.commailto:mohamed.boucad...@orange.com Dear Ole, all, For sure MAP spec can be updated to cover 1:1 mode but this brings more confusion for some people as this contradicts the no state in ISP network paradigm. I personally vote for limiting MAP to its initial scope rather than trying to cover other deployment options. I see three main flavours which justifies having standalone specification documents: (1) Full stateful mode: DS-Lite (2) Full stateless mode: MAP/4rd (3) Per-customer state/binding mode: lw4o6 (draft-cui-softwire-b4-translated-ds-lite) These three flavours have been already sketched in Figure 7 of RFC6346 (see http://tools.ietf.org/html/rfc6346#section-3.3.4). yes. i share this point. thanks, Med, for the clear explanation on the big picture. - maoke Having standalone specifications for each of these flavours helps operators to better target their suitable deployment model without being disturbed with parameters and details not pertinent for their deployment context. Cheers, Med -Message d'origine- De : softwires-boun...@ietf.orgmailto:softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.orgmailto:softwires-boun...@ietf.org] De la part de Ole Trøan Envoyé : jeudi 26 juillet 2012 12:23 À : Lee, Yiu Cc : Softwires-wg Objet : Re: [Softwires] map-00: review on the mode 1:1 Yiu, Set EA bits=0 only saves bits in v6 address and decouples v4/v6 address dependency. It doesn't bring any new function compared to embedding full v4 address in the EA-bit. However, the operation models of EA-bit0 or =0 are very different. By the way, this works only for MAP-E. I fail to see why we want to include this in the base spec. what do you say in the spec if EA=0 and provisioned IPv4 prefix length = 32. the spec has to say something about this to be complete. cheers, Ole Thanks, Yiu On 7/25/12 9:45 PM, Satoru Matsushima satoru.matsush...@gmail.commailto:satoru.matsush...@gmail.com wrote: Hi Yiu, On 2012/07/26, at 4:08, Lee, Yiu wrote: Ole, Where can I get the formal definition of 1:1 mode? My understanding of 1:1 refers to one public IPv4 address per subscriber but you refer very specific to decoupling IPv4 and IPv6 addresses. It doesn't 1:1 in MAP and 4rd context, because embedding full ipv4 address in ea-bits is as a result of prefix allocation operation. Before MAP was accepted as WG item, MAP was proposed to embed IPv4 address information (EA bits 0) in the CE IPv6 address to achieve stateless. No, there was no such definition for EA-bits length restriction. Now there is a new proposal to add a new feature to have the IPv4 information in the BR only. This change requires to provision individual subscriber information to the BR (instead of aggregated information). Benefit are saving bits and breaking v4 and v6 address dependency. There's no change from previous spec, to just clarify MAP, as a stateless solution, could naturally support most granular mapping rule in its nature. Questions to WG: Is it useful feature to be included in MAP? If not, why and alternative? I believe that it does not make sense to restrict EA-len 0 for both MAP and 4rd. It does make sense that you see MAP as framework of solutions which covers specific 1:1 solution by the mapping algorithm. cheers, --satoru Thanks, Yiu On 7/25/12 2:40 PM, Ole Trøan otr...@employees.orgmailto:otr...@employees.org wrote: Yiu, I am not asking whether MAP
Re: [Softwires] [softwire] #10: Nothing in common with DS-Lite
Re-, Yes, the CGN is not required. This design choice is motivated in the draft (read the Introduction text). What is the issue then? If you are saying this is a generic solution and it does not apply only to ds-lite, this point is taken (see the note below). Cheers, Med De : Wojciech Dec [mailto:wdec.i...@gmail.com] Envoyé : vendredi 27 juillet 2012 14:44 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : softwire issue tracker; draft-ietf-softwire-dslite-multic...@tools.ietf.org; sarik...@ieee.org; softwires@ietf.org Objet : Re: [Softwires] [softwire] #10: Nothing in common with DS-Lite Med, the point is that the DS-Lite (CGN AFTR) solution is not necessary to be deployed for the multicast solution described here to work. As to how this ended up being charterd in Softwire I don't know and IMO it doesn't make much sense. Regards, Woj. On 27 July 2012 13:48, mohamed.boucad...@orange.commailto:mohamed.boucad...@orange.com wrote: Dear all, I really don't understand this issue. It is even misplaced to have this comment at this stage, since this is a document which has been adopted by the WG and the solution it specifies is the same as the one reviewed by the WG prior to its adoption (i.e., since April 2011). Anyway, below a tentative to explain the overall rationale: DS-Lite model can not be reduced to a CGN/AFTR + tunnel. DS-Lite should be first seen as an IP connectivity service. This service can be defined as follows: * delivery of IPv4 connectivity over an IPv6-capable network. * delivery of native IPv6 connectivity * DS-Lite serviced customers are assigned with IPv6 prefix and no IPv4 address. The unicast portion of the service is defined in RFC6333 and is implemented using a tunnel + CGN. The multicast portion of the service is defined in draft-ietf-softwire-dslite-multicast. This portion of the service can be defined as follows: * delivery of IPv4 multicast content using native IPv6 multicast capabilities * delivery of native IPv6 multicast content The solution proposed in draft-ietf-softwire-dslite-multicast is designed to allow DS-Lite serviced customers be delivered IPv4 multicast services. A side note, I agree with Stig and Woj the proposed solution can be generalized to cover any 4-6-4 scenario. This can be done easily by updating the draft (abstract and introduction) to reflect the change of scope of use cases. We didn't had the ambition to define a generic solution when we wrote this draft, we focused mainly on the DS-Lite context. If there is no objection from the WG, we can implement that change. Cheers, Med -Message d'origine- De : softwire issue tracker [mailto:trac+softw...@tools.ietf.orgmailto:trac%2bsoftw...@tools.ietf.org] Envoyé : vendredi 13 juillet 2012 23:55 À : draft-ietf-softwire-dslite-multic...@tools.ietf.orgmailto:draft-ietf-softwire-dslite-multic...@tools.ietf.org; sarik...@ieee.orgmailto:sarik...@ieee.org Cc : softwires@ietf.orgmailto:softwires@ietf.org Objet : Re: [softwire] #10: Nothing in common with DS-Lite #10: Nothing in common with DS-Lite Changes (by sarikaya@.): * owner: sarikaya@. = draft-ietf-softwire-dslite-multicast@. -- -+- Reporter: sarikaya@. | Owner: draft-ietf-softwire-dslite- Type: defect | multicast@. Priority: major| Status: new Component: dslite- | Milestone: milestone1 multicast | Version: 2.0 Severity: In WG Last | Resolution: Call | Keywords: tunneling| -+- Ticket URL: http://trac.tools.ietf.org/wg/softwire/trac/ticket/10#comment:1 softwire http://tools.ietf.org/softwire/ ___ 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] [softwire] #10: Nothing in common with DS-Lite
Hi Stig, Wouldn't be sufficient enough to add this sentence to the abstract and the Introduction: The proposed solution can be deployed for other 4-6-4 use cases. Thanks. Cheers, Med -Message d'origine- De : Stig Venaas [mailto:s...@venaas.com] Envoyé : vendredi 27 juillet 2012 18:29 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : softwire issue tracker; draft-ietf-softwire-dslite-multic...@tools.ietf.org; sarik...@ieee.org; softwires@ietf.org Objet : Re: [Softwires] [softwire] #10: Nothing in common with DS-Lite Hi On 7/27/2012 4:48 AM, mohamed.boucad...@orange.com wrote: Dear all, I really don't understand this issue. It is even misplaced to have this comment at this stage, since this is a document which has been adopted by the WG and the solution it specifies is the same as the one reviewed by the WG prior to its adoption (i.e., since April 2011). Anyway, below a tentative to explain the overall rationale: DS-Lite model can not be reduced to a CGN/AFTR + tunnel. DS-Lite should be first seen as an IP connectivity service. This service can be defined as follows: * delivery of IPv4 connectivity over an IPv6-capable network. * delivery of native IPv6 connectivity * DS-Lite serviced customers are assigned with IPv6 prefix and no IPv4 address. The unicast portion of the service is defined in RFC6333 and is implemented using a tunnel + CGN. The multicast portion of the service is defined in draft-ietf-softwire-dslite-multicast. This portion of the service can be defined as follows: * delivery of IPv4 multicast content using native IPv6 multicast capabilities * delivery of native IPv6 multicast content The solution proposed in draft-ietf-softwire-dslite-multicast is designed to allow DS-Lite serviced customers be delivered IPv4 multicast services. I think I agree with the above. A side note, I agree with Stig and Woj the proposed solution can be generalized to cover any 4-6-4 scenario. This can be done easily by updating the draft (abstract and introduction) to reflect the change of scope of use cases. We didn't had the ambition to define a generic solution when we wrote this draft, we focused mainly on the DS-Lite context. If there is no objection from the WG, we can implement that change. This is all I've been asking for. An update to abstract/introduction to indicate that it is a generic solution. And then say that DS-Lite is one of the use-cases. You can even say that the solution was developed to solve the problem for DS-Lite. All I want is to make it clear that it is a generic solution. Stig Cheers, Med -Message d'origine- De : softwire issue tracker [mailto:trac+softw...@tools.ietf.org] Envoyé : vendredi 13 juillet 2012 23:55 À : draft-ietf-softwire-dslite-multic...@tools.ietf.org; sarik...@ieee.org Cc : softwires@ietf.org Objet : Re: [softwire] #10: Nothing in common with DS-Lite #10: Nothing in common with DS-Lite Changes (by sarikaya@.): * owner: sarikaya@. = draft-ietf-softwire-dslite-multicast@. -- -+- Reporter: sarikaya@. | Owner: draft-ietf-softwire-dslite- Type: defect | multicast@. Priority: major| Status: new Component: dslite- | Milestone: milestone1 multicast | Version: 2.0 Severity: In WG Last | Resolution: Call | Keywords: tunneling| -+- Ticket URL: http://trac.tools.ietf.org/wg/softwire/trac/ticket/10#comment:1 softwire http://tools.ietf.org/softwire/ ___ 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] [softwire] #10: Nothing in common with DS-Lite
Hi Behcet, Please see inline. Cheers, Med -Message d'origine- De : Behcet Sarikaya [mailto:sarikaya2...@gmail.com] Envoyé : vendredi 27 juillet 2012 18:48 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : softwire issue tracker; draft-ietf-softwire-dslite-multic...@tools.ietf.org; softwires@ietf.org Objet : Re: [softwire] #10: Nothing in common with DS-Lite Hi Med, My comments below. Please do not take them personal. No offense. Please, please. On Fri, Jul 27, 2012 at 6:48 AM, mohamed.boucad...@orange.com wrote: Dear all, I really don't understand this issue. It is even misplaced to have this comment at this stage, since this is a document which has been adopted by the WG and the solution it specifies is the same as the one reviewed by the WG prior to its adoption (i.e., since April 2011). Anyway, below a tentative to explain the overall rationale: DS-Lite model can not be reduced to a CGN/AFTR + tunnel. DS-Lite should be first seen as an IP connectivity service. This service can be defined as follows: * delivery of IPv4 connectivity over an IPv6-capable network. * delivery of native IPv6 connectivity * DS-Lite serviced customers are assigned with IPv6 prefix and no IPv4 address. The unicast portion of the service is defined in RFC6333 and is implemented using a tunnel + CGN. The multicast portion of the service is defined in draft-ietf-softwire-dslite-multicast. This portion of the service can be defined as follows: * delivery of IPv4 multicast content using native IPv6 multicast capabilities * delivery of native IPv6 multicast content The solution proposed in draft-ietf-softwire-dslite-multicast is designed to allow DS-Lite serviced customers be delivered IPv4 multicast services. These are religious arguments. Translation multicast integrates well with several IPv6 transition technologies. MAP-T is one. NAT64 is another, 4rd also. But not MAP-E. Let's use translation multicast with those technologies. No matter what you want to believe, DS-Lite is a tunneling technology. Why do you think DS-Lite was standardized in Softwires WG? Same thing with 6rd. Remember softwire means tunnel. Translation has only been added to Softwires WG recently after Behave WG stopped working on it. Med: I failed to get the point you are trying to make. Do you want draft-ietf-softwire-dslite-multicast to cover the translation case also? Let me remind that draft-ietf-softwire-dslite-multicast covers only the encapsulation scheme: IPv4 multicast packets are encapsulated in IPv6 ones. ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
[Softwires] draft-ietf-softwire-dslite-multicast-03
Dear all, A new version taking into account comments received during the WGLC has been submitted. The main changes are: * change the title * clarify the solution is generic for any 4-6-4 use case and the solution has been designed with DS-Lite in mind * add a discussion about scoping: preserve the scope when translation multicast addresses * add a note only IPv4-in-IPv6 encap is detailed in the document but other tunnelling techniques may be defined in the future * update the security section with some discussions related to scoping. * + other editorial changes. To view the detailed changes: http://www.ietf.org/rfcdiff?url2=draft-ietf-softwire-dslite-multicast-03 I hope this version solve the concerns raised during the WGLC. Cheers, Med -Message d'origine- De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la part de internet-dra...@ietf.org Envoyé : jeudi 23 août 2012 16:47 À : i-d-annou...@ietf.org Cc : softwires@ietf.org Objet : [Softwires] I-D Action: draft-ietf-softwire-dslite-multicast-03.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 : Delivery of IPv4 Multicast Services to IPv4 Clients over an IPv6 Multicast Network Author(s) : Jacni Qin Mohamed Boucadair Christian Jacquenet Yiu L. Lee Qian Wang Filename: draft-ietf-softwire-dslite-multicast-03.txt Pages : 20 Date: 2012-08-23 Abstract: This document specifies a solution for the delivery of IPv4 multicast services to IPv4 clients over an IPv6 multicast network. The solution relies upon a stateless IPv4-in-IPv6 encapsulation scheme and uses the IPv6 multicast distribution tree to deliver IPv4 multicast traffic. The solution is particularly useful for the delivery of multicast service offerings to DS-Lite serviced customers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-softwire-dslite-multicast There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-softwire-dslite-multicast-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-softwire-dslite-mul ticast-03 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 ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] draft-ietf-softwire-dslite-multicast-03
Hi Behcet, I'm ready to record in the document whatever the WG agrees to do. But as far as I know the solution which consists in encapsulating all multicast flows to the unicast AFTR has not been accepted by the working group. The drawbacks are even been documented in this draft. I'm aware of the tickets you opened. I already answered several times to those issues by e-mail. I sincerely don't see what I can do more. Cheers, Med -Message d'origine- De : Behcet Sarikaya [mailto:sarikaya2...@gmail.com] Envoyé : jeudi 23 août 2012 21:33 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : softwires@ietf.org Objet : Re: [Softwires] draft-ietf-softwire-dslite-multicast-03 Hi Med, Thanks for posting this revision but it seems like it has not solved any problems but instead it created more problems :-). First, please see the two active tickets, ticket #10 and ticket #11 in the issue tracker: http://tools.ietf.org/wg/softwire/trac/report/1 In addition, in Section 4.3, the draft all of a sudden deviates from translation which is used all over and introduces encapsulation. I had asked before in my mails, asking it again, why? You think that translation of multicast data could not be used/does not work? Please see http://tools.ietf.org/html/draft-sarikaya-behave-mcast4nat64-06 Section 5 might be containing immature text as the underlying draft work has not yet been finalized. The right way to handle tickets # 10 11 is first to include the encapsulation solution and next describe the drawbacks based on the application that you consider and then next present this translation solution. Failing this, the only suggestion is to take this draft to another place, e.g. mboned and try its chances there. Regards, Behcet On Thu, Aug 23, 2012 at 9:54 AM, mohamed.boucad...@orange.com wrote: Dear all, A new version taking into account comments received during the WGLC has been submitted. The main changes are: * change the title * clarify the solution is generic for any 4-6-4 use case and the solution has been designed with DS-Lite in mind * add a discussion about scoping: preserve the scope when translation multicast addresses * add a note only IPv4-in-IPv6 encap is detailed in the document but other tunnelling techniques may be defined in the future * update the security section with some discussions related to scoping. * + other editorial changes. To view the detailed changes: http://www.ietf.org/rfcdiff?url2=draft-ietf-softwire-dslite-mul ticast-03 I hope this version solve the concerns raised during the WGLC. Cheers, Med -Message d'origine- De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la part de internet-dra...@ietf.org Envoyé : jeudi 23 août 2012 16:47 À : i-d-annou...@ietf.org Cc : softwires@ietf.org Objet : [Softwires] I-D Action: draft-ietf-softwire-dslite-multicast-03.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 : Delivery of IPv4 Multicast Services to IPv4 Clients over an IPv6 Multicast Network Author(s) : Jacni Qin Mohamed Boucadair Christian Jacquenet Yiu L. Lee Qian Wang Filename: draft-ietf-softwire-dslite-multicast-03.txt Pages : 20 Date: 2012-08-23 Abstract: This document specifies a solution for the delivery of IPv4 multicast services to IPv4 clients over an IPv6 multicast network. The solution relies upon a stateless IPv4-in-IPv6 encapsulation scheme and uses the IPv6 multicast distribution tree to deliver IPv4 multicast traffic. The solution is particularly useful for the delivery of multicast service offerings to DS-Lite serviced customers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-softwire-dslite-multicast There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-softwire-dslite-multicast-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-softwire-dslite-mul ticast-03 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 ___ 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] draft-cordeiro-softwire-experience-mapt
Dear Edwin, Thank you for sharing the experiment results. I saw you made tests for torrent applications. FWIW, we had done an extensive testing of this application. The results of these testing are valid for all address sharing variants (including A+P): http://tools.ietf.org/html/draft-boucadair-pcp-bittorrent-00. This I-D provides an explanation for the failure you observed. Cheers, Med -Message d'origine- De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la part de ecorde...@nic.br Envoyé : lundi 17 septembre 2012 20:46 À : softwires@ietf.org Objet : Re: [Softwires] Way forward with MAP-T and 4rd Hello Suresh and all, Regardind MAP-T we, at NIC.br, made some tests to verify the user experience on a network using MAP-T. We published a draft with the results (http://tools.ietf.org/id/draft-cordeiro-softwire-experience-ma pt-00.txt). Any comments are welcome. Best Regards, Edwin Cordeiro NIC.br Quoting Suresh Krishnan suresh.krish...@ericsson.com: Hi all, One of the followup questions we had after choosing the standards track solution was to see what the wg wanted to do with the other two solutions (MAP-T and 4rd). The sense of the room was that the wg was in favor of not abandoning them. We have not verified this formally in the ML and we have not worked out the exact logistics of how we will go about pursuing the other solutions. The chairs will get this process started by the end of this week with a set of questions to the wg. Thanks Suresh Yong ___ 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] [Gen-art] Review: draft-ietf-softwire-stateless-4v6-motivation-04
Dear Joel, Thank you for the review. Please see inline. Cheers, Med -Message d'origine- De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la part de Joel M. Halpern Envoyé : vendredi 5 octobre 2012 17:15 À : A. Jean Mahoney Cc : softwires@ietf.org; gen-...@ietf.org; Yong Cui; draft-ietf-softwire-stateless-4v6-motivat...@tools.ietf.org Objet : [Softwires] [Gen-art] Review: draft-ietf-softwire-stateless-4v6-motivation-04 I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-softwire-stateless-4v6-motivation-04 Motivations for Carrier-side Stateless IPv4 over IPv6 Migration Solutions Reviewer: Joel M. Halpern Review Date: 5-Oct-2012 IETF LC End Date: 17-Oct-2012 IESG Telechat date: 25-Oct-2012 Summary: This document is nearly ready for publication as an Informational RFC. Major issues: I may be misreading the first sub-paragraph in section 3.3.2. It seems to assert that no ALGs are necessary with stateless 4v6 solution as the payload of IPv4 packets is not altered in the path. This seems to make very strong assumptions on the end host behavior, which are not called out in the document. Med: I guess you are referring to this text: Facilitates service evolution: Since the payload of IPv4 packets is not altered in the path, services can evolve without requiring any specific function (e.g., Application Level Gateway (ALG)) in the Service Provider's network; The host behaviour is the same as for deployments where no NAT is enabled in the SP's network. Could you please clarify what is the issue with that text? Would it be better if I change not altered in the path with not altered in Service Provider's network? Minor issues: It is unfortunate that the elaborations on the motivations do not correlate with the initial list of those motivations. They are not in the same order, and do not use the same titles. This makes it harder for the reader who, after reading the base list, is looking for more explanation of item(i). Med: Point taken, I will see how to re-order the list to be aligned with the sections/sub-sections ordering. The description of the anycast capability (Section 3 bullet 5 and section 3.2.1 first bullet) is very unclear. Since packets are not addressed to the address translator, this reader is left confused as to what anycast capability is preserved by this and damaged by stateful NAT. A few additional words in section 3.2.1 would be helpful. Med: What about this change? OLD: anycast-based schemes can be used for load-balancing and redundancy purposes. NEW: anycast-based schemes can be used for load-balancing and redundancy purposes between nodes embedding the Stateless IPv4/IPv6 interconnection function. The issues raised in section 4 of the document (Discussion) are interesting. But they do not seem related to the motivation for seeking a stateless v4v6 solution. They seem to be details of how such a solution might be built. Why is this section in this document? Med: We added this section because we received comments asking for having a section listing the main limitations(?) stateless solutions. It was a fair comment. Nits/editorial comments: ___ 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] [Gen-art] Review: draft-ietf-softwire-stateless-4v6-motivation-04
Dear Joel, Please see inline. Cheers, Med -Message d'origine- De : Joel M. Halpern [mailto:j...@joelhalpern.com] Envoyé : vendredi 5 octobre 2012 17:52 À : BOUCADAIR Mohamed OLNC/OLN Cc : A. Jean Mahoney; softwires@ietf.org; gen-...@ietf.org; Yong Cui; draft-ietf-softwire-stateless-4v6-motivat...@tools.ietf.org Objet : Re: [Softwires] [Gen-art] Review: draft-ietf-softwire-stateless-4v6-motivation-04 Thank you for the prompt followup. Taking things out of order, if the Discussion section were called Limitations, I would have understood why it was there. It is not clear to me that the content actually describes limitations though. It describes design choices that need to be made in specifying and deploying statelessv4v6 solutions. Med: The points listed in that section are usually presented as limitations of the solution. If you noticed I said in my first answer limitations(?) because I disagree those points were limitations but rather open questions which depend on the design choices. On the packet preservation description text in section 3.3.2, I am not sure what assumptions the document makes. For good and appropriate reasons, the document does not describe. I believe tat the ability to avoid ALGs is dependent upon more specific choices of solution, beyond merely the stateless property. Would it be acceptable to weaken the statement in the document to one that notes that stateless solutions admit the possibility of solutions which do not require ALGs? And that such avoidance is highly desirable? Med: Below a text proposal: OLD: Facilitates service evolution: Since the payload of IPv4 packets is not altered in the path, services can evolve without requiring any specific function (e.g., Application Level Gateway (ALG)) in the Service Provider's network; NEW: Facilitates service evolution: Stateless solutions admit applications can be deployed without enabling any application- specific function (e.g., Application Level Gateway (ALG)) in the Service Provider's network. Avoiding ALGs is highly desirable. Better? Yours, Joel On 10/5/2012 11:38 AM, mohamed.boucad...@orange.com wrote: Dear Joel, Thank you for the review. Please see inline. Cheers, Med -Message d'origine- De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la part de Joel M. Halpern Envoyé : vendredi 5 octobre 2012 17:15 À : A. Jean Mahoney Cc : softwires@ietf.org; gen-...@ietf.org; Yong Cui; draft-ietf-softwire-stateless-4v6-motivat...@tools.ietf.org Objet : [Softwires] [Gen-art] Review: draft-ietf-softwire-stateless-4v6-motivation-04 I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-softwire-stateless-4v6-motivation-04 Motivations for Carrier-side Stateless IPv4 over IPv6 Migration Solutions Reviewer: Joel M. Halpern Review Date: 5-Oct-2012 IETF LC End Date: 17-Oct-2012 IESG Telechat date: 25-Oct-2012 Summary: This document is nearly ready for publication as an Informational RFC. Major issues: I may be misreading the first sub-paragraph in section 3.3.2. It seems to assert that no ALGs are necessary with stateless 4v6 solution as the payload of IPv4 packets is not altered in the path. This seems to make very strong assumptions on the end host behavior, which are not called out in the document. Med: I guess you are referring to this text: Facilitates service evolution: Since the payload of IPv4 packets is not altered in the path, services can evolve without requiring any specific function (e.g., Application Level Gateway (ALG)) in the Service Provider's network; The host behaviour is the same as for deployments where no NAT is enabled in the SP's network. Could you please clarify what is the issue with that text? Would it be better if I change not altered in the path with not altered in Service Provider's network? Minor issues: It is unfortunate that the elaborations on the motivations do not correlate with the initial list of those motivations. They are not in the same order, and do not use the same titles. This makes it harder for the reader who, after reading the base list, is looking for more explanation of item(i). Med: Point taken, I will see how to re-order the list to be aligned with the sections/sub-sections ordering. The description of the anycast capability (Section 3 bullet 5 and section 3.2.1 first bullet) is very unclear. Since packets are not addressed to the address translator, this reader is left confused as to what anycast capability is preserved by this and damaged by stateful NAT. A few additional words in section 3.2.1 would be helpful. Med:
Re: [Softwires] I-D Action: draft-ietf-softwire-multicast-prefix-option-02.txt
Dear all, A new version was submitted with the following change: * Remove a normative reference. We believe this version is ready for a WGLC. Cheers, Med -Message d'origine- De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la part de internet-dra...@ietf.org Envoyé : mardi 16 octobre 2012 17:03 À : i-d-annou...@ietf.org Cc : softwires@ietf.org Objet : [Softwires] I-D Action: draft-ietf-softwire-multicast-prefix-option-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 : DHCPv6 Option for IPv4-Embedded Multicast and Unicast IPv6 Prefixes Author(s) : Mohamed Boucadair Jacni Qin Tina Tsou Xiaohong Deng Filename: draft-ietf-softwire-multicast-prefix-option-02.txt Pages : 7 Date: 2012-10-16 Abstract: This document defines Dynamic Host Configuration Protocol version 6 (DHCPv6) Option for multicast transition solutions, aiming to convey the IPv6 prefixes to be used to build unicast and multicast IPv4- embedded IPv6 addresses. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-softwire-multicast- prefix-option There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-softwire-multicast-prefix -option-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-softwire-multicast- prefix-option-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 ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] I-D Action: draft-ietf-softwire-multicast-prefix-option-02.txt
Dear Ted, Please see inline. Cheers, Med -Message d'origine- De : Ted Lemon [mailto:ted.le...@nominum.com] Envoyé : jeudi 18 octobre 2012 14:51 À : BOUCADAIR Mohamed OLNC/OLN Cc : softwires@ietf.org Objet : Re: [Softwires] I-D Action: draft-ietf-softwire-multicast-prefix-option-02.txt In review in the DHC working group (which just started!), Med: As a reminder, I have sent a notification to DHC to review this draft (April 2012). Please refer to http://www.ietf.org/mail-archive/web/dhcwg/current/msg12575.html. Bernie Volz pointed out that you've defined yet another format for IPv6 prefixes in DHCPv6 options, and requests that you use one of the two existing formats. I also notice that it appears that you have a fixed-format option, but some parts of the option may or may not appear depending on server configuration, and that if they do not appear, the option merely has a shorter length. This is contrary to the way things are normally done in DHCP servers, and will require special UI or configuration file tweaks to get right. Med: I can change this easily if you think we need to do so. We use a fixed length because: * SSM_PREFIX64 and ASM_PREFIX64 are /96 * U_PREFIX64 follows RFC6052; it may have variable length with a maximum being /96. It would be better if each of the three optional fields in the option were simply its own option. Is there some strong reason why all three of these fields need to be in the same DHCP option? Med: I have provided an answer to this question here (http://www.ietf.org/mail-archive/web/dhcwg/current/msg12577.html; and given I didn't received an answer from your side I thought you were fine with my explanation. ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] I-D Action: draft-ietf-softwire-dslite-multicast-04.txt
Behcet, Please see inline. Cheers, Med -Message d'origine- De : Behcet Sarikaya [mailto:sarikaya2...@gmail.com] Envoyé : jeudi 18 octobre 2012 21:40 À : BOUCADAIR Mohamed OLNC/OLN Cc : softwires@ietf.org Objet : Re: [Softwires] I-D Action: draft-ietf-softwire-dslite-multicast-04.txt Hi all, On Thu, Oct 18, 2012 at 12:50 AM, mohamed.boucad...@orange.com wrote: Dear all, We submitted an updated version to resolve one open issue for the draft. The main changes are: * Remove a normative reference * Add a new section to describe how address translation is done. * Updated the examples to make use of the IPv6 address block defined in RFC6676. A detailed diff is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-softwire-dslite-mul ticast-04. As suggested by Stig, a message was sent to mboned ML (http://www.ietf.org/mail-archive/web/mboned/current/msg01725.html). We believe this version solves the technical comments raised during WGLC and also against -03. There was a request from Behcet to add some normative references to the draft but this was not accepted (see the mailing list archives). I don't remember what this refers to. Med: I'm referring to this http://www.ietf.org/mail-archive/web/softwires/current/msg04766.html when you asked and I would like this be a normative reference. But I do remember that this draft does not consider a very significant case: IPv6 network may not be multicast enabled. Med: This draft assumes multicast capabilities are enabled in the network. For the case you are referring to, you can use some existing tools (e.g., AMT). If this issue is resolved (it could be resolved by accepting another solution, because more than one solution may be accepted for a given problem/charter item) then my issues with this draft will be resolved. Med: This point was discussed several times (e.g., http://www.ietf.org/mail-archive/web/softwires/current/msg04767.html). Regards, Behcet ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
[Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe
Dear all, As agreed in Atlanta, we prepared an I-D describing a proposed approach for the unified CPE. We hope this version is a good starting point to have fruitful discussion. Your comments, suggestions and contributions are more than welcome. Cheers, Med -Message d'origine- De : i-d-announce-boun...@ietf.org [mailto:i-d-announce-boun...@ietf.org] De la part de internet-dra...@ietf.org Envoyé : jeudi 29 novembre 2012 10:57 À : i-d-annou...@ietf.org Objet : I-D Action: draft-bfmk-softwire-unified-cpe-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Unified Softwire CPE Author(s) : Mohamed Boucadair Ian Farrer Suresh Krishnan Filename: draft-bfmk-softwire-unified-cpe-00.txt Pages : 12 Date: 2012-11-29 Abstract: Transporting IPv4 packets over IPv6 is a common solution to the problem of IPv4 service continuity over IPv6-only provider networks. A number of differing functional approaches have been developed for this, each having their own specific characteristics. As these approaches share a similar functional architecture and use the same data plane mechanisms, this memo describes a specification whereby a single CPE can interwork with all of the standardized and proposed approaches to providing encapsulated IPv4 in IPv6 services. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-bfmk-softwire-unified-cpe There's also a htmlized version available at: http://tools.ietf.org/html/draft-bfmk-softwire-unified-cpe-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ I-D-Announce mailing list i-d-annou...@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe
Dear Maoke, Thank you for the review and comments. Please see inline. Cheers, Med De : Maoke [mailto:fib...@gmail.com] Envoyé : vendredi 30 novembre 2012 03:31 À : Suresh Krishnan Cc : BOUCADAIR Mohamed OLNC/OLN; draft-cui-softwire-b4-translated-ds-lite; draft-ietf-softwire-...@tools.ietf.org; draft-ietf-softwire-public-4ov...@tools.ietf.org; softwires@ietf.org; draft-ietf-softwire-map-d...@tools.ietf.org Objet : Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe thanks Med for the initialization of the work! i noticed that: 1. MAP is working in the context of prefix delegation and therefore the LAN side IPv6 addresses (prefix) is involved in the mapping between the IPv4 and IPv6, while lw4over6 applies the WAN IPv6 address directly. when a unified CPE is made, the logic of the address assignment to interfaces should also consider this difference in the behaviour. [Med] I'm not sure I understand your point. Could you please clarify further the difference between the stateless and binding mode and what you think it should be added to bullet (2.3.2) of Section 3.4? Thanks. 2. is the deployment of difference modes able to be overlapped? current section 4.4 implies the answer is yes. i agree. but is it the best behaviour to select one mode at the device-wise according to a certain preferences? my question is: when the CPE receives multiple rules/parameter-sets from different sources of provisioning, can it store and use these pieces of information to adapt packets for corresponding mode of service, i.e., applying a proper mode on demand and session-specific? [Med] The current text says: o For a given network attachment, only one mode MUST be activated. o The CPE MAY be configured by a user or via remote device management means (e.g., DHCP, TR-069). o A network which supports one or several modes MUST return valid configuration data allowing requesting devices to unambiguously select a single mode to use for attachment. Does this text answer your questions? If not, what you think is needed to be added? Thanks. 3. related to 2, how can we keep the CPE/BR CPE/AFTR consistency? 4. fragmentation issue is common to all modes and it is also needed to be clarified/unified for the unified CPE. [Med] Fully agree. We preferred to focus first on the unified logic. If the WG accepts the proposed direction, then the document should be updated to cover items common to all modes. only my 2 cents, identifying the problems that i expect this draft to cover. - maoke 2012/11/29 Suresh Krishnan suresh.krish...@ericsson.commailto:suresh.krish...@ericsson.com Thanks Med. This is a highly exploratory draft to be used as a strawman to determine if an unified CPE is even possible. Please comment on it so that we can determine if proceeding in this path is worthwhile. Also, if you are interested in being an editor of this draft and are not currently working on any of the current solution drafts please contact the chairs. Thanks Suresh - Original Message - From: mohamed.boucad...@orange.commailto:mohamed.boucad...@orange.com mohamed.boucad...@orange.commailto:mohamed.boucad...@orange.com To: draft-ietf-softwire-...@tools.ietf.orgmailto:draft-ietf-softwire-...@tools.ietf.org draft-ietf-softwire-...@tools.ietf.orgmailto:draft-ietf-softwire-...@tools.ietf.org, draft-ietf-softwire-map-d...@tools.ietf.orgmailto:draft-ietf-softwire-map-d...@tools.ietf.org draft-ietf-softwire-map-d...@tools.ietf.orgmailto:draft-ietf-softwire-map-d...@tools.ietf.org, draft-ietf-softwire-public-4ov...@tools.ietf.orgmailto:draft-ietf-softwire-public-4ov...@tools.ietf.org draft-ietf-softwire-public-4ov...@tools.ietf.orgmailto:draft-ietf-softwire-public-4ov...@tools.ietf.org, draft-cui-softwire-b4-translated-ds-lite draft-cui-softwire-b4-translated-ds-l...@tools.ietf.orgmailto:draft-cui-softwire-b4-translated-ds-l...@tools.ietf.org, Reinaldo Penno (repenno) repe...@cisco.commailto:repe...@cisco.com, softwires@ietf.orgmailto:softwires@ietf.org softwires@ietf.orgmailto:softwires@ietf.org Sent: 11/29/2012 5:16 AM Subject: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe Dear all, As agreed in Atlanta, we prepared an I-D describing a proposed approach for the unified CPE. We hope this version is a good starting point to have fruitful discussion. Your comments, suggestions and contributions are more than welcome. Cheers, Med -Message d'origine- De : i-d-announce-boun...@ietf.orgmailto:i-d-announce-boun...@ietf.org [mailto:i-d-announce-boun...@ietf.orgmailto:i-d-announce-boun...@ietf.org] De la part de internet-dra...@ietf.orgmailto:internet-dra...@ietf.org Envoyé : jeudi 29 novembre 2012 10:57 À : i-d-annou...@ietf.orgmailto:i-d-annou...@ietf.org Objet : I-D Action: draft-bfmk-softwire-unified-cpe-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories.
Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe
Hi Woj, Many thanks for the comments. Please see inline. Cheers, Med -Message d'origine- De : Wojciech Dec (wdec) [mailto:w...@cisco.com] Envoyé : vendredi 30 novembre 2012 11:42 À : BOUCADAIR Mohamed OLNC/OLN; draft-ietf-softwire-...@tools.ietf.org; draft-ietf-softwire-map-d...@tools.ietf.org; draft-ietf-softwire-public-4ov...@tools.ietf.org; draft-cui-softwire-b4-translated-ds-lite; Reinaldo Penno (repenno); softwires@ietf.org Objet : Re: Unified Softwire CPE: draft-bfmk-softwire-unified-cpe Hi, While thanking the authors for their attempt, I need to provide some high level feedback first on key issues: The rationale section 1.1 states co-existance as the goal - this appears to imply some entirely different solutions for which co-existance is needed, and here are two points: A) I can agree that DS.-lite is an entirely different solution, but I firmly believe that it is entirely outside the agreed scope which was a unified solution CPE spec in the context of MAP and Lw4o6. Thus, I would recommend that ds.-lite be dropped from this draft as it bears no influence on unifying MAP and Lw4o6, nor does it bear anything on the already defined and shipped ds.-lite solution. Work on such themes of multiple solutions coexisting is what the v6ops CPE draft is covering and I would place ds.-lite coexistence there. Med: We included DS-Lite in the scope because of the following: * Several WG participants are concerned with optimizing the code and re-using existing modules. * Some DS-Lite components are shared with A+P solution: e.g., tunnel endpoint * A+P may be seen as an exit strategy of the CGN: optimisation migration path and required changes in the CPEs need to be taken into account. B) I disagree that co-existance between Lw4o6 and MAP is a goal; Med: MAP1:1 and lw4o6 are presented in the draft as soltuions for the binding mode. a unified functional CPE spec for NAT44-less core relays accessed via IPv6 is. As such, describing modes as in solution modes is not conductive to that and a solution term neutral functional breakdown is essential and IMO possible (further explained below). This will only make the spec better and simpler for implementers. Med: This is what we tried to do in http://tools.ietf.org/html/draft-bfmk-softwire-unified-cpe-00#section-4.3. In Section 3 the draft coin a new term/class of solution called Binding approach. Med: FYI, this is not a new term: please refer to http://tools.ietf.org/html/rfc6346#section-4.4. This effectively refers to configuration state which *all* solutions need, and is not helpful in providing anything but more verbiage. Removing this classification from all of the text is recommended. Med: IMHO this is the core of the discussion between MAP and Lw4o6 teams. Having a neutral terminology and a full understand of what this is about is IMHO important to converge. Further in section 3 the draft lists different functional elements, and it is here that major changes are needed. Med: Section 3 is to be seen as a reminder for the solution flavors we have on the table. This section can be moved to an appendix. I would expect we focus our discussion on Section 4. For a unified solution a functional breakdown in a solution neutral text is essential. Med: We really tried to adopt a neutral terminology in Section 4. Suggestions are welcome on how to enhance that section. IMO A unified CE has the following basic functionalities, which I propose to be added to the text in place of the existing one: Med: Could you please point me which text you are referring to? Thanks. - IPv4 NAT whose address and port restrictions are configurable - an IPv6 transport whose source and destination transport address are deterministically derived/configurable - an IPv4 routing capability (also configurable) Med: What does that mean? In example terms, consider a CPE configured with IPv4 address, restricted Port range X and IPv6 source address Y and transport address Z. There is no difference in these parameters between Lw4o6 and MAP, and it shows the essence of what we need to get at. Med: Isn't that what is captured in Table 3: Supported Features ? +--++-+-+ | Functional | IPv4-in-IPv6 | Port-restricted | Port-restricted | | Element | tunnel | IPv4 | NAT44 | | |endpoint| | | +--++-+-+ | B4 | Yes | N/A |No | +--++-+-+ | lwB4 | Yes | Yes | Optional| +--++-+-+ | MAP-E CE | Yes | Yes | Optional|
Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe
Hi Simon, Please see inline. Cheers, Med -Message d'origine- De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la part de Simon Perreault Envoyé : vendredi 30 novembre 2012 13:59 À : softwires@ietf.org Objet : Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe Le 2012-11-29 11:16, mohamed.boucad...@orange.com a écrit : As agreed in Atlanta, we prepared an I-D describing a proposed approach for the unified CPE. We hope this version is a good starting point to have fruitful discussion. Your comments, suggestions and contributions are more than welcome. Here are some: - First, I think this is very positive. I like what I'm reading. Med: Thanks. - Didn't we also consider public 4o6 as one mode? Any reason why it was left out? - Is public 4o6 the minor change to lw4o6 that section 4.1 hints at? Med: The rationale we adopted in this draft is as follows: * there are three major flavors: full stateful, full stateless, and binding mode * all these modes can support assigning a full or a shared IPv4 address As such Public4over6 is classified as part of binding mode (see Section 3) (2) Binding approach (e.g., Lightweight 4over6 (Lw4o6) [I-D.cui-softwire-b4-translated-ds-lite], [I-D.ietf-softwire-public-4over6] or MAP 1:1 [I-D.ietf-softwire-map] ): Requires a single per-subscriber state (or a few) to be maintained in the Service Provider's network. - In section 3.2. Required Provisoning Information, I believe it would be possible and beneficial to specify only what each mode requires *in addition* to what the previous mode already provides. e.g. - DS-Lite requires the remote tunnel endpoint address. - In addition to that, lw4o6 requires the CPE's IPv4 address and port set. - In addition to that, MAP requires mesh routes. So each mode's provisioning parameters would be a superset of the previous one. (DS-Lite lw4o6 MAP) Med: The current text of Section 3.2 says: +-+-+ |Mode | Provisioning Information| +-+-+ | DS-Lite | Remote IPv4-in-IPv6 Tunnel Endpoint | | Lw4o6 | Remote IPv4-in-IPv6 Tunnel Endpoint | | | IPv4 Address| | | Port Set| | MAP-E | Mapping Rules | | | MAP Domain Parameters | +-+-+ Table 4: Provisioning Information Note: MAP Mapping Rules are translated into the following configuration parameters: Set of Remote IPv4-in-IPv6 Tunnel Endpoints, IPv4 Address and Port Set. Can you please explicit the change you want to see appear in that text? Thanks. One we have this kind of hierarchical provisioning, we can define CPE behaviour in the same way. For example, MAP behaviour would be: 1. Do exactly what a lw4o6 CPE does. 2. In addition to 1, also send and receive packets directly to and from other CPEs according to the provisioned mesh routes. Med: Do you think this is different from the approach adopted in Section 4.3? (I will refrain from commenting on section 4.4 until we have the higher-level design figured out.) Simon -- DTN made easy, lean, and smart -- http://postellation.viagenie.ca NAT64/DNS64 open-source-- http://ecdysis.viagenie.ca STUN/TURN server -- http://numb.viagenie.ca ___ 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
