Re: Multi-6 [WAS: OT - Vint Cerf joins Google]

[Igor Gashinsky]

:: > We also like that fact that we can change our 
:: > announcements so others can only use prefix X through transit provider Y 
:: > and not transit provider Z, unless transit provider Y goes away (those 2 
:: > are obviously not the only uses of such policies, but are just examples). 
:: 
:: 
:: This also seems like it achievable via DNS hacks on your side.  Again,
:: this seems like it can be done locally.

Wonderful.. so now we have to do routing in DNS, a protocol that's not 
exactly designed for rapid convergence (yes, neither is BGP, but it's a 
*lot* faster then DNS). Just brilliant.

:: While I realize that the status quo is always the most comfortable, you
:: should also recognize that the status quo is simply not sustainable from
:: an architectural viewpoint.  Thus, the charter of multi6/shim6 is to
:: change the model into one that is sustainable, and the fact that certain
:: features and functionality will be lost is an unfortunate necessity.

While the status quo is not sustainable if growth continues for 4+ years, 
deciding to "fix" the problem by pretending that there was never a 
good reason for it in the first place, and moving it to a different place 
is not a very good architectural solution either. 

:: Well, I cannot disagree with you.  However, this is the direction that
:: the IETF has chosen after careful and lengthy discussions.  Those of us
:: who had alternative ideas have long since lost the battle and are
:: resigned to the inevitable, of which shim6 seems like the best of a bad
:: lot.

And I hope this thread points out why more content isn't v6 enabled.. And 
no, I'm not saying that "the evil greedy bastards" did this on purpose, 
unfortunately, it's simply yet another example of things being created 
without operator involvement (and yes, we, the operators, are at fault for 
that). See you on [EMAIL PROTECTED]

-igor

Re: LA power outage?

[Romain Komorn]

OneWilshire did lose power but their generators did their
job just fine. Getting up to any data center space there
was impossible on the other hand. They have enough
current to run the entire building, just not the elevators,
the lights in the stairwells, or the key-card locks on the
data center doors (or so management told the bunch of us
who were waiting outside).

Still, none of our circuits lost power, which is better
off than half of L.A. was.


On Mon, 12 Sep 2005 21:21:59 -, "Reeves, Rob" said:

We've been told by our field tech in LA that One Wilshire had lost power
for a bit, but it is now restored.  I don't know the duration of the
outage, but our equipment there is on DC and did not go down.


So - who in LA is going to be telling Santa they want a new data-center  
sized

diesel UPS genset for Christmas? ;)




--
Romain Komorn
System Administrator
Globat.com, Webhosting Made Easy
http://www.Globat.com/

Re: LA power outage?

[Valdis . Kletnieks]

On Mon, 12 Sep 2005 21:21:59 -, "Reeves, Rob" said:
> We've been told by our field tech in LA that One Wilshire had lost power
> for a bit, but it is now restored.  I don't know the duration of the
> outage, but our equipment there is on DC and did not go down.

So - who in LA is going to be telling Santa they want a new data-center sized
diesel UPS genset for Christmas? ;)


pgpU2Yfec5s7R.pgp
Description: PGP signature

Re: Multi-6 [WAS: OT - Vint Cerf joins Google]

[John Payne]

On Sep 12, 2005, at 7:43 PM, Tony Li wrote:

Rather, what is needed is a mechanism that allows congestion control 
and
mechanisms to feed into the address selection algorithms, so that when 
a

link does become saturated, some traffic (but not all! ;-), shifts to
alternate addresses.


Not disagreeing, but where is that implementation or RFC or draft or 
discussion?


We have something that works in v4 that a lot of places rely on... and 
that is being taken away in v6 with nothing (that has been mentioned) 
to replace it.


I'm just tired of people whining about the lack of v6 take up when the 
tools needed for many sites.


And yes, I'm fully aware that I (and others) should have been active in 
multi6... however, it never occurred to me that multihomed sites would 
be left completely out in the cold with only a token gesture.

Re: Multi-6 [WAS: OT - Vint Cerf joins Google]

[Crist Clark]

Igor Gashinsky wrote:
[snip]


Moving everything to the end-hosts is simply not a good idea imho.


But isn't that what IP is supposed to be about? Smart endpoints, dumb
network (a.k.a. the stupid network)?
--
Crist J. Clark   [EMAIL PROTECTED]
Globalstar Communications(408) 933-4387

Re: Multi-6 [WAS: OT - Vint Cerf joins Google]

[Igor Gashinsky]

:: All in all, site traffic engineering is NOT going to be an easy problem
:: to solve in a hop-by-hop forwarding paradigm based on clever
:: manipulation of L3 locators.  Architecturally, what one would really
:: like is to not worry about the traffic engineering problem per-se.
:: Rather, what is needed is a mechanism that allows congestion control and
:: mechanisms to feed into the address selection algorithms, so that when a
:: link does become saturated, some traffic (but not all! ;-), shifts to
:: alternate addresses.

