IPv6 Routing

smaxwell2

Hi All,

First off, I am very new to IPv6 (still learning) and trying to get my head around this.

I use the FRR Package - OSPF to Dynamically Route IPv4 around my network, which works perfectly. To distribute the "Default IPv4 Route" from my master routers, I tick the box "Redistribute a Default route to neighbors" and the "site" nodes pickup the Master Routers as their 0.0.0.0/0 route for Internet Access (along with other Internal Routes)

I have just enabled IPv6 on my network, and have enabled OSPF6 within FRR. This is working perfectly to distribute internal IPv6 Routes (SERVER-1 can ping SERVER-2 and vice versa). However there is no longer an option within OSPF6 to " Redistribute a Default route to neighbors". I am sure this is my lacking of IPv6 understanding.

On my master routers WAN Ports I have a /64, and my ISP Routes me a /48 to the CARP IPv6 Address on the Master's WAN Ports.

I have then split this /48 into lots of /64's which I use within my network. Internet Connectivity is not working on the "site" side of the network (SERVER-2). SERVER-1 has working IPv6 Internet access.

I am currently setting client IPv6 addresses manually. And I have not enabled DHCP6 / SLAC / RA

When doing a tracert from SERVER-2 to SERVER-1 I get the following:

1 <1 ms <1 ms <1 ms 2a02:2658:xxxx:2::241
2 9 ms 9 ms 10 ms 2a02:2658:xxxx:1::1
3 10 ms 10 ms 9 ms 2a02:2658:xxxx::1

When doing a tracert from SERVER-2 to Google IPv6 Public DNS Servers I get the following:

Tracing route to dns.google [2001:4860:4860::8888]
over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms 2a02:2658:xxxx:2::241
2 * * * Request timed out.
3 * * * Request timed out.
4 * * * Request timed out.
5 * * * Request timed out.
6 * * * Request timed out.

Am I missing something simple here ? Any pointers ?

pfadmin

you always need to advertise routes from routers via RA. I think, the answers don't come back because of missing routes. Enable RA, no need for SLAAC or DHCPv6

JKnott

@pfadmin

Is he talking about just the next router or using OSPF to advertise routes? RAs are only used to advise the next hop router. There's an entire OSPF protocol for advertising routes to elsewhere. I'm not entirely sure which he's referring to, but I suspect OSPF. Even without SLAAC, he should be seeing neighbour advertisements, etc..

IsaacFL

@JKnott
I have never been able to try out multiple pfsense routers like this and have always wondered if it would work. I tried setting up a multihome configuration once with 2 pfsense routers and it didn't work.

The reason, is that pfsense hardcodes fe80::1:1 onto the LAN interfaces. So you can't have 2 pfsense routers on the same layer 2 network without breaking Router Announcements, and Router Discovery which are all link local based.

So the configuration on the right, I don't believe will work with ipv6. I have always assumed that pfsense could only be used on the edge gateway because of that.

pfadmin

Ok, that fe80::1:1 is good practice. But why can I not change it to my needs? Please look at thread Link Text only the pictures. there are other than fe80::1:1 gateways. Some picture shows it on all interfaces, others only at vlan interfaces. how does it work?

JKnott

@IsaacFL

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.