Subject: Calculation of TCP MSS for IPv6 internet

From: Usman Latif <[email-masked]>
Date: Fri, 9 Oct 2015 23:10:19 +0000 (UTC)

Hi,

I am trying to look for drafts/standards which can help any vendor/carrier/operator in determining TCP MSS for IPv6 internet.
Assume there is a mobile/fixed carrier that uses TCP MSS adjustments for its mobile/fixed line consumers in the IPv4 domain as follows:

MTU = 1460 (assume that mostly works without any need for fragmentation in IPv4 today)
TCP header = 20
IP header = 20

TCP MSS = 1420

In the IPv6 domain, we would have:

MTU = 1460 - 20 - 40 (IPv6 standard header) = 1400B

However what I am not clear on, is how to cater for presence of (one or more) IPv6 extension headers on a packet.

RFC-2460 talks about using PMTU or a minimum MTU of 1280 if PMTU is not used
However we have seen in the field that PMTU rarely gives us the right measure of path-mtu (as some networks block ICMP messages across network boundaries)
Using a minimum MTU 1280 for calculating MSS may work but still two questions arise here:
i. Will host/network not have to process too many packets if a smaller MSS is computed thus increasing overhead?
ii. Even if we used 1280 - 20 - 40 (1220B) for MSS, do we completely address the presence of multiple maximum sized extension headers? - probably not.

The main question here would be whether presence of one or more extension headers is something that needs to be subtracted from the actual available MSS for the host to use in its TCP communication? - or would that be something that needs to be compensated for by measures like jumbo frame support on both the host interfaces as well network interfaces ?

Rgds,Usman

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 11 Oct 2015 11:09:20 +1300

Usman,

I am not going to comment on the content of your message, but you should realise
that by posting from a yahoo.com address, your message ends up in the spam folder
for every gmail user on the list, because of DMARC. So unless people regularly
check their spam folders, your messages will be ignored.

Regards
   Brian

On 10/10/2015 12:10, Usman Latif wrote:
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Usman Latif <[email-masked]>
Date: Sun, 11 Oct 2015 09:49:52 +1100

Thanks Brian.
Atleast since you being a GMAIL user have replied to this thread - I am hoping that atleast this subject will now be visible to all subscribers of the list
I always forget to use my GMAIL address and instead send emails from yahoo address

Regards,
Usman

> On 11 Oct 2015, at 9:09 am, Brian E Carpenter <[email-masked]> wrote:
> 
> Usman,
>

---

From: Mark Smith <[email-masked]>
Date: Sun, 11 Oct 2015 11:12:27 +1100

Hi,

On 10 Oct 2015 10:10, "Usman Latif" <[email-masked]> wrote:
>
> Hi,
>
> I am trying to look for drafts/standards which can help any
vendor/carrier/operator in determining TCP MSS for IPv6 internet.

See RFC6691.

Be aware that TCP MSS hacking in the network is a hack, and isn't a
solution to PMTUD issues that would impact UDP, IPsec, GRE, DCCP, SCTP etc.

If the TCP header is behind EHs, I would wonder whether the TCP MSS hacking
is going to be successful - is suspect many hardware implementations assume
the TCP header is directly after the IP header, and perhaps assume the MSS
option is also in the same location.

You are better off making PMTUD work or never need to be used, by
eliminating dumbbell MTU scenarios (<BIG><small><BIG> MTUs in path) (e.g.
for PPPoE, supporting RFC4638), ensuring ICMP PTBs make it back to the
packet originating hosts, or lowering the originating hosts' MTUs using the
RA MTU option.

Note that your hosts might support RFC4821 PMTUD which doesn't rely on ICMP
PTBs.

> Assume there is a mobile/fixed carrier that uses TCP MSS adjustments for
its mobile/fixed line consumers in the IPv4 domain as follows:
> However what I am not clear on, is how to cater for presence of (one or
more) IPv6 extension headers on a packet.
> RFC-2460 talks about using PMTU or a minimum MTU of 1280 if PMTU is not
used

If you can't be confident of PMTUD working reliably then the only truly
safe option is an MTU of 1280.

