Have WAN track WAN IPv6?
-
@mariatech said in Have WAN track WAN IPv6?:
Do those interfaces share an ISP assigned prefix? How about
ping6 -S ::1 google.comYes. They're all part of the /56 I get from my ISP. Only the last 8 bits of the prefix change. For example, the prefix ID for my main LAN is 0, my VLAN, 3. etc. That ::1 is not a valid address for use over the Internet.
By /128, do you mean global host address?
The /128 means the size of the "network" is only 1 device, /127 provides 2, etc. If there is only one device, all that address does is identify the interface. My WAN address is also /128, which means it cannot communicate directly with any other address. As for those other routers, I bet they're using a link local address as happens here.
This is my default gateway from my ISP: fe80::217:10ff:fe9a:a199. The WAN /128 global address is not used for routing. It can be used as a target for VPN etc..
-
Only the last 8 bits of the prefix change. For example, the prefix ID for my main LAN is 0, my VLAN, 3. etc. That ::1 is not a valid address for use over the Internet.
Hence all the source addresses from your ISP-assigned prefix will be acceptable to the ISP's router, and the responses will come back via the same gateway. When your pfSense automatically chooses a source address, it will be one of those, so it will always work. 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, same as they would reject a packet having ::1 as the source.
My WAN address is also /128
My ISP does not assign any global address (NA), they only offer the PD through DHCP. All I am trying to do is to assign an address from the PD to the WAN, just like I can assign addresses to other interfaces with the 'track interface' option. I have demonstrated that manual configuration solves my source address problem without having to mess with the policy table. There have been no adverse effects wrt routing. The only negative is that if the alias is not removed before soliciting another lease, the interface goes into 'IFDISABLED' state, which has to be cleared before restarting dhcp6c.
-
Why are you trying to use an address that's not provided by the ISP? The Internet routers won't know how to return replies to you. Where are you getting that address from? Since your ISP doesn't provide a WAN address, all you have to do is point to an internal address they do provide, as I have suggested.
-
Why are you trying to use an address that's not provided by the ISP?
Because pfSense is a router
...all you have to do is point to an internal address they do provide, as I have suggested.
The DNS root servers, the package repo, NTP servers, ACME, etc. are internet resources, they are not hosted on my network.
-
The prefix is used to find the network you're connected to. If you use an address from another network any packets that you're expecting will be sent to some other network.
The DNS root servers, etc. have absolutely nothing to do with this. If you take some address that does not belong on your network, the Internet will have no idea that you're using that address and will send all packets to that other network, no exceptions. For example, I'm on Rogers. If you were to use one of my addresses and you tried to do something on the Internet, I'd suddenly start receiving packets that I have no idea about and you'd be sitting there wondering why things don't work. They don't work because they can't work.
You cannot use those addresses while on your ISPs network, with the exception if you have a VPN to the network where that address belongs. In that case, the packets will be sent to that network and then forwarded over the VPN to you. I mentioned my prefixes earlier, where I have a /56 prefix. This provides me with 256 /64 prefixes, where the last 8 bits are used to determine which one. I use the highest one, "ff" for my VPN. So, I could take my notebook computer to some other network and connect to the Internet through my VPN, using an address within that ff network as my source address and everything will work fine. I cannot just take one of those addresses and assign it to my computer while on some other network and expect it to work.
Perhaps you should do some reading on how routing works.
-
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.
