Lower 64 bits all zero - Appropriate to use such an address?

[snarked]

I am aware that the pedantic answer is no.  However, I have noticed that an occasional IPv6 user comes into my server (usually, the web server) with the low 64 bits all zero, and I deny the connection.  Is there any good reason why I should change this behavior?  I thought that the all 64-bits-zero address was supposed to be for the network to mark itself, and during autoconfiguration, to represent a host that doesn't know its full address but does know its own network prefix.

I raise the question here because I noted other HE users using such addresses when they fetch my avatar image (which is actually stored on my server, not on HE's forum server).

[kcochran]

May be that they're coming from a /48 and for whatever reason are using an all-zeroes lower /64, which would technically be legal, much as using a all zero lower 8 bits within a /23 or larger IPv4 block is legal.  It's definitely unusual, but I don't think it's outright verboten.

[snarked]

Although a subset of what I'm seeing, when I see queries from a HE /48 allocation, I also note that the fourth quad is all zeros as well as the /64 LSBs (thus they are using an address with 80 LSB zeros).

Considering the pedantic view, aren't /48's supposed to be divided into multiple /64's, so such doesn't really change anything?

[lukec]

You can divide your /48 into any longer mask as long as the mask is contiguous...I use /126 for my p-t-p (don't use a /127  - may conflict) and /128 for my lo interfaces. Looks like an all zeros last two octects is legal and actually works...
Last two octets in a /128 is valid.
Regards
lukec

[avongauss]

Answering a question with a question admittedly, but why deny the connection?  I doubt I would ever intentionally configure a host to use such an address, and I'm not an expert, but I can't think of any reason why it would be invalid or really advantageous to block the connection.

[snarked]

Why deny these?  Because I deny all accesses that have invalid constructs since the vast majority of them are spambots.  I also deny other stupid things such as having a reverse DNS entry ending in ".local", ".private", or ".invalid"; all of which I have actually logged at one time or another.  Additionally, I have seen reverse entries of "localhost" for other than 127.0.0.1/8 or ::1/128, and even some which had only "." in the PTR-RR.  Tell me why I should allow any of that?


Under various IPv6 autoconfiguration schemes, an address of all-zeroes for the 64 LSBs may be used ONLY when a host knows (or has learnt) its /64 prefix but still doesn't know its LSBs (an intermediate step between "::" and a fully-specified IPv6 address).

[snarked]

Follow-up:  Here's a "live" yet invalid PTR I found in my logs today (IPv4):

  89-149-244-240.local (89.149.244.240)

So why should I allow such stupidity?

[avongauss]

For mail anti-spam techniques I would probably block it as well, but for a non-sensitive web service I don't know that I would personally worry about it that much.

[maestroevolution]

While I wholeheartedly agree in blocking all of the garbage traffic coming from the Internet, in this case you may be dropping legitimate traffic.  In the IPv4 scenario, you definitely would be.

Traffic from the all zero host of a subnet is invalid.  However, the destination server can never be certain what the source's subnet mask is.  If you assume that the source network has a /64 mask, then yes, a lower /64 all-zero's host would be invalid.

But, what if the subnet mask is something other than a /64?  A /60, /48, or anything less than a /64?  (I don't see why you would in IPv6, as a /64 is ridiculously huge to begin with.)

In the IPv4 equivalent, you would drop traffic from any address ending in .0, (i.e 68.24.10.0), on the assumption that the subnet mask is /24.  But, that's an assumption... and incorrect.  In my previous life working for a mobile IP carrier, the address pools for mobile phones were subnetted from /16s down to /20s.  We occasionally received tickets from users who reported that they couldn't reach certain websites, and found that those servers were blocking traffic from any address in .0 or .255, as they assumed a /24 subnet mask.
I've personally called... well, one of the major news companies, and one of the major search engine providers for accidentally blocking our customer's traffic.  Not surprisingly, it's hard to find the correct person to talk to with issues like this.

Heck, our own DNS guy contributed to the problem once... he generated reverse DNS entries for every address except the .0 and .255, so if a user had either of those addresses, they would have a slow response from anything that does a reverse dns lookup (mail servers and vpn concentrators especially).

My two bits,

Joel

[snarked]

cf. IPv4:  Back when we had "classful networking," then an /8, /16, or /24 (depending on which range the first octet belonged to) could easily be determined.  With today's classless CIDR, it takes a "whois" record to determine the netmask of the network.  However, this practice does not scale to IPv6.

Under IPv6, even auto-configuration (radvd) operates as if /64 defines a network (or network segment) for which an all-zero 64 LSBs indicates a host that doesn't know its own address.  Larger allocations (/32 through /63) typically indicate multiple network segments.  Therefore, I don't see any case where the 64 LSBs all zero would be an assignable address to a host.  Put another way, if the 64 MSBs differ, then the two hosts are ALWAYS on different layer 2 network segments - and I don't see any assumption there.