Subject: [tsvwg] Please tell us of any topics you would like to see discussed by TSVWG at the Montreal IETF

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 07 Jun 2018 11:11:11 +0100

Hi TSVWG'ers,

This is a request for people with any new topics that you may wish to presented to the TSVWG working group at the Montreal IETF. If you edit a WG draft and believe you do *NOT* need to present, please also do let us know.

Priority, as ever will be given to drafts that have been discussed on the list and which are expected to benefit from WG discussion time. Please tell the chairs if you would like to present, but also you should also make sure to discuss the draft on the list prior to this meeting.

Gorry, David and Wes
(TSVW Co-Chairs)

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 7 Jun 2018 12:42:47 +0200 (CEST)

On Thu, 7 Jun 2018, Gorry Fairhurst wrote:

> Priority, as ever will be given to drafts that have been discussed on 
> the list and which are expected to benefit from WG discussion time. 
> Please tell the chairs if you would like to present, but also you should 
> also make sure to discuss the draft on the list prior to this meeting.

I would like to see if we can progress the whole "IP fragmentation doesn't 
always work, and perhaps applications should avoid to use fragmentation, 
and btw, MTU-blackhole is a thing, so PLPMTUD is something protocols 
should do"-discussion.

I will not be on-site, but in discussions on this topic some have said 
that they'd like TSVWG to publish documents on the topic.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Joe Touch <[email-masked]>
Date: Thu, 7 Jun 2018 07:13:00 -0700

> On Jun 7, 2018, at 3:42 AM, Mikael Abrahamsson <[email-masked]> wrote:
> 
> I would like to see if we can progress the whole "IP fragmentation doesn't always work, and perhaps applications should avoid to use fragmentation, and btw, MTU-blackhole is a thing, so PLPMTUD is something protocols should do"-discussion.
> 
> I will not be on-site, but in discussions on this topic some have said that they'd like TSVWG to publish documents on the topic.

I won’t be there either.

The real issue is that IP fragmentation is absolutely necessary and must be supported as long as:

	a) IP has a maximum packet size
	b) IP-in-IP is a key part of IETF protocols (it is, both for native overlays and IPsec tunnel mode)

So applications can *try* to avoid fragmentation, but ultimately doing so means there will never be a “smallest safe maximum packet size”.

IMO, the only useful conclusions are:
	1) routers MUST support IP fragmentation 
	2) DPI devices MUST reassemble those fragments; this isn’t a violation of “routers must not reassemble) though
	3) apps can try to avoid needing 1) and 2), but that’s all they can do - try. they can’t strictly avoid it

Note that this is already covered in draft-ietf-intarea-tunnels

Joe

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 7 Jun 2018 16:28:47 +0200 (CEST)

> Note that this is already covered in draft-ietf-intarea-tunnels

Are you saying there is no more work to be done here?

---

From: Joe Touch <[email-masked]>
Date: Thu, 7 Jun 2018 07:39:33 -0700

> On Jun 7, 2018, at 7:28 AM, Mikael Abrahamsson <[email-masked]> wrote:
> 

I’d suggest looking at what has already been done first. If there is a proposal to remove IP fragmentation for upper layers, it needs to start with how to address IP-IP tunnels in general and IPsec tunnel mode in specific first.

Simply saying “it isn’t deployed, so let’s change the app behavior” ignores an important alternative - call out the vendors who fail to support existing (necessary, based on that draft) requirements.

Joe

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 8 Jun 2018 06:13:45 +0200 (CEST)

On Thu, 7 Jun 2018, Joe Touch wrote:

> I’d suggest looking at what has already been done first. If there is a 
> proposal to remove IP fragmentation for upper layers, it needs to start 
> with how to address IP-IP tunnels in general and IPsec tunnel mode in 
> specific first.

The proposal is not to remove IP fragmentation, the proposal is to tell 
applications that in real life, IP fragmented packets have a worse 
delivery rate, and that applications should avoid using IP fragmentation 
where possible.

