APNIC Allocated 14/8, 223/8 today

[Skeeve Stevens]

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
ske...@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.

Re: APNIC Allocated 14/8, 223/8 today

[Stephane Bortzmeyer]

On Wed, Apr 14, 2010 at 05:02:10PM +1000,
 Skeeve Stevens  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).

--- Begin Message ---
___

Two /8s allocated to APNIC from IANA (14/8 and 223/8)
___


Dear colleagues

The information in this announcement is to enable the Internet
community to update network configurations, such as routing filters,
where required.

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

Reachability and routability testing of the new prefixes will commence
soon. The daily report will be published at the usual URL:

http://www.ris.ripe.net/debogon

For more information on the resources administered by APNIC, please
see:

http://www.apnic.net/db/ranges.html

For information on the minimum allocation sizes within address
ranges administered by APNIC, please see:

http://www.apnic.net/db/min-alloc.html

Please be aware, there are now just twenty /8s remaining in IANA's
unallocated IPv4 address pool.

Kind regards,

___

APNIC Secretariat
Asia Pacific Network Information Centre (APNIC) Tel: +61-7-3858-3100
PO Box 2131 Milton, QLD 4064 Australia Fax: +61-7-3858-3199
Level 1, 33 Park Road, Milton, QLD http://www.apnic.net
___



-- 
This is the SANOG (http://www.sanog.org/) mailing list.
--- End Message ---

advertisements of 14/8 and 223/8

[Geoff Huston]

Hi,

APNIC and NTT are cooperating in a project to investigate the properties of 
unwanted traffic that is being sent to specific destinations in the address 
blocks of 14.0.0.0/8 and 223.0.0.0/8. These address blocks have been recently 
allocated to APNIC from the IANA, and APNIC and NTT are wanting to undertake 
this investigation prior to the commencement of ordinary allocations. 
Accordingly, APNIC has authorized AS38639 to advertise routes for 14.0.0.0/8 
and 223.0.0.0/8 from now until 26 April 2010, and requests that AS38639's peers 
and upstreams accept this as a legitimate routing advertisement.

thanks,

   Geoff Huston
   APNIC

Re: APNIC Allocated 14/8, 223/8 today

[Nick Hilliard]

On 14/04/2010 08:06, Srinivas Chendi  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

Re: Mikrotik RouterOS

[Allan Eising]

On Mon, 12 Apr 2010 14:54:59 -0400, James Jones wrote:

> I am currently looking at using RouterOS as a way to build a Metro
> Ethernet solution. Does anyone have experience with the device and the
> OS? How is the performance? Are there any "Gotchas"?
> 
> 
> -James

I've been working with RouterOS for a while, especially with it's more 
service provider oriented features such as MPLS and BGP. Here are some 
points that might help you:

1) Consider what device you want to run it on, especially regarding 
expected throughput. If you want to run it on x86 hardware, consider 
either buying one of the available x86 solutions, such as PoweRouter or 
OGMA connect, or spend some time evaluating that your hardware 
configuration is indeed supported. RouterOS is based on a 32-bit linux 
kernel, and it's not the newest one... The upcoming version 5 will 
feature a recent kernel, but is still 32bit, so don't expect things like 
multiqueue to work on your intel NICs.

2) Understand that bugs happen, and new software is released frequently. 
Acknowledge that there might be issues with quality assurance for new 
software versions. Expect to test new versions rigorously before rolling 
out. That said, MikroTik support is very friendly and will help you with 
most issues.

3) Their RouterBoard products are cheap, and are often made from the 
cheapest components. I have seen issues with faulty components.
Recently, they EOL'd their only rack-mount router, the RB1000U, while the 
replacement - a cheaper router with more ports, and little less power - 
has not yet gone into sale.

And now for all the good things:

4) Their MPLS support, as well as their implementations of routing 
protocols are quite good. They support both MPLS and VPLS and can even 
work with Cisco's BGP-signalled VPLS, as well as the rfc version of it.

5) The CLI is easy to work with, and has an excellent API that allows you 
to easily integrate provisioning into your existing systems. There is 
also a graphic tool called WinBox. This tool gives you a very easy 
overview of your router's configuration, so put away any CLI-only bias 
you might have inherited from working with other vendors.

I consider their routers great for Metro Ethernet solutions on a lower 
scale. Their low cost makes it very easy to roll out an MPLS network, as 
the price for a PoP will be low, however keep an eye on the performance 
of the routers.

