"rm" == Roy Marples <roy%marples.name@localhost> writes:
rm> So what is the problem?
If you're having the same problem as Matthias, it is that some router
in the to-you direction is accepting packets on a 1500 interface,
forwarding them onto a 1492 interface, and not sending the ICMP
'too-big' message when a packet that won't fit comes along---instead
just dropping it.
Routers never fragment because on IPv6 it is a rule that only
end-systems fragment, and on IPv4 all TCP packets have the DF bit set.
so their correct behavior for TCP is always drop and send ICMP
frag-needed/too-big.
The usual ``PPPoE problem'' is that a router DOES send this message,
but some moron's firewall is configured to block all the ICMP the
sysadmin doesn't understand, which is basically everything.
Matthias was saying in his case, he thinks the guilty party is his DSL
modem translating from PPPoA (1500) to PPPoE (1492), but doing so as
some silly-hack route-bridge thing with no IP address of its own so it
couldn't send an ICMP. (I don't really see why not---it breaks every
other sane behavior, so why not spoof an ICMP from any address it has
handy, yours, the other side's, whatever). but that's the theory, and
why I say, can you replace the modem?
I've never heard of PPPoA to PPPoE translation before though. I've
heard of a PPPoA router. And I have the BroadXtent modem, a PPPoE
route-bridge-thing that routes without having an IP for itself, but it
spits out clear unencapsulated packets.
rm> rtadvd
rm> 1492.
rm> Linux
rm> Works like a champ.
rm> NetBSD ignores (or seems to) the MTU in the IPv6 RA.
There is a line of reasoning:
routing may be asymmetric, so TCP should not assume the MTU is the
same in both directions, and shouldn't give the other end's mss based
on the MTU of a direct-attached interface for the opposite direction,
and instead let the other side figure out the MTU using PMTU-D.
There's a sysctl to change this
net.inet.tcp.mss_ifmtu = 1
net.inet6.tcp6.mss_ifmtu = 1