Using Unique Local Addresses

[awebster]

@jknott According to RFC4193 fc::/7 is set aside for this purpose, and pp3.1 further clarifies that locally assigned ULA prefixes are to be allocated in fd::/8, whereas fc::/8 is reserved for future use.

You could also presumably use NPt to translate the ULA into a GUA address space thereby replicating the behavior of the RFC1918 address space, although one of the underlying features of IPv6 is to specifically not need to do NATing, not to mention protocol breakage that may ensue.

It boggles the mind how many providers don't understand how IPv6 is supposed to work and vendors who deliver solutions that only go 90% of the way leaving you to fend for yourself for the remaining 10%.

[JKnott]

@awebster

My understanding is that fc:: /8 was to be used with an external prefix server, but that never happened, so all of fc:: /7 is now used for locally assigned addresses. However, to keep things pure, just use fd , as I do here.

I'm allergic to NAT.

I agree that many providers and others don't understand fully how IPv6 works, because they're stuck in the IPv4 world. I've come across this with my own ISP that otherwise is quite good with IPv6. When I had a problem a couple of years ago, I found I had to explain the finer points of DHCPv6-PD and link local routing to the 2nd level help desk and a senior tech. I wrote this article to address some questions that have popped up here.

[johnpoz]

@awebster said in Using Unique Local Addresses:

It boggles the mind how many providers don't understand how IPv6 is supposed to work and vendors who deliver solutions that only go 90%

Same here, but I think your giving them too much credit with the 90% number ;)

[JKnott]

There's another method to generate a random number. At the FreeBSD or Linux command prompt, enter the command ps aux|shasum, which will return a 40 digit random number.

ps aux|shasum
23501cdc1873bf37181127051dff8384df2132af -

ps aux lists system processes and shasum generates a hash of it.

[JKnott]

@jknott

One thing I forgot to mention. You'll need to create a DNS Access List entry to cover the range of ULA addresses used. This can be done individually for each interface or block of ULA used on your network. I used a /56 block to cover any ULA on my network.

[Decepticon]

