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
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.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. *) 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? Yes, actually the multiple rules ([IPv6 DomPref, IPv4 DomPref] pairs) are used to accommodate fragmented IPv4 address spaces. 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. Not necessary, for encapsulation, the next header can be used to distinguish the traffic. In addition, a special IID is defined, which can be used in the translation context. Cheers, Jacni ___ 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 Mohamed, I am a developer of 4rd which is used by Nejc. From my perspective, the complexity is not coming from the algorithm itself but I think the complex is depend on the implementation as well. So, I don't think it is good to make a conclusion with a given implementation only. In fact, I have already improved my 4rd implementation. Nejc is using the old version. I think I could improve 4rd configuration in the latest version of my implementation. So, I think we should clarify the complexity from clear cannon which should be coming from many perspective such as algorithm, implementation, etc. Thanks, Tetsuya Murakami On 2011/09/06, at 22:35, mohamed.boucad...@orange-ftgroup.com mohamed.boucad...@orange-ftgroup.com wrote: 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. 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 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 ___ 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)
Le 7 sept. 2011 à 09:55, Satoru Matsushima a écrit : ... And from my experience, none of configuration complexity for 4rd implementations. These don't require any complicated configuration to generate port-set from port-set ID. +1 (in addition to my personal comments) 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)
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. Difficulty to configure is rather minimal with solutions that are completely stateless. Having High complexity for 4rd-addmapping can therefore be misleading. (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 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 ___ 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)
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.com 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.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. Here is a tentative contribution in this direction. Major criteria to evaluate port-indexing methods: a) Fairness (no CPE gets well-known ports 0-1023) b) RTP/RTCP compatibility c) Stateless BR support of multiple CPE-port-set sizes d) UPnP friendliness (interleaved port sets) 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. *) 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? Yes, still stateless. The BR doesn't need to know the length of a CPE prefix to build an address that starts with the CPE prefix. It may have bits beyond the CPE prefix, but the CPE ignores them. Kind regards, RD 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. IPv4 traffic is recognized by the fact that Interface ID is a 4rd IID (sec 5.3) 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.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.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
Re: [Softwires] draft-murakami-softwire-4v6-translation
Le 22 août 2011 à 19:41, Cameron Byrne a écrit : 2011/8/22 Nejc Škoberne n...@skoberne.net: Dear Cameron, some pressure. IMHO, i believe that static over-subscription ratios required by A+P will not meaningfully keep pace with the rapid growth in the number of internet nodes. I would be very happy if you elaborated on this. Can you give something to support this belief? Easy math version assuming the entire internet moves to this model of stateless address sharing: 50 Billion Internet nodes [1] 240 Million IPv4 addresses [2] 208.3 devices per IPv4 address -- by dividing the above numbers 312.5 ports per user -- by dividing by 65k ports 312 ports per host for IPv4, while more and more sites are accessible in IPv6 and consume no IPv4 port, is in my understanding a comfortable perspective. Regards, RD Not a perfect guesstimate on several levels since the internet is not uniform and does move to anything in a uniform, the numbers used above are suspect, and this is not an internet wide solution, some nodes may go IPv6 only, and so on ... but sometimes looking at numbers like this in the macroscopic view helps us understand our little part of the internet that we are trying to design a solution for. As stated, some providers may find a benefit here... I believe that is clear. My understanding is that in North America many of the incumbent land line providers have fairly static subscriber bases, not a lot of growth in users demanding IPv4. In my world (mobile), AFAIK approximately half of the service providers globally already do NAT44 / LSN / CGN. Areas of the internet that are experiencing or anticipate rapid growth (mobile, cloud, new ventures) in address consumption will likely not extend their existing addresses far with a stateless solution. Regards, Cameron [1] http://www.ericsson.com/thecompany/press/releases/2010/04/1403231 [2] http://tools.ietf.org/html/rfc3194 Thanks, Nejc ___ 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)
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.com 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.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. Here is a tentative contribution in this direction. Major criteria to evaluate port-indexing methods: a) Fairness (no CPE gets well-known ports 0-1023) b) RTP/RTCP compatibility c) Stateless BR support of multiple CPE-port-set sizes d) UPnP friendliness (interleaved port sets) 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. *) 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? Yes, still stateless. The BR doesn't need to know the length of a CPE prefix to build an address that starts with the CPE prefix. It may have bits beyond the CPE prefix, but the CPE ignores them. Kind regards, RD 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. IPv4 traffic is recognized by the fact that Interface ID is a 4rd IID (sec 5.3) 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.com wrote: Dear all, We have just submitted an I-D analysing the port set algorithms we have on the table. A set of propertiesare 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) :
[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] Call for presentations for the interim meeting
Thanks so much, Dan. Hope you can join the interim meeting. Yong -Original Message- From: Dan Wing dw...@cisco.com Date: Tue, 6 Sep 2011 16:37:19 -0700 To: 'Alain Durand' adur...@juniper.net, softwires@ietf.org, Yong Cui cuiy...@tsinghua.edu.cn Subject: RE: [Softwires] Call for presentations for the interim meeting -Original Message- From: softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] On Behalf Of Alain Durand Sent: Monday, August 22, 2011 8:37 AM To: softwires@ietf.org; Yong Cui Subject: [Softwires] Call for presentations for the interim meeting As we mentioned earlier, the softwire interim meeting will focus on 'stateless solutions'. If you'd like to present there, please send the chairs a note by Friday this week. After seeing a bunch of replies to this request, I have a feeling of unease. We -- the IETF -- need to reach some decisions on the direction we're going to move forward. To do that, we need comparisons so we can make educated and informed decisions. Documents like draft-bsd-softwire-stateless-port-index-analysis and draft-dec-stateless-4v6 are on the right track -- I hope we can discuss them in more detail prior to the interim. Can the chairs and presenters please consider spending a majority of the interim meeting discussing the merits of different approaches, rather than presentations of how-this-Internet-Draft-encodes-bits-on-the-wire? Wishing for a fruitful Softwire interim meeting, -d ___ 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)
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. Here's a suggestion: configuration complexity could be measured in terms of the number of parameters necessary. This is an objective criteria. 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
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
[Softwires] Use cases of the Domain IPv6 suffix of the 4rd address mapping
Hi Satoru-san, Tetsuya-san, As you have seen, I-D.despres-4rd-addmapping includes for the first time an explanation about use cases of the Domain IPv6 suffix (sec 5.5 titled The CPE cascade option). As originators of the need for this option, could you please check what is written and tell whether this correctly reflects use cases you want to be possible? Thanks, RD ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Softwire Interim Meeting in Beijing
Alain, The agenda for the interim meeting contradicts what was said during the IETF81 v6ops (thanks to the recording (.mp3 url) and corresponding transcript below), so I would appreciate any clarity you could provide. With such a narrow-defined agenda, which doesn't allow discussion, analysis, and comparison of various stateless 4v6 transition options as the 1st step, many folks may just boycott and discount whatever is decided in the interim meeting. This is not only unproductive, but also unreasonable for those who have decided to attend the interim meeting. Audio recording from v6ops ### http://www.ietf.org/audio/ietf81/ietf81-205abc-20110728-1256-pm.mp3 Transcript: Alain: This is done in Softwire. We are planning to organize an interim meeting in September, in some part of the world, to actually go through all the technical solutions that have been put forward and analyze them and do what we did at the beginning of Softwires. Pretty intensive interim meeting, locked in a room, and figure out what we need. Fred: So, Alain, we are finally going to have the discussion. Alain: We are actually going to make technical progress on this - more than just discussing. Jari: suggested doing everything in one group (implying a new WG). Alain: there are no more groups. We will just do it now. On the other hand, the agenda for the interim meeting is the following: Interim meeting Agenda ## 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... I am afraid that the interim meeting agenda would end up allowing more than one WGs work on 4v6 transition options. Not the best intent in favor of larger internet community. Cheers, Rajiv -Original Message- From: Rajiv Asati (rajiva) Sent: Friday, August 19, 2011 11:04 AM To: 'Alain Durand' Cc: Yong Cui; softwires@ietf.org; liziye; iesg-secret...@ietf.org; Ralph Droms (rdroms) Subject: 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 ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04
Hi Med, In line with [TT2]... Best Regards, Tina From: mohamed.boucad...@orange-ftgroup.com [mailto:mohamed.boucad...@orange-ftgroup.com] Sent: Thursday, August 25, 2011 12:06 AM To: Tina TSOU; Jacni Qin Cc: softwires@ietf.org Subject: 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é : mercredi 24 août 2011 20:26 À : BOUCADAIR Mohamed OLNC/NAD/TIP; Jacni Qin Cc : softwires@ietf.org Objet : RE: [Softwires] Comments on draft-qin-softwire-dslite-multicast-04 Bonjour Med, Ca va? Thank you for your deep insight and reply. When the IPv6 packet comes, how does mB4 know it should make encapsulation or translation if mPrefix64 and uPrefix64 are the same? As defined in section 6.3 of draft-boucadair-behave-64-multicast-address-formathttp://tools.ietf.org/html/draft-qin-softwire-dslite-multicast-04#ref-I-D.boucadair-behave-64-multicast-address-format, there is no need to reserve a bit in the IPv6 multicast address to separate between the translation and the encapsulation schemes. So when mPrefix64 and uPrefix64 are the same for both encapsulation and translation, mB4 could not make decision which operation to make. In this case, the IPv6 header itself can be used to identify encapsulation or translation. For example, if the next header of IPv6 header is 4, mB4 should make de-capsulation because there is IPv4 packet inside. If it is other value, translation may be needed. [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? From: softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] On Behalf Of mohamed.boucad...@orange-ftgroup.com Sent: Tuesday, August 23, 2011 11:54 PM To: Tina TSOU; Jacni Qin Cc: softwires@ietf.org Subject: 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
Re: [Softwires] Comments on section 6.3 of draft-qin-softwire-dslite-multicast-04
Yiu, Thank you for your good comments, even in the hurricane. I am proposing modify the texts in the document to be more accurate since PMTU is unable to avoid fragmentation here. Cache in mAFTR maybe one possible way, but I agree that it is more complicated. For the time being, there are two issues I can see. First, the path of multicast may be not consistent with unicast. Second, if m AFTR sends PMTU to every B4s and take the least common denominator, the efficiency will be reduced. There may be malicious reduction of PMTU value. But if we set the acceptable minimum value of PMTU at mAFTR, this problem may be solved. Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html From: softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] On Behalf Of Lee, Yiu Sent: Monday, August 29, 2011 12:16 AM To: softwires@ietf.org Subject: Re: [Softwires] Comments on section 6.3 of draft-qin-softwire-dslite-multicast-04 Hi Tina, To use PMTU in this scenario, this is more complicated than what you explain. First, this traffic flow is from mAFTR to the mB4. In between, there could be more than one IPv6 multicast routers. In our spec, mAFTR will replicate the packet once in the multicast I/F to the IPv6 MDT, can you explain to me your poropose how PMTU can work here? Does it mean mAFTR will send PMTU to every B4s and take the least common denominator? Regards, Yiu From: Jacni Qin jac...@gmail.commailto:jac...@gmail.com Date: Sat, 27 Aug 2011 09:48:12 +0800 To: Tina TSOU tina.tsou.zout...@huawei.commailto:tina.tsou.zout...@huawei.com Cc: softwires@ietf.orgmailto:softwires@ietf.org softwires@ietf.orgmailto:softwires@ietf.org Subject: Re: [Softwires] Comments on section 6.3 of draft-qin-softwire-dslite-multicast-04 hi, On Sat, Aug 27, 2011 at 2:32 AM, Tina TSOU tina.tsou.zout...@huawei.commailto:tina.tsou.zout...@huawei.com wrote: Dear Jacni, Just after reading RFC 1981, I think fragmentation of IPv6 is needed. In section 5.1, it says, It is possible that a packetization layer, perhaps a UDP application outside the kernel, is unable to change the size of messages it sends. This may result in a packet size that exceeds the Path MTU. To accommodate such situations, IPv6 defines a mechanism that allows large payloads to be divided into fragments, with each fragment sent in a separate packet (see [IPv6-SPEC] section Fragment Header). If the node which makes PMTU is the multicast source, it can change the size of message when the size exceeds the PMTU value. However, mAFTR, as a router, is unable to change the size of the message. Here is an example: An IPv4 packet is sent from the multicast source to mAFTR with size of 1000, while the IPv6 PMTU for mAFTR and mB4 is 960, how does mAFTR forward the packet? One possible way is to make IPv6 fragmentation, with two fragments: one is 960 and the other is 40 with IPv6 Fragment Header. In addition, there may be also other ways to avoid fragmentation, e.g., cache in mAFTR as defined in [draft-jiang-behave-v4v6mc-proxy]. Jacni: Please see Yiu's comments, while for the discovery if you really want to do it, this way to help you to understand, it's the end point of tunnel which seems to source the v6 packets. Hope you can get it. Cheers, Jacni ___ 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 section 6.3 of draft-qin-softwire-dslite-multicast-04
Hi Yiu, Thank you for your prompt reply. I am not saying the multicast path must be consistent with unicast path. I was trying to explain that PMTU is not a good way to avoid fragmentation in this scenario. Anyway, my proposal to the draft is to delete the texts after or in section 6.3. 6.3. Fragmentation Encapsulating IPv4 over IPv6 from mAFTR to mB4 for data forwarding reduces the effective MTU size by the size of an IPv6 header (assuming [RFC2473http://tools.ietf.org/html/rfc2473] encapsulation). To avoid fragmentation, a service provider may increase the MTU size by 40 bytes on the IPv6 network or mAFTR and mB4 may use IPv6 Path MTU discovery. Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html From: Lee, Yiu [mailto:yiu_...@cable.comcast.com] Sent: Thursday, September 01, 2011 11:25 AM To: Tina TSOU; softwires@ietf.org Subject: Re: [Softwires] Comments on section 6.3 of draft-qin-softwire-dslite-multicast-04 Hi Tina, I can't understand the two issues. (1) Why the multicast path must be consistent with unicast path? All PIM cares is to pass RPF check. If an operator decides to do traffic engineering on the multicast path, it is possible the multicast path is different from the unicast path. (2) My last email tried to explain that it is impractical to use PMTU in this scenario. It is pointless to discuss in the draft. B.R., Yiu From: Tina TSOU tina.tsou.zout...@huawei.commailto:tina.tsou.zout...@huawei.com Date: Thu, 1 Sep 2011 16:59:49 + To: Yiu L. LEE yiu_...@cable.comcast.commailto:yiu_...@cable.comcast.com, softwires@ietf.orgmailto:softwires@ietf.org softwires@ietf.orgmailto:softwires@ietf.org Subject: RE: [Softwires] Comments on section 6.3 of draft-qin-softwire-dslite-multicast-04 Yiu, Somehow this email was delayed in some magic part of my email system, or awaits the list administrator's approval. Resending... I am proposing modify the texts in the document to be more accurate since PMTU is unable to avoid fragmentation here. Cache in mAFTR maybe one possible way, but I agree that it is more complicated. For the time being, there are two issues I can see. First, the path of multicast may be not consistent with unicast. Second, if m AFTR sends PMTU to every B4s and take the least common denominator, the efficiency will be reduced. There may be malicious reduction of PMTU value. But if we set the acceptable minimum value of PMTU at m AFTR, this problem may be solved. Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html From: softwires-boun...@ietf.orgmailto:softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] On Behalf Of Lee, Yiu Sent: Sunday, August 28, 2011 9:16 AM To: softwires@ietf.orgmailto:softwires@ietf.org Subject: Re: [Softwires] Comments on section 6.3 of draft-qin-softwire-dslite-multicast-04 Hi Tina, To use PMTU in this scenario, this is more complicated than what you explain. First, this traffic flow is from mAFTR to the mB4. In between, there could be more than one IPv6 multicast routers. In our spec, mAFTR will replicate the packet once in the multicast I/F to the IPv6 MDT, can you explain to me your poropose how PMTU can work here? Does it mean mAFTR will send PMTU to every B4s and take the least common denominator? Regards, Yiu From: Jacni Qin jac...@gmail.commailto:jac...@gmail.com Date: Sat, 27 Aug 2011 09:48:12 +0800 To: Tina TSOU tina.tsou.zout...@huawei.commailto:tina.tsou.zout...@huawei.com Cc: softwires@ietf.orgmailto:softwires@ietf.org softwires@ietf.orgmailto:softwires@ietf.org Subject: Re: [Softwires] Comments on section 6.3 of draft-qin-softwire-dslite-multicast-04 hi, On Sat, Aug 27, 2011 at 2:32 AM, Tina TSOU tina.tsou.zout...@huawei.commailto:tina.tsou.zout...@huawei.com wrote: Dear Jacni, Just after reading RFC 1981, I think fragmentation of IPv6 is needed. In section 5.1, it says, It is possible that a packetization layer, perhaps a UDP application outside the kernel, is unable to change the size of messages it sends. This may result in a packet size that exceeds the Path MTU. To accommodate such situations, IPv6 defines a mechanism that allows large payloads to be divided into fragments, with each fragment sent in a separate packet (see [IPv6-SPEC] section Fragment Header). If the node which makes PMTU is the multicast source, it can change the size of message when the size exceeds the PMTU value. However, mAFTR, as a router, is unable to change the size of the message. Here is an example: An IPv4 packet is sent from the multicast source to mAFTR with size of 1000, while the IPv6 PMTU for mAFTR and mB4 is 960, how does mAFTR forward the packet? One possible way is to make IPv6 fragmentation, with two fragments: one is 960 and the other is 40 with IPv6 Fragment Header. In addition, there may be also other ways to avoid fragmentation, e.g., cache in mAFTR as defined in [draft-jiang-behave-v4v6mc-proxy]. Jacni: Please see Yiu's
[Softwires] [Softwires] draft-xli-behave-divi-pd
In the appendix we use v and h represent the IPv4 subnet (hex) and host index (hex). The length of v is (s), and the length of h is (k) as shwon in Figure 2. Could you kindly elaborate that more? How could a specific IPv4-translatable address be derived? I can't fully follow the algorithm. It would be great if you could take example, like how 2001:db8:a4a6:4614:c0:a801:140:100 (item#2) could be generated. Thanks Joy ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
[Softwires] Fwd: v6ops - ietf81 recording
Alain: I have a question. In your recent note to softwire, you seem to be changing the charter that you and Jari stated in v6ops at IETF-81. At IETF-81, you stated that there was no need for a translation-related working group because translation (specifically the dIVI proposal, but more generally translation) would be part of the ongoing softwire charter. In your more recent statements, you appear to be saying that the topic would be discussed in a vs setting and buried because the IETF has decided to not work on translation. I'll remind you that the IETF has not only chosen to work on translation, but to standardize it along with tunneling technologies. I call on you to not only give lip service to discussion, but to allow and support open discussion of stateless a+p tunneling (as apposed to ds-lite, which is stateful) and translation, as you said you would. Fred Alain's translation statement is ~2hrs 57 min into the recording at: http://www.ietf.org/audio/ietf81/ietf81-205abc-20110728-1256-pm.mp3 Transcript: Alain: This is done in Softwire. We are planning to organize an interim meeting in September, in some part of the world, to actually go through all the technical solutions that have been put forward and analyze them and do what we did at the beginning of Softwires. Pretty intensive interim meeting, locked in a room, and figure out what we need. Fred: So, Alain, we are finally going to have the discussion. Alain: We are actually going to make technical progress on this - more than just discussing. Jari suggested doing everything in one group (implying a new WG). Alain: there are no more groups. We will just do it now. ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] v6ops - ietf81 recording
Fred: The way I phrased the call for the interim meeting on the mailling list might have created some unwanted confusion. Yong and I are going to publish the agenda for the interim meeting very soon. There will be ample time to discuss the various propositions on the table in the 'stateless' arena (that I can define loosely as no centralized CGN) Some more stateless than others, some more stateful than others, some based on tunnels and some based on translation. Giving ample time to discuss all those solution is the very reason of the interim meeting. Is that clearer? - Alain. On Sep 7, 2011, at 3:10 PM, Fred Baker wrote: Alain: I have a question. In your recent note to softwire, you seem to be changing the charter that you and Jari stated in v6ops at IETF-81. At IETF-81, you stated that there was no need for a translation-related working group because translation (specifically the dIVI proposal, but more generally translation) would be part of the ongoing softwire charter. In your more recent statements, you appear to be saying that the topic would be discussed in a vs setting and buried because the IETF has decided to not work on translation. I'll remind you that the IETF has not only chosen to work on translation, but to standardize it along with tunneling technologies. I call on you to not only give lip service to discussion, but to allow and support open discussion of stateless a+p tunneling (as apposed to ds-lite, which is stateful) and translation, as you said you would. Fred Alain's translation statement is ~2hrs 57 min into the recording at: http://www.ietf.org/audio/ietf81/ietf81-205abc-20110728-1256-pm.mp3 Transcript: Alain: This is done in Softwire. We are planning to organize an interim meeting in September, in some part of the world, to actually go through all the technical solutions that have been put forward and analyze them and do what we did at the beginning of Softwires. Pretty intensive interim meeting, locked in a room, and figure out what we need. Fred: So, Alain, we are finally going to have the discussion. Alain: We are actually going to make technical progress on this - more than just discussing. Jari suggested doing everything in one group (implying a new WG). Alain: there are no more groups. We will just do it now. ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] v6ops - ietf81 recording
On Sep 7, 2011, at 1:58 PM, Alain Durand wrote: Fred: The way I phrased the call for the interim meeting on the mailling list might have created some unwanted confusion. Yong and I are going to publish the agenda for the interim meeting very soon. There will be ample time to discuss the various propositions on the table in the 'stateless' arena (that I can define loosely as no centralized CGN) Some more stateless than others, some more stateful than others, some based on tunnels and some based on translation. Giving ample time to discuss all those solution is the very reason of the interim meeting. Is that clearer? Hopefully. There is a pretty strong concern here that the meeting is being arranged to encourage certain outcomes. I'd really hope for a level playing field, whatever the outcome may turn out to be. - Alain. On Sep 7, 2011, at 3:10 PM, Fred Baker wrote: Alain: I have a question. In your recent note to softwire, you seem to be changing the charter that you and Jari stated in v6ops at IETF-81. At IETF-81, you stated that there was no need for a translation-related working group because translation (specifically the dIVI proposal, but more generally translation) would be part of the ongoing softwire charter. In your more recent statements, you appear to be saying that the topic would be discussed in a vs setting and buried because the IETF has decided to not work on translation. I'll remind you that the IETF has not only chosen to work on translation, but to standardize it along with tunneling technologies. I call on you to not only give lip service to discussion, but to allow and support open discussion of stateless a+p tunneling (as apposed to ds-lite, which is stateful) and translation, as you said you would. Fred Alain's translation statement is ~2hrs 57 min into the recording at: http://www.ietf.org/audio/ietf81/ietf81-205abc-20110728-1256-pm.mp3 Transcript: Alain: This is done in Softwire. We are planning to organize an interim meeting in September, in some part of the world, to actually go through all the technical solutions that have been put forward and analyze them and do what we did at the beginning of Softwires. Pretty intensive interim meeting, locked in a room, and figure out what we need. Fred: So, Alain, we are finally going to have the discussion. Alain: We are actually going to make technical progress on this - more than just discussing. Jari suggested doing everything in one group (implying a new WG). Alain: there are no more groups. We will just do it now. ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Softwire Interim Meeting in Beijing
I hope the agenda I just published will clear things up. - Alain On Sep 7, 2011, at 4:19 PM, Rajiv Asati (rajiva) wrote: Alain, The agenda for the interim meeting contradicts what was said during the IETF81 v6ops (thanks to the recording (.mp3 url) and corresponding transcript below), so I would appreciate any clarity you could provide. With such a narrow-defined agenda, which doesn't allow discussion, analysis, and comparison of various stateless 4v6 transition options as the 1st step, many folks may just boycott and discount whatever is decided in the interim meeting. This is not only unproductive, but also unreasonable for those who have decided to attend the interim meeting. Audio recording from v6ops ### http://www.ietf.org/audio/ietf81/ietf81-205abc-20110728-1256-pm.mp3 Transcript: Alain: This is done in Softwire. We are planning to organize an interim meeting in September, in some part of the world, to actually go through all the technical solutions that have been put forward and analyze them and do what we did at the beginning of Softwires. Pretty intensive interim meeting, locked in a room, and figure out what we need. Fred: So, Alain, we are finally going to have the discussion. Alain: We are actually going to make technical progress on this - more than just discussing. Jari: suggested doing everything in one group (implying a new WG). Alain: there are no more groups. We will just do it now. On the other hand, the agenda for the interim meeting is the following: Interim meeting Agenda ## 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... I am afraid that the interim meeting agenda would end up allowing more than one WGs work on 4v6 transition options. Not the best intent in favor of larger internet community. Cheers, Rajiv -Original Message- From: Rajiv Asati (rajiva) Sent: Friday, August 19, 2011 11:04 AM To: 'Alain Durand' Cc: Yong Cui; softwires@ietf.org; liziye; iesg-secret...@ietf.org; Ralph Droms (rdroms) Subject: 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 ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Use cases of the Domain IPv6 suffix of the 4rd address mapping
Re-, On 9/7/2011 11:03 PM, Rémi Després wrote: Hi Satoru-san, Tetsuya-san, As you have seen, I-D.despres-4rd-addmapping includes for the first time an explanation about use cases of the Domain IPv6 suffix (sec 5.5 titled The CPE cascade option). As originators of the need for this option, could you please check what is written and tell whether this correctly reflects use cases you want to be possible? And, can you please elaborate the use cases/needs? That will be quite helpful, thanks. Cheers, Jacni Thanks, 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
