Subject: [BEHAVE] General PMTUD black hole detection in translators

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 10 Feb 2010 08:19:52 +0100

If we want to avoid cases where there is a link with a reduced MTU between the IPv6 hosts and a translator that triggers path MTU discovery black holes towards certain IPv4 servers, we could add a form of PMTUD black hole detection to translators.

It would work like this: the translator of course translates too big messages from the IPv6 side to IPv4. If it remembers that it did this and then sees that the IPv4 host doesn't lower its packet sizes within a reasonable timeframe, it can then when new sessions are set up from the same IPv6 host towards the same IPv4 host, adjust the MSS to the value that was present in the earlier too big message.

So then the first TCP session would time out but subsequent ones would have their MSS clamped and those would work. This would only kick in when there is an actual black hole so there is no impact for well behaved systems. The initial session would still fail so there would still be good reason for PMTUD breakers to fix their systems, but after the initial failure, the user would have something that works.

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 10 Feb 2010 08:49:10 -0800

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Iljitsch van Beijnum
> Sent: Tuesday, February 09, 2010 11:20 PM
> To: [email-masked] WG
> Subject: [BEHAVE] General PMTUD black hole detection in translators
> 
> If we want to avoid cases where there is a link with a 
> reduced MTU between the IPv6 hosts and a translator that 
> triggers path MTU discovery black holes towards certain IPv4 
> servers, we could add a form of PMTUD black hole detection to 
> translators.
> 
> It would work like this: the translator of course translates 
> too big messages from the IPv6 side to IPv4. If it remembers 
> that it did this and then sees that the IPv4 host doesn't 
> lower its packet sizes within a reasonable timeframe, it can 
> then when new sessions are set up from the same IPv6 host 
> towards the same IPv4 host, adjust the MSS to the value that 
> was present in the earlier too big message.
> 
> So then the first TCP session would time out but subsequent 
> ones would have their MSS clamped and those would work. This 
> would only kick in when there is an actual black hole so 
> there is no impact for well behaved systems. The initial 
> session would still fail so there would still be good reason 
> for PMTUD breakers to fix their systems, but after the 
> initial failure, the user would have something that works.

Can we defer this to an improvement of the stateful translator?
This feels like it could be described in a new I-D describing 
how to best utilize a path's MTU using extra smarts in the 
translator.

If anyone feels this sort of behavior needs to be in the 
stateless or stateful I-Ds, please speak up now.

-d

> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 17 Feb 2010 17:05:55 -0800

Iljitsch,

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Iljitsch van Beijnum
> If we want to avoid cases where there is a link with a reduced MTU between the IPv6 hosts and a
> translator that triggers path MTU discovery black holes towards certain IPv4 servers, we could add a
> form of PMTUD black hole detection to translators.
> 
> It would work like this: the translator of course translates too big messages from the IPv6 side to
> IPv4. If it remembers that it did this and then sees that the IPv4 host doesn't lower its packet
> sizes within a reasonable timeframe, it can then when new sessions are set up from the same IPv6 host
> towards the same IPv4 host, adjust the MSS to the value that was present in the earlier too big
> message.
> 
> So then the first TCP session would time out but subsequent ones would have their MSS clamped and
> those would work. This would only kick in when there is an actual black hole so there is no impact
> for well behaved systems. The initial session would still fail so there would still be good reason
> for PMTUD breakers to fix their systems, but after the initial failure, the user would have something
> that works.

This sounds like the translator would be required
to do a lot of work, keep a lot of state, and would
present a non-deterministic service to end users.
And, it also only works for TCP.

Better would be to somehow ensure that all links on
the IPv6 side support a large enough MTU so that
1520 (*) or larger packets are delivered from the
translator to the IPv6 host without loss due to an
MTU restriction. Here, I include IPv6-over-IPv4
tunnels as "links".

Fred
[email-masked]

(*) For TCP communications initiated on the IPv6 side,
    an IPv6 host attached to a 1500 link would use a
    TCP MSS of 1440. So, an IPv4 host would only send
    1480 packets (1440 plus IPv4 header plus TCP header)
    which would be turned into 1500 packets on the IPv6
    side. But for non-TCP protocols, the IPv4 host would
    not see an MSS and could send 1500 packets that would
    be turned into 1520 packets on the IPv6 side.