> However we have seen in the field that PMTU rarely gives us the right
measure of path-mtu (as some networks block ICMP messages across network
boundaries)

Have you measured this for IPv6, or are you just assuming it will be the
same as IPv4?

> i. Will host/network not have to process too many packets if a smaller
MSS is computed thus increasing overhead?
> ii. Even if we used 1280 - 20 - 40 (1220B) for MSS, do we completely
address the presence of multiple maximum sized extension headers? -
probably not.
>
> The main question here would be whether presence of one or more extension
headers is something that needs to be subtracted from the actual available
MSS for the host to use in its TCP communication? - or would that be
something that needs to be compensated for by measures like jumbo frame
support on both the host interfaces as well network interfaces ?

Regards,
Mark.

> Rgds,

---

From: Mark Andrews <[email-masked]>
Date: Sun, 11 Oct 2015 11:29:12 +1100

> Note that your hosts might support RFC4821 PMTUD which doesn't rely on ICMP

Also be aware that lots of implementations fail to look at
IPV6_USE_MINMTU like they should when performing TCP MSS negotiation.

If IPV6_USE_MINMTU=1 then the MTU to start the TCP MSS calculation
for the MSS negotiation should be 1280.

This leads to fragmented TCP packets outbound and PMTUD occuring
inbound despite IPV6_USE_MINMTU=1 being set.  Neither of these
behaviours should happen with IPV6_USE_MINMTU=1.

Mark

> --001a11434a3a622f930521c9119c
> Content-Type: text/html; charset=UTF-8
> Content-Transfer-Encoding: quoted-printable
> 
> <p dir=3D"ltr">Hi,<br></p>
> <p dir=3D"ltr">On 10 Oct 2015 10:10, &quot;Usman Latif&quot; &lt;<a href=3D=
> "mailto:[email-masked]">[email-masked]</a>&gt; wrote:<br>
> &gt;<br>
> &gt; Hi,<br>
> &gt;<br>
> &gt; I am trying to look for drafts/standards which can help any vendor/car=
> rier/operator in determining TCP MSS for IPv6 internet.</p>
> <p dir=3D"ltr">See RFC6691.</p>
> <p dir=3D"ltr">Be aware that TCP MSS hacking in the network is a hack, and =
> isn&#39;t a solution to PMTUD issues that would impact UDP, IPsec, GRE, DCC=
> P, SCTP etc.</p>
> <p dir=3D"ltr">If the TCP header is behind EHs, I would wonder whether the =
> TCP MSS hacking is going to be successful - is suspect many hardware implem=
> entations assume the TCP header is directly after the IP header, and perhap=
> s assume the MSS option is also in the same location.</p>
> <p dir=3D"ltr">You are better off making PMTUD work or never need to be use=
> d, by eliminating dumbbell MTU scenarios (&lt;BIG&gt;&lt;small&gt;&lt;BIG&g=
> t; MTUs in path) (e.g. for PPPoE, supporting RFC4638), ensuring ICMP PTBs m=
> ake it back to the packet originating hosts, or lowering the originating ho=
> sts&#39; MTUs using the RA MTU option.</p>
> <p dir=3D"ltr">Note that your hosts might support RFC4821 PMTUD which doesn=
> &#39;t rely on ICMP PTBs.</p>
> <p dir=3D"ltr">&gt; Assume there is a mobile/fixed carrier that uses TCP MS=
> S adjustments for its mobile/fixed line consumers in the IPv4 domain as fol=
> lows:<br>
> &gt;<br>
> &gt; MTU =3D 1460 (assume that mostly works without any need for fragmentat=
> ion in IPv4 today)<br>
> &gt; TCP header =3D 20<br>
> &gt; IP header =3D 20<br>
> &gt;<br>
> &gt; TCP MSS =3D 1420<br>
> &gt;<br>
> &gt; In the IPv6 domain, we would have:<br>
> &gt;<br>
> &gt; MTU =3D 1460 - 20 - 40 (IPv6 standard header) =3D 1400B<br>
> &gt;<br>
> &gt; However what I am not clear on, is how to cater for presence of (one o=
> r more) IPv6 extension headers on a packet.<br>
> &gt;<br>
> &gt; RFC-2460 talks about using PMTU or a minimum MTU of 1280 if PMTU is no=
> t used</p>
> <p dir=3D"ltr">If you can&#39;t be confident of PMTUD working reliably then=
>  the only truly safe option is an MTU of 1280.</p>
> <p dir=3D"ltr">&gt; However we have seen in the field that PMTU rarely give=
> s us the right measure of path-mtu (as some networks block ICMP messages ac=
> ross network boundaries)</p>
> <p dir=3D"ltr">Have you measured this for IPv6, or are you just assuming it=
>  will be the same as IPv4?</p>
> <p dir=3D"ltr">&gt; Using a minimum MTU 1280 for calculating MSS may work b=
> ut still two questions arise here:<br>
> &gt; i. Will host/network not have to process too many packets if a smaller=
>  MSS is computed thus increasing overhead?<br>
> &gt; ii. Even if we used 1280 - 20 - 40 (1220B) for MSS, do we completely a=
> ddress the presence of multiple maximum sized extension headers? - probably=
>  not.<br>
> &gt;<br>
> &gt; The main question here would be whether presence of one or more extens=
> ion headers is something that needs to be subtracted from the actual availa=
> ble MSS for the host to use in its TCP communication? - or would that be so=
> mething that needs to be compensated for by measures like jumbo frame suppo=
> rt on both the host interfaces as well network interfaces ?<br>
> &gt;</p>
> <p dir=3D"ltr">Regards,<br>
> Mark.</p>
> <p dir=3D"ltr">&gt;<br>
> &gt; Rgds,<br>
> &gt; Usman<br>
> &gt;<br>
> &gt; --------------------------------------------------------------------<b=
> r>
> &gt; IETF IPv6 working group mailing list<br>
> &gt; <a href=3D"mailto:[email-masked]">[email-masked]</a><br>
> &gt; Administrative Requests: <a href=3D"https://www.ietf.org/mailman/listi=
> nfo/ipv6">https://www.ietf.org/mailman/listinfo/ipv6</a><br>
> &gt; --------------------------------------------------------------------<b=
> r>
> &gt;<br>
> </p>
> 
> --001a11434a3a622f930521c9119c--
> 
> 
> --===============5238962577470170318==
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
> 
> --===============5238962577470170318==--
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Usman Latif <[email-masked]>
Date: Mon, 12 Oct 2015 03:40:59 +0000 (UTC)