> Simply saying “it isn’t deployed, so let’s change the app behavior” 
> ignores an important alternative - call out the vendors who fail to 
> support existing (necessary, based on that draft) requirements.

I don't see IP fragmentation working perfectly being an realistic 
operational possibility in the near future (it never has, historically), 
and applications should avoid using it, or at least have a fallback mode 
in cases where it doesn't work. "Limp mode" or something.

---

From: Joe Touch <[email-masked]>
Date: Thu, 7 Jun 2018 21:25:46 -0700

> On Jun 7, 2018, at 9:13 PM, Mikael Abrahamsson <[email-masked]> wrote:
> 
> I don't see IP fragmentation working perfectly being an realistic operational possibility in the near future (it never has, historically), and applications should avoid using it, or at least have a fallback mode in cases where it doesn't work. "Limp mode" or something.

If you were to swap fragmentation with ‘v6’ would it be equally true?

That should give a sense of why I consider such a position not particularly productive. 

Joe

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 8 Jun 2018 07:47:14 +0200 (CEST)

> That should give a sense of why I consider such a position not particularly productive.

We invented Happy Eyeballs to get people to deploy IPv6, because it worked 
around defective IPv6 networks. I want a similar mechanism for PMTU 
blackholes and fragmentation being broken.

Happy Eyeballs has proven to be extremely productive, there are numerous 
players who have said they would otherwise not have deployed IPv6.

---

From: Joe Touch <[email-masked]>
Date: Thu, 7 Jun 2018 23:10:07 -0700

> On Jun 7, 2018, at 10:47 PM, Mikael Abrahamsson <[email-masked]> wrote:
> 
> We invented Happy Eyeballs to get people to deploy IPv6, because it worked around defective IPv6 networks. I want a similar mechanism for PMTU blackholes and fragmentation being broken.
> 
> Happy Eyeballs has proven to be extremely productive, there are numerous players who have said they would otherwise not have deployed IPv6.

Happy Eyeballs still tries to use IPv6. A focus on ways around the use of IP fragmentation would be the equivalent of abandoning IPv6 - because nobody gets it right and we’ve been waiting for a fix for years.

That’s the point - we need to recognize that fragmentation is a critical capability that needs to be supported - not declared “OBE” simply because it’s insufficiently profitable. 

Joe

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 8 Jun 2018 08:40:55 +0200 (CEST)

On Thu, 7 Jun 2018, Joe Touch wrote:

> Happy Eyeballs still tries to use IPv6. A focus on ways around the use 
> of IP fragmentation would be the equivalent of abandoning IPv6 - because 
> nobody gets it right and we’ve been waiting for a fix for years.

I don't know what you think I am trying to do here, but it's not that.

These is what I want to end up with:

Networks must support IP fragmentation.
Networks must support PMTUD.
Applications must work when IP fragmentation does not work.
Applications must work when there is PMTU blackhole.

I don't care if the applications turns the check engine light on and goes 
into limp mode with 1/10th the performance. But they should still work, 
somewhat. This is not the case today.

---

From: Vincent Roca <[email-masked]>
Date: Fri, 8 Jun 2018 14:17:03 +0200

Hi Gorry et al.,

I suggest topic that is closely related to what Joe/Mikael exchange: about the minimum guaranteed MTU on a link (i.e., the 576 or 1280 limit).
This is a discussion I wanted to bring, especially as it has connections to the UDP PLPMTU I-D, but haven’t found time till now...

The question is what happens if, for a good or bad reason (e.g., an attack), a router that is a tunnel entry point, is already limited to this 576 or 1280 size on its outgoing link?
How will a client whose packets need to go through this tunnel behave after receiving PTB ICMP error messages with a suggested MTU lower than 576/1280?
The quick answer is: « a big mess », with either a DoS, or major performance issues, sometimes after a long freeze period (we measured up to 7 min).

