Have WAN track WAN IPv6?
-
Perhaps you should do some reading on how routing works.
Excuse me, everything you have tried to explain in this post can be found in what I have written above.
-
Please explain how you think an address from another network is reachable on yours. You have told me that you are trying to use an address from other than your ISP. How is traffic destined for that address supposed to reach your network?
-
Please explain how you think an address from another network is reachable on yours.
That's not what I think. I haven't said anything that would suggest that.
You have told me that you are trying to use an address from other than your ISP.
A router necessarily has addresses on different networks.
How is traffic destined for that address supposed to reach your network?
Through the peer's ISP.
-
You have a router, with one interface connected to your ISP. You have one or more interfaces for your local LAN. Your router knows about your LAN(s) and your ISPs gateway. That's it, as apparently you don't even get a global WAN address. It knows of no other addresses. The peer (whoever that is) has a similar setup with their ISP (unless they're large enough to have their own autonomous system). If you try to use an address from that other ISP on your router, then you will not see incoming traffic for that address. It will be sent through the other ISP, to that peer, with no way to get to you. This is determined entirely by the network prefixes. The prefix for that peer belongs to that other ISP, not yours.
Here is Google's IPv6 address: 2607:f8b0:400b:80c::200e. Assume they're on an ISP with a /56 prefix like me. The prefix is the first 64 bits, ending in 80c. With a /56, those could be anything between 800 and 8ff. Now, if you were to take an address anywhere within that 2607:f8b0:400b:800/56 and assign it to your firewall, I can guarantee you, you will never, ever see any packets come back to you, because they'd all be sent to Google and not you. What you are trying to do simply won't work, because it violates the way IP networks work. Now, if you had your own autonomous system, where you use a routing protocol, such as BGP, then yes, you could do what you want and then your autonomous network would advertise, via BGP, to the world where to find that address and that would have to propagate around the world for it to work. It would also cause entries in routing tables around the world, to create an exception to where that address would normally go.
What you're trying to do will not work in either IPv4 or IPv6.
-
@jknott said in Have WAN track WAN IPv6?:
You have a router, with one interface connected to your ISP. You have one or more interfaces for your local LAN. Your router knows about your LAN(s) and your ISPs gateway. That's it, as apparently you don't even get a global WAN address. It knows of no other addresses. The peer (whoever that is) has a similar setup with their ISP (unless they're large enough to have their own autonomous system). If you try to use an address from that other ISP on your router, then you will not see incoming traffic for that address. It will be sent through the other ISP, to that peer, with no way to get to you. This is determined entirely by the network prefixes. The prefix for that peer belongs to that other ISP, not yours.
Only until the traffic gets to the peer. They have their own routes pointed at one of their networks, which is connected to one of my interfaces.
Here is Google's IPv6 address: 2607:f8b0:400b:80c::200e. Assume they're on an ISP with a /56 prefix like me. The prefix is the first 64 bits, ending in 80c. With a /56, those could be anything between 800 and 8ff. Now, if you were to take an address anywhere within that 2607:f8b0:400b:800/56 and assign it to your firewall, I can guarantee you, you will never, ever see any packets come back to you, because they'd all be sent to Google and not you. What you are trying to do simply won't work, because it violates the way IP networks work.
That's not what I'm trying to do. Actually that's exactly what is going wrong, at least we are clear on that. But pfSense is doing it anyway.
Now, if you had your own autonomous system, where you use a routing protocol, such as BGP, then yes, you could do what you want and then your autonomous network would advertise, via BGP, to the world where to find that address and that would have to propagate around the world for it to work. It would also cause entries in routing tables around the world, to create an exception to where that address would normally go.
What you're trying to do will not work in either IPv4 or IPv6.The IPv4 WAN interface has a routable address from the ISP. That address is used by the pfSense host as the source address and everything works fine. The default pfSense configuration does not configure the WAN interface with an IPv6 global address. Routing works, but the pfSense host itself cannot communicate on IPv6 for DNS, NTP, ACME, etc. for exactly the reasons you have explained above, because pfSense picks the address from the peer network and tries to use it on my ISP. When I manually configure WAN with one of the addresses from MY ISP, pfSense then uses that address, and everything works fine. But it should not be manually configured, it should be done by DHCP.
Everything you have said above about routing is completely correct and agrees with my previous description of the difficulty. It is not my decision to use an address that is foreign to my ISP. It is pfSense that is trying to do it. I am well aware of the reasons it cannot work.
-
@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