Hi Mark,

     From: Mark Smith <[email-masked]>
 To: Usman Latif <[email-masked]> 
Cc: 6man WG <[email-masked]> 
 Sent: Sunday, 11 October 2015, 11:12
 Subject: Re: Calculation of TCP MSS for IPv6 internet
   
Hi,
On 10 Oct 2015 10:10, "Usman Latif" <[email-masked]> wrote:
>
> Hi,
>
> I am trying to look for drafts/standards which can help any vendor/carrier/operator in determining TCP MSS for IPv6 internet.See RFC6691.Be aware that TCP MSS hacking in the network is a hack, and isn't a solution to PMTUD issues that would impact UDP, IPsec, GRE, DCCP, SCTP etc.If the TCP header is behind EHs, I would wonder whether the TCP MSS hacking is going to be successful - is suspect many hardware implementations assume the TCP header is directly after the IP header, and perhaps assume the MSS option is also in the same location.You are better off making PMTUD work or never need to be used, by eliminating dumbbell MTU scenarios (<BIG><small><BIG> MTUs in path) (e.g. for PPPoE, supporting RFC4638), ensuring ICMP PTBs make it back to the packet originating hosts, or lowering the originating hosts' MTUs using the RA MTU option.Note that your hosts might support RFC4821 PMTUD which doesn't rely on ICMP PTBs.

[[Usman]] How can one carrier ensures PMTUD works correctly across the global internet? 
The security policies on network boundaries used by every carrier is not consistent and thus leads to unpredictable behavior for PMTUD type protocols running over Layer-3.
You raised an interesting point around RFC-4821 (PLPMTUD) - though I am not sure whether every host/application (and more specifically every IPv6 host/application) would be making use of PLPMTUD ? 
Is that something we are mandating for every IPv6 host/application?