You are welcome to contact me if you have any additional questions.

Regards,

Allan Eising

Re: Router for Metro Ethernet

[Tim Franklin]

> Some caveats:
> 
> 1. only the ME version supports MPLS, in case you want to overlay an
> MPLS TE/VPN network on a Metro Ethernet Forum (MEF) ELAN raw Ethernet
> service.
> 2. If you are using IP multicast, make sure that the Metro Ethernet
> provider supports PIM snooping, otherwise (S,G) directed multicast
> packets will be flooded out all service provider ports that connect
> to
> your devices, emulating a 1993-style Ethernet hub. 

3. Only "switch-style" QoS, not full-blown MQC.  The 3750ME has two "router" 
ports which do mostly support MQC, but still have some limitations (e.g. 
traffic locally sourced from the device is not correctly classified / marked).  
Which is all kind of what you'd expect from a switch, but may be relevent if 
the original question was "which router?"

Regards,
Tim.

Re: Router for Metro Ethernet

[Tim Franklin]

> All of those numbers are straight forwarding with nothing turned on
> and 64 
> byte packets.  That way you get a nice idea of what the CPU can do.

They're also, as ever, unidirectional, so you can immediately halve them if 
your question is "what size pipe can I connect this device to?"

As a VPN managed CE, with QoS, BGP, a little bit of IPSLA etc, I'm seeing a 
practical limit of around 70Mb/s bidirectional out of the 3845.

Regards,
Tim.

Re: APNIC Allocated 14/8, 223/8 today

[Dave Hart]

On Wed, Apr 14, 2010 at 09:20 UTC, Nick Hilliard wrote:
> On 14/04/2010 08:06, Srinivas Chendi  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

Re: APNIC Allocated 14/8, 223/8 today

[Joe Abley]

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

Re: APNIC Allocated 14/8, 223/8 today

[Vincent Hoffman]

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  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
>   

Re: APNIC Allocated 14/8, 223/8 today

[Larry Sheldon]

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  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

Re: APNIC Allocated 14/8, 223/8 today

[Dave Hart]

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:
Bad Request (Invalid Hostname)

FireFox is probably violating some spec.  Thankfully.

Cheers,
Dave Hart

Re: Router for Metro Ethernet

[Bill Stewart]

On Tue, Apr 13, 2010 at 9:12 PM, Tony Varriale  wrote:
> > From: "Bill Stewart" 
> > Be careful using 3845s for 100 Mbps connections or above
> The 3825 says 179mbps on their spec sheet.  Not sure where you are getting
> your numbers but they are way off.
> All of those numbers are straight forwarding with nothing turned on and 64
> byte packets.  That way you get a nice idea of what the CPU can do.

That's the spec sheet, and that's for straight forwarding.
If you want to do much of anything else at all with the router,
Cisco has another web page that says they only recommend 45Mbps on the
3845 and something like half that on the 3825.
It's especially an issue if you need to do traffic-shaping, which you
usually do for MetroE.
-- 

 Thanks; Bill

Note that this isn't my regular email account - It's still experimental so far.
And Google probably logs and indexes everything you send it.

alt.folklore.nanog (was:Re: Commodore PET, was: Re: legacy /8)

[Lamar Owen]

On Sunday 11 April 2010 06:18:28 am Jeroen van Aart wrote:
> According to the book "On the edge" by Brian Bagnall the first showing
> was in March 1977. In January of 1977 it was announced at the CES.  It 
> was shown to John Roach, then an operations guy of Rat
> Shack. He was interested to have it distributed in their stores but
> because Jack Tramiel also demanded they'd order a lot of Commodore's
> calculators John Roach didn't go through with the deal and decided they
> could make their own... missed opportunities.

While this isn't alt.folklore.computers, I have a minor correction (and a 
lead-in to a question about early IP routers):

According to the book 'Priming the Pump: How TRS-80 Enthusiasts Helped Spark 
the PC Revolution' the prototype TRS-80 was shown to Charles Tandy on 
Groundhog Day, February 2, 1977.  One of the great engineering stories of our 
time is that of Steve Leininger, who is the person responsible for the design 
and construction of the prototype.  It was announced to the public on August 
3, 1977, and sold a quarter of a million units over its lifetime (talking 
about the 'Model I' only).  IOW, the TRS-80 was already in design before the 
PET was shown to John Roach; that's the minor correction.

