Route advertisement with static IPv6 for both WAN and LAN?

mqudsi

Hello,

Is there anything that needs to be manually configured for pfSense to advertise its route to the LAN subnet on the WAN interface?

My datacenter host gave me the following:

Network: 2604:f80:2::/48
Gateway: 2604:f80:2::1/48

I have the WAN on pfSense configured statically as 2604:f80:2::3/64 (yes, not set to /48 because then it would overlap with the LAN)
I have the LAN on pfSense configured statically as 2604:f80:2:1::1/64

There is bidirectional communication from the world to pfSense, no problems. However, I cannot ping the LAN IPv6 from outside and I cannot ping the gateway IPv6 from inside.
The firewall is correctly configured and is passing traffic from the LAN to WAN (shows up in the logs), but responses never reach the WAN port back (confirmed via wireshark).

I have a feeling the gateway should not be configured to be /48 but rather /64 on the ISP's end?

mqudsi

The silence is a bit deafening…

In answer to my own question and for the benefit of future readers:

In a situation like this where tcpdump reveals that LAN-destined traffic is being dumped on to the WAN interface directly, there are only two options:

You use router advertisements to inform the upstream router of the existence of the route to LAN
The upstream IPS/DC statically adds the route to your LAN as being via your WAN

In my case, my ISP had given me the /48 but neither was accepting route advertisements from my prefix (not surprising) nor had they configured any static routing for my LAN (also not surprising).
The solution ended up asking them to assign me another static /126 or /112 ("interconnecting route") that was strictly routed from the gateway to the WAN, and adding a static route on their end to the /48 specifying my end of the /112 as being the route for the entire /48.

awebster

They really should be allocating a /64 for the point-to-point link.
The "Internet powers that be" really need to come out and state for once and for all that the minimum network size is /64.
Going to anything smaller (longer prefix, oh yeah and the vocabulary too while they are at it!) just causes confusion and breaks clients who have take a more simplified approach.
Just my 2¢.
–A.

cmb

For the interconnect networks, a /126 or /112 is fine. /64s are only strictly required where SLAAC is involved, and that won't happen on your interconnects with your ISP.

The "throw a /48 on what should be an interconnect and give it to the customer" is the braindead stuff that ISPs need to understand doesn't apply in the IPv6 world. Apparently most small-mid size ISP network engineers weren't around in the '90s pre-NAT and have a hard time grasping how IPv6 routing should work in a world that doesn't have NAT, judging by the number of people who show up here with similarly broken assignments.

Router advertisements aren't to inform the upstream where to route something, that's how hosts find their router (and do SLAAC, where applicable). Generally routing is static where you have static IPs, or uses BGP to exchange routes with the ISP where not statically routed (usually only if you're multi-homed). It's handled dynamically on the ISP side in the case of dynamic allocation with PD. Outside of BGP scenarios, you never configure something on your side to tell the ISP how to route things.

awebster

My concern is that the ISP has no idea what's on the other side of the pipe.
If for instance, you were to have a bunch of IPs proxy ARPed by a firewall you'd simply give the customer their subnet. However, as you astutely point out, we're not in Kansas anymore; There is no proxy ARP happening on IPv6 (or proxy NDP as I've seen some people ask!), this is plain vanilla routing, so there needs to be an interconnect subnet. Here something smaller (longer) than a /64 might make sense, such as /112 or /126, but on the other hand, if there is just a single device, such as a PC connected on the client side, then a /64 would make more sense so that SLAAC would have a chance to work.
Bottom line, what I'm saying is that if the ISP puts something other than /64 on the interconnect subnet, the setup might not work depending on what device the client connects.

The smallest allocation an ISP should be receiving from ARIN/RIPE/etc would be a /36 which is truly gargantuan. Even if they are a small ISP with a few hundred clients downstream from a larger ISP, then they might only have a /48; either way there's plenty (65536) /64 subnets you can cut out of that.
The whole principle of IPv6 addressing is to not try to economize addresses. I think it is going to take many years to "unlearn" what was preached for IPv4.

I get the distinct feeling that many people just don't grasp the orders of magnitude that each additional bit adds, so at the risk of repeating myself, I'll put it up again:

If the ISP gets a /32 prefix, which is the standard default size allocated to ISPs, from their local numbering registry, then they have enough prefixes to give out a /64 prefix to every single IPv4 host on the ENTIRE INTERNET with lots left over!!

/60 = 2^4 (16) /64 prefixes
/56 = 2^8 (256) /64 prefixes
/52 = 2^12 (4,096) /64 prefixes
/48 = 2^16 (65,536) /64 prefixes
/40 = 2^24 (16,777,216) /64 prefixes or 2^8 (256) /48 prefixes
/36 = 2^28 (268,435,456) / 64 prefixes or 2^12 (4096) /48 prefixes
/32 = 2^32 (4,294,967,296) /64 prefixes or 2^16 (65536) /48 prefixes

hda

@awebster:

My concern is that the ISP has no idea what's on the other side of the pipe.

Yes, IPv6 does VLSM. When using /120 or /112 as a ISP-client on Static/DHCP6-Server other than /64, that helps protecting against NDP exhaustion. <blog.ipspace.net 2011="" 05="" ipv6-neighbor-discovery-exhaustion.html="">If one feels concerned to contribute but wants to be able to switch back, then take reservation for SLAAC host space while not using it. i.e. a server-LAN for upto 22221234:1::ff/120 is reverseable with 22221234:1::ff/64.</blog.ipspace.net>

awebster

I'm not saying IPv6 doesn't do VLSM, I'm saying that ISPs shouldn't do it.
On NDP exhaustion attacks, Owen DeLong seems to think otherwise:

The primary solution is that while ND exhaustion attacks are a reality, remote ND exhaustion attacks can be mitigated with reasonable firewall rules in most cases.

I think there is quite a bit of fear mongering around NDP attacks, but that should not stop one from using /64 everywhere.
See also: http://www.networkworld.com/article/2223248/cisco-subnet/the-logic-of-bad-ipv6-address-management.html

Just my 2¢.

cmb

It depends on the circumstances. In this case in a datacenter environment, or in any business class Internet connectivity situations, the ISP can be confident there will be a router or firewall on the interconnect to them. Where that's the case, it's fine to use a longer prefix.

There is something to be said for limiting the possibilities for NDP exhaustion. Surprises me to see "mitigated with reasonable firewall rules" from Owen DeLong, given his background at he.net and other service providers. Maybe it's just missing context. For an end user, yeah for sure, no problem with reasonable firewall rules. For ISPs, no, you have no filtering of that sort at all as an ISP. NDP exhaustion is only relevant in the context we're discussing here for the ISP's side (unless something inside your network is scanning out to your WAN subnet).