> RFC-2460 talks about using PMTU or a minimum MTU of 1280 if PMTU is not usedIf you can't be confident of PMTUD working reliably then the only truly safe option is an MTU of 1280.> However we have seen in the field that PMTU rarely gives us the right measure of path-mtu (as some networks block ICMP messages across network boundaries)Have you measured this for IPv6, or are you just assuming it will be the same as IPv4?> Using a minimum MTU 1280 for calculating MSS may work but still two questions arise here:

Mark.

---

From: Mark Smith <[email-masked]>
Date: Tue, 13 Oct 2015 08:39:59 +1100

Hi Usman,

On 12 Oct 2015 14:41, "Usman Latif" <[email-masked]> wrote:
>
> Hi Mark,
>
> ________________________________
> If the TCP header is behind EHs, I would wonder whether the TCP MSS
hacking is going to be successful - is suspect many hardware
implementations assume the TCP header is directly after the IP header, and
perhaps assume the MSS option is also in the same location.
> Note that your hosts might support RFC4821 PMTUD which doesn't rely on
ICMP PTBs.
> [[Usman]] How can one carrier ensures PMTUD works correctly across the
global internet?

Unfortunately you can't specifically ensure PMTUD works correctly over the
Internet because it commonly relies on ICMP PTBs, and as you've said, some
networks that are out of your control might block them.

I think currently the best way to ensure PMTUD works is to not have to use
it, by having hosts have MTUs that are small enough not to trigger it. Both
IPv6 RAs and IPv4 DHCP can be used to lower host MTUs, or RFC4638 can be
used to raise a pppoe link's MTU.

I think that tends to be a better option than just trying to use TCP MSS
hacking because the Internet isn't just carrying TCP, and as I mentioned, I
wonder how smart  implementations are when the TCP header isn't directly
behind the IP header.

This was in part why I was wondering if you'd measured blocking of ICMP
PTBs for IPv6. We know it is happens for IPv4, but I wondered whether it is
happening to the same extent with IPv6.

> The security policies on network boundaries used by every carrier is not
consistent and thus leads to unpredictable behavior for PMTUD type
protocols running over Layer-3.
> You raised an interesting point around RFC-4821 (PLPMTUD) - though I am
not sure whether every host/application (and more specifically every IPv6
host/application) would be making use of PLPMTUD ?
> Is that something we are mandating for every IPv6 host/application?

I haven't done a lot of research into its support, however Linux does
support it but it defaults to bring off, and Windows supports it, and if I
recall correctly, it resorts to using it if certain failures occur.

It isn't something that applications request.

There are some more comments on it in this discussion.

https://www.ietf.org/mail-archive/web/v6ops/current/msg19815.html

Regards,
Mark.

>
> > Assume there is a mobile/fixed carrier that uses TCP MSS adjustments
same as IPv4?
> >
> > The main question here would be whether presence of one or more
extension headers is something that needs to be subtracted from the actual
available MSS for the host to use in its TCP communication? - or would that
be something that needs to be compensated for by measures like jumbo frame
support on both the host interfaces as well network interfaces ?

---

From: Mark Andrews <[email-masked]>
Date: Tue, 13 Oct 2015 09:37:45 +1100

> It isn't something that applications request.

But it is something that applications not using TCP need to implement
themselves or force packet back to network MTU.  Named sets
IPV6_USE_MINMTU=1 for all IPv6 sockets including TCP because the
costs of PMTUD is too high for TCP.  It also implements stategies
to select a EDNS UDP message size that gets answers through.

If you block PTB messages then applications *will* break.  Only
idiots block PTB messages.  If you load balancers don't handle PTB
messages you need to replace them with something that does.

What would really be best in the long term but painful in the short
term is to get rid of the TCP MSS fixup code.  It lets you think
that you have your network properly configured when it isn't.

