[9fans] bug in v4parseip?

[9fans] bug in v4parseip?

[Saroj Mahapatra]

v4parseip function code in libip/ipparse.c looks suspicious. First of
all, I don't know why it bothers about class A or B given the trend
towards classless addresses? Next, if it is trying to handle inputs of
the form: a.b.c and a.b, then the problem is that c in the first case
can be a 24-bit integer and b in the second case can be a 16-bit
integer; the code assigns those parts to a 'uchar' resulting in
truncation. Or, did I misunderstand the code?


Thank you,
Saroj Mahapatra

Re: [9fans] bug in v4parseip?

[David Presotto]

On Thu Feb 13 04:50:37 EST 2003, saroj@optonline.net wrote:
> v4parseip function code in libip/ipparse.c looks suspicious. First of
> all, I don't know why it bothers about class A or B given the trend
> towards classless addresses?

Classless or not, the most standard string form of v4 IP addresss is
a set of dot separated decimal numbers, each number representing
an octet.  The only truncated form was the class{ABC} one and such
truncated addresses (such as 127.1) are still very common.  Ignoring
them would be a disservice.  Hence the class sensitivity.

> Next, if it is trying to handle inputs of
> the form: a.b.c and a.b, then the problem is that c in the first case
> can be a 24-bit integer and b in the second case can be a 16-bit
> integer; the code assigns those parts to a 'uchar' resulting in
> truncation. Or, did I misunderstand the code?

In the (classy?) truncated forms a, b, and c are still required
to be octet representations.  You understood the code, just not
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
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.

Re: [9fans] bug in v4parseip?

[Lucio De Re]

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 <grin>

> 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

Re: [9fans] bug in v4parseip?

[David Presotto]

[-- Attachment #1: Type: text/plain, Size: 116 bytes --]

that still doesn't give me a definition.  I guess the implied
definition is do whatever BSD is doing at the moment?

[-- Attachment #2: Type: message/rfc822, Size: 4122 bytes --]

From: Lucio De Re <lucio@proxima.alt.za>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] bug in v4parseip?
Date: Thu, 13 Feb 2003 17:55:43 +0200
Message-ID: <20030213175543.B9084@cackle.proxima.alt.za>

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 <grin>

> 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

Re: [9fans] bug in v4parseip?

[Boyd Roberts]

David Presotto wrote:

>that still doesn't give me a definition.  I guess the implied
>definition is do whatever BSD is doing at the moment?
>
But it's a hideously bad idea.  Why go down that path at all?
A dotted quad is a dotted quad and be done with it.

Re: [9fans] bug in v4parseip?

[Lucio De Re]

On Thu, Feb 13, 2003 at 11:12:25AM -0500, David Presotto wrote:
>
> that still doesn't give me a definition.  I guess the implied
> definition is do whatever BSD is doing at the moment?

I was just presenting the devil's advocate position.  The present
code (presumably) matches the documented BSD behaviour and that
ought to suffice.

My guess is that only zero-insertion and elimination is permissible,
going on the limited documentation.

One could do worse than track BSD's behaviour, it is unlikely to
fly in the face of logic.  NetBSD explicitly attempts to satisfy
the Posix standards unless there is good reason to avoid it.  It
is not very different from the Plan 9 philosophy, where Posix
compatibility is just less desirable a target.

Also, NetBSD retains very strong backwards compatibility, sometimes
at great cost (and sometimes through lack of choice :-) so they
won't have a flavour-of-the-day approach to this type of issue.

++L