Use IPv6 DHCPv6, Prefix Delegation without Link-Local (SLAAC)

RobbieTT

@FireDrunk The link-local bit is kind of one of the IPv6 supporting pillars.

There is no NAT involvement with IPv6 (hurray!) as the address space is so large and nobody in the right mind would want NAT anyway - it was a kludge that kept IPv4 viable.

Link-local addresses are not routable on the internet though; typically they use the privacy address (or the actual address) for routing purposes. You always want IPv6 link-local to be working inside an IPv6 capable LAN. They are the glue that holds it all together.

️

FireDrunk

@RobbieTT Yeah, that's what I'm beginning to understand.
That makes having a 'nice' and 'orderly' list of curated IP Addresses for all systems involved in your LAN a bit tedious. For example: I have DHCP Lease Reservations for all machines that require incoming traffic to be regulated. They get addresses in the range <local-scope>.50-100. Devices that do not have a reservation get an address between 100-200. That way I have a better view on what's what.

With IPv6's Link-Local, having a proper 'overview' of which device is using which IP becomes way harder... :-(

JKnott

While global addresses can be used, normally a router provides a link local address for routing. This is part of SLAAC, where all sorts of ICMP6 works over link local. The only time I've seen a global address used is with my VPN, where there isn't a link local address to use. Are you sure you're seeing the WAN address in the router advertisements? That wouldn't make sense. It would be the LAN link local address.

Also, are you sure you want to use DHCPv6? Android devices won't work with it and you already have a persistent address with SLAAC.

JKnott

@Bob-Dig said in Use IPv6 DHCPv6, Prefix Delegation without Link-Local (SLAAC):

Can I force pfSense to push the Router Advertisements from the 'correct' private IPv6 address instead of using the link-local address?

The gateway IPv6 is most of the time (or even always) a link-local address, so no need for "fixing" anything. It is true for pfSense WAN and even for my Windows machines.

Link local addresses are used for a lot, beyond just a gateway address. All of ICMP6 relies on it, as well as some other protocols.

JKnott

@FireDrunk said in Use IPv6 DHCPv6, Prefix Delegation without Link-Local (SLAAC):

To my understanding (which might not be much regarding IPv6), link-local is not required by any means, and having GUA on all nodes with a Router Advertisement on a GUA of a local node for ::/0 is theoretically fine.
Another point: It's my understanding that by just using link-local, you won't have a fully functioning IPv6 connection to the world, since there is no NAT active. That means you cannot contact the outside world because no route back is available.
This makes having a link-local address on the interface pretty useless, because IPv6 would almost exclusively be used to access the internet, and not anything local (for now).

Link local addresses are absolutely essential for the functioning of IPv6. ICMP6 relies on it. It has nothing to do with the route back. A router needs to know only the next hop to the destination. It doesn't even need a link local address. With a point to point link, only the interface is needed. The route back is based on a routing protocol, such as OSPF or BGP, but it still works out to the next hop.

Why are you even thinking about NAT. It's not needed with IPv6. NAT is a hack to get around the IPv4 address shortage and in turn causes it's own problems. Best to forget it ever existed.

JKnott

@FireDrunk

You're worried about global addresses, not link local. LL addresses don't leave the LAN.

RobbieTT

@JKnott said in Use IPv6 DHCPv6, Prefix Delegation without Link-Local (SLAAC):

Why are you even thinking about NAT. It's not needed with IPv6.
Best to forget it ever existed.

Praise be.

FireDrunk

I know NAT is no longer used (or even useful) in IPv6, and I don't want to use it. What I do want is order in my network, and (pseudo-)random IP's kind of get my OCD going...

For now my configuration (that should work):