Of course the detailed behaviour depends on the use of TCP vs. UDP, PMTUd vs. PLPMTU, IPv4 vs. IPv6, Ubuntu vs. W7.
We tried to explore all of this through an exploit. The two articles below exhibit an IPsec and IP-in-IP attack that relies on this principle, but the underlying problem
is of course independent of the tunnel nature.

- The initial work:
L. Jaqcuin, V. Roca, J-L. Roch, ``Too Big or Too Small? The PTB-PTS ICMP-based Attack against IPsec Gateways'', IEEE Global Communications Conference (GLOBECOM'14), December 2014. http://hal.inria.fr/hal-01052994/en/ <http://hal.inria.fr/hal-01052994/en/>, (slides, PDF) <http://www.inrialpes.fr/planete/people/roca/doc/slides_globecom14_ptb_pts_attack_interactive_session.pdf>.

- An update with many additional configurations tested (you can look at these slides for a good introduction to the problem):
V. Roca, L. Jacquin, S. Fall, J-L. Roch, ``New Results for the PTB-PTS Attack on Tunnelling Gateways'', GreHack 2015, November 2015. https://hal.inria.fr/hal-01245629/en/ <https://hal.inria.fr/hal-01245629/en/>, (slides, PDF) <http://www.inrialpes.fr/planete/people/roca/doc/GreHack15_ptb_pts_attack_VR.pdf>.

- We tried to discuss it at IPSECME a few years ago but didn’t find any echo:
V. Roca, S. Fall, ``Too Big or Too Small? The PTB-PTS ICMP-based Attack against IPsec Gateways'', IETF IP Security Maintenance and Extensions (IPSECME) Working Group, work in progress, July 2015. 
https://datatracker.ietf.org/doc/draft-roca-ipsecme-ptb-pts-attack/ <https://datatracker.ietf.org/doc/draft-roca-ipsecme-ptb-pts-attack/>

If the group considers it’s a topic of interest, I can update the I-D (perhaps focussing more on the min guaranteed MTU and strange situations it can create than on
the attack itself) and discuss it during next IETF meeting.

Cheers,

  Vincent

---

From: Joe Touch <[email-masked]>
Date: Fri, 8 Jun 2018 08:18:49 -0700

> On Jun 8, 2018, at 5:17 AM, Vincent Roca <[email-masked] <mailto:[email-masked]>> wrote:
> 

See draft-ietf-intarea-tunnels.

First, outgoing link *requirements* are 64 and 1280 (576 is a receiver *reassembly* requirement for IPv4, just as is 1500 for IPv6).

Second, the tunnel ingress, which adds the header, is always responsible for ensuring that those limits can be supported - otherwise the tunnel isn’t IPv4 (or IPv6) anymore. That means the ingress MUST fragment at the outer header level and the egress MUST reassemble.

You can argue that these are inefficient, impractical, - whatever. But they are REQUIRED by the current IP minimums for link MTU. Merely having such a minimum, coupled with an upper bound on packet size, means these rules will ALWAYS come into play, regardless of what they are.

An interesting contrast is Ethernet. With VLAN extensions, Ethernet actually has NO upper bound on packet size - the upper layer payload is 1500, but the headers can have an unlimited number of nested VLAN tags - and adding those tags has no impact on that payload size. 

So either (strictly) your device buffers could be unbounded or you need to do frag/reassembly when you tunnel. Those are the only choices.

Joe

---

From: Joe Touch <[email-masked]>
Date: Fri, 8 Jun 2018 08:20:13 -0700

> On Jun 7, 2018, at 11:40 PM, Mikael Abrahamsson <[email-masked]> wrote:
> 

These are fine - as long as they are ALL reflected in the doc title, abstract, intro, discussion, and recommendations.

That has not been my experience with any of the drafts in this area I’ve seen - including a few very recent ones.

Joe

---

From: Tom Herbert <[email-masked]>
Date: Fri, 8 Jun 2018 09:57:00 -0700

On Thu, Jun 7, 2018 at 11:10 PM, Joe Touch <[email-masked]> wrote:

> > We invented Happy Eyeballs to get people to deploy IPv6, because it
> worked around defective IPv6 networks. I want a similar mechanism for PMTU
> Happy Eyeballs still tries to use IPv6. A focus on ways around the use of
> IP fragmentation would be the equivalent of abandoning IPv6 - because
> That’s the point - we need to recognize that fragmentation is a critical
> capability that needs to be supported - not declared “OBE” simply because
> it’s insufficiently profitable.
>
+1

The suggestion that IP fragmentation should be generally avoided seems like
overreach to me. There are definitely cases where fragmentation is in use
today and is a perfectly fine solution for those deployments. Grant it,
these are often situations where the network over which fragementation is
being used doesn't have middleboxes that are inspecting the transport layer
and get confused when presented with IP fragments.

Tom

---

From: Vincent Roca <[email-masked]>
Date: Tue, 12 Jun 2018 13:40:43 +0200

Hello Joe, all

You’re right, I’ve been confused by the erroneous variable name in Linux:
	$ cat /proc/sys/net/ipv4/route/min_pmtu
	552
This is not a minimum PMTU but, as you say, a receiver *reassembly* requirement for IPv4 (i.e., the minimum EMTU_R following your I-D terminology).
(NB: I think it’s fixed with Linux/IPv6 since we now have a /proc/sys/net/ipv6/route/min_adv_mss variable, which returns 1220)

That being said, the real world issues remain:

- with PMTUd and IPv4, a Linux or Windows7 host that receives an ICMP PTB with an advertised value 502 (i.e. 576 minus various headers) refuses to comply.
  This should not be the case since having a link limited to a 68 bytes MTU on the path is valid. Do you agree?

- with the Linux IPsec implementation we used, the tunnel ingress refuses to fragment packets whose DF bit is set (idem for IPIP).
  If I understand, this should not be the case when this decision prevents the tunnel ingress to comply with the 64 and 1280 min PMTU requirements. Do you agree?

- the tunnel ingress should accept to use a PMTU as low as 68 bytes with IPv4. Instead, we observe that the tunnel ingress does not go below 576 bytes.
  If I understand this should not be the case. Do you agree? 

There’s theory (and your I-D is highly valuable, as I already told you some time ago) and practice.
I do not argue that fragmentation/reassembly is "inefficient, impractical, - whatever", I’m just observing what happens (I should say happened 3 years ago, I haven’t
tried recently).
A conclusion could be that the IPsec and IPIP implementations we used, as well as Linux and W7 are all broken, for various reasons. In that case it’s a matter of
fixing bugs. But the question is in fact pretty complex and it’s not surprising to see some confusion in the developer’s mind (and sometimes in my mind too).

Another important aspect is that PLPMTU / TCP turned out to be much more robust (after 3 to 6 second delay, a working MSS was found, although not perfect),
hence my support to draft-ietf-tsvwg-datagram-plpmtud as being part of the solution. This is no theory nor interpretation, but pure observation.

--
NB: there is a wrong reference in draft-ietf-intarea-tunnels-08, section "4. IP Tunnel Requirements », first paragraph.
	Instead of: « 	i.e., 68 bytes for IPv4 [RFC793]… » it should be [RFC791].

Thanks for the feedback.
Cheers,

  Vincent

> Le 8 juin 2018 à 17:18, Joe Touch <[email-masked]> a écrit :
>

---

From: Joe Touch <[email-masked]>
Date: Tue, 12 Jun 2018 07:32:37 -0700

Hi, Vincent,

> On Jun 12, 2018, at 4:40 AM, Vincent Roca <[email-masked]> wrote:
> 
> Hello Joe, all
> 

Equally importantly, why is it 552? IPv6 reassembly requires a min of 576, which would be 556 assuming a default IPv4 header. Was this adjusted to account for a 4-byte IPv4 option? If so, which one?

And what does 1220 represent? For IPv6, it’s required to be *1500*, not 1280 - and if 1280, that would represent an IPv6 base header and 20 bytes of options… again, which ones?

I.e., both look either incorrect in value or name.

> - with PMTUd and IPv4, a Linux or Windows7 host that receives an ICMP PTB with an advertised value 502 (i.e. 576 minus various headers) refuses to comply.

PTB isn’t supposed to exclude IP or any other headers (L3 or above). From RFC 1191:

          ...                             The size includes the IP
          header and IP data, and does not include any lower-level
          headers.

>   This should not be the case since having a link limited to a 68 bytes MTU on the path is valid. Do you agree?

Strictly, yes.

>   If I understand, this should not be the case when this decision prevents the tunnel ingress to comply with the 64 and 1280 min PMTU requirements. Do you agree?

It is NEVER appropriate to ignore the DF bit in a packet and fragment *at that level*.

In cases when the encapsulated packet is too large to support the minimum path MTU required (which is 68 for IPv4, not 64 — and 1280 for IPv6), the ingress MUST fragment the encapsulated packet - which is not prohibited by a flag on the header of its *payload* IP.

>   If I understand this should not be the case. Do you agree? 

An ingress that claims to support use of IPv4 MUST support the minimums IPv4 allows, yes.

> fixing bugs. But the question is in fact pretty complex and it’s not surprising to see some confusion in the developer’s mind (and sometimes in my mind too).

I am never surprised when I see implementation errors (including, FWIW, my own). That just means they need to be fixed.

> hence my support to draft-ietf-tsvwg-datagram-plpmtud as being part of the solution. This is no theory nor interpretation, but pure observation.

My concern is that all of our docs need to reaffirm the fact that fragmentation is an important part of IP that must not be ignored. Making things robust to errors everywhere can be useful, but also can lead to protocols that try to infer intended behavior - which is a recipe for disaster.

When we find a bug, we need to call it out and fix it. We shouldn’t be designing protocols to adapt to bugs.

Again, as above, I’m not surprised - but I intend to fix that, not to author an RFC that encourages everyone in the community to consider whether RFC 791 was intended when RFC 793 is cited. That’s the issue with work-arounds to the lack of fragmentation support - we need to make sure they do not undermine the position that fragmentation must be supported in a device that claims IP protocol compliance.

Joe

> 
> Thanks for the feedback.
> Cheers,
> 
>   Vincent
> 
> 
>> Le 8 juin 2018 à 17:18, Joe Touch <[email-masked] <mailto:[email-masked]>> a écrit :
>>

---

From: Vincent Roca <[email-masked]>
Date: Wed, 13 Jun 2018 14:14:43 +0200

Hello Joe,

So it seems these situations exhibit mistakes/bugs in certain default values and behaviours.
I agree that designing protocols to circumvent bugs is not the right approach. So we need to fix them
(even if in the meantime PLPMTUd remains a good way to mitigate problems ;-)

IMHO in order to go forward we need to:
- exhibit these erroneous situations (eg. through packet captures);
- justify why it's inappropriate via analyses and references to RFCs and your I-D.
  The question is often complex, information spread in various documents (your I-D is an exception),
  and I will not blame developers.

Your comment on the validity of the 552 and 1220 values is meaningful.
Are those (magic) values the best choice (from Linux source code it seems that 552 = 512 + 20 + 20)?
Will it still be the case tomorrow (new protocol options may lead to a different header size)?
Is the algorithmic part associated to these variables correct?

I’ve just found a discussion on a close topic:
		https://www.systutorials.com/linux-kernels/500762/
And also this one (easier to understand and agree on):
		https://www.systutorials.com/linux-kernels/157211
Both of them are very recent (March and May 2018), showing work in progress in Linux kernel. That’s a
good opportunity.

We can do something similar with other topics...

Cheers,

 Vincent

> Le 12 juin 2018 à 16:32, Joe Touch <[email-masked]> a écrit :
> 
> Hi, Vincent,
> 
>> On Jun 12, 2018, at 4:40 AM, Vincent Roca <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hello Joe, all
>>

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 13 Jun 2018 07:35:10 -0500

I'm sure that a number of people on this list remember the TCPIMPL working
group (now concluded), and I'm betting that a number of people don't
remember TCPIMPL.

> We can do something similar with other topics...

I had JUST started at IETF when TCPIMPL was working on what was eventually
published as https://tools.ietf.org/html/rfc2525, so was remembering the
format for these kinds of reports on implementation problems, and had
forgotten that https://tools.ietf.org/html/rfc2923 was published
separately, focusing entirely on TCP problems with PMTU discovery.

It's possible that using these documents as templates to record problems
that the transport community is seeing today would be helpful.

Spencer, speaking as a reminiscing individual ...

Cheers,
> This is not a minimum PMTU but, as you say, a receiver *reassembly*
> requirement for IPv4 (i.e., the minimum EMTU_R following your I-D
> terminology).
> (NB: I think it’s fixed with Linux/IPv6 since we now have a
> /proc/sys/net/ipv6/route/min_adv_mss variable, which returns 1220)
>
>
> Equally importantly, why is it 552? IPv6 reassembly requires a min of 576,
> which would be 556 assuming a default IPv4 header. Was this adjusted to
> account for a 4-byte IPv4 option? If so, which one?
>
> And what does 1220 represent? For IPv6, it’s required to be *1500*, not
> 1280 - and if 1280, that would represent an IPv6 base header and 20 bytes
> of options… again, which ones?
>
> - with PMTUd and IPv4, a Linux or Windows7 host that receives an ICMP PTB
> with an advertised value 502 (i.e. 576 minus various headers) refuses to
> comply.
>
>
> - with the Linux IPsec implementation we used, the tunnel ingress refuses
> to fragment packets whose DF bit is set (idem for IPIP).
>
>   If I understand, this should not be the case when this decision prevents
> the tunnel ingress to comply with the 64 and 1280 min PMTU requirements. Do
> you agree?
>
>
> In cases when the encapsulated packet is too large to support the minimum
> path MTU required (which is 68 for IPv4, not 64 — and 1280 for IPv6), the
> ingress MUST fragment the encapsulated packet - which is not prohibited by
> a flag on the header of its *payload* IP.
>
>
> - the tunnel ingress should accept to use a PMTU as low as 68 bytes with
> IPv4. Instead, we observe that the tunnel ingress does not go below 576
> bytes.
> I do not argue that fragmentation/reassembly is "inefficient, impractical,
> - whatever", I’m just observing what happens (I should say happened 3 years
> ago, I haven’t
> tried recently).
> A conclusion could be that the IPsec and IPIP implementations we used, as
> well as Linux and W7 are all broken, for various reasons. In that case it’s
> a matter of
> fixing bugs. But the question is in fact pretty complex and it’s not
> surprising to see some confusion in the developer’s mind (and sometimes in
> my mind too).
>
>
> I am never surprised when I see implementation errors (including, FWIW, my
> own). That just means they need to be fixed.
>
> Another important aspect is that PLPMTU / TCP turned out to be much more
> robust (after 3 to 6 second delay, a working MSS was found, although not
> perfect),
> *hence my **support to draft-ietf-tsvwg-datagram-plpmtud* as being part
> of the solution. This is no theory nor interpretation, but pure observation.
>
>
> My concern is that all of our docs need to reaffirm the fact that
> fragmentation is an important part of IP that must not be ignored. Making
> things robust to errors everywhere can be useful, but also can lead to
> protocols that try to infer intended behavior - which is a recipe for
> disaster.
>
> NB: there is a wrong reference in draft-ietf-intarea-tunnels-08, section
> "4. IP Tunnel Requirements », first paragraph.
> Again, as above, I’m not surprised - but I intend to fix that, not to
> author an RFC that encourages everyone in the community to consider whether
> RFC 791 was intended when RFC 793 is cited. That’s the issue with
> work-arounds to the lack of fragmentation support - we need to make sure
> they do not undermine the position that fragmentation must be supported in
> a device that claims IP protocol compliance.
>
> Joe
>
>
> Thanks for the feedback.
> Cheers,
>
>   Vincent
>
>
> On Jun 8, 2018, at 5:17 AM, Vincent Roca <[email-masked]> wrote:
>
> The question is what happens if, for a good or bad reason (e.g., an
> attack), a router that is a tunnel entry point, is already limited to this
> 576 or 1280 size on its outgoing link?
> How will a client whose packets need to go through this tunnel behave
> after receiving PTB ICMP error messages with a suggested MTU lower than
> 576/1280?
> The quick answer is: « a big mess », with either a DoS, or major
> performance issues, sometimes after a long freeze period (we measured up to
> 7 min).
>
>
> First, outgoing link *requirements* are 64 and 1280 (576 is a receiver
> *reassembly* requirement for IPv4, just as is 1500 for IPv6).
>
> Second, the tunnel ingress, which adds the header, is always responsible
> for ensuring that those limits can be supported - otherwise the tunnel
> isn’t IPv4 (or IPv6) anymore. That means the ingress MUST fragment at the
> outer header level and the egress MUST reassemble.
>
> You can argue that these are inefficient, impractical, - whatever. But
> they are REQUIRED by the current IP minimums for link MTU. Merely having
> such a minimum, coupled with an upper bound on packet size, means these
> rules will ALWAYS come into play, regardless of what they are.
>
> An interesting contrast is Ethernet. With VLAN extensions, Ethernet
> actually has NO upper bound on packet size - the upper layer payload is
> 1500, but the headers can have an unlimited number of nested VLAN tags -
> and adding those tags has no impact on that payload size.
>
> So either (strictly) your device buffers could be unbounded or you need to
> do frag/reassembly when you tunnel. Those are the only choices.
>
> Joe
>
>
>
>
>

