Subject: Re: [BEHAVE] NAT6 fragmentation discussion

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 4 Aug 2008 14:58:40 +0200

On 30 jul 2008, at 1:39, Dave Thaler wrote:

> That's why we have RFC 4890 ("Recommendations for Filtering ICMPv6
> Messages in Firewalls").  Section 4.3.1 ("Traffic That Must Not Be  
> Dropped")
> includes:

>>  o  Packet Too Big (Type 2)

> And also RFC 4821 ("Packetization Layer Path MTU Discovery")
> that specifies PMTU discovery for TCP without relying on ICMP.

RFC 4821 doesn't get anyone off the hook for filtering ICMP.

Are there _any_ implementations of 4821 available in the wild, let  
alone in common OSes?
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Mon, 4 Aug 2008 16:18:58 +0300

> RFC 4821 doesn't get anyone off the hook for filtering ICMP.

Not sure what you mean. But this is a real-life problem, e.g. when the "last 
mile" link uses PPPoE or PPPoA (MTU = 1492) and the LAN uses Fast Ethernet 
(MTU = 1500).

> Are there _any_ implementations of 4821 available in the wild, let

I believe Linux does not do it (for TCP), though it has explicit support for 
UDP(/UDP-Lite) applications to do it at layer-7.

However, NAT box typically do TCP MSS clamping. This works around the problem 
if the shortest MTU hop sits next to a TCP MSS clamping device and/or one of 
the end point. This is almost always true. If not true, "the Internet does 
not work" is a strong argument to make it true ;) Obviously, this only works 
for TCP, and will break with any other transport protocol, including UDP or 
UDP-encapsulated transport protocol.

-- 
Rémi Denis-Courmont
Maemo Software, Nokia Devices R&D
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 4 Aug 2008 15:55:06 +0200

> Not sure what you mean.

That you can't say "we can filter ICMP because there's RFC 4821" or  
"we can filter ICMP because we implement RFC 4821". (The other side  
may still depend on existing PMTUD.)

> However, NAT box typically do TCP MSS clamping.

Yes, we should probably specify reducing the advertised MSS for TCP in  
the NAT64 draft to accommodate for the difference in header size  
between IPv4 and IPv6.

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Mon, 4 Aug 2008 17:11:36 +0300

> may still depend on existing PMTUD.)

Ok. In principles, I have to agree that filtering ICMP is bad. And filtering 
Packet Too Big "violates" RFC4890 (which is however only _Informational_). In 
practice however, filtering ICMPv4 is common practice. Any NAT64 solution 
that fails to account for this will dramatically fail in real deployments.

> the NAT64 draft to accommodate for the difference in header size

The IPv6 end of the TCP session will negotiate a small enough MSS to account 
for the extra 20 bytes of IPv6 as part of its normal TCP stack operation.
MSS clamping is an ugly-but-functional hack in case of mismatching layer-2 
maximum frame payload sizes. It is not at all needed nor useful with regards 
to layer-3 mismatching packet payload sizes, as far as I can tell.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 5 Aug 2008 11:23:46 +0200

On 4 aug 2008, at 16:11, Rémi Denis-Courmont wrote:

> Packet Too Big "violates" RFC4890 (which is however only  
> _Informational_).

That's not relevant.

What's relevant is that the OS vendors have chosen to all enable PMTUD  
by default and set the DF bit on all packets. (The latter was the big  
mistake.) This means that filtering ICMP too bigs WILL break  
connectivity which is NOT acceptable.

For IPv6 it's impossible to set DF to zero as there is no DF bit and  
again, all implementers use PMTUD implicitly by sending packets larger  
than 1280 bytes. So again, filtering ICMP breaks connectivity and is  
therefore not acceptable.

Which means that all IETF standards and other documents MUST REQUIRE  
that ICMP too big messages are NOT filtered.

> In
> practice however, filtering ICMPv4 is common practice.

I know behave has a tradition of looking at what's out there in the  
real world, rather than what's in the standards, but in this case,  
that's not a workable choice.

> Any NAT64 solution

NAT64 is not the place to compensate for bad ICMP filtering practices,  
but it's certainly not the place to promote such practices, either.

That said, I'm not aware of anything in our draft (or any of the  
others) that would break in addition to "normal" PMTUD breakage.

> MSS clamping is an ugly-but-functional hack

I guess in practice it would normally work. For instance, if the v4  
side has a 1492-byte MTU so MSS = 1452 the IPv6 side will think it can  
send 1452 + 60 = 1512-byte packets but it will of course send 1500- 
byte IPv6 packets which will be translated into 1480-byte IPv4 packets  
so no problem.

But what if the v6 host and the translator support jumboframes and the  
v6 host sends 1512-byte packets? Or if the translator reassembles IPv6  
fragments before translating?

I think adjusting the MSS option in the v4->v6 direction makes the  
most sense here, and it would be good to implement a knob for  
operators to further reduce the MSS in both directions in the  
translator if desired.
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave