[Tharre]

"IPv6 is weird. One of the more strange parts of the standard is that every interface's link local addresses are in fe80::whatever`."

How is IPv6 weird here, it's the exact same thing in IPv4, no? If you have two different network interfaces, you have to identify which is which somehow, either by assigning a specific IP range to it or by adding some kind of identifier.

Making zones part of addresses in the first place was probably a mistake, I agree, but the problem of address conflicts when users can choose arbitrary addresses certainly isn't a design flaw of IPv6.

[WhyNotHugo]

It's not the same as IPv4. IPv4 doesn't solve this problem. If eth0 and eth1 are both 169.254.0.20 on two different networks, you can't specify that you want to ping 169.254.0.1 on a specific interface. There's no way to disambiguate both destinations.

[fragmede]

https://linux.die.net/man/8/ping

ping takes a -I argument you specify which interface to use.

[sznio]

except in ipv4 getting a link-local address means "I fucked up DHCP" and isn't really meant to be a feature it didn't really work in ipv4 land, and as per the OP, doesn't work in ipv6 land too. Just give everything a proper address and leave link-local to mdns or whatever it was meant to support

[throw0101a]

> except in ipv4 getting a link-local address means "I fucked up DHCP" […]

No, it means "there is no infrastructure on this link segment". No router (to send out IPv6 RAs), and (as you say) no (working) DHCP server.

Still being able to have network connectivity automatically in this scenario can still be handy. If mDNS is running on things, then the user doesn't even have to bother manually setting an address: the link light comes on and you have connectivity to the local segment.

[trumpdong]

A link-local address necessarily needs a way to specify a link, and the link is local to the sending host and not something the receiving host knows. I suppose they could have used the upper address bits, but the sending host would need to know to convert them to 0 when sending the packet out on the wire, and with the interface ID when receiving.

[masfuerte]

There aren't address conflicts. And users aren't choosing this, it's part of the IPv6 spec. Each interface has a unique address, but you can't tell from looking at an address which network it lives on.

[ivlad]

Not really.

Nothing prevents host from configuring a static link-local address, like fe80::1234. Not only that, some networks choose to have some standard link local address as a default gateway. For example, a router or a L3 switch can have fe80::1 on its downstream interfaces. This way, all hosts on all networks have fe80::1 as the default gateway and the router will have fe80::1 address on multiple interfaces.

Furthermore, you can (and some say, should) use link local addresses on transit links between your network devices, eg, between layers of switches in a hyperscale-sized data center network. Typically, the addresses will be deterministically configured, for example, consider

-(e1.0)[switch1](e1.1)—--(e2.48)[switch2](e2.25)-(eth0)[server1]

We have server1 connected to top-of-rack switch2 connected to aggregator switch1. Link between switch1 and switch2 is point-to-point transit. You can use exclusively link local addresses there. There are a few approaches:

- e2.48 gets fe80::2, e1.1 gets fe80::1 - all upstream ports are always fe80::2 in all network, all downstream ports are always fe80::1. A good thing is that link configuration is the same on all switches regardless of the Clos layer.

- switch1 serial number is 1001, switch2 serial number is 2002. Then, e2.48 gets fe80::2002, e1.1 gets fe80::1001. This way, all interfaces on a switch N have address fe80::N

You then can set up BGP session between the link local addresses and it either will always be either fe80::1 <-> fe80::2 or fe80::N <-> fe80::M. Switches also have a loopback address for ping, and other ICMP traffic. Either has advantages and disadvantages.

This is discussed in more details in RFC 6164, and a more high level overview is provided in RFC 7404.

[themafia]

> you have to identify which is which somehow

The _routing_ system does. You have the same problem if you have multiple public IPs on a machine. Your local routing will not automatically return packets back through the address they came to. They will go to the _default_ route. So if you have this configuration you need to setup either the routing tables or the firewall to re-route packets "back out" the proper interface or IP address.

This is strictly a routing problem and not an addressing problem.

[josephcsible]

I think the weirdness comes from the use of multiple addresses at once, specifically fe80::whatever addresses always being present and getting used even on normal setups when everything's working fine and a global address is configured, as opposed to 169.254.whatever addresses, which most networks never intend to use and so usually only show up when something is wrong.

[nine_k]

Isn't 127/8 always present in IPv4, without I'll consequences?

[josephcsible]

I meant it's one address per interface, and loopback has always been its own interface.

[trumpdong]

One address per host is more common in serious networks that don't have endless IP addresses (10/8 block) allocated to them.

[dcrazy]

There is no problem with allocating one 127.0.0.0/8 to every interface on your host, because 127.0.0.0/8 is only ever accessible to the host itself. So even if you have multi-homed a single routable IPv4 address to 2 NICs on your server (for redundancy), you can still assign 127.0.0.1 to the first and 127.0.0.2 for the second, which you can then use to bind a port to a specific interface in the pair. (I don’t know if anyone actually does this.)

[trumpdong]

How would the receiving host know which 127 address you imagined belongs to it?

[farfatched]

The title of the post suggests the issue is allowing that syntax in URLs.

Is there an equivalent syntax for IPv4 addresses?

[toast0]

No, IPv4 doesn't have the concept of addresses that are scoped to a particular interface.

Rfc3927 which standardizes the use of 168.254.0.0/16 for ipv4 link local was published in 2005, mentions scoped addresses but does not offer any solutions.

However, nothing really relies on ipv4 link local addressing, and most networks don't use it. It's a conceptual problem that these are interface scoped addresses and there's no (standard) way to specify them to applications, but it doesn't cause actual problems.

On the other hand, ipv6 neighbor discovery uses ipv6 link local addresses, so they have to work. And you might try to use them for other things... but then you need to pass through the scope. It's kind of ugh when it causes problems.