IPv6 Routing

JKnott

fe80::1 is the default, but if there are more than one pfSense system, then only 1 should get that. Others should have other addresses. On IPv6, duplicate address detection is mandatory. Have you actually tried 2 systems and seen what addresses they get?

JKnott

@pfadmin said in IPv6 Routing:

there are other than fe80::1:1 gateways. Some picture shows it on all interfaces, others only at vlan interfaces. how does it work?

One thing to bear in mind is duplicate link local addresses within one system are entirely legal, as the interface is actually part of the address. On the other hand, a link local address can only be used once within a L2 network.

IsaacFL

@JKnott

Yes, I have tried 2 systems and they both get fe80::1:1. It is hardcoded into the interface.

This in my mind is a bug, because pfSense is not using DAD on its link local address.

I found it when I tried to set up another interface with ULA and connect it to the same layer 2 net and it would not work because the router announcements from the 2 pfSense interfaces were both using the same link local address.

It is a valid configuration to have more than one router in a layer 2 ipv6 network.

I do not agree that fe80::1:1 is good practice. It is only visible as the gateway address so it isn't like you are trying to ping it, etc. I think that using the SLAAC address is best practice because then DAD will do its thing and you don't have to worry about people who don't understand ipv6 assigning the same link local address. As was done in pfSense.

JKnott

@IsaacFL

The LAN interface gets both link local and SLAAC addresses, but using the link local address for routing is common with IPv6. The question is why the link local address is always fe80::1:1. Not using DAD before assigning the address is a violation of RFC 4862.

"To ensure that all configured addresses are likely to be unique on a
given link, nodes run a "duplicate address detection" algorithm on
addresses before assigning them to an interface. The Duplicate
Address Detection algorithm is performed on all addresses,
independently of whether they are obtained via stateless
autoconfiguration or DHCPv6. This document defines the Duplicate
Address Detection algorithm.

The autoconfiguration process specified in this document applies only
to hosts and not routers. Since host autoconfiguration uses
information advertised by routers, routers will need to be configured
by some other means. However, it is expected that routers will
generate link-local addresses using the mechanism described in this
document. In addition, routers are expected to successfully pass the
Duplicate Address Detection procedure described in this document on
all addresses prior to assigning them to an interface."

Perhaps someone should file a bug report, as pfSense should not cause conflicts.

IsaacFL

@JKnott

It is my opinion that it is a bug too, but I didn't spend enough time on it at the time to write a bug myself. I don't use ULA myself so I didn't test it any further.

I did wonder at the time, how would high availability work in pfSense but I don't have a way to test that.

I have briefly tested a couple of other router types and they use a link local which has the appearance of using SLAAC, so I would say based on my limited survey a fixed address isn't "best practice" since of the 3 I looked at only pfSense used the fixed address.

smaxwell2

Interesting :) as I said in my initial post I am new to IPv6 ... but sounds like pfSense need to make a few modifications to the way pfSense deals with HA with IPv6.

Let’s say for a second that I removed HA for IPv6 and just used the primary routers along the path, leaving IPv6 disabled on all secondary nodes.

What do I need to enable on each router and on which interface ? Have I set the addresses correctly etc ?

IsaacFL

@smaxwell2

Maybe you could repost this in the HA/CARP area. Maybe someone there could give you advice there?

JKnott

@IsaacFL said in IPv6 Routing:

I don't use ULA myself so I didn't test it any further.

I don't think the link local issue has anything to do with ULA.

IsaacFL

@JKnott said in IPv6 Routing:

@IsaacFL said in IPv6 Routing:

I don't use ULA myself so I didn't test it any further.

I don't think the link local issue has anything to do with ULA.

I was trying to set up an interface using ULA as the prefix connected on layer 2 to another interface with a GUA prefix. That way a service such as DNS could get a ULA address in addition to its GUA. This is a valid use case for ipv6 as you can have multiple prefixes in a single link.

Having the same Link Local Address on both of the pfsense interfaces, caused problems as this gave me 2 different MACs both claiming to be using fe80::1:1.

JKnott

@IsaacFL

