I thought I had this problem worked out but it appears not. For example, trying to browse to ipv6-test.com does not respond...
So, here is the topology again:
Laptop (windows 10) --> CPE --> LNS --> Core --> Upstream ISP
IPv4 is working great. I have the CPE configured to 1500 MTU and the tunnel profile on the LNS is configured to 1500 as per below:
set access group-profile l2tp-group-profile ppp ppp-options mtu 1500
If I ping www.ipv6-test.com on 2001:41d0:8:e8ad::1 from the laptop it works fine. If I tracert from the laptop to this IPv6 address, it also works fine and takes the correct route. However, when I try and browse to the website it fails completely. I get nothing in return.
So, the MSS is configured on the upstream interface (egress) as per below:
set interfaces xe-1/2/5 unit 0 family inet6 tcp-mss 1410
Strangely, if I complete a wireshark trace while connecting, the TCP SYN from the laptop to the URL does not state any MSS but the SYN ACK response states 1440 from the server. I am completing the wireshark trace on the actual laptop but I expected to see a TCP SYN with an MSS of 1410 and agreement on this in the SYN ACK from the URL. This is not the case.
So, couple of questions please:
1: Does the LNS require any specific MTU setting on the PPP interface for IPv6?
2: Anyone else seen this issue and know how to resolve it?
Did you try to remove the MSS from uplink and configure it on subscriber IFL?
No, I have not tried that yet. Do I need to upgrade for this requirement? If so, we cannot complete this.
Having checked it seems like we would need to upgrade to enable this option. As we would require all systems to be on the same version it is important to know if upgrading all four systems will have any detrimental effect?
We are currently on Junos: 16.1R6.7 and the command structure is not available. I believe we need to be on 17.3R3.
Are there any issues with this upgrade?
17.3R3 is golden release [ Lot of bugs fixed].
There is no issues with direct upgrade to 17.3R3.
I have downloaded the correct version as you mentioned and am now in the process of ftp'ing to the LNS. I will upgrade the backup routing engine first and reboot that and then the master and reboot that one.
I'll then complete the configuration on the dynamic profile and will let you know the results.
From the perspective of removing the MSS from the upstream interface, I am not sure we can do that. We have ethernet customers who enter straight onto the core and I am sure they will require an MSS too.
Here is the mine for version 17:
set dynamic-profiles PPPOE-PROFILE interfaces pp0 unit "$junos-interface-unit" family inet6 tcp-mss 1452
set interfaces xe-0/1/0 description WAN-INTERFACE
set interfaces xe-0/1/0 unit 0 family inet6 tcp-mss 1452
Yes. That's how mine would be configured.
However, I have run into another issue.
I upgraded to 17.3 and suddenly the CPE could no longer get it's IPv6 details from the RADIUS. The configuration was exactly the same. Now, I have downgraded back to 16.1R6.7 and IPv6 is working again.
How have you managed to get IPv6 working to the CPE via the dynamic profile under 17.3?
Thanks to superb help from Rahul, we have solved the issue of no IPv6 address being assigned in 17.3.
Strangely, removing ffff:ffff:ffff from the /128 IANA Assigned address to ::1 /128 has allowed the CPE to get the RADIUS assigned IPv6 address.
Given that they are both within the prefix assigned range that is really strange. But it does allow me to continue the MSS testing. Will let you know the results.
After more testing with differing MSS sizes I am still getting strange issues.
It may be something to do with ICMPv6 Type 2 packets or Packet Too Big errors.
Anyone know how to resolve this issue please?
Okay. It looks like the issues are surrounding Microsoft Edge as testing with Firefox and Chrome works fine.
I will close this MSS issue for now as it works almost 100%.