What is the one true way of using or configuring a single /64 IPv6 prefix?
-
Hello all,
Fact: it is universally accepted here and everywhere else on the web that an ISP (or even worse, a datacenter host) providing only a single /64 is wrong, incorrect, hard-to-work-with, breaks SLAAC, and doesn't work correctly with RAs.
That said, if one finds themselves in such a situation where they have been assigned a single /64 and can neither obtain a /60 or a /56 or a second /64, or even a point-to-point /126 or /128, what is the correct way of configuring pfSense so that it can correctly route and distribute traffic in a dual IPv4/IPv6 environment?
Given a static IPv6 /64 prefix, with one address already taken by the gateway (and another by the multicast), a single WAN interface, and a single LAN interface, what is the correct way of having pfSense sit in between the WAN and LAN and correctly route traffic between the two, using NAT for IPv4 and native IPv6 address assignment for PCs on the LAN? Also, what upstream changes (if any) have to be made in order for incoming requests to the /64 prefix to be correctly routed through the router's WAN IPv6 address?
Thank you kindly,
-
(I am posting my own thoughts on possible solutions in a separate reply so as not to mislead or provide inaccurate or incomplete information in the first post for future readers. Disclaimer: everything below is conjecture and brainstorming.)
A) Given instead two WAN interfaces (or a single interface that has been virtualized/split into two interfaces, etc), is it possible to have one dedicated to IPv6 traffic that simply bridges all IPv6 traffic from WAN to LAN, making IPv6 a bridged and not subnetted interface, while directing all IPv4 traffic to the second interface in a standard NAT configuration? While pfSense can still filter incoming IPv6 traffic to correctly act as a firewall?
B) Is there a correct way to configure pfSense so that you split the /64 into a /112 or a /126 for the connection between the gateway and the WAN port on the pfSense router and then use the remainder of the /64 space as your local subnet, without requiring any changes to the configuration of the gateway or any routing configuration upstream (i.e. solely on the customer's end)? Assuming one is OK with the breakage of RA and/or SLAAC and will run their own DHCPv6 service on the pfSense router for the LAN subnet/prefix?
C) Effectively, would option B be any different than configuring pfSense as an IPv6 NAT? Is there any way to assign all the /64 address space to pfSense's WAN interface, and yet run a DHCPv6 instance that will assign to local LAN machines addresses from that same pool (without the WAN and LAN routes getting confused by the presence of overlapping subnets)?
-
"That said, if one finds themselves in such a situation"
Show them how that is WRONG.. change ISP/DC if its such an issue to you. Or tunnel your ipv6 traffic.. HE will give you /48 that is for sure..
-
The premise of the question here is "if I have completely broken IPv6 connectivity, how do I make it not broken?" :)
If you have an ISP that isn't willing to route you at least a /64 for your internal network, they aren't providing IPv6 service, and are completely clueless. It's really as simple as that.
For the sake of answering the question in theory, you could do one of three things in theory.
- bridge LAN and WAN so your LAN hosts are on the same broadcast domain as the WAN and hence right on that WAN /64. That's a really awful thing to do in nearly every network.
- If you could proxy NDP a big chunk of that /64 (which we have no capability for, and that's a very uncommon feature in all routers and firewalls), then you could answer NDP WAN-side, and assign that chunk LAN-side. It's not pretty.
- IPv4-style NAT + ULA - shoot me now - we have no capability for this (exposed in the GUI today at least…) and thankfully most other things don't either, but you could in theory assign ULA IPv6 space on your LAN, and NAT everything to one or a small number of IPs on your WAN-side public /64. This is horrible.
In practice, there is no reason to have to do something like that.
-
Im not sure i understand your initial question mqudsi.
Are you saying your ISP assigns you 1 /64 net, and that net gets "taken" by your WAN, and thus you cant assign this on the LAN side? Not sure what is wrong with that scenario, but your WAN does not have to have a assigned /64 or even /128 for IPV6 to work afaik.
My WAN does not have a public IPV6 address, as it seems when i do that, all ipv6 connectivity on the LAN side stops working, so i make WAN only request a prefix, and then my LAN picks it up and things work. (Using Telenor Fibre ISP in Norway)
Bridging or any other way of making your LAN "move" to the same side of the firewall as your WAN would ofc break all possibilities of firewalling, and is absolutely nothing to want in your case.
Ill try to reply to your #2 post as best as i can:
A) What you are requesting is not really possible. Well.. depends on ISP i guess, but in most cases, your ISP wont allow 2 NIC's to obtain IP addresses from 1 fibre modem (or whatever equipment you are using). Atleast highly unlikely.
B) Everyone sais and really really consistently mean that /64 is the absolute smallest subnet you should ever work with… Wont get any of the devs here to recommend otherwise i think, nor should you consider it an option. SLAAC (afaik only thing working for android based gear) wont work with less than /64 https://en.wikipedia.org/wiki/IPv6_subnetting_reference
C) Dont think of ipv6 with NAT. That makes no (pf)sense :)
Other than that, im not entirely sure what you are asking here tho, so please comment further on that :) Im by no means an network (least of all IPV6) expert, so forgive me if im way off here tho.
C
-
So the common response to people that are only getting a single /64 from their ISP has been "Your ISP is doing it wrong"… but a thought crossed my mind last night after reading this thread...
Shouldn't it be possible to use SLAAC for a link-local WAN connection with the ISP router, then configure that /64 for your LAN?
I know that with DHCPv6 and PD, if you request just a prefix and not an address, link-local will be used on the WAN side and that /64 gets applied to the LAN. Shouldn't the same be possible with SLAAC on the WAN and a static /64 on the LAN?
-
@virgiliomi:
Shouldn't it be possible to use SLAAC for a link-local WAN connection with the ISP router, then configure that /64 for your LAN?
I know that with DHCPv6 and PD, if you request just a prefix and not an address, link-local will be used on the WAN side and that /64 gets applied to the LAN. Shouldn't the same be possible with SLAAC on the WAN and a static /64 on the LAN?
No, as that requires routing on the ISP's side. When they assign you a subnet via PD, they add a route to send that PD subnet to your WAN-side IP, whether that's link-local or public.
-
Yep… I knew I had to be missing something... :)
-
It gets even worse… what about the ISP's happy to charge you for a /64... the most you can get... and: limit to 6 the number of macs the router will connect with.
-
Vote with your wallet if their restrictions are a burden.
But the number of MAC addresses should not change. you should be able to get by with at most 3 in most cases as far as the provider is concerned. Even with thousands of IPv6 hosts on LAN all with "real" IPv6 addresses.
-
Fact: it is universally accepted here and everywhere else on the web that an ISP (or even worse, a datacenter host) providing only a single /64 is wrong, incorrect, hard-to-work-with, breaks SLAAC, and doesn't work correctly with RAs.
SLAAC most definitely works with /64. In fact, it's the only prefix it works with. Shorter prefixes are simply multiple /64s, which must be split up by a router. The standard for IPv6 local networks is /64.
BTW, my ISP, which recently started providing IPv6, currently hands out only a /64, but plans to move to larger blocks later. SLAAC and RA work fine here.
and: limit to 6 the number of macs the router will connect with
That is a bit much, given IPv6 has such a huge address space. In fact, there are enough /48s to give every person on earth over 4000 of them and that's with 3/4 of the entire IPv6 address space unallocated for any purpose.
I have my cable modem in bridge mode, providing my own firewall/router running pfSense. I have at least 6-7 devices here, each with it's own global unicast address. It's beyond me how an ISP can be so miserly with IPv6 addresses. Perhaps some public shaming is in order.
-
It gets even worse… what about the ISP's happy to charge you for a /64... the most you can get...
I don't really see a big issue with that when it comes to home Internet service. Most home users do not run multiple subnets on their local network. That's more for business users and geeks like us. ;) Of course I'm still happy that providers like Comcast provide at least a /60 for home users that want it.
It's a different story for those ISPs who give their users a single /128. That's completely missing the point of v6, of course.
and: limit to 6 the number of macs the router will connect with.
Never heard of such a thing. Are you sure that's not referring to MAC bindings on the WAN side?
-
It's a different story for those ISPs who give their users a single /128
A /128 is completely useless. It's only used as an interface identifier. A point to point link requires a /127 or /126
-
It's a different story for those ISPs who give their users a single /128
A /128 is completely useless. It's only used as an interface identifier. A point to point link requires a /127 or /126
Some ISPs actually do this. It's basically the same as v4 home Internet service. They give you a single address for your WAN interface, and you're expected to use NAT6 for internal hosts. Of course this completely negates the advantages that v6 brings.
-
They give you a single address for your WAN interface
You still need one address for the other end of the connection. My ISP, on IPv4, uses a /23 subnet mask, which allows up to 510 devices, plus their router. You can do the same with IPv6, where they could have all the customers assigned a single address out a a prefix. The /127 prefix or /31 on IPv4 is the smallest usable block, with one address available for use on each end of a point to point link.
Still, it's beyond belief that an ISP could be so stingy. It's like going to the beach and being allowed one grain of sand to sit on. ;)
-
You still need one address for the other end of the connection.
You're talking about two different things. Of course the ISP has a bigger inter-router subnet, but you as the user still get only a single address, which is a /128. It's just DHCP without PD. A /127 PD is also possible and would allow you to use two addresses in addition to the one assigned to the WAN interface via DHCP.
Still, it's beyond belief that an ISP could be so stingy. It's like going to the beach and being allowed one grain of sand to sit on. ;)
I don't think it's necessarily stinginess, but simply that they haven't bothered to learn about v6 and just apply what they understand from v4. That should hopefully go away once v6 becomes more common.
-
OP, either change to another ISP or bide time for them to see the light by using a tunnel. I've been using an HE tunnel for several years and it's been rock solid. The performance isn't quite as fast as native, but it's okay and even better, it's free.
-
I also used a tunnel for about 6 years, before my ISP provided IPv6. Worked well, though there were occasional issues.
As far as the number of available addresses go, there are currently enough /48s to given every person on earth over 4000 of them. This is even with 3/4 of the IPv6 address space not currently assigned for anything. At my count, the unicast address range could be 6x what's currently available.
-
I actually came across this thread while searching for /64 workarounds once more, all these years later (another ISP, this time).
I never did post back with what happened. I managed to get up and running by bridging WAN and LAN in a very ugly fashion while continuing to fight with the ISP, insisting that I was decidedly not asking for too much and that /64 was simply not enough. In the end they gave in and gave me a separate /112 for my WAN, so I'm happy :)
Now I'm fighting with another situation where an ISP is dynamically assigning a /64 to a business internet account…
(btw, protip: if you're ever playing around with the IPv6 configuration and at any point enable DHCPv6 on WAN, make sure you always delete /var/db/dhcp6c_duid
when changing it to something else) -
Hello all,
Fact: it is universally accepted here and everywhere else on the web that an ISP (or even worse, a datacenter host) providing only a single /64 is wrong, incorrect, hard-to-work-with, breaks SLAAC, and doesn't work correctly with RAs.
That said, if one finds themselves in such a situation where they have been assigned a single /64 and can neither obtain a /60 or a /56 or a second /64, or even a point-to-point /126 or /128, what is the correct way of configuring pfSense so that it can correctly route and distribute traffic in a dual IPv4/IPv6 environment?
Given a static IPv6 /64 prefix, with one address already taken by the gateway (and another by the multicast), a single WAN interface, and a single LAN interface, what is the correct way of having pfSense sit in between the WAN and LAN and correctly route traffic between the two, using NAT for IPv4 and native IPv6 address assignment for PCs on the LAN? Also, what upstream changes (if any) have to be made in order for incoming requests to the /64 prefix to be correctly routed through the router's WAN IPv6 address?
Thank you kindly,
Ignoring the fact this thread is so old it's gone mouldy, there is nothing wrong with a single /64, other than a stingy ISP. A /64 is the smallest prefix that supposed to be assigned. No matter how big your prefix is, your gateway will normally get one. I know that with only 18.4 billion, billion addresses, you don't have any to spare. ;)
To answer your question, place your modem in bridge mode, so that pfSense is the gateway, not the modem. That's what I have here.
