Re: [Softwires] Path to move forward with 4rd
4rd-U is in the very early design stage, there is no running code. In addition, it tries to modify the IPv6 address architecture. We need to see the experimental data before making any decision. -- Zhang Huanjie E-mail/msn: ja...@ustc.edu.cn ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Path to move forward with 4rd
Is there experimental data for MAP running on production networks? Certainly that is an important point to consider. On 3/22/12 11:06 PM, Zhang Huanjie ja...@ustc.edu.cn wrote: 4rd-U is in the very early design stage, there is no running code. In addition, it tries to modify the IPv6 address architecture. We need to see the experimental data before making any decision. -- Zhang Huanjie E-mail/msn: ja...@ustc.edu.cn ___ 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Š
Hello Guanghui, 2012/3/23, Guanghui Yu yu.guang...@gmail.com: Hi all To define the transtion extension has the same problem, it still is a new packet for existing devices. 4rd-U cannot replace MAP-T, since it cannot support single translation. I guess the concern of single translation has already been addressed in http://www.ietf.org/mail-archive/web/softwires/current/msg03724.html BRs Gang 4rd-U cannot replace MAP-E, since it cannot support IPv4 option. Therefore, it is no way for 4rd-U to replace MAP series. BTW, we need both encapsulation and translation, i.e. MAP-E and MAP-T. On Fri, Mar 23, 2012 at 12:55 PM, Lee, Yiu yiu_...@cable.comcast.comwrote: Hi Guanghui, I have to admit that I am not IPv6 protocol expert. I guess Remi took the fragmentation header and overload it for his design. Say he defines a new extension called transition extension, I would guess it would no longer overload the fragmentation extension. I don't know enough the current implementation of the FIB and how u,g in 4rd-u design would impact the implementation. I have homework to do. Apart from that, I found MAP and 4rd-u are similar technologies trying to solve the same problem. So far I follow all the discussions in the mailing list about this topics. Technically speaking, they have pros and cons. I fail to see one is absolutely superior than the other. Both designs make trade-offs. When we come to WG adoption, I am completely fine if the WG decides one over the other. That said, the current discussion reminds me about OSPF vs IS-IS. They are so similar but yet have subtle differences. Today, both protocols are running in production. Best case scenario is the authors can balance the trade-offs and merge two drafts. If not WG could potentially publish both techs (e.g. one standard track and one informational/experimental) and let the market force to decide. B.R., Yiu P.S. When I say MAP, I mean all 3 drafts (T/M/A+P). I see them one complete series. From: Guanghui Yu yu.guang...@gmail.com Date: Fri, 23 Mar 2012 11:04:54 +0800 To: Yiu L. LEE yiu_...@cable.comcast.com Cc: Softwires WG softwires@ietf.org Subject: Re: [Softwires] Path to move forward with 4rdŠ Hi Yiu 4rd-u changes the IPv6 header architecture (redefine fragmentation header extension) and IPv6 address architecture (different meaning of u-bit when g-bit=1). These are the fundamental changes. If 4rd-u becomes the standard, then there will be new defined “IPv6” packets on the Internet, which are not compatible with existing IPv6 packets and no existing devices can understand those packets. Yu Guanghui ygh at dlut.edu.cn Network and Information Center Dalian University of Technology, China On Fri, Mar 23, 2012 at 10:10 AM, Lee, Yiu yiu_...@cable.comcast.comwrote: Hi Guanghui, I agree that both MAP and 4rd-u are similar technology and solving the same problem. From technical perspective, can you elaborate this a lithe bit? Thanks, Yiu From: Guanghui Yu yu.guang...@gmail.com Date: Thu, 22 Mar 2012 20:26:40 +0800 To: Softwires WG softwires@ietf.org Subject: Re: [Softwires] Path to move forward with 4rd… I read 4rd-u draft and found it is flawed. -- Yu Guanghui ygh at dlut.edu.cn Network and Information Center Dalian University of Technology, China ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
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] MAP and 4rd - Relationship with Single translation
Le 2012-03-23 à 02:54, Xing Li a écrit : Hi, Remi, 于 2012/3/19 21:22, Rémi Després 写道: Hi, Xing, I look forward to face to face discussions in Paris if we don't clarify everything before that (I will be busy on something else in the next 3 days). Le 2012-03-18 à 23:39, Xing Li a écrit : ... A key point is that 4rd doesn't prevent a 4rd-capable dual-stack CE node, when it receives no 4rd mapping rule, to exercise single translation. Actually, I believe that using for this the BIH of RFC6535 is both sufficient and recommendable. Translated IPv4 packets, because they are sent from CE nodes to DNS64 synthesized addresses, are appropriately routed to their destinations. (It can be via the NAT64-CGN if needed, or via more direct paths if possible.) Anything missed? Sorry, this is a misunderstanding. Hint: Single translation and double translation are based on the same mapping rule in the CERNET2 deployment. I am well aware of this, but this doesn't explain why 4rd mapping rules similar to those of CERNET2 wouldn't have, like MAP-T, IPv4 to IPv6 communication (single translation) supported. As said in RFC6219, CERNET hosts have their IPv6 addresses configured via manual configuration or stateful autoconfiguration via DHCPv6. Hosts can therefore be assigned Interface IDs that have the 4rd-u format (with V octet and CNP). Now, when both addresses happen to be checksum neutral, RFC6145 translation doesn't modify L4 data, so that it doesn't matter whether the DS node has used 4rd-u header mapping or single translation. Thus, IPv6-only hosts can exchange packets with IPv4 applications of 4rd CE nodes. Sorry, it still a misunderstanding. one BRM per CPE, or ONE IPv6 for host. Let me ask again, then, for an example with its mapping rules and IPv4 prefixes. We can then discuss with facts. Without that IPv4 to IPv6 communication (single translation) supported remains a claim, not a feature others can verify. Thanks, RD Regards, xing Regards, RD Regards, xing Regards, RD Regards, xing Regards, RD Le 2012-02-10 à 04:28, Xing Li a écrit : ... | | | | | | 5 | IPv6 web caches work for IPv4| Y | N | Y | N | || packets | | | | | suggest you rename to IPv4 to IPv6 communication (single translation) supported (2) More clarification should be added here. I am not sure 4rd-H can support single translation. (a) According to (1), 4rd-H does not perform header translation defined by RFC6145. (b) In the softwire mailing list, it seems that 4rd-H cannot support single translation. See the thread containing http://www.ietf.org/mail-archive/web/softwires/current/msg03324.html and other posts. (c) If 4rd-H cannot support single translation, then IPv6 web caches work for IPv4 packets requires special configurations, it cannot do IPv6 web caches for non 4rd-H packets. ... (5) I would like to see the details of how 4rd-H handles ICMP and ICMP error messages. In the softwire mailing list there were some discussions. See the thread containing http://www.ietf.org/mail-archive/web/softwires/current/msg03324.html and other posts. Please add | 17 | Handle ICMP (RFC6145) | Y | n/a | ? | ? | ... ___ 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Š
Yiu, I have to admit that I am not IPv6 protocol expert. I guess Remi took the fragmentation header and overload it for his design. Say he defines a new extension called transition extension, I would guess it would no longer overload the fragmentation extension. I don't know enough the current implementation of the FIB and how u,g in 4rd-u design would impact the implementation. I have homework to do. Type 3 Routing Header? we've tried this type of tunneling before. ;-) Apart from that, I found MAP and 4rd-u are similar technologies trying to solve the same problem. So far I follow all the discussions in the mailing list about this topics. Technically speaking, they have pros and cons. I fail to see one is absolutely superior than the other. Both designs make trade-offs. When we come to WG adoption, I am completely fine if the WG decides one over the other. That said, the current discussion reminds me about OSPF vs IS-IS. They are so similar but yet have subtle differences. Today, both protocols are running in production. Best case scenario is the authors can balance the trade-offs and merge two drafts. If not WG could potentially publish both techs (e.g. one standard track and one informational/experimental) and let the market force to decide. the authors did already do that. the dIVI and 4rd authors met 16th of November at the last IETF. we collectively went through the complete feature list. the result is what you find in the MAP document series. Remi, who was also at that meeting, later came up with a different solution and new features and decided to create a competing proposal. MAP is largely original 4rd and dIVI, considering its roots. there has been a continuing exchange of ideas and improvement of the proposals. Remi's latest 4rd-U proposal largely represents all the functions that there was no support for in the MAP design team. I do not think attempting yet another merger will be a good use of our time. P.S. When I say MAP, I mean all 3 drafts (T/M/A+P). I see them one complete series. yes, that makes sense. OK, what if we try this: MAP is a unified solution consisting of two transport modes (T/E), a provisioning (DHCP) and a deployment document. then we can pick between MAP and 4rd-U. the winner gets published on standards track. the looser gets documented as informational for the purpose of historical reference. cheers, Ole ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Path to move forward with 4rd…
Alain, et al, we have been at an impasse, so thank you very much for proposing a path forward. 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. I do agree with that. the Venn diagram for the three solutions would look awfully similar to a single circle. ;-) there are some use cases though, that can only be fulfilled with one mode of transport versus the other. I left the interim meeting in Beijing having been convinced that there are use cases requiring both encapsulation and requiring translation. if we for a moment accept that, I would suggest that we treat MAP as one single solution. it will have two options/flavours of transport. 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. with the above proposal, we can drop question 3. 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. can ask the chairs to take a hum of how many would want t-shirts for the meeting with: Just pick one for F's sake and stop arguing. ;-) cheers, Ole ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Fragmentation in sdnat-02
Le 2012-03-23 à 10:16, mohamed.boucad...@orange.com a écrit : 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. In this context, the important consideration is AFAIK that it is completely acceptable to lose fragmented packets that, with bad luck, happen to be routed via distinct BRs when there is a route change. Frequent route changes would have many more severe consequences than this one if considered normal. Do we agree on this? Cheers, RD 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
Hi Penno, MAP-T was derived from dIVI and dIVI-PD, which has been running at CERNET2 for two years and have been tested at China Telcom both in Beijing and Hunan last year. In addition, the dIVI-PD was demonstrated successfully in Softwire Interim Meeting in Beijing last September. BTW, the MAP-T code will be available soon. Congxiao 2012/3/23 Reinaldo Penno repe...@cisco.com Is there experimental data for MAP running on production networks? Certainly that is an important point to consider. On 3/22/12 11:06 PM, Zhang Huanjie ja...@ustc.edu.cn wrote: 4rd-U is in the very early design stage, there is no running code. In addition, it tries to modify the IPv6 address architecture. We need to see the experimental data before making any decision. -- Zhang Huanjie E-mail/msn: ja...@ustc.edu.cn ___ 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] Path to move forward with 4rd
I have been running single translation (IVI) for one year and have tested divi in the same environment by cascading second translator successfully. -- Zhang Huanjie E-mail/msn: ja...@ustc.edu.cn -Original E-mail- From: Reinaldo Penno repe...@cisco.com Sent Time: 2012-3-23 14:33:00 To: Zhang Huanjie ja...@ustc.edu.cn, Softwires WG softwires@ietf.org Cc: Subject: Re: [Softwires] Path to move forward with 4rd Is there experimental data for MAP running on production networks? Certainly that is an important point to consider. On 3/22/12 11:06 PM, Zhang Huanjie ja...@ustc.edu.cn wrote: 4rd-U is in the very early design stage, there is no running code. In addition, it tries to modify the IPv6 address architecture. We need to see the experimental data before making any decision. -- Zhang Huanjie E-mail/msn: ja...@ustc.edu.cn ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires -- 张焕杰 E-mail/msn: ja...@ustc.edu.cn 安徽省合肥市金寨路96号 中国科学技术大学网络信息中心 (230026) Mobile: +86-13505693311 Tel: +86-551-3601897 ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Path to move forward with 4rd…
Le 2012-03-22 à 13:26, Guanghui Yu a écrit : Hi all This mail raises a very important issue. MAP-T and MAP-E are not competing technologies. They have different user scenarios. I read 4rd-u draft and found it is flawed. Please explain what, in your understanding, would be flawed. I will not support the adoption of 4rd-u, since there is no running code and there is no experimental evaluation. The theory of Reversible header mapping is so simple that, AFAIK, nobody with implementation experience would negate that it will work when tested. Other features of the U proposal may be debated, but they are not necessary to replace T and E by a solution that is suitable for use cases of these two. In summary, 4rd-U is not in the same level of MAP series Would you claim that there are no inconsistencies today in the MAP set of drafts? Actually, the U draft is more complete and self consistent than the set of MAP documents. Regard, RD and it should not be considered for adoption in coming Paris IETF meeting. PS: I'am sorry if this mail sends more than one time, the mail system of our university may have problems with this mail list today. Yu Guanghui ygh at dlut.edu.cn Network and Information Center Dalian University of Technology, China Tel: +86 411 84708117 在 2012-3-21，下午9:39， Xing Li 写道： Hi, Alain, Yong and Ralph, The newly posted agenda does not match the consensus as you mentioned on 6 Oct 2011, that “multiple address and port mapping technologies could and should converge” and you formally announced “the creation of the MAP (Mapping of Addresses and Ports) design team”, a design team which “is tasked to formulate a unified format to be used either in an encapsulation or double translation mode” (http://www.ietf.org/mail-archive/web/softwires/current/msg03024.html). For the past few months, the design team has produced a series of MAP documents, including MAP, MAP-E, MAP-T, MAP-dhcp, etc. The mailing-list has also showed positive feedback on the adoption of the MAP series as the standard track of working group documents. Moreover, the dIVI (an earlier version of MAP-T) has been running successfuly at CERNET2 for two years now. 4rd-U was submitted later, and the goal is to replace the MAP Series. There have been discussions in the mailing list, but the discussions are mainly questions concerning the 4rd-U proposal. Actually, 4rd-U is still in the early design stage. Due to its proposed modification of the IPv6 architecture (V-Oct and the fragmentation header), the discussion should be extended at least to 6man WG before the Softwire WG makes any decision of adoption. Furthermore, experimental data should be presented to the WG to show that these modifications are not harmful. In addition, the fragmentation header modifications actually only deal with a very corner case of double translation (10e-5% of the packets, not production traffic). Therefore, I don’t think we have any reason to change the procedure and in the coming meeting, we should discuss whether consensus can be reached for the adoption of the MAP series. We should discuss whether 4rd-U can be adopted in a later meeting when it gets proved by 6man and its modifications are proved to be not harmful by experimental data. Regards, xing 于 2012/3/20 7:38, Alain Durand 写道: 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
Re: [Softwires] Path to move forward with 4rd
Hi, On 23 March 2012 13:10, Reinaldo Penno repe...@cisco.com wrote: Thank you. I believe the answer to my question is 'no'. divi and divi-pd and MAP-T are essentially the same, algorithmically, ie with the MAP algorithm and certain paramaters set (eg M=1) they are the same. The difference of on-the-wire encoding would not appear to have any tangible effect on experimental data collected for divi. Eg http://tools.ietf.org/html/draft-sunq-v6ops-ivi-sp-02 -Woj. Still, it is good to see that you are planning to deploy MAP-T. It is certainly an important data point. Do you plan to substitute dIVI and dIVI-PD by MAP-T or run them in parallel? From: Congxiao Bao cx.cer...@gmail.com Date: Fri, 23 Mar 2012 18:04:47 +0800 To: Cisco Employee repe...@cisco.com Cc: Zhang Huanjie ja...@ustc.edu.cn, Softwires WG softwires@ietf.org Subject: Re: [Softwires] Path to move forward with 4rd Hi Penno, MAP-T was derived from dIVI and dIVI-PD, which has been running at CERNET2 for two years and have been tested at China Telcom both in Beijing and Hunan last year. In addition, the dIVI-PD was demonstrated successfully in Softwire Interim Meeting in Beijing last September. BTW, the MAP-T code will be available soon. Congxiao 2012/3/23 Reinaldo Penno repe...@cisco.com Is there experimental data for MAP running on production networks? Certainly that is an important point to consider. On 3/22/12 11:06 PM, Zhang Huanjie ja...@ustc.edu.cn wrote: 4rd-U is in the very early design stage, there is no running code. In addition, it tries to modify the IPv6 address architecture. We need to see the experimental data before making any decision. -- Zhang Huanjie E-mail/msn: ja...@ustc.edu.cn ___ 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
From: Wojciech Dec wdec.i...@gmail.com Date: Fri, 23 Mar 2012 13:26:48 +0100 To: Cisco Employee repe...@cisco.com Cc: Congxiao Bao cx.cer...@gmail.com, Softwires WG softwires@ietf.org Subject: Re: [Softwires] Path to move forward with 4rd Hi, On 23 March 2012 13:10, Reinaldo Penno repe...@cisco.com wrote: Thank you. I believe the answer to my question is 'no'. divi and divi-pd and MAP-T are essentially the same, algorithmically, ie with the MAP algorithm and certain paramaters set (eg M=1) they are the same. The difference of on-the-wire encoding would not appear to have any tangible effect on experimental data collected for divi. [RP] Interesting, thanks for the clarification. Can dIVI and MAP-T hosts/CPEs interoperate given they are essentially the same? Eg http://tools.ietf.org/html/draft-sunq-v6ops-ivi-sp-02 [RP] I will read it and provide feedback. Thanks for the pointer. -Woj. Still, it is good to see that you are planning to deploy MAP-T. It is certainly an important data point. Do you plan to substitute dIVI and dIVI-PD by MAP-T or run them in parallel? From: Congxiao Bao cx.cer...@gmail.com Date: Fri, 23 Mar 2012 18:04:47 +0800 To: Cisco Employee repe...@cisco.com Cc: Zhang Huanjie ja...@ustc.edu.cn, Softwires WG softwires@ietf.org Subject: Re: [Softwires] Path to move forward with 4rd Hi Penno, MAP-T was derived from dIVI and dIVI-PD, which has been running at CERNET2 for two years and have been tested at China Telcom both in Beijing and Hunan last year. In addition, the dIVI-PD was demonstrated successfully in Softwire Interim Meeting in Beijing last September. BTW, the MAP-T code will be available soon. Congxiao 2012/3/23 Reinaldo Penno repe...@cisco.com Is there experimental data for MAP running on production networks? Certainly that is an important point to consider. On 3/22/12 11:06 PM, Zhang Huanjie ja...@ustc.edu.cn wrote: 4rd-U is in the very early design stage, there is no running code. In addition, it tries to modify the IPv6 address architecture. We need to see the experimental data before making any decision. -- Zhang Huanjie E-mail/msn: ja...@ustc.edu.cn ___ 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] MAP and 4rd - Relationship with Single translation
On 19 March 2012 14:22, Rémi Després despres.r...@laposte.net wrote: Hi, Xing, I look forward to face to face discussions in Paris if we don't clarify everything before that (I will be busy on something else in the next 3 days). Le 2012-03-18 à 23:39, Xing Li a écrit : ... A key point is that 4rd doesn't prevent a 4rd-capable dual-stack CE node, when it receives no 4rd mapping rule, to exercise single translation. Actually, I believe that using for this the BIH of RFC6535 is both sufficient and recommendable. Translated IPv4 packets, because they are sent from CE nodes to DNS64 synthesized addresses, are appropriately routed to their destinations. (It can be via the NAT64-CGN if needed, or via more direct paths if possible.) Anything missed? Sorry, this is a misunderstanding. Hint: Single translation and double translation are based on the same mapping rule in the CERNET2 deployment. I am well aware of this, but this doesn't explain why 4rd mapping rules similar to those of CERNET2 wouldn't have, like MAP-T, IPv4 to IPv6 communication (single translation) supported. As said in RFC6219, CERNET hosts have their IPv6 addresses configured via manual configuration or stateful autoconfiguration via DHCPv6. Hosts can therefore be assigned Interface IDs that have the 4rd-u format (with V octet and CNP). Now, when both addresses happen to be checksum neutral, RFC6145 translation doesn't modify L4 data, so that it doesn't matter whether the DS node has used 4rd-u header mapping or single translation. Thus, IPv6-only hosts can exchange packets with IPv4 applications of 4rd CE nodes. If those packets are UDP checksum 0, the IPv6 host would either need to be customized, or something else would need to changed/configured on the 4rd-u CE specifically to get that to work for specific IPv6 destinations, while with MAP-t this would be transparent (and not require specific forwarding rules). -Woj. Regards, RD Regards, xing Regards, RD Regards, xing Regards, RD Le 2012-02-10 à 04:28, Xing Li a écrit : ... | | | | | | 5 | IPv6 web caches work for IPv4| Y | N | Y | N | || packets | | | | | suggest you rename to IPv4 to IPv6 communication (single translation) supported (2) More clarification should be added here. I am not sure 4rd-H can support single translation. (a) According to (1), 4rd-H does not perform header translation defined by RFC6145. (b) In the softwire mailing list, it seems that 4rd-H cannot support single translation. See the thread containing http://www.ietf.org/mail-archive/web/softwires/current/msg03324.html and other posts. (c) If 4rd-H cannot support single translation, then IPv6 web caches work for IPv4 packets requires special configurations, it cannot do IPv6 web caches for non 4rd-H packets. ... (5) I would like to see the details of how 4rd-H handles ICMP and ICMP error messages. In the softwire mailing list there were some discussions. See the thread containing http://www.ietf.org/mail-archive/web/softwires/current/msg03324.html and other posts. Please add | 17 | Handle ICMP (RFC6145) | Y | n/a | ? | ? | ... ___ 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
On 23 March 2012 13:40, Reinaldo Penno repe...@cisco.com wrote: From: Wojciech Dec wdec.i...@gmail.com Date: Fri, 23 Mar 2012 13:26:48 +0100 To: Cisco Employee repe...@cisco.com Cc: Congxiao Bao cx.cer...@gmail.com, Softwires WG softwires@ietf.org Subject: Re: [Softwires] Path to move forward with 4rd Hi, On 23 March 2012 13:10, Reinaldo Penno repe...@cisco.com wrote: Thank you. I believe the answer to my question is 'no'. divi and divi-pd and MAP-T are essentially the same, algorithmically, ie with the MAP algorithm and certain paramaters set (eg M=1) they are the same. The difference of on-the-wire encoding would not appear to have any tangible effect on experimental data collected for divi. [RP] Interesting, thanks for the clarification. Can dIVI and MAP-T hosts/CPEs interoperate given they are essentially the same? Well, MAP-T and divi-pd in non-address-sharing mode (ie 1:1) should be totally compatible. However, given that the on-the-wire encoding of the PSID is different in the address sharing mode, interoperability in that mode won't be there. Cheers, Woj. Eg http://tools.ietf.org/html/draft-sunq-v6ops-ivi-sp-02 [RP] I will read it and provide feedback. Thanks for the pointer. -Woj. Still, it is good to see that you are planning to deploy MAP-T. It is certainly an important data point. Do you plan to substitute dIVI and dIVI-PD by MAP-T or run them in parallel? From: Congxiao Bao cx.cer...@gmail.com Date: Fri, 23 Mar 2012 18:04:47 +0800 To: Cisco Employee repe...@cisco.com Cc: Zhang Huanjie ja...@ustc.edu.cn, Softwires WG softwires@ietf.org Subject: Re: [Softwires] Path to move forward with 4rd Hi Penno, MAP-T was derived from dIVI and dIVI-PD, which has been running at CERNET2 for two years and have been tested at China Telcom both in Beijing and Hunan last year. In addition, the dIVI-PD was demonstrated successfully in Softwire Interim Meeting in Beijing last September. BTW, the MAP-T code will be available soon. Congxiao 2012/3/23 Reinaldo Penno repe...@cisco.com Is there experimental data for MAP running on production networks? Certainly that is an important point to consider. On 3/22/12 11:06 PM, Zhang Huanjie ja...@ustc.edu.cn wrote: 4rd-U is in the very early design stage, there is no running code. In addition, it tries to modify the IPv6 address architecture. We need to see the experimental data before making any decision. -- Zhang Huanjie E-mail/msn: ja...@ustc.edu.cn ___ 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.
Le 2012-03-23 à 11:13, mohamed.boucad...@orange.com mohamed.boucad...@orange.com a écrit : 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. Note that -04 and -05 are significantly improved. Expertise of its now co-authors include broadband and mobile services as ell as product vendors. AFAIK, no reason why it wouldn't work, or do less than claimed, remained unanswered. If later on a flaw or uncertainty is identified, and confirmed after discussion, this will be fairly acknowledged. 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: This may be taken as I don't care how many designs are standardized... provided my use case is covered by one of them. This is not AFAIK the best approach to simplify standards we make for the future. The chair encouraged further work on U after IETF 82 after arguments used to exclude it in Taipei were acknowledged to be invalid. Excluding to discuss U although it provides a unified design, with more operational features than either T or E, seems to me difficult to justify. Regards, RD 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
Re: [Softwires] Fragmentation in sdnat-02
Hi, Washam, Le 2012-03-23 à 03:08, Washam Fan a écrit : There is no text saying 4rd-u BRs are anycasted to IPv4 network in the first place. Remi, could you clarify on this? Thanks, washam Not sure to understand the question. IPv4 routing toward BRs is based on IPv4 prefixes (which are anycast by nature). RD ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] [Softwire] Algorithmic feature for SD-NAT
On Mar 23, 2012, at 4:22 AM, Qiong wrote: Dear Alain and all, I'm trying to understand sd-nat-02 and I'm still wondering how to setup subscriber-based binding table in sd-nat. In my understanding, a totally static binding table will introduce a lot of workload for operators. Not necessarily. Operators maintain large database for customers, this is just one more field there. The real question is how to propagate this static table to the AFTRs. This is implementation specific, but our proposed solution is to use netconf. But otherwise, I guess there might be an algorithmic relationship between IPv6 and IPv4 + port range. In this way, would it become some kind of MAP, in which IPv4 address and IPv6 address is tightly coupled and need to be planned in advance ? This can be done too, but you loose the most important advantage of SD-Nat: the absence of hard coupling between the IPv4 and IPv6 address. Not coupling both addresses enables great flexibility on how you allocate addresses and port. I'm just wondering why do we still need to maintain per-subscriber table in AFTR while still keeping stateless. Please correct me if I miss something here : SD-Nat is per-flow stateless, with a per-subscriber static state. - Alain. ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Path to move forward with 4rdŠ
Hi Guanghui, Just curious, how common IPv4 option is used these days? I don't have any data in-hand. Thanks, Yiu From: Guanghui Yu yu.guang...@gmail.com Date: Fri, 23 Mar 2012 13:43:07 +0800 To: Yiu L. LEE yiu_...@cable.comcast.com Cc: Softwires WG softwires@ietf.org Subject: Re: [Softwires] Path to move forward with 4rdŠ it cannot support IPv4 option. smime.p7s Description: S/MIME cryptographic signature ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Path to move forward with 4rdŠ
Hi Guanghui, Is the original use case for MAP is to deliver v4 over v6 in a stateless fashion in the network? This is stated in the stateless-requirements draft. If we can get v4-v6 (single translation) for free, I am all for it. But this isn't the original requirements we are trying to solve. Right? Thanks, Yiu From: Guanghui Yu yu.guang...@gmail.com Date: Fri, 23 Mar 2012 13:43:07 +0800 To: Yiu L. LEE yiu_...@cable.comcast.com Cc: Softwires WG softwires@ietf.org Subject: Re: [Softwires] Path to move forward with 4rdŠ 4rd-U cannot replace MAP-T, since it cannot support single translation. smime.p7s Description: S/MIME cryptographic signature ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Path to move forward with 4rd…
Le 2012-03-22 à 15:40, Maoke a écrit : dear Alain, Yong, Ralph and all, in program, the effort of the MAP team should be respected. The formation of the MAP team was also the consensus of our meeting in beijing and we have seen the the team is working with clear progress. I don't think it is correct now to insert 4rd-u into a sort of exclusive decision of choice. And 4rd-u also has the address format elements abondoned by the MAP design team. I believe the MAP format reflects that the common understanding concludes the insignificance of those features. Sorry but the chair's questions a little confused me: if we need to go back to the stage before the works of the MAP design team? The MAP series have reached running codes and the collective understanding of the community. Here are some issues among those remaining before reaching collective understanding: a) T operation in hubspoke (hasn't been so far answered in an understandable way). b) IDs from shared-address CEs. T currently has so far no solution while both U and E include one. c) MAP-A+P says Each MAP node in the domain has the same set of rules while MAP-T says if a CE knows only a subset of the mapping rules ... d) Whether T can work with a single mapping rule (as was, I think, the case for IVI). So far DMR and BMR seem exclusive, and there is no way to distinguish them in MAP-dhcp. The fact that no-one involved in the MAP design raised any of these issues is AFAIK sign that MAP has NOT reached collective understanding of the community. (Note that, concerning stateless v4/v6 solutions, I think I should be considered part of this community. Right? ). Maoke, clarifications on these points will be welcome. From a view of a middle-sized ISP and cloud service provider, we do support to accept MAP series into standard track in order we can utilize it into business as soon as possible. in technology, first of all, MAP now has approached address mapping algorithm and that enough to make the series a unified solution. In our practice, we need to use either encapsulation or translation according to the actual needs and environment. Note: This excludes ISPs that would like to offer full IPv4 transparency with some IPv6-only middles boxes. Right? The most important is, both the building blocks of transition architecture: virtual link (supported by encapsulation/tunneling) and participant of the delivery path (supported by translation), have their suitable use cases. And their advantages and limitations have been well investigated and understood by the community. second, i deeply discussed and explored 4rd-u, but i found its attempting of mixing the tunneling and translation, if accepted as standard, may trap the operators into a harsh situation of being unable to define what building block it really is. Such an operator would know it uses 4rd-U. This doesn't seem to justify any FUD from co-authors from broadband and mobile operators (or from product vendors). It is stated as tunneling but actually behaves like tunnel in some aspects while like translation in some other aspects. Yes indeed, thus achieving the best of both worlds without making it more complex. Actually making it clearly less complex than supporting both T and E. (I have pointed out in the 4rd-u discussion thread). We see it only a yet-another-translation that try to solve some corner problems but introduces new, possibly major flaws (also pointed out in the technical threads on 4rd.) Possibly major flaws isn't an identified point on which U would do less than what it has been designed to do (unified replacement of T + E). IMPORTANT: - The essential characterization of U (vs T and E) is its Reversible header mapping (as replacement of both Double RFC6145 translation and Encapsulation). - Other features of U that differ from MAP (V-octet, CNP), or are complementary to it (Rule IPv6 suffix, NAT64+), are secondary in this respect. Each of these features could be abandoned in U, or, if the WG appreciates what they offer, added to MAP. - For this, community acceptance to listen to explanations, would be the normal process. I will be available this week for this. Cheers, RD In either the term of architectural philosophy or technical details, introducing 4rd-u into standards would be harmful. personally, i respect the exploration of the author(s), and the discussion between me and the author encouraged me to comprehensively review E and T, and the result is: i bacame much more confident of the correctness of the MAP track. We should move forward. regarding the chair's questions, my answer is: MAP, MAP-E/T, MAP-DHCP are of a whole suite needing to be put into standard track. Question is not about T, E or U. best regards, Maoke 在 2012年3月20日星期二，Alain Durand 写道： Dear wg, After a number of discussions with my co-chair, our AD and various authors, here is how
Re: [Softwires] Path to move forward with 4rdŠ
Hi, Guanghui, Le 2012-03-23 à 04:04, Guanghui Yu a écrit : Hi Yiu 4rd-u changes the IPv6 header architecture (redefine fragmentation header extension) 4rd-U uses between CEs and BRs an IPv6 packet format that not only is completely authorized, but that is already used in double translation: RFC6145 also adds a fragmentation header to some unfragmented packets (sec 4.). and IPv6 address architecture (different meaning of u-bit when g-bit=1). - U builds on the fact that all IPv6 unicast addresses are so far either universal scope (u=1 g=0) or local link scope (u=0 g=any value). This (fortunately) leaves an escape combination for new types of addresses (U is only one of these possible addresses, but the first one). - A 4rd-U address happens to be partially universal scope (embedded public IPv4 addresses) and partially ISP-domain scope (dependent on ISP defined mapping rules). None of the existing formats is therefore mandatorily applicable. - Impact on IPv6 address architecture is only a backward compatible extension: no interference is possible with anything that works in conformance with current IPv6 specifications. These are the fundamental changes. If 4rd-u becomes the standard, then there will be new defined “IPv6” packets on the Internet, which are not compatible with existing IPv6 packets and Please see above. no existing devices can understand those packets. Only BRs and CEs need to understand that these packets have IPv4 compatible payloads. Regards, RD Yu Guanghui ygh at dlut.edu.cn Network and Information Center Dalian University of Technology, China On Fri, Mar 23, 2012 at 10:10 AM, Lee, Yiu yiu_...@cable.comcast.com wrote: Hi Guanghui, I agree that both MAP and 4rd-u are similar technology and solving the same problem. From technical perspective, can you elaborate this a lithe bit? Thanks, Yiu From: Guanghui Yu yu.guang...@gmail.com Date: Thu, 22 Mar 2012 20:26:40 +0800 To: Softwires WG softwires@ietf.org Subject: Re: [Softwires] Path to move forward with 4rd… I read 4rd-u draft and found it is flawed. ___ 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-dslite-multicast-01.txt
Good feed back. We started to address dslite and like what you said this could be more generic then just dslite. I will talk to the authors and see what we should do. Thanks again! On 3/23/12 1:02 PM, Stig Venaas s...@venaas.com wrote: On 3/22/2012 7:29 PM, Lee, Yiu wrote: Hi Stig, DS-Lite was designed to deliver v4 unicast packets over v6-only network to v4 host. However when we started thinking about how to deliver multicast packets in the same network setup, we will have to tunnel all multicast packets over tunnels. This is very inefficient to use of AFTR. This is the motivation of dslite-multicast draft. However, you are absolutely right. This is a solution for tunneling IPv4 multicast through an IPv6-only network. I agree that double tunneling is a non-starter, so the draft seems to do the right thing. But since we seem to agree it is a more general solution, why not change the title and the text to make it more generic? You can still say that one of the use-cases is to provide IPv4 multicast for DS-Lite deployments. Stig B.R., Yiu On 3/20/12 4:47 PM, Stig Venaass...@venaas.com wrote: I'm a little bit puzzled by how this document talks about DS-Lite. Isn't this an entirely generic solution for tunneling IPv4 multicast through an IPv6-only network? Stig ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires smime.p7s Description: S/MIME cryptographic signature ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] [Softwire] Algorithmic feature for SD-NAT
Hi Alain, Quick question. What snag suggests to keep in the customer database? Port range info? Thanks, Yiu On 3/23/12 10:06 AM, Alain Durand adur...@juniper.net wrote: Not necessarily. Operators maintain large database for customers, this is just one more field there. The real question is how to propagate this static table to the AFTRs. This is implementation specific, but our proposed solution is to use netconf. smime.p7s Description: S/MIME cryptographic signature ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Path to move forward with 4rd
Hi Wjociech, So the only different between MAP-T and dIVI-PD is the new PSID calculation in MAP. Otherwise, they are identical. Thanks, Yiu From: Wojciech Dec wdec.i...@gmail.com Date: Fri, 23 Mar 2012 14:01:59 +0100 To: Reinaldo Penno repe...@cisco.com Cc: Softwires WG softwires@ietf.org Subject: Re: [Softwires] Path to move forward with 4rd Well, MAP-T and divi-pd in non-address-sharing mode (ie 1:1) should be totally compatible. However, given that the on-the-wire encoding of the PSID is different in the address sharing mode, interoperability in that mode won't be there. Cheers, Woj. smime.p7s Description: S/MIME cryptographic signature ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Path to move forward with 4rdŠ
Hi Ole, Technically, I think it now comes down to one question to debate between MAP-T and 4rd-u. Btw reservable header and double-translation, what technology better serves the requirements. Do you agree? Thanks, Yiu On 3/23/12 5:28 AM, Ole Trøan otr...@employees.org wrote: Remi, who was also at that meeting, later came up with a different solution and new features and decided to create a competing proposal. MAP is largely original 4rd and dIVI, considering its roots. there has been a continuing exchange of ideas and improvement of the proposals. Remi's latest 4rd-U proposal largely represents all the functions that there was no support for in the MAP design team. I do not think attempting yet another merger will be a good use of our time. smime.p7s Description: S/MIME cryptographic signature ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
