Using Unique Local Addresses
-
@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.
-
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.
-
@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).
-
@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.
-
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.
-
@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.