Over on NANOG there is a discussion about TCP/IPv6 sessions stalling
behind a IPv6 in IPv4 tunnel.  We wouldn't be seeing this if nobody
was using TCP MSS fixup code as everyone would know how idiotic it
is to block all ICMP.  Load balanced that don't handle PTB messages
would have been cleared out of the ecosystem.

A bit of short term pain can give you a much better system in the
end.

> --001a1143a3f0ca25f30521ef2b25
> <p dir=3D"ltr">Hi Usman,</p>
> <p dir=3D"ltr">On 12 Oct 2015 14:41, &quot;Usman Latif&quot; &lt;<a href=3D=
> &gt; Hi Mark,<br>
> &gt; ________________________________<br>
> &gt; From: Mark Smith &lt;<a href=3D"mailto:[email-masked]">markzzz=
> [email-masked]</a>&gt;<br>
> &gt; To: Usman Latif &lt;<a href=3D"mailto:[email-masked]">osmankh@yahoo=
> .com</a>&gt; <br>
> &gt; Cc: 6man WG &lt;<a href=3D"mailto:[email-masked]">[email-masked]</a>&gt;=
>  <br>
> &gt; Sent: Sunday, 11 October 2015, 11:12<br>
> &gt; Subject: Re: Calculation of TCP MSS for IPv6 internet<br>
> &gt;<br>
> &gt; Hi,<br>
> &gt; On 10 Oct 2015 10:10, &quot;Usman Latif&quot; &lt;<a href=3D"mailto:os=
> [email-masked]">[email-masked]</a>&gt; wrote:<br>
> &gt; &gt;<br>
> &gt; &gt; Hi,<br>
> &gt; &gt;<br>
> &gt; &gt; I am trying to look for drafts/standards which can help any vendo=
> r/carrier/operator in determining TCP MSS for IPv6 internet.<br>
> &gt; See RFC6691.<br>
> &gt; Be aware that TCP MSS hacking in the network is a hack, and isn&#39;t =
> a solution to PMTUD issues that would impact UDP, IPsec, GRE, DCCP, SCTP et=
> c.<br>
> &gt; If the TCP header is behind EHs, I would wonder whether the TCP MSS ha=
> cking is going to be successful - is suspect many hardware implementations =
> assume the TCP header is directly after the IP header, and perhaps assume t=
> he MSS option is also in the same location.<br>
> &gt; You are better off making PMTUD work or never need to be used, by elim=
> inating dumbbell MTU scenarios (&lt;BIG&gt;&lt;small&gt;&lt;BIG&gt; MTUs in=
>  path) (e.g. for PPPoE, supporting RFC4638), ensuring ICMP PTBs make it bac=
> k to the packet originating hosts, or lowering the originating hosts&#39; M=
> TUs using the RA MTU option.<br>
> &gt; Note that your hosts might support RFC4821 PMTUD which doesn&#39;t rel=
> y on ICMP PTBs.<br>
> &gt;<br>
> &gt; [[Usman]] How can one carrier ensures PMTUD works correctly across the=
>  global internet?</p>
> <p dir=3D"ltr">Unfortunately you can&#39;t specifically ensure PMTUD works =
> correctly over the Internet because it commonly relies on ICMP PTBs, and as=
>  you&#39;ve said, some networks that are out of your control might block th=
> em.</p>
> <p dir=3D"ltr">I think currently the best way to ensure PMTUD works is to n=
> ot have to use it, by having hosts have MTUs that are small enough not to t=
> rigger it. Both IPv6 RAs and IPv4 DHCP can be used to lower host MTUs, or R=
> FC4638 can be used to raise a pppoe link&#39;s MTU.</p>
> <p dir=3D"ltr">I think that tends to be a better option than just trying to=
>  use TCP MSS hacking because the Internet isn&#39;t just carrying TCP, and =
> as I mentioned, I wonder how smart=C2=A0 implementations are when the TCP h=
> eader isn&#39;t directly behind the IP header.</p>
> <p dir=3D"ltr">This was in part why I was wondering if you&#39;d measured b=
> locking of ICMP PTBs for IPv6. We know it is happens for IPv4, but I wonder=
> ed whether it is happening to the same extent with IPv6.<br></p>
> <p dir=3D"ltr">&gt; The security policies on network boundaries used by eve=
> ry carrier is not consistent and thus leads to unpredictable behavior for P=
> MTUD type protocols running over Layer-3.<br>
> &gt; You raised an interesting point around RFC-4821 (PLPMTUD) - though I a=
> m not sure whether every host/application (and more specifically every IPv6=
>  host/application) would be making use of PLPMTUD ? <br>
> &gt; Is that something we are mandating for every IPv6 host/application?<br=
> >
> &gt;</p>
> <p dir=3D"ltr">I haven&#39;t done a lot of research into its support, howev=
> er Linux does support it but it defaults to bring off, and Windows supports=
>  it, and if I recall correctly, it resorts to using it if certain failures =
> occur.</p>
> <p dir=3D"ltr">It isn&#39;t something that applications request.</p>
> <p dir=3D"ltr">There are some more comments on it in this discussion.</p>
> <p dir=3D"ltr"><a href=3D"https://www.ietf.org/mail-archive/web/v6ops/curre=
> nt/msg19815.html">https://www.ietf.org/mail-archive/web/v6ops/current/msg19=
> 815.html</a></p>
> &gt; &gt; Assume there is a mobile/fixed carrier that uses TCP MSS adjustme=
> nts for its mobile/fixed line consumers in the IPv4 domain as follows:<br>
> &gt; &gt;<br>
> &gt; &gt; MTU =3D 1460 (assume that mostly works without any need for fragm=
> entation in IPv4 today)<br>
> &gt; &gt; TCP header =3D 20<br>
> &gt; &gt; IP header =3D 20<br>
> &gt; &gt;<br>
> &gt; &gt; TCP MSS =3D 1420<br>
> &gt; &gt;<br>
> &gt; &gt; In the IPv6 domain, we would have:<br>
> &gt; &gt;<br>
> &gt; &gt; MTU =3D 1460 - 20 - 40 (IPv6 standard header) =3D 1400B<br>
> &gt; &gt;<br>
> &gt; &gt; However what I am not clear on, is how to cater for presence of (=
> one or more) IPv6 extension headers on a packet.<br>
> &gt; &gt;<br>
> &gt; &gt; RFC-2460 talks about using PMTU or a minimum MTU of 1280 if PMTU =
> is not used<br>
> &gt; If you can&#39;t be confident of PMTUD working reliably then the only =
> truly safe option is an MTU of 1280.<br>
> &gt; &gt; However we have seen in the field that PMTU rarely gives us the r=
> ight measure of path-mtu (as some networks block ICMP messages across netwo=
> rk boundaries)<br>
> &gt; Have you measured this for IPv6, or are you just assuming it will be t=
> he same as IPv4?<br>
> &gt; &gt; Using a minimum MTU 1280 for calculating MSS may work but still t=
> wo questions arise here:<br>
> &gt; &gt; i. Will host/network not have to process too many packets if a sm=
> aller MSS is computed thus increasing overhead?<br>
> &gt; &gt; ii. Even if we used 1280 - 20 - 40 (1220B) for MSS, do we complet=
> ely address the presence of multiple maximum sized extension headers? - pro=
> bably not.<br>
> &gt; &gt;<br>
> &gt; &gt; The main question here would be whether presence of one or more e=
> xtension headers is something that needs to be subtracted from the actual a=
> vailable MSS for the host to use in its TCP communication? - or would that =
> be something that needs to be compensated for by measures like jumbo frame =
> support on both the host interfaces as well network interfaces ?<br>
> &gt;<br>
> &gt;<br>
> &gt;<br>
> &gt;<br>
> &gt; &gt;<br>
> &gt; Regards,<br>
> &gt; Mark.<br>
> &gt;<br>
> &gt;<br>
> &gt; &gt;<br>
> &gt; &gt; Rgds,<br>
> &gt; &gt; Usman<br>
> &gt;<br>
> &gt; &gt;<br>
> &gt; &gt; -----------------------------------------------------------------=
> ---<br>
> &gt; &gt; IETF IPv6 working group mailing list<br>
> &gt; &gt;<a href=3D"mailto:[email-masked]"> [email-masked]</a><br>
> &gt; &gt; Administrative Requests:<a href=3D"https://www.ietf.org/mailman/l=
> istinfo/ipv6"> https://www.ietf.org/mailman/listinfo/ipv6</a><br>
> &gt;<br>
> &gt; &gt; -----------------------------------------------------------------=
> ---<br>
> &gt; &gt;<br>
> &gt;<br>
> &gt;<br>
> </p>
> 
> --001a1143a3f0ca25f30521ef2b25--
> 
> 
> --===============7308620086717668270==
> --===============7308620086717668270==--
>

