Re: [Softwires] Call for agenda items
Dear chairs, We would like to have a slot for (1) Draft name: http://tools.ietf.org/html/draft-boucadair-softwire-dslite-v6only-00 Time slot: 10 mins Presenter: Yiu Lee and for (2) Draft name: http://tools.ietf.org/html/draft-boucadair-softwire-cgn-bypass-03 Time slot: 10 mins Presenter: Christian Jacquenet Cheers, Med -Message d'origine- De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la part de Alain Durand Envoyé : vendredi 15 octobre 2010 01:32 À : Softwires list Objet : [Softwires] Call for agenda items This is a call for agenda items for the upcoming meeting in Beijing. Please send request directly the chairs. Alain David, co-chairs. ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires * This message and any attachments (the message) are confidential and intended solely for the addressees. Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration. France Telecom Group shall not be liable for the message if altered, changed or falsified. If you are not the intended addressee of this message, please cancel it immediately and inform the sender. ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Call for agenda items
Hi Alain, Hi David, Brian Carpenter, Sheng Jiang, and myself, request an agenda item on 6a44. Document: Native IPv6 Across NAT44 CPEs (6a44) tools.ietf.org/id/draft-despres-softwire-6a44-01 The plan is that I will be the presenter. Time requested: 30 minutes - The draft is the result of a convergence and improvement work of two independent previous drafts submitted to Softwire, and is related to a third one. - It contains substantial technical material. - Discussions on the list and off list show that it raises interests, and also substantial technical questions. Regards, RD Le 15 oct. 2010 à 01:31, Alain Durand a écrit : This is a call for agenda items for the upcoming meeting in Beijing. Please send request directly the chairs. Alain David, co-chairs. ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] [v4tov6transition] IPv6 VPNs configured over 1280 MTU tunnels
Hi Brian, -Original Message- From: v4tov6transition-boun...@ietf.org [mailto:v4tov6transition-boun...@ietf.org] On Behalf Of Brian E Carpenter Sent: Thursday, October 14, 2010 3:10 PM To: Templin, Fred L Cc: Softwires; v4tov6transit...@ietf.org Subject: Re: [v4tov6transition] IPv6 VPNs configured over 1280 MTU tunnels Fred, All of your assumptions are lowest-common-denominator. What else can an operator safely do but make such assumptions? They can roll up their sleeves and probe the paths to the clients. Thanks - Fred fred.l.temp...@boeing.com Regards Brian On 2010-10-15 02:08, Templin, Fred L wrote: Hi Washam, -Original Message- From: Washam Fan [mailto:washam@gmail.com] Sent: Thursday, October 14, 2010 5:50 AM To: Templin, Fred L Cc: Rémi Després; Softwires; v4tov6transit...@ietf.org Subject: Re: [v4tov6transition] IPv6 VPNs configured over 1280 MTU tunnels Hi Fred, Please see inline. I did have some different assumptions. And those assumptions might be wrong. It might be better at this stage we let the tunneled IPv6 MTU be 1280 and tunneling IPv4 MTU not less than 1308. All of your assumptions are lowest-common-denominator. All end user networks are made to suffer because of the few that are poorly configured. GigE is a current day reality, and MTUs much larger than the lowest common denominator should be made available to the end user networks that paid good money for them when possible. Fred fred.l.temp...@boeing.com 2010/10/13 Templin, Fred L fred.l.temp...@boeing.com: Hi Washam, -Original Message- From: Washam Fan [mailto:washam@gmail.com] Sent: Monday, October 11, 2010 10:48 PM To: Templin, Fred L Cc: Rémi Després; Softwires; v4tov6transit...@ietf.org Subject: Re: [v4tov6transition] IPv6 VPNs configured over 1280 MTU tunnels Hi Fred, I might see your points. Good. Let H represents Host, N represents NAT, S represents the 6a44 servers. PMTU(H,S) stands for the PMTU between H and S. HOME_MTU represents MTU within home LAN (i.e., unmanaged network), SP_MTU represents MTU within SP network(i.e., managed network). We assume both SP_MTU and SP_MTU should exceed or equal to 1308. This is an incomplete characterization. PMTU is not necessarily symmetric, e.g., even just within the end user it could be different in the H-N direction than in the N-H direction. Also, there could be multiple N's in the path; each imparting their own MTU uncertainties. I assume H-N-S PMTU can be probed, Ns in between should be capable of translating ICMPv4 messages appropriately. As you said, S-N-H can not be probed as Ss are stateless. if HOME_MTU=SP_MTU, PMTU(H,S)=SP_MTU, the H could configure SP_MTU-28 as the IPv6 virtual interface MTU. A couple of things here. First, you seem to be assuming a static S instead of a redundantly replicated S with anycast, where there may be many distinct paths with varing SP_MTUs to reach the multiple S's. I assume all Ss shared the same MTUs since they are located in managed networks. Or the MTU on their interfaces attaching SP networks can be configured with the least IPv4 MTU value. Second, how does H discover SP_MTU; by engaging in an initial probing by sending large packets and getting a PTB message back? I assume H can discover PMTU traversing Ns in between. Again, this won't give a deterministic SP_MTU value if S is replicated across paths with varying PMTUs. I assume all Ss configured with the same MTUs on their interfaces attaching to SP networks. H-S direction: if S received or trigger any ICMPv6 PTB messages, it can forward ICMPv6-in-UDP-in-IPv4 to H. You keep saying this, and I keep saying that you are right but that this has never been a matter for concern. PMTUD *beyond* the tunnel is not in question; it is only PMTUD *within* the tunnel that bears further discussion. S-H direction: S would reject any IPv6 packets exceeding SP_MTU-28 with ICMPv6 PTB. I don't see problems here. Huh? Is S supposed to cache the SP_MTU to each and every potential host H? I assume the goal is for a completely stateless S - right? I assume MTU is statically configured on Ss' interfaces attaching the SP networks. If HOME_MTUSP_MTU,PMTU(H,S)=HOME_MTU, the H could configure HOME_MTU-28 as IPv6 virtual interface MTU. So again, H could discover this only by sending probes? And again, any probing would be non-deterministic if S is an anycast (and not unicast) address. See above. Thanks, washam H-S direction: if S received or trigger any ICMPv6 PTB messages, it can forward ICMPv6-in-UDP-in-IPv4 to H. Yes, we have confirmed this several times now; not a point in question. I don't expect the size of the encapsulated packet is too much. Encapsulated PTB could be as big as 1280 + 20 + 8. S-H
[Softwires] I-D Action:draft-ietf-softwire-gateway-init-ds-lite-01.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Softwires Working Group of the IETF. Title : Gateway Initiated Dual-Stack Lite Deployment Author(s) : F. Brockners, et al. Filename: draft-ietf-softwire-gateway-init-ds-lite-01.txt Pages : 14 Date: 2010-10-15 Gateway-Initiated Dual-Stack lite (GI-DS-lite) is a variant of Dual- Stack lite (DS-lite) applicable to certain tunnel-based access architectures. GI-DS-lite extends existing access tunnels beyond the access gateway to an IPv4-IPv4 NAT using softwires with an embedded context identifier that uniquely identifies the end-system the tunneled packets belong to. The access gateway determines which portion of the traffic requires NAT using local policies and sends/ receives this portion to/from this softwire. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-softwire-gateway-init-ds-lite-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ftp://ftp.ietf.org/internet-drafts/draft-ietf-softwire-gateway-init-ds-lite-01.txt ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
[Softwires] Comment on draft-despres-softwire-6a44-01.txt
Hi Remi, The IPv6 host address is directly obtained by an indication message from the 6a44 server. Here is the format of the IPv6 address. +---+---+---+---+---+---+---+---+ | ISP 6a44 prefix (D) | Customer IPv4 |NAT ext| Host IPv4 | | | address (N) |port(Z) | address (A)| +---+---+---+---+---+---+---+---+ According to the draft, N:Z is the address and port used on the CPE NAT44's external side. _.---. Host / \ CPE / \ 6a44 Relay +--+ . IP .+-+ . IPv4. +---+IPv6 |6a44-C|--| no |--|NAT44|---| Provider |--O 6a44-S|-- network +--+ . NAT . +-+ . network . +---+ ^ ^ \ _ /^ \ / |^ | A |'---.---' || | A:W - N:Z || | | || | | || |- - - - - IPv6/UDP/IPv4 - - - - - - | | | | | D.N.Z.A (/128) - - - - - - - -IPv6 - - - - D (/48) Is the A:W-N:Z mapping created staticly? Or dynimicly?When the host reqests the IPv6 address to the 6a44 server, the server gives the host IPv6 address and liftime directly. If the mapping on the CPE is allocated dynamically, how does the lifetime of the allocated host IPv6 address will be set? I mean this lifetime should longer than the expire time of the mapping on the CPE. It is because if the mapping is deleted first and the host still uses the IPv6 address embeded N:Z. It will arise problem. For instance, the CPE may allocate another port, A:W-N:Y. Therefore, there may be two ways to solve this. a) set the lifetime of the allocated host IPv6 address shorter than the expire time of CPE NAT44. Thus, the host is able to re-request its IPv6 address within the NAT mapping expire time. b) require the CPE comply with endpoint-independent mapping in RFC4787,RFC5382. But for this behavior, the premise is the host re-send the address request message must use the same source address and port, A:W. Thus, the NAT can provide the same N:Z. I suppose this should be clarified in 6a44 draft, if I am correct and not missing someting. Thanks. 2010-10-15 Dong Zhang ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Call for agenda items
Dear Alain and David, We would like to ask for 10 minutes to present softwire mesh multicast transition. 1. Draft: we will publish before Oct. 18. 2. Time requested: 10 mins 3. Presenter: Mingwei Xu, Chris Metz Thanks, Mingwei - 发件人：Alain Durand 发送日期：2010-10-15 07:33:14 收件人：Softwires list 抄送： 主题：[Softwires] Call for agenda items This is a call for agenda items for the upcoming meeting in Beijing. Please send request directly the chairs. Alain David, co-chairs. ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires = = = = = = = = = = = = = = = = = = = = 致 礼！ Mingwei Xu ...@csnet1.cs.tsinghua.edu.cn 2010-10-15 ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Call for agenda items
Hi chairs, We would like to ask for a slot to discuss the following: - draft-lee-softwire-dslite-deployment-00 - 10 mins - Yiu Lee Regards, Yiu On 10/14/10 7:31 PM, Alain Durand adur...@juniper.net wrote: This is a call for agenda items for the upcoming meeting in Beijing. Please send request directly the chairs. Alain David, co-chairs. ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] Call for agenda items
Hi Alain and David, I would like to have a 20min slot to introduce IRON and to discuss SEAL and its implications for tunnel MTU determination. The drafts are here: http://www.ietf.org/internet-drafts/draft-templin-iron-13.txt http://www.ietf.org/internet-drafts/draft-templin-intarea-seal-21.txt Thanks - Fred fred.l.temp...@boeing.com -Original Message- From: softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] On Behalf Of Alain Durand Sent: Thursday, October 14, 2010 4:32 PM To: Softwires list Subject: [Softwires] Call for agenda items This is a call for agenda items for the upcoming meeting in Beijing. Please send request directly the chairs. Alain David, co-chairs. ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] DHCP option for DS-lite
On Fri, Oct 15, 2010 at 07:46:15AM +0200, mohamed.boucad...@orange-ftgroup.com wrote: This: o First of all, this document is the proprietary of the working group and should reflect the consensus of the working group not the opinions of the authors neither the chairs. is why this: o The comment from Jari is valid and the document should justify why two options are needed. This is even surprising because D. Hankins is also the author of http://tools.ietf.org/html/draft-ietf-dhc-option-guidelines since 2007. This is issue in not new for him. shouldn't surprise you. -- David W. HankinsIf you don't do it right the first time, Software Engineeryou'll just have to do it again. Internet Systems Consortium, Inc. -- Jack T. Hankins pgpCvBWOXK3cx.pgp Description: PGP signature ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] [v4tov6transition] Comment on draft-despres-softwire-6a44-01.txt
On 2010-10-16 15:15, Dong Zhang wrote: Hi Remi, Please see inline. ... Is the A:W-N:Z mapping created staticly? Or dynimicly? Dynamically when the 6a44-C starts operation. It then remains static until the 6a44 client or the NAT is reset. That is say it is similar to a kind of permanent state once the mapping is created, supposing that there no NAT reboot and power off. Right? If so, the interruption issue of CPE should be considered. 6a44 still needs to guarantee the state recovery, right? Why? When I have to restart my IPv4-only ADSL box, I lose all sessions, and for all I know I get a different IPv4 address. So why do I care if 6a44 loses state too? Certainly the IPv6 client host must be forced to restart the 6a44 process when this happens. We do need a method of forcing that. Brian ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
