🚀 go-pugleaf

In article <CM8Kny.8Ho@eecs.nwu.edu> hpa@nwu.edu (H. Peter Anvin) writes:
>In article <CM5JM7.D19@cup.hp.com> of comp.sys.novell,
>  mintz@cup.hp.com (Ken Mintz) writes:
 
>>   Not 128 specifically, but certainly other values, such as 192, 224 etc.
>>   The problem with 128 per se is that that creates a one-bit subnet id.
>>   Since all-zero and all-one values have special meaning, subnet id and host
>>   id fields must comprise at least __two__ bits each.

>Nope, sorry.  Not for a *network* number.  However, all 0 and all 1
>for a *host* number are the clueless and the broadcast addresses,
>respectively.

There are differences between "network" and "subnet" masks; they aren't
the same thing. Ken is correct in his two-bit minimum statement.

>Hence, a one-bit subnet mask is perfectly valid, albeit a bit silly.

No, it's specifically stated as not acceptable. Check RFC 950, page 6.

>However, the subnet mask 255.255.255.254 would be invalid, since each
>subnet would consist of only the clueless and the broadcast address.

>> PS:  Some implementations do permit one-bit subnet ids, but this is non-
>> conformant.

>No, they are not.  Any application that does *not* permit a one-bit
>subnet id is nonconformant.

They *are* non-conformant, and will stay that way until someone writes
a new RFC and gets it approved--something I don't consider likely.




-- 
Gary Heston      SCI Systems, Inc.       gary@sci.com       site admin
   The Chairman of the Board and the CFO speak for SCI. I'm neither.
"Quit while you're ahead. All the best gamblers do."  Baltasar Gracian