tech-net archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: IPV6 router works, but clients fail



Miles Nordin wrote:
"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?

Thanks for the explanation.

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

My understanding is that only works on the router and not the ones connected by NAT. I think I'll go with the 1492 MTU everywhere as it's the less "hackish" and would make any box behind my broken modem behave better to the outside.

Maybe I'll look into allowing NetBSD to use the MTU as advertised by rtadvd as it currently ignores it.

Thanks

Roy


Home | Main Index | Thread Index | Old Index