[donnachangstein]

> Can anyone explain to me if there is any way to determine whether an inbound IPv6 address is "local"?

No, because it's the antithesis of IPv6 which is supposed to be globally routable. The concept isn't supposed to exist.

Not to mention Google can't even agree on the meaning of "local" - the article states they completely changed the meaning of "local" to be a redefinition of "private" halfway through brainstorming this garbage.

Creating a nonstandard, arbitrary security boundary based on CIDR subnets as an HTTP extension is completely bonkers.

As for your application, you're going about it all wrong. Just assume your application is public-facing and design your security with that in mind. Too many applications make this mistake and design saloon-door security into their "local only" application which results in overreaction such as the insanity that is the topic of discussion here.

".local" is reserved for mDNS and is in the RFC, though this is frequently and widely ignored.

[ryanisnan]

It's very useful to have this additional information in something like a network address. I agree, you shouldn't rely on it, but IPv6 hasn't clicked with me yet, and the whole "globally routable" concept is one of the reasons. I hear that, and think, no, I don't agree.

[donnachangstein]

Globally routable doesn't mean you don't have firewalls in between filtering and blocking traffic. You can be globally routable but drop all incoming traffic at what you define as a perimeter. E.g. the WAN interface of a typical home network.

The concept is frequently misunderstood in that IPv4 consumer SOHO "routers" often combine a NAT and routing function with a firewall, but the functions are separate.

[rerdavies]

It is widely understood that my SOHO router provides NAT for IPV4, and routing+firewall (but no NAT) for IPV6. And provides absolutely no configuability for the IpV6 firewall (which would be extremely difficult anyway) because all of the IPV6 addresses allocated to devices on my home network are impermanent and short-lived.

[vel0city]

You can make those IPv6 IP addresses permanent and long-lived. They don't need to be short-lived addresses.

Also, I've seen lots of home firewalls which will identify a device based on MAC address for match criteria and let you set firewall rules based on those, so even if their IPv6 address does change often it still matches the traffic.

[mixmastamyk]

There’s something about ip6 addresses being big as a guid that makes them hard to remember. Seem like random gibberish, like a hash. But I can look at an ip4 address like a phone number, and by looking tell approximately its rules.

Maybe there’s a standard primer on how to grok ip6 addresses, and set up your network but I missed it.

Also devices typically take 2 or 4 ip6 addresses for some reason so keeping on top of them is even harder.

[vel0city]

A few tips:

When just looking at hosts in your network with their routable IPv6 address, ignore the prefix. This is the first few segments, probably the first four in most cases for a home network (a /64 network) When thinking about firewall rules or having things talk to each other, ignore things like "temporary" IP addresses.

So looking at this example:

   Connection-specific DNS Suffix  . : home.arpa
   IPv6 Address. . . . . . . . . . . : 2600:1700:63c9:a421::2000
   IPv6 Address. . . . . . . . . . . : 2600:1700:63c9:a421:e17f:95dd:11a:d62e
   Temporary IPv6 Address. . . . . . : 2600:1700:63c9:a421:9d5:6286:67d9:afb7
   Temporary IPv6 Address. . . . . . : 2600:1700:63c9:a421:4471:e029:cc6a:16a0
   Temporary IPv6 Address. . . . . . : 2600:1700:63c9:a421:91bf:623f:d56b:4404
   Temporary IPv6 Address. . . . . . : 2600:1700:63c9:a421:ddca:5aae:26b9:a53c
   Temporary IPv6 Address. . . . . . : 2600:1700:63c9:a421:fc43:7d0a:7f8:e4c8
   Link-local IPv6 Address . . . . . : fe80::7976:820a:b5f5:39c3%18
   IPv4 Address. . . . . . . . . . . : 192.168.20.59
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . : fe80::ec4:7aff:fe7f:d167%18
                                       192.168.20.254

Ignore all those temporary ones. Ignore the longer one. You can ignore 2600:1700:63c9:a421, as that's going to be the same for all the hosts on your network, so you'll see it pretty much everywhere. So, all you really need to remember if you're really trying to configure things by IP address is this is whatever-is-my-prefix::2000.

But honestly, just start using DNS. Ignore IP addresses for most things. We already pretty much ignore MAC addresses and rely on other technologies to automatically map IP to MAC for us. Its pretty simple to get a halfway competent DNS setup going on, so many home routers will have things going by default, and its just way easier to do things in general. I don't want to have to remember my printer is at 192.168.20.132 or 2600:1700:63c9:a421::a210 I just want to go to http://brother or ipp://brother.home.arpa and have it work.

[bombela]

At home, with both ip v4 and v6. For any device exposed on the Internet, I add a static IPv6 address with the host part the same as the IPv4 adress.

example: 2001:db8::192.168.0.42

This makes it very easy to remember, correlate and firewall.

[ryanisnan]

That makes sense. I do love the idea of living in a world without NAT.

[fiddlerwoaroof]

I don’t: NAT may have been a hack at first, but it’s my favorite feature provided by routers and why I disable ipv6 on my local network

[TheDong]

Why do you like NAT?

Does your router being slower and taking more CPU make you feel happy?

Do you enjoy not seeing the correct IP in remote logs, thus making debugging issues harder?

Do you like being able to naively nmap your local network fairly easily?

[mixmastamyk]

Perf concerns over 32bit numbers ended in the nineties. Who at home cares about remote logs?

[fiddlerwoaroof]

I like all the computers in my house appearing to remote servers as a single remote host. Avoids leaking details about my home network.

[rerdavies]

@donnachangstein:

The device is an IoT guitar pedal that runs on a Raspberry Pi. In performance, on stage, a Web UI runs on a phone or tablet over a hotspot connection on the PI, which is NOT internet connected (since there's no expectation that there's a Wi-Fi router or internet access at a public venue). OR the pi runs on a home wifi network, using a browser-hosted UI on a laptop or desktop. OR, I suppose over an away-from-home Wi-Fi connection at a studio or rehearsal space, I suppose.

It is not reasonable to expect my users to purchase domain names and certs for their $60 guitar pedal, which are not going to work anyway, if they are playing away from their home network. Nor is ACME provisioning an option because the device may be in use but unconnected to the internet for months at a time if users are using the Pi Hotspot at home.

I can't use password authentication to get access to the Pi Web server, because I can't use HTTPS to conceal the password, and browsers disable access to javascript crypto APIs on non non-HTTPS pages (not that I'd really trust myself to write javascript code to obtain auth tokens from the pi server anyway), so doing auth over an HTTP connection doesn't really strike me as a serious option either..

Nor is it reasonable to expect my non-technical users to spend hours configuring their networks. It's an IoT device that should be just drop and play (maybe with a one-time device setup that takes place on the Pi).

There is absolutely NO way I am going to expose the server to the open internet without HTTPS and password authentication. The server provides a complex API to the client over which effects are configured and controlled. Way too much surface area to allow anyone of the internet to poke around in. So it uses IP/4 isolation, which is the best I can figure out given the circumstances. It's not like I havem't given the problem serious consideration. I just don't see a solution.

The use case is not hugely different from an IoT toothbrush. But standards organizations have chosen to leave both my (hypothetical) toothbrush and my application utterly defenseless when it comes to security. Is it any surprise that IoT toothbrushes have security problems?

How would YOU see https working on a device like that?

> ".local" is reserved for mDNS and is in the RFC, though this is frequently and widely ignored.

Yes. That was my point. It is currently widely ignored.

[mixmastamyk]

Grandparent explained that a firewall is also needed with ip6.

I understand that setting it up to delineate is harder in practice. Therein lies the rub.

[AStonesThrow]

> can't even agree on the meaning of "local"

Well, who can agree on this? Local network, private network, intranet, Tailscale and VPN, Tor? IPv6 ULA, NAT/CGNAT, SOCKS, transparent proxy? What resources are "local" to me and what resources are "remote"?

This is quite a thorny and sometimes philosophical question. Web developers are working at the OSI Layer 6-7 / TCP/IP Application Layer.

https://en.wikipedia.org/wiki/OSI_model#Comparison_with_TCP/...

Now even cookies and things like CSRF were trying to differentiate "servers" and "origins" and "resources" along the lines of the DNS hierarchy. But this has been fraught with complication, because DNS was not intended to delineate such things, and can't do so cleanly 100% of the time.

Now these proposals are trying to reach even lower in the OSI model - Layer 3, Layer 2. If you're asking "what is on my LAN" or "what is a private network", that is not something that HTTPS or web services are supposed to know. Are you going to ask them to delve into your routing table or test the network interfaces? HTTPS was never supposed to know about your netmask or your next-hop router.

So this is only one reason that there is no elegant solution for the problem. And it has been foundational to the way the web was designed: "given a uniform locator, find this resource wherever it may be, whenever I request it." That was a simpler proposition when the Web was used to publish interesting and encyclopedic information, rather than deliver applications and access sensitive systems.