Ipv6 unusable due lack of love from FreeBSD (prev: Support baby jumbo frames)
-
Raising money does not seem to help :-[ If it does after all, I am willing to donate
In the Netherlands fiber connections are all PPPoE. Don't know for other countries, someone?
What/who is determing if (and when) it is implemented or not?
[/quote]PPPoE is an artifact left over from the days of dialup. Ethernet is already meant to be line rate, but now you have to add a PPPoE server and suddenly you're centralizing your contention. PPPoE has issues with high speed connections, like 1Gb and soon 10Gb. It can be done if you throw enough money at it, but that can be said of nearly anything.
-
It's supported by ISP (NL: xs4all) yes, but as far as I know not by pfSense.
Or do you mean it's also supported by pfSense?Yes, pfsense doesn't yet support RFC 4638. Meanwhile ipfire, untangle, openvpn, tomato etc works.
-
PPPoE is an artifact left over from the days of dialup. Ethernet is already meant to be line rate, but now you have to add a PPPoE server and suddenly you're centralizing your contention. PPPoE has issues with high speed connections, like 1Gb and soon 10Gb. It can be done if you throw enough money at it, but that can be said of nearly anything.
Yes you are correct. But that doesn't mean PPPoE is disappearing, or even shrinking.
-
As someone that works for a few ISPs…
Unfortunately no, PPPoE isn't going anywhere anytime soon. Especially with DSL services.Personally I dunno why they can't just use DHCP as it requires less from the generally "I just know how to turn it on and load porn" population.
Then again using PPPoE with Radius means it's easier to kick a connection offline or bring it back online -- so that is probably why they keep it.
-
Out of curiosity what issue are you seeing that this would solve?
Steve
-
In my browser (FF, IE and Chrome) some ipv6 pages did load very slow. After entering an MSS clamping value on the WAN interface of 1492 it load normally, but does not seem to me the way to solve this.
Also complying seems to me as a good thing (not an expert so can't value this)
-
Out of curiosity what issue are you seeing that this would solve?
Steve
Good question : ) The issue is fragmentation.
Normal PPPoE
Pinging 8.8.8.8 with 1472 bytes of data: Packet needs to be fragmented but DF set. Packet needs to be fragmented but DF set. Packet needs to be fragmented but DF set. Packet needs to be fragmented but DF set.PPPoE with RFC 4638
Pinging 8.8.8.8 with 1472 bytes of data: Reply from 8.8.8.8: bytes=1472 time=111ms TTL=49 Reply from 8.8.8.8: bytes=1472 time=112ms TTL=49 Reply from 8.8.8.8: bytes=1472 time=111ms TTL=49 Reply from 8.8.8.8: bytes=1472 time=112ms TTL=49 -
I realise that the reduced MTU causes fragmentation it's just that I've never really seen that cause a problem. Both my WAN connections are PPPoE.
[2.2.2-RELEASE][root@pfsense.fire.box]/root: ping -s 1492 8.8.8.8 PING 8.8.8.8 (8.8.8.8): 1492 data bytes 1500 bytes from 8.8.8.8: icmp_seq=0 ttl=56 time=6.845 ms 1500 bytes from 8.8.8.8: icmp_seq=1 ttl=56 time=7.074 ms 1500 bytes from 8.8.8.8: icmp_seq=2 ttl=56 time=6.916 ms 1500 bytes from 8.8.8.8: icmp_seq=3 ttl=56 time=6.659 ms 1500 bytes from 8.8.8.8: icmp_seq=4 ttl=56 time=6.898 msEdit: Of course that doesn't work with DF set! ::)
Steve
-
You need to set do-not-fragment bit (capital -D). Or else it's fragmented; you could basically ping any size.
ping -s 1800 yahoo.com PING yahoo.com (78.148.253.109): 1800 data bytes 1808 bytes from 78.148.253.109: icmp_seq=0 ttl=51 time=298.873 ms 1808 bytes from 78.148.253.109: icmp_seq=1 ttl=51 time=298.197 ms 1808 bytes from 78.148.253.109: icmp_seq=2 ttl=51 time=298.765 msping -D -s 1800 yahoo.com PING yahoo.com (78.148.253.109): 1800 data bytes 36 bytes from localhost (127.0.0.1): frag needed and DF set (MTU 1492) Vr HL TOS Len ID Flg off TTL Pro cks Src Dst 4 5 00 0724 a893 0 0000 40 01 f6be 82.88.192.51 78.148.253.109 36 bytes from localhost (127.0.0.1): frag needed and DF set (MTU 1492) Vr HL TOS Len ID Flg off TTL Pro cks Src Dst 4 5 00 0724 fac3 0 0000 40 01 0000 82.88.192.51 78.148.253.109 -
Indeed, I realise that now.
What I mean is. How does having fragmented packets cause you a problem?Steve
-
Isn't being able to ping 1472 size a problem itself? It's broken.
-
I realise that the reduced MTU causes fragmentation it's just that I've never really seen that cause a problem. Both my WAN connections are PPPoE.
And on your both WAN interfaces, did you specify MTU and/or MSS?
-
No they are both set at default values, which is 1492.
Steve
-
In my browser (FF, IE and Chrome) some ipv6 pages did load very slow.
This ridiculous bug has been ignored by the FreeBSD guys for ages.
https://redmine.pfsense.org/issues/2762
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=172648IOW, you don't need baby jumbo, you need pf to stop throwing out legitimate traffic.
-
PPPoE is an artifact left over from the days of dialup. Ethernet is already meant to be line rate, but now you have to add a PPPoE server and suddenly you're centralizing your contention. PPPoE has issues with high speed connections, like 1Gb and soon 10Gb. It can be done if you throw enough money at it, but that can be said of nearly anything.
Yes you are correct. But that doesn't mean PPPoE is disappearing, or even shrinking.
I was responding to "In the Netherlands fiber connections are all PPPoE. Don't know for other countries, someone?". On this side of the pond, few people have access to PPPoE, especially the type of people the devs are for PFSense. Without access to PPPoE, it's hard to test, plus it's a bit unglamorous to be working on code to support legacy systems.
Is the baby jumbo frame thing a PFSense thing or a FreeBSD thing? Maybe asking in the FreeBSD forums would gain more traction. Would be nice to check off another feature.
-
I am trying to understand the status quo: Does this mean this bug is preventing normal usage of ipv6 in pfSense and because the dev's have focus on other stuff no solution is expected in near future?
-
I was responding to "In the Netherlands fiber connections are all PPPoE. Don't know for other countries, someone?". On this side of the pond, few people have access to PPPoE, especially the type of people the devs are for PFSense. Without access to PPPoE, it's hard to test, plus it's a bit unglamorous to be working on code to support legacy systems.
Is the baby jumbo frame thing a PFSense thing or a FreeBSD thing? Maybe asking in the FreeBSD forums would gain more traction. Would be nice to check off another feature.
Since when did pppoe become legacy and "unglamorous" to continue support for? Probably from a purely academic and philosophical point of view.
FWIW the way I see it pfsense supports pppoe over legacy copper dsl & cable, and not up-to-date for pppoe over optical fiber. -
Just to be clear here I have 2x FTTC connections at home which are both PPPoE. I have not applied any special settings to either of them and have never seen any particular issues with fragmented packets.
However I don't have an IPv6 tunnel setup, nor do my ISPs offer native IPv6.
Looking at Doktornotor's links this appears to be an upstream bug in IPv6 handling in pf. It also looks as though Ermal submitted a patch at one time. I'm not aware of what happened about that though.
I can try to find out…Steve
-
Looking at Doktornotor's links this appears to be an upstream bug in IPv6 handling in pf. It also looks as though Ermal submitted a patch at one time. I'm not aware of what happened about that though.
I can try to find out…Yeah that bug is IPv6 specific. Until you lower the MTU/MSS, the experience is extremely annoying. Takes multiple attempts to get some sites loaded (notably, also pfsense.org ones). And then there are sites that just totally fail, like https://www.o2.cz/
-
Indeed, I realise that now.
What I mean is. How does having fragmented packets cause you a problem?
SteveI realise that the reduced MTU causes fragmentation it's just that I've never really seen that cause a problem. Both my WAN connections are PPPoE.
Just to be clear here I have 2x FTTC connections at home which are both PPPoE. I have not applied any special settings to either of them and have never seen any particular issues with fragmented packets.
Bug
root: ping -D -s 1472 yahoo.com PING yahoo.com (206.190.36.45): 1472 data bytes 36 bytes from localhost (127.0.0.1): frag needed and DF set (MTU 1492) Vr HL TOS Len ID Flg off TTL Pro cks Src Dst 4 5 00 05dc 6b46 0 0000 40 01 abcc 2.97.247.19 206.190.36.45Expected result
ping -D -s 1472 www.dslreports.com PING www.dslreports.com (64.91.255.98): 1472 data bytes 1480 bytes from 64.91.255.98: icmp_seq=0 ttl=47 time=122.827 msThe issue is for those of us who have a maximum MTU of 1500 cannot ping 1472 bytes without it getting fragmented. That itself is the issue; nothing more or less.
It seems as though you're putting the burden on us to prove that something is broken because of fragmented packets. Terribly sorry that myself or the OP can't tickle your mind in a purely academic and pedantic fashion.
