Using Unique Local Addresses
-
@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.
-
@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.
-
@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.
-
@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.
-
@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. :)
-
@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.
-
@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.
-
@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.
-
@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??? :)
-
@Decepticon said in Using Unique Local Addresses:
At what age did you get your Ham Radio license??? :)
18
In addition to that 300B modem, I had an interface to my radio for radio teletype and I also had a model 35 ASR teletype and with the serial board I built and software I wrote, I could have them all running a the same time, with the software converting between Baudot and ASCII for the radio.
BTW, at the time I did all that I was a computer tech with a telecom company, maintaining the big systems, not PCs.
-
I was younger than you when I got mine, but based upon your other historical background, I suspect that you're a few years older than me as well. Too bad we didn't know each other back then. I think we would have had a lot of fun.
Thank you again for engaging with me in this discussion, and for keeping it civil. I've enjoyed the discussion, and look forward to communicating with you again.
