Airtel is rolling out IPv6 on their wired broadband services

Ok, so here are my IPv6 settings for Airtel PPPoE. Note Airtel v6 does not work with a static IP, possibly unless you have PPPoEv6 as shared earlier.
I was able to get a PD on the LAN and all my devices.

I tried this with a static IPv4 and it simply refuses to work. Airtel's Nokia ONT uses DHCPv6 via v4 not PPPoEv6for IPv6 assignment. Unchecking "Do not wait for RA" may or may not work. Further experimenting to be done.

Airtel IPv6 on pfSense
 
3 points I needed to add for pfSense:
a) It required a reboot as it simply would not get a v6 PD without it. Rather strange since pfSense which runs on FreeBSD doesn't need Windows type reboots.
b) LAN track interface should be set to Airtel WAN. Not an issue if you have a single WAN connection but for me my default v6 config is for Tata Play which has assigned me a static IPv6 /64 block. So set track interface setting accordingly to the correct WAN.
c) pfSense assigns the WAN port a fe80:: link local address and NOT a routable DUID v6 address. That's how it is designed to work in this router/firewall. Ditto for OPNSense.
 
@awemonk What Hurricane Electric is probably reporting is that it's a /48 (the 1st three quartets that define that subnet, itself taken taken from a larger /40) for the ISP out of which one subnet i.e a /64 is assigned to you.

It shows the same i.e. /48 for my IPv6 (static) under Tata Play while what TPBB has assigned to me is a /64 which means the 1st 4 quartets remain constant while the rest are dynamically assigned by RA/DHCPv6.

cwwGkYT.png
 
For those interested in IPv6 prefix values and resultant # of subnets here's a guide:

YNHRcNz.jpg
 
It required a reboot as it simply would not get a v6 PD without it. Rather strange since pfSense which runs on FreeBSD doesn't need Windows type reboots
Does pfSense use odhcp6c?
If yes, this might be similar to the issue I was facing, where odhcp6c simply ignores the PD received from the advertisement.

Look in the following thread for details: Debugging DHCPv6-PD
The thread is for OpenWRT, but you can adapt the solution for pfSense
 


@doineedto pfSense uses 'dhcp6c' and I am not sure if pfSense/Netgear has tuned the underlying FreeBSD 12.3 OS to overcome any issues.

Actually I faced this issue with only Airtel possibly because I changed from static v4 to PPPoEv4 + DHCPv6. Maybe it would've sorted itself out had I waited but I got impatient I just rebooted the machine. I need to add pfSense works perfectly with TPBB IPv6.

Also, I just found out you can uncheck "do not wait for RA" and TPBB still works fine. This box is only to be checked if the ISP doesn't use PPPoE for v4 and/or has given express instructions to do so.
 
Happens with me too, when IPv6 is unavailable for a while the browser defaults over to IPv4. Try opening in a new tab, should be fixed, if not, close the browser completely and check again, should default back to IPv6 again.
 
@nishantt6969 yep that's default..I won't call it 'normal'. That's the way things are going to be even with the OS. Now for e.g. I have a v6 address and if I ping or trace route to a particular site it always picks the v6 address to ping on. If that's not available then v4. For e.g. when I ping google.com this is what I see:

Code:
C:\Users>ping google.com
Pinging google.com [2404:6800:4009:811::200e] with 32 bytes of data:
Reply from 2404:6800:4009:811::200e: time=4ms
Reply from 2404:6800:4009:811::200e: time=4ms
Reply from 2404:6800:4009:811::200e: time=6ms
Reply from 2404:6800:4009:811::200e: time=6ms

Ping statistics for 2404:6800:4009:811::200e:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 4ms, Maximum = 6ms, Average = 5ms

If I want it to ping Google's v4 address only then i use the switch '-4' and then here's what I get:

Code:
C:\Users>ping -4 google.com

Pinging google.com [142.250.183.78] with 32 bytes of data:
Reply from 142.250.183.78: bytes=32 time=41ms TTL=118
Reply from 142.250.183.78: bytes=32 time=39ms TTL=118
Reply from 142.250.183.78: bytes=32 time=45ms TTL=118
Reply from 142.250.183.78: bytes=32 time=41ms TTL=118

Ping statistics for 142.250.183.78:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 39ms, Maximum = 45ms, Average = 41ms

PS - notice the difference in ping times 🙂
 
Last edited:

Top