Should zone identifier be in X-Forwarded-For IP?

When messing around with Go's http/httputil.ReverseProxy, listening on a local address with a zone, making a request through it locally, including the zone, I've seen that the zone identifier ends up in the X-Forwarded-For header added by the reverse proxy. (You can see it occur around here. SplitHostPort leaves the zone intact.)

Should the zone be in the XFF IP? Does it make sense? Is it a bug?

My not-very-clear understanding of zone identifiers is that it doesn't make sense outside of the particular machine that's using it. On the other hand, maybe if you're trying to trace the path a request took, the zone is necessary to disambiguate?

After thinking about this for a while, I ended up writing a blog post about it. Here is the conclusions section of that post:

Zones should be kept until the point of use, and then the decision to keep or strip them should be based on the specific use of the IP and ramifications of zones to that use.

This means that reverse proxies should be including the zone in the X-Forwarded-For header, rate limiters should probably be discarding them, and prefix-contains-IP checks should be based on whether there's a zone in the prefix. But these are only examples -- there are myriad uses of IP addresses, and the particular use will dictate (or at least inform) the fate of the zone.

Of course, this is all debatable. To see some other other opinions, check out the few comments I got when I asked about this in the r/ipv6 subreddit. If you have a differing opinion or know of anyone else having written about this, please let me know.