Traffic engineering is not *only* about congestion, in fact, for a large 
content provider, it's about *policy*. Content providers like the fact 
that by manipulating the routing policy we can chose to send X amount of 
traffic to B via peering link Y (provided that prefix is announced by 
both peers Y and Z). We also like that fact that we can change our 
announcements so others can only use prefix X through transit provider Y 
and not transit provider Z, unless transit provider Y goes away (those 2 
are obviously not the only uses of such policies, but are just examples). 
For us (and i'm sure not only us) it's about control, and that control 
is required for financial, political (and when the 2 intersect), as well as 
performance engineering reasons, things that are easily done in v4 right 
now, and can not be done simply in v6 (please correct me if I'm wrong 
here), unless every datacenter all of a sudden gets a /32 (and if the 
folks in ARIN have no problems giving a large content provider a /26 
(of v6 space) in order to encourage it's adoption, because the 
current multihoming strategies simply do not work, please do drop me a 
line)

Moving everything to the end-hosts is simply not a good idea imho.

-igor

Re: Multi-6 [WAS: OT - Vint Cerf joins Google]

[Tony Li]

> Or, on top of that, how traffic engineering can be performed with shim6..
> 
> -igor
> (firmly in the shim6 does not adress *most* of the issues camp)


Shim6 doesn't do what most end user sites would like to think of as
traffic engineering.

For a multihomed site, traffic engineering is about inbound or outbound
traffic loading.  Affecting inbound traffic distribution means that
there needs to be a site-specific locus of control that is capable of
causing all of the hosts within the domain to alter the destination
address that their correspondents are using.  This was seen as extremely
complicated.

Similarly, outbound traffic engineering would require a locus of control
that has knowledge of the site's external routing tables and can affect
the destination addresses used by the site's hosts.  This also seems
extremely complicated.

Then, there is the inherent conflict: what happens when the remote
traffic engineering conflicts with the local traffic engineering?

All in all, site traffic engineering is NOT going to be an easy problem
to solve in a hop-by-hop forwarding paradigm based on clever
manipulation of L3 locators.  Architecturally, what one would really
like is to not worry about the traffic engineering problem per-se.
Rather, what is needed is a mechanism that allows congestion control and
mechanisms to feed into the address selection algorithms, so that when a
link does become saturated, some traffic (but not all! ;-), shifts to
alternate addresses.

Tony
[Firmly in the camp that not all issues have simple, pragmatic solutions
-- and thus not all issues should be solved.]

Re: Multi-6 [WAS: OT - Vint Cerf joins Google]

[Tony Li]

> Whilst this thread is open... perhaps someone can explain to me how
> shim6 is as good as multihoming in the case of redundancy when one of
> the links is down at the time of the initial request, so before any
> shim-layer negotiation happens.
> 
> I must be missing something, but there's a good chance that the
> requester is going to have to wait for a timeout on their SYN packets
> before failing over to another address to try.   Or is the requester
> supposed to send SYNs to all addresses for a hostname and race them off?


There are a variety of possible implementations.  A full timeout and
serial retries are one extreme.  Trying all addresses in parallel is
another.  Anything in between is not out of the bounds of possibility.

IMHO, the thing to do is to send out the first SYN and wait 1 RTT, not a
full timeout.  Then, try two addresses.  After the next RTT, try four
addresses...  It's just binary exponential backoff of another flavor.  ;-)

My $.02,
Tony

Re: LA power outage?

[Henry Linneweh]

Utility Error Blamed for L.A. Blackout

http://news.yahoo.com/s/ap/20050912/ap_on_re_us/la_power_outage

-Henry

--- Kevin <[EMAIL PROTECTED]> wrote:

> 
> I've been dealing with a data center outage due to
> this,
> and power just came back up a few minutes ago.
> 
> Halon dumps are only fun from the outside.
> 
> Kevin Kadow
> 

Re: Multi-6 [WAS: OT - Vint Cerf joins Google]

[Marshall Eubanks]

On Mon, 12 Sep 2005 17:41:51 -0400
 John Payne <[EMAIL PROTECTED]> wrote:
> 
> 
> On Sep 12, 2005, at 6:58 AM, Iljitsch van Beijnum wrote:
> 
> >> I'll be blunt.  As long as that question is up in the air, none of 
> >> the major content providers are going to do anything serious in the 
> >> IPv6 arena.
> >
> > Well, I have no evidence of them doing anything with IPv6 anyway, so I 
> > don't know if this makes a difference.
> 
> I have a very strong feeling that part of the lack of content providers 
> on IPv6 is due to the lack of multihoming.
> 

No, I would say it is due to the lack of an audience that can _only_  be reached
(or even _best_ be reached) using IPv6.

Once the audience is there, the content providers will follow.

Regards
Marshall

> Whilst this thread is open... perhaps someone can explain to me how 
> shim6 is as good as multihoming in the case of redundancy when one of 
> the links is down at the time of the initial request, so before any 
> shim-layer negotiation happens.
> 
> I must be missing something, but there's a good chance that the 
> requester is going to have to wait for a timeout on their SYN packets 
> before failing over to another address to try.   Or is the requester 
> supposed to send SYNs to all addresses for a hostname and race them 
> off?
> 
> 

Re: Multi-6 [WAS: OT - Vint Cerf joins Google]

[Brandon Butterworth]

> >> So how do you know it's 4 million and not 4.1?
> 
> > Could be 4.1 or even 4.2.
> 
> And therein lies the problem.

My point, we don't know so some arbitrary or technology limits will
have to do as there isn't financial reason to make something
bigger

> in any event, 32-bit AS  
> numbers allow for 4 billion ASes, not 4 million.

Of course.

So we know it's somewhere between 4G and current 20K. If the current
policies apply then ASs may not increase greatly but prefixes will be
lots less.

Sounds like no problem for multi homing as we do now if nothing more
acceptable is agreed. Otherwise people will just ignore V6 until it's
too late

V6 could have saved lots of upgrades for those about to hit
the ~250K V4 limit of existing Ciscos

> > If we need it then it will exist, if not then we won't be able to do
> > that and will do something else instead
> 
> That's not good engineering.

It's what people do though, good engineering is pointless if it doesn't
get used

> we still have SOME time  
> to come up with new stuff that will make multihoming in IPv6 scale.

As long as it doesn't involve pushing the problem onto the hosts, C & J
don't always get it right, I'd hate to see 1M times more machines relying
on M or L.

brandon

Re: Multi-6 [WAS: OT - Vint Cerf joins Google]

[Igor Gashinsky]

:: > Well, I have no evidence of them doing anything with IPv6 anyway, so I
:: > don't know if this makes a difference.
:: 
:: I have a very strong feeling that part of the lack of content providers on
:: IPv6 is due to the lack of multihoming.
:: 
:: Whilst this thread is open... perhaps someone can explain to me how shim6 is
:: as good as multihoming in the case of redundancy when one of the links is
:: down at the time of the initial request, so before any shim-layer negotiation
:: happens.
:: 
:: I must be missing something, but there's a good chance that the requester is
:: going to have to wait for a timeout on their SYN packets before failing over
:: to another address to try.   Or is the requester supposed to send SYNs to all
:: addresses for a hostname and race them off?

Or, on top of that, how traffic engineering can be performed with shim6..

And people wonder why more "content" isn't available for v6. Maybe when 
content providers start asking for a /32 *per datacenter* (ie a /26 or so 
of initial allocation) those issues might get solved... then again, 
probably not.

-igor
(firmly in the shim6 does not adress *most* of the issues camp)

Re: 12/8 problems?

[Richard A Steenbergen]

On Sat, Sep 10, 2005 at 06:15:38AM -0700, Eric Louie wrote:
> 
> FYI, happened again this morning for (at least) 12/8 
> duration approx 30 minutes 
> starting at 5:45 AM PDT.

Notice that AT&T is no longer taking chances, and is announcing 2 /9s.

-- 
Richard A Steenbergen <[EMAIL PROTECTED]>   http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)

Re: LA power outage?

[Kevin]

I've been dealing with a data center outage due to this,
and power just came back up a few minutes ago.

Halon dumps are only fun from the outside.

Kevin Kadow

Re: Multi-6 [WAS: OT - Vint Cerf joins Google]

[John Payne]

On Sep 12, 2005, at 6:58 AM, Iljitsch van Beijnum wrote:

I'll be blunt.  As long as that question is up in the air, none of 
the major content providers are going to do anything serious in the 
IPv6 arena.


Well, I have no evidence of them doing anything with IPv6 anyway, so I 
don't know if this makes a difference.


I have a very strong feeling that part of the lack of content providers 
on IPv6 is due to the lack of multihoming.


