Kitz Forum

Computers & Hardware => Networking => Topic started by: Weaver on January 17, 2018, 05:07:58 AM

Title: Dot zero / zeroth device in subnet
Post by: Weaver on January 17, 2018, 05:07:58 AM
What problems if any am I likely to encounter if I allocate the first IP v4 address in a subset to a device?  That is: x.x.x.0 or dot base-plus-zero if the subnet is smaller than a /24 and doesn't start on .0. My current main IPv4 /26 is based at .192 and out of old-fashioned superstition I have not allocated .192 to any box. I have never actually been given a real concrete reason not to do it, just told it bad juju.

Same question with IPv6 too. I used xxxx:1 rather than :0 for a node a while back for example.

The obvious answer is to try it out and pray.

(I get the feeling I have asked this question many years earlier, if so: mea culpa maxima.)
Title: Re: Dot zero / zeroth device in subnet
Post by: andyfitter on January 17, 2018, 08:13:48 AM
I don’t think you can ever user the first or last address in a subnet for an individual device in IPv4. The first address is the subnet identifier used for routing and the last is the broadcast address.
Title: Re: Dot zero / zeroth device in subnet
Post by: Weaver on January 17, 2018, 09:59:39 PM
Agree Andy. The last address is obvious.

However I've never been able to find out why one can't use the first address. Maybe need to express it in these terms:
    1. Exactly what bad thing is going to happen to you if you do?
or
    2. Exactly what prevents you from just doing it?

I only just realised that the things I have read are ambiguous and maybe some people have been talking about (2), the _ability_ to do so. Epistemic modality vs deontic modality.

I am able to commit the crime, but am I able to get away with it? Or would others not be able to get away with it, or even not be able to commit it?

Title: Re: Dot zero / zeroth device in subnet
Post by: d2d4j on January 17, 2018, 10:23:14 PM
Hi weaver

Sorry if I’m not understanding

Do you mean an internal ip range or ipv4 range externally assigned to you

If internal, I don’t think the nic would let you assign .0 but if it did, you would not be able to use it I don’t think, and/or it could cause routing issues

If external ip range, same thing but provider may also not be happy with you

Many thanks

John
Title: Re: Dot zero / zeroth device in subnet
Post by: burakkucat on January 17, 2018, 10:33:05 PM
Let us consider the 16-bit private address space, 192.168.X.X/16

If I was performing an nmap scan, I could use 192.168.0.0/16 or 192.168.[0-255].0/24 as the address target range. (In the latter case, I have used [0-255] just to signify that the number in that position is any one from the range so specified and not something funky for nmap to perform.) Explicitly: 192.168.0.0/24 specifies the range 192.168.0.0 to 192.168.0.255 and 192.168.0.0/16 specifies the range 192.168.0.0 to 192.168.255.255 (if I've typed it correctly).

Now I perform two simple ping tests --

[Duo2 ~]$ ping -c 1 192.168.1.0
Do you want to ping broadcast? Then -b. If not, check your local firewall rules.
[Duo2 ~]$ ping -c 1 192.168.1.255
Do you want to ping broadcast? Then -b. If not, check your local firewall rules.
[Duo2 ~]$


In both cases the ping command responds as if both target addresses are broadcast addresses. Possibly a bug in the ping command.

What use or relevance is the above?  :shrug2:
Title: Re: Dot zero / zeroth device in subnet
Post by: d2d4j on January 17, 2018, 10:42:50 PM
Hi

Sorry, my understanding is .0 and .255 are used to determine responding ip within the range of 254 useable ip

.0 is loopback and .255 broadcast

This is why I think it would cause routing issues, although a nnn.nnn.0.0 on internal class c range, should allow a nnn.nnn.0.0 to be used normally on a subnet mask of 255.0.0.0

Sorry though, if this is referring to external ipv4 range, I would strongly advice not to try it.

Many thanks

John
Title: Re: Dot zero / zeroth device in subnet
Post by: Weaver on January 18, 2018, 03:12:13 AM
@burakkucat That's an error message from the *nix ping command ? Never knew that, that’s exactly why I’m glad that I asked the question.

I wonder if that is an explicit check by the ping command’s own app code itself then? As opposed to some error coming back from lower layers. So I need to write a C program to whack a udp message off to say 10.0.0.0 and one to 81.187.147.192 (/26) which is a (base  + 0) ≠ .0 example.

I wonder if ping for windows also does the same thing?

So one certain reason already is that
Out of devilment, I have forced the Ipv4 address of the current ios box to be .192 which is a (base  + 0) ≠ .0 example on this particular subnet, and the subnet mask is still correct at /26. Scanned the LAN, browsed the internet no problems as yet, nor any expected. To be fair, how would the internet even know in this  (base  + 0) ≠ .0 case. I could use an ipv6 ::0 source address as an evil test.

Title: Re: Dot zero / zeroth device in subnet
Post by: Weaver on January 18, 2018, 03:19:32 AM
@d2d4j Could you explain you point about ‘loopback’ for stupid people? :-) Would that be a loopback implemented by interface-specific code or hardware within the particular interface subsystem that you route so-and-so prefix to?

Because that isn't visibly happening with my IPv4 subnet on this WLAN NIC on iOS? But I'm perhaps not doing the right thing without it literally being dot-zero, but rather (ipv4 & ~mask) == 0, yet (base  + 0) ≠ .0 example.
Title: Re: Dot zero / zeroth device in subnet
Post by: Weaver on January 18, 2018, 03:31:06 AM
I tried setting my ipad to 10.0.0.0 and talking http to my Firebrick, which should respond from 10.0.0.254 which is its permanent alternative additional address and which normally works. Safari didn't like that at all. However changing my source addr to 10.0.0.7 instead didn't fix the problem, so I have more problems there, and a literal source =.0 isn't the only one.

