Re: MTU handling in 6RD deployments

[Mark Townsley]

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

[Mark Townsley]

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: Microsoft: Give Xbox One users IPv6 connectivity

[Mark Townsley]

On Oct 10, 2013, at 4:56 PM, Geoff Huston wrote:
 
 I have not gathered data on Teredo-to-Teredo reliability. The connection 
 failure numbers quoted above make use of a Teredo Relay. But this 
 teredo-to-teredo connection failure rate in the Internet appears to be a 
 critical assumption here for this form of connection architecture.

This does sound like something you could do with your measurement architecture. 
Just a little tweak here and there. Any chance of that?

- Mark

 
 
 Geoff