---

From: Joe Touch <[email-masked]>
Date: Wed, 13 Jun 2018 08:03:26 -0700

Hi, Vincent,

> On Jun 13, 2018, at 5:14 AM, Vincent Roca <[email-masked]> wrote:
> 
> Hello Joe,
> 

Agreed...

> Are those (magic) values the best choice (from Linux source code it seems that 552 = 512 + 20 + 20)?

On deeper check, according to: https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt <https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt>

   min_pmtu - INTEGER
	default 552 - minimum discovered Path MTU
That implies this value is a the **sender-side** value, i.e., the value the sender uses as the PMTU until told otherwise.

I.e., this is not the receiver reassembly MTU, so it’s OK that it falls below 576. As the sender’s assumption of PMTU (i.e., before hearing otherwise), the value should never fall below 68, but there’s no strict rule that the sender is required to try to use the full 576 either.

It also means that packets that end up being encapsulated by IP once will also still fit in the min MTU of the tunnel.

The IPv6 value seems like it deliberately makes room for those sort of tunnels as well.

This just means (if accurate) it isn’t a bug at all, but the choice of value and meaning could be made more clear in the documentation.

FWIW.

Joe

> 		https://www.systutorials.com/linux-kernels/500762/ <https://www.systutorials.com/linux-kernels/500762/>
> 		https://www.systutorials.com/linux-kernels/157211 <https://www.systutorials.com/linux-kernels/157211>
>> Le 12 juin 2018 à 16:32, Joe Touch <[email-masked] <mailto:[email-masked]>> a écrit :
>> 
>> Hi, Vincent,
>>