[lkml]   [2000]   [Jan]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: all zeroes/all ones used in host IP's...
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: or with hosts
> through or with hosts through
> 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

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:

> 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 and
this is clearly a class C address. Analysing this according to the
above, I note the following:

1. From para (5) above:

IP = = 0xC13FFF04
CM = = 0xFFFFFF00
NM = = 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. |

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:56    [W:0.081 / U:2.976 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site