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.
ping takes a -I argument you specify which interface to use.
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.
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.
Is there an equivalent syntax for IPv4 addresses?
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.
The Python `ipaddress` library has an `ip_address` address that returns either an IPv4Address or IPv6Address if the passed string is a valid IPv4 or IPv6 address, or throws a ValueError if the address is invalid.
I've seen code that uses that function to determine if a user-supplied string is a valid IP before passing it to a command line. At first glance, that seems fine, but some shell metacharacters are valid in the IPv6 zone ID.
`fe80::1%a;whoami>${PATH:0:1}tmp${PATH:0:1}pwned` is a valid IPv6 IP, and if you did `ping fe80::1%a;whoami>${PATH:0:1}tmp${PATH:0:1}pwned`, you'd have the output of `whoami` written to /tmp/pwned.
Obviously, people shouldn't writing code that puts user input into a shell call without the proper method of execution (ie, shell=False when using subprocess.Popen), but people often think "I validated it, it's fine" and then get popped because their validation wasn't as good as they thought it was.
EDIT: In case it isn't clear, `${PATH:0:1}` is necessary in the attack payload because a `/` is invalid in a zone ID. `${PATH:0:1}` is a tricky way to get a `/` character by just grabbing the first character of your PATH environment variable.
Is this really a Python problem? `subprocess.run` for example defaults to `shell=False` so you have to set `shell=True`, and on top of that be building up argv?
The "default" API for `subprocess.run` has you doing `subprocess.run(["ping", ip])` which... I think just entirely avoids this problem?
There's def a general sort of "oh people will just copy/paste stuff into a shell" or the whole shell script arg escaping mess. Just feels like Python is not really doing anything bad here.
Granted, a lot of software works like that, but the command line was invented as a human interface, we just bungee-strapped a computer instead.
> [fe80::4]:80
I really do wish they'd just stuck with dots. Or if we must upend things, commit to the bit and change the character to separate ports.
Then it would get confused with domain names (e.g. babe.cafe).
URL parsers don't break, the amount of code to change is not that big, and many of the user-space applications can keep working with no changes at all, as long as they use high-level network libraries.
If you really hate this for some reason, use some other characters. How about underscores (_) for example? Those are not valid in DNS, so there is no chance of confusion.
Choosing colon when URLs were already using it is either very stupid or very mean.
Just yesterday I tried to use rsync (like I do all the time, in my mind there's no reason to use scp when rsync does everything better), but this time I needed to specify an IPv6 address. On the (admittedly ancient) rsync version that comes with macOS, this doesn't work:
rsync foo 'user@[fe80::4]:/tmp'
Note already, how I had to put the second argument in quotes, because otherwise the shell tries to expand the square brackets as filename expansion.
But even then rsync just complains, because rsync itself separates host from path through colon. I think the only workaround is to do something like `rsync -e 'ssh user@[fe80::4] ...'`... but I just used an updated rsync from homebrew, which is of course the saner method. Still, just another colon/bracket-caused issue.
Nonetheless I do agree that the choice of colons isn't great due to how it ambiguates their meaning.
If you want to do this properly then you configure a Unique Local Addresses (ULA) out of the range fc00::/7. These are the equivalent of 192.168 or 172.16 or 10. and they can be routed.
Trying to run services on fe80: addresses is a mistake IMHO
These link local addresses are quiet handy. But sadly the parsing of these with modern browsers is a flame war ever since. I assume that's the reason why we don't see its usage that often.
Another nice use case is to use these link local addresses in cloud environments...
To explain, IPv6 link local addresses are like using a MAC address to send packets. You wouldn’t ever host services on a LL address and things that do are doing it wrong. Every v6 router should advertise a ULA prefix to all downstream clients. If you want to connect to your router’s web UI you’d use its universal local address—not its link local—and avoid all of these problems. This is exactly why zones were deemed mistake and replaced by ULAs and this was 10 years ago… at least!
Also what gives you the impression that zones were “deemed a mistake”? They may be awkward in URIs but they are very much not a mistake, they are a deliberate part of ensuring that each link has its own link-local subnet without any ambiguity. It solves the problem of what the operating system should do if you need to access a link-local address that shows up via more than one network interface, which is a very real problem with unscoped IPv4 link-local addresses.
Finally, ULAs don’t and were never intended to replace link-local addresses, they serve a different purpose entirely.
Right, but ULAs are the correct answer here because the purpose they serve is exactly the one the article is trying to hack around with link-local addresses. Like most "IPv6 is hard" articles, the main issue with this one is the author simply refusing to learn how IPv6 works or follow best practices.
ULAs are not hard to set up. You just need one device to broadcast Router Advertisements with the "A" flag set and router priority 0. That device may be the same one hosting the service!
> Also what gives you the impression that zones were “deemed a mistake”?
I disagree that zones are a mistake, but a good rule of thumb is that if you're trying to use zones and you're not writing system code, you're probably holding it wrong. Use IPv6 the right way and your life will be so much easier.
> Having services be accessible on a link-local address and then advertising that service via mDNS is a completely legitimate use-case that works extremely well and is extremely common with Apple devices amongst others.
Apple devices actually advertise services to hostnames via mDNS. Hostnames are then resolved to IP addresses, again via mDNS. While link-local address are populated in the host table, so are the routable addresses as well as the ULA-prefixed addresses (if your network uses ULAs).
mDNS working on link-local means you can advertise your service over mDNS so no user ever types this shit into their address bar in the first place.
I still maintain that the interface leaking into the address is a bad thing from a design perspective even though I very much appreciate that everything works naturally on v6 LL addresses after applying this one small fix… no user should ever by typing a v6 LL into a browser, and probably every use case you can imagine that isn’t managing network link topology or NDP/bootstrap or running LL name resolution can be solved with ULAs or DNS.
Just give me GUAs and be done with it.
Second, if you don't want to use interface IDs, you can just enable ULAs on your networks, and routing will take you to the correct interface.
Ideally, you’d be able to connect a PC and a printer with an Ethernet cable, they would both (having failed to find a better alternative) allocate a link-local address for themselves, and then the PC would use DNS-SD over mDNS to discover the printer and show it to you. Similar story with PCs exporting their media files over the network, a—say—set-top box, and a switch they’re all plugged into.
And for some combinations of parts this actually works. It’s just that the functionality is not always well-exposed by the OS, that a switch + DHCP server in a box (in practice, a consumer router) can work just as well with no configuration as an unmanaged switch can, and that people are not that interested in local-only wired networks anymore.
There’s also the “having failed to find a better alternative” part: unlike with IPv6, the RFC does not endorse always assigning a link-local address as the second one next to a static or DHCP-provided one, I’m guessing for software compatibility. Thus you really only see 169.254.* in your interface configuration when DHCP is borked, and it’s kind of useless in that case.
Yes, but the question is, "what if an address in this range is assigned to _two_ interfaces at the same time?" Now your local routing information base cannot distinguish which interface to use when trying to reach other hosts in that same network. So, it's fair to say, it's not a feature even available in IPv4.
The second difference is IPv6 is almost always going to have link local addresses assigned and machines with multiple network interfaces are the norm rather than the exception.
I also didn't realize that part of the idea behind these LL things was one of the rounds of wishful networking ideas of the 90s or 2000s, kind of a cousin of UPnP and mDNS in that way (in increasing order of eventual usefulness).
Considered completely in a vacuum, especially ignoring the WAN, I can see how it seemed silly that if you plugged three computers and a printer into a switch, rolling random IP addresses like this could have allowed things to be discoverable and to function locally (I thought mDNS or "Bonjour"/"Rendezvous" as Apple called it came much later, but I know my PCs could "see" each other with NetBIOS or whatever long before mDNS was invented).
RFC 6874: Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers (https://www.rfc-editor.org/rfc/rfc6874.html)
Which says that, yes, you need to %-encode the %, so a URL containing a host of fe80::4%eth0 becomes http://[fe80::4%25eth0]/. Yes, that's ugly. Sorry.
> TL;DR: computers were a mistake.
I agree entirely.
(For what it's worth, I am a maintainer of Go's net/url package, and I believe net/url correctly handles zone ids in URLs. It's always possible there's something wrong I'm not aware of. Please let me know if there is!)
> This document completely obsoletes [RFC6874], which implementors of web browsers have determined is impracticable to support [LINK-LOCAL-URI], and replaces it with a generic UI requirement. Note that obsoleting [RFC6874] reverts the change that it made to the URI syntax defined by [RFC3986], so [RFC3986] is no longer updated by [RFC6874]. As far as is known, this change will have no significant impact on non-browser deployments of URIs.
Given that net/url has supported RFC 6874 since before RFC 9844 came along, our choices are:
* Keep supporting the RFC 6874 syntax.
* Drop support for it, require strict RFC 3986, have no support for zone IDs in URLs at all. Breaks existing users, utterly infeasible.
* Stop supporting RFC 6875 and start supporting an unescaped % as the zone ID separator, which conforms to no standard I know of. Also breaks existing users, infeasible.
* Some sort of hybrid where we try to support both %25 and % as a separator? Ugh.
Of these, keeping the existing support as-is until or unless a new standard comes along seems like the best option.
https://github.com/Xe/site/commit/f846b489092412b8c1ef70bebd...
[fe80::4%eth0]:80
About here my I felt my heart start to beat really fast and I started to hyperventilate.
I'll just accept that this is as much of a nightmare as it seems.
At work, I have a rare case of a useful application of IPv6: setting IPv4 addresses. We have multiple embedded devices in one product which all got the same default IPv4. But their serials map to their MACs which map to their link-local IPv6.
So workers scan the serial and I connect to all devices at once via their IPv6 address. Then, I set their individual IPv4 address and that's all I do via IPv6.
I must say, I rather enjoy both IPv6s autoconfiguration, and the fact that my non-link-local addresses are actually unique (and if I want to, routable).
Link-local ipv6 addresses are not designed for the use case of serving web applications.
Routing tables get you to the destination but I think the question is about which source address to use ie which network card/interface to use as source - after all, they are all in fe80::.
For a destination in fe80:: the OS will pick the one on the right interface (in effect the IPv6 version of ARP).
You never use fe80:: as a source for a network beyond fe80:: because it and they are link local addresses. You'll send to the default gateway/GoLR/etc unless you have more explicit routes and set your source address as your IPv6 "identity" which might be one of many.
Anyway, here's your problem:
"But if you try to parse this as a URL in Go, you get an error:"
Go needs fixing!
fe80::/64 dev eth0 proto kernel metric 256 pref medium
fe80::/64 dev eth0.11 proto kernel metric 256 pref medium
fe80::/64 dev eth0.13 proto kernel metric 256 pref medium
fe80::/64 dev eth0.14 proto kernel metric 256 pref medium
fe80::/64 dev eth0.15 proto kernel metric 256 pref medium
fe80::/64 dev eth0.16 proto kernel metric 256 pref medium
That is literally the reason for the metric. You set it if you need your routes to be deterministic.
You need to direct your IP stack which routes are important to you - your IP stack cannot read your mind! You could use a routing protocol and daemon to do the job for you but someone needs to tell it how to work.
NDP. That's a discovery protocol not an elimination protocol. There's no guarantee that a link local address isn't available on multiple networks.
> the OS will pick the one
Linux will simply pick the first entry in the routing table. It may make this appear as if it's working by default or some underlying magic; however, it's literally just the very first entry that matches.
(rationale being that whatwg said no: https://github.com/whatwg/url/issues/392 ; firefox bug https://bugzilla.mozilla.org/show_bug.cgi?id=700999 )
The "solution" is to use a proxy such as https://github.com/twisteroidambassador/prettysocks/tree/ipv... which incidentally encode the % as a `s` and handle special URLs like this http://fe80--1ff-fe23-4567-890as3.ipv6-literal.net for you through the socks dns resolution feature... I've never found anything else that works recently -_-
--- a/netwerk/base/nsURLHelper.cpp
+++ b/netwerk/base/nsURLHelper.cpp
@@ -928,3 +928,3 @@ bool net_IsValidIPv4Addr(const nsACString& aAddr) {
bool net_IsValidIPv6Addr(const nsACString& aAddr) {
- return mozilla::net::rust_net_is_valid_ipv6_addr(&aAddr);
+ return true;
}
bool net_IsValidIPv6Addr(const nsACString& aAddr) {
struct addrinfo *res, hints = {.ai_flags = AI_NUMERICHOST};
int err = getaddrinfo(aAddr.get(), nullptr, &hints, &res);
if (err) return false;
bool isValid = res[0].ai_family != AF_INET;
freeaddrinfo(res);
return isValid;
}
https://devblogs.microsoft.com/oldnewthing/20100915-00/?p=12...
> \\fe80--1ff-fe23-4567-890as3.ipv6-literal.net\share
After you'd get a unique local than thebn would be used for normal routing needs.
Did I get the wrong?
Even though it's rare, I actually do use it if I want to talk to another host on a very specific interface. Sometimes there's multiple paths.
If the mapping between the logical and physical interfaces changes, that probably means that your NICs lack proper IDs to differentiate them or the bus topology is somehow not stably sorted. I wouldn't blame the OS for this.
Now if someone else a URI, is there going to be any confusion on how many times a URI needs to be decoded?
If the answer is yes, then we have a problem.
(and by looking at the other comments in this thread, the answer is most definitely yes)
It seems clear that browsers would need to special case this and implement OS specific rules for what a valid Zone ID is.
Browsers have overloaded the URL/search/AI magic bar for years. I don’t quite see how IPv6 Zone ID are that different. They already auto append or auto hide the www subdomain.
I know it solve some real problem. but the cost for solving those is just too high. A careful planning and manual configuration can avoid those.
IPv6 promised a 128bit address space, but we got 128bit + arbitrary length of string instead. This force lots of complication on to application developer.
This is what happens when language and standard library designers ignore a spec like IPv6 for a couple of decades.
(It basically has to be this way, or the URL syntax would need to be updated to support future address families with their own address formats. New address families can be loaded at runtime, including ones that didn't exist at the time your current software was compiled -- and this is handled properly by the BSD socket API -- so hardcoding possible address formats is incorrect.)
The _only_ character that needs special handling is ], and if you're willing to declare that you can't be bothered to support link-local addresses at all then declaring that you'll support anything except addresses containing a "]" should be far easier.
RFC 3986 says "This syntax does not support IPv6 scoped addressing zone identifiers." Makes sense because '%' is a reserved character for percent encoding (hence the %25 that Go's net/url expects).
The URL Standard explicitly states "Support for <zone_id> is intentionally omitted."
`http::Uri` does, and it accepts both `%` and `%25`.
https://play.rust-lang.org/?version=stable&mode=debug&editio...
If someone gives you a link-local address, you have to know which interface they want you to use, either implicitly or otherwise.