Whilst this thread is open... perhaps someone can explain to me how 
shim6 is as good as multihoming in the case of redundancy when one of 
the links is down at the time of the initial request, so before any 
shim-layer negotiation happens.


I must be missing something, but there's a good chance that the 
requester is going to have to wait for a timeout on their SYN packets 
before failing over to another address to try.   Or is the requester 
supposed to send SYNs to all addresses for a hostname and race them 
off?

Re: LA power outage?

[ravi pina]

On Mon, Sep 12, 2005 at 01:49:13PM -0700, brett watson said at one point in 
time:
> 
> On Sep 12, 2005, at 1:32 PM, Jared Mauch wrote:
> 
> >there's also a blurb on yahoo news of an outage
> >http://news.yahoo.com/s/ap/20050912/ap_on_re_us/la_power_outage
> 
> AM radio news is reporting a "wrong cable cut" by the department of  
> water and power folks...  they're saying "no ties to terrorism"...

its been on cnn for the last 1.5h.  make it stop.

now how a single cable cut that seems to have affected
the greater LA area including for voice and data
infrastructure can have "no ties to terrorism" is amazing.

i may file this under "ignorance induced domestic terrorism."

-r

-- 
+++ATH
7MN; {{{

RE: LA power outage?

[Reeves, Rob]

We've been told by our field tech in LA that One Wilshire had lost power
for a bit, but it is now restored.  I don't know the duration of the
outage, but our equipment there is on DC and did not go down.

-Rob

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Ashe Canvar
Sent: Monday, September 12, 2005 5:08 PM
To: nanog@merit.edu
Subject: Re: LA power outage?



My equiment at 1200 W. 7th Street is unreachable. 

Can anyone confirm if one wilshire is affected ?

-ashe


On 9/12/05, brett watson <[EMAIL PROTECTED]> wrote:
> 
> 
> 
> On Sep 12, 2005, at 1:32 PM, Jared Mauch wrote:
> 
> 
> 
> there's also a blurb on yahoo news of an outage
> 
> http://news.yahoo.com/s/ap/20050912/ap_on_re_us/la_power_outage
> 
> AM radio news is reporting a "wrong cable cut" by the department of 
> water and power folks...  they're saying "no ties to terrorism"...
> 
> 
> -b

Re: LA power outage?

[Fergie (Paul Ferguson)]

CNN is reporting that power is starting to be restored to some
areas afected by the outage.

- ferg


--
"Fergie", a.k.a. Paul Ferguson
 Engineering Architecture for the Internet
 [EMAIL PROTECTED] or [EMAIL PROTECTED]
 ferg's tech blog: http://fergdawg.blogspot.com/

Re: LA power outage?

[Ashe Canvar]

My equiment at 1200 W. 7th Street is unreachable. 

Can anyone confirm if one wilshire is affected ?

-ashe


On 9/12/05, brett watson <[EMAIL PROTECTED]> wrote:
> 
> 
> 
> On Sep 12, 2005, at 1:32 PM, Jared Mauch wrote:
> 
> 
> 
> there's also a blurb on yahoo news of an outage
> 
> http://news.yahoo.com/s/ap/20050912/ap_on_re_us/la_power_outage
> 
> AM radio news is reporting a "wrong cable cut" by the department of water and 
> power folks...  they're saying "no ties to terrorism"...
> 
> 
> -b

Re: LA power outage?

[brett watson]

On Sep 12, 2005, at 1:32 PM, Jared Mauch wrote:    there's also a blurb on yahoo news of an outage http://news.yahoo.com/s/ap/20050912/ap_on_re_us/la_power_outage AM radio news is reporting a "wrong cable cut" by the department of water and power folks...  they're saying "no ties to terrorism"...-b

Re: LA power outage?

[prue]

Yep.  LA got hit with a power outage that hit downtown and the San Fernando 
valley according to reports.  Power was restored to USC campus which is about
4 miles from downtown at about 1:30 PDT, for an outage of about half an hour.

Walt

LA power outage?

[Roy Badami]

Google News is your friend

Major power outage hits Los Angeles

http://today.reuters.com/investing/financeArticle.aspx?type=bondsNews&storyID=URI:urn:newsml:reuters.com:20050912:MTFH66743_2005-09-12_20-24-41_N12366749:1

Re: LA power outage?

[Jared Mauch]

I'm seeing a number of customers that appear to have gone
down in the past hour or so, mostly from 19:05-20:25 time frame.

there's also a blurb on yahoo news of an outage
http://news.yahoo.com/s/ap/20050912/ap_on_re_us/la_power_outage

- jared

On Mon, Sep 12, 2005 at 01:28:47PM -0700, matthew zeier wrote:
> 
> 
> I'm hearing rumors of a power outage in LA - any truth?  I lost access to 
> my gear up there and the NOC phone is fast busy.
> 
> --
> matthew zeier - "Curiosity is a willing, a proud, an eager confession
> of ignorance." - Leonard Rubenstein

-- 
Jared Mauch  | pgp key available via finger from [EMAIL PROTECTED]
clue++;  | http://puck.nether.net/~jared/  My statements are only mine.

Re: LA power outage?

[matthew zeier]

Suppose so -

http://tinyurl.com/bpbz5


http://www.latimes.com/news/nationworld/nation/sns-ap-la-power-outage,0,3767081.story?coll=la-news-alert


matthew zeier wrote:



I'm hearing rumors of a power outage in LA - any truth?  I lost access 
to my gear up there and the NOC phone is fast busy.


--
matthew zeier - "Curiosity is a willing, a proud, an eager confession
of ignorance." - Leonard Rubenstein


--


--
matthew zeier - "Curiosity is a willing, a proud, an eager confession
of ignorance." - Leonard Rubenstein

LA power outage?

[matthew zeier]

I'm hearing rumors of a power outage in LA - any truth?  I lost access to my 
gear up there and the NOC phone is fast busy.


--
matthew zeier - "Curiosity is a willing, a proud, an eager confession
of ignorance." - Leonard Rubenstein

Re: DNSSEC in public

[bmanning]

> > about for doing DNSSEC in the public, using either a "root" key and/or 
> > possibly having master keys pulished in WHOIS?
> 
> there is no plan i know of involving master keys published by whois.  (that's
> sort of a chicken-or-egg approach, since you'd be using dns to figure out what
> whois server to ask.)

although that has been proposed as a method (one of several)
 
> > I guess my question is: is there even something up for discussion at this 
> > point?  I know it's early in the game.
> 
> the official plan is, every zone's zonesigning key is signed by that zone's
> keysigning key, and that zone's keysigning key is signed by its parent zone's
> zonesigning key.  thus, every zone is at the mercy of its parent zone's
> deployment schedule, and nothing is really possible until the root zone is
> signed, since that will allow the TLD's to sign, which will allow SLD's to
> sign, and so on down the tree.

not exactly true, the use of Secure Entry Points ad/or Trust Anchors
is a fine way to "boot-strap" the process...  DLV is yet another.

> this stuff works in the lab, but there are several pieces still missing:
> 1. distributing and updating the root zone's keysigning key
> 
> some say, make the key, keep the private part save, publish the
> public part on IETF T-Shirts, and let everybody hardcode it, and
> if we ever have to change it, we're completely screwed.

s/if/when/  -- which begs the question, why do it at all if we 
KNOW we are going to be screwed.


> some say, delay deployment until we have a secure way to "roll"
> new root keysigning keys out.  this is a protocol change, and will
> have to take into account embedded and rarely-connected devices.

perhaps it is not a protocol change, but that discussion occurs on 
the DNSEXT wg list.

> 2. figuring out who would be trusted to hold the root zone's keysigning key

there-in lies the path of madness... which is why SEP/TA and even
perhaps DLV makes sense.

> my own views are: (1) hardcode the root zone keysigning key, and hope
> there's an in-band key-rollover protocol ready to roll out before the first
> time we have to invalidate/replace/revoke this key; and (2) use DLV to get
> deployment started, and hope that the root zone and the most compelling TLD's
> are all signed before DLV reaches its built in crippleware scaling limit.

imho, jumping w/o a parachute...  but ymmv.

> Paul Vixie

other methods, used in the lab for key distribution include finger,
ixfr, and the usual OOB suspects (in source distribution, publication
in periodicals, via RSS feeds and a few others).
--bill

Re: DHS Cyber Security Investment Study

[Valdis . Kletnieks]

On Mon, 12 Sep 2005 13:39:56 EDT, "Rowe, Brent" said:

> clear that I are not interested in learning the makeup of your IT
> infrastructure, the IT policies and procedures your organization
> employs, the number of breaches you have each year, or any other
> sensitive information related to your organization's IT security.
> Instead, I am interested in discussing the information you use to decide
> how much to spend on various IT security-related activities and what
> information you are collecting (and using) from your IT system
> operations.

Any attempt at trying to analyze information about budget allocations
without at least some understanding of the IT policies is probably doomed
to failure.  At least in our shop, there are things we track in a very
anal-retentive fashion, and information we don't bother collecting, *because*
our policies say the first is important and the second one is ignorable.

For instance, if I told you how many hundreds of dollars we spent on perimeter
firewalls last year, you'd be totally dazed and confused unless you understood
our thinking regarding perimeter firewalls. (And yes, "hundreds" is the right
units, and yes, we know what we're doing, and no, I don't want to hear how
we're nuts. It works *in our environment, YMMV...:)



pgpuGnEF3pJDc.pgp
Description: PGP signature

Re: DNSSEC in public

[Paul Vixie]

[EMAIL PROTECTED] ("Dan Mahoney, System Admin") writes:

> In response to a recent question I saw regarding DNSSEC on RIPE domains, 
> I'd like to ask if there's any sort of draft or standard that anyone knows 
> about for doing DNSSEC in the public, using either a "root" key and/or 
> possibly having master keys pulished in WHOIS?

there is no plan i know of involving master keys published by whois.  (that's
sort of a chicken-or-egg approach, since you'd be using dns to figure out what
whois server to ask.)

there are plenty of web sites that talk about the general field of deployment,
most of which are all reachable via jacco's excellent www.dnssec.net web site.
however, your question falls outside of the things most deployment experts are
willing to talk about in public.  since i've had quite enough coffee and maybe
a little extra, i'll see what i can offer.

> I see a very experimental thing Verisign is doing for the .net zone, and 
> also for some other opt-in zone, but I'm sure that's highly experimental 
> at this point.
> 
> I guess my question is: is there even something up for discussion at this 
> point?  I know it's early in the game.

the official plan is, every zone's zonesigning key is signed by that zone's
keysigning key, and that zone's keysigning key is signed by its parent zone's
zonesigning key.  thus, every zone is at the mercy of its parent zone's
deployment schedule, and nothing is really possible until the root zone is
signed, since that will allow the TLD's to sign, which will allow SLD's to
sign, and so on down the tree.

this stuff works in the lab, but there are several pieces still missing:

1. distributing and updating the root zone's keysigning key

some say, make the key, keep the private part save, publish the
public part on IETF T-Shirts, and let everybody hardcode it, and
if we ever have to change it, we're completely screwed.

some say, delay deployment until we have a secure way to "roll"
new root keysigning keys out.  this is a protocol change, and will
have to take into account embedded and rarely-connected devices.

2. figuring out who would be trusted to hold the root zone's keysigning key

some people distrust ICANN.  others distrust US-DoC.  still others
distrust ITU, UN, and/or WSIS -- and some people distrust VeriSign.
and of course, most of those entities don't trust most of the others.

yet, those entities are largely responsible for the root zone today,
and they have to learn to increase their mutual trust as well as
their collective perceived trustworthiness, or there will be no
DNSSEC deployment at the root zone level.

one candidate-conclusion that leaps to mind is "this can't ever work".  more
charitibly, one might say that "it's not anywhere close to being deployable."

my own views are: (1) hardcode the root zone keysigning key, and hope
there's an in-band key-rollover protocol ready to roll out before the first
time we have to invalidate/replace/revoke this key; and (2) use DLV to get
deployment started, and hope that the root zone and the most compelling TLD's
are all signed before DLV reaches its built in crippleware scaling limit.

now for the disclaimers.  i work at ISC, and we've been funded to work on
DNSSEC for most of the last ten years.  our BIND9 (9.3.x and soon 9.4.x) is
as far as we know a complete implementation of the current (DNSSEC-bis) spec.
it's free software, free as in BSD-style license.  we don't make money from
your use of our software, and when we do collect money (usually from support
or software development), we're a non-profit corp with no shareholders so we
can only spend our money on public benefit activities.

oh, and one more thing: i'm the primary pusher behind DLV.  DLV is the
thing you're alluding to when you talk about the .NET experiment at
VeriSign.  DLV isn't experimental, ISC is going to run it as a full
production service as a way to get dnssec deployment to begin even though
there are a lot of things not quite ready yet.  you can learn more about DLV
at: .

i hope this helps.  and do remember to look at jacco's www.dnssec.net pages;
he (wisely) does not delve into the root zone's political problems or the DLV
controversy, but otherwise his site is a very complete and useful reference.
-- 
Paul Vixie

Re: DHS Cyber Security Investment Study

[n3td3v]

"Department of Homeland Security" Thats a Bush get out of jail card.
If New Orleans was anything to go by, "Department of Homeland
Security" has little credibility or infulence on the world stage,
accept within the U.S propaganda bubble of 24 hour news channels.

On 9/12/05, Rowe, Brent <[EMAIL PROTECTED]> wrote:
> 
> NANOG members,
> 
> I am writing to ask for your participation in a study which I am working
> on for the Department of Homeland Security on IT security investment


-- 
http://www.geocities.com/n3td3v

Re: Katrina Network Damage Report

[Valdis . Kletnieks]

On Mon, 12 Sep 2005 12:26:03 EDT, "Howard, W. Lee" said:

> Maybe I missed an intermediate post or two, but is the assertion
> here that IPv6 is more secure because it's impractical to scan such
> a large number of possible host IP addresses?  Sort of like zebra
> camouflage--it's easy to see the herd, but hard to see a single
> zebra.
> 
> There may be other ways to find a host address than random botting.
> Phishing, perhaps.

The good news here is that although there's "neighbor discovery protocols" that
let you find the other zebras on the subnet, they only work if you're already
riding a zebra in the herd.  If you're riding a giraffe or hippo, or a zebra
from another herd, you still can't see the zebras.

Now if we could just do some genetic engineering to cull this mutation
that causes zebras to spontaneously sprout big neon "Ride Me" signs.

(In other words, yes - we *will* see a shift in tactics from "random scanning"
to "find a vulnerable host on the subnet, and use it to enumerate the other
hosts".  I predict that web bugs and spam variants will be the method of choice
for finding that first host.)


pgpqLJTfk9BW2.pgp
Description: PGP signature

DHS Cyber Security Investment Study

[Rowe, Brent]

NANOG members,
 
I am writing to ask for your participation in a study which I am working
on for the Department of Homeland Security on IT security investment
decisions.  My intension is not to upset anyone with an unwanted
solicitation, so if you are uninterested in this topic, please disregard
the remainder of this email.
 

--
 
My company, RTI, has been contracted by the the Department of Homeland
Security to analyze how organizations make investment decisions related
to IT security.  As part of this project, we are gathering information
from organizations in seven different sectors, one of which is Internet
Service Providers.
 
I am interested in talking with any individuals representing ISPs about
their organizations' IT security decision making practices.  Let me be
clear that I are not interested in learning the makeup of your IT
infrastructure, the IT policies and procedures your organization
employs, the number of breaches you have each year, or any other
sensitive information related to your organization's IT security.
Instead, I am interested in discussing the information you use to decide
how much to spend on various IT security-related activities and what
information you are collecting (and using) from your IT system
operations.
 
If you are interested in participating in this study and/or have
questions related to how we plan to use the data we collect, the purpose
of the study, or the intended use of the study results, please contact
me at [EMAIL PROTECTED] or 919-485-2626.
 
Thank you any assistance you can provide.
 
Regards,
Brent



Brent Rowe
Research Economist
Technology Economics & Policy
RTI International
3040 Cornwallis Road
Research Triangle Park, NC 27709
phone: (919) 485-2626
fax: (919) 541-6683
www.rti.org

Re: MEDIA: eBay to Acquire Skype

[Mark Owen]

On 9/12/05, william(at)elan.net <[EMAIL PROTECTED]> wrote:
> 
> 
> Let me play Paul Ferguson for a second ... :
> (and I wonder if we'll soon be trading voip minutes on ebay :)
> 
> http://finance.lycos.com/home/news/story.asp?story=51709287

Link to Fergie's blog ;)
http://fergdawg.blogspot.com/2005/09/ebay-buying-skype-for-26b.html

-- 
Mark Owen

RE: Katrina Network Damage Report

[Joel Jaeggli]

On Mon, 12 Sep 2005, Howard, W. Lee wrote:


Maybe I missed an intermediate post or two, but is the assertion
here that IPv6 is more secure because it's impractical to scan such
a large number of possible host IP addresses?  Sort of like zebra
camouflage--it's easy to see the herd, but hard to see a single
zebra.


I didn't assert that it was more secure, rather that scanning as it works 
now, to collect the ip's of exploitable embedded or other devices is 
infeasible.


Miscreants will of course looks for other ways if they can't feasibly 
scan. The IETF is full of resource discovery mechanism work and there's no 
reason to expect that those selfsame mechanisms wouldn't be subverted to 
other ends. There's no point in conneccting a device to the internet if 
you can't find it or manange it.


As my firewall logs would testify though, host discovery throught probing 
is one of the low hanging fruit.



There may be other ways to find a host address than random botting.
Phishing, perhaps.

I suppose the relative security question becomes, "Which is more
secure: address translation or sparseness?"  I've heard people say
that NAT provides no security, but dynamic assignment (from the
Internet's point of view) of an address for only the duration of
a session means you can't target a specific host, and have to have
some access already to hijack a session.

I'm not saying NAT is sufficient security, but it can be part of
a good plan.  Obscurity isn't sufficient security, but I'm not
publishing my network map.

Lee






--
--
Joel Jaeggli   Unix Consulting [EMAIL PROTECTED]
GPG Key Fingerprint: 5C6E 0104 BAF0 40B0 5BD3 C38B F000 35AB B67F 56B2

MEDIA: eBay to Acquire Skype

[william(at)elan.net]

Let me play Paul Ferguson for a second ... :
(and I wonder if we'll soon be trading voip minutes on ebay :)

http://finance.lycos.com/home/news/story.asp?story=51709287

 eBay to Acquire Skype
 - Sep 12, 2005 06:00 AM (BusinessWire)

LONDON--(BUSINESS WIRE)--Sept. 12, 2005--eBay Inc.
(Nasdaq:EBAY) www.ebay.com) has agreed to acquire Luxembourg-based
Skype Technologies SA, the global Internet communications company, for
approximately $2.6 billion in up-front cash and eBay stock, plus
potential performance-based consideration. The acquisition will
strengthen eBay's global marketplace and payments platform, while
opening several new lines of business and creating significant new
monetization opportunities for the company. The deal also represents a
major opportunity for Skype to advance its leadership in Internet
voice communications and offer people worldwide new ways to
communicate in a global online era. Skype, eBay and PayPal will create
an unparalleled ecommerce and communications engine for buyers and
sellers around the world.

...

Re: OT - Vint Cerf joins Google (Please change subject to what is discussed)

[james edwards]

Re: OT - Vint Cerf joins Google

[Simon Lockhart]

On Mon Sep 12, 2005 at 05:58:15PM +0300, Joe Abley wrote:
> >Not contesting the quantification, but what typical IXP switches can
> >do stats based on ethertype?
> 
> There are a few exchanges who isolate v6 and v4 traffic on separate  
> VLANs. Stats based on VLAN are a little easier to come by.

sflow data?

Simon
-- 
Simon Lockhart | * Sun Server Colocation * ADSL * Domain Registration *
   Director|* Domain & Web Hosting * Internet Consultancy * 
  Bogons Ltd   | * http://www.bogons.net/  *  Email: [EMAIL PROTECTED]  * 

Re: OT - Vint Cerf joins Google

[Daniel Roesen]

On Mon, Sep 12, 2005 at 05:58:15PM +0300, Joe Abley wrote:
> There are a few exchanges who isolate v6 and v4 traffic on separate  
> VLANs. Stats based on VLAN are a little easier to come by.

Yeah, a few. Dying quickly. The most relevant IXPs or the IPv6 world
aren't, they run real dual-AFI in a single VLAN. So I'd say that most
of the IPv6 traffic bypasses any IXP stats, either because the IXP runs
dual-AFI in single VLAN, or that IPv6 traffic is being tunneled via
proto 41 or GRE.


Best regards,
Daniel

-- 
CLUE-RIPE -- Jabber: [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- PGP: 0xA85C8AA0

RE: DNSSEC in public

[Christopher L. Morrow]

On Mon, 12 Sep 2005, Marcus H. Sachs wrote:

>
> Dan, check out http://www.dnssec-deployment.org/
>

also Sparta has:
http://www.dnssec-tools.org/

and from some other place:
http://www.dnssec.net/  (no idea about quality on this, but it does
mention RIPE including an 'howto dnssec' :) )

Perhaps one or more of these will de-mystify the dns-sec issue? :)

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dan
> Mahoney, System Admin
> Sent: Monday, September 12, 2005 6:15 AM
> To: [EMAIL PROTECTED]
> Subject: DNSSEC in public
>
>
>
> In response to a recent question I saw regarding DNSSEC on RIPE domains,
> I'd like to ask if there's any sort of draft or standard that anyone knows
> about for doing DNSSEC in the public, using either a "root" key and/or
> possibly having master keys pulished in WHOIS?
>
> I see a very experimental thing Verisign is doing for the .net zone, and
> also for some other opt-in zone, but I'm sure that's highly experimental
> at this point.
>
> I guess my question is: is there even something up for discussion at this
> point?  I know it's early in the game.
>
> Thanks
>
> Dan
>
> --
>
> "I can feel it, comin' back again...Like a rolling thunder chasin' the
> wind..."
>
> -Dan Mahoney, JS, JB & SL, May 10th, 1997, Approx 1AM
>
> Dan Mahoney
> Techie,  Sysadmin,  WebGeek
> Gushi on efnet/undernet IRC
> ICQ: 13735144   AIM: LarpGM
> Site:  http://www.gushi.org
> ---
>

Re: OT - Vint Cerf joins Google

[Joe Abley]

On 12-Sep-2005, at 17:11, Daniel Roesen wrote:


On Mon, Sep 12, 2005 at 06:28:22PM +0700, Randy Bush wrote:


those who see full stats at ixes, v4/6 isps, etc will tell you that
actual v6 traffic is miniscule.


Not contesting the quantification, but what typical IXP switches can
do stats based on ethertype?


There are a few exchanges who isolate v6 and v4 traffic on separate  
VLANs. Stats based on VLAN are a little easier to come by.



Joe

Re: OT - Vint Cerf joins Google

[william(at)elan.net]

On Mon, 12 Sep 2005, Randy Bush wrote:


8% seems high to me as well


not by much more than O(10^1) :-).  those who see full stats at
ixes, v4/6 isps, etc will tell you that actual v6 traffic is
miniscule.


And I thought you were in Japan ...

--
William Leibzon
Elan Networks
[EMAIL PROTECTED]

Re: IPv6 traffic numbers [was: Re: OT - Vint Cerf joins Google]

[Marshall Eubanks]

On Mon, 12 Sep 2005 15:59:00 +0200
 Simon Leinen <[EMAIL PROTECTED]> wrote:
> [CC'ing Stanislav Shalunov, who does the Internet2 weekly reports.]
> 
> Marshall Eubanks writes, in response to Jordi's "8% IPv6" anecdote:
> > These estimates seem way high and need support. Here is a counter-example.
> 

Simon is correct. The numbers I quoted were for protocol 41 traffic,
and presumably more IPv6 is "hidden in plain sight" on the Internet 2
backbone. 

Sorry for the confusion.

Regards
Marshall

> While I'm also skeptical about the representativeness of Jordi's
> estimates, this is a bad counterexample (see below about why):
> 
> > Netflow on Internet 2 for last week 
> 
> > http://netflow.internet2.edu/weekly/20050829/
> 
> > has 6.299 Gigabytes being sent by IPv6, out of a total 383.2
> > Terabytes, or 0.0016% This is backbone traffic, and would not catch
> > intra-Campus traffic, nor would it catch tunnel or VPN traffic,
> ^^^^
> 
> Wrong.  What you see here is ONLY tunnel traffic, because the number
> is for IPv6-in-IPv4 (IP protocol 41) traffic.
> 
> Netflow for IPv6 isn't widely used yet.  Our own equipment doesn't
> support it, and I don't think the Junipers used in Abilene do, either
> (someone please correct me if I'm wrong).
> 
> > but it is suggestive.
> 
> Yes, but it's also irrelevant, because Abilene has native IPv6, so
> there is little incentive for sending IPv6 tunneled in IPv4.
> 
> > According to the graph
> > http://netflow.internet2.edu/weekly/longit/perc-protocols41-octets.png
> > the most I2 IPv6 traffic was in  2002, when it was almost 0.6% of the 
> > total. 
> 
> I would assume that that was before IPv6 went native on Abilene.
> 
> > It is hard for me to imagine that the situation for commerical US
> > traffic is much different.
> 
> I'm sure there's less
> > There may be similar statistics for Geant - I would be interested to
> > see them.
> 
> I'll look up the GEANT numbers in a minute, stay tuned.
> -- 
> Simon.
> 

Re: OT - Vint Cerf joins Google

[Eric Gauthier]

> > 8% seems high to me as well, I don't think I've ever seen my v6 traffic
> > over 1% honestly :( 
>
> These estimates seem way high and need support. Here is a counter-example.
> 
> Netflow on Internet 2 for last week 
> 
> http://netflow.internet2.edu/weekly/20050829/
> 
> has 6.299 Gigabytes being sent by IPv6, out of a total 383.2 Terabytes, 
> or 0.0016% 

Not that I have any knowledge or expectations one way or another, but I
think there is a bit of an apples-to-oranges comparision going on here.

The Internet2 graphs all appear to be packets/octets whereas the other
estimates were for hits to a web site, which is probably more comparible
to flow counts than packet counts.  I quickly looked and didn't see any
flow charts in I2's Netflow site, but I'd be interested to see what 
percentage of I2's flow's are v6.

Eric :)

Re: OT - Vint Cerf joins Google

[Daniel Roesen]

On Mon, Sep 12, 2005 at 06:28:22PM +0700, Randy Bush wrote:
> those who see full stats at ixes, v4/6 isps, etc will tell you that
> actual v6 traffic is miniscule.

Not contesting the quantification, but what typical IXP switches can
do stats based on ethertype? Given that most relevant IPv6 players
especially in Europe and ASPAC do run dual stack and IPv4 and IPv6
over the same interface, I fail to see how you can see the IPv6 traffic
levels. I can remember Equinix refusing to allow IPv6 on the normal
switch port because they want to see IPv6 traffic levels and need extra
port for that. Which hinders IPv6 deployment even more... extra ports do
cost real extra money for most folks. Perhaps this policy has changed
nowadays (I hope).


Best regards,
Daniel

-- 
CLUE-RIPE -- Jabber: [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- PGP: 0xA85C8AA0

IPv6 traffic numbers [was: Re: OT - Vint Cerf joins Google]

[Simon Leinen]

[CC'ing Stanislav Shalunov, who does the Internet2 weekly reports.]

Marshall Eubanks writes, in response to Jordi's "8% IPv6" anecdote:
> These estimates seem way high and need support. Here is a counter-example.

While I'm also skeptical about the representativeness of Jordi's
estimates, this is a bad counterexample (see below about why):

> Netflow on Internet 2 for last week 

> http://netflow.internet2.edu/weekly/20050829/

> has 6.299 Gigabytes being sent by IPv6, out of a total 383.2
> Terabytes, or 0.0016% This is backbone traffic, and would not catch
> intra-Campus traffic, nor would it catch tunnel or VPN traffic,
^^^^

Wrong.  What you see here is ONLY tunnel traffic, because the number
is for IPv6-in-IPv4 (IP protocol 41) traffic.

Netflow for IPv6 isn't widely used yet.  Our own equipment doesn't
support it, and I don't think the Junipers used in Abilene do, either
(someone please correct me if I'm wrong).

> but it is suggestive.

Yes, but it's also irrelevant, because Abilene has native IPv6, so
there is little incentive for sending IPv6 tunneled in IPv4.

> According to the graph
> http://netflow.internet2.edu/weekly/longit/perc-protocols41-octets.png
> the most I2 IPv6 traffic was in  2002, when it was almost 0.6% of the total. 

I would assume that that was before IPv6 went native on Abilene.

> It is hard for me to imagine that the situation for commerical US
> traffic is much different.

I'm sure there's less
> There may be similar statistics for Geant - I would be interested to
> see them.

I'll look up the GEANT numbers in a minute, stay tuned.
-- 
Simon.

RE: DNSSEC in public

[Marcus H. Sachs]

Dan, check out http://www.dnssec-deployment.org/

Marc


Marcus H. Sachs, P.E.
SRI International
1100 Wilson Blvd Suite 2800
Arlington VA  22209
www.hsarpacyber.com


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dan
Mahoney, System Admin
Sent: Monday, September 12, 2005 6:15 AM
To: [EMAIL PROTECTED]
Subject: DNSSEC in public



In response to a recent question I saw regarding DNSSEC on RIPE domains, 
I'd like to ask if there's any sort of draft or standard that anyone knows 
about for doing DNSSEC in the public, using either a "root" key and/or 
possibly having master keys pulished in WHOIS?

I see a very experimental thing Verisign is doing for the .net zone, and 
also for some other opt-in zone, but I'm sure that's highly experimental 
at this point.

I guess my question is: is there even something up for discussion at this 
point?  I know it's early in the game.

Thanks

Dan

--

"I can feel it, comin' back again...Like a rolling thunder chasin' the
wind..."

-Dan Mahoney, JS, JB & SL, May 10th, 1997, Approx 1AM

Dan Mahoney
Techie,  Sysadmin,  WebGeek
Gushi on efnet/undernet IRC
ICQ: 13735144   AIM: LarpGM
Site:  http://www.gushi.org
---

Re: OT - Vint Cerf joins Google

[Iljitsch van Beijnum]

On 12-sep-2005, at 13:28, Randy Bush wrote:


8% seems high to me as well



not by much more than O(10^1) :-).


Hm, 10^1... so it's 0.8%?

those who see full stats at ixes, v4/6 isps, etc will tell you that  
actual v6 traffic is miniscule.


Which is not very surprising. Even if 10% of all clients and servers  
were IPv6-enabled, that would only result in 1% IPv6 traffic. And  
even on hosts that support IPv6, the bandwidth hogs (p2p apps)  
generally don't support IPv6.


(FYI: about 1.8% of the DNS traffic to/from my server (excluding my  
own requests) is IPv6.)

Re: OT - Vint Cerf joins Google

[Marshall Eubanks]

On Mon, 12 Sep 2005 05:06:36 + (GMT)
 "Christopher L. Morrow" <[EMAIL PROTECTED]> wrote:
> 
> On Sun, 11 Sep 2005, JORDI PALET MARTINEZ wrote:
> 
> >
> > I recall last month in our web servers was something like 8% with IPv6
> > (average), but in my opinion most of the IPv6 traffic is peer-to-peer so not
> 
> 8% seems high to me as well, I don't think I've ever seen my v6 traffic
> over 1% honestly :( Why do you think it's mostly P2P traffic? Are there
> P2P applications that prefer v6 over v4? or only work on v6? If a host has
> v6 capabilities, in my experience, it'll use them atleast as often as v4
> when given the chance.

These estimates seem way high and need support. Here is a counter-example.

Netflow on Internet 2 for last week 

http://netflow.internet2.edu/weekly/20050829/

has 6.299 Gigabytes being sent by IPv6, out of a total 383.2 Terabytes, or 
0.0016%
This is backbone traffic, and would not catch intra-Campus traffic, nor would 
it catch
tunnel or VPN traffic, but it is suggestive.

By contrast, (IPv4) UDP is 12 % of the data sent, and (IPv4 ASM) Multicast is  
1.76%, so
IPv6 trafic is just about  10^-3 of the Multicast (before any  fan-out).

According to the graph

http://netflow.internet2.edu/weekly/longit/perc-protocols41-octets.png

the most I2 IPv6 traffic was in  2002, when it was almost 0.6% of the total. 

It is hard for me to imagine that the situation for commerical US traffic is 
much
different.

There may be similar statistics for Geant - I would be interested to see them.

Regards
Marshall Eubanks

> 
> I think the last v6 traffic study I saw still said +90% of the v6 traffic
> was still ping/traceroute :(
> 
> 
> 

Re: OT - Vint Cerf joins Google

[Randy Bush]

> 8% seems high to me as well

not by much more than O(10^1) :-).  those who see full stats at
ixes, v4/6 isps, etc will tell you that actual v6 traffic is
miniscule.

randy

Re: Multi-6 [WAS: OT - Vint Cerf joins Google]

[Iljitsch van Beijnum]

On 12-sep-2005, at 4:55, Matthew Petach wrote:


> And no, multiple IP addresses is not good enough.



What requirements do you have that are fundamentally incompatible
with using multiple addresses?



How would a default-free content provider with 1000+  peering sessions
be handled?  Would they be treated as an ISP, even though they have no
downstreams, and get PI space?


There are a few corner cases that fall through the cracks in today's  
policies. A content network like you describe would be one, a transit  
ISP with customers that all have their own addresses would be  
another: where would they get the IPv6 addresses to number their  
routers?


However, the number of such networks is so incredibly small that  
whatever happens to them is completely insignificant with regard to  
scalability. Still, we need a decent policy for these cases, and JUST  
these cases but not random people who'd also like a /32.


Or would you expect them to get prefixes from every peer they have,  
and configure several hundred IP addresses on each server?


Getting address space from a peer doesn't make much sense. But  
99.999% of all content networks have 1 or more ISPs that they can get  
address space from and then announce to any peers.


I'll be blunt.  As long as that question is up in the air, none of  
the major content providers are going to do anything serious in the  
IPv6 arena.


Well, I have no evidence of them doing anything with IPv6 anyway, so  
I don't know if this makes a difference.


The whole point of IPv6 is that we have a technology that will allow  
our networks to grow for decades to come. Importing IPv4 mistakes  
defeats the purpose.



ACLs are already enough of a hassle with one
IP address per host.


Ok, let's see... which is more important to keep the internet  
running, a routing table that fits in our routers, or acl monkeys  
that get to go home at 5?

Re: Katrina Network Damage Report

[Iljitsch van Beijnum]

On 12-sep-2005, at 2:47, [EMAIL PROTECTED] wrote:


In other words: 0wning random appliances isn't all that interesting.



Amazingly enough, the *single* biggest problem in trying to get Joe
Sixpack to secure their systems is "But I don't have anything  
they'd be

interested in..."


Security isn't an end in itself. For instance, I don't care enough  
about people using up my paper and ink to secure my print server  
against remote printing. However, I do care about my passwords,  
documents and so on.



In fact, I would much rather allow access to pretty much anything
else rather than a powerful general-purpose computer.


On the other hand, if it's got enough smarts to do an IPv6 stack  
and have

enough left over to have something interesting to say, it's probably
"powerful enough" for miscreants to think of creative and interesting
uses for it, even if it *is* just a toaster


I think I didn't make my point clear. On a general purpose computer,  
you can install new software to make it do whatever you want. Not so  
for most appliances. (Although if they have way to upgrade their  
flash or whatever that would be a way in.)

Re: Multi-6 [WAS: OT - Vint Cerf joins Google]

[Iljitsch van Beijnum]

On 11-sep-2005, at 20:59, Brandon Butterworth wrote:


So how do you know it's 4 million and not 4.1?



Could be 4.1 or even 4.2.


And therein lies the problem.


I'm assuming those working on 4byte ASs know, if it's more we'll have
to migrate again which would be silly so soon


I don't think the people working on 32-bit AS numbers are privvy to  
information that the rest of us isn't. But in any event, 32-bit AS  
numbers allow for 4 billion ASes, not 4 million.



We know that 125k works today



That's quite a bit less than current SUP720-3BXL


I haven't seen the specs for that one, so I don't know if it can hold  
500k _prefixes_ or 500k _paths_. Big difference. Also, not everyone  
is going to buy new hardware immediately.



so the storage requirements should
sort themselves out according to Moore in 7 x 1.5 years, so that
would work in 2013. Processing scales non-linearly, though.



If we need it then it will exist, if not then we won't be able to do
that and will do something else instead


That's not good engineering. It's a very bad idea to start a course  
of action without knowing whether you can finish it. Although we  
don't have as much time as we used to have, we still have SOME time  
to come up with new stuff that will make multihoming in IPv6 scale.

DNSSEC in public

[Dan Mahoney, System Admin]

In response to a recent question I saw regarding DNSSEC on RIPE domains, 
I'd like to ask if there's any sort of draft or standard that anyone knows 
about for doing DNSSEC in the public, using either a "root" key and/or 
possibly having master keys pulished in WHOIS?


I see a very experimental thing Verisign is doing for the .net zone, and 
also for some other opt-in zone, but I'm sure that's highly experimental 
at this point.


I guess my question is: is there even something up for discussion at this 
point?  I know it's early in the game.


Thanks

Dan

--

"I can feel it, comin' back again...Like a rolling thunder chasin' the
wind..."

-Dan Mahoney, JS, JB & SL, May 10th, 1997, Approx 1AM

Dan Mahoney
Techie,  Sysadmin,  WebGeek
Gushi on efnet/undernet IRC
ICQ: 13735144   AIM: LarpGM
Site:  http://www.gushi.org
---

[db-wg] DNSSEC deployment on the reverse tree. (fwd)

[william(at)elan.net]

FYI - RIPE seems to be getting ready to deploy DNSSEC on inaddr (rdns)
tree so I thought nanog folks might want to know about it too being the 
kind operational issue that we don't seem to be discussing here lately 
quite as much...


BTW - are there any plans to deploy DNSSEC for ARIN ip dns tree and if so 
when are the good people at ARIN planning to tell about it? And perhaps 
presentation about DNSSEC on ip dns tree and how it is being handled and 
what we should be ready for maybe good to have at upcoming NANOG meeting.


-- Forwarded message --
Date: Mon, 12 Sep 2005 09:39:48 +0200
From: Henk Uijterwaal <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: [db-wg] DNSSEC deployment on the reverse tree.

Dear Colleagues,

In June, Olaf Kolkman wrote:


The RIPE NCC has been involved with the development of the DNSSEC
protocol. Now that the protocol has become available, we plan to
implement DNSSEC on our domains in the reverse DNS tree. The
deployment of DNSSEC is the second and last phase of the Reverse DNS
restructuring project. [...]
We welcome your feedback on this poposal before 1 August 2005. Please
send your comments to the DNS Working Group Mailing List.


The comment period was extended to 1 September and some comments were
posted to the list.  These have all been incorporated and the new
documents are at:


You can find the proposed policy at:

http://www.ripe.net/rs/reverse/dnssec/draft-dnssec-policy.html.
  "DNSSEC Key Maintenance Procedure"

http://www.ripe.net/rs/reverse/dnssec/key-maintenance-procedure.html
  "Procedure for Requesting DNSSEC Delegations"

http://www.ripe.net/rs/reverse/dnssec/registry-procedure.html


I'm going to suggest to the chairs of the WG to do a last call on these
documents and have them published as RIPE documents.

Kind regards,

Henk


--
Henk Uijterwaal   Email: henk.uijterwaal(at)ripe.net
RIPE Network Coordination Centre  http://www.amsterdamned.org/~henk
P.O.Box 10096  Singel 258 Phone: +31.20.5354414
1001 EB Amsterdam  1016 AB Amsterdam  Fax: +31.20.5354445
The NetherlandsThe NetherlandsMobile: +31.6.55861746
--

Look here junior, don't you be so happy.
And for Heaven's sake, don't you be so sad. (Tom Verlaine)