> My guess is that it is going to output x.x.x.x/32, but we should supply
> a function so they can get just the IP or the mask from the type. That
> way, people who don't want the cidr format can pull out the part they
> want.
this i don't understand. why would you want only one part of it? if you
want to do address arithmetic then you need specific OR and AND and NOT
functions -- like making a broadcast address if all you know is your address
and netmask. but why would you want to know the mantissa without the scale?
> If they don't specify a netmask when they load the value, perhaps we use
> the standard class A,B,C netmasks. How you specify a HOST address using
> the non-cidr format, I really don't know. I am sure the experts will
> hash it out before 6.4 beta on September 1.
classful assumptions are out of fashion, outdated, and dangerous. consider:
"16" -> "16/8" -> "16.0.0.0/8"
"128" -> "128/16" -> "128.0.0.0/16"
"192" -> "192/24" -> "192.0.0.0/24"
not very helpful. the implementation of "cidr" that i posted here yesterday
uses the BIND-8 functions for representational conversion. those functions
assume that a text representation with no "/" given has as many bits as the
number of octets they fully cover:
"16" -> "16/8"
"128" -> "128/8"
"192" -> "192/8"
"127.1" -> "127.1/16"
this is how a Cisco router would interpret such routes if "ip classless" is
enabled and static routes were being entered. "ip classless" is a prereq-
uisite for running OSPF, RIPv2, or BGP4. in other words it's pervasive.
BIND follows RFC 1884 in this regard, and deviates significantly from both
classful assumptions and the old BSD standard, which would treat "127.1" as
"127.0.0.1". this burned on some old /etc/rc files but it was the right
thing to do and now that the world has gotten over the scars, let's not run
backwards.
the IETF's CIDR project was long running, painful, and successful.