all zeroes/all ones used in host IP's...

[Riley Williams]

Hi Mike.

 > On another mailing list I'm on there is a small discussion about
 > using "0's" in IP addresses.  Nobody could categorically say
 > wether or not they are allowed or not including myself, so I
 > hunted down RFC 1123, and found the relevant section.

 > Here it is:

 > Q> IP addresses are not permitted to have the value 0 or -1 for
 > Q> any of the <Host-number>, <Network-number>, or <Subnet-
 > Q> number> fields (except in the special cases listed above).
 > Q> This implies that each of these fields will be at least two
 > Q> bits long.

 > Now I interpreted that as meaning that none of the octets in an
 > IP address could be 0 or "-1" in either the network/subnet or
 > host portions of a valid host IP.  The definition of "-1" is
 > "all ones" in the host or network/subnet portion.

 > I interpret the above as meaning that it is not legal to have a
 > network like this: 192.168.0.0/24 or 23.0.0.0/24 with hosts
 > 192.168.0.1 through 192.168.0.254 or with hosts 23.0.0.1 through
 > 23.0.0.254. The first zero makes it illegal no?

Not according to a strict interpretation of the paragraph quoted, no.
I will state my understanding as clearly as I can.

 1. The relevant standard states that all IP addresses are
    classified as one of classes A, B, C or D depending only
    on the FIRST octet/byte thereof, as follows:

	0		Reserved
	1-127		Class A		 8 bit
	128-191		Class B		16 bit
	192-223		Class C		24 bit
	224-254		Class D
	255		Reserved

    Class D appears to have some strange rules associated with it,
    and I can't claim to fully understand them, so I will not
    analyse it further.

 2. With regards specifically to the segments labelled as being
    classes A, B and C in the above, the "Network number" field
    is defined as being the first X bits thereof, as also stated
    above.

 3. The "Subnet number" field is defined as being those bits of
    the IP address included in the netmask that are NOT in the
    "Network number" as defined above. This is often, but not
    always, 0 bits.

 4. The "Host number" field is defined as being those bits of
    the IP address that are not included in the netmask.

 5. For brevity, I will assign the following abbreviations for
    use later in this discussion:

	IP = Relevant IP address.
	CM = Class Mask, defined as being the netmask that
	     directly corresponds to the class the Ip address
	     belongs to.
	NM = NetMask from `ifconfig`.
	SM = Subnet mask, 

    I will also note that in the common case where the "Subnet
    number" field is of zero length, CM == NM.

 6. Taken literally, the paragraph you quote states that none of
    these three fields can consist entirely of 0's, nor can it
    consist entirely of 1's. That basically states that ALL of
    the following are true, using bitwise arithmetic:

	(IP & CM) != 0			Network number != 0
	(~IP & CM) != 0			Network number != -1

	(IP & (NM & ~CM)) != 0		Subnet number != 0
	(~IP & (NM & ~CM)) != 0		Subnet number != -1

	(IP & ~NM) != 0			Host number != 0
	(~IP & ~NM) != 0		Host number != -1

    One direct implication of this is that the "Subnet number"
    field can NOT be of zero length, whereas such is in fact a
    common case.

 7. From what I can see, the actual tests used on the Internet are
    rather simpler, as follows:

     a. Is the field masked by the netmask valid? This basically
	combines the "Network number" and the "Subnet number"
	into a single field and requires that the resulting
	field is neither 0 nor -1.

	(IP & NM) != 0
	(~IP & NM) != 0

     b. Is the host number valid?

	(IP & ~NM) != 0
	(~IP & ~NM) != 0

Note that in the common case where the "Subnet number" field is of
zero length, the two sets of conditions are identical, and in the
(valid) case where the "Subnet number" field is one bit long, the
definition quoted and analysed in paragraph (6) states that there
are NO valid IP addresses. As a result, I for one would have to
consider the definition flawed in that case.

 > Could someone in the know please clarify this as it has been
 > bugging me for some time and nobody else seems to be able to say
 > with 100% certainty what the proper rule is.

 > Also, would a network like:

 > 142.255.255.0/24 be illegal?

 > Someone has suggested that my interpretation is wrong, and if
 > that is indeed so, I'd like to know the proper interpretation
 > and share it with everyone.

Whilst I can't offer any standards to refer to, I can point out that
the primary IP address of the SunSITE UK mirror is 193.63.255.4 and
this is clearly a class C address. Analysing this according to the
above, I note the following:

 1. From para (5) above:

	IP = 193.63.255.4	= 0xC13FFF04
	CM = 255.255.255.0	= 0xFFFFFF00
	NM = 255.255.255.0	= 0xFFFFFF00

 2. From para (6) above:

	(IP & CM)		= 0xC13FFF00	!= 0
	(~IP & CM)		= 0x3EC00000	!= 0

	(IP & (NM & ~CM))	= 0x00000000	== 0	***
	(~IP & (NM & ~CM))	= 0x00000000	== 0	***

	(IP & ~NM)		= 0x00000004	!= 0
	(~IP & ~NM)		= 0x000000FC	!= 0

    As stated earlier, since the "Subnet number" field has been
    taken as being of zero length, NM == CM with the result that
    (NM & ~CM) is always zero, and thus that the two conditions
    indicated will always fail.

    Assuming that this is dealt with by excluding those two
    conditions whenever the "Subnet number" field is of zero
    length, this is clearly a valid IP address.

 3. From para (7) above:

	(IP & NM)		= 0xC13FFF00	!= 0
	(~IP & NM)		= 0x3EC00000	!= 0

	(IP & ~NM)		= 0x00000004	!= 0
	(~IP & ~NM)		= 0x000000FC	!= 0

    Based on this definition, that is a valid IP address.

Does that help?

 > I looked through some of the kernel source and couldn't find any
 > special handling of such addresses.

I wouldn't know as I haven't actually examined the kernel source for
this, but have just used my experience of what actually happens to
analyse the situation. However, I would expect any such logic to be in
the `ifconfig` tool rather than in the kernel itself anyway.

Best wishes from Riley.

 * Copyright (C) 1999, Memory Alpha Systems.
 * All rights and wrongs reserved.

+----------------------------------------------------------------------+
| There is something frustrating about the quality and speed of Linux  |
| development, ie., the quality is too high and the speed is too high, |
| in other words, I can implement this XXXX feature, but I bet someone |
| else has already done so and is just about to release their patch.   |
+----------------------------------------------------------------------+
 * http://www.memalpha.cx/Linux/Kernel/


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo en vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/