---

From: Usman Latif <[email-masked]>
Date: Tue, 13 Oct 2015 22:21:59 +0000 (UTC)

Hi Mark,
 Sent: Tuesday, 13 October 2015, 8:39
   
Hi Usman,On 12 Oct 2015 14:41, "Usman Latif" <[email-masked]> wrote:
> Be aware that TCP MSS hacking in the network is a hack, and isn't a solution to PMTUD issues that would impact UDP, IPsec, GRE, DCCP, SCTP etc.
> If the TCP header is behind EHs, I would wonder whether the TCP MSS hacking is going to be successful - is suspect many hardware implementations assume the TCP header is directly after the IP header, and perhaps assume the MSS option is also in the same location.
> You are better off making PMTUD work or never need to be used, by eliminating dumbbell MTU scenarios (<BIG><small><BIG> MTUs in path) (e.g. for PPPoE, supporting RFC4638), ensuring ICMP PTBs make it back to the packet originating hosts, or lowering the originating hosts' MTUs using the RA MTU option.
> Note that your hosts might support RFC4821 PMTUD which doesn't rely on ICMP PTBs.
>
> [[Usman]] How can one carrier ensures PMTUD works correctly across the global internet?Unfortunately you can't specifically ensure PMTUD works correctly over the Internet because it commonly relies on ICMP PTBs, and as you've said, some networks that are out of your control might block them.I think currently the best way to ensure PMTUD works is to not have to use it, by having hosts have MTUs that are small enough not to trigger it. Both IPv6 RAs and IPv4 DHCP can be used to lower host MTUs, or RFC4638 can be used to raise a pppoe link's MTU.I think that tends to be a better option than just trying to use TCP MSS hacking because the Internet isn't just carrying TCP, and as I mentioned, I wonder how smart  implementations are when the TCP header isn't directly behind the IP header.This was in part why I was wondering if you'd measured blocking of ICMP PTBs for IPv6. We know it is happens for IPv4, but I wondered whether it is happening to the same extent with IPv6.

