headers
Dani Roisman | 28 Mar 2012 19:46
Favicon

zero-padded IP addresses in "startAddress" and "endAddress" values

Greetings,

One of our developers just pointed out to me that the values for "startAddress" and "endAddress" values are
now zero padded.  Is it possible this was a result of the Mar 24th code push
(http://lists.arin.net/pipermail/arin-tech-discuss/2012-March/000187.html)?  If so - was this
expected, or a bug?

Here's an example from query "curl -4
https://www.arin.net/rest/net/NET-75-126-0-0-1?apikey=<snip>" (note, the API key must be
authorized to the network owner if you're trying to reproduce this, try your key and your netblock)

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<net xmlns="http://www.arin.net/regrws/core/v1">
<pocLinks>
<pocLinkRef handle="IPADM258-ARIN" function="N" description="NOC"/>
<pocLinkRef handle="IPADM258-ARIN" function="T" description="Tech"/>
<pocLinkRef handle="ABUSE1025-ARIN" function="AB" description="Abuse"/>
</pocLinks>
<netBlocks>
<netBlock>
<cidrLength>16</cidrLength>
<description>Direct Allocation</description>
<endAddress>075.126.255.255</endAddress>    <--- this line
<startAddress>075.126.000.000</startAddress>    <--- and this line
<type>DA</type>
</netBlock>
</netBlocks>
<handle>NET-75-126-0-0-1</handle>
<netName>SOFTLAYER-4-3</netName>
<orgHandle>SOFTL</orgHandle>
(Continue reading)

Permalink | Reply |
headers
David Huberman | 28 Mar 2012 21:40

Re: zero-padded IP addresses in "startAddress" and "endAddress" values

Hello Dani,

ARIN's Registration RESTful web service has always expressed IP addresses
with zero padding. As you point out, however, the Whois RESTful web
service does not.  I think a fair explanation of these two behaviors is
that Whois is assumed to be read mostly by humans, and in contrast, the
output of the Registration RESTful web service is assumed to be
interpreted by machines.

We do note that the Payloads documentation currently available does not
properly indicate that the output is zero padded. We have a documentation
refresh coming very very shortly, and we will work to correct this
immediately.

Regards,
David

---
David R Huberman
Principal Technical Analyst, ARIN
703-227-9866

On 3/28/12 1:46 PM, "Dani Roisman" <droisman@...> wrote:

Greetings,

One of our developers just pointed out to me that the values for
"startAddress" and "endAddress" values are now zero padded.  Is it
possible this was a result of the Mar 24th code push
(http://lists.arin.net/pipermail/arin-tech-discuss/2012-March/000187.html)?
(Continue reading)

Permalink | Reply |
headers
Seth Mattinen | 28 Mar 2012 22:17
Picon
Favicon

Re: zero-padded IP addresses in "startAddress" and "endAddress" values

On 3/28/12 12:40 PM, David Huberman wrote:
> Hello Dani,
> 
> ARIN's Registration RESTful web service has always expressed IP addresses
> with zero padding. As you point out, however, the Whois RESTful web
> service does not.  I think a fair explanation of these two behaviors is
> that Whois is assumed to be read mostly by humans, and in contrast, the
> output of the Registration RESTful web service is assumed to be
> interpreted by machines.
> 

I find that logic flawed; leading zeros can mean "octal" to machines. If
indeed the output is assumed to be interpreted be machines as octal then
leading zeros would be appropriate, whereas a human would normally read
a zero-padded number as base 10. If you're going to zero-pad then for
consistency you should return "075.0126.000.000" rather than an
ambiguous mix of potentially octal and potentially base 10. Or simply
don't zero pad without a technical basis.

For example, if I were to take that output and feed it into "ping" on
any of my Linux servers they do indeed interpret 075 as octal and try to
ping "61.126.0.0".

~Seth
Permalink | Reply |
headers
Aaron Hughes | 28 Mar 2012 22:38
Favicon

Re: zero-padded IP addresses in "startAddress" and "endAddress" values

+1

Thanks Seth.

Cheers,
Aaron

On Wed, Mar 28, 2012 at 01:17:40PM -0700, Seth Mattinen wrote:
> On 3/28/12 12:40 PM, David Huberman wrote:
> > Hello Dani,
> > 
> > ARIN's Registration RESTful web service has always expressed IP addresses
> > with zero padding. As you point out, however, the Whois RESTful web
> > service does not.  I think a fair explanation of these two behaviors is
> > that Whois is assumed to be read mostly by humans, and in contrast, the
> > output of the Registration RESTful web service is assumed to be
> > interpreted by machines.
> > 
> 
> I find that logic flawed; leading zeros can mean "octal" to machines. If
> indeed the output is assumed to be interpreted be machines as octal then
> leading zeros would be appropriate, whereas a human would normally read
> a zero-padded number as base 10. If you're going to zero-pad then for
> consistency you should return "075.0126.000.000" rather than an
> ambiguous mix of potentially octal and potentially base 10. Or simply
> don't zero pad without a technical basis.
> 
> For example, if I were to take that output and feed it into "ping" on
> any of my Linux servers they do indeed interpret 075 as octal and try to
> ping "61.126.0.0".
(Continue reading)

Permalink | Reply |
headers
Andy Newton | 29 Mar 2012 15:56

Re: zero-padded IP addresses in "startAddress" and "endAddress" values


On Mar 28, 2012, at 10:17 PM, Seth Mattinen wrote:

> On 3/28/12 12:40 PM, David Huberman wrote:
>> Hello Dani,
>> 
>> ARIN's Registration RESTful web service has always expressed IP addresses
>> with zero padding. As you point out, however, the Whois RESTful web
>> service does not.  I think a fair explanation of these two behaviors is
>> that Whois is assumed to be read mostly by humans, and in contrast, the
>> output of the Registration RESTful web service is assumed to be
>> interpreted by machines.
>> 
> 
> I find that logic flawed; leading zeros can mean "octal" to machines. If
> indeed the output is assumed to be interpreted be machines as octal then
> leading zeros would be appropriate, whereas a human would normally read
> a zero-padded number as base 10. If you're going to zero-pad then for
> consistency you should return "075.0126.000.000" rather than an
> ambiguous mix of potentially octal and potentially base 10. Or simply
> don't zero pad without a technical basis.
> 
> For example, if I were to take that output and feed it into "ping" on
> any of my Linux servers they do indeed interpret 075 as octal and try to
> ping "61.126.0.0".

Seth,

Let me offer the technical basis you are asking for.
(Continue reading)

Permalink | Reply |
headers
Seth Mattinen | 30 Mar 2012 04:06
Picon
Favicon

Re: zero-padded IP addresses in "startAddress" and "endAddress" values

On 3/29/12 6:56 AM, Andy Newton wrote:
> 
> On Mar 28, 2012, at 10:17 PM, Seth Mattinen wrote:
> 
>> On 3/28/12 12:40 PM, David Huberman wrote:
>>> Hello Dani,
>>>
>>> ARIN's Registration RESTful web service has always expressed IP addresses
>>> with zero padding. As you point out, however, the Whois RESTful web
>>> service does not.  I think a fair explanation of these two behaviors is
>>> that Whois is assumed to be read mostly by humans, and in contrast, the
>>> output of the Registration RESTful web service is assumed to be
>>> interpreted by machines.
>>>
>>
>> I find that logic flawed; leading zeros can mean "octal" to machines. If
>> indeed the output is assumed to be interpreted be machines as octal then
>> leading zeros would be appropriate, whereas a human would normally read
>> a zero-padded number as base 10. If you're going to zero-pad then for
>> consistency you should return "075.0126.000.000" rather than an
>> ambiguous mix of potentially octal and potentially base 10. Or simply
>> don't zero pad without a technical basis.
>>
>> For example, if I were to take that output and feed it into "ping" on
>> any of my Linux servers they do indeed interpret 075 as octal and try to
>> ping "61.126.0.0".
> 
> Seth,
> 
> Let me offer the technical basis you are asking for.
(Continue reading)

Permalink | Reply |
headers
Andy Newton | 30 Mar 2012 14:54

Re: zero-padded IP addresses in "startAddress" and "endAddress" values


On Mar 30, 2012, at 4:06 AM, Seth Mattinen wrote:

> I personally treat IP addresses as unsigned integers (or double/float
> for IPv6). It never occurred to me to treat an IP as a string since it's
> supposed to represent a 32-bit or 128-bit number. Integer comparisons
> are, IMO, easier.

Seth,

Interpretation of IP addresses as numbers makes complete sense. But I will note that some languages do not
have unsigned integers and double and float on many platforms, languages, and databases are only 64 bits.
Float can be particularly troublesome as IEEE 754 interpretations of it only give 56 bits of precision.

Comparison as a numeric type is also natural, but in a database where an IP address column is indexed that
difference is only important for an r-tree index which are not very common. Additionally in a database
context, substring matching can be used for prefix queries, though admittedly only on octet boundaries.

Like you, my first inclination as a programmer is to treat IP addresses as numbers. And when I first
encountered the usage of zero-padded IP address strings, doing so had never occurred to me. That being
said, in my career ARIN is not the first place I have seen this, and in the ARIN codebases we have found this
pattern many times, implemented by multiple coders in many subsystems, going back to code that well
predates ARIN.

That long-winded explanation aside, we can certainly take steps to make programming against the Reg-RWS
interface easier if the community desires. New elements can be added that do not have the zero-padded IP
addresses. I do not recommend modifying the current elements as we may break code that counts on the zero
padding. And, as David stated, we should update our documentation. Would adding new elements containing
IP addresses that are not zero-padded be helpful?
(Continue reading)

Permalink | Reply |
headers
Jimmy Hess | 30 Mar 2012 15:33
Picon

Re: zero-padded IP addresses in "startAddress" and "endAddress" values

On Fri, Mar 30, 2012 at 7:54 AM, Andy Newton <andy@...> wrote:
> On Mar 30, 2012, at 4:06 AM, Seth Mattinen wrote:

> That long-winded explanation aside, we can certainly take steps to make programming against the
>Reg-RWS interface easier if the community desires. New elements can be added that do not have the
>zero-padded IP addresses. I do not recommend modifying the current elements as we may break code >that
counts on the zero padding. And, as David stated, we should update our documentation. Would

I would suggest versioning the API;   for example if version X is used
the format is A, if version Y of the API is used then the format is B;
and adding an optional attribute to the element to indicate the format
of its contents.

>adding new elements containing IP addresses that are not zero-padded be helpful?

--
-JH
Permalink | Reply |
headers
Andy Newton | 30 Mar 2012 16:23

Re: zero-padded IP addresses in "startAddress" and "endAddress" values


On Mar 30, 2012, at 3:33 PM, Jimmy Hess wrote:

> I would suggest versioning the API;   for example if version X is used
> the format is A, if version Y of the API is used then the format is B;
> and adding an optional attribute to the element to indicate the format
> of its contents.

Thanks Jimmy. Yes we will version it. More than likely we will add additional elements using another XML
namespace, that way both elements are present but distinguishable.

Again, thanks for the code sample. And I'm sorry for the inconvenience this has caused.

Note that there is an upcoming modification to the Reg-RWS interface but unfortunately it will not contain
this modification as that software is already "in the can."

-andy
Permalink | Reply |
headers
Andy Newton | 30 Mar 2012 17:59

Re: zero-padded IP addresses in "startAddress" and "endAddress" values

All,

So that we may track this suggested improvement and have it considered for prioritization with other
software improvements and changes, will one of you in the community please file this in the ACSP system.
That form can be found here:

https://www.arin.net/app/suggestion/

A reference to this thread describing this issue is here: http://lists.arin.net/pipermail/arin-tech-discuss/2012-March/000192.html

Thanks in advance.

Andy Newton,
Chief Engineer, ARIN
Permalink | Reply |
headers
Dani Roisman | 30 Mar 2012 15:46
Favicon

Re: zero-padded IP addresses in "startAddress" and "endAddress" values

Andy - thanks for considering this.  David mentioned earlier in the thread that it's always been this way - is
that really accurate?  I don't have historical examples, but when we first coded to the RESTful API late in
2011, we didn't see the zero-padding of IPs.

----
Dani Roisman
VP, Network Operations
droisman@...
(281) 714-3714 direct 
(818) 481-5581 cell

| -----Original Message-----
| From: arin-tech-discuss-bounces@... [mailto:arin-tech-discuss-
| bounces@...] On Behalf Of Andy Newton
| Sent: Friday, March 30, 2012 07:54
| To: Seth Mattinen
| Cc: <arin-tech-discuss@...>
| Subject: Re: [arin-tech-discuss] zero-padded IP addresses in "startAddress"
| and "endAddress" values
| 
| 
| On Mar 30, 2012, at 4:06 AM, Seth Mattinen wrote:
| 
| > I personally treat IP addresses as unsigned integers (or double/float
| > for IPv6). It never occurred to me to treat an IP as a string since it's
| > supposed to represent a 32-bit or 128-bit number. Integer comparisons
| > are, IMO, easier.
| 
| Seth,
|
(Continue reading)

Permalink | Reply |
headers
Andy Newton | 30 Mar 2012 16:31

Re: zero-padded IP addresses in "startAddress" and "endAddress" values


On Mar 30, 2012, at 3:46 PM, Dani Roisman wrote:

> Andy - thanks for considering this.  David mentioned earlier in the thread that it's always been this way -
is that really accurate?  I don't have historical examples, but when we first coded to the RESTful API late
in 2011, we didn't see the zero-padding of IPs.

Dani,

To be truthful I had forgotten this difference between Whois-RWS and Reg-RWS. But to our knowledge, yes
this has already been the case. We had our QA department double check it.

However, our Reg-RWS documentation says it will be returned without zero padding. So this is our mistake.
Sorry for the inconvenience.

Andy Newton
Permalink | Reply |
headers
Jimmy Hess | 30 Mar 2012 05:20
Picon

Re: zero-padded IP addresses in "startAddress" and "endAddress" values

On Thu, Mar 29, 2012 at 8:56 AM, Andy Newton <andy@...> wrote:

I would say that ad-hoc textual representation is dangerous when
presented in an API for remote use,  because it visually _resembles_
an IP so closely that it may confuse a human into thinking it is a
valid IP address,   but  the leading zeros make it non-compliant with
the standard representation of an IP address;   the result is
ill-defined, and the octal interpretation is very common.

The leading zeros make the IP addresses unparseable by standard APIs.
I'll give you a  "padded" string has its uses,  but that should be the
responsibility of the application,
and it makes sense to omit the dots in that case to avoid any confusion.

Interoperability with applications utilizing standard APIs should also
be preferred over supporting hacks to facilitate programming in
languages that lack them.

Remote interfaces should utilize the standard representation of IP
addresses,  either the standard textual representation of an IP
address,   or an  internal format that won't likely lead to confusion
or errors, such as the decimal IP address in network byte order.

The  "zero padding"  is non-standard  and    results in something that
cannot be parsed so well with standard APIs for interpreting IP
addresses.

For example,
   "012.020.030.040"   actually  indicates the IP address "10.16.24.32"
(Continue reading)

Permalink | Reply |
headers
Andy Newton | 30 Mar 2012 14:54

Re: zero-padded IP addresses in "startAddress" and "endAddress" values


On Mar 30, 2012, at 5:20 AM, Jimmy Hess wrote:

> I would say that ad-hoc textual representation is dangerous when
> presented in an API for remote use,  because it visually _resembles_
> an IP so closely that it may confuse a human into thinking it is a
> valid IP address,   but  the leading zeros make it non-compliant with
> the standard representation of an IP address;   the result is
> ill-defined, and the octal interpretation is very common.

Jimmy,

The RFC literature quite liberally refers to the notation as "dotted-decimal" and therefore
zero-padding is a good faith interpretation of the standard form. That being said...

> For example,
>   "012.020.030.040"   actually  indicates the IP address "10.16.24.32"
> 
> [root <at> orb1 ~ ]# ping -c 5 012.020.030.040
> PING 012.020.030.040 (10.16.24.32) 56(84) bytes of data.
>                                        ^^^^^^^^^^^
> 
> 
> ^C
> cat <<END > blah.c
>> #include <stdio.h>
>> #include <arpa/inet.h>
>> 
>> int main()
>> {
(Continue reading)

Permalink | Reply |

Gmane