Date: Sat, 17 Sep 2022 10:17:58 +0200 From: <driesm@FreeBSD.org> To: "'Evilham'" <contact@evilham.com> Cc: <freebsd-net@freebsd.org> Subject: RE: PPPoE (mpd5) IPv6 issues Message-ID: <002a01d8ca6d$ff31cf10$fd956d30$@FreeBSD.org> In-Reply-To: <6b34c0b352f1e1a9d5787b948dc4262bcdc6@yggdrasil.evilham.com> References: <004701d8c9ea$63e10090$2ba301b0$@FreeBSD.org> <007d01d8c9eb$87a45120$96ecf360$@FreeBSD.org> <6b34c0b352f1e1a9d5787b948dc4262bcdc6@yggdrasil.evilham.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> -----Original Message----- > From: Evilham <contact@evilham.com> > Sent: Friday, 16 September 2022 22:00 > To: driesm@FreeBSD.org > Cc: freebsd-net@freebsd.org > Subject: Re: PPPoE (mpd5) IPv6 issues >=20 > Hey, >=20 > On dv., set. 16 2022, driesm@FreeBSD.org wrote: >=20 > > Hmm this mail was not finished, sorry about that. > > > > I will include the link that fell-off, IPv6 PPPoE MSS incorrect > > | Netgate Forum > > > > > > > > Any help or pointers are greatly appreciated! > > > > > > > > PS: I use IPFW as my firewall, if this has anything to do with it. I > > do have a =E2=80=9Creassemble all in=E2=80=9D rule at the top of my = ruleset > > > > > > > > From: driesm@FreeBSD.org <driesm@FreeBSD.org> > > Sent: Friday, 16 September 2022 18:36 > > To: freebsd-net@freebsd.org > > Subject: PPPoE (mpd5) IPv6 issues > > > > > > > > Hi freebsd-net! > > > > > > > > After a lot of google and tinkering I have hit a brick wall trying = to > > set-up my new ISP which uses PPPoE. > > > > I=E2=80=99m at the point where IPv4 works fine 100% for all = websites. > > But from the moment I turn on IPv6 all sites that prefer IPv6 stop > > working, I have confirmed that routing table etc all look good. So = I=E2=80=99m > > more suspicious to a MTU / MSS issue. > > > > Although I cant find that much info about it. I have tcpmss fix = turned > > on in my mpd.conf > > > > > > > > There seems to be a few sites like google.com and youtube.com that > > keep working. > > > > > > > > I have googled thoroughly but I was unable to find a fix for my > > problem. The one close to my issue seems this issue from 2020: >=20 >=20 > Some things to take into account are: MTU of the physical interface = and > ICMP blackholes, see below. >=20 > For the MTU of the physical interface, take into account that if a = VLAN and > PCP (vlan(4)+ifconfig(8)) are required by the wholesale provider, = those > consume 4 bytes each and taking PPPoE's 8 bytes into account as well, = your > physical interface should have a higher MTU (4 bytes for VLAN + 4 = bytes for > PCP + 8 bytes for PPPoE =3D 16 bytes overhead on physical interface) = than the > connection (I'd guess one of 1500, 1492 or 1484 depending on the = wholesale > provider and the ISP). >=20 >=20 > Basically, from the router if the interface created by mpd5 has an MTU = of > 1500, you should be able to: >=20 > ping -6D -s 1452 ipv6.icmp.host >=20 > With -6D being "do not fragment" > And 1452 bytes being the payload =3D > 1500 bytes - 40 bytes from IPv6 headers - 8 bytes for ICMP > header >=20 >=20 > And you **should** receive a "ping: sendmsg: Message too long" > with: >=20 > ping -6D -s 1453 ipv6.icmp.host >=20 >=20 > When in doubt, try: > ping -6D -s 1232 ipv6.icmp.host > This should work since 1280 bytes is the minimum MTU for IPv6 and > gradually go up to establish what the maximum MTU for your > connection is being. Thanks a lot for the troubleshooting steps! After trying this I identified the max ping size to be 1444 bytes. 1445 bytes results in message too long. This was both the case on the = router as one of the clients (windows), so consistency seems good here. This was with ng0 configured on the standard 1492 bytes MTU. All my other physical interfaces are on the standard 1500 MTU. Now how do I translate this info to getting IPv6 to work reliably?=20 Which MTU should I tweak? LAN side or WAN side? Dries >=20 >=20 > If you don't receive the "Message too long" with way too large > packets, there might be a bit of an ICMP blackhole on the ISP side > or on the route to the ipv6.icmp.host. >=20 > This is usually not too tragic for IPv4 because routers do the > fragmenting magic, but it is terrible for IPv6 since it is the > client that has to fragment, and for that it needs to receive the > "Message too long" ICMP response. >=20 > By using tcpdump on the router, convince yourself truly that it is > not *you* dropping all incoming ICMP! If you see the ICMP "message > too long" packets arrive and they are not forwarded, the issue is > on your side, time to check the firewall. >=20 > If you are 100% sure your side is right, it might be on the ISP > side; we actually had this issue until recently in our associative > ISP and we have seen large commercial providers have issues with > this as well (IPv6 not widely adopted around here). >=20 > A workaround was to announce locally a lower MTU for IPv6 with > rtadvd(8). > Over time that proved to be an issue on Windows hosts, which > didn't seem to handle well a different MTU for IPv4 and IPv6, so I > ended up announcing the lower MTU internally for both stacks > temporarily (using DHCP for v4). >=20 > Hope that helps and wasn't too all over the place, this is memory > talking here :-D. >=20 > Cheers, > -- > Evilham
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?002a01d8ca6d$ff31cf10$fd956d30$>