Re: [Softwires] [v4tov6transition] 6a44 MTU issues
Le 13 oct. 2010 à 22:04, Templin, Fred L a écrit : ... If IPv6 packets longer than 1280 would be accepted by 6a44 servers, hosts could receive them in fragmented IPv4 datagrams. Or they might be reassembled in the NAT(s) in front of the host. They would indeed. But they would then be forwarded across the customer network. There, they may somewhere be fragmented to fit into fragments shorter than the ISP MTU + 28. This happens for example if the ISP IPv6 MTU would be 1500-28 and that of some link in the customer site would be 1500-40 (say, for an IPv4 in IPv6 tunnel). Right? The fact of life is that we have the ISP managed network domain and the end user network unmanaged network domain, whether the ISP controls the CPE or not. The managed domain should be well-behaved, but any manner of MTU irregularities is possible within the unmanaged domain. For example, I can login to my Linksys home router and manually set the MTU to any value I want. Anything that can be configured can be mis-configured, and the ISP has no control of any misconfigurations that might occur in the end user network. As far as the ISP can tell, the end user network is just a black hole that silently consumes packets. The point isn't about misconfigurations. It is that stateless tunnels (i.e. without SEAL ...) are legitimate within customer sites. They can lead some intra-site IPv4 PMTUs that are less than 1500, and even less than 1500 - 28. Then, because the 6a44 design privileges robustness, it is better to avoid more constraints on intra-site PMTUs than those that are absolutely mandatory. In order to statelessly support IPv6/UPD/IPV4 packets intra-site IPv4 PMTUs of 1280 + 8 + 20 = 1308 octets IS the obligation (one that should be satisfied with all realistic stateless tunnels in customer sites). RD ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] [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. 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 direction: if S forward some IPv6 packets whose size is between HOME_MTU-28 and SP_MTU-28, N might trigger a ICMPv4 PTB or filtering them. For the former, S might don't have enough info to infer which IPv6 original packet it is related, Right. for the latter, black hole might occur. I see problems here. Right. Fred fred.l.temp...@boeing.com Thanks, washam 2010/10/12 Templin, Fred L fred.l.temp...@boeing.com: Hi Washam, -Original Message- From: Washam Fan [mailto:washam@gmail.com] Sent: Monday, October 11, 2010 7:38 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, If 6a44 deployed in a managed ISP network, the 6a44 client could be configured with IPv4_MTU-28 for its IPv6 MTU. My understanding is that the 6a44 server is in the managed ISP network, and the 6a44 client is in the UNmanaged end user network. For inbound direction, 6a44 server would reject any IPv6 packets whose size exceeds IPv4_MTU-28 with a ICMPv6 PTB message, so no ICMPv6-ICMPv4 translation needed. Huh? How does the server have any idea what MTU the client set on its tunnel interface? The client is behind a NAT in an unmanaged end user network. Are you expecting the server to probe the path MTU to the client and maintain state? (An IRON server might be in position to do
Re: [Softwires] [v4tov6transition] 6a44 MTU issues
Hi Remi, -Original Message- From: Rémi Després [mailto:remi.desp...@free.fr] Sent: Thursday, October 14, 2010 12:09 AM To: Templin, Fred L Cc: Softwires; v4tov6transit...@ietf.org Subject: Re: [Softwires] [v4tov6transition] 6a44 MTU issues Le 13 oct. 2010 à 22:04, Templin, Fred L a écrit : ... If IPv6 packets longer than 1280 would be accepted by 6a44 servers, hosts could receive them in fragmented IPv4 datagrams. Or they might be reassembled in the NAT(s) in front of the host. They would indeed. But they would then be forwarded across the customer network. There, they may somewhere be fragmented to fit into fragments shorter than the ISP MTU + 28. This happens for example if the ISP IPv6 MTU would be 1500-28 and that of some link in the customer site would be 1500-40 (say, for an IPv4 in IPv6 tunnel). Right? The fact of life is that we have the ISP managed network domain and the end user network unmanaged network domain, whether the ISP controls the CPE or not. The managed domain should be well-behaved, but any manner of MTU irregularities is possible within the unmanaged domain. For example, I can login to my Linksys home router and manually set the MTU to any value I want. Anything that can be configured can be mis-configured, and the ISP has no control of any misconfigurations that might occur in the end user network. As far as the ISP can tell, the end user network is just a black hole that silently consumes packets. The point isn't about misconfigurations. It is that stateless tunnels (i.e. without SEAL ...) are legitimate within customer sites. They can lead some intra-site IPv4 PMTUs that are less than 1500, and even less than 1500 - 28. No; the point is that (without a deterministic MTU discovery scheme) you can't control the few end user networks that set a 1308 MTU so the vast majority of end user networks that set a 1500+ MTU are made to suffer. Fred fred.l.temp...@boeing.com Then, because the 6a44 design privileges robustness, it is better to avoid more constraints on intra-site PMTUs than those that are absolutely mandatory. In order to statelessly support IPv6/UPD/IPV4 packets intra-site IPv4 PMTUs of 1280 + 8 + 20 = 1308 octets IS the obligation (one that should be satisfied with all realistic stateless tunnels in customer sites). RD ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] [v4tov6transition] IPv6 VPNs configured over 1280 MTU tunnels
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 direction: if S forward some IPv6 packets whose size is between HOME_MTU-28 and SP_MTU-28, N might trigger a ICMPv4 PTB or filtering them. For the former, S might don't have enough info to infer which IPv6 original packet it is related, Right. for the latter, black hole might occur. I see problems here. Right. Fred fred.l.temp...@boeing.com Thanks, washam 2010/10/12 Templin, Fred L fred.l.temp...@boeing.com: Hi Washam, -Original Message- From: Washam Fan [mailto:washam@gmail.com] Sent: Monday, October 11, 2010 7:38 PM To: Templin, Fred L Cc: Rémi Després; Softwires; v4tov6transit...@ietf.org Subject: Re:
Re: [Softwires] [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? 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 direction: if S forward some IPv6 packets whose size is between HOME_MTU-28 and SP_MTU-28, N might trigger a ICMPv4 PTB or filtering them. For the former, S might don't have enough info to infer which IPv6 original packet it is related, Right. for the latter, black hole might occur. I see problems here. Right. Fred fred.l.temp...@boeing.com Thanks, washam 2010/10/12 Templin, Fred L fred.l.temp...@boeing.com: Hi Washam, -Original Message- From: Washam Fan [mailto:washam@gmail.com] Sent: Monday, October 11, 2010 7:38 PM To: Templin, Fred L Cc: Rémi
Re: [Softwires] Call for agenda items
Hi, Alain David, We'd like to have a time slot for a presentation in IETF 79. 1. Draft name: draft-guo-softwire-sc-discovery 2. Time requested: 5~10 mins 3. Presenter: Sheng Jiang This is the fourth time we present this draft. This draft has also been reviewed by DHC working group. All received comments has been addressed. We'd like to ask the WG adoption during IETF 79. Best regards, Sheng -Original Message- From: softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] On Behalf Of Alain Durand Sent: Friday, October 15, 2010 7:32 AM 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] DHCPv6 AFTR name option is needed
On Oct 14, 2010, at 1:13 AM, Maglione Roberta wrote: In the specific case being able to provide load-balancing and redundancy in DS-Lite scenario is a requirement for us, thus I would like to see a solution for this coming from IETF. So your requirement is to have load balancing, not to have DNS, correct? ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] DHCP option for DS-lite
David (document shepherd), Jari, all, In can answer to the technical questions, but before that let position this discussion in its context in the overall process (softwire should follow the ietf process). Below a reminder of the main steps for the adoption of this document: o First of all, this document is the proprietary of the working group and should reflect the consensus of the working group not the opinions of the authors neither the chairs. o The working group reached a consensus on the version, available at http://tools.ietf.org/html/ draft-ietf-softwire-ds-lite-tunnel-option-03. During the last call I didn't remember comments about the name option. o Dave Ward who is the document shepherd mentioned the following in his note (available on the tracker): (1) We saw evidence of extensive review on the mailing list. The documents has been presented in softwires, v6ops, and dhc working groups. (2) the document has strong support in the WG. (3) This is strictly a protocol specification. We believe that an operational document discussing some of the various tradeoffs and choices when deploying DS-Lite would be valuable. o According to the IETF tracker, a Go Ahead has been received from R. Droms on August, 5th. I understand this as Ralph has no technical issue with the content of the document. o According to the IETF tracker, Jari raised the following comment: This document is ready to move forward. However, there is one issue that I would like to briefly discuss before recommending the final approval of the RFC. We have been pushing back in other cases when people defined both FQDN and IP address information for the same configuration item in DHCP. Why are two options and configuration mechanisms absolutely necessary in this case? Wouldn't IP-address based configuration suffice? o The comment from Jari is valid and the document should justify why two options are needed. This is even surprising because D. Hankins is also the author of http://tools.ietf.org/html/draft-ietf-dhc-option-guidelines since 2007. This is issue in not new for him. o The authors on their own (or with the document shepherd, I don't know) decided to remove the name option **without** asking the working group's opinion. No notification has been sent on the mailing list to notify or to justify this IMPORTANT change to the document. At least two representatives of service providers reiterated the need of the name option for high availability and load balancing reasons. We can provide Jari with more details if required. Since the authors already maintained the IP address I believe they have strong arguments to maintain also the IP address option. The question should whether this feedback solves the issue raised by Jari during the IESG review. Jari, do you need more justification? Cheers, Med -Message d'origine- De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la part de Alain Durand Envoyé : jeudi 14 octobre 2010 18:59 À : Softwires list Cc : Ralph Droms Objet : Re: [Softwires] DHCP option for DS-lite I went back to the other thread on this topic DHCPv6 AFTR name option is needed. The only technical argument brought forward is that some ISPs would like to use a level of indirection via DNS to achieve load balancing (where the DNS has some form of measurement of the current load of the system). They point at VoIP for a precedent in that space. I would like to offer several remarks: 1) In the current DS-Lite model, the B4 element would only find out the tunnel end-point at config (boot) time. There is no provision in the spec to regularly refresh this information. This means that whatever is configured is going to stay that way for possibly a very long time. 2) It is unclear that the load information that the DNS was using at the time of the resolution is a good indicator of what the load will be hours or days later. 3) Thus, it is unclear that such a system provide any better load distribution that a simple round-robin that can trivially be implemented in a DHCP server 4) If one follows that logic, the DNS redirection just add a round trip time for no benefits. 5) The analogy with VoIP does not hold here because the VoIP client can do the query just before placing a call. The load information coming from the DNS has a better chance of being accurate for the next few minutes. I would like to invite the proponents of the DNS indirection to provide technical arguments as why the above remarks are incorrect. - Alain. On Oct 12, 2010, at 12:00 PM, Alain Durand wrote: Dear wg:
