6 ms·

Let's maybe hope that they'll make an exception for the RFC1918/4193 ranges. Of course, the other side of the coin of is that even a "private" network could be

Let's maybe hope that they'll make an exception for the RFC1918/4193 ranges. Of course, the other side of the coin of is that even a "private" network could be anything from your private home to your workplace intranet to an airport wi-fi hotspot, and can't be assumed to be safe from snooping/injection. As for your particular hassle, it makes sense to me for a browser to mark sites that mix http/https as insecure from the point of view that once the data is on the plain http page you can no longer be sure that it won't be handed off over an unencrypted connection some place else by some rogue javascript. Perhaps a rather drastic change like this will lead to more user friendly ways to install self-signed certificates on home networks. Say, a method for routers to discover certificates announced by devices on the network to list them in its management interface where you can enable or disable them.

zAy0LfpBZLC8mAC 9y ago
> Let's maybe hope that they'll make an exception for the RFC1918/4193 ranges. Of course, the other side of the coin of is that even a "private" network could be anything from your private home to your workplace intranet to an airport wi-fi hotspot, and can't be assumed to be safe from snooping/injection. That would be idiotic not just because unrusted parties can use those addresses, but more importantly because those are more or less terrible hacks that should be avoided completely if possible. You rather should have globally unique addresses on your internal network if you can, which would just break this. > Perhaps a rather drastic change like this will lead to more user friendly ways to install self-signed certificates on home networks. That's also not sensible. The whole idea of linking stuff to specific networks is bad. There is no reason why access to a device on your home network should in any way be linked to your client device being connected to that same network. It's the internet, not "the home network and the cloud". What is needed is a way to establish a trust relationship between two devices that you have control over. Where those devices happen to be connected to the internet should be absolutely irrelevant. There might be an argument to be had to maybe support for a simplified peering procedure on a local network might be a good idea--but the point is that once the trust trelationship is established, you should be able to move your client device to a different network on the other side of the planet and still be able to talk to your device on your home network.
- dcow 9y ago
  I guess you missed the whole IPv6 scoped addressing architecture memo.
  - zAy0LfpBZLC8mAC 9y ago
    Like what specifically?
    - dcow 9y ago
      A) Scopes aren't a hack they're part of the protocol. B) Scopes are exactly: "the global internet and the home". Considering those things why should it be absurd if I want to secure my home scope at the application layer too? IPv6 is literally designed to allow for this. Browsers are the things that are being stubborn. If IPv6 is just a terrible collection of hacks then we need a new version and fast before everyone get stuck on v6 for the next 50 years....
      - zAy0LfpBZLC8mAC 9y ago
        What scopes specifically would you suggest are "the global internet and the home" in the sense that is applicable here?
        dcow 9y ago
        In IPv6 one interface has many addresses. Each one can have: 1. global addresses, 2. rotating temporary global addresses, 3. universal local addresses (one for each site), and 4. a link-local address (required). The first 3 now technically reside in the global scope. ULAs used to be called site-local and had their own scope, but they were restructured to basically be fancy UUIDs and their scope abolished and merged with the global scope. Link-local is still its own scope. Although both are globally scoped, there's a difference between a global IPv6 address and a ULA. The global is globally routeable and prefixes are organized regionally and delegated to allow hierarchical routing while ULAs have arbitrary prefixes (not suitable for global routing) and are not supposed to be forwarded to interfaces outside their subnet. So to answer your question, for local communications in your home that you didn't want leaving your network, you would use ULAs. You could use link-local addresses if your home was all on the same l2 link, but the generally preferred solution is to use ULAs so you don't leak protocol details upwards and so you can leverage l3 tunnels. Local DNS is allowed to respond with ULAs, just not servers participating in the global authoritative DNS. If you want DNS on your home site you simply run a local DNS server that resolves your local names and is configured to forward unknown names to the global DNS. IPv6 kills NAT, so "scoped" addresses step in to fill the void and are overall a much better solution.

zAy0LfpBZLC8mAC 9y ago

> Let's maybe hope that they'll make an exception for the RFC1918/4193 ranges. Of course, the other side of the coin of is that even a "private" network could be anything from your private home to your workplace intranet to an airport wi-fi hotspot, and can't be assumed to be safe from snooping/injection. That would be idiotic not just because unrusted parties can use those addresses, but more importantly because those are more or less terrible hacks that should be avoided completely if possible. You rather should have globally unique addresses on your internal network if you can, which would just break this. > Perhaps a rather drastic change like this will lead to more user friendly ways to install self-signed certificates on home networks. That's also not sensible. The whole idea of linking stuff to specific networks is bad. There is no reason why access to a device on your home network should in any way be linked to your client device being connected to that same network. It's the internet, not "the home network and the cloud". What is needed is a way to establish a trust relationship between two devices that you have control over. Where those devices happen to be connected to the internet should be absolutely irrelevant. There might be an argument to be had to maybe support for a simplified peering procedure on a local network might be a good idea--but the point is that once the trust trelationship is established, you should be able to move your client device to a different network on the other side of the planet and still be able to talk to your device on your home network.

dcow 9y ago
I guess you missed the whole IPv6 scoped addressing architecture memo.
- zAy0LfpBZLC8mAC 9y ago
  Like what specifically?
  - dcow 9y ago
    A) Scopes aren't a hack they're part of the protocol. B) Scopes are exactly: "the global internet and the home". Considering those things why should it be absurd if I want to secure my home scope at the application layer too? IPv6 is literally designed to allow for this. Browsers are the things that are being stubborn. If IPv6 is just a terrible collection of hacks then we need a new version and fast before everyone get stuck on v6 for the next 50 years....
    - zAy0LfpBZLC8mAC 9y ago
      What scopes specifically would you suggest are "the global internet and the home" in the sense that is applicable here?
      - dcow 9y ago
        In IPv6 one interface has many addresses. Each one can have: 1. global addresses, 2. rotating temporary global addresses, 3. universal local addresses (one for each site), and 4. a link-local address (required). The first 3 now technically reside in the global scope. ULAs used to be called site-local and had their own scope, but they were restructured to basically be fancy UUIDs and their scope abolished and merged with the global scope. Link-local is still its own scope. Although both are globally scoped, there's a difference between a global IPv6 address and a ULA. The global is globally routeable and prefixes are organized regionally and delegated to allow hierarchical routing while ULAs have arbitrary prefixes (not suitable for global routing) and are not supposed to be forwarded to interfaces outside their subnet. So to answer your question, for local communications in your home that you didn't want leaving your network, you would use ULAs. You could use link-local addresses if your home was all on the same l2 link, but the generally preferred solution is to use ULAs so you don't leak protocol details upwards and so you can leverage l3 tunnels. Local DNS is allowed to respond with ULAs, just not servers participating in the global authoritative DNS. If you want DNS on your home site you simply run a local DNS server that resolves your local names and is configured to forward unknown names to the global DNS. IPv6 kills NAT, so "scoped" addresses step in to fill the void and are overall a much better solution.