Hey all, As the subject says, APNIC was allocated 14/8 and 223/8 today... which does seems a little close after 1/8 and 27/8 in January 2010 - since 1/8 hasn't started, I'm surprised about the new ones. Not sure why I haven't seen any announcements about it... just thought I'd break the news... ...Skeeve -- Skeeve Stevens, CEO/Technical Director eintellego Pty Ltd - The Networking Specialists skeeve@eintellego.net / www.eintellego.net Phone: 1300 753 383, Fax: (+612) 8572 9954 Cell +61 (0)414 753 383 / skype://skeeve www.linkedin.com/in/skeeve ; facebook.com/eintellego -- NOC, NOC, who's there? Disclaimer: Limits of Liability and Disclaimer: This message is for the named person's use only. It may contain sensitive and private proprietary or legally privileged information. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. eintellego Pty Ltd and each legal entity in the Tefilah Pty Ltd group of companies reserve the right to monitor all e-mail communications through its networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of any such entity. Any reference to costs, fee quotations, contractual transactions and variations to contract terms is subject to separate confirmation in writing signed by an authorised representative of eintellego. Whilst all efforts are made to safeguard inbound and outbound e-mails, we cannot guarantee that attachments are virus-free or compatible with your systems and do not accept any liability in respect of viruses or computer problems experienced.
On Wed, Apr 14, 2010 at 05:02:10PM +1000, Skeeve Stevens <Skeeve@eintellego.net> wrote a message of 37 lines which said:
As the subject says, APNIC was allocated 14/8 and 223/8 today...
Actually, it was a few days ago.
Not sure why I haven't seen any announcements about it...
There have been announcements (here a mail from APNIC on the Sanog mailing list).
On 14/04/2010 08:06, Srinivas Chendi <sunny@apnic.net> wrote:
APNIC received the following IPv4 address blocks from IANA in April 2010 and will be making allocations from these ranges in the near future:
014/8 223/8
Sunny, Please be careful about how you write this. "014" is formally an octal representation, and what you've written there actually means that APNIC has received 12/8 (= octal 014). Nick
On Wed, Apr 14, 2010 at 09:20 UTC, Nick Hilliard wrote:
On 14/04/2010 08:06, Srinivas Chendi <sunny@apnic.net> wrote to SANOG:
014/8 223/8
Sunny,
Please be careful about how you write this. "014" is formally an octal representation, and what you've written there actually means that APNIC has received 12/8 (= octal 014).
Nick
Nick, My eyebrow raised at the leading zero as well, but I'd call it ambiguous. 0x14 is unambiguously decimal 20, but 014 is only unambiguous in a context that defines leading zero as implying octal. For a C program relying on the runtime to convert text to numeric representation, it depends. sscanf("%d", &myint) will convert 014 to decimal 14, "%i" gets decimal 12. I personally hunt down and kill %i and other octal-assuming code when I see it, except where octal is conventional. To my eyes, 0xFF (or FF) screams "all bits lit" while 0377 (or 377) only hesitantly clears its throat. Moreover, I assume computers will be used by people who have never had reason to believe a leading zero implies base 8, and I find no joy in forcing them to learn that quirk of computing history. Take care, Dave Hart
On 2010-04-14, at 08:45, Dave Hart wrote:
My eyebrow raised at the leading zero as well, but I'd call it ambiguous. 0x14 is unambiguously decimal 20, but 014 is only unambiguous in a context that defines leading zero as implying octal.
Note that such a context is inet_ntoa(), at least on BSD-based machines I have handy. From inet(3): All numbers supplied as ``parts'' in a `.' notation may be decimal, octal, or hexadecimal, as specified in the C language (i.e., a leading 0x or 0X implies hexadecimal; otherwise, a leading 0 implies octal; other- wise, the number is interpreted as decimal). Given the popularity of Octal in address nomenclature in 2010 this seems like a small problem for mail to NANOG. However, if the practice extends to use in contexts which might be machine-readable (e.g. in text files which are auto-curl(1)d out of cron to build filters) then there is potential for hilarity. Joe
On Wed, 14 Apr 2010, Joe Abley wrote:
From inet(3): All numbers supplied as ``parts'' in a `.' notation may be decimal, octal, or hexadecimal, as specified in the C language (i.e., a leading 0x or 0X implies hexadecimal; otherwise, a leading 0 implies octal; other- wise, the number is interpreted as decimal).
But note Theos reply about just this paragraph: "Yes, we should fix the manual page. Single Unix is wrong in this regard." -- http://kerneltrap.org/mailarchive/openbsd-bugs/2009/6/6/5882713/thread Also this from two months ago: http://www.merit.edu/mail.archives/nanog/msg05062.html Don't expect non-canonical IP address formats to work. Because they often don't. And you just might get silent errors. --------- typedef struct me_s { char name[] = { "Thomas Habets" }; char email[] = { "thomas@habets.pp.se" }; char kernel[] = { "Linux" }; char *pgpKey[] = { "http://www.habets.pp.se/pubkey.txt" }; char pgp[] = { "A8A3 D1DD 4AE0 8467 7FDE 0945 286A E90A AD48 E854" }; char coolcmd[] = { "echo '. ./_&. ./_'>_;. ./_" }; } me_t;
On 14/04/2010 13:45, Dave Hart wrote:
On Wed, Apr 14, 2010 at 09:20 UTC, Nick Hilliard wrote:
On 14/04/2010 08:06, Srinivas Chendi <sunny@apnic.net> wrote to SANOG:
014/8 223/8
Sunny,
Please be careful about how you write this. "014" is formally an octal representation, and what you've written there actually means that APNIC has received 12/8 (= octal 014).
Nick
Nick,
My eyebrow raised at the leading zero as well, but I'd call it ambiguous. 0x14 is unambiguously decimal 20, but 014 is only unambiguous in a context that defines leading zero as implying octal. For a C program relying on the runtime to convert text to numeric representation, it depends. sscanf("%d", &myint) will convert 014 to decimal 14, "%i" gets decimal 12.
I personally hunt down and kill %i and other octal-assuming code when I see it, except where octal is conventional. To my eyes, 0xFF (or FF) screams "all bits lit" while 0377 (or 377) only hesitantly clears its throat. Moreover, I assume computers will be used by people who have never had reason to believe a leading zero implies base 8, and I find no joy in forcing them to learn that quirk of computing history.
On an up to date OSX install (and Centos linux and FreeBSD) (15:23:17 <~>) 0 $ ping 014.0.0.1 PING 014.0.0.1 (12.0.0.1): 56 data bytes Request timeout for icmp_seq 0
From windows 2003 servert
C:\Documents and Settings\Administrator>ping 014.0.0.01 Pinging 12.0.0.1 with 32 bytes of data: wget (on linux and freebsd) (15:26:02 <~>) 0 $ wget 014.0.0.1 --2010-04-14 15:26:06-- http://014.0.0.1/ Connecting to 014.0.0.1|12.0.0.1|:80... Oddly on OSX it doesnt take it as octal (15:27:30 <~>) 130 $ wget 014.0.0.1 --2010-04-14 15:27:31-- http://014.0.0.1/ Connecting to 014.0.0.1 (014.0.0.1)|14.0.0.1|:80... When it comes to IP addresses, its not history, its important :) Vince
Take care, Dave Hart
On 4/14/2010 09:35, Vincent Hoffman wrote:
On 14/04/2010 13:45, Dave Hart wrote:
On Wed, Apr 14, 2010 at 09:20 UTC, Nick Hilliard wrote:
On 14/04/2010 08:06, Srinivas Chendi <sunny@apnic.net> wrote to SANOG:
014/8 223/8
Sunny,
Please be careful about how you write this. "014" is formally an octal representation, and what you've written there actually means that APNIC has received 12/8 (= octal 014).
Nick
Nick,
My eyebrow raised at the leading zero as well, but I'd call it ambiguous. 0x14 is unambiguously decimal 20, but 014 is only unambiguous in a context that defines leading zero as implying octal. For a C program relying on the runtime to convert text to numeric representation, it depends. sscanf("%d", &myint) will convert 014 to decimal 14, "%i" gets decimal 12.
I personally hunt down and kill %i and other octal-assuming code when I see it, except where octal is conventional. To my eyes, 0xFF (or FF) screams "all bits lit" while 0377 (or 377) only hesitantly clears its throat. Moreover, I assume computers will be used by people who have never had reason to believe a leading zero implies base 8, and I find no joy in forcing them to learn that quirk of computing history.
On an up to date OSX install (and Centos linux and FreeBSD) (15:23:17 <~>) 0 $ ping 014.0.0.1 PING 014.0.0.1 (12.0.0.1): 56 data bytes Request timeout for icmp_seq 0
From windows 2003 servert
C:\Documents and Settings\Administrator>ping 014.0.0.01 Pinging 12.0.0.1 with 32 bytes of data:
wget (on linux and freebsd)
(15:26:02 <~>) 0 $ wget 014.0.0.1 --2010-04-14 15:26:06-- http://014.0.0.1/ Connecting to 014.0.0.1|12.0.0.1|:80...
Oddly on OSX it doesnt take it as octal (15:27:30 <~>) 130 $ wget 014.0.0.1 --2010-04-14 15:27:31-- http://014.0.0.1/ Connecting to 014.0.0.1 (014.0.0.1)|14.0.0.1|:80...
When it comes to IP addresses, its not history, its important :)
I think it is important form us to recognize and accept that this is 2010. The Constitution means what ever the speaker needs for it to mean, or can be dismissed outright. 014 means what ever the speaker needs for it to mean..... It is the duty and responsibility of the hearer (or reader) to figure out how it applies to them for the moment. Standards and agreements on protocol are so eighteenth century.
Vince
Take care, Dave Hart
Dark Ages Larry -- Somebody should have said: A democracy is two wolves and a lamb voting on what to have for dinner. Freedom under a constitutional republic is a well armed lamb contesting the vote. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml
On Wed, Apr 14, 2010 at 14:35 UTC, Vincent Hoffman wrote:
PING 014.0.0.1 (12.0.0.1): 56 data bytes C:\Documents and Settings\Administrator>ping 014.0.0.01 Pinging 12.0.0.1 with 32 bytes of data: Connecting to 014.0.0.1|12.0.0.1|:80... Connecting to 014.0.0.1 (014.0.0.1)|14.0.0.1|:80...
When it comes to IP addresses, its not history, its important :)
Good point. In most of these classic utility contexts, octal is generally accepted. 32-bit unsigned decimal representation has provided obfuscation for fun and profit in HTTP URIs. I'm sure you can find some software that still accepts it, and some that doesn't. For me, with no proxy, Chrome and IE both accept a non-dotted numeric IPv4 URI, but rewrite it in the address bar to the familiar dotted quad format. FireFox shows an error page that appears equivalent to: <h1>Bad Request (Invalid Hostname)</h1> FireFox is probably violating some spec. Thankfully. Cheers, Dave Hart
On 14/04/10 15:54, Dave Hart wrote:
On Wed, Apr 14, 2010 at 14:35 UTC, Vincent Hoffman wrote:
PING 014.0.0.1 (12.0.0.1): 56 data bytes C:\Documents and Settings\Administrator>ping 014.0.0.01 Pinging 12.0.0.1 with 32 bytes of data: Connecting to 014.0.0.1|12.0.0.1|:80... Connecting to 014.0.0.1 (014.0.0.1)|14.0.0.1|:80...
When it comes to IP addresses, its not history, its important :)
Good point. In most of these classic utility contexts, octal is generally accepted. 32-bit unsigned decimal representation has provided obfuscation for fun and profit in HTTP URIs. I'm sure you can find some software that still accepts it, and some that doesn't. For me, with no proxy, Chrome and IE both accept a non-dotted numeric IPv4 URI, but rewrite it in the address bar to the familiar dotted quad format. FireFox shows an error page that appears equivalent to: <h1>Bad Request (Invalid Hostname)</h1>
FireFox is probably violating some spec. Thankfully.
Cheers, Dave Hart
This is a historical issue with inet_aton(). See http://tools.ietf.org/html/draft-main-ipaddr-text-rep-00 for more details on the history behind this. Firefox bug 554596 addresses this problem. -- N.
participants (9)
-
Dave Hart -
Joe Abley -
Larry Sheldon -
Neil Harris -
Nick Hilliard -
Skeeve Stevens -
Stephane Bortzmeyer -
Thomas Habets -
Vincent Hoffman