Re: [Softwires] Fragmentation in sdnat-02
Dear Gang, Thanks, but I failed to find the text describing how to handle two fragments received by two distinct BRs. Could you please point me to that text in case I miss it? Cheers, Med -Message d'origine- De : GangChen [mailto:phdg...@gmail.com] Envoyé : jeudi 22 mars 2012 08:33 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : Washam Fan; Softwires Objet : Re: [Softwires] Fragmentation in sdnat-02 2012/3/21, mohamed.boucad...@orange.com mohamed.boucad...@orange.com: Dear Washam, This is an issue common to all stateless solutions, including deterministic NAT with (anaycast) IPv4 address pool. FWIW, we recorded this issue here: http://tools.ietf.org/html/draft-dec-stateless-4v6-04#section-5.15.2. As a solution to this issue, we proposed to implement the fragmentation-related function in one single node: any received fragment is redirected to a dedicated node which will be responsible for reassembly or forward the fragment to the appropriate CPE. This node must dedicate resources to handle out of order fragments. FYI, I see another approach doing that with a entry table + redirection action, similarly like http://tools.ietf.org/html/draft-despres-softwire-4rd-u-05#sect ion-4.5.2. BRs Gang Saying that, I can not quantify the severity of this issue in all operational networks. Cheers, Med -Message d'origine- De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la part de Washam Fan Envoyé : mercredi 21 mars 2012 07:25 À : Softwires Objet : [Softwires] Fragmentation in sdnat-02 Hi Authors, In section 3.2, it states IPv4 address pool should be anycasted. This introduces a risk where different incoming fragments go to different AFTRs. Because one IPv4 address is shared between multiple subscribers, reassemly is needed on AFTRs when receiving fragments. If different fragments go thru different AFTRs, the reassmely process would fail and incur DoS. Thanks, washam ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Fragmentation in sdnat-02
Dear Med, Yes. There are no texts targeting to this topics. I mean we could leverage the consideration in 4rd-U to build a entry table. One more REDIRECTION action obviously should be added to the row of RESULTING ACTIONS. Any received fragment looking for conditions and execute a proper action(forwarding or redirection) BRs Gang 2012/3/22, mohamed.boucad...@orange.com mohamed.boucad...@orange.com: Dear Gang, Thanks, but I failed to find the text describing how to handle two fragments received by two distinct BRs. Could you please point me to that text in case I miss it? Cheers, Med -Message d'origine- De : GangChen [mailto:phdg...@gmail.com] Envoyé : jeudi 22 mars 2012 08:33 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : Washam Fan; Softwires Objet : Re: [Softwires] Fragmentation in sdnat-02 2012/3/21, mohamed.boucad...@orange.com mohamed.boucad...@orange.com: Dear Washam, This is an issue common to all stateless solutions, including deterministic NAT with (anaycast) IPv4 address pool. FWIW, we recorded this issue here: http://tools.ietf.org/html/draft-dec-stateless-4v6-04#section-5.15.2. As a solution to this issue, we proposed to implement the fragmentation-related function in one single node: any received fragment is redirected to a dedicated node which will be responsible for reassembly or forward the fragment to the appropriate CPE. This node must dedicate resources to handle out of order fragments. FYI, I see another approach doing that with a entry table + redirection action, similarly like http://tools.ietf.org/html/draft-despres-softwire-4rd-u-05#sect ion-4.5.2. BRs Gang Saying that, I can not quantify the severity of this issue in all operational networks. Cheers, Med -Message d'origine- De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la part de Washam Fan Envoyé : mercredi 21 mars 2012 07:25 À : Softwires Objet : [Softwires] Fragmentation in sdnat-02 Hi Authors, In section 3.2, it states IPv4 address pool should be anycasted. This introduces a risk where different incoming fragments go to different AFTRs. Because one IPv4 address is shared between multiple subscribers, reassemly is needed on AFTRs when receiving fragments. If different fragments go thru different AFTRs, the reassmely process would fail and incur DoS. Thanks, washam ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Path to move forward with 4rd…
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. I will not support the adoption of 4rd-u, since there is no running code and there is no experimental evaluation. In summary, 4rd-U is not in the same level of MAP series 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 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
Re: [Softwires] Path to move forward with 4rd…
Hello Chairs, all In essence, while at a very high level all solutions appear to solve a common problem, just like all ducks look the same, some solve extra problems that are of critical importance to some operators, this forms the basis for the different approaches, and what led to the MAP draft set, and in that set there is no way to sqaure the circle The hybrid solution also does not square the circle, and what more raises several technical questions, besides lacking the trial implementation experience factor that MAP's constituents have shown - it thus appears to be in a different, rather experimental, league . Respectfully thus, the view presented under item 1) below and ultimately the questions appear set to cause further thrashing of arguments all over again. All this going a long way off from actually progressing the development of solutions that solve problems the WG cares about and under majority consensus if universal consensus is not possible. As a way forward I would suggest a much simpler approach that is more likely to result in some progress, with the following questions being asked: 1. Should MAP (all MAP drafts) be adopted as WG drafts all on Informational track? 2. Should 4rd-u as WG draft on the Experimental or Informational track, if shown to be in line with existing specs. Along with an acceptance of any/all of the above, there should be a charter clause indicating that one, or all of these drafts can be moved to a Standards track following WG consensus, without altering the status of the others, unless similarly consented. Regards, Wojciech. On 20 March 2012 00:38, Alain Durand adur...@juniper.net wrote: 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…
On 3/20/12 12:38 AM, Alain Durand wrote: 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. Hi, I'm not really happy with this decision. RFC 6346 Stateless A+P (a.k.a. 4rd/MAP) world is polarized in encapsulation and translation part. MAP-U is brave attempt to unify both worlds, but I;m not sure all the best parts from both world ended up in -U proposal and that result is what I would like to see in reality. Coming from operational ISP world, where this stuff will actually be implemented in reality, I would suggest to publish -E and -T as documents in standards track - and -U as experimental or informational. What I would like to see as network architect is that vendors deploys -E and -T in the same product named 4RD and operator can choose operating mode when implementing the solution - deciding between encapsulation or translation at will. This way this working group work and effort would become useful for operations. Cheers and see you in few days, Jan Zorz Go6 Institute Slovenia ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Path to move forward with 4rd…
+1, support Best regards -- Name:Zhankao WEN(温占考) Email: w...@synet.edu.cn w...@mail.neu.edu.cn TelFax: +86-24-83687240 Address: Networking Center Northeastern University Shenyang Liaoning Province P.R. China (110819) - Original Message - From: Xing Li x...@cernet.edu.cn To: Alain Durand adur...@juniper.net Cc: Softwires WG softwires@ietf.org, Yong Cui cuiy...@tsinghua.edu.cn, Ralph Droms rdr...@cisco.com Sent: Wednesday, 21 March, 2012 9:39:07 PM Subject: Re: [Softwires] Path to move forward with 4rd… 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 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
Re: [Softwires] Path to move forward with 4rd
I am disappointed with this approach. Despite the support, the WG adoption of MAP documents has been delayed for a label reason. I find it unfair since the label can be changed any time until the IESG review. How can it be a hold-up? One would have to wonder the intent of forming the design team at first place. It seems that we keep putting roadblocks on the path for the stateless solutions to get standardized. One after another. What's the purpose? It seems that the work done by the design team, which was formed for a reason, is being ignored. If not, then their documents would have been the WG documents by now and the email would be referring to MAP (and not 4rd). This is a bit disrespectful. I would suggest to put all the documents developed by the MAP design team as Standards track document, and anything else is up for discussion. Cheers, Rajiv -Original Message- From: Alain Durand adur...@juniper.net Date: Mon, 19 Mar 2012 16:38:42 -0700 To: Softwires WG softwires@ietf.org Cc: Yong Cui cuiy...@tsinghua.edu.cn, Ralph Droms rdr...@cisco.com Subject: [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] MAP and 4rd - Relationship with Single translation
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. 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] Path to move forward with 4rdŠ
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. smime.p7s Description: S/MIME cryptographic signature ___ 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
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. B.R., Yiu On 3/20/12 4:47 PM, Stig Venaas s...@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] I-D Action: draft-ietf-softwire-dslite-multicast-01.txt
One more note. When we developed this draft, we focused on access network delivery. There is a mesh-multicast draft which also solve the same problem (i.e. Tunneling v4 mcast through v6-only network) in the core network. On 3/22/12 10:29 PM, Lee, Yiu yiu_...@cable.comcast.com 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. B.R., Yiu On 3/20/12 4:47 PM, Stig Venaas s...@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 ___ 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] 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. ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Path to move forward with 4rdŠ
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 http://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. 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 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. 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