IPv6 Subnet Delegation on my WAN and Track Interface on my LAN.
I have DHCPv6 in Managed mode, which says nodes should use DHCPv6 instead of SLAAC, which is what I prefer (I know it's not required).

On a linux node:

2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether xx::xx brd ff:ff:ff:ff:ff:ff
    altname enp0s31f6
    inet 192.168.1.3/24 brd 192.168.1.255 scope global eno1
       valid_lft forever preferred_lft forever
    inet6 <public-ipv6>::3/128 scope global dynamic noprefixroute
       valid_lft 4121sec preferred_lft 1421sec
    inet6 fe80::<mac-address>:f247/64 scope link
       valid_lft forever preferred_lft forever

Routes:

<public-ipv6>:: dev eno1 proto kernel metric 256 expires 1822sec pref medium
<public-ipv6>::/64 dev eno1 proto kernel metric 256 expires 82735sec pref medium
<public-ipv6>::/64 dev eno1 proto ra metric 1024 expires 86368sec pref medium
default via fe80::<link-local-of-router> dev eno1 proto ra metric 1024 expires 1768sec mtu 1500 pref medium

Which all seems fine.
I can:

Use IPv6 DNS properly
Ping IPv6 Hosts
Use HTTP to IPv6 Hosts

What doesn't work:

I cannot use HTTPS to IPv6 Hosts

root@nas:~# curl -vvv -6 www.ip6.nl
*   Trying 2a01:4f8:c010:a08c::1:80...
* Connected to www.ip6.nl (2a01:4f8:c010:a08c::1) port 80 (#0)
> GET / HTTP/1.1
> Host: www.ip6.nl
> User-Agent: curl/7.74.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 301 Moved Permanently
< Server: nginx
< Date: Thu, 01 Jun 2023 16:51:51 GMT
< Content-Type: text/html
< Content-Length: 162
< Connection: keep-alive
< Location: https://ip6.nl/
<
<html>
<head><title>301 Moved Permanently</title></head>
<body>
<center><h1>301 Moved Permanently</h1></center>
<hr><center>nginx</center>
</body>
</html>
* Connection #0 to host www.ip6.nl left intact
root@nas:~# curl -vvv -6 https://www.ip6.nl
*   Trying 2a01:4f8:c010:a08c::1:443...
* Connected to www.ip6.nl (2a01:4f8:c010:a08c::1) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):

My firewall allows any IPv6 on the LAN interface, but nothing specifically on the WAN interface besides DHCPv6

JKnott

@FireDrunk said in Use IPv6 DHCPv6, Prefix Delegation without Link-Local (SLAAC):

I cannot use HTTPS to IPv6 Hosts

If you can use HTTP but not HTTPS to hosts, then it's nothing to do with IPv6 addresses. My bet would be on firewall rules on the host.

FireDrunk

@JKnott I've added an any/any rule on both WAN & LAN interface, and it still fails. It also fails consistently on all clients (Both Windows & Linux), which makes me believe it's a pfSense config issue.

I'm running 2.6.0.

JKnott

@FireDrunk

Where are the hosts? Local? And the clients? If both on the LAN, then pfSense has nothing to do with it. However, as I said, it's not an IPv6 or address issue, if HTTP works and HTTPS doesn't.

FireDrunk

@JKnott The host is on the regular interwebs, clients are on the LAN interface.

I've just tested it from the CLI of the pfSense machine and it works fine on the machine itself:

*   Trying 2a01:4f8:c010:a08c::1:443...
* Connected to ip6.nl (2a01:4f8:c010:a08c::1) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
*  CAfile: /usr/local/share/certs/ca-root-nss.crt
*  CApath: none
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: CN=ip6.nl
*  start date: May 10 13:11:37 2023 GMT
*  expire date: Aug  8 13:11:36 2023 GMT
*  subjectAltName: host "ip6.nl" matched cert's "ip6.nl"
*  issuer: C=US; O=Let's Encrypt; CN=R3
*  SSL certificate verify ok.
* Using HTTP2, server supports multiplexing
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x801497800)
> GET / HTTP/2
> Host: ip6.nl
> user-agent: curl/7.80.0
> accept: */*
>
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
* Connection state changed (MAX_CONCURRENT_STREAMS == 128)!
< HTTP/2 200
< server: nginx
< date: Thu, 01 Jun 2023 18:37:20 GMT
< content-type: text/html
< content-length: 10713
< last-modified: Wed, 01 Mar 2023 05:02:43 GMT
< etag: "63fedc73-29d9"
< accept-ranges: bytes
<
<!DOCTYPE html>
*snip*

I've tried disabling extra services that might interfere (don't know why, but testing couldn't hurt) like OpenVPN & HAProxy.

FireDrunk

This post is deleted!

keyser

@FireDrunk Even though this is not what you want to hear, you need to get to terms with your OCD because IPv6 is just not as tidy as IPv4.

Link Local is essential and needed for IPv6 to work, and the link local address on a host is the same on all interfaces (with the added %interfaceidentifier). It takes a while to get used to, but the real “OCD Killer” is the privacy features of IPv6 where hosts takes on dusins of IP addresses in the same /64 for different sessions over time (to not originate from one known IP). Firewall rules is EXTREMELY difficult compared to IPv4 if tight control is needed.

The whole original idea behind IPv6 is that we should no longer care about the client devices addresses - they should be very dynamic and resolvable by name only. But the needed DNS delivery and update features never really matured to that level (especially not in pfsense).
So we are back to trying to manage something that humans are not designed to cope with in terms of dynamics….

I am a huge fan of IPv6, but honestly I think they botched it so badly with first insisting on slaac (that was not DNS feature complete), and now turning so heavily to DHCPv6 that Slaac is not really a good solution any more. This might see IPv6 take another 20 years to finally become the prevalent protocol.

JKnott

@keyser said in Use IPv6 DHCPv6, Prefix Delegation without Link-Local (SLAAC):

and now turning so heavily to DHCPv6 that Slaac is not really a good solution any more

SLAAC now included RDNSS, which provides the DNS server. Just use the consistent address for DNS.

keyser

@JKnott said in Use IPv6 DHCPv6, Prefix Delegation without Link-Local (SLAAC):

SLAAC now included RDNSS, which provides the DNS server. Just use the consistent address for DNS.

Yes I know it was just pretty late to the party, and there is still no completely standardized way of asking - or if desired - requiring clients to automatically register their address in DNS when an address is aqquired. So we are still left with having to use a DHCP server, and have that register leases in DNS (Which incidentally never worked properly in pfSense).
So nameresolution is still crap, and with mac addresses going random combined with privacy session IPv6 adresses, we are on the path of complete lack of transparancy.

RobbieTT

@keyser said in Use IPv6 DHCPv6, Prefix Delegation without Link-Local (SLAAC):

This might see IPv6 take another 20 years to finally become the prevalent protocol.

There are probably experiences on this forum that differ by country or continent, when it comes to how networking, the internet, and ISP access works for them.

I've lived in the States, so I have a reasonable understanding of how disjointed things can be with internet access, the lack of common standards between ISPs and no common or national backhaul. But it is also the county that pushed the internet so hard with early adoption and product design, albeit slightly blinkered when it comes to what other continents do.

I now live in the UK; here the IPv6 adoption was rapid, supported at a national level, interfacing with the wider Europe and hosting all the early links across the Atlantic. IPv6 adoption by ISPs at core level was decades ago and IPv6 support by ISPs is universal. As such, most of the UK population has little appreciation of what protocols are in use or that most of their traffic is handled via IPv6.

Those of us who have more advanced networking needs clearly need to know more but even here I just note that over 65% of my household web-browsing is via IPv6 and most external DNS resolution happens via IPv6. In all respects IPv6 is the prevalent protocol, at least here.

Looking at the remaining IPv4 traffic a great deal of it comes from the US and, as a predominantly English-speeking nation, a great deal of our internet traffic comes from the States. The US has become an outlier with IPv6 adoption, for many reasons. Regrettably there are many network products designed in the 'Silicon Valley Experience' that have significant deficiencies in IPv6 support that then cascade to the bigger, global market - effectively spreading poor IPv6 experience to other countries (Ubiquity springs to mind, amongst many others).

I look at IPv4 as the poor relation to IPv6 - it is in a different league. I have more control with IPv6, more options and a massive 'free' address space. It is more prevalent, tends to be faster and offers a better experience. If we could just get the US to embrace it and fully support it in all their designs, the world would run just a little bit smoother!

️

keyser

@RobbieTT Yes, and I agree with that idea - even coming from denmark where IPv6 is nonexistant outside of a few small ISPs.
IPv6 is just not present in denmark - i think it has an adoptionrate of less than 5% if we discount 4/5G Mobile connections.

If just Google, Facebook, youtube, Tiktok and Twitter would gang up and say: Hey: on january 1. 2025 non of social media platforms are available on IPv4, we could end this 20 year debacle. That would cause ALL ISP's that wish to survive past 2025 to adopt IPv6 NOW, and then there is really no need to support IPv4 for more than a few additional years because only slow enterprises would not have gone IPv6 at that time.

RobbieTT

@keyser Yep, Denmark is a slow adopter but it looks like the pace of adoption is increasing:

2023-06-02 at 12.42.34.png

️

JKnott

@RobbieTT

Part of the reason for the U.S. being so slow with IPv6 goes back to when IPv4 was created and most of the addresses went to the U.S.. As a result it didn't have the pressure of the IPv4 address shortage as the rest of the world did. Of course, when it was originally set up, it wasn't intended to be world wide. It was just to support defense researchers and grew from there. Also, back then, there wasn't a lot of data crossing the pond, as there wasn't much capacity until fibre came along.