Have WAN track WAN IPv6?
-
@mariatech said in Have WAN track WAN IPv6?:
My pfSense has global addresses that do not belong to the default ISP, yet pfSense is selecting those addresses as the source and sending those packets to the ISP via the default gateway. The ISP's router will only forward packets originating from prefixes that the ISP owns, my packets are thus rejected
So it boils down to that.
And you can't or don't want to use that other IPv6 connection.
If not assigning an IPv6-address to the WAN is not violating the standards than it is valid to ask for this feature, assigning one prefix to WAN, I guess.
Other than that, maybe you can "hack" something with NPt (or NAT) and virtual IPs on WAN.
-
If I'm hacking anything I'll probably try to hook into DHCP and automatically assign an alias as detailed above. Then I would have to verify the behaviour when the link flaps or disconnects.
I don't know what the rationale was here
RFC3633 (Obsolete)
Upon the receipt of a valid Reply message, for each IA_PD the
requesting router assigns a subnet from each of the delegated
prefixes to each of the links to which the associated interfaces are
attached, with the following exception: the requesting router MUST
NOT assign any delegated prefixes or subnets from the delegated
prefix(es) to the link through which it received the DHCP message
from the delegating router.but the prohibition is implicitly downgraded
RFC 6603 (Updates: 3633)
This specification defines a new DHCPv6 option, OPTION_PD_EXCLUDE
(67), that is used to exclude exactly one prefix from a delegated
prefix. The OPTION_PD_EXCLUDE is included in the OPTION_IAPREFIX
IAprefix-options field. There can be at most one OPTION_PD_EXCLUDE
option in one OPTION_IAPREFIX option. The OPTION_PD_EXCLUDE option
allows prefix delegation where a requesting router is delegated a
prefix (e.g., /56) and the delegating router uses one prefix (e.g.,
/64) on the link through which it exchanges DHCPv6 messages with the
requesting router with a prefix out of the same delegated prefix set.]No mention of OPTION_PD_EXCLUDE (67) in dhcp6c.conf(5), though it is in dhcpcd.conf(5). I have yet to try this option.
The existing CPE assigns a /64 prefix to the LAN and reports having a global WAN address belonging to the successively numbered /64. I'm not set up at the moment to capture traffic on the ISP side of the CPE.
-
@mariatech I'd be curious if you find a way to script this or something to make this work and be automated. Please share the knowledge if you do! My ISP (Verizon) uses RFC6603 and gives out a /56 and assigns the isp cpe the FF prefix. Sure, everyone says to just manually assign a virtual IP, but those random PD changes will get ya. Or to use a lan ipv6 address. It's disappointing that crappy ISP provided routers/equipment supports RFC6603 but something that is miles and miles more advanced like pfSense doesn't (yet?) If dynamic ip address updaters allowed you to use the lan ipv6 address to update a dynamic dns that would be a help too, but alas they don't...
-
@mariatech Just for completeness, what happens if you don't have another public IPv6-connection from somewhere else on pfSense? Probably pfSense would only use IPv4 for its own needs with no interruptions/problems.
-
@mariatech said in Have WAN track WAN IPv6?:
The OPTION_PD_EXCLUDE option
allows prefix delegation where a requesting router is delegated a
prefix (e.g., /56) and the delegating router uses one prefix (e.g.,
/64) on the link through which it exchanges DHCPv6 messages with the
requesting router with a prefix out of the same delegated prefix set.]What a waste though, why should a whole /64 used only for one connection and that prefix must be used from the delegating router, not pfSense, so maybe it is non of its business for pfSense anyway? But maybe both sides have to agree somewhat on that.
-
@sirsilentbob said in Have WAN track WAN IPv6?:
My ISP (Verizon) uses RFC6603 and gives out a /56 and assigns the isp cpe the FF prefix. Sure, everyone says to just manually assign a virtual IP, but those random PD changes will get ya.
ACTUALLY... as I just mentioned in another thread... it was BELIEVED that RFC 6603 might be used to accomplish what Verizon is doing, because that seemed to be the most logical (and standards-based) method to get where they are with their CPE. However, someone with an OpenWRT router (which has a DHCP6 client that supports that RFC) found that they're not getting any data back when requesting that option... so it may just be something hard-coded into Verizon's CPE.
I don't believe anyone has gotten an actual packet capture on the WAN side of a Verizon router to see if in fact RFC 6603 is being used.
-
@bob-dig said in Have WAN track WAN IPv6?:
What a waste though, why should a whole /64 used only for one connection and that prefix must be used from the delegating router, not pfSense, so maybe it is non of its business for pfSense anyway? But maybe both sides have to agree somewhat on that.
There are enough /48s to give every single person on earth over 4000 of them, so a /64 isn't much. More to the point, why doesn't the ISP use a single /64 to provide WAN addresses for their customers, as mine does?
-
@bob-dig Assuming you have addresses from one and only one global PD configured on any interface, it uses one of those.
- 8.1.1.6. Source Address Selection Rule 3
- RFC6724 Rule 8: Use longest matching prefix.
I believe the default pfSense configuration is to prefer IPv6. I have not seen it fall back to IPv4, at least for system/package updates, it keeps trying IPv6.
-
@jknott The intent was to give the customer exclusive authority over addressing. If the ISP needed to access their CPE router, they would have to allocate and manage a disjoint address just for the router and add an additional route to the tables. Some ISPs prefer having the traffic under one prefix, so they "steal" one /64 from the customer allocation, and the traffic to both the ISP router and the customer is aggregated under one prefix.
Since the pfSense router is under customer control, the ISP does not need to access it so there is actually no need to give up that /64.
-
@mariatech said in Have WAN track WAN IPv6?:
If the ISP needed to access their CPE router, they would have to allocate and manage a disjoint address just for the router and add an additional route to the tables.
My impression is they have their own addresses, possibly unique local, for managing the CPE. For example, my modem is in bridge mode, without a public address that I'm aware of, yet my ISP is able to access it. Given the huge IPv6 address space that wouldn't be difficult to do. As for my WAN address, it is part of a /64 shared with other customers, but that prefix has nothing to do with my /56.
BTW, I would expect my ISP and others now manage their CPE with IPv6. In fact, that was a significant reason why Comcast moved to IPv6, as there weren't enough rfc1918 addresses to do it.
-
Apologies, I was under the belief someone had confirmed the data/request was being sent but either in their case the reply was blank or they couldn't capture the response for whatever reason.
@mikev7896 said in Have WAN track WAN IPv6?:
@sirsilentbob said in Have WAN track WAN IPv6?:
My ISP (Verizon) uses RFC6603 and gives out a /56 and assigns the isp cpe the FF prefix. Sure, everyone says to just manually assign a virtual IP, but those random PD changes will get ya.
ACTUALLY... as I just mentioned in another thread... it was BELIEVED that RFC 6603 might be used to accomplish what Verizon is doing, because that seemed to be the most logical (and standards-based) method to get where they are with their CPE. However, someone with an OpenWRT router (which has a DHCP6 client that supports that RFC) found that they're not getting any data back when requesting that option... so it may just be something hard-coded into Verizon's CPE.
I don't believe anyone has gotten an actual packet capture on the WAN side of a Verizon router to see if in fact RFC 6603 is being used.
-
I have found another approach, but first be sure that it applies to your situation. As others have pointed out, it is not essential that the WAN interface be configured with a Global Unicast Address (GUA). Most installations work fine without it, and its absence has not affected routing at all i.e. the clients all have full IPv6 connectivity.
Prerequisites:
- Prefix Delegation (PD) e.g. 2001:A:B:C00::/56 from your ISP
- At least one address from PD assigned to any interface other than WAN e.g. 2001:A:B:C00::1 on LAN
- At least one GUA which is NOT in PD, assigned to any interface other than WAN e.g. 2600:X:Y::2 on OPT1.
Symptom:
ping6 from pfSense to internet fails e.g.$ ping6 -c4 google.com PING6(56=40+8+8 bytes) 2600:X:Y::2 --> 2607:f8b0:400a:807::200e --- google.com ping6 statistics --- 4 packets transmitted, 0 packets received, 100.0% packet lossforcing LAN GUA as the source address succeeds
$ ping6 -c4 -S 2001:A:B:C00::1 google.com PING6(56=40+8+8 bytes) 2001:A:B:C00::1 --> 2607:f8b0:400a:807::200e 16 bytes from 2607:f8b0:400a:807::200e, icmp_seq=0 hlim=120 time=21.028 ms 16 bytes from 2607:f8b0:400a:807::200e, icmp_seq=1 hlim=120 time=25.185 ms 16 bytes from 2607:f8b0:400a:807::200e, icmp_seq=2 hlim=120 time=20.654 ms 16 bytes from 2607:f8b0:400a:807::200e, icmp_seq=3 hlim=120 time=20.645 ms --- google.com ping6 statistics --- 4 packets transmitted, 4 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 20.645/21.878/25.185/1.915 msIf this is the case, you can assign a unique label to each offending network in the address selection policy table
$ ip6addrctl Prefix Prec Label Use ::1/128 50 0 12 ::/0 40 1 23716 ::ffff:0.0.0.0/96 35 4 0 2002::/16 30 2 0 2001::/32 5 5 0 fc00::/7 3 13 0 ::/96 1 3 0 fec0::/10 1 11 0 3ffe::/16 1 12 0 $ sudo ip6addrctl add 2600:X:Y::/48 45 6 $ ip6addrctl Prefix Prec Label Use ::1/128 50 0 15 ::/0 40 1 29076 ::ffff:0.0.0.0/96 35 4 0 2002::/16 30 2 0 2001::/32 5 5 0 fc00::/7 3 13 0 ::/96 1 3 0 fec0::/10 1 11 0 3ffe::/16 1 12 0 2600:X:Y::/48 45 6 10 $ ping6 -c4 google.com PING6(56=40+8+8 bytes) 2001:A:B:C00::1 --> 2607:f8b0:400a:807::200e 16 bytes from 2607:f8b0:400a:807::200e, icmp_seq=0 hlim=119 time=26.779 ms 16 bytes from 2607:f8b0:400a:807::200e, icmp_seq=1 hlim=119 time=22.534 ms 16 bytes from 2607:f8b0:400a:807::200e, icmp_seq=2 hlim=119 time=20.708 ms 16 bytes from 2607:f8b0:400a:807::200e, icmp_seq=3 hlim=119 time=20.716 ms --- google.com ping6 statistics --- 4 packets transmitted, 4 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 20.708/22.684/26.779/2.478 msBecause we only reference the networks we are trying to keep away from the default route, source address selection will still be correct should the PD change.
I don't yet know how to make this persistent across reboots or updates. One thing I have tried is putting the table in /etc/ip6addrctl.conf using the filer package, but after rebooting, the ip6addrctl service still needs to be manually restarted.
-
@mariatech Maybe this will be helpful
