Standardlib "ipaddr.rb"

[Markus Werner]

Happy New Year Everyone,

I seems for me that there is a bug (or a feature) in the standard lib
"ipaddr.rb". ;-)

See irb output ->

irb(main):001:0> require 'ipaddr'
=> true
irb(main):002:0> ip1 = IPAddr.new("192.168.1.243/24")
=> #<IPAddr: IPv4:192.168.1.0/255.255.255.0>

IMHO should it be #<IPAddr: IPv4: 192.168.1.243/255.255.255.0>

And there should be methods to get the "net" and in case of ipv4 maybe
"broadcast" address of the prefix.

But this is just a suggestion cause this would be intuitive for me as newbie.

 

[E S]

Happy New Year Everyone,

I seems for me that there is a bug (or a feature) in the standard lib
"ipaddr.rb". ;-)

See irb output ->

irb(main):001:0> require 'ipaddr'
=> true
irb(main):002:0> ip1 = IPAddr.new("192.168.1.243/24")
=> #<IPAddr: IPv4:192.168.1.0/255.255.255.0>

IMHO should it be #<IPAddr: IPv4: 192.168.1.243/255.255.255.0>

I think the problem is that technically there's no such address
as 192.168.1.243/24, you just have 192.168.1.243 in the subnet
192.168.1.0/24.

And there should be methods to get the "net" and in case of ipv4 maybe
"broadcast" address of the prefix.

I'd say it should use a different syntax if you want to designate
the subnet too, IPAddr.new(192.168.1.243, 24) or then just provide
a separate class Subnet.

E

 

[Markus Werner]

On Monday 03 January 2005 17:32, E S wrote

Hi,

I think the problem is that technically there's no such address
as 192.168.1.243/24, you just have 192.168.1.243 in the subnet
192.168.1.0/24.

That is just a point of view.
If I tell a other netadmin that he should use the address 192.168.1.33/29
he'll knew that the prefix is of the length of 29 bits. He'll also knew that
192.168.1.32/29 is the prefix.
So why shouldn't have the standard lib the same intelligence?

But you right, technically there is no such Prefix like "192.168.1.33/29"

And in my point of view it is a failure that you tell a methode to store
192.168.1.33/29 and it's stores 192.168.1.32/29.
It would be better to inform the caller that the value that he submitted is
not supported and tell him why.
In other case somebody could get trapped cause he stores the value and
sometime later he use it. He'll be very suprised if the value is altered.

Objective:
Both opinions have his points. But in anycase the decision should be mentioned
in the doc. So everyone knows about it and what it means for the user.


regards

Markus

PS
My English isn't so well and it could happend real easily to step on someone's
toes. So please let me know if I did it?

 

[Aredridel]

And in my point of view it is a failure that you tell a methode to store

192.168.1.33/29 and it's stores 192.168.1.32/29.
It would be better to inform the caller that the value that he submitted is
not supported and tell him why.
In other case somebody could get trapped cause he stores the value and
sometime later he use it. He'll be very suprised if the value is altered.

Objective:
Both opinions have his points. But in anycase the decision should be mentioned
in the doc. So everyone knows about it and what it means for the user.

I'd suggest a wrapper class: IPAddressWithContext or something. Let it
have the net and host methods, and make use of IPAddr internally.

 

[Markus Werner]

Hi Again,

I'd suggest a wrapper class: IPAddressWithContext or something. Let it
have the net and host methods, and make use of IPAddr internally.

No a wrapper class is not the right solution in my opinion. It is a more
basic problem.

Yesterday night I was thinking about this problem. I came to the point, that
this implementation is brocken in any case. So it is not good to have as a
standard lib.
There are some reasons. But cause it is hard to argue if things are mixed up.
I try to split this case into 2 parts.

First Programming ( Since I'm a newbie, it is hard for me to argue in this
area).

Second Networking ( This is my core area, so I know something more about
it;-) )



####
Lets look at the Programming site.

Definition:
The address 192.168.2.243/24 is not a valid address. Valid addresses are just
Network addresses like 192.168.2.0/24 or 10.1.1.0/22.

The constructor method does accept an invalid value and then change the value
to a valid one. IMHO this shouldn't happen.
It should be reject at the first place.

The doc should mention what valid values are.

Even if you don't share my opinion. Then the doc should mention that invalid
values are turned to valid values automagically.

I was told or I read that constructors shouldn't behave the way that
IPAddress ones does. If I'm wrong, tell me please.


####
The Network view of things.

This is a matter of "terminology". So it is likely that there exist many
different opinions.

There are serval ways to express a Network ( Nowadays a IP Prefix)

Long form 10.93.192.0/255.255.224.0
Short form 10.93.192.0/19
Or even shorter 10.93.192/19

There are serval ways to write IP Addresses

-> IP = 10.93.192.14
Netmask = 255.255.255.128

-> 10.93.192.14/255.255.255.128

-> 10.93.192.14/25

Any 'real' netadmin will understand any notation.

In this notation the IP Address 10.93.192.0/25 has the special meaning. It is
the networkaddress or nothing else then the Prefix 10.93.192.0/25.

So technical if you talk about prefixes, the Prefix 10.93.192.14/25 is
unvalid, but if you talk about IP addresses, the Address 10.93.192.14/25 t is
a valid notation.

For instance the iproute2 suite for linux use the notation I mentioned above.

And even if there is just a great minority - I'm not saying it's a minority,
IMHO there are many people who share this opinion - but if there is just a
great minority that use this notation, it is necessary to rethink about the
recent implementation.

----------


Last but not least

In my last mail I wrote: 'But you right, technically there is no such Prefix
like "192.168.1.33/29" '

Thats true, but I don't know any more, why I was talking about prefixes.
Cause the Class is named "IPAddress" and not "IPPrefix".
And the doc tells the user also that it is about IPAddresses
----
# Creates a new ipaddr containing the given human readable form of
# an IP address.
----

If you don't share my opinions. I guess there is no argument against the fact
that it should be documented how the class behave.


regards

Markus

 

[Markus Werner]

On Wednesday 05 January 2005 14:59, Florian G. Pflug wrote:
Hi Florian,

IpNetwork: Represents a network/ip-prefix, e.g.
192.168.0.0/16, or
192.168.1.0/24, but not 192.168.1.1/24, because it's not a
network.
IpAddress: Represents an ip-address, without netmask
IpInterface: Represents an ip-address in a certain network, e.g
192.168.1.1/24.
I'm not sure if 192.168.0.0 is a valid ip-address in the
192.168.0.0/24 network...

Just to think about : 192.168.1.1/32 or fe00::1/128 is a valid notation for a
single IP Address.

I will write my own Classes for IP Addresses now, and hope that the IPAddr lib
get changed in the future.

regards


Markus

 

[Austin Ziegler]

On Wednesday 05 January 2005 14:59, Florian G. Pflug wrote:
Hi Florian,


Just to think about : 192.168.1.1/32 or fe00::1/128 is a valid notation for a
single IP Address.

I will write my own Classes for IP Addresses now, and hope that the IPAddr lib
get changed in the future.

Why not modify the IPAddr lib and offer your changes as a patch to the
author/maintainer?

-austin