I know that this is an old topic, but I wanted to add a question here as well as a rant about the continuing rejection of NAT in IPv6 (which is reflected in JKnott's statement that he is allergic to NAT).

I do want to preface my comments by saying that my questions are serious. I do really want to know the answers to these questions. And my rant is not a personal attack on JKnott or anyone else, but rather simply my observations on the subject of NAT.

Questions/Comments:

When using the ULAs recommend by JKnott here, how do devices get their ULAs?

1. Are they assigned via SLAAC? If so, that's a potential problem for me, because SLAAC methodologies may change, and thus SLAAC addresses may change.

2. Is there a way to get pfsense to do DHCPv6 assignments in the ULA prefix rather than in the tracked interface prefix?

FYI- My Ubiquiti Edgerouter has allowed DHCP servers to make assignments outside of the primary interface range for ten+ years. And PFsense can easily handle routing from those interfaces by assigning a Virtual IP.

Rant (Begins)

I'm a huge fan of NAT. NAT works perfectly to allow the use of a single, local IP address and an easy to write set of routing/firewall rules. That's the reason why most people use it on home routers in the IPV4 setting.

Even if NAT was initially designed to address the lack of address space in IPv4 and even if that use is not needed in IPv6, NAT works perfectly to allow the use of a single, consistent, easy to type IP address in home environments. And that continues to be important for home and small office users, even when using IPv6. Saying that you shouldn't use NAT other than for its original purpose is like saying that the internet was initially developed by DARPA for military use, and so consumers should not use it to watch Netflix.

While NAT certainly has some shortcomings in the rare case where someone wants to operate a server, its benefits greatly outweigh them for the vast majority or home and small office users. So far, in order to avoid NAT, the IPv6 crowd wants us to assign at least three IP addresses to every interface (LLA, GUA, and ULA), none of which are easy to remember or type.

The solution to that, we're told, is to set-up every device with an easy to remember DNS entry. To make that work, however, you'll need to use your router as your DNS server, giving up the benefits of browser based DOH and DNS over TLS. You could, of course, set-up a public DNS system, but that's even more work. And if your devices suddenly come up with a new SLAAC method, the DNS entry will stop working.

And if your prefix can change (which is true of 99% of the home users), then you may have to completely rewrite all of your firewall rules. It appears that pfsense allows you to replace the prefix in firewall rules with "::" (which seems to work but is not documented anywhere that I can find). Other firewalls use negative prefixes to address this issue. ULAs won't solve the firewall issue because ULAs cannot route to the internet (except when you NAT). Since there's no consistency on how to handle firewall rules when a prefix changes, I have to assume that the IPv6 designers just didn't consider this issue at all. The same trick works in the DHCPv6 server on pfsense, but only if you're using tracked interfaces. DHCPv6 appears to break immediately if you use "::" as the prefix when the interface is not tracked. And using "::" as a substitute for the network prefix is not consistent with the IPv6 addressing scheme.

To address the privacy issue created by using GUAs, we add privacy addresses, which can add dozens more IP addresses to every device and further make routing rules difficult. But, we're told that IP based routing is not real security because IP addresses can be spoofed, and that the solution is VLAN hardware. Never mind that VLANs can be spoofed as well.

And all of this is in the name of having end-to-end global addresses so that everyone could theoretically run their own globally addressable servers, which 99% of home users don't care about anyways, and which many large institutional settings (convert venues, schools, etc.) actively seek to block.

Put simply, I don't need my rice cooker, my FireTV, or my fridge to have a global internet address. For better or worse, I don't want them to have a global address.

We're also told that NAT offers no security benefit, even though everybody knows that obscurity and privacy are a form of security. And even the IPv6 crowd's argument that NAT offers no security breaks down when they admit that the use of GUAs in a VPN could cause traffic to go out on the internet without encryption if the VPN goes down or is misconfigured.

Even worse, a single misconfigured firewall rule combined with GUAs could mean that every device in your network could be reached from the internet. NAT makes that error impossible to make. The solution to that, we're told, is to ensure that the humans configuring the routing firewall rules don't make a mistake. In a world where humans are infallible and everyone who subscribes to internet service is a trained network engineer, there is no benefit to using NAT. But, that world doesn't exist.

In the end, NAT is a simple elegant solution that allow me to use a single, statically assigned and easy to type and remember address for all of the devices in my home/small office network. It is far superior to having 10+ IP addresses for every device on my network, forcing me to use a local DNS server (or configure a global DNS to resolve LUAs), and having to re-write firewall rules every time my prefix changes. NAT's main downside, that every device on my network will not have a global address is totally irrelevant to me and to 99% of home users.

Fortunately, I have been pleased to find that the people who write netfilter (and pfsense) have implemented NAT for ipv6 and it seems to work perfectly. The only issue that I have now is that Android refuses to use DHCPv6 and so I have to enable SLAAC to make them work on my network. Even then, however, NAT works just fine.

I can't help but think that IPv6 was designed by and for tech companies, without regard to the desired use case for small offices, home offices, and even large institutional venues that are not tech companies. End to end addressing (which I don't need and don't care about) has been elevated above all else.

I have never used NAT to address the shortage of IPv4 addresses, and I don't care if it was designed for that purpose. I have always used NAT to allow me to assign an easy to remember/type IP address to the devices on my LAN. My router has always been 10.10.1.1/24. On IPv6, I'm seriously considering using "fc00::1/64", and since "1::" is not part of the GUA range and is reserved for future assignment, I may even just use "1::1/64" for my router until it breaks.

With NAT, I can assign one, easy to remember (and easy to type) local address to every device on my network and be certain that it will never change. My firewall rules will never change, even if my ISP changes my IPv6 address. As long as I get at least ONE public IPv6 address from my ISP, I do not care whether my ISP is "doing IPv6 right" (which is a common problem noted in these forums). I don't have to bother with setting up DNS, or with the possibility that my devices will decide to change their IPv6 addresses without telling me.

NAT elegantly gave me exactly what I wanted. The only problem NAT created for me is that my SIP server wants RTP ports to be unmangled. So, I set an outbound NAT rule giving it static access to RTP ports. Others will just forward the ports, which is a greater security risk and not necessary. But, it's still far easier (and less risky) then than GUA, ULA, DNS, Negative Prefixes, and all the other stuff that IPv6 has invented to avoid NAT.

So to those who say that NAT is dead, I say "Long Live NAT!"

[JKnott]

@Decepticon said in Using Unique Local Addresses:

Are they assigned via SLAAC? If so, that's a potential problem for me, because SLAAC methodologies may change, and thus SLAAC addresses may change.

I use SLAAC. I suppose ULA could be assigned with DHCPv6, but I don't know if it can be used to provide both ULA and global addresses. SLAAC can do both.

I'm a huge fan of NAT. NAT works perfectly to allow the use of a single, local IP address and an easy to write set of routing/firewall rules. That's the reason why most people use it on home routers in the IPV4 setting.

Are you planning on making devices on your LAN accessible from outside? Or just locally? If only locally, ULA does exactly what you want in that the prefix won't change unless you change it. I don't know about the prefix changing with 99% of home users, though it is an issue for some. I've had my prefix for almost 6 years even though both my modem and the computer I run pfSense on have been changed in the mean time.

The solution to that, we're told, is to set-up every device with an easy to remember DNS entry. To make that work, however, you'll need to use your router as your DNS server, giving up the benefits of browser based DOH and DNS over TLS. You could, of course, set-up a public DNS system, but that's even more work. And if your devices suddenly come up with a new SLAAC method, the DNS entry will stop working.

Setting up a DNS resolver on pfSense is easy. Not sure what you're complaining about here. One benefit is you can set up aliases for some sites if you want. For example, I have my notebook computer configured to use pool.ntp.org for the NTP server and that's what I access when away from home. But at home, that connects to the pfSense NTP server, which gets it's time from some public NTP servers, including 3 stratum 1. Even before I started using IPv6, I had my own DNS server, as I didn't want to keep updating the hosts files on my devices.

As for using ULA, the main reason is so you have consistent local addresses, even if your ISP changes your global prefix. However, it can also be used as the only prefix for things like IoT, should you want to keep them entirely off the 'net.

As for security, this is the pfSense forum and it provides, surprise, surprise, a firewall. NAT provides nothing that a firewall can't and even NAT can leak.

I have never used NAT to address the shortage of IPv4 addresses, and I don't care if it was designed for that purpose.

Really? How many devices do you have on your network? How many addresses do you get from your ISP? If the number of devices is greater than the number of addresses then you're using it to get around the address shortage.

The only problem NAT created for me is that my SIP server wants RTP ports to be unmangled.

This is just one example of the problems NAT causes. To use SIP and some games, you need a STUN server to report your WAN address, when you're on your LAN's NAT addresses. NAT breaks things.

I can't help but think that IPv6 was designed by and for tech companies, without regard to the desired use case for small offices, home offices, and even large institutional venues that are not tech companies. End to end addressing (which I don't need and don't care about) has been elevated above all else.

Or maybe the problem is those who are stuck on IPv4 and can't be bothered to learn about the improvements IPv6 brings.

[Decepticon]

@JKnott

Thank you very much for taking the time to respond. I've been reading a lot of posts here before I posted my message today, and I know that you're an institution here. I've found a lot of value in your posts, and I appreciate that you volunteer your time here to help others. Thank you for engaging me in a civil, but spirited discussion.

@JKnott said in Using Unique Local Addresses:

Are you planning on making devices on your LAN accessible from outside? Or just locally?

Generally, I don't make my devices available from the outside. But, if I wanted to, I'd much rather do it via VPN, which offers encryption that GUA IPv6 does not offer.

@JKnott said in Using Unique Local Addresses:

If only locally, ULA does exactly what you want in that the prefix won't change unless you change it.

ULA does not do exactly what I want.

What I want is for every device on my network to have an easy to remember and easy to type IP address that I can use with firewall rules to control ingress and egress.

Because ULA is not routable (except via NAT), ULA cannot be the subject of firewall rules at all. I have to use the GUA, which can change if the prefix changes, in my firewall rules.

ULA is also not easy to remember or type. Even if I control the suffix via DHCPv6, I still have to remember and type the ULA portion of the prefix. And why does it need to be random? The argument in favor of a truly "unique" ULA is that I might someday merge my network with someone else's. This may be a concern for tech companies, but it's not a concern for home users.

@JKnott said in Using Unique Local Addresses:

I don't know about the prefix changing with 99% of home users, though it is an issue for some.

If the MAC address on your WAN port changes, you're almost certain to see your GUA change at some point.

Even if it never changes, the risk that it might change means that the whole benefit of GUAs a fallacy. If you set up your whole network assuming that every device has a unique GUA, and your ISP changes your prefix, every device on your network gets a new IP address. All external references have to be redone and if your router hasn't adopted some non-standard mechanism for referencing the prefix using a variable, all the internal references do as well.

With NAT, I can just pick an easy to type, local address for each device and be confident that they will never change unless I change them.

@JKnott said in Using Unique Local Addresses:

Setting up a DNS resolver on pfSense is easy. Not sure what you're complaining about here.

Well, I've set-up the DNS resolver on pfSense, and I can tell you that setting up the outbound NAT rule for IPv6 was far easier.

Arguably, once you know how DNS works (and I do), you can enable Unbound fairly quickly, but then manually entering all the GUAs or ULAs and giving them local domains names takes a long time, especially if you have a lot of devices that you need to address on your network. And see above re: the risk that they change and you have to do it all over again.

@JKnott said in Using Unique Local Addresses:

As for using ULA, the main reason is so you have consistent local addresses, even if your ISP changes your global prefix. However, it can also be used as the only prefix for things like IoT, should you want to keep them entirely off the 'net.

That's not quite true. If the ULA is assigned by SLAAC, it could change if the device decides to use a different SLAAC method.

With NAT, I don't have to worry about any of that. I can just set a non-unique local address for everything based upon my preferences. My file server can be fc00::500/64. My router can be fc00::1/64. They will never change.

And in the unlikely event that I want to keep something off the internet entirely, I can do that with a firewall rule, or even by creating a unique subnet with no router attached to it.

@JKnott said in Using Unique Local Addresses:

Really? How many devices do you have on your network? How many addresses do you get from your ISP? If the number of devices is greater than the number of addresses then you're using it to get around the address shortage.

Because I use NAT, I only need one IP address from my ISP. I can have 100,000 devices, and I still only need one. As long as I get one, I don't care how many they have left. Having more IP addresses is my ISP's problem, not mine. And with IPv6, I hear that they have an unlimited number. Again, I still only need one.

@JKnott said in Using Unique Local Addresses:

This is just one example of the problems NAT causes. To use SIP and some games, you need a STUN server to report your WAN address, when you're on your LAN's NAT addresses. NAT breaks things.

I don't think that it's fair to say that NAT breaks things, any more than it is fair to say that a firewall breaks things.

By virtue of its design, NAT prevents some things from working. Firewalls do that as well.

NAT can be configured to allow things that are not NAT friendly to work (as in my example with my SIP server). That's not a reason to scrap NAT. And in the last decade, most applications have been NAT friendly.

In the case of SIP that I mentioned, NAT wasn't the problem. It's the port mangling that pfSense adds to NAT. This was not a problem with my Ubiquiti Edgerouter, which was based on Debian and did not mangle ports when doing NAT like pfSense does.

PfSense says that port mangling in NAT is a matter of security, which is hilarious given that they also say that GUA's in connection with IPv6 aren't a security concern at all.

@JKnott said in Using Unique Local Addresses:

I can't help but think that IPv6 was designed by and for tech companies, without regard to the desired use case for small offices, home offices, and even large institutional venues that are not tech companies. End to end addressing (which I don't need and don't care about) has been elevated above all else.

Or maybe the problem is those who are stuck on IPv4 and can't be bothered to learn about the improvements IPv6 brings.

So you read my detailed explanation of why I want to use NAT on IPv6 and you came away with the impression that I could not be bothered to learn about the difference between IPv4 and IPv6?

My post was all about NAT and IPv6, and was not a comparison of IPv4 and IPv6. I think that you've forgotten that if you use IPv4 without NAT, you would still have all the same problems that I'm trying to avoid, e.g., you'd be using random IP addresses assigned by your ISP that could change at any time.

Let me make this clear: Suppose that, tomorrow, 3/4 of the world stopped using the internet, and suddenly, there were tons of IPv4 addresses available. As a result, every device in my house could now have its own IPv4 address and there would be plenty left. If you came to me and told me that I should stop using NAT, and let my ISP give me a publicly routable IPv4 address for every device in my home because NAT's only purpose was to address exhaustion, I would give you the same answer that I wrote in my original post, but without the discussion of ULAs. My post is about NAT, and is agnostic to the addressing scheme. The only reason I mentioned IPv6 and IPv4 in my post was that they are factual background. My comments apply whether we're talking about IPv4, IPv6, or even whatever comes next.

But, since you brought it up...

The primarily benefit of IPv6 is a larger address space, which addresses IPv4 exhaustion. As I mentioned before, this is primarily a concern for my ISP. As long as I can get one public IP address so that I can send out traffic and get traffic back from the internet, my needs are met.

An ancillary benefit of having a larger address space is that every device on my network can have a GUA, and ULA, and dozens of privacy addresses. But, as I've written before, I don't need any of these things, and I don't want them. My primarily concern for devices on my LAN is an easy to type consistent IP address that will never change.

I'm quite happy to use IPv6. As I said before, I'd love to name my router:

fc00::1/64

and my file server

fc00::900/64

In other words, when it comes to IPv6, I want the benefits of IPv6 (a massive address space to keep my ISP happy and even shorter local addresses than 10.10.x.x.), but I still want every device on my network to have an easy to type, non-public address, that can be routed through my public IP address. I want all of those addresses to stay the same unless I choose to change them. With NAT on IPv6, I can get all of the benefits of IPv6's larger address space. The only benefit that I don't get is the benefit that I don't care about.

So, as I said before, the argument that NAT is not needed on IPv6 is fallacious. NAT on IPv6 allows me to use IPv6 and get its massive address space, without having to worry that my ISP will change my prefix, or my devices will decide to change their addresses spontaneously. I can set-up an easy to type and easy to remember addressing scheme, with firewall rules that I'll never have to worry about changing. And I won't have to enter it all into my local DNS server.

NAT does have some downsides, but for the average home user, the benefits greatly outweigh them, even on IPv6.

[Decepticon]

@JKnott said in Using Unique Local Addresses:

Are they assigned via SLAAC? If so, that's a potential problem for me, because SLAAC methodologies may change, and thus SLAAC addresses may change.

I use SLAAC. I suppose ULA could be assigned with DHCPv6, but I don't know if it can be used to provide both ULA and global addresses. SLAAC can do both.

I can't find a way to get pfSense to allow me to use GUA and ULA, and to have the ULAs assigned via DHCPv6. To use GUA reliably, the LAN needs to be set-up to track the WAN interface. The ULA can be set-up as you described in your original post (by using a Virtual IP and Router Advertisement), but the ULA can only be assigned via SLAAC. Pfsense seems to only have the ability to use DHCPv6 on the primary subnet assigned to the LAN port.

If you run across a way to use a Virtual IP's subnet on the DHCPv6 on pfSense (or any way to have DHCPv6 assign ULAs and still use GUAs), I'd love to know how to do it.

(And because I want to head off the "that's impossible posts" that I've seen elsewhere in response to similar questions, I want to reiterate that my Ubiquiti Edgerouter has been able to hand out DHCP addresses outside of the primary subnet assigned to an interface for more than a decade).

[johnpoz]

@Decepticon said in Using Unique Local Addresses:

I want to reiterate that my Ubiquiti Edgerouter has been able to hand out DHCP addresses outside of the primary subnet assigned to an interface for more than a decade).

And how is that? how does the dhcp server know which IP to hand out? Pfsense has never setup this ability.. Sure you can run a dhcp server somewhere and have other devices relay dhcp from another network and get an IP - but in the relay the source of the dhcp discover or request is added.

This is for sure possible with ISC, it was never enabled in pfsense because why - you would have to ask the developers.. But to be honest if you are to the point where you want central dhcp - you prob shouldn't be running that on your firewall.. pfsense can relay dhcp to some central server.

But how would a dhcp server running on the same L2 network know that hey hand out GUA to this guy, but ULA to that guy when they are all on the same network.

[Decepticon]

@johnpoz

Well, it would only work with static assignments. But, as with any static DHCP assignment, the server receives the MAC address of requesting device, looks up the IP address and subnet in a database, and then sends that matching IP/subnet back to the device.

You are correct that Pfsense refuses to allow me to enter a static IP/subnet that doesn't match the primary interface, but that's an arbitrary limitation. Pfsense probably assumes that I wouldn't want to be allowed to enter a different IP/subnet because it wouldn't route. But that assumption ignores the fact that if I set-up a virtual IP, that different IP/subnet will route just fine.

I find it interesting that the same assumption was not made in the case of router advertisements and SLAAC, which have no problem giving out IP/subnets that are outside of the primary subnet assigned to the interface. In fact, there's a whole field in the router advertisement module just for this purpose, and as long as you set-up a virtual IP, devices which assign themselves IP addresses via SLAAC outside of the primary interface's subnet will route just fine.

[JKnott]

@Decepticon said in Using Unique Local Addresses:

Because ULA is not routable

It most certainly is. It's just not allowed on the Internet. It's the same with RFC1918 addresses on IPv4. Also, with both global and ULA addresses, the global address will be used when you go out to the Internet. If you're trying to remember addresses, you're doing it wrong. Use DNS. This is the way things should be done on IPv4 too. The ULA doesn't have to be random. You can use any address within the ULA range you want. Using a random source is just to reduce the risk of address collisions.

If the MAC address on your WAN port changes, you're almost certain to see your GUA change at some point.

See my earlier note about my prefix lasting almost 6 years even though I've changed both the computer I run pfSense on and also my cable modem. The MAC address has changed on both. You retain the prefix because it's set in a file called DUID (DHCP device identifier).

If you set up your whole network assuming that every device has a unique GUA, and your ISP changes your prefix, every device on your network gets a new IP address.

Again, if you're only accessing devices locally, use the ULA address instead of the global.

but then manually entering all the GUAs or ULAs and giving them local domains names takes a long time

Setting up a DNS is something you should be doing, whether on IPv4 or IPv6.

That's not quite true. If the ULA is assigned by SLAAC, it could change if the device decides to use a different SLAAC method.

You can configure the router advertisements to provide either global or ULA addresses. It's done on the Router Advertisement page. That's the way I have it set up as shown here:

I don't think that it's fair to say that NAT breaks things, any more than it is fair to say that a firewall breaks things.

It's absolutely fair. The first thing I heard about NAT breaking was FTP, back in the days when FTP over the Internet was commonplace. NAT required FTP to be used in passive mode, which most clients of the day didn't do passive. When browsers became popular, they used passive mode and would then work with NAT. Since then, there's been SIP for VoIP, games, IPSec authentication headers and possibly more that I haven't heard of. Firewalls shouldn't prevent things from working, provided they are allowed.

In the case of SIP that I mentioned, NAT wasn't the problem.

NAT is the problem as SIP has to use the address of the end device but if you're behind NAT, it needs the WAN address, which requires using STUN and then NAT has to be configured to connect to the right device. As for GUA security, with SLAAC, you get one consistent address, which you'd use for incoming connections and up to 7 temporary addresses for outgoing, with a new address every day.

Let me make this clear: Suppose that, tomorrow, 3/4 of the world stopped using the internet, and suddenly, there were tons of IPv4 addresses available.

That would result in only 4 billion addresses which might be fine for you, but is nowhere near enough for the Internet. However, if you want to do that, why not go back to Novell's IPX? It had 48 bits for local host addresses.

Also, if you are so worried about configuring short addresses then you can locally assign whatever MAC you want and then use the consistent address based on it. This way, you could have a ULA address like fc::7.

[Decepticon]

@JKnott said in Using Unique Local Addresses:

Again, if you're only accessing devices locally, use the ULA address instead of the global.

ULAs do not solve the problem that I want to solve for the reasons I've explained previously.

@JKnott said in Using Unique Local Addresses:

Setting up a DNS is something you should be doing, whether on IPv4 or IPv6.

No, it isn't.

@JKnott said in Using Unique Local Addresses:

That's not quite true. If the ULA is assigned by SLAAC, it could change if the device decides to use a different SLAAC method.

You can configure the router advertisements to provide either global or ULA addresses. It's done on the Router Advertisement page. That's the way I have it set up as shown here:

Your statement is not responsive to my assertion that addresses assigned by SLAAC can change.

@JKnott said in Using Unique Local Addresses:

I don't think that it's fair to say that NAT breaks things, any more than it is fair to say that a firewall breaks things.

It's absolutely fair. The first thing I heard about NAT breaking was FTP, back in the days when FTP over the Internet was commonplace. NAT required FTP to be used in passive mode, which most clients of the day didn't do passive. When browsers became popular, they used passive mode and would then work with NAT. Since then, there's been SIP for VoIP, games, IPSec authentication headers and possibly more that I haven't heard of. Firewalls shouldn't prevent things from working, provided they are allowed.

This is semantics. FTP was incompatible with NAT. Now, we have SCP and HTTP, both of which work fine with NAT. As an aside, FTP was a horribly insecure method of file transfer, and if NAT hastened FTP's demise, that's just another reason to love NAT.

@JKnott said in Using Unique Local Addresses:

In the case of SIP that I mentioned, NAT wasn't the problem.

NAT is the problem as SIP has to use the address of the end device but if you're behind NAT, it needs the WAN address, which requires using STUN and then NAT has to be configured to connect to the right device.

What you're describing is a historical problem with early SIP stacks that was resolved more than a decade ago.

CHAN_SIP and pjsip both have an option that allows them to use IP headers instead of the SIP headers. Everyone uses it now. It works fine with NAT.

@JKnott said in Using Unique Local Addresses:

That would result in only 4 billion addresses which might be fine for you, but is nowhere near enough for the Internet. However, if you want to do that, why not go back to Novell's IPX? It had 48 bits for local host addresses.

You have missed the point of my my hypothetical.

Suppose that there were only 1,000 people using the internet. 4 billion would be plenty. If you urged me to drop NAT because there were plenty of publicly available IPv4 addresses to go around, I would respond exactly as I have here. Exhaustion was my ISPs problem. IP exhaustion is not the reason that I use NAT. I use NAT for other reasons that have nothing to do with exhaustion.

@JKnott said in Using Unique Local Addresses:

Also, if you are so worried about configuring short addresses then you can locally assign whatever MAC you want and then use the consistent address based on it. This way, you could have a ULA address like fc::7.

I'm not worried about this problem because NAT takes care of it.

Also, most devices don't have the ability to locally assign a MAC, nor to choose whether SLAAC uses the MAC address or some other method.

[JKnott]

@Decepticon said in Using Unique Local Addresses:

This is semantics. FTP was incompatible with NAT. Now, we have SCP and HTTP, both of which work fine with NAT.

Back when I started using the Internet, in the early 90s, browsers were not common and there were apps like FTP, wais, gopher and more, doing the things that are now rolled into browsers. In fact, when I first started my dial up connection used SLIP, as PPP wasn't yet commonly used. This meant I had a static public address way back then. This was also around the time it was becoming obvious there weren't enough IPv4 addresses. Also, as I mentioned, FTP was compatible with NAT, but only in passive mode. Few people had heard about HTTP or SCP back then.

What you're describing is a historical problem with early SIP stacks that was resolved more than a decade ago.

STUN still needed? Thought so.

[Decepticon]

@JKnott said in Using Unique Local Addresses:

What you're describing is a historical problem with early SIP stacks that was resolved more than a decade ago.

STUN still needed? Thought so.

No. In fact, I've never had to use STUN.

I've run a dozen SIP servers in the last 15 years, and still have two running as I type this. We have internal trunks that connect from behind a NAT to another behind a NAT. We have external trunks that connect from behind a NAT to an ITSP.

NAT=yes in the PEER details is all that's required. You usually don't even need to forward any ports. There are still lots of guides claiming otherwise from pfSense users, but setting up static port rules is all that you actually need, and then only for RTP traffic.

[Decepticon]

@JKnott said in Using Unique Local Addresses:

Back when I started using the Internet, in the early 90s, browsers were not common and there were apps like FTP, wais, gopher and more, doing the things that are now rolled into browsers. In fact, when I first started my dial up connection used SLIP, as PPP wasn't yet commonly used. This meant I had a static public address way back then. This was also around the time it was becoming obvious there weren't enough IPv4 addresses. Also, as I mentioned, FTP was compatible with NAT, but only in passive mode. Few people had heard about HTTP or SCP back then.

Back when I started using computers in the 1980s, I used an Apple ][+ with an Apple Cat modem and could get 1200 baud transfers, but only when we were connected to another Apple Cat. We could also do two-way chat while transferring warez. When we connected to a friend with a Hayes Micro-modem, it was only 300 baud. It was usually faster to walk over to his house and hand him a floppy disk.

When the internet came around, people had these discussions on Usenet, and Godwin's law was announced. I mention this because I remain very happy that our discussion has remained civil. :)

[JKnott]

@Decepticon said in Using Unique Local Addresses:

I've run a dozen SIP servers in the last 15 years, and still have two running as I type this. We have internal trunks that connect from behind a NAT to another behind a NAT. We have external trunks that connect from behind a NAT to an ITSP.

I have also set up VoIP PBXs and phones on hosted PBX. When you get away from internal systems, as you describe, how does a phone elsewhere in the world contact one of your phones, when SIP/RTP is supposed to use the end address of the device? It can't. It requires STUN or a server acting as a proxy to accept the call.

Incidentally, 4G (VoLTE) and 5G (VoNR) phones use IPv6 precisely for this reason. Having all those phones behind NAT networks would be a horrible mess to try to work through.

One other issue, which you haven't mentioned is when someone is stuck behind carrier grade NAT. In that case, even something as simple as a VPN is not possible, without something acting as a relay.

[JKnott]

@Decepticon said in Using Unique Local Addresses:

Back when I started using computers in the 1980s, I used an Apple ][+ with an Apple Cat modem

My first computer was an IMSAI 8080, which I bought as a kit in 1976. A few years later I got a 300B manual modem. I got it so my wife could dial into a VAX 11/780 computer at work, to play Adventure.

I designed and built from scratch the serial port board to connect my modem and a couple of other devices to.

[Decepticon]

@JKnott said in Using Unique Local Addresses:

I have also set up VoIP PBXs and phones on hosted PBX. When you get away from internal systems, as you describe, how does a phone elsewhere in the world contact one of your phones, when SIP/RTP is supposed to use the end address of the device? It can't. It requires STUN or a server acting as a proxy to accept the call.

When you want an offsite phone to connect to a SIP server, you have lots of options. The most secure and easiest is a VPN. You can also use a public IP address. Neither require STUN or a proxy to accept the call. But, given that SIP servers are notoriously insecure, I would never place one of my own SIP servers on the internet.

My preference is to set-up a SIP server on site with the phones it supports. That way, if the internet goes down, the local phones still work. No phone has to reach out to a SIP server on the internet. You can then configure SIP or IAX trunks connecting each of the servers to one another, and connecting to the ITSP. Ideally, the SIP Servers in each physical location will communicate to one another over a VPN.

When you do it this way, none of the SIP Servers or phones need public IP addresses. It can all be done behind NAT, without forwarding any ports. And, again most importantly, the internal phones work to call each other even when the internet is down.

The only connection that needs to be on a publicly available internet address is the ITSP.

Incidentally, when Verizon began offering SIP Service, they would only allow you to connect to their SIP servers over a dedicated VPN. I don't think that they even offer SIP service anymore, though.

@JKnott said in Using Unique Local Addresses:

Incidentally, 4G (VoLTE) and 5G (VoNR) phones use IPv6 precisely for this reason. Having all those phones behind NAT networks would be a horrible mess to try to work through.

I'm only advocating NAT for home users like myself. If I ran a 5G network, I probably wouldn't use NAT.

@JKnott said in Using Unique Local Addresses:

One other issue, which you haven't mentioned is when someone is stuck behind carrier grade NAT. In that case, even something as simple as a VPN is not possible, without something acting as a relay.

I'm not advocating for carrier grade NAT. I'm advocating NAT for home use with IPv6. It seems unlikely that a carrier will ever need to NAT IPv6 at the carrier level.

[Decepticon]

@JKnott said in Using Unique Local Addresses:

My first computer was an IMSAI 8080, which I bought as a kit in 1976. A few years later I got a 300B manual modem. I got it so my wife could dial into a VAX 11/780 computer at work, to play Adventure.

I designed and built from scratch the serial port board to connect my modem and a couple of other devices to.

At what age did you get your Ham Radio license??? :)