From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lucio De Re To: 9fans@cse.psu.edu Subject: Re: [9fans] bug in v4parseip? Message-ID: <20030213175543.B9084@cackle.proxima.alt.za> References: <6d3220b4.0302121654.66a0f55e@posting.google.com> <713e94f597696a29dd5a3ef441a109ca@plan9.bell-labs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <713e94f597696a29dd5a3ef441a109ca@plan9.bell-labs.com>; from David Presotto on Thu, Feb 13, 2003 at 10:21:09AM -0500 Date: Thu, 13 Feb 2003 17:55:43 +0200 Topicbox-Message-UUID: 5c20ec18-eacb-11e9-9e20-41e7f4b1d025 On Thu, Feb 13, 2003 at 10:21:09AM -0500, David Presotto wrote: > > In the (classy?) truncated forms a, b, and c are still required Classful > to be octet representations. You understood the code, just not Not to my knowledge, although there probably isn't an RFC to cover it. I assume that class A addresses take exactly two values (127.1 or 10.100000) and B addresses allow three values (168.210.45000, say) as alternatives to the more conventional dot-quad. > the representation. If you do indeed use 10.100000, you won't > get what you want. I've never seen that form defined and am > not totally sure what the correct value would be, though BSD > would convert it to 10.1.134.160 which is the result I would > have guessed at. What should 192.100000.1 be? If there 192.100000.1 is invalid, a class C address should not be representable in less than four octets. The big clue is in the man page for the Unix 'route' command: For example, 128.32 is interpreted as -host 128.0.0.32; 128.32.130 is in- terpreted as -host 128.32.0.130; -net 128.32 is interpreted as 128.32.0.0; and -net 128.32.130 is interpreted as 128.32.130.0. I haven't access to Xenix, where route had no mechanism to select between hosts and nets and the description was more appropriate than the above. I do note that the above contradicts my belief that two values only apply to class A, three to class B and four to class C, but it does indicate, vaguely, that 192.100000.1 is inappropriate. You may have a point that only octets (0-255) are permitted, though. On the other hand, is it a BSDism that allows spammers to specify 32-bit addresses in URLs? > really is a well accepted definition of what non > octet representations yield, I'ld be happy to implement > that. If its a side effect of the BSD conversion, I'ld > be less thrilled. I think this type of class consciousness is disappearing from NetBSD, at least. I think even 127.1 is no longer treated sensibly in some of the library functions. 0.0.0.0, incidentally, seems no longer to mean 127.0.0.1, either. It's laziness, I think, although CIDR does justify it. ++L