stdlib ipaddr request for comment;-)

[Markus Werner]

Hello,


at the moment the lib behaves like following.

ip = IPAddr.new("192.168.2.43/24")
=> #<IPAddr: IPv4:192.168.2.0/255.255.255.0>

So so orgin information is lost
IMHO this is a bad behavior.

I discussed this matter already in the ruby ml a year ago.
Somebody was the opinion thats this is what he expect, cause 192.168.2.43/24
is not a valid notation. He said the valid notation is either
192.168.2.43/32, 192.168.2.43 or 192.168.2.0/24.


If I would agree with him ( I don't) I would say that IPAddr still behaves
wrong.
It should raise an execption if the argument (notation) is invalid and
should not alter the argument silently.

But I state it is a valid notation. Many network administrator use this
notation to express the address and the prefixlen/netmask in one string.

So I suggest to change the behavior of the lib a following and like to read
your opinions about it.

ip = IPAddr.new("192.168.2.43/24")
=> #<IPAddr: IPv4:192.168.2.43/255.255.255.0>

ip.addr => "192.168.2.43"
ip.netmask => "255.255.255.0"
ip.net => "192.168.2.0" # just for ipv4 family"
ip.broadcast "192.168.2.255" # just for ipv4 family"
ip.prefix => "192.168.2.0/24"
ip.prefixlen => "24"

And I would also suggest to migrate to cidr in all places cause this is the
future. So the class should internal just use the prefixlen and net the
netmask anymore.


BTW
A 6to4 method would be a nice feature too.
exp.

ip = IPAddr.new("192.168.2.43")
=> #<IPAddr: IPv4:192.168.2.43/255.255.255.255>

ip.6to4_prefix => "2002:3eb0:e08c::0621:7622:4140/48"
ip.6to4 => "2002:3eb0:e08c::0621:7622:4140/128"
or
ip.6to4 => "2002:3eb0:e08c::0621:7622:4140"



bye

Markus


Disclaimer
Cause my english is not as good as it should be. Everything I've written
should be interpreted as objective and open minded. I don't have a
unalterable opinion, how it could seem.

 

[Daniel Berger]

Hello,


at the moment the lib behaves like following.

ip = IPAddr.new("192.168.2.43/24")
=> #<IPAddr: IPv4:192.168.2.0/255.255.255.0>

So so orgin information is lost
IMHO this is a bad behavior.

I discussed this matter already in the ruby ml a year ago.
Somebody was the opinion thats this is what he expect, cause 192.168.2.43/24
is not a valid notation. He said the valid notation is either
192.168.2.43/32, 192.168.2.43 or 192.168.2.0/24.


If I would agree with him ( I don't) I would say that IPAddr still behaves
wrong.
It should raise an execption if the argument (notation) is invalid and
should not alter the argument silently.

But I state it is a valid notation. Many network administrator use this
notation to express the address and the prefixlen/netmask in one string.

So I suggest to change the behavior of the lib a following and like to read
your opinions about it.

ip = IPAddr.new("192.168.2.43/24")
=> #<IPAddr: IPv4:192.168.2.43/255.255.255.0>

ip.addr => "192.168.2.43"
ip.netmask => "255.255.255.0"
ip.net => "192.168.2.0" # just for ipv4 family"
ip.broadcast "192.168.2.255" # just for ipv4 family"
ip.prefix => "192.168.2.0/24"
ip.prefixlen => "24"

And I would also suggest to migrate to cidr in all places cause this is the
future. So the class should internal just use the prefixlen and net the
netmask anymore.


BTW
A 6to4 method would be a nice feature too.
exp.

ip = IPAddr.new("192.168.2.43")
=> #<IPAddr: IPv4:192.168.2.43/255.255.255.255>

ip.6to4_prefix => "2002:3eb0:e08c::0621:7622:4140/48"
ip.6to4 => "2002:3eb0:e08c::0621:7622:4140/128"
or
ip.6to4 => "2002:3eb0:e08c::0621:7622:4140"



bye

Markus

My suggestion is to submit a patch to ruby-core and see what folks
think. It may be rejected, but at least it will be considered.

Another option is to submit your idea to the author of the ip-address
project on RubyForge at http://rubyforge.org/projects/ip-address/ and
see what Erik thinks of it.

Regards,

Dan

 

[Markus Werner]

Dear Daniel,

My suggestion is to submit a patch to ruby-core and see what folks
think. It may be rejected, but at least it will be considered.

Since I'm not a real programmer I would discuss the different ways to do it.
So I don't chose a bad way.

Another option is to submit your idea to the author of the ip-address
project on RubyForge at http://rubyforge.org/projects/ip-address/ and
see what Erik thinks of it.

I'll consider this, thanks for this hint.


Just an overview:

1. Easy way would be do just extend the Method IPAddr#new to save also the
IPAdress and not only the net.

So it would be easy to derive from ipaddr.

2. Simple derive from ipaddr and write your own initialize function which
stores the required attr.

In this case it is necessary to reimplement (cut & paste things that
are already in the superclass.
I don't like this way.


3. Implementing a different behavior with an migration strategy.


....


with kind regards

Markus