Three Steves (Leininger, Wozniak, Jobs others?) at the lead-in of the 
microcomputer (and thus the Internet) age.

Along those lines (and the primary reason I reply), does anyone here have any 
Proteon routers still in operation?  I have three with full docs and those 
80Mb/s ProNET over fiber links, and am wondering if they are at all useful in 
this day and ageif nothing else, the enclosure makes a nice shielded rack 
boxHey, I hate to see gear sit on the shelf unused, regardless of how old 
it is!

Undersea cable cut?

[St. Onge,Adam]

Seeing a serious uptick in latency to India from North America and am hearing 
reports of an undersea cable cut in the Mediterranean? Has anyone else heard 
something similar?

Thanks,
Adam

==
This communication, including attachments, is confidential, may be subject to 
legal privileges, and is intended for the sole use of the addressee. Any use, 
duplication, disclosure or dissemination of this communication, other than by 
the addressee, is prohibited. If you have received this communication in error, 
please notify the sender immediately and delete or destroy this communication 
and all copies.

Re: Undersea cable cut?

[Chris McDonald]

There's a cut in SWM4

*SMW4 Segment 4.1 cable fault*

Cable shunt fault developed on SMW4 segment 4.1 (Egypt / Alexandria –
Branching Unit #4A onward France / Marseilles) at 07:15GMT on 14-Apr. 2010.
However the shunt fault has further deteriorated and the cable segment was
down at 10:03GMT.  Only four unprotected Singapore – London / Frankfurt
STM-4c IP trunks were being affected.

SMW4 NOC updated that there is a shunt fault in segment 4.1 between  Egypt /
Alexandria and France / Marseilles with cable fault on Fiber Pair #2 at
1886.152 km from Alexandria towards Palermo.  The traffic landed at Palermo
onwards to Europe was being affected, while the traffic running between
Alexandria and Marseilles via Fiber Pair #1 is still maintained.




On Wed, Apr 14, 2010 at 2:13 PM, St. Onge,Adam wrote:

> Seeing a serious uptick in latency to India from North America and am
> hearing reports of an undersea cable cut in the Mediterranean? Has anyone
> else heard something similar?
>
> Thanks,
> Adam
>
>
> ==
> This communication, including attachments, is confidential, may be subject
> to legal privileges, and is intended for the sole use of the addressee. Any
> use, duplication, disclosure or dissemination of this communication, other
> than by the addressee, is prohibited. If you have received this
> communication in error, please notify the sender immediately and delete or
> destroy this communication and all copies.
>

Re: Router for Metro Ethernet

[Lamar Owen]

On Monday 12 April 2010 01:28:45 pm Jeffrey Negro wrote:
> Any and all suggestions on the hardware would be greatly appreciated. 
> Thank you in advance!

Well, I've read through this thread as it's unfolded

I repurposed some big hardware (that we already had on-hand) to terminate our 
metro ethernet connection, which replaced a point to point OC3.  The carrier 
was easy to work with, and provisioned the local loop over 1000Base-LX, which 
I terminated on a 12008 (same router that previously terminated the OC3).

Yep, overkill.  Until I want IPv6, that is, and then the 1 port GE will be 
about right for a metro e at less than 100Mb/s bandwidth.  And 12000's are 
beasts for HA.

Now, 12000's aren't designed for edges, really, so there's no NAT and some 
other edge features.  And it has a pretty weak CPU for the control plane, 
especially if it's a GRP.  But if you happen to have one on hand.

A 7200 NPE-G1 or G2 would work, as would a 7400 if you don't mind older IOS.  
The 7400 is more than capable of 150Mb/s throughput with features; I have one 
that had previously terminated the other end of the OC3, which is still there, 
and still doing NAT and other edge features very well.  I was able to saturate 
the OC3 when it was lit, with features turned on, and the 7400 churned through 
it quite well, with max CPU hitting 75% or so under the heaviest loads.

If you have a 7500 series lying around you can go that route, too, as current 
12.4 mainline is still there for the RSP platform.  But the HA with 12.4 is 
not as robust as with 12.0S, and with 12.0S it acts more like a 12000 and less 
like an edge router.  And even the RSP16's CPU is a little weak for heavy edge 
features.

There's a lot of older Cisco kit that will handle 40Mb/s quite well.  And, 
well, Cisco gear is built better than most 'industrial' x86 boxes out there 
(even if Cisco has shipped 'industrial' x86 boxes before, like the rebranded 
IBM x Series servers that were labeled 'Content Engines' and the PC's 
relabeled as LocalDirectors and PIXen of various models; the router platforms 
have, in my experience at least, been more reliable).  As much as I like and 
use Linux (and I installed SLS from floppy tape back in the day), I rest easier 
at night with a 12008 terminating the circuit.

Re: APNIC Allocated 14/8, 223/8 today

[Thomas Habets]

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[] = { "tho...@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;

Re: APNIC Allocated 14/8, 223/8 today

[Neil Harris]

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:
Bad Request (Invalid Hostname)

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.

Root Zone DNSSEC Deployment Technical Status Update

[Joe Abley]

This is the fourth of a series of technical status updates intended
to inform a technical audience on progress in signing the root zone
of the DNS.


RESOURCES

Details of the project, including documentation published to date,
can be found at http://www.root-dnssec.org/.

We'd like to hear from you. If you have feedback for us, please
send it to roots...@icann.org.


DOCUMENTATION

The following draft document was recently published:

 - Resolver Testing with a DURZ
 - TCR - Proposed Approach to Root Key Management

ICANN has begun the process of formally soliciting expressions of
interest for volunteers from the technical community to act as
Trusted Community Representatives. These volunteers will witness
cryptographic key ceremonies and also carry out various important
roles relating to KSK key management. For more information, see:

  http://www.icann.org/en/announcements/announcement-12apr10-en.htm

Expressions of interest can be submitted here:

  http://www.root-dnssec.org/tcr/


DEPLOYMENT STATUS

KSR exchanges continue between production platforms at VeriSign
and ICANN.

Build-out of KSK Key Ceremony facilities at ICANN continues, and
both facilities (east- and west-coast USA) are expected to be ready
on schedule.

The incremental deployment of DNSSEC in the Root Zone is being
carried out first by serving a Deliberately Unvalidatable Root Zone
(DURZ), and subsequently by a conventionally signed root zone.
Discussion of the approach can be found in the document "DNSSEC
Deployment for the Root Zone", as well as in the technical presentations
delivered at RIPE, NANOG, IETF and ICANN meetings.

Twelve of the thirteen root servers have now made the transition
to the DURZ.  No harmful effects have been identified.  Some early
analysis of packet captures from many root servers surrounding each
event was recently presented at the IETF meeting in Anaheim, CA,
USA and can be found with other presentation materials at
.


PLANNED DEPLOYMENT SCHEDULE

Already completed:

  2010-01-27: L starts to serve DURZ

  2010-02-10: A starts to serve DURZ

  2010-03-03: M, I start to serve DURZ

  2010-03-24: D, K, E start to serve DURZ

  2010-04-14: B, H, C, G, F start to serve DURZ

To come:

  2010-05-05: J starts to serve DURZ

  2010-07-01: Distribution of validatable, production, signed root
zone; publication of root zone trust anchor

  (Please note that this schedule is tentative and subject to change
  based on testing results or other unforeseen factors.)

A more detailed DURZ transition timetable with maintenance windows
can be found in the document "DNSSEC Deployment for the Root Zone",
the most recent draft of which can be found on the project web page
at .

Re: alt.folklore.nanog

[Jeroen van Aart]

Lamar Owen wrote:
and construction of the prototype.  It was announced to the public on August 
3, 1977, and sold a quarter of a million units over its lifetime (talking 
about the 'Model I' only).  IOW, the TRS-80 was already in design before the 
PET was shown to John Roach; that's the minor correction.


Right, I believe the book was trying to say that the missed opportunity 
is that Commodore could have sold the original PET in Tandy's stores. I 
assume you were (as I was) wondering why the hell Tandy would have done 
that as it've been a competitor to the TRS-80. But then Commodore 
(having taken over MOS technologies) sold CPUs to their major 
competitors including Apple and Atari. So it's not unheard of.


Regards,
Jeroen

comcast routing contact needed (wheeling/weirton, wv)

[jason jeffries]

Can a router-handy person with Comcast contact me off-list?

We have a customer that is having problems between a branch office on our 
network, and their HQ's Comcast connection--seems like packets from (at least) 
one particular IP on their net here are going awry in Comcast somewhere.

Thanks!

jason jeffries - jjeffr...@labs.net
labyrinth solutions - as26097