RE: MTU handling in 6RD deployments
Hi Mark, -Original Message- From: Mark Townsley [mailto:m...@townsley.net] Sent: Friday, January 17, 2014 12:41 AM To: Mikael Abrahamsson Cc: Templin, Fred L; ipv6-ops@lists.cluenet.de Subject: Re: MTU handling in 6RD deployments On Jan 17, 2014, at 9:24 AM, Mikael Abrahamsson wrote: On Thu, 16 Jan 2014, Templin, Fred L wrote: The key is that we want to probe the path between the BR and CE (in both directions) *before* allowing regular data packets to flow. We want to know ahead of time whether to allow large packets into the tunnel or whether we need to shut the MTU down to 1480 (or 1472 or something) and clamp the MSS. Because, once we restrict the tunnel MTU hosts will be stuck with a degenerate MTU indefinitely or at least for a long time. This method makes some sense, but since network conditions can change, I would like to see periodic re-checks of the tunnel still working with the packet sizes, perhaps pinging itself over the tunnel once per minute with the larger packet size if larger packet size is in use. Section 8 of RFC 5969 could be relevant here. In that section, I see: The link-local address of a 6rd virtual interface performing the 6rd encapsulation would, if needed, be formed as described in Section 3.7 of [RFC4213]. However, no communication using link-local addresses will occur. So, if we were to construct the pings from the IPv6 level we would want to use link-local source and destination addresses. But, that raises a question that would need to be addressed - should the pings be constructed at the IPv6 level, the IPv4 level, or some mid-level like SEAL? One other thing about this is that we are specifically not testing to determine an exact path MTU. We are only trying to answer the binary question of whether or not the tunnel can pass a 1500 byte IPv6 packet. Thanks - Fred fred.l.temp...@boeing.com - Mark -- Mikael Abrahamssonemail: swm...@swm.pp.se
RE: MTU handling in 6RD deployments
Hi Mark, -Original Message- From: ipv6-ops-bounces+fred.l.templin=boeing@lists.cluenet.de [mailto:ipv6-ops- bounces+fred.l.templin=boeing@lists.cluenet.de] On Behalf Of Templin, Fred L Sent: Friday, January 17, 2014 7:57 AM To: Mark Townsley; Mikael Abrahamsson Cc: ipv6-ops@lists.cluenet.de Subject: RE: MTU handling in 6RD deployments Hi Mark, -Original Message- From: Mark Townsley [mailto:m...@townsley.net] Sent: Friday, January 17, 2014 12:41 AM To: Mikael Abrahamsson Cc: Templin, Fred L; ipv6-ops@lists.cluenet.de Subject: Re: MTU handling in 6RD deployments On Jan 17, 2014, at 9:24 AM, Mikael Abrahamsson wrote: On Thu, 16 Jan 2014, Templin, Fred L wrote: The key is that we want to probe the path between the BR and CE (in both directions) *before* allowing regular data packets to flow. We want to know ahead of time whether to allow large packets into the tunnel or whether we need to shut the MTU down to 1480 (or 1472 or something) and clamp the MSS. Because, once we restrict the tunnel MTU hosts will be stuck with a degenerate MTU indefinitely or at least for a long time. This method makes some sense, but since network conditions can change, I would like to see periodic re-checks of the tunnel still working with the packet sizes, perhaps pinging itself over the tunnel once per minute with the larger packet size if larger packet size is in use. Section 8 of RFC 5969 could be relevant here. In that section, I see: The link-local address of a 6rd virtual interface performing the 6rd encapsulation would, if needed, be formed as described in Section 3.7 of [RFC4213]. However, no communication using link-local addresses will occur. Sorry, I was looking at the wrong section. I see now that Section 8 is talking about a method for a CE to send an ordinary data packet that loops back via the BR. That method is fine, but it is no more immune to someone abusing the mechanism than would be sending a ping (or some other NUD message). By using a ping, the BR can impose rate-limiting on its ping responses whereas with a looped-back data packet the BR really can't do rate limiting. Also, Section 8 of RFC5969 only talks about the CE testing the forward path to the BR. Unless the BR also tests the reverse path to the CE it has no way of knowing whether the CE can accept large packets. Thanks - Fred fred.l.temp...@boeing.com So, if we were to construct the pings from the IPv6 level we would want to use link-local source and destination addresses. But, that raises a question that would need to be addressed - should the pings be constructed at the IPv6 level, the IPv4 level, or some mid-level like SEAL? One other thing about this is that we are specifically not testing to determine an exact path MTU. We are only trying to answer the binary question of whether or not the tunnel can pass a 1500 byte IPv6 packet. Thanks - Fred fred.l.temp...@boeing.com - Mark -- Mikael Abrahamssonemail: swm...@swm.pp.se
RE: MTU handling in 6RD deployments
On Fri, 17 Jan 2014, Mikael Abrahamsson wrote: On Fri, 17 Jan 2014, Templin, Fred L wrote: Sorry, I was looking at the wrong section. I see now that Section 8 is talking about a method for a CE to send an ordinary data packet that loops back via the BR. That method is fine, but it is no more immune to someone abusing the mechanism than would be sending a ping (or some other NUD message). By using a ping, the BR can impose rate-limiting on its ping responses whereas with a looped-back data packet the BR really can't do rate limiting. You don't ping the BR, you ping yourself via the BR. The BR only forwards the packet. My bad, I didn't read your text properly. Why would the BR want to rate-limit data plane traffic? -- Mikael Abrahamssonemail: swm...@swm.pp.se
RE: MTU handling in 6RD deployments
On Fri, 17 Jan 2014, Templin, Fred L wrote: Sorry, I was looking at the wrong section. I see now that Section 8 is talking about a method for a CE to send an ordinary data packet that loops back via the BR. That method is fine, but it is no more immune to someone abusing the mechanism than would be sending a ping (or some other NUD message). By using a ping, the BR can impose rate-limiting on its ping responses whereas with a looped-back data packet the BR really can't do rate limiting. You don't ping the BR, you ping yourself via the BR. The BR only forwards the packet. Also, Section 8 of RFC5969 only talks about the CE testing the forward path to the BR. Unless the BR also tests the reverse path to the CE it has no way of knowing whether the CE can accept large packets. You misread the text. -- Mikael Abrahamssonemail: swm...@swm.pp.se
RE: MTU handling in 6RD deployments
Hi Mikael, -Original Message- From: Mikael Abrahamsson [mailto:swm...@swm.pp.se] Sent: Friday, January 17, 2014 8:15 AM To: Templin, Fred L Cc: Mark Townsley; ipv6-ops@lists.cluenet.de Subject: RE: MTU handling in 6RD deployments On Fri, 17 Jan 2014, Templin, Fred L wrote: Sorry, I was looking at the wrong section. I see now that Section 8 is talking about a method for a CE to send an ordinary data packet that loops back via the BR. That method is fine, but it is no more immune to someone abusing the mechanism than would be sending a ping (or some other NUD message). By using a ping, the BR can impose rate-limiting on its ping responses whereas with a looped-back data packet the BR really can't do rate limiting. You don't ping the BR, you ping yourself via the BR. The BR only forwards the packet. Also, Section 8 of RFC5969 only talks about the CE testing the forward path to the BR. Unless the BR also tests the reverse path to the CE it has no way of knowing whether the CE can accept large packets. You misread the text. I don't see anywhere where it says that the BR should also ping the CE and cache a boolean ACCEPTS_BIG_PACKETS for this CE. If the BR doesn't do that, it needs to set its MTU to the CE to 1480 (or 1472 or something). Thanks - Fred fred.l.temp...@boeing.com -- Mikael Abrahamssonemail: swm...@swm.pp.se
RE: MTU handling in 6RD deployments
cache a boolean ACCEPTS_BIG_PACKETS for this CE. BTW, the reason I am saying that the only thing we are trying to determine is whether/not the CE-BR path can pass a 1500 byte packet is that 1500 bytes is the de facto Internet cell most end systems expect to see w/o getting an ICMP PTB back. So, if we can give the hosts at least 1500 then if they want to try for a larger size they should use RFC4821. This makes things much easier than trying to probe the CE-BR path for an exact size. Thanks - Fred fred.l.temp...@boeing.com
Re: MTU handling in 6RD deployments
On Jan 17, 2014, at 5:14 PM, Mikael Abrahamsson wrote: On Fri, 17 Jan 2014, Templin, Fred L wrote: Sorry, I was looking at the wrong section. I see now that Section 8 is talking about a method for a CE to send an ordinary data packet that loops back via the BR. That method is fine, but it is no more immune to someone abusing the mechanism than would be sending a ping (or some other NUD message). By using a ping, the BR can impose rate-limiting on its ping responses whereas with a looped-back data packet the BR really can't do rate limiting. You don't ping the BR, you ping yourself via the BR. The BR only forwards the packet. Precisely. The whole idea is to stay on the data plane. - Mark Also, Section 8 of RFC5969 only talks about the CE testing the forward path to the BR. Unless the BR also tests the reverse path to the CE it has no way of knowing whether the CE can accept large packets. You misread the text. -- Mikael Abrahamssonemail: swm...@swm.pp.se
RE: MTU handling in 6RD deployments
On Fri, 17 Jan 2014, Templin, Fred L wrote: But, if the BR doesn't examine the packet it could get caught up in a flood-ping initiated by a malicious CE. The BR should have enough dataplane forwarding capacity to handle this. I am considering a specific ping rather than an ordinary data packet as a way for the BR to know whether the CE is testing the MTU vs whether it is just looping back packets. If the BR knows the CE is testing the MTU, it can send ping replies subject to rate limiting so a malicious CE can't swamp the BR with excessive pings. Why does it need to know? The CE is pinging itself CE-BR-CE, and if the CE doesn't receive the packet back then the MTU is obviously limited. So the CE sends out a packet towards the BR, with the IPv6 address being the CE itself. So the packet arrives at the BR, gets decapsulated, does IPv6 dst address lookup, gets encapsulated, and then sent onto the CE. Pure data plane. I don't get why the BR should need to get involved in anything more complicated than that? -- Mikael Abrahamssonemail: swm...@swm.pp.se
RE: MTU handling in 6RD deployments
Hi, You don't ping the BR, you ping yourself via the BR. The BR only forwards the packet. Precisely. The whole idea is to stay on the data plane. I do not work for a network equipment manufacturer, so I'll take your word that remaining in the data plane is critical for 6rd BRs and that high data rate loopbacks are not a problem. So, a looped back MTU test tests both the forward and reverse path MTUs between the CE and BR. This is important to the CE, because if it were only to test the forward path to the BR it would not know whether the reverse path MTU is big enough and so allowing an IPv6 destination outside of the 6rd site to discover a too-large MSS could result in communication failures. In terms of the BR's knowledge of the path MTU to the CE, if we can assume that the BR will receive the necessary ICMPs from the 6rd site then it can passively rely on translating ICMPv4 PTB messages coming from the 6rd site into corresponding ICMPv6 PTB messages to send back to the remote IPv6 correspondent. So, the BR should be able to set an infinite IPv6 MTU on its tunnel interface and passively translate any PTB messages it receives. That, plus the fact that the two IPv6 hosts have to agree on an MSS excuses the BR from having to do any active probing itself. So, take what is already in RFC5969, and add that a successful test of a 1500 byte probe allows the CE to set an infinite IPv6 MTU with the understanding that IPv6 hosts that want to use sizes larger than 1500 are expected to use RFC4821. BTW, by infinite I mean 4GB minus the encapsulation overhead. Thanks - Fred fred.l.temp...@boeing.com
RE: MTU handling in 6RD deployments
BTW, by infinite I mean 4GB minus the encapsulation overhead. Umm, sorry; that is only for tunnels over IPv6. For tunnels over IPv4, infinite means 64KB minus the overhead. Thanks - Fred fred.l.temp...@boeing.com
RE: MTU handling in 6RD deployments
Here's another idea on 6RD MTU. When a 6RD CE router first comes up, have it ping the BR with a 1520 byte ping. If it gets a reply, don't advertise an MTU in RA options and set the MTU to the BR to infinity. If it doesn't get a reply, advertise an MTU of 1480 (or maybe 1472). No fragmentation and reassembly are permitted. In the reverse direction, when a 6RD BR forwards a packet to a CE router that it hasn't ping'd before (or hasn't ping'd recently), have it ping the CE with a 1520 byte ping. If it gets a reply, set the MTU to the CE to infinity. If it doesn't get a reply, set the MTU to 1480 (or maybe 1472). Again, no fragmentation and reassembly. The only state in the BR then is an MTU value for each CE that it talks to - in the same way ordinary IPv4 nodes maintain a path MTU cache for the destinations they talk to. Thanks - Fred fred.l.temp...@boeing.com
Re: MTU handling in 6RD deployments
Hi, In the reverse direction, when a 6RD BR forwards a packet to a CE router that it hasn't ping'd before (or hasn't ping'd recently), have it ping the CE with a 1520 byte ping. If it gets a reply, set the MTU to the CE to infinity. If it doesn't get a reply, set the MTU to 1480 (or maybe 1472). Again, no fragmentation and reassembly. The only state in the BR then is an MTU value for each CE that it talks to - in the same way ordinary IPv4 nodes maintain a path MTU cache for the destinations they talk to. Since we assume that 6RD packets between the BR and the CE go over infrastructure that the ISP controls, wouldn't it be easier to just try to send bigger (IPv4) packets from the BR to the CE with the DF bit set, and look for PTB messages? On the public internet relying on PTBs might be a bad idea, but on controlled infrastructure you might be able to reply on those. If you can raise the MTU to 1520 you should be able to make PTBs work, right? ;-) It might save an extra roundtrip with a ping and use standard ICMP messages and associated state. Cheers, Sander
RE: MTU handling in 6RD deployments
Hi Tore, Does anyone know what tricks, if any, the major 6RD deployments (ATT, Free, Swisscom, others?) are using to alleviate any problems stemming from the reduced IPv6 MTU? Some possibilities that come to mind are: * Having the 6RD CPE lower the TCP MSS value of SYN packets as they enter/exit the tunnel device * Having the 6RD BR lower the TCP MSS value in the same way as above * Having the 6RD CPE advertise a lowered MTU to the LAN in RA Options * Several (or all) of the above in combination We advertise an MTU of 1472 in the RA Options. We still have a small number of PPPoE users and the max-payload-tag is not working reliably enough on third-party devices. Hence: 1500 Bytes - 20 Bytes IPv4 - 8 Bytes PPPoE = 1472 Bytes \Martin
RE: MTU handling in 6RD deployments
Hi Mikael, -Original Message- From: Mikael Abrahamsson [mailto:swm...@swm.pp.se] Sent: Thursday, January 09, 2014 11:11 PM To: Templin, Fred L Cc: IPv6 Ops list Subject: RE: MTU handling in 6RD deployments On Thu, 9 Jan 2014, Templin, Fred L wrote: I don't doubt that your experience is valid for the environment you are working in. What I am saying is that there may be many environments where setting IPv4 link MTUs to 1520+ is a viable alternative and then the hosts can see a full 1500+ MTU w/o ICMPs. SEAL detects when such favorable conditions exist and uses limited fragmentation/reassembly only when they don't. Or, if fragmentation/reassembly is deemed unacceptable for the environment, then clamp the MSS. 6RD relays can be made cheap because they are stateless. 6RD implementation in hosts can be bade cheap, because it's easy. SEAL isn't stateless (obviously, since it can do re-assembly), thus increasing cost and complexity both in host and relay. I understand. But, SEAL is not heavy-duty and steady state fragmentation and reassembly is not a desired end condition. Instead, it is a sign that something is out of tune and needs to be tuned properly. Or, if it can't be tuned, then fall back to MSS clamping and you are no worse off than without SEAL. So while it might have a technical fit, it isn't really an operational or monetary fit right this minute. 6RD is widely implemented today, by the time any other mechanism is implemented, the use-case for IPv6 tunneled in IPv4 might be much less interesting, hopefully more are moving towards IPv4 over native IPv6 for new implementations. There is an alpha implementation available at: linkupnetworks.com/seal/sealv2-1.0.tgz And, I don't know whether any of us can say what the timeframe is for all native IPv6 everywhere given that we are close to 20yrs in and still no end in sight for IPv4. Also, SEAL works for all tunnel combinations of IPvX-over-IPvY and is not specific to 6rd. So, implementation should be of interest in the general sense for the longer term. Thanks - Fred fred.l.temp...@boeing.com -- Mikael Abrahamssonemail: swm...@swm.pp.se
RE: MTU handling in 6RD deployments
Hi all. We have now changed and upgraded our BR to handle MTU in a sensible manner. We are not able to set the IPv4 MTU to more than 1500 due to limitations in our Cisco Cat4500 platform. So we have to reduce the MTU to 1480 somehow. Our other problem is that, by mistake, our RA MTU size is set to 1500, and not 1480, as it should be. This will be fixed in the next firmware we push out. Due to the problem with the MTU size, we had a lot of ICMPv6 PTB packets being returned from the Cisco 1K unit (BR). This again results to that the rate-limiting feature in the 1K dropped a lot of the PTB messages going back to the sender, hence making the IPv6 experience sluggish. Typical problems was that pictures and such had some timeout before they were loaded. To fix this issue, we first of all upgraded our 1K's to the latest IOS (Cisco IOS XE Software, Version 03.11.00.S) which has the MSS-Clamping feature. This feature was added by Cisco in November. Then we added the command ipv6 tcp adjust-mss 1420 to the 6rd tunnel interface. With this command set, all ICMPv6 PTB packets has disappeared, and the whole IPv6 experience has become a whole lot better with snappy loading of pages and pictures. So for TCP everything is good. As soon as we have fixed our firmware, this problem should be gone all together. Thanks to Tore Anderson for point this out to us. Hopefully this is useful for someone. Best Regards Ragnar Anfinsen Chief Architect CPE IPv6/IPv4 Architect Infrastructure Technology Altibox AS Phone: +47 51 90 80 00 Phone direct: +47 51 90 82 35 Mobile +47 93 48 82 35 E-mail: ragnar.anfin...@altibox.no Skype: ragnar_anfinsen www.altibox.no CONFIDENTIAL The content of this e-mail is intended solely for the use of the individual or entity to whom it is addressed. If you have received this communication in error, be aware that forwarding it, copying it, or in any way disclosing its content to any other person, is strictly prohibited. If you have received this communication in error, please notify the author by replying to this e-mail immediately, deleting this message and destruct all received documents.
RE: MTU handling in 6RD deployments
Hi Ragnar, What is the MTU as seen by the IPv6 hosts - 1480? Something less? Would it not be better if they could see 1500+? Thanks - Fred fred.l.temp...@boeing.com -Original Message- From: ipv6-ops-bounces+fred.l.templin=boeing@lists.cluenet.de [mailto:ipv6-ops- bounces+fred.l.templin=boeing@lists.cluenet.de] On Behalf Of Anfinsen, Ragnar Sent: Thursday, January 09, 2014 5:35 AM To: IPv6 Ops list Subject: RE: MTU handling in 6RD deployments Hi all. We have now changed and upgraded our BR to handle MTU in a sensible manner. We are not able to set the IPv4 MTU to more than 1500 due to limitations in our Cisco Cat4500 platform. So we have to reduce the MTU to 1480 somehow. Our other problem is that, by mistake, our RA MTU size is set to 1500, and not 1480, as it should be. This will be fixed in the next firmware we push out. Due to the problem with the MTU size, we had a lot of ICMPv6 PTB packets being returned from the Cisco 1K unit (BR). This again results to that the rate-limiting feature in the 1K dropped a lot of the PTB messages going back to the sender, hence making the IPv6 experience sluggish. Typical problems was that pictures and such had some timeout before they were loaded. To fix this issue, we first of all upgraded our 1K's to the latest IOS (Cisco IOS XE Software, Version 03.11.00.S) which has the MSS-Clamping feature. This feature was added by Cisco in November. Then we added the command ipv6 tcp adjust-mss 1420 to the 6rd tunnel interface. With this command set, all ICMPv6 PTB packets has disappeared, and the whole IPv6 experience has become a whole lot better with snappy loading of pages and pictures. So for TCP everything is good. As soon as we have fixed our firmware, this problem should be gone all together. Thanks to Tore Anderson for point this out to us. Hopefully this is useful for someone. Best Regards Ragnar Anfinsen Chief Architect CPE IPv6/IPv4 Architect Infrastructure Technology Altibox AS Phone: +47 51 90 80 00 Phone direct: +47 51 90 82 35 Mobile +47 93 48 82 35 E-mail: ragnar.anfin...@altibox.no Skype: ragnar_anfinsen www.altibox.no CONFIDENTIAL The content of this e-mail is intended solely for the use of the individual or entity to whom it is addressed. If you have received this communication in error, be aware that forwarding it, copying it, or in any way disclosing its content to any other person, is strictly prohibited. If you have received this communication in error, please notify the author by replying to this e-mail immediately, deleting this message and destruct all received documents.
Re: MTU handling in 6RD deployments
Thus wrote Templin, Fred L (fred.l.temp...@boeing.com): What is the MTU as seen by the IPv6 hosts - 1480? Something less? Would it not be better if they could see 1500+? Is this about the let's improve a case of flu (router generates too many Packet Too Big ICMP) with bubonic plague (let the router do both packet fragmentation (wasn't that explicitly forbidden in IPv6?) and packet reassembly) idea? regards, spz -- s...@serpens.de (S.P.Zeidler)
RE: MTU handling in 6RD deployments
Hi spz, -Original Message- From: S.P.Zeidler [mailto:s...@serpens.de] Sent: Thursday, January 09, 2014 8:22 AM To: Templin, Fred L Cc: IPv6 Ops list Subject: Re: MTU handling in 6RD deployments Thus wrote Templin, Fred L (fred.l.temp...@boeing.com): What is the MTU as seen by the IPv6 hosts - 1480? Something less? Would it not be better if they could see 1500+? Is this about the let's improve a case of flu (router generates too many Packet Too Big ICMP) with bubonic plague (let the router do both packet fragmentation (wasn't that explicitly forbidden in IPv6?) and packet reassembly) idea? Fragmentation and reassembly would not happen at the IPv6 level; they would happen at a sub-layer below IPv6 and above IPv4. So, there is no violation of the IPv6 standard since the tunnel endpoint is acting as a host when it encapsulates IPv6 packets. But, in some environments we might not want the 6rd BRs to suffer from sustained fragmentation and reassembly so a responsible network operator would fix their IPv4 link MTUs to 1520+. If they can't do that and the load on the 6rd BR appears too great, then MSS clamping and a degenerate IPv6 MTU reported to the IPv6 hosts is the only option. This is not a one size fits all solution for all 6rd domains; some might be better able to manage their IPv4 link MTUs and/or accept steady-state fragmentation than others. Thanks - Fred fred.l.temp...@boeing.com regards, spz -- s...@serpens.de (S.P.Zeidler)
Re: MTU handling in 6RD deployments
On 09.01.14 17:36, Templin, Fred L fred.l.temp...@boeing.com wrote: But, in some environments we might not want the 6rd BRs to suffer from sustained fragmentation and reassembly so a responsible network operator would fix their IPv4 link MTUs to 1520+. If they can't do that and the load on the 6rd BR appears too great, then MSS clamping and a degenerate IPv6 MTU reported to the IPv6 hosts is the only option. The problem with your statement is that many L3 access networks do not support MTU greater than 1500 on the access port. And if the RA MTU is set to 1480, you would not see any problems at all. However, there are some retail routers which do not set the MTU to 1480 when using a 6rd tunnel. In these cases adjusting the MSS if a good and efficient way of correcting that problem. Our experience so far is that MSS-clamping does not have any additional CPU load compared to not do it. /Ragnar
RE: MTU handling in 6RD deployments
Hi Ragnar, -Original Message- From: Anfinsen, Ragnar [mailto:ragnar.anfin...@altibox.no] Sent: Thursday, January 09, 2014 11:36 AM To: Templin, Fred L; S.P.Zeidler Cc: IPv6 Ops list Subject: Re: MTU handling in 6RD deployments On 09.01.14 17:36, Templin, Fred L fred.l.temp...@boeing.com wrote: But, in some environments we might not want the 6rd BRs to suffer from sustained fragmentation and reassembly so a responsible network operator would fix their IPv4 link MTUs to 1520+. If they can't do that and the load on the 6rd BR appears too great, then MSS clamping and a degenerate IPv6 MTU reported to the IPv6 hosts is the only option. The problem with your statement Where do you see a problem with my statement - it agrees with what you said below: is that many L3 access networks do not support MTU greater than 1500 on the access port. And if the RA MTU is set to 1480, you would not see any problems at all. However, there are some retail routers which do not set the MTU to 1480 when using a 6rd tunnel. In these cases adjusting the MSS if a good and efficient way of correcting that problem. Our experience so far is that MSS-clamping does not have any additional CPU load compared to not do it. I don't doubt that your experience is valid for the environment you are working in. What I am saying is that there may be many environments where setting IPv4 link MTUs to 1520+ is a viable alternative and then the hosts can see a full 1500+ MTU w/o ICMPs. SEAL detects when such favorable conditions exist and uses limited fragmentation/reassembly only when they don't. Or, if fragmentation/reassembly is deemed unacceptable for the environment, then clamp the MSS. Thanks - Fred fred.l.temp...@boeing.com /Ragnar
RE: MTU handling in 6RD deployments
On Thu, 9 Jan 2014, Templin, Fred L wrote: I don't doubt that your experience is valid for the environment you are working in. What I am saying is that there may be many environments where setting IPv4 link MTUs to 1520+ is a viable alternative and then the hosts can see a full 1500+ MTU w/o ICMPs. SEAL detects when such favorable conditions exist and uses limited fragmentation/reassembly only when they don't. Or, if fragmentation/reassembly is deemed unacceptable for the environment, then clamp the MSS. 6RD relays can be made cheap because they are stateless. 6RD implementation in hosts can be bade cheap, because it's easy. SEAL isn't stateless (obviously, since it can do re-assembly), thus increasing cost and complexity both in host and relay. So while it might have a technical fit, it isn't really an operational or monetary fit right this minute. 6RD is widely implemented today, by the time any other mechanism is implemented, the use-case for IPv6 tunneled in IPv4 might be much less interesting, hopefully more are moving towards IPv4 over native IPv6 for new implementations. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: MTU handling in 6RD deployments
Hello, Le 7 janv. 2014 à 12:37, Tore Anderson a écrit : Hi list, Does anyone know what tricks, if any, the major 6RD deployments (ATT, Free, Swisscom, others?) are using to alleviate any problems stemming from the reduced IPv6 MTU? Some possibilities that come to mind are: * Having the 6RD CPE lower the TCP MSS value of SYN packets as they enter/exit the tunnel device * Having the 6RD BR lower the TCP MSS value in the same way as above * Having the 6RD CPE advertise a lowered MTU to the LAN in RA Options For your information, i see an advertised mtu of 1480 on my WiFi interface with the Free CPE. * Several (or all) of the above in combination Also, given that some ISPs offer [only] Layer-2 service and expect/allow their customers to bring their own Layer-3 home gateway if they want one, I would find it interesting to learn if any of the most common off-the-shelf home gateway products (that enable 6RD by default) also implement any such tricks by default or not. Best regards Emmanuel Thierry
Re: MTU handling in 6RD deployments
Does anyone know what tricks, if any, the major 6RD deployments (ATT, Free, Swisscom, others?) are using to alleviate any problems stemming from the reduced IPv6 MTU? Some possibilities that come to mind are: * Having the 6RD CPE lower the TCP MSS value of SYN packets as they enter/exit the tunnel device * Having the 6RD BR lower the TCP MSS value in the same way as above * Having the 6RD CPE advertise a lowered MTU to the LAN in RA Options * Several (or all) of the above in combination ensure the 6rd domain MTU is =1520. Also, given that some ISPs offer [only] Layer-2 service and expect/allow their customers to bring their own Layer-3 home gateway if they want one, I would find it interesting to learn if any of the most common off-the-shelf home gateway products (that enable 6RD by default) also implement any such tricks by default or not. cheers, Ole signature.asc Description: Message signed with OpenPGP using GPGMail
Re: MTU handling in 6RD deployments
On Jan 7, 2014, at 12:56 PM, Emmanuel Thierry wrote: Hello, Le 7 janv. 2014 à 12:37, Tore Anderson a écrit : Hi list, Does anyone know what tricks, if any, the major 6RD deployments (ATT, Free, Swisscom, others?) are using to alleviate any problems stemming from the reduced IPv6 MTU? Some possibilities that come to mind are: * Having the 6RD CPE lower the TCP MSS value of SYN packets as they enter/exit the tunnel device * Having the 6RD BR lower the TCP MSS value in the same way as above * Having the 6RD CPE advertise a lowered MTU to the LAN in RA Options For your information, i see an advertised mtu of 1480 on my WiFi interface with the Free CPE. Section 9.1 of RFC 5969: If the MTU is well-managed such that the IPv4 MTU on the CE WAN side interface is set so that no fragmentation occurs within the boundary of the SP, then the 6rd Tunnel MTU should be set to the known IPv4 MTU minus the size of the encapsulating IPv4 header (20 bytes). For example, if the IPv4 MTU is known to be 1500 bytes, the 6rd Tunnel MTU might be set to 1480 bytes. Absent more specific information, the 6rd Tunnel MTU SHOULD default to 1280 bytes. Note I've heard some ISPs consider running Jumbo Frames under the covers so that IPv4 could carry 1520 and 1500 would be possible for IPv6, but have not yet seen that confirmed to me in practice. - Mark * Several (or all) of the above in combination Also, given that some ISPs offer [only] Layer-2 service and expect/allow their customers to bring their own Layer-3 home gateway if they want one, I would find it interesting to learn if any of the most common off-the-shelf home gateway products (that enable 6RD by default) also implement any such tricks by default or not. Best regards Emmanuel Thierry
Re: MTU handling in 6RD deployments
On Tue, 7 Jan 2014, Mark Townsley wrote: Note I've heard some ISPs consider running Jumbo Frames under the covers so that IPv4 could carry 1520 and 1500 would be possible for IPv6, but have not yet seen that confirmed to me in practice. Unless this is done in a very controlled environment I'd say this is bordering on the impossible. There are so many failure points for a jumbo solution it's scary. Most of them is also silent failure of PMTUD, basically blackholing of traffic. Yes, it can be done of course, but I'd say operationally it's easier to just drop the MTU to 1480 and known working, than the jumbo alternative. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: MTU handling in 6RD deployments
Hi, On Tue, Jan 07, 2014 at 12:37:39PM +0100, Tore Anderson wrote: Does anyone know what tricks, if any, the major 6RD deployments (ATT, Free, Swisscom, others?) are using to alleviate any problems stemming from the reduced IPv6 MTU? Some possibilities that come to mind are: Have a higher IPv4 MTU between the 6rd tunnel endpoints sounds like a nice solution an ISP could deploy. But I've long given up hope after everybody seems to agree that 1492 is just fine. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
RE: MTU handling in 6RD deployments
Hi Tore. Does anyone know what tricks, if any, the major 6RD deployments (ATT, Free, Swisscom, others?) are using to alleviate any problems stemming from the reduced IPv6 MTU? Some possibilities that come to mind are: * Having the 6RD CPE lower the TCP MSS value of SYN packets as they enter/exit the tunnel device * Having the 6RD BR lower the TCP MSS value in the same way as above * Having the 6RD CPE advertise a lowered MTU to the LAN in RA Options * Several (or all) of the above in combination Our managed CPEs (D-Links) send (IPv4 MTU) - 20 bytes in RAs, usually 1480. In the list of tricks, you might want to add: * Slightly raise the ICMPv6 rate-limit values for your 6RD BR (we do 50/20) I haven't seen IPv6 MSS clamping in the wild yet (it was discussed on this list a year ago). Also, given that some ISPs offer [only] Layer-2 service and expect/allow their customers to bring their own Layer-3 home gateway if they want one, I would find it interesting to learn if any of the most common off-the-shelf home gateway products (that enable 6RD by default) also implement any such tricks by default or not. From off-the-shelf, we see mostly D-Links and Cisco/Linksys/Belkin with option 212 support. A few Asus models started showing up in the stats in 2013 I believe. Last time I checked, all models supporting option 212 also reduced their MTU properly (YMMV here, that was almost a year ago). Too bigs remain quite common however... #sh ipv6 traffic | in too 11880 encapsulation failed, 0 no route, 3829023354 too big #sh ver | in upt uptime is 2 years, 4 weeks, 5 days, 4 hours, 3 minutes If 6lab's data is right, roughly half of Canada's IPv6 users go through that box (50k users). /JF
Re: MTU handling in 6RD deployments
* Gert Doering Have a higher IPv4 MTU between the 6rd tunnel endpoints sounds like a nice solution an ISP could deploy. True, well, in theory anyway. The reason I didn't include this in my list was that considering the whole point of 6RD is to be able to bypass limitations of old rusty gear that don't support fancy features like IPv6...the chances of that old rusty gear being able to reliably support jumbo frames wasn't very high either. Tore
Re: MTU handling in 6RD deployments
De : Gert Doering g...@space.net Have a higher IPv4 MTU between the 6rd tunnel endpoints sounds like a nice solution an ISP could deploy. Docsis MTU is 1518 bytes, so that won't happen any time soon in the cable world. (Docsis 3.1 is higher at 2000 bytes, but that's years away) /JF
Re: MTU handling in 6RD deployments
* Templin, Fred L 6RD could use SEAL the same as any tunneling technology. SEAL makes sure that packets up to 1500 get through no matter what, and lets bigger packets through (as long as they fit the first-hop MTU) with the expectation that hosts sending the bigger packets know what they are doing. It works as follows: - tunnel ingress pings the egress with a 1500 byte ping - if the ping succeeds, the path MTU is big enough to accommodate 1500s w/o fragmentation - if the ping fails, use fragmentation/reassembly to accommodate 1500 and smaller - end result - IPv6 hosts always see an MTU of at least 1500 In order for the BR to support reassembly it must maintain state. That's going to have a very negative impact on its scaling properties... Tore
RE: MTU handling in 6RD deployments
Hi again, Second (and more importantly) reassembly is not needed for packets of any size if the path can pass a 1500 byte ping packet. I should have qualified this by saying that the mechanism still works even if the BR responds to pings subject to rate limiting. Thanks - Fred fred.l.temp...@boeing.com
