Hi Michael,
I have to admit, I hadn't considered the consequences of this change; I
was focused on my particular application.
I provision point-to-point links between routers to conserve IP space
(obviously, the primary use case for RFC3021).
The immediate application where I'm wanting this -- the 'pinger-report'
(
http://www.skendric.com/nmgmt/device/IP/) -- grabs a route table from a
nearby router, walks through each route using hostenum to generate the
addresses on that route, pings them, and records which addresses respond
and which don't respond. Addresses on /31 routes show up as having
'never' responded to a ping, because hostenum doesn't generate their
addresses. Technicians at our site consult this report (auto-generated
nightly) before assigning IP space -- a technician did precisely this
and ended-up re-using a previously assigned /31.
Obviously, for this application, I can hack around this, e.g. check the
route before handing it to hostenum, if the route has a /31 mask, then
generate the addresses myself. But I figured a cleaner way, from the
point of view my code! would be for hostenum to do this for me.
I think your point is well-taken, that changing the default behavior of
NetAddr::IP wrt /31 routes & hostenum could break existing code; and
thus your suggested approach, to add a switch which would enable RFC3021
support (leaving the default being the OLD behavior) would be preferable.
I think the challenge for you is to figure out whether or not this is
worth you time wrt to the value it would add to NetAddr::IP -- RFC3021
is probably not widely deployed outside the IP transport community.
Speculating here, I suppose it is possible to employ /31 subnetting to
hosts, as a way to isolate hosts in a data center from each other's
broadcast traffic ... in which case I can imagine various applications
which would want hostenum to support RFC3021 ... but I have never
actually heard of anyone doing this. (Do any host operating systems
support /31 addressing? ... a quick google search suggests that Windows
does not, from folks wanting to do precisely what I outline above ... )
What do you think? If you decide that this isn't worth your time, I'll
hack 'pinger-report'; if you see merit in this proposal, then I'll wait
to see how you handle it.
--sk
On Mon Sep 24 15:45:03 2012, MIKER wrote:
Show quoted text> There are no useable IP's in a /31 network. /31 IP space contains two
> addresses only that are consumed by the network and gateway address.
>
> Because rfc3021 contemplates exceptions to the standard netmask scheme
> and includes certain restrictions I don't know if this would we wise or
> not as a feature enhancement since it could possibly break code in
> modules already developed that rely on NetAddr::IP. It COULD be
> implemented in NetAddr::IP as a special case with a unique method call.
> However that does not satisify a requirement to treat IP space in a
> consistent manner. Perhaps a SWITCH to control the treatment of IP space
> in the OLD way or rfc3021 compliant manner would be more appropriate
> with the default being the OLD way.
>
> Your comments would be welcome.
>
> Michael
>
> On Sun Sep 23 10:48:25 2012, skendric@fhcrc.org wrote:
> > I don't believe that hostenum and hostenumref support RFC3021 addresses
> >
> > guru> cat test-netaddr-ip-with-rfc3021
> > #!/usr/bin/perl
> > use 5.12.0;
> > use strict;
> > use warnings;
> > use feature 'say';
> > use NetAddr::IP;
> > my $ip = NetAddr::IP->new('10.1.1.222/31');
> > my @addrs = $ip->hostenum();
> > say 'Number of addresses = ', scalar @addrs;
> > say 'Addresses = ', join ', ', @addrs;
> >
> > guru> ./test-netaddr-ip-with-rfc3021
> > Number of addresses = 0
> > Addresses =
> > guru>
> >
> > perl-5.12.2
> > uname -a [...] 2.6.18-308.13.1.el5.centos.plus #1 SMP Tue Aug 21 18:54:5
> > 8 EDT 2012 x86_64 x86_64 x86_64 GNU/Linux
>
