Subject: Re: NAT vs PMTU-D
To: None <tech-net@NetBSD.org>
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
Date: 04/17/2006 09:20:59
>> - ip_output calls icmp_error
> I don't see how ip_output() would call icmp_error() itself. If the
> packet size exceeds MTU and can't be fragmented, ip_output() simply
> drops the packet and returns EMSGSIZE to ip_forward(). It is
> ip_forward() that calls icmp_error() when ip_output() returned an
Yes, I miswrote.
> But ip_forward() makes a copy of the packet (header) before calling
> ip_output() on the original packet. If it later does generate an
> ICMP error, it is based on that copy. Since the copy is
> pre-ip_output(), it is not NATed, and the ICMP error should not refer
> to the NATed packet at all.
Hm, that's true. (And - I just checked - it's equally true of the
source I've been working with, so this isn't just a version issue.)
> So, I'm puzzled at how you can actually see what you describe.
Well, I put a debugging printf in icmp_reflect, and the reflected
packet is being passed to ip_output with ip_src set to the "inside"
address of the gateway and ip_dst set to the "outside" address, as
You're right that I got myself confused about input and output NAT
processing; this theory doesn't look as plausible in view of the code
as it did when I wrote that last night (ENOSLEEP or some such). But
I'm not sure how to explain the addresses the packet bears, then. I
suppose I need to throw in a bunch more debugging info.
> Are you doing some encapsulation, where NAT happens on the
> decapsulated layer and MTU fails on the encapsulated layer or
> something like that?
I would be, except that I set the MTU on the decapsulated interface as
appropriate to compensate. (Think userland PPPoE and you'll be close
enough for these purposes.)
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML firstname.lastname@example.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B