Re: [BEHAVE] Amount of fragmentation resulting from translation

[Iljitsch van Beijnum <iljitsch at muada.com>]

On 31 okt 2009, at 21:00, Brian E Carpenter wrote:

> > I've been looking at IPv6 in BitTorrent a bit, and nearly all peers
> > participating in BitTorrent over IPv6 use 6to4. Obviously there  
> > will be
> > little overlap between 6to4 users and NAT64 users...

> Actually draft-defeche shows that Teredo is twice as important as  
> 6to4,
> but yes, most of the 1280s come from automatic tunnels.

Another interesting observation: of all of those 6to4 peers I saw,  
pretty much none successfully accepted incoming TCP sessions.

> But I don't get
> your argument: if the PMTU is limited to 1280 anywhere in the IPv6  
> domain,
> it's a problem, for some of the deployment scenarios for
> draft-ietf-behave-v6v4-xlate.

It's not really a problem as long as you make sure the PMTUD works.

However, if such small MTUs are common (and I think they won't be  
because typical NAT64 deployments will happen with native IPv6 where  
there is no need to have a < 1500 MTU) then it makes sense to adjust  
the MSS option so TCP traffic doesn't have to hit PMTUD all the time.

> > I'll see if I can dig up some info from people visiting my websites  
> > over
> > IPv6.

> Yes, that would be valuable.

My websites (and mail server) aren't THAT popular and neither is IPv6,  
so in the past 24 hours I only caught this:

2001:xxx > 2001:1af8:2:5::2.25: <mss 1440,sackOK,timestamp 427258783 0>
2001:xxx > 2001:1af8:2:5::2.80: <mss 8940,nop,wscale  
1,nop,nop,timestamp 616253582 0,sackOK,eol>
2001:xxx > 2001:1af8:2:5::2.80: <mss 1220,nop,wscale 2,nop,nop,sackOK>

So average MTU = 3927.  :-)

I'll let it run for a week or so and after that also see in how many  
cases the actual path MTU is smaller than the MTU advertised in the  
MSS option.