I need to do something a bit simpler within the 10.0.0.0 range. Perhaps I should just ping traceroute between two machines.
Title: Re: Dot zero / zeroth device in subnet
Post by: Weaver on January 18, 2018, 03:41:06 AM
Mind you, if we are just looking at what are ultimately just app code bugs, then the question is: What is the code ? Is it
    (ipv4 & ~ mask) != 0
or the ‘incorrect’
     ipv4 != 0
Title: Re: Dot zero / zeroth device in subnet
Post by: adrianw on January 18, 2018, 07:50:44 AM
In both cases the ping command responds as if both target addresses are broadcast addresses.
Long ago, broadcasts were sent to the network address (local address part all zero), subsequently changed to using the broadcast address (local address part all ones).

Some software still honours using the network address as the broadcast address, e.g. on my home network (192.168.1.0/24)

[aw1@titus .../src/sbin/ping]$ ping 192.168.1.0
PING 192.168.1.0 (192.168.1.0): 56 data bytes
64 bytes from 192.168.1.249: icmp_seq=0 ttl=64 time=4.722 ms
64 bytes from 192.168.1.239: icmp_seq=0 ttl=64 time=4.952 ms (DUP!)
64 bytes from 192.168.1.246: icmp_seq=0 ttl=64 time=5.597 ms (DUP!)
64 bytes from 192.168.1.239: icmp_seq=1 ttl=64 time=1.674 ms
64 bytes from 192.168.1.249: icmp_seq=1 ttl=64 time=2.073 ms (DUP!)
64 bytes from 192.168.1.246: icmp_seq=1 ttl=64 time=3.267 ms (DUP!)
64 bytes from 192.168.1.239: icmp_seq=2 ttl=64 time=2.148 ms
64 bytes from 192.168.1.249: icmp_seq=2 ttl=64 time=2.494 ms (DUP!)
64 bytes from 192.168.1.246: icmp_seq=2 ttl=64 time=3.269 ms (DUP!)
64 bytes from 192.168.1.249: icmp_seq=3 ttl=64 time=2.132 ms
64 bytes from 192.168.1.239: icmp_seq=3 ttl=64 time=2.310 ms (DUP!)
64 bytes from 192.168.1.246: icmp_seq=3 ttl=64 time=7.636 ms (DUP!)
^C
--- 192.168.1.0 ping statistics ---
4 packets transmitted, 4 packets received, +8 duplicates, 0.0% packet loss
round-trip min/avg/max/stddev = 1.674/3.523/7.636/1.749 ms

[aw1@titus .../src/sbin/ping]$ ping 192.168.1.255
PING 192.168.1.255 (192.168.1.255): 56 data bytes
64 bytes from 192.168.1.36: icmp_seq=0 ttl=64 time=0.439 ms
64 bytes from 192.168.1.239: icmp_seq=0 ttl=64 time=2.191 ms (DUP!)
64 bytes from 192.168.1.249: icmp_seq=0 ttl=64 time=3.887 ms (DUP!)
64 bytes from 192.168.1.246: icmp_seq=0 ttl=64 time=6.399 ms (DUP!)
64 bytes from 192.168.1.36: icmp_seq=1 ttl=64 time=0.428 ms
64 bytes from 192.168.1.239: icmp_seq=1 ttl=64 time=2.316 ms (DUP!)
64 bytes from 192.168.1.249: icmp_seq=1 ttl=64 time=5.118 ms (DUP!)
64 bytes from 192.168.1.36: icmp_seq=2 ttl=64 time=0.576 ms
64 bytes from 192.168.1.239: icmp_seq=2 ttl=64 time=2.563 ms (DUP!)
64 bytes from 192.168.1.249: icmp_seq=2 ttl=64 time=4.060 ms (DUP!)
64 bytes from 192.168.1.246: icmp_seq=2 ttl=64 time=5.315 ms (DUP!)
^C
--- 192.168.1.255 ping statistics ---
3 packets transmitted, 3 packets received, +8 duplicates, 0.0% packet loss
round-trip min/avg/max/stddev = 0.428/3.027/6.399/1.992 ms


https://www.cisco.com/c/en/us/support/docs/ip/routing-information-protocol-rip/13788-3.html contains:
"host ids of all zeros or all ones are not allowed (it is very important to remember this)"

https://www.cisco.com/c/en/us/support/docs/ip/dynamic-address-allocation-resolution/13711-40.html contains more information.

https://tools.ietf.org/html/rfc950 contains:
the values of all zeros and all ones in the subnet field should not be assigned to actual (physical) subnets.

Attempting to research this leads to a twisty maze of RFCs, all alike.

If Weaver wants to inspect a ping command, https://github.com/freebsd/freebsd contains the entire FreeBSD source, with ping at https://github.com/freebsd/freebsd/blob/master/sbin/ping/ping.c
Title: Re: Dot zero / zeroth device in subnet
Post by: Weaver on January 18, 2018, 11:09:13 AM
What a great post from adrianw, many thanks.

I read that Cisco article some years ago. I had the idea that back in the beginnings of time maybe people were thinking about all-zeros (after masking) for broadcast instead-of or as-well-as all ones.
Title: Re: Dot zero / zeroth device in subnet
Post by: burakkucat on January 18, 2018, 07:30:12 PM
[off-topic]
Attempting to research this leads to a twisty maze of RFCs, all alike.

Whilst exploring them, the battery in your torch fails and a hollow voice says "Plugh" .  ;)
[/off-topic]
Title: Re: Dot zero / zeroth device in subnet
Post by: Weaver on January 18, 2018, 08:15:57 PM
My thoughts were with Adrian and Burrakucat