I think you're getting issues mixed up. I was responding to your comments about the link local address always being fe80::1.1, which prevented having more than 1 pfSense box on a network. That has nothing to do with ULA. ULA works and I have it set up here. My computer, which I'm typing on right now, has both ULA and GUA addresses. Here is one of the ULA on it: fd48:1a37:2160:0:14ad:9c43:189d:fb77. It also has GUA, so I can go out to the internet.

IsaacFL

@JKnott
It was maybe a year ago I tried it so maybe they fixed it. At the time pfSense would not advertise a 2nd prefix on the same interface and trying to use a second interface to advertise a 2nd prefix failed because of the duplicate link local. Two separate Mac addresses both claiming the same ip address.

But I haven’t tried it with 2.4.5 so maybe it is fixed.

IsaacFL

@JKnott

I did check and the issue I had that led me to try 2 interfaces is fixed. Not using ULA's today:

I was able to add a spare /64 to the RA of one of my interfaces.
I verified that it created the proper entry in the /var/etc/radvd.conf
A test pc did receive an additional address from the added prefix
First ping did not work.
Noted that pfsense did not automatically create a route for the new /64
Created a VIP with an address in the /64 which did create the route
Ping worked.

So that is all good now. Could be more automatic but it works.

But that is not a real common usage of multihoming (ULA excepted). More common would be the case where for redundancy you have 2 ipv6 routers, each advertising a different /64. connected to the same layer 2. This I don't think would work with pfsense, because of the hard coded fe80::1:1 on the LAN interfaces when connected to the same layer 2.

I don't really have a way to try that out currently as I would have to create a virtual pfsense, etc. and with stay at home, Dear Spouse would probably not consider me so dear.

I could write a bug report for it, but I don't have an easy way to test.

IsaacFL

@JKnott

Wait, the dual prefix setup did not survive a reboot.
I remember now, the bug is that IPv6 VIP overwrites the prefix that should be provided from the track id.

So how do you get ULA to work on pfsense and survive a reboot?

JKnott

@IsaacFL

I have been using ULA for well over a year. However, one thing I found is that the GUA prefix was no longer automatically assigned. I had to manually add both the ULA and GUA prefixes on the Router Advertisement page.

JKnott

@IsaacFL

You seem to be bouncing all over and making it hard to figure out what you're doing. ULA works, as I have here. Multiple interfaces work, as I have done here. The LAN link local address appears to be broken, as it should never try to force fe80::1:1. According to that RFC, duplicate address detection is supposed to be used.

IsaacFL

@JKnott said in IPv6 Routing:

@IsaacFL

You seem to be bouncing all over and making it hard to figure out what you're doing. ULA works, as I have here. Multiple interfaces work, as I have done here. The LAN link local address appears to be broken, as it should never try to for fe80::1:1. According to that RFC, duplicate address detection is supposed to be used.

The other things were just what led me to the last thing

The LAN link local address broken is the only thing I am concerned about as it keeps me from trying out multihoming with multi routers.

q54e3w

@JKnott said in IPv6 Routing:

@IsaacFL

I have been using ULA for well over a year. However, one thing I found is that the GUA prefix was no longer automatically assigned. I had to manually add both the ULA and GUA prefixes on the Router Advertisement page.

I’ve been thrown a loop with these interfaces changing on me, could you add a picture of your VIPs and RA pages please? I’be tied myself up in knots over the prefix size which I thought I had right, but folowing a reboot I’m not sure it was ever right. Thanks for useful posts elsewhere on IPv6 they’ve been useful.

Edit: ah, I think I’ve hit the issue around the interface addresses that reorder after a reboot that’s reported on Redmine.

JKnott

@q54e3w

Hers's the RA page. I had to include the prefix from my ISP, as for some reason pfSense doesn't do that when you use ULA

And the VIP page

IsaacFL

@JKnott

Wouldn't this break though if your ipv6 prefix changed dynamically? Any devices on this interface would lose internet connectivity via ipv6.

I thought the only point of trying to use the ULA address, was to try to keep connectivity to things like external DNS, etc. if the prefix changed.

It seems that the real bug here, is that a route isn't automatically added when the subnet is added. If that was done, you wouldn't have to use a VIP which brings in its own issues.

Also are both of these subnets included in "LAN net"?

q54e3w

@JKnott Thank you. I was on the right track and not totally closing my mind.
@IsaacFL My understanding is these workarounds are partly to help mitigate the issue here