[[Usman]] Few points come out of this:

Lowering host MTU too much may cause more packets per second overhead for the host and network elements - so ideally an MTU close to 1400 or 1500 bytes is what seems to be the going trend in IPv4 today
If we lower an IPv6 host MTU by many hundreds of bytes below that figure, are we not making the packet processing worse than what it is today with IPv4? - transition to IPv6 should appear more of something that makes packet processing better instead of making it worse? what u think.

This brings me back to the original point of header length estimation - assuming if we are not relying on PMTUD (or PLPMTUD), then in order to calculate an optimal host IPv6 MTU (in relation to IPv4), we can only do this based on a fixed size IPv6 header length of 40 bytes subtracted from what host MTU we believe *works* today for IPv4. However this estimation would not cater for presence of one of more extension headers(?) - and since the number and length of extension headers in a given packet could be variable- this does not seem to give us the right approach.

This is where my initial query was: whether the presence of one or more extension headers would be something we want a host OS to deal with either by having a feedback mechanism to vary the available payload size for applications running on the host in view of additional extension headers (i.e. when extension headers are being injected by source/host) OR would the host OS and network elements be expected to cater for this using jumbo frame support?

>I haven't done a lot of research into its support, however Linux does support it but it defaults to bring off, and Windows supports it, and if I recall correctly, it resorts to using it if certain failures occur.It isn't something that applications request.There are some more comments on it in this discussion.https://www.ietf.org/mail-archive/web/v6ops/current/msg19815.htmlRegards,

Mark.>
> If you can't be confident of PMTUD working reliably then the only truly safe option is an MTU of 1280.
> Have you measured this for IPv6, or are you just assuming it will be the same as IPv4?

---

From: Mark Andrews <[email-masked]>
Date: Wed, 14 Oct 2015 11:19:00 +1100

In message <[email-masked]>, Usm
an Latif writes:
> > implementations assume the TCP header is directly after the IP header,
> > and perhaps assume the MSS option is also in the same location.
> > packet originating hosts, or lowering the originating hosts' MTUs using
> > the RA MTU option.
> > [[Usman]] How can one carrier ensures PMTUD works correctly across the
> global internet?Unfortunately you can't specifically ensure PMTUD works
> correctly over the Internet because it commonly relies on ICMP PTBs, and
> as you've said, some networks that are out of your control might block
> them.I think currently the best way to ensure PMTUD works is to not have
> to use it, by having hosts have MTUs that are small enough not to trigger
> it. Both IPv6 RAs and IPv4 DHCP can be used to lower host MTUs, or
> RFC4638 can be used to raise a pppoe link's MTU.I think that tends to be
> a better option than just trying to use TCP MSS hacking because the
> Internet isn't just carrying TCP, and as I mentioned, I wonder how smart 
> implementations are when the TCP header isn't directly behind the IP
> header.This was in part why I was wondering if you'd measured blocking of
> ICMP PTBs for IPv6. We know it is happens for IPv4, but I wondered
> whether it is happening to the same extent with IPv6.
>
> Lowering host MTU too much may cause more packets per second overhead for
> the host and network elements - so ideally an MTU close to 1400 or 1500
> bytes is what seems to be the going trend in IPv4 today
> If we lower an IPv6 host MTU by many hundreds of bytes below that figure,
> are we not making the packet processing worse than what it is today with
> IPv4? - transition to IPv6 should appear more of something that makes
> packet processing better instead of making it worse? what u think.

PMTUD was about reducing fragmentation and reducing the packet count.

> This brings me back to the original point of header length estimation -
> assuming if we are not relying on PMTUD (or PLPMTUD), then in order to
> calculate an optimal host IPv6 MTU (in relation to IPv4), we can only do
> this based on a fixed size IPv6 header length of 40 bytes subtracted from
> what host MTU we believe *works* today for IPv4. However this estimation
> would not cater for presence of one of more extension headers(?) - and
> since the number and length of extension headers in a given packet could
> be variable- this does not seem to give us the right approach.

For any session the extension headers are almost alway fixed.  Just
account for them.

> This is where my initial query was: whether the presence of one or more
> extension headers would be something we want a host OS to deal with
> either by having a feedback mechanism to vary the available payload size
> for applications running on the host in view of additional extension
> headers (i.e. when extension headers are being injected by source/host)
> OR would the host OS and network elements be expected to cater for this
> using jumbo frame support?

TCP should always use what knowledge it has of the lower levels of
the stack.  Remember MSS is just a attempt to align TCP framing
with IP framing.

> > The security policies on network boundaries used by every carrier is
> >not consistent and thus leads to unpredictable behavior for PMTUD type 
> > support it but it defaults to bring off, and Windows supports it, and if
> > I recall correctly, it resorts to using it if certain failures occur.It
> > isn't something that applications request.There are some more comments on
> > it in this
> > discussion.https://www.ietf.org/mail-archive/web/v6ops/current/msg19815.ht
> > mlRegards,
>
>
> Mark.>
> > > However what I am not clear on, is how to cater for presence of (one
> > > or more) IPv6 extension headers on a packet.
> > >
> > > i. Will host/network not have to process too many packets if a
> > > smaller MSS is computed thus increasing overhead?
> > > extension headers is something that needs to be subtracted from the
> > > actual available MSS for the host to use in its TCP communication? - or
> > > would that be something that needs to be compensated for by measures like
> > > jumbo frame support on both the host interfaces as well network
> > > interfaces ?
> >
> >
> >
> >
> > >
> > Regards,
> > Mark.
> >
> >
> > >
> > > Rgds,
> > > Usman
> >
> > >