Ipv6 unusable due lack of love from FreeBSD (prev: Support baby jumbo frames)
-
https://forum.pfsense.org/index.php?topic=93902.0
-
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? -
For anyone having FTTx and connect using PPPoE, baby jumbo packet is supported because it's standard on all OLTs aka optical DSLAM.
-
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? -
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?
