AfNOG@Mar 30, 2009

Date: Mon, 30 Mar 2009 21:34:47 -0400
From: Hervey Allen
Subject: [afnog] Detecting and Scanning for Conficker
To: AFNOG
Message-ID: <49D17337.6090805@nsrc.org>
Content-Type: text/plain; charset=ISO-8859-1

>From various posts to various Network Operator Group lists:

NMAP now has a beta version for scanning for Conficker:

http://insecure.org/

There is a standalone tool (for Windows) packaged up by Dan Kaminsky
here:

http://www.doxpara.com/

Which he has put together from source here:

http://iv.cs.uni-bonn.de/wg/cs/applications/containing-conficker/

The Honeynet Project has information as well here:

https://www.honeynet.org/node/389

Cheers,
- Hervey


明日、猛威を振るうはずの「Conficker」についての情報シェア。
自分の身は自分で守らないとね。

APPLe@Mar 30, 2009

Date: Mon, 30 Mar 2009 00:29:33 -0700 (PDT)
From: David Goldstein
Subject: [APPLe list] domain name news - 26 March
To: APPLe Mailing List , TechNewsReview Mailing
List
Message-ID: <94443.87645.qm@web54102.mail.re2.yahoo.com>
Content-Type: text/plain; charset=utf-8


**********************************************************

Sponsored by the Singapore Internet Research Centre
Nanyang Technological University, Singapore
http://www.ntu.edu.sg/sci/sirc/

**********************************************************


Don't forget to check out http://www.auda.org.au/domain-news/ for today's edition of the complete domain news, already online!


Headlines from the latest edition of the news include:
nz: InternetNZ board resigns en masse | .TEL Domains Available to All; 100,000 Names Registered | ICANN Continues Collaborative Response to Conficker Worm | Conficker worm might originate from China | Fears of a Conficker meltdown greatly exaggerated | Google tries to break IPv6 logjam by own example


And see my website - http://technewsreview.com.au/ - for daily updates in between postings.


***************************************************

The domain name news is supported by auDA

***************************************************
～略～

**********************
GOVERNANCE
**********************
～略～

**********************
DOMAIN NAMES
**********************

**********************
- ICANN
**********************
～略～

**********************
- ccTLD & gTLD NEWS
**********************
～略～

**********************
- DNS SECURITY
**********************
～略～

**********************
- DOMAIN DISPUTES
**********************
～略～

**********************
- IPv4/IPv6
**********************
～略～

**********************
- MISCELLANEOUS
**********************
～略～

**********************
- DOMAINING & AFTERMARKET
**********************
～略～

**********************
- NON-ENGLISH NEWS
**********************
**********************
- German News
**********************
～略～

**********************
- French News
**********************
～略～

**********************
- Italian News
**********************
～略～

**********************
- Spanish News
**********************
～略～

**********************
- Portuguese News
**********************
～略～

**********************
- Dutch News
**********************
～略～

**********************
- Indonesian News
**********************
～略～

**********************
- Russian News
**********************
～略～

**********************
- Chinese News
**********************
～略～

+++++++++++++++++++++++++++++++

The domain name news is supported by auDA

For information on subscriptions to the domain name and/or general internet news please contact me. For archives of postings to the list, see http://lists.technewsreview.com.au/pipermail/technewsreview/. Also see http://technewsreview.com.au/ for recent updates.

+++++++++++++++++++++++++++++++

(c) David Goldstein 2009


---------


David Goldstein

APPLeとはAsia Pacific Policy and Legal Forumのこと。
このメーリングリストは上記のような世界各国のニュースが飛んできます。
全文引用は膨大だったのでヘッダだけ引用。
#domain name newsにJapanese Newsがないんですよね。
もうひとつ、「general internet news」というものも流れてきます。
この2つを見ていると世界のInternet業界のNewsが追えたりします。
記事が膨大で、さらにLink先まで読みに行ってるととても読みきれないですけど。
元気なときに目を通すようにしています。

AusNOG@Mar 30, 2009

from: McDonald Richards
to: ausnog@ausnog.net
date: Mon, Mar 30, 2009 at 3:07 PM
subject: Re: [AusNOG] Power outage sydney cbd


And it's made the news:

http://www.news.com.au/story/0,27574,25263822-2,00.html



-----Original Message-----
From: ausnog-bounces@lists.ausnog.net
[mailto:ausnog-bounces@lists.ausnog.net] On Behalf Of McDonald Richards
Sent: Monday, 30 March 2009 4:58 PM
To: ausnog@ausnog.net
- Hide quoted text -
Subject: Re: [AusNOG] Power outage sydney cbd

Power out to offices in George St and I saw some alarms from gear in
Castlereagh St as well.... not good.

Macca

-----


From: ausnog-bounces@lists.ausnog.net
[mailto:ausnog-bounces@lists.ausnog.net] On Behalf Of Bevan Slattery
Sent: Monday, 30 March 2009 4:56 PM
To: ausnog@ausnog.net
Subject: [AusNOG] Power outage sydney cbd

Anyone have more info. Stuck in swissotel 23rd floor no elevators.


シドニーエリアで停電。
CNNによると港のほうから煙が来てるっていうことで何かが燃えたか。消防車も出動の模様。

ARIN-ppml@Mar 30, 2009

Date: Mon, 30 Mar 2009 09:07:03 -0700 (PDT)
From: Lee Howard
Subject: [arin-ppml] clarification of Board actions Feb 2 and Mar 18,
2009
To: ppml@arin.net
Message-ID: <376189.27706.qm@web63303.mail.re1.yahoo.com>
Content-Type: text/plain; charset=utf-8



The community has requested clarification from the Board on
the series of events and motivations that led to the emergency draft proposal
2009-1: Transfer Policy.

At its February 6, 2009 meeting, the Board accepted the recommendation of the
Advisory Council, finding that the process had been followed, and adopted
policy proposal 2008-6: Emergency Transfer Policy for IPv4 Addresses. The
Board has been concerned for some time that the lack of a liberalized transfer
policy would create legal risk: that we had not provided a mechanism to improve
the efficient utilization of previously-allocated resources, and that this risk was
significant enough to jeopardize ARIN?s ability to fulfill its stewardship mission.

The sense of the Board is that a transfer policy is needed well before IANA?s
last IPv4 allocation, to allow early transfers and ease the demand for IPv4
numbers from ARIN. Allowing for the possibility that demand might increase
as IANA allocates its last IPv4 numbers, the Board believes that there is
insufficient time for another full policy cycle. The policy in 2008-6 allowed
the Board to activate it by declaring an emergency, which the Board did.
The policy had certain gaps which, in the Board?s opinion, allowed for
exploitation. As noted in the minutes of the February 6 meeting, the Board
resolved to make certain edits to the policy that had just been adopted.
These edits were out of order: according to ARIN?s Policy Development
Process, the Board of Trustees may (in emergency circumstances) suspend
a policy or propose a policy, but may not edit the Number Resource Policy
Manual directly. Therefore, at its March 18, 2009 meeting, the Board
rescinded its action editing the policy, and proposed a new policy, which is
2009-1: Transfer Policy. The minutes of that meeting will be published once
Board members have reviewed them, according to the published procedure.


The
discussion of Draft Policy 2009-1: Transfer Policy has provided
valuable
input to the Board of Trustees. The Board notes that this draft policy
includes substantial
changes to current policy, and encourages constructive
discussion of the
draft policy as written.

Lee Howard
ARIN Secretary, but speaking without Board resolution


紛糾しているARINでの議論「2009-1」に関してARIN AC/Boardが、
どのような動機で"emergency"として牽引したかの明確化する為の投稿。
それを受けて、今までの「2009-1」の議論のまとめが投稿されました。


Date: Mon, 30 Mar 2009 18:10:52 -0400
From: "Alexander, Daniel"
Subject: [arin-ppml] Summary of 2009-1 discussion so far
To:
Message-ID:
<997BC128AE961E4A8B880CD7442D94800A83EE7D@NJCHLEXCMB01.cable.comcast.com>

Content-Type: text/plain; charset="us-ascii"


Hello All,

This email is rather long but I wanted to try and summarize some of the
discussion of 2009-1 so far. My apologies if I neglected any particular
comments or if my counts might be off. I was trying to select one or two
points from each of the major issues, and I was consolidating more than
one thread. If you have not done so already, please let the AC know if
you are in favor or against this proposal, or if you have specific
suggestions as to how the wording should be changed.

Thanks,
Dan Alexander
ARIN AC


PPML Postings: As of 5pm 3/30

In Favor:

None stated


Opposed:

Leo Bicknell
Kevin Kargel
Ted Mittelstaedt
William Herrin
Seth Mattinen
Jeremy H Griffith
Jay Hennigan


Contributions:

1 Dan Alexander
7 Leo Bicknell
1 Cort Buffington (CB)
1 Dale W Carder
3 John Curran
7 Bill Darte
3 Owen DeLong (OD)
4 Michael Dillon
7 David Farmer
1 Jeremy H Griffith (JG)
5 Martin Hannigan (MH)
1 Jay Hennigan
6 William Herrin (WH)
5 Lee Howard (LH)
11 Kevin Kargel
4 Mathew Kaufman
2 Eliot Lear
4 Scott Leibrand (SL)
2 Seth Mattinen (SM)
6 Ted Mittelstaedt
3 Milton L Mueller
4 John Schnizlein
1 Michael K Smith
1 Stephen Sprunk
2 Bill Woodcock


Notable Points:

Recurring questions of clarity and procedure.
Why did the BoT use the Emergency PDP?
Where is the proper explanation in the meeting minutes?
What was the emergency?
Why was this needed?
Is 2008-6 actually accepted and just not implemented?

(OD) "The same argument could be made about laws with sunset clauses,
but, the same applies. While it is true that the community can change
things and could even repeal a sunset clause, the sunset clause creates
a default action that occurs unless the community takes action.
Additionally, repealing a policy, even
if there is strong community consensus to do so, takes time. By having
a sunset clause in place, it clearly indicates that the intent of the
community is for the policy to be temporary and short-term in nature,
and, it creates a default action of removing the policy after some
period of time, rather than requiring additional subsequent action by
the community to do so."

(LB) "In broad terms, sunset provisions can be used for two purposes:
- To reduce future workload on a body where it is expected the item
will no longer be useful at some point. Rather than having to waste
time removing old policy it automatically goes.
- To require a body to re-evaluate an item via the normal debate
process in the future because the current authors are worried
the plan is not yet perfect, and/or the situation may change."

(WH) "2008-06 intentionally sunsetted section 8.4 three years after
adoption. This was no accident: the community has long been suspicious
of processes that effectively permit the sale of IP addresses from one
party to another. We're willing to give it a chance, but if we don't
like what we see, we don't want to have to fight again to take the
policy back out... especially with the board hinting it might try
sketchy procedural maneuvers in order to overrule such an effort."

(WH) "Under normal ARIN policy, any legal entity which can justify its
request may receive number resources. Though normally companies or other
organizations, this does occasionally apply to individuals. AS 11875 for
example. 2009-1 restricts the transfer recipients to "organizations."
2008-6 retains ARIN's broader definition of eligible recipients."

(JG) "So far I have seen *NO* support for this policy. Zero.
Zip. If it goes forward anyway, it will be very clear that the ideas of
"consensus" and "community policy" are mere travesties, to be discarded
whenever the BOT finds that convenient."

(WH) "Should the board elect to promptly withdraw proposal 2009-1, let's
say by close of business Friday, it would be my pleasure to resubmit the
text of the proposal to the normal policy process and serve as the
proposal's author."

(SM) "Lack of interest in entities adopting IPv6 is not ARIN's
emergency. It's a business case issue, as in many orgs see no business
case for putting forth the effort to deploy IPv6 in their networks, not
an "emergency"."

(CB) "Emergency? I think so. But I don't think that the majority of the
networking community will choose to deal with this until it reaches
crisis state. By the time we reach crisis, the problem will be too big
to worry about pointing fingers. As usual in the US, those who were
responsible enough to deal with it before it became and emergency will
see no benefit since there will be some kind of either bailout, or
social acceptance of the crisis and the half-baked solutions that will
come with waiting until two weeks past the very last date to reasonable
address the issue."

(LH) "The sense of the Board is that a transfer policy is needed well
before IANA's last IPv4 allocation, to allow early transfers and ease
the demand for IPv4 numbers from ARIN. Allowing for the possibility
that demand might increase as IANA allocates its last IPv4 numbers, the
Board believes that there is insufficient time for another full policy
cycle. The policy in 2008-6 allowed the Board to activate it by
declaring an emergency, which the Board did. The policy had certain gaps
which, in the Board's opinion, allowed for exploitation. As noted in
the minutes of the February 6 meeting, the Board resolved to make
certain edits to the policy that had just been adopted. These edits
were out of order: according to ARIN's Policy Development Process, the
Board of Trustees may (in emergency circumstances) suspend a policy or
propose a policy, but may not edit the Number Resource Policy Manual
directly. Therefore, at its March 18, 2009 meeting, the Board rescinded
its action editing the policy, and proposed a new policy, which is
2009-1: Transfer Policy. The minutes of that meeting will be published
once Board members have reviewed them, according to the published
procedure."


Suggestions:

(MH) "Number resources are issued based on justified need to
organizations and not to individuals that represent those organizations.
Upon notification that a major negative event related to the
Corporations solvency [define these in definitions] has occurred, ARIN
will freeze all assigned provider independent "PI" address space,
ASN's, and affiliated resources deemed necessary to protect ARIN
assigned number resources and their disposition. Changes to these
resources during the negative event will be processed in a manner
consistent with ARIN policy and agreements in effect at the time of the
negative event".

(SL) "I heard a number of people express the opinion that we don't want
to set a permanent precedent allowing transfers of IPv6 (and ASN). Both
2008-2 and 2008-6 were very explicit that transfers were only being
allowed as a result of the extraordinary circumstance of IPv4
exhaustion, and that such transfers would not be allowed for any other
type of number resource. I believe it would be appropriate to restore
such a limitation to section 8.3 of 2009-1."

(WH) "The changed text in 8.2 implies that a transfer of resources will
not be permitted except as a result of a merger or acquisition. Does
this rule out any kind of transfer that was previously permitted? If so,
what?"

(WH) "The original use of the word "effecting" was correct. The
instrument(s) effecting the transfer of assets. You don't affect a
change, you effect a change. The use of the word "affecting" in 2009-1
is incorrect."

ppmlでは更に議論が進んでいます。

ARIN-PPML@Mar 30, 2009

Date: Mon, 30 Mar 2009 01:05:39 -0500
From: "David Farmer"
Subject: [arin-ppml] Draft Policy 2009-1: Is there an Emergency?
To: arin-ppml@arin.net
Message-ID: <49D01AE3.21085.B9720F6@farmer.umn.edu>
Content-Type: text/plain; charset=US-ASCII

I would like to motivate a discussion of the question "Is there
an Emergency?"

I have heard several people express the opinion that they don't
see an emergency. I would like to respectfully disagree with
that opinion.

In my opinion the crux of the emergency is IPv4 exhaustion
combined with the lack of IPv6 adoption, which means we are
going to hit the proverbial wall when it comes to functional IP
address availability. But when does this become an
emergency?

Maybe we can use a car accident as a metaphor; When does
a car accident start? When you hit the wall? When the
airbags deploy? When you fail to make the turn or hit the
breaks in time to prevent yourself from hitting the wall?

Using this metaphor, I propose; IANA free pool exhaustion is
equivalent to the car hitting the wall. The trigger set in 2009-2:
Depleted IPv4 Reserves, is the equivalent of the airbags going
off shortly after the car hits the wall. RIR and ISP free pool
exhaustion are equivalent to the passengers hitting the interior
of the car and the brain and internal organs colliding with the
skull and the rest of the body, receptively.

So when did the IPv4 car accident start, when did we hit the
point where we would inextricably hit the wall? I'm not exactly
sure, but I think most of us started realizing back in 2007 that
we were going to inextricably hit the wall. And today, to me
personally it is virtually unquestionable that will we are going to
hit the wall. We obviously haven't hit the wall just yet, but the
car is headed toward the wall to fast to stop or turn, the
accident must and will happen.

Further, it is possible we don't have as much time as we think
we do. We currently have approximately 500 Million IPv4
address in the IANA Free Pool. While current projections,
based on current usage rates, provide a little over two years to
exhaustion[1]. However, it is not difficult to imagine scenarios
where the IANA free pool could be exhausted much sooner
than that. For example, if mobile providers were to start
issuing IPv4 address to mobile hand sets it wouldn't be hard to
exhaust the IANA free pool in no time flat[2].

[1] http://www.potaroo.net/tools/ipv4/index.html

[2]
http://newsroom.parksassociates.com/article_display.cfm?articl
e_id=5128

I'm not saying that will or even should happen, but it is by no
means impossible. Further, under current policies if the mobile
industry came to the RIRs for IPv4 addresses for hand set, the
RIRs would likely have to fulfill the requests, and exhaust the
IANA free pool in short order.

Therefore, at least in reference to IPv4, I believe there is a
valid Emergency.

So, I'm interested to hear other people's opinion on if there is
an emergency.

================================================
=======
David Farmer Email:
farmer@umn.edu


ARINの2009-1「IP移転」は緊急性のあるものか否か、という問いかけ。
緊急性のあるものだよ、という意見とIPv6の導入は緊急じゃないよね、という意見が見えて
います。以前あった意見としてはIP再割り当てのポリシーがあるのに移転を緊急で決める
必要ある？などのコメントがありました。

AfNOG@Mar 30, 2009

Date: Mon, 30 Mar 2009 18:18:40 +0800
From: Mark Tinka
Subject: [afnog] Google over IPv6
To: afnog@afnog.org
Message-ID: <200903301818.41455.mtinka@globaltransit.net>
Content-Type: text/plain; charset="iso-8859-1"

In case anyone missed it:

http://www.google.com/intl/en/ipv6/

Cheers,

Mark.


NANOGで話題になったIPv6化されたGoogleの告知。
ここでも情報の伝播が見えて楽しい。

SwiNOG@Mar 30, 2009

Date: Mon, 30 Mar 2009 00:50:28 +0200
From: Tonnerre LOMBARD
Subject: Re: [swinog] SwiNOG-18 Registration Information
To: Pascal Gloor
Cc: swinog@swinog.ch
Message-ID:
<20090329225028.GE8549@jules.pas-un-geek-en-tant-que-tel.ch>
Content-Type: text/plain; charset="utf-8"

Salut, Spale,

On Thu, Mar 26, 2009 at 02:37:05PM +0100, Pascal Gloor wrote:
> As you may have noticed, our registration is waaaay overbooked.

It is overbooked up to 50% every year. Maybe the real solution to that
problem would be to look for ways to increase the capacity.

Tonnerre


SwiNOGMeetingに関して。
SwiNOGでは毎年50%ほどオーバーブックするらしい(笑)
SwiNOGでは会場の拡張が必要かも、と。
JANOGではレジストしてもこない人がいるくらいなのに。

GTER@Mar 29, 2009

Date: Sun, 29 Mar 2009 23:47:31 -0300
From: Thiago Coutinho
Subject: [GTER] DoS
To: gter@eng.registro.br
Message-ID:
<62a888170903291947hcf8356blc8dd399a0297dad5@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8

Boa tarde.

Na empresa onde trabalho temos um cliente que est? recebendo v?rias
requisi??es UDP na porta 5060 vindas do IP
213.149.105.45. N?o sei exatamente a quantidade, mas pelo tcpdump vi
que s?o algumas dezenas por segundo.
J? bloqueamos no firewall, por?m as requisi??es continuam batendo no
firewall, isso h? 2 dias.
J? entrei em contato com a Intelig e eles disseram que n?o podem
bloquear o IP no backbone, s? conseguem bloquear tudo que for
internacional ou nada.

H? alguma outra forma de resolver isso?


Agrade?o a aten??o.

--
Thiago Coutinho - http://thiago.bunghole.com.br/


ブラジルでもSIPに対するDoSが発生している模様。
この人はCERT.brに連絡すべきじゃないかな。

NANOG@Mar 29, 2009

Date: Sun, 29 Mar 2009 11:10:54 -0600
From: Ken Gilmour
Subject: Re: Fiber cut on Irish Sea
To: "Justin M. Streiner"
Cc: nanog@nanog.org
Message-ID:
<5b6f80200903291010t29630956tdd244a9daaa02350@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

2009/3/29 Justin M. Streiner :
> On Sun, 29 Mar 2009, Ken Gilmour wrote:
>
>> This has been fixed now. I will follow up directly with PE for an RFO.
>
> If it was repaired that quickly it was probably not a cut or a 'wet' failure
> but maybe something like an electronics failure in a landing station or
> something similar.
>
> jms
>


Hi Justin,

It happened at 8:00AM Irish time (which is about 2:00 AM My time) I
didn't get in to the office and notice the mail until 6 hours after it
happened (In Central America) so it took about 7 hours and 30 minutes
to fix.

PE also reported that the problem started at 8:00 AM on the 29th and
was repaired at 9:05 (no AM or PM) on the 26th (yes, three days in the
past). I don't think their timing procedure is functioning correctly.

Regards,

Ken

アイルランドの海にある海底ケーブル障害についてのメール。
IE-NOGが稼動していない今、NANOGがこのような障害情報を担うことに。
最初、海底ケーブル切断？という話だったが3日前に交換したパーツの不良で
なんらかの電気的な障害が発生した模様、というレポートで収束。

日本も海底ケーブルに囲まれていて、台湾や東南アジアでの地震、東シナ海での底引き網漁船に引っ掛けられるなど数々の障害を経験していますし、たまに話題にはなりますね。

GTER@Mar 29, 2009

Date: Sun, 29 Mar 2009 18:35:29 -0300
From: max _tor
Subject: Re: [GTER] Caching e controle P2P
To: Grupo de Trabalho de Engenharia e Operacao de Redes

Message-ID:
<20a28b1b0903291435m8b2f756qe90d1d1584bcc461@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

Ja ? um caminho!!


https://cs-svn.cs.surrey.sfu.ca/nsl/wiki/P2PCache



2009/3/26 Fabr?cio Cabral

> Ol?!
>
> Eu n?o sei se esse assunto ? off-topic (me perdoem se for). Eu gostaria
> de saber, j? que muitos aqui na lista trabalham em empresas e provedores
> de acesso ? Internet, se voc?s enxergam que exista uma demanda por
> equipamentos que sejam capazes de realizar caching e/ou controle de
> tr?fego P2P.
>
> Com rela??o ao controle, sei que existem algumas solu??es por a?,
> como l7-filter do linux ou o ipp2p, mas acontece que essas solu??es
> n?o apresentam uma boa efici?ncia, al?m do fato, que como os
> protocolos P2P mudam com certa frequ?ncia, deve haver uma
> atualiza??o no software, e portanto demanda de algum suporte.
>
> A respeito de fazer caching de P2P, s? conhe?o solu??es BEM caras,
> como a da CacheLogic ou PeerApp, com suporte apenas no exterior.
>
> Assim sendo, existe demanda por esse tipo de servi?o/produto em
> empresas de pequeno, m?dio ou grande porte?
>
> Agrade?o a aten??o de todos,
>
> --
> --fx


P2Pトラフィックをキャッシュしたり制限したりできないか、という質問に対して、
カナダのP2PCacheプロジェクトの紹介をするメール。
日本はP2Pのトラフィックは既に脅威ではないという発表があるくらいですが(その影にはWinny開発者・使用者の逮捕、暴露事件の蔓延等色々な理由があるとは思うのですが)南米地域では未だ猛威をふるっているようです。

NANOG@Mar 28, 2009

Date: Sat, 28 Mar 2009 17:13:54 +0000 (GMT)
From: tt tt
Subject: iBGP Scaling
To: nanog@nanog.org
Message-ID: <450499.97499.qm@web26702.mail.ukl.yahoo.com>
Content-Type: text/plain; charset=utf-8


Hi List,

We are looking to move our non infrastructure routes into iBGP to help with our IGP scalability (OSPF). We already run full BGP tables on our core where we connect to multiple upstream and downstream customers. Most of our aggregation and edge routers cannot hold full tables and it's certainly not possible to upgrade them. Is there any reason why we shouldn't filter iBGP routes between our core and aggregation layers (we plan to use route reflectors) or should we be look at using a private AS number per POP?

Thanks

Dave


エッジでiBGPを動かしてるとフルルートを持てない、Upgradeも不可。
IGPのスケーラビリティを上げるにはどうしたらいい？
という質問。
フルルートが30万経路に届きつつある現在、ネットワーク事業者にとって切実な問題かも。

返答として経路の集約、BGPコミュニティで頑張れ、というものが届いてきています。

denog@Mar 28, 2009

Date: Sat, 28 Mar 2009 12:54:40 +0100
From: Thomas Eichhorn
Subject: SSL-VPNs
To: denog@lists.denog.de
Message-ID: <49CE1000.6050603@te3networks.de>
Content-Type: text/plain; charset="utf-8"

Hallo alle miteinandern,

ich stehe grade an einem Punkt, wo ich ein OpenVPN-System durch was 'richtiges'
ablösen soll, und IPSEC fällt aufgrund der NAT-Probleme raus.

Daher war die Idee auf ein SSL-VPN zu gehen,
welche Systeme sind da empfehlenswert, bzw gibt es Erfahrungswerte zu?

Ich wollte mit mal näher die Sachen anschauen von:

- Juniper
- Barracuda
- SonicWall

Gibt es hier jemanden der noch was anderes im Einsatz hat, und meint ich soll mir das mal anschauen?

Als Leistungsmerkmale brauche ich quasi das was OpenVPN kann, für ca. 80 User bei nicht mehr als insgesamt 50 MBit.

Danke schonmal & Grüße vom Rhein

SSL-VPNの機器をリプレイスするんだけど、何がいいかな？　Juniper/Barracuda/SonicWall・・・
80人で50Mbps以下のTrafficなんだけど。という質問。
詳しい方、ドイツ語でどうぞ。

securityfocus-focus-linux@Mar 28, 2009

from: M. Boelen
to: focus-linux@securityfocus.com
date: Sat, Mar 28, 2009 at 2:55 AM
subject: [tool] Unix auditing, Lynis 1.2.5


A new version of Lynis is available, which includes currently over 200
tests to assist auditors and security administrators to audit their Unix
machines. The tool can be executed without a required installation and
displays the outcome of the tests on the screen. Extended information
can be found in the log file, including all the results of tests.

After many releases I want to ask to try this new version and give me
input about what you like to see when checking Unix systems for their
security strenghts and weaknesses.

More information and a download link can be found on the project page:
http://www.rootkit.nl/projects/lynis.html

Regards,

Michael Boelen
--
Original author of Rootkit Hunter and Lynis - http://www.rootkit.nl


Linux監査用Tool「Lynus」新バージョン公開のお知らせ。
こういうToolの認知度も上げていかないとね。

NANOG@Mar 27, 2009

Date: Fri, 27 Mar 2009 13:35:16 +0100
From: Peter Dambier
Subject: Re: Google Over IPV6
To: nanog@nanog.org
Message-ID: <49CCC804.7060402@peter-dambier.de>
Content-Type: text/plain; charset=ISO-8859-1

Yes I do.

I can use it but sometimes got trouble with teredo.
Retry half an hour later works :)

ipv6.google.com looks better to me than the IPv4 version does.
More comfort. It is worth the trouble with teredo.

Peter


Robert D. Scott wrote:
> http://www.google.com/intl/en/ipv6/
>
> http://www.networkworld.com/news/2009/032509-google-ipv6-easy.html
>
> Any one making use of Google IPV6?
>
> Robert D. Scott Robert@ufl.edu


IPv6でGoogleにアクセスできてる？というメールに対する返答。
たまにTeredoがトラブルけど、30分～1時間後にリトライすりゃ動く、と。
自分はhexagoやHE.NETのトンネルを使ってしまうのでTeredoについてはよくわかりません。

ARIN-PPML@Mar 27, 2009

Date: Fri, 27 Mar 2009 11:25:56 -0500
From: Leo Bicknell
Subject: [arin-ppml] How hard is it to transition to IPv6?
To: arin-ppml@arin.net
Message-ID: <20090327162556.GA57288@ussenterprise.ufp.org>
Content-Type: text/plain; charset="us-ascii"


http://www.networkworld.com/news/2009/032509-google-ipv6-easy.html

At the IETF meeting there was a panel discussion on transitioing
to IPv6, at which Google gave their perspective. I know a lot of
folks have been looking for some more concrete information on how
hard the transition will be, and here's one companies's take on it.

I would like to applaud Google for both being out front and talking
about their experiences.

--
Leo Bicknell - bicknell@ufp.org - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/


色々IPv4移転やらなにやらで揉めているところにこのような質問が。
「IPv6への移行ってどんぐらい難しいの？」
原点回帰させるかのような議論の持っていきかたです。
そのメールに対して各機器においてIPv6では実現できていない機能などを説明するメールが
返信として続々と入っています。

AfNOG@Mar 27, 2009

Date: Fri, 27 Mar 2009 00:14:28 +0100 (MET)
From: "Thomas M. Knoll"
Subject: [afnog] Traffic separation between ASes
To: afnog@afnog.org
Message-ID:

Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII

Dear Sirs,

excuse me please for bothering you with the following information, but I
thought it could be of use for you as well.

Increasing Internet traffic and the transfer of delay and loss critical
traffic may lead to congested interconnection links and dropping of the
"wrong" packets as a result.
This is particularly regrettable, if the interconnected partners both use
traffic differentiation in their networks and are cut back to best effort
interconnection (p2p or through IXPs).

I have proposed a concept for simple Inter-AS Class of Service
interconnection that allows for consistent traffic separation even across
interconnection points.

By means of this email, I would like to receive your feedback, whether the
described situation is currently seen or expected in the next months.
Furthermore, I would be interested to hear, whether there have already
been set up class of service based interconnections, which could make us
of such an automated CoS signalling concept.

Background information about the proposed and implemented concept can be
found at:
http://www3.ietf.org/proceedings/09mar/slides/idr-5.pdf
and
http://www.ripe.net/ripe/meetings/ripe-57/presentations/Knoll-Traffic_Categorisation_and_Inter-AS_Peering.pdf

Thank you in advance,
Thomas Knoll


P2PのトラフィックとUpstream/IXに向かうパケットを分けたい。どうしたらいい？というメール。
米国や日本、欧州各国では既に終わった話題のように感じられるがアフリカではまだこれから
このような問題に接することに。
技術情報が共有できるようになるといいと思うけど、考える力のないエンジニアが増えてもね・・・

LACNIC-politicas@Mar 26, 2009

Date: Thu, 26 Mar 2009 19:13:40 -0300
From: Nicolas Antoniello
Subject: Re: [LACNIC/Politicas] Transferencias de bloques IPv4 en la
region
To: Lista para discusi?n de politicas de la comunidad de LACNIC

Message-ID:

Content-Type: text/plain; charset=ISO-8859-1

Estimados,

Viendo el texto de la pol?tica:

"8.4 Emergency Transfer Policy for IPv4 Addresses

For a period of 3 years from policy implementation, authorized resource
holders served by ARIN may designate a recipient for number resources they
release to ARIN.

Number resources may only be received under RSA in the exact amount
which can be justified under ARIN resource-allocation policies."

Tal vez no estoy interpretando correctamente el texto, pero creo que de el
se desprende que quien tendr? la potestad de decidir quien es el
destinatario de los bloques liberados es justamente quien libera las
direcciones... y es eso con lo que discrepo.

Justamente en la propuesta de modificaci?n que les hac?a a la pol?tica de
transferencia propuesta aqu? se explicitaba que (en mi opini?n) debe ser el
RIR qui?n asigne los recursos liberados y nunca la entidad que los libera
(al igual que deber?a ser ARIN en este caso). De tal forma, se atender?an
las peticiones de direcciones en el orden en que se solicitan y no en el
orden que quien las libera desee, "democratizando" a?n m?s el proceso de
re-asignaci?n.

Saludos,

Nicolas.

P.D.: Desconozco tambi?n la raz?n por la cual la pol?tica fue votada en un
marco de "emergencia" por ARIN. Tal vez alguien pueda arrojar luz al
respecto.


ARIN地域でのIPv4移転に関する議論について。
LACNIC地域でも疑念が。

NANOG@Mar 26, 2009

Date: Thu, 26 Mar 2009 17:32:10 -0700
From: Charles Wyble
Subject: First steps towards v6 support by ATT?
To: "nanog@nanog.org"
Message-ID: <49CC1E8A.20608@thewybles.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

While researching at&t and ipv6 I came across
http://www.feise.com/~jfeise/blogs/index.php?blog=8 and also
http://www.corp.att.com/gov/solution/network_services/data_nw/ipv6/

Looks like they have established a tunnel in the United States perhaps?

I realize that getting native v6 support to DSL users isn't exactly a
high priority for US IPSes, but building tunnel servers that are on the
same continent as the user base is nice. :) .... of course that tunnel
might be broken.


Can anyone comment on this?


AT&T(旧SBC)のADSLユーザに対してv6トンネルを掘っていて、ネイティブIPv6のプライオリティ
はISPにとって高くない。トンネルサーバは少ない機器でたくさんユーザ収容できるからいいけど、トンネルって落ちるよね・・・という半ば独り言のようなお話。
返信では何を言いたい？と突込みが。

NLNOG@Mar 26, 2009

Date: Thu, 26 Mar 2009 19:24:20 +0100
From: Marco Hogewoning
Subject: [Nlnog] Nederlandse vertaling rfc 2119
To: nlnog@nlnog.net
Message-ID: <9718891B-F64F-4E21-9016-08E81F6630AD@marcoh.net>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes

Volgend op een dicsussie over de IMHO belachelijke eis van SIDN dat
een nameserver een A record zou moeten hebben, die nergens op
gebaseerd lijkt.

Weet iemand of er een behoorlijke vertaling is van RFC 2119 in de vorm
van een NEN norm of als die er niet is, zijn er mensen met goede
ideeen over hoe je hem zou vertalen en in welk platform eventueel
geschikt zou zijn om tot een breed geaccepteerd document te komen
zonder de public domain status te verliezen ?

Dat zou misschien een beter handvat geven in dit soort discussies,
waarbij er aan de ene kant een aandrang is om de documentatie in het
Nederands op te stellen, terwijl die gebaseerd is op internationale,
en meestal in het engels opgestelde, normen.

Iemand pointers naar leesvoer of goede ideeen ?

MarcoH

みんな、議論がSIDN標準に基づくことを前提としてるけど、その内容はRFCのどこに書いてあるんだい？というメール。
SIDNとは.nlのNIR/ccTLDのようなところ。
なにがスタンダードでなにが翻訳物なのかを見極めないと・・・ということか。

AusNOG@Mar 26, 2009

from: Greg M
to: ausnog@ausnog.net
date: Thu, Mar 26, 2009 at 3:24 PM
subject: [AusNOG] Google now peering with WAIX


Not sure if it is well known, but it seems that Google is now Peering with WAIX. (I think they have been Peering with PIPE for some time now also)

As we have a 100mbps peer with WAIX, and our Staff do a significant amount of traffic to Google (Google Maps specifically) this is awesome news for us and our external bandwidth costs. I’m sure that other smaller organisations are excited by this, and even some of the bigger ones who currently push Google traffic (such as Youtube etc) across to the country.

Greg

GoogleがWAIXに登場、Peering開始してるよ、というメール。
Googleのような巨大コンテンツ企業が各IXに足を出してくれると中小のISPは助かる。
YoutubeのTrafficのせいで上流ISPへ払う従量制課金が増えて収益悪化なんてよくある
話しなので。
あとはGmail、Googleカレンダーなんかは主要インフラになりつつあるので耐障害性の意味でも重要。

NZNOG@Mar 26, 2009

Date: Thu, 26 Mar 2009 09:55:22 +1300
From: Philip D'Ath
Subject: [nznog] Linksys + Netgear Worm
To: "nznog@list.waikato.ac.nz"
Message-ID:

Content-Type: text/plain; charset="iso-2022-jp"

Oh joy, a worm is now out that infects Linksys and NetGear DSL routers.


http://blogs.zdnet.com/BTL/?p=15197

'Psyb0t' worm infects Linksys, Netgear home routers, modems

More information has surfaced about the botnet ?psyb0t,? the first known to be capable of directly infecting home routers and cable/DSL modems.

It was first observed infecting a Netcomm NB5 modem/router in Australia.

Members of the website DroneBL, a real-time IP tracker that scans for and botnets and vulnerable machines, came to the conclusion that the ?psyb0t? (or ?Network Bluepill?) botnet was a test run to prove the technology. After the botnet?s discovery and public outing, the botnet operator swiftly shut it down, APC reports.

[Read more: Stealthy router-based botnet worm squirming]

However, the most recently discovered generation (dubbed ?version 18? in the code) targets a wide range of devices, and contains the shellcode for over 30 different Linksys models, 10 Netgear models, and 15 other models of cable and DSL modems, APC reports. It did not specify which models.

APC:

A list of 6000 usernames and 13,000 passwords were also included, to be used for brute force entry to Telnet and SSH logins which are open to the LAN and sometimes even the public WAN side of the routers. Generally, routers do not lock a user out after a number of incorrect password attempts, making brute force attacks possible.

According to DroneBL, any router that uses a MIPS processor and runs the Linux Mipsel operating system (a simple operating system for MIPS Processors) is vulnerable if they have the router administration interface, or sshd/telnetd in a DMZ, with weak username/passwords. DroneBL noted this includes devices flashed with the open-source firmwares openwrt and dd-wrt, and the group also said that other routers may be vulnerable, as it had observed the bot running on routers based on the Vxworks operating system.

Clearly, exploiting a home network ? which are growing in popularity ? has its benefits: they rarely power down, and a router attack enables hackers to exploit a network with greater levels of stealth, since there?s no affect on individual PCs on the network, APC writes.

In fact, the staff of DroneBL wrote that the exploit is very difficult to detect, and the only way to discover it is to monitor traffic going in and out of the router itself ?beyond the reach of desktop computer software.

In the past, exploits on professional-grade Cisco routers were easier to detect, as Cisco provides dedicated ports for connecting to the router, monitoring internal performance and configuring them. However, the vast majority of home routers sacrifice these features for the sake of cost savings.

DroneBL says that the botnet is capable of scanning for vulnerable PHPMyAdmin and MySQL installations, and can also disable access to the control interfaces of a router, (meaning a factory reset is necessary to clear the worm).

DroneBL was successful in shutting down the Command & Control channel that the botnet utilized, and the DNS that was hosted with afraid.org was also nullrouted. The Command & Control channel is now defunct, but at the height of its penetration, the botnet was suspected to control 100,000 hosts.

Worse, the author of the botnet claimed to have infected 80,000 routers at one point while chatting anonymously on an IRC channel.

WHAT DEVICES ARE AFFECTED

According to Drone BL:

We don?t know. There are so many devices out there that we could not possibly know.

Your best bet would be to take action to upgrade the device firmware and secure any passwords if there is concern that the device may be vulnerable. Such actions will help to avoid exploitation by the worm.

WHAT TO DO

According to DroneBL:

Ports 22, 23 and 80 are blocked as part of the infection process (but NOT as part of the rootkit itself, running the rootkit itself will not alter your iptables configuration).

If these ports are blocked, you should perform a hard reset on your device, change the administrative passwords, and update to the latest firmware. These steps will remove the rootkit and ensure that your device is not reinfected.


リンクシスやネットギアのADSLルータにWorm(増殖型のコンピュータウィルス)が報告されたという話。
SSL/Telnet/HTTPのポートがブロックされてたら感染の恐れがあるのでハードリセットしてね。パスワードも変えてね、とのこと。
ホームルータはなにかない限りいじらないので忘れがち・・・

日本版Slashdotでも記事「mipsel搭載ルータやモデムを狙い、ボットネット形成するワーム」になりましたね。

IETF-Digest@Mar 26, 2009

Date: Thu, 26 Mar 2009 19:28:54 +0900
From: Jun Murai
Subject: First Itojun Service Award
To: "ietf@ietf. org"
Message-ID:

Content-Type: text/plain; charset=ISO-8859-1

Dear Colleagues,

On behalf of the Itojun Service Award selection committee, I am
pleased to announce that in the next few weeks we will begin accepting
nominations for the first award to be presented this fall at IETF 76
in Hiroshima, Japan.

The Itojun Service Award, launched in 2008 to provide recognition and
support for individuals progressing IPv6, honours the memory of Dr.
Jun-ichiro "Itojun" Hagino, who passed away in 2007, aged just 37. The
award, established by the friends of Itojun and administered by the
Internet Society, recognises and commemorates the extraordinary
dedication exercised by Itojun over the course of IPv6 development.

Memorial donations to the Itojun Service Award Fund are welcomed. The
Internet Society has established an account for donations. The WIDE
project has also established a Japanese bank account to collect
donations in Japanese Yen.

Additional information about the Itojun Service Award, and links to
information about donations, are available at:

http://www.isoc.org/awards/itojun/

We look forward to sharing additional specific information about the
Itojun award soon.

Applications / Nominations for this year's award will be opened in a few
weeks. We will announce how and when, and information and aform will be
on the above web site.



Sincerely,
Jun Murai
Itojun Service Award selection committee


IETF76広島で授与される予定の第一回Itojun Service Awardのノミネート受付開始のお知らせ。
Itojunさんの名前がBSDのコードの中だけでなく、こうして残るのは非常に嬉しい。
#Itojunさんは世の中がIPv6になることの方が喜ぶかもしれないけれど。

NANOG@Mar 26, 2009

Date: Thu, 26 Mar 2009 14:05:17 +0000
From: Alexander Harrowell
Subject: Re: Netflix, Blockbuster, and streaming content ... what
impact?
To: Joe Greco
Cc: nanog@nanog.org
Message-ID:

Content-Type: text/plain; charset=ISO-8859-1

The UK has already had this experience in early 2008 when the BBC began
making huge amounts of TV content available through its iPlayer project. The
impact on the DSL ISP industry was..not pretty. Our company did quite a bit
of analysis on the results:
http://www.telco2.net/blog/2008/02/bbcs_iplayer_nukes_all_you_can.html
http://www.telco2.net/blog/2008/04/bbc_its_paymasters_cutting_the.html
http://www.telco2.net/blog/2008/06/no_video_really_has_killed_the.html
http://www.telco2.net/blog/2008/07/online_video_scoreboard_youtub.html
http://www.telco2.net/blog/2008/08/bbc_iplayer_bandwidth_wars.html

Essentially, if you're dependent on bitstream or on monopoly/near monopoly
backhaul, you're in for an interesting few years. Answers: encourage peering
with content providers, push CDNs as far into the network as possible, look
at using set-top boxes creatively (local caching, integrated delivery with
satellite/broadcast/cable).


On Thu, Mar 26, 2009 at 1:48 PM, Joe Greco wrote:

> I've been seeing a flurry of new streaming service offerings, proposed or
> actual, such as Netflix, where it appears that they may be shooting to
> eventually ditch the mailed-DVD approach and just do broadband delivery of
> content. Might be a ways off, but they're doing the streaming now.
>
> http://www.bloomberg.com/apps/news?pid=email_en&refer=&sid=a1zxwiC6ELnA
>
> So we're potentially talking 4Mbps streamed at a customer for 2 hours at
> a shot, 500KB/s, 3.6GB of data.
>
> I know I've mentioned this several times in the past as a "coming
> challenge," and various parties, including many of our Australian
> networking friends, have expressed skepticism (and implemented
> quotas, etc). Yet it seems ever more certain that we're going to be
> seeing an explosion of video over the Internet, and sooner or later
> our rural areas, and all of the Australians ( :-) ), won't want to
> feel like left-out, second-rate Internet users.
>
> I see the current situation as being a gateway of sorts. Clearly,
> there are fortunes to be made and fortunes to be lost on this sort
> of thing, and I suspect that if some company is successful at this
> sort of streaming, we'll suddenly see a lot more business plans
> that involve Internet video delivery.
>
> This would seem to present some challenges to networks today, and
> probably more in the future. This would seem to be a pivotal time of
> sorts, are our networks planning to meet this challenge by providing
> the capacity, or are we going to degrade or limit service, or ... ???
> What are networks doing today about these issues?
>
> ... JG
> --
> Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
> "We call it the 'one bite at the apple' rule. Give me one chance [and] then
> I
> won't contact you again." - Direct Marketing Ass'n position on e-mail
> spam(CNN)
> With 24 million small businesses in the US alone, that's way too many
> apples.


Netflixという会社が新しくストリーミングサービスを行うがそれに対するインパクトは？というメールに対する返答。
英国では2008年からBBCがiPlayerというサービスを実施してTVのコンテンツをInternetに配信している。それのレポートの紹介。
iPlayerは英国外からは見られないしようになっていたので概略しか知りませんが、
どこかで紹介されたのを見た覚えがあります。

cisco-nsp@Mar 26, 2009

Date: Thu, 26 Mar 2009 10:10:17 -0700
From: Inca
Subject: [c-nsp] Free/low-cost traffic generator?
To: cisco-nsp@puck.nether.net
Message-ID:

Content-Type: text/plain; charset=ISO-8859-1

Does anyone know of a free (open source or otherwise) or low cost
traffic generator that we can use to stress test multiple gigabit
links simultaneously? Ideally, it would be a software package that one
can install on *nix/OSX/Windows.

Thanks!

いつもはCisco社製品に関する内容や相互接続性に関するような内容を議論する
メーリングリストなのですが、たまにこういう一般的な質問も出てきます。

回答としてNetperf,iperf,d-itgなどのTool紹介がありました。

ARIN-ppml@Mar 26, 2009

Date: Thu, 26 Mar 2009 10:13:18 -0500
From: "Kevin Kargel"
Subject: Re: [arin-ppml] Draft Policy 2009-1: Transfer Policy (Using
theEmergency PDP)
To: "PPML ppml"
Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106601B4AF23@mail>
Content-Type: text/plain; charset="us-ascii"


> -----Original Message-----
> From: arin-ppml-bounces@arin.net [mailto:arin-ppml-bounces@arin.net] On
> Behalf Of John Curran
> Sent: Wednesday, March 25, 2009 6:16 PM
> To: arin-ppml@arin.net
> Subject: Re: [arin-ppml] Draft Policy 2009-1: Transfer Policy (Using
> theEmergency PDP)
>
> All -
>
> As noted in Daniel's message, the material change made to the
> transfer policy by the ARIN Board is removal of the 3 year
> sunset clause. It was the consensus of the Board that this did
> not materially improve the usefulness of the 2008-6, created
> uncertainty for the community, and most importantly represented
> a dangerous precedent of time-based expirations of policy clauses.
>
> At present, the Board has one tool at its disposal for timely
> modification of policy language, and that is use of the emergency
> policy process. The Board has already indicated the urgent need
> for a transfer policy and due to the timeliness of the situation,

What urgent need for a transfer policy? Why does this keep getting restated
as though it is established fact. I have not seen a community consensus
that there is a need for a transfer policy. There are a few vocal
individuals that voice the need for a transfer policy until some accept it
as fact.

There is no need for a transfer policy. We have a policy for reassignment
of IP blocks. We do not need a new policy unless the goal is to make profit
from the transfer.

Kevin


既にIPv4再アサイン規定があるのに急いでIP移転ポリシーを決めるのはどうして？
というコメント。
どうもARIN ACは急いで決めたがっているように(外野からは)見受けられる。
さらに。


Date: Thu, 26 Mar 2009 11:12:08 -0700 (PDT)
From: Lee Howard
Subject: Re: [arin-ppml] Draft Policy 2009-1: Transfer Policy (Using
the Emergency PDP)
To: Leo Bicknell , arin-ppml@arin.net
Message-ID: <829182.10675.qm@web63307.mail.re1.yahoo.com>
Content-Type: text/plain; charset=us-ascii



As a Board member, I have some insight into the process by which the
emergency draft policy was submitted to the community. However, I am
not willing to discuss the Board's deliberations without checking with my
fellow Board members; I'm afraid of mischaracterizing their positions. I
do have my own opinions, which I will share, but I have an open mind,
and it can be changed by well-reasoned argument or correction of my
faulty memory.

The Board tries to stay out of policy matters, having created the Advisory
Council for that purpose. Generally I am reluctant to advocate for or
against potential policies. In this case, there's a policy gap, where
numbers could be better allocated as needed, per ARIN's mission.


ARIN Boardからも強烈な懸念が。

NANOG@Mar 26, 2009

Date: Thu, 26 Mar 2009 00:39:25 -0400
From: Rodrick Brown
Subject: OnLive -- Very disruptive internet technology to change
things as we know it?
To: NANOG
Message-ID:

Content-Type: text/plain; charset=windows-1252

Not sure if anyone has followed the recent announcement of OnLive and
their new gaming service which will basically allow them to stream
video game gameplay output realtime to any commodity PC over a
broadband network.

Currnet ISP pricing models are not not how many backbone providers
today can handle thousands of users simultaneously watch continuous
streaming video at 5Mb/s ?
If this thing takes off it seem tiered pricing for internet usage
might not be as far off as one may think?

OnLive is launching the world?s highest performance Games On Demand
service, instantly delivering the latest high-end titles over home
broadband Internet to the TV and entry-level PCs and Macs.

More overview here:
http://www.engadget.com/2009/03/24/onlive-killed-the-game-console-star/
http://www.rockpapershotgun.com/2009/03/24/onlive-the-end-of-seperate-games-platforms/


Engadgetなどで話題になったOnLiveというゲームサービスについての疑義について。
まだ発表だけで実物を見ていないので・・・
どうなることやら。

IP-USERS@Mar 26, 2009

from: Izumi Okutani
to: ip-users@nic.ad.jp
date: Thu, Mar 26, 2009 at 4:27 PM
subject: (JPNIC-IP-USERS 1694) Re: [Fwd: [sig-policy] Report onAPNIC27PolicySIG decisions]


奥谷です。

移転提案ですが、議論がまた違った方向に流れつつあり

「(提案そのものを反対するものではないが)現時点で移転提案を施行するべき
ではない」

という中国のNICであるCNNICの方から意見が出ています。

主な理由としては「APNIC在庫が移転によって消費されない防止策がない状態な
のでこの対策が明確になってから施行するべき」ということのようです。

一方、主な反論としては

懸念はいろいろあるかもしれないけれど懸念が晴れるまでなにもしないのでは
なく、だからこそ早い段階で施行したうえで実情に合わせた対策をとっていく
ことが重要

という意見が複数の人からいろいろな言い方で述べられています。

議論は今のところ一段落していますが、APNIC在庫消費への防止策のない状態で
移転提案が通っては困る/CNNICの主張には賛成できないのでAPNICのMLで表明し
たいなどのご意見があればお聞かせください。

今のところ単純に数からみるとCNNICの主張への反対派が優勢です。
(CNNIC以外はまずは施行を進めることを支持)

# 遅ればせながら、072の意図については私も山西さんと同じ理解です



APNICのSIG-PolicyメーリングリストでCNNICの人が独り敢然と戦っている姿を
載せたかったのですが、メール1通1通全レスしていてうまく纏まらないので
断念してました。IP-USERSでこの状態の報告があったのでここで載せます。

CNNICのTerence vs IANAのLeo、APNICのGeoff、CiscoのPhilip達が総出で議論を
戦わせています。ARIN-ppmlではよく見かける光景ですが、APNICのメーリングリストではこんな激戦はほとんど見ない気がします。貴重な光景。

RIPE-db-wg@Mar 25, 2009

Date: Wed, 25 Mar 2009 13:41:07 +0100
From: Denis Walker
To: Database WG , ncc-services-wg@ripe.net
Subject: [db-wg] ASplain deployment

[Apologies for duplicates]


Dear Colleagues,

The RIPE NCC has now successfully completed the implementation of
ASPLAIN format in the RIPE Database. If you are the maintainer of
any routing data in the RIPE Database that is associated with 32-bit
Autonomous System (AS) Numbers, please check your data to be sure
that it was correctly converted.

From this point, any AS Numbers or references must be in the ASPLAIN
format. The ASDOT format will no longer be accepted in RIPE NCC
services such as the LIR Portal and the RIPE Database.

Please note that the Routing Information Service (RIS) RIS has not been
converted to ASPLAIN at this point. Some RIS tools may accept ASPLAIN
input, however this is not yet officially supported.

If you use AS Numbers internally, or with other tools that have not yet
been updated, you may be interested in a conversion tool that has been
provided by APNIC. This tool converts ASDOT format AS Numbers to ASPLAIN
and back. It can be downloaded from:
http://www.apnic.net/cgi-bin/convert-asn.pl

If you have any concerns about this matter, please send an email to


Kind regards,

Denis Walker
Business Analyst
Database Department
RIPE NCC


RIPEのデータベースがASPLAINに対応しました、というご報告。
ただしRISはASDOTのままですよ、という注付き。
時代はASPLAINへ。

RIPE-list@Mar 25, 2009

From: Paul Rendek
To: ripe-list@ripe.net, cooperation-wg@ripe.net
Subject: Report of the RIPE Enhanced Cooperation Task Force Published
Date: Wed, 25 Mar 2009 16:19:21 +0100

[Apologies for duplicates]


Dear Colleagues,

We are pleased to announce the publication of ripe-464, "Report of the
RIPE Enhanced Cooperation Task Force".

This document is now available in the RIPE Document Store at:
http://www.ripe.net/ripe/docs/ripe-464.html


Regards,

Paul Rendek
Head of External Relations and Communications
RIPE NCC


RIPE Enhanced Cooperation Task Force報告書発行のお知らせ
RIPEは割りとフットワーク軽く色々なタスクフォースやワーキンググループが作られ、
アクティブに引っ張る人も多数いるので色々なことがパキパキ決まる印象がある。
地形の入り組んだ欧州ならではの交渉術かな、と思う。

securityfocus-security-basics@Mar 25, 2009

from: Eduardo Cavalcanti
to: security-basics@securityfocus.com
date: Wed, Mar 25, 2009 at 4:02 AM
subject: Log Management


Hello.
I'm looking for a Log Management solution appliance.
Do you have any recomendations???

We're having a log management difficult in our enterprise.
We want one appliance to solve this log management problem.
Our stuff is not working very well with the free software solutions.

Grateful.
Eduardo.


アプライアンスでのLogマネージメントでいいのない？という質問。
RSA envision, ARCSight, MARS, Splunk, SIEM log rhythm, TriGeo, Tenable New, ISS, NetIQ's Security Manager, GFI Events Manager, OSSIM, Juniper STRMなどの情報が寄せられています。
質問者はOSSIMを選択した模様。

AusNOG@Mar 25, 2009

from: Richard Billington
to: Daniel
cc: AusNOG@lists.ausnog.net
date: Wed, Mar 25, 2009 at 4:03 PM
subject: Re: [AusNOG] GEO IP databases


I have also always used Maxmind GeoIP (one of the types available).

> Maxmind GeoIP is the one I've always seen used around the place. -
> http://sourceforge.net/projects/geoip/

But today I ran across this site (thanks to Daniel at AusCERT):

http://blogama.org/node/58

which provides a mysql (or web API) to the Maxmind free GeoIP database.

Regards,
Richard

元メールは地域とIPの対応データベースの情報を求めるもの。
それに対するリプライ。
オープンソースのものや、それをMySQLフォーマットにしたもの等の情報が寄せられている。

こういう情報はみんな欲しがる。地域IXで折り返すには必須な情報。

SwiNOG@Mar 25, 2009

Date: Wed, 25 Mar 2009 08:51:37 +0100
From: "Tissieres, Jerome"
Subject: [swinog] Network Latency Calculator
To:
Message-ID:

Content-Type: text/plain; charset="us-ascii"

Hi everybody,

This could help some of us to explain latency to customers.

http://www.netqos.com/resourceroom/calculator/index.html

There's other nice tools on the same web site.

Cheers,
Jerome


ネットワークレイテンシの計算Webリリースのお知らせ。
SwiNOGはこういうツールのお知らせがあって面白い。

Multipost@Mar 25, 2009

Nordnog
Cisco Security Advisory: Cisco IOS cTCP Denial of Service Vulnerability
Cisco Security Advisory: Cisco IOS Software Multiple Features IP Sockets Vulnerability
Cisco Security Advisory: Cisco IOS Software Secure Copy Privilege Escalation Vulnerability
Cisco Security Advisory: Cisco IOS Software Mobile IP and Mobile IPv6 Vulnerabilities
Cisco Security Advisory: Cisco IOS Software Session Initiation Protocol Denial of Service Vulnerability
Cisco Security Advisory: Cisco IOS Software Multiple Features Crafted TCP Sequence Vulnerability
Cisco Security Advisory: Cisco IOS Software Multiple Features Crafted UDP Packet Vulnerability
Cisco Security Advisory: Cisco IOS Software WebVPN and SSLVPN Vulnerabilities

JANOG
[janog:08829] Cisco Security Advisory: Cisco IOS cTCP Denial of Service Vulnerability
[janog:08830] Cisco Security Advisory: Cisco IOS Software Mobile IP and Mobile IPv6 Vulnerabilities
[janog:08831] Cisco Security Advisory: Cisco IOS Software Multiple Features IP Sockets Vulnerability

cisco-nsp
Cisco Security Advisory: Cisco IOS Software Mobile IP and Mobile IPv6 Vulnerabilities(Cisco Systems Product Security Incident Response Team)
Cisco Security Advisory: Cisco IOS cTCP Denial of Service Vulnerability(Cisco Systems Product Security Incident Response Team)
Cisco Security Advisory: Cisco IOS Software WebVPN and SSLVPN Vulnerabilities(Cisco Systems Product Security Incident Response Team)
Cisco Security Advisory: Cisco IOS Software Secure Copy Privilege Escalation Vulnerability(Cisco Systems Product Security Incident Response Team)
Cisco Security Advisory: Cisco IOS Software Multiple Features IP Sockets Vulnerability(Cisco Systems Product Security Incident Response Team)
Cisco Security Advisory: Cisco IOS Software Session Initiation Protocol Denial of Service Vulnerability(Cisco Systems Product Security Incident Response Team)
Cisco Security Advisory: Cisco IOS Software Multiple Features Crafted TCP Sequence Vulnerability(Cisco Systems Product Security Incident Response Team)
Cisco Security Advisory: Cisco IOS Software Multiple Features Crafted UDP Packet Vulnerability(Cisco Systems Product Security Incident Response Team)

SANOG
[SANOG] Cisco Security Advisory: Cisco IOS Software Secure Copy Privilege Escalation Vulnerability
[SANOG] Cisco Security Advisory: Cisco IOS Software Multiple Features Crafted TCP Sequence Vulnerability
[SANOG] Cisco Security Advisory: Cisco IOS Software Session Initiation Protocol Denial of Service Vulnerability
[SANOG] Cisco Security Advisory: Cisco IOS Software Multiple Features Crafted UDP Packet Vulnerability
[SANOG] Cisco Security Advisory: Cisco IOS Software WebVPN and SSLVPN Vulnerabilities

APOPS
Cisco Security Advisory: Cisco IOS Software Multiple Features Crafted TCP Sequence Vulnerability(Cisco Systems Product Security Incident Response Team)
Cisco Security Advisory: Cisco IOS Software Multiple Features IP Sockets Vulnerability(Cisco Systems Product Security Incident Response Team)
Cisco Security Advisory: Cisco IOS Software Session Initiation Protocol Denial of Service Vulnerability(Cisco Systems Product Security Incident Response Team)
Cisco Security Advisory: Cisco IOS Software Multiple Features Crafted UDP Packet Vulnerability(Cisco Systems Product Security Incident Response Team)
Cisco Security Advisory: Cisco IOS Software Mobile IP and Mobile IPv6 Vulnerabilities(Cisco Systems Product Security Incident Response Team)
Cisco Security Advisory: Cisco IOS cTCP Denial of Service Vulnerability (Cisco Systems Product Security Incident Response Team)
Cisco Security Advisory: Cisco IOS Software WebVPN and SSLVPN Vulnerabilities(Cisco Systems Product Security Incident Response Team)
Cisco Security Advisory: Cisco IOS Software Secure Copy Privilege Escalation Vulnerability(Cisco Systems Product Security Incident Response Team)

NANOG
Cisco Security Advisory: Cisco IOS cTCP Denial of Service Vulnerability (Cisco Systems Product Security Incident Response Team)
Cisco Security Advisory: Cisco IOS Software Mobile IP and Mobile IPv6 Vulnerabilities(Cisco Systems Product Security Incident Response Team)
Cisco Security Advisory: Cisco IOS Software Secure Copy Privilege Escalation Vulnerability(Cisco Systems Product Security Incident Response Team)
Cisco Security Advisory: Cisco IOS Software Multiple Features Crafted TCP Sequence Vulnerability(Cisco Systems Product Security Incident Response Team)
Cisco Security Advisory: Cisco IOS Software WebVPN and SSLVPN Vulnerabilities(Cisco Systems Product Security Incident Response Team)
Cisco Security Advisory: Cisco IOS Software Multiple Features IP Sockets Vulnerability(Cisco Systems Product Security Incident Response Team)
Cisco Security Advisory: Cisco IOS Software Session Initiation Protocol Denial of Service Vulnerability(Cisco Systems Product Security Incident Response Team)
Cisco Security Advisory: Cisco IOS Software Multiple Features Crafted UDP Packet Vulnerability(Cisco Systems Product Security Incident Response Team)

CiscoSystems-PSIRTから出たセキュリティアドバイザリの案内が各MLに流れた。
cisco-nspは当然のこととして、NANOG,Nordnog,apopsは8件全て情報が流れた。
しかし、SANOGは5件、JANOGは3件（取りこぼしであればご容赦）。

各地域のネットワーク機器の状況を全てPSIRTのメンバーが知っているはずがないので脆弱性を選んで各MLに投げているとは思えない。
なんでこんな違いになるのだろう？

確認した限り、AusNOG, NZNOG, GTER等には流れていませんでした。これからかな？

Gore/ESNOG@Mar 24, 2009

Date: Tue, 24 Mar 2009 14:20:24 -0700
From: Joao Damas
Subject: [Gore] versions de sw de routers con soporte ASN 32bit
To: grupo de operadores de red en españa
Message-ID: <68BE6BFE-116D-4D24-B7B6-DBC88ECBCB2C@isc.org>
Content-Type: text/plain; charset=US-ASCII; format=flowed

http://as4.cluepon.net/index.php/Software_Support

Joao

前日、LACNOGに流れた4ByteASを扱えるルータOSのバージョンを纏めたPageの告知。
こういう情報の伝播を見られるのは面白い。

SwiNOG@Mar 24, 2009

Date: Tue, 24 Mar 2009 10:40:27 +0100
From: Olivier Mueller
Subject: [swinog] F5 Big-IP or ServerIron housing in .ch ?
To: swinog@swinog.ch
Message-ID: <1237887627.5265.25.camel@ompc.insign.local>
Content-Type: text/plain

Good morning,

Is there such thing as F5 Big-IP (or ServerIron, etc.) "Shared-Housing"
available around in Switzerland?

It would be for a small and simple HA/LB setup (2-3 L/FAMP Servers), and
we can't (yet) afford the costs of getting a F5 Big-Ip (or two) :-)

The other option would be to get the Load-Balancing-work done "by hand"
with a custom-pound/carp/heartbeat & co. solution from a housing/hosting
company (for example nine.ch), but I first need to check all options.

So if you have something like this in your catalog, please tell me or
feel free to forward my mail address to your "sales" people.

Thanks & regards,
Olivier


サーバロードバランサのシェアードハウジングサービス無いかな？という投稿。
確かにBig-IPもServerIronもちょっとしたサービスに使うには高い。
かといってIPVSで組むのも不安・スキル不足となると手が無い。
eBayで探すとか・・・？

ARIN-ppml@Mar 24, 2009

Date: Tue, 24 Mar 2009 12:46:05 -0600
From: Matthew Wilder
Subject: Re: [arin-ppml] Draft Policy 2009-2: Depleted IPv4 reserves
To: Ron Cleven , ARIN PPML
Message-ID:

Content-Type: text/plain; charset="us-ascii"


Ron wrote:
> Stephen's comments are spot on. The large ISP's are the very ones who
> have both the resources and clout to make the IPv6 transition happen.
> If they are unwilling or unable to do so, what does that say about the
> viability of ever making that transition? Mr. Wilder doth protest too
> much.

My explicit role in my organization is to ensure adequate IP Addressing to support service growth and new service introduction. I believe without a doubt that the only way I will be successful in that mandate is to position IPv6 as the vehicle so that the IP Addresses are there.

My organization is taking the steps necessary to get that transition happening, so we are not unwilling. I can tell you that with certain services, we might well be unable to transition before IPv4 exhaust hits, but my focus is to transition the high growth services. I want to make sure that the other services which may take longer to transition have the IP Addresses available, as I am sure every other admin POC out there is trying to ensure.

I don't protest for the sake of demanding unfair privileges on the behalf of large ISPs. I protest a policy that says everyone can have their needs completely met except for one group, which can't even have a reasonable fraction of their need met.

Respectfully,
Matthew Wilder

ARIN地域でもIP移転の議論は喧々諤々。
この地域はInternetに初期から参加している企業が多く、そういう企業は
IPv4アドレスを巨大ブロックで保有していることが多い。それゆえ、IPv4枯渇にも
関心が薄かった。
今になって猛烈な勢いで議論している。それはやはり豊富に持っているIPv4を資産化
する為なのか、と邪推してしまう。
あとはスタートアップ企業の設立コストの上昇にも跳ね返るか。

NANOG@Mar 23, 2009

Date: Mon, 23 Mar 2009 07:40:38 +0000
From: Andy Davidson
Subject: Re: AS path weirdness
To: Jason Lewis
Cc: NANOG list
Message-ID: <1CDE960B-63CD-4D42-8C42-1C6BC475C371@nosignal.org>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes


On 21 Mar 2009, at 02:48, Jason Lewis wrote:

> I'm not entirely sure what I'm looking at. The reserved AS, 65490
> appears in parentheses and I've never seen that in MRT formatted
> data and not sure why it's happening.

This has been observed when a vendor runs 32-bit AS aware code on part
of their edge, and non-32-bit AS aware code on a different part of
their edge.

> I'm also not clear on why I see 23456 *and* a 32 bit AS in the
> path. Is anyone else seeing this or is it something wacky at RRC04?
> 91.207.218.0/23|29222 6830 (65490) 3356 35320 3.21 23456

There's some history with this prefix.

http://www.andyd.net/media/talks/asn4_breaks_network.pdf [from nanog45]

Andy


4バイトAS(32bitAS)について各所で既に説明されたことに関する質問と回答。
回答側も度重なるとだんだんスマートになってくる。

LACNOG@Mar 23, 2009

Date: Mon, 23 Mar 2009 14:26:35 -0700
From: Roque Gagliano
Subject: [lacnog] I am up to day for 32 bits ASNs? / ?Estoy
actualizado para ASNs de 32 bits?
To: Latin America and Caribbean Region Network Operators Group

Message-ID:
Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dear friends,

The following link has a table of operational system versions needed
to be able to be compatible for 32 bits ASNs from different vendors.
http://as4.cluepon.net/index.php/Software_Support

Regards,
Roque

- ------------------------

Amigos,

Esta liga indica las versiones m?nima de diferentes sistemas
operativos para soportar ASNs de 32 bits.
http://as4.cluepon.net/index.php/Software_Support

Saludos,
Roque

4ByteASを扱えるルータOSのバージョンを纏めたPageの告知。
こういう一覧でわかる情報はありがたい。
#まだASDOTとASPLAINが入り乱れているのが判る。

##僕のBayNetworksANHは4ByteAS化は無理だよね・・・

IETF-Digest@Mar 23, 2009

Date: Mon, 23 Mar 2009 17:35:35 -0400
From: Melinda Shore
Subject: Subscriptions to "ietf-honest"
To: 'IETF Discussion Mailing List'
Message-ID: <49C800A7.70208@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

I was auto-subscribed to Dean's "ietf-honest" mailing
list, and I'm unhappy about it. I don't know what his
current status is with regard to the ietf@ietf.org
mailing list but I think he's pretty clearly abusing
this mailing list by snagging names from it and
putting us on his mailing list without asking. I'm also
not thrilled that the "welcome" message he sends out
fails to clearly identify who's sending it and that
he does not represent the IETF. This is a small problem
but a problem nonetheless.

Melinda


色々なメーリングリストを覗いていると、善意からなのでしょうが一方的なメールマガジン(SPAM？)が送られてくることがあります。
議論の場を宣伝に使うようなもので、あまりオススメできない行為ですけどね。

AfNOG@Mar 22, 2009

Date: Sun, 22 Mar 2009 09:30:44 +0800
From: Mark Tinka
Subject: Re: [afnog] Data mining for African ISP
To: Global One Solutions
Cc: discuss , afnog@afnog.org
Message-ID: <200903220930.52725.mtinka@globaltransit.net>
Content-Type: text/plain; charset="iso-8859-6"

On Sunday 22 March 2009 03:30:42 am Global One Solutions
wrote:

> I would like to hear what our local ISP in African is
> using for data-mining, which helps them deal with (a)
> with DDoS attack, (b) Understand their traffic pattern,
> which helps them plan their capacity planning. I know
> DDoS attack is very critical to the operation folks and
> some of us used or still use home grown application. You
> can buzz offline if you want to. Any feedback is greatly
> appreciated.

These are typical applications of NetFlow/cflowd in IOS and
JunOS.

There's a lot of non-commercial flow collectors, e.g.,
Nfsen/Nfdump, as well as commercial products that work quite
well, e.g., Arbor Networks.

Other folks may use NTOP for the same, as well.

Cheers,

Mark.

DDoSアタックとか、トラフィック傾向とか知る為に、データマイニングに何を使えばいい？という質問に対する返答。
一般的にはIOSやJunOSで、お金を掛けないならNfsen/Nfdumpと、この辺りは先進国と状況変わらず。
あとのメールでもエンジニアのスキルとお金が必要という非常に的確なコメントも。

Outages@Mar 22, 2009

from Franck Martin
to outages@outages.org
date Sun, Mar 22, 2009 at 6:13 AM
subject [outages] Internet is slow today?

Did anyone notice any changes in email traffic?

_______________________________________________
outages mailing list
outages@outages.org
https://puck.nether.net/mailman/listinfo/outages


Outagesは障害情報が流れるメーリングリストで、以前は活用されていたようなのですが。
今は以前のようにNANOGメーリングリストに流れることが多いですね。
Outagesは上記のような、ゆる～い質問も出てくるメーリングリストになっています。
#ただ、そういう漠然とした違和感がトラブルの予兆だったりするのでバカにできないんですけど。

IETF-Digest@Mar 21, 2009

Date: Sat, 21 Mar 2009 15:55:29 -0700
From: Morgan Sackett
Subject: Audio Streams for IETF 74 in San Francisco
To: ietf@ietf.org
Message-ID: <4F7CD90E-B212-4014-BF70-7FB3DCEA22D1@verilan.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes

There will be MP3 audio streams of the meetings happening in the
breakout rooms. Specifically these are

Continental 1&2
Continental 3
Continental 4
Continental 5
Continental 6
Imperial A
Imperial B
Franciscan A

Please refer to the online agenda at http://tools.ietf.org/agenda/74/
to find a link to the stream for each session.

If there are concerns about the audio streams, there are a few ways to
get our attention. Via email either audio@meeting.ietf.org, or noc@meeting.ietf.org
. Via XMPP at noc@jabber.ietf.org.

Morgan Sackett
VP of Engineering

VeriLAN Event Services, Inc.
215 SE Morrison Street
Portland, OR 97214

Tel: 503 907-1415
Fax: 503 224-8833


IETF74ミーティングの音声中継に関して。
今は会場にこれる人でなくても議論を聞けるし、Chatなどで議論への参加もできる会議もあるので
以前に比べて敷居は多少下がったんじゃないかな。
そういうインフラを用意しても参加しない人は参加しないし。

NANOG@Mar 21, 2009

Date: 21 Mar 2009 10:32:30 -0000
From: John Levine
Subject: Re: REVERSE DNS Practices.
To: nanog@nanog.org
Message-ID: <20090321103230.24415.qmail@simone.iecc.com>
Content-Type: text/plain; charset=iso-8859-1

> I want to ask some folks out there that maintain reverse DNS queries
>of their respective IP blocks. I want to know if there is a need for
>me to contact my upstream provider. I am in charge of 2 /24's under
>LACNIC. I've already registered my DNS servers on LACNIC. but for some
>weird reason it's not owning reverse resolves. any tips would be
>gladly appreciated.

The RIRs don't maintain rDNS for you. You'll have to trace the
delegations downward from in-addr.arpa, find out who's handling your
/24's, and contact them to get them to delegate your chunks to you.

R's,
John

自分の管理してる逆引きDNSがうまく反映されないんだよね～。上流ISPに問い合わせたほうがいい？LACNICには自分のDNSサーバ登録したんだけど。という質問に対しての回答。

全てのDNSはdelegationされているのでそのツリーを追ったほうがいいと思うんだけどね。

RIPE-address-policy-wg@Mar 20, 2009

Subject: RE: [address-policy-wg] Policy?
Date: Fri, 20 Mar 2009 07:50:23 -0000
From:
To:

> imagine there is a company having huge allocation/assignment.=20
> Some happens (i.e. crisis), they lost a significant number of=20
> clients, so they have a lot of free IP space. Is there any=20
> policy ENFORCES this company to return unused address space?

No.

Policies do not enforce anything. Policies are like laws. They are
just words on paper. Enforcement has to come from somewhere=20
else.

If you read RIPE policies carefully, you will see that you do not have
to have a technical requirement today for every address that you
receive from RIPE. If RIPE is willing to give addresses to some=20
organizations which will not be used for many months, or years,
then it is difficult to force any organization to return addresses=20
when they experience a temporary downturn. Also, remember that most
RIPE members will reserve unused addresses for several months after
disconnecting a customer, before they assign those to other customers.

In the case of a dispute between RIPE and a member organization,
you cannot expect quick results. There will almost always be a
language barrier between RIPE and the member organization. The
multilingual hostmasters are probably not the right people to
be in the middle of a dispute. There are subtle difference in=20
translating a lot of the terminology that we use, for instance
assign and allocate have almost identical meanings in English,
so I don't expect translated terms to make any sense outside of
the RIPE context.

Let's face it, we are running out of IPv4 and the special efforts
that RIPE has made in the past year or so, has only caused this
runout date to become sooner for all but the smallest organizations.
IPv6 is the only way out of this mess. Attempting to enforce some=20
sort of efficient-use policy for IPv4 is wasted effort.

--Michael Dillon


顧客を失った企業から"ポリシー"として不要なIPアドレスの返却を"強制"できないか、
という質問に対する返答。端的に言うと、ポリシーで強制はできません、という話。

どのRIRでも既存の巨大Allocationを受けた企業から回収する方法に苦慮している。
どんなインセンティブを与えるか・・・
今まで検討された案は大部分が、先行者利益をかなり認める形でなかなか合意が得られない。
難しい。

ARIN-PPML@Mar 20, 2009

Date: Fri, 20 Mar 2009 11:07:09 -0700
From: Scott Leibrand
Subject: Re: [arin-ppml] Policy Proposal: Sunset 2008-6 on schedule
To: Ted Mittelstaedt
Cc: arin-ppml@arin.net
Message-ID: <49C3DB4D.8030605@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Ted,

I don't believe that the Board has yet released the record of their
(very recent) emergency policy action subsequent to adopting 2008-6. We
should see something released on that in the near future, and per the
PDP, will be discussing the action on PPML and at the San Antonio Public
Policy Meeting.

-Scott (speaking solely for myself, and not yet expressing any opinion
on any action taken or policy proposed on this subject)

Ted Mittelstaedt wrote:
> I fully support this.
>
> The disregarding of the "For a period of 3 years from policy implementation"
> statement in the policy proposal was NOT mentioned AT ALL in the actual
> records of the policy proposal itself:
>
> https://www.arin.net/policy/proposals/2008_6.html
>
> For THIS REASON ALONE setting aside ALL OTHER discussion I would be
> in favor of Owen's proposal.
>
> The COMPLETE implementation of ANY policy is a sacred trust, and while
> I might condone the ARIN board's actions of removing the sunset clause
> IF AN EXPLANATION WAS SUPPLIED IN THE POLICY RECORD the fact that one
> WAS NOT and NO mention of this appears in the record is, in my opinion,
> far, far worse than the thwarting the will of the community.
>
> It is one thing for ARIN to thwart the will of the community for reasons
> they feel are good and have a logical basis (changed premises, etc.) It is
> ENTIRELY DIFFERENT for them to do so and SWEEP IT UNDER THE RUG by NOT
> documenting it in the proposal.
>
> So, are we going to have to now, check and verify every accepted proposal
> against the actual NRPM itself to make sure the board didn't just
> "forget" to include something it didn't like?
>
> Fagh!
>
> Ted
>
>
>> -----Original Message-----
>> From: arin-ppml-bounces@arin.net
>> [mailto:arin-ppml-bounces@arin.net] On Behalf Of Member Services
>> Sent: Friday, March 20, 2009 10:30 AM
>> To: arin-ppml@arin.net
>> Subject: [arin-ppml] Policy Proposal: Sunset 2008-6 on schedule
>>
>> ARIN received the following policy proposal and is posting it
>> to the Public Policy Mailing List (PPML) in accordance with
>> Policy Development Process.
>>
>> This proposal is in the first stage of the Policy Development Process.
>> ARIN staff will perform the Clarity and Understanding step.
>> Staff does not evaluate the proposal at this time, their goal
>> is to make sure that they understand the proposal and believe
>> the community will as well.
>> Staff will report their results to the ARIN Advisory Council
>> (AC) within 10 days.
>>
>> The AC will review the proposal at their next regularly
>> scheduled meeting (if the period before the next regularly
>> scheduled meeting is less than 10 days, then the period may
>> be extended to the subsequent regularly scheduled meeting).
>> The AC will decide how to utilize the proposal and announce
>> the decision to the PPML.
>>
>> In the meantime, the AC invites everyone to comment on the
>> proposal on the PPML, particularly their support or
>> non-support and the reasoning behind their opinion. Such
>> participation contributes to a thorough vetting and provides
>> important guidance to the AC in their deliberations.
>>
>> The ARIN Policy Development Process can be found at:
>> http://www.arin.net/policy/pdp.html
>>
>> Mailing list subscription information can be found at:
>> http://www.arin.net/mailing_lists/
>>
>> Regards,
>>
>> Member Services
>> American Registry for Internet Numbers (ARIN)
>>
>>
>> ## * ##
>>
>>
>> Policy Proposal Name: Sunset 2008-6 on schedule
>>
>> Proposal Originator: Owen DeLong
>>
>> Proposal Version: 1.0
>>
>> Date: 19 March 2009
>>
>> Proposal type: delete
>>
>> Policy term: permanent
>>
>> Policy statement:
>>
>> Effective March 31, 2012, the changes made to the NRPM by
>> policy 2008-6 are to be deleted.
>>
>> Rationale:
>>
>> Part of the policy that the community developed consensus for
>> in 2008-6 included a sunset clause. The ARIN Board in an
>> unprecedented action chose to discard this clause while
>> approving the remainder of the policy.
>>
>> This proposal is intended to restore the will of the
>> community and ensure that this policy remains temporary as intended.
>>
>> Timetable for implementation: March 31, 2012
>>

各RIRで今熱心に議論されているのがIPv4アドレスブロックの移転について。
この2008-6は特定用途に関する緊急IPv4アドレス移転ポリシー。
しかしPDP(PolicyDevelopmentProccess)の性質上、多少時間が掛かるので
緊急性にどれだけ対応できるのか？ということで今後も注意深く見守る必要があるとの意見。

各RIRとも強制力の無いポリシーで先行者利益によって得たアドレスをいかに回収するかという
難題を抱えている。

GTER@Mar 19, 2009

Date: Thu, 19 Mar 2009 14:30:39 -0300
From: Flavio Junior
Subject: Re: [GTER] Failover de link ADSL
To: Grupo de Trabalho de Engenharia e Operacao de Redes

Message-ID:
<58aa8d780903191030v89842abo6c09c76d90fa1b78@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

As rotas ser?o removidas quando as interfaces forem baixadas pelo
script, antes de rodar o dhclient na placa que deve assumir o link...

Vamos a um caso extremamente simples, um script:

#!/bin/bash
#

# Links por eth
ADSL=eth1
EBT=eth2

# Descobrindo link atual
LinkAtual="$(awk '$1~/0.0.0.0/{print $NF}' < <(route -n))"

# Hosts de teste
HOST[0]="200.160.2.3" # registro.br
HOST[1]="$(awk '$1~/0.0.0.0/{print $2}' < <(route -n))"

LinkStatus="DOWN"
for host in ${HOST[@]}; do
ping -c2 -w2 -q $host >/dev/null 2>&1
if [ $? -eq 0 ]; then
exit 0
fi
done

if [ "$LinkStatus" == "DOWN" ]; then
ifdown $ADSL || ifconfig $ADSL down
ifdown $EBT || ifconfig $EBT down
if [ "$LinkAtual" == "$ADSL ]; then
ifup $EBT || dhclient $EBT || dhcpcd $EBT
else
ifup $ADSL || dhclient $ADSL || dhcpcd $ADSL
fi
fi

## FIM DO SCRIPT


Isso ta grosseiro e eu escrevi diretamente aqui no e-mail...
A ideia do funcionamento eu acho que ta correta, ou seja:

1. Executa testes no link atual
2. Se o link estiver fora, DESATIVA AS PLACAS DE REDE DE INTERNET e
reativa a do OUTRO link (dhclient)
2. Se o link estiver OK, ignora o restante do script

Veja que eu considerei o gateway como um host de teste, nem todos
cenarios s?o assim, muitas vezes a internet cai e o gateway ainda
responde ping, ou ent?o o gateway se torna um IP de LAN que o modem
forneceu via DHCP e assim responde ping..
Tu pode por 2, 3, 4, X hosts ali pra testar... Qto mais testes, mais
tempo o script executa..

O caso agora seria por isso no crontab:

*/5 * * * * /usr/local/bin/script_ninja_linkswitch.sh


--

Fl?vio do Carmo J?nior aka waKKu

2009/3/19 Alexandro Corr?a - SulSoft :
> Sobre essa quest?o de rotas criadas pelo DHCLIENT, depois de adquirir o IP
> eu costumo rodar um script que remove todas as rotas e cria novamente
> conforme minhas necessidades.
> Tem funcionado bem at? o momento...
>
> Atenciosamente,
>
> ? ? ? ?Alexandro Corr?a
> Tecnologia da Informa??o
> alexandro@sulsoft.com.br
> Fone/Fax: +55 (51) 3333-1581
>
>
> "Esta mensagem pode conter informa??o confidencial e/ou privilegiada. Se
> voc? n?o for o destinat?rio ou a pessoa autorizada a receber esta mensagem
> n?o pode usar copiar ou divulgar as informa??es nela contidas ou tomar
> qualquer tipo de a??o baseada nessas informa??es. Se voc? recebeu esta
> mensagem por engano por favor avise imediatamente o remetente respondendo o
> e-mail e em seguida apague-o."
>
>
> bruno@openline.com.br escreveu:
>>
>> --- Leonardo Amaral escreveu:
>>
>>>
>>> Mas quando der o DHClient na primeira interface ele n?o "come"
>>> a rota da primeira?
>>>
>>
>> na verdade fica com 2 rotas...
>>
>> o que voc? pode fazer ? alterar o script que "sobe" a rota
>> (o dhclient chama um script pra setar interface e rota)
>> e guardar o gateway num arquivo
>>
>> dai quando precisar mudar, verifica o arquivo e muda de
>> acordo
>>
>> pode no down do dhclient tamb?m remover o arquivo para
>> saber que este est? down
>>
>> []s, !3runo
>>

ADSLリンクの冗長化について。
ISPのエンジニアの議論というよりも、家庭内サーバ管理者の技術メーリングリストのような時もある。それもまた面白い。

RIPE-db-wg@Mar 19, 2009

Date: Thu, 19 Mar 2009 11:59:04 +0100
From: Henk Uijterwaal
To: ncc-announce@ripe.net, ncc-services-wg@ripe.net, db-wg@ripe.net
Subject: Re: [db-wg] Implementation of ASPLAIN Format

[Apologies for duplicates]


Dear Colleagues,

With the publication of RFC 5396, the IETF has standardised the
representation of all Autonomous System (AS) Numbers in the ASPLAIN
format. This covers both 16-bit and 32-bit AS Numbers. The previous
ASDOT format is now obsolete. The RIPE NCC plans to start using the
ASPLAIN format on March 25, 2009.

From that time, any AS Numbers or references must be in the ASPLAIN
format. The ASDOT format will no longer be accepted in RIPE NCC
services such as the LIR Portal and the RIPE Database.

The update of RIPE NCC systems to ASPLAIN will take place on
Wednesday, March 25, according to the following schedule (all times
are in UTC and are approximations):

7:00 1. Updates to the RIPE Database via webupdates and syncupdates
will be disabled. Mail updates will be queued.

After the update mechanism has been stopped, all objects
containing an AS Number in ASDOT format will be
automatically converted to identical objects with the AS
Number in ASPLAIN format. Technical details of the
conversion process will be published shortly.

2. The LIR Portal will be stopped.

10:00 The RIPE Database will now accept queries in ASPLAIN format;
it will no longer accept queries in ASDOT format.

12:00 1. The LIR portal will be restarted. Any reference
to an AS Number should be made in ASPLAIN format.

2. Any mail updates to the RIPE Database submitted after 7:00
will be processed. Webupdates and syncupdates will be enabled
again.

The Routing Information Service (RIS) will not be updated on March 25.

If you use AS Numbers internally, or with other tools that have not yet
been updated, you may be interested in a conversion tool that has been
provided by APNIC. This tool converts ASDOT format AS Numbers to ASPLAIN
and back. It can be downloaded from: http://www.apnic.net/cgi-bin/convert-asn.pl

If you have any concerns about this matter, please send an email to


Kind regards,

Henk Uijterwaal
Senior Project Manager, RIPE NCC


JANOGでの議論から追いかけたのですが、思いのほか早くASDOTからASPLAINになりましたね。
BGPオペレータとしては統一感があっていいかもしれない。
ASDOTしかなかった時代は前半の16Bitを国番号にすればいいのにと思ってました。
1.*は米国、44.*は英国、7.*はロシア、81.*は日本、というように。
#そうすれば国毎のFilterが簡単。
でもそうなるとIETFというよりITUっぽくなるのでInternetに対する政府/国連の管理が強くなってしまうかも、という反対意見を聞き、諦めた次第です(笑)

NANOG@Mar 18, 2009

Date: Wed, 18 Mar 2009 22:27:25 -0400
From: "Tim McKee"
Subject: RE: Seeking Connectivity in IRAQ
To: "'Gerard Dupont III'" , "'Robert D. Scott'"

Cc: nanog@nanog.org
Message-ID: <005f01c9a83a$3e758af0$bb60a0d0$@net>
Content-Type: text/plain; charset="us-ascii"

www.sdnglobal.com does enterprise grade satellite service.

Tim mckee

-----Original Message-----
From: Gerard Dupont III [mailto:gerard@avolutia.com]
Sent: Wednesday, March 18, 2009 20:12
To: Robert D. Scott
Cc: nanog@nanog.org
Subject: Re: Seeking Connectivity in IRAQ

Have you looked at

http://www.tigrisnet.net
or
http://www.sniperhill.com

Gerard


Robert D. Scott wrote:
> A unit within the University has need to get reliable network connectivity
> to Iraq, more specifically Baghdad. I was wondering if any nanogers have
any
> recommendations and/or contacts with providers in the area. Wired or
> Wireless. Off-list is fine.
>
> TIA
>
> Robert D. Scott Robert@ufl.edu

イラク・バグダッドに展開しているISPを問い合わせるメール。
それに対して情報が集まってきています。
やはり情報衛星でのInternet接続がメインか。
#ま、インフラは自分の国の軍隊が壊した訳だし。

JPCERT/CC-Report@Mar 18, 2009

from: JPCERT/CC
to: announce@jpcert.or.jp
date: Wed, Mar 18, 2009 at 10:28 AM
subject: JPCERT/CC REPORT 2009-03-18


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

JPCERT-WR-2009-1101
JPCERT/CC
2009-03-18

<<< JPCERT/CC REPORT 2009-03-18 >>>

～ばっさりと略～

――――――――――――――――――――――――――――――――――――――
■今週のひとくちメモ
――――――――――――――――――――――――――――――――――――――

○英 BBC の情報番組がボットネットを特集

英 BBC の "Click" という情報番組がボットネットに関する特集を行い
話題になりました。

この番組ではスタッフが実際に数万台規模のボットネットを購入し、ボッ
トネットから予め用意した実験用のメールアドレスにスパムを送信した
り、DDoS 攻撃を行うデモンストレーションをしたりしました。番組で
はボットネット管理者とのチャットの様子や、複数のボットを管理し命
令を実行するための管理 GUI が紹介されています。最後にスタッフは
購入したボットネットに対して自己消去の命令を出して番組は終了しま
す。

アンダーグラウンドな世界で起こっている事象を正確に理解するために
は、この番組のように実際の攻撃者と同じことをしてみることが有効で
す。しかし、アンチウイルスベンダの研究者からは、ユーザへの啓発を
目的としているにしても、このような形でボットネットを利用すること
は、社会的に許されないことではないか、との問題提起がなされていま
す。

セキュリティ研究者は「どこまで許されるのか?」を自問自答しながら
今日も調査研究を続けています。

参考文献 (英語)
BBC World News
Click - Buying a botnet
http://www.bbcworldnews.com/Pages/ProgrammeFeature.aspx?id=18&FeatureID=1075

SOPHOS: Graham Cluley’s blog
Did BBC break the law by using a botnet to send spam?
http://www.sophos.com/blogs/gc/g/2009/03/12/bbc-break-law-botnet-send-spam/

～後略～

以前から考えていたBotnet撲滅方法をBBCがやった！
素晴らしい。がこれが全てではなく、他にも活動しているBotnetはあるはず。
もしあるBotnetが撲滅されても、同じように侵入されるPCは後を絶たず、
ユーザのリテラシを高める運動を重ねるか、OSメーカーにセキュアなOSを作るように
働きかけるか、くらいしか解決方法がない。
こういう地道な活動って大変なわりに報われることが少ないので関わってらっしゃる方々には頭が下がります。

arabeyes-general@Mar 18, 2009

Date: Wed, 18 Mar 2009 00:29:47 +0100
From: Abdelmonam Kouka
Subject: Re: [general] New Project name of Ubuntu Muslim Edition
To: general@arabeyes.org
Message-ID:

Content-Type: text/plain; charset="utf-8"

السلام عليكم ورحمة الله،

* أخي يوسف شهيبي: جازاك الله خيرا
* أخي أسامة خياط: لا ندري إن كان طلب من مشروع
ubuntu christian edition
مثلما طلب من هذا المشروع، الرسالة أرسلت لنا خصيصا، ربما راسلوهم أيضا وربما
لا، وفي صورة مراسلتهم لا أدري إن كانوا إستجابو أم لا!
لكن الحمد لله، رب ضارة نافعة، فتغيير الإسم ربما سيجلب عددا أكبر من المهتممين
والمساهمين، إضافة إلى إمكانية تطوير التوزيعة بصفة مستقلة عن أوبونتو في صورة
توفر الموارد..من يدري [?]

السلام عليكم

Ubuntuプロジェクトにアラビア語クリスチャンバージョンの要求を送るという話。
翻訳の精度が低いからか「偽装」とか「名前の変更」というワードが出てくる。
本当にそういう話をしているとすると・・・？！

s-asia-it@Mar 17, 2009

Date: Tue, 17 Mar 2009 18:04:51 +0500
From: Fouad Bajwa
Subject: [s-asia-it] For a better Deal - Deal Makers Anyone?
To: Pakistan ICT Policy group ,
pakgrid ,
bytesforall_readers@yahoogroups.com, s-asia-it@apnic.net
Message-ID:
<701af9f70903170604s5cd4c263l442fb996c0b84b94@mail.gmail.com>
Content-Type: text/plain; charset=windows-1252

For a better Deal - Deal Makers Anyone?
Creating Pakistan's Mix - Deal Makers: Will they take our society,
economy and progress to a new level?

(Fouad Bajwa, Independent Discussion/17-03-2009) "Are you a Deal
Maker?" asks someone named Walmer. "A Deal Maker? What's that supposed
to mean?" is my reply. "You know, a social innovator striving to bring
his country out of a social-economic deadlock in these difficult
times?", I stare at my screen trying to make sense of what this guy is
asking me during a Video Chat online. "There are a bunch of you guys
that can act as the perfect mix to make that happen", he continues as
a response to my silence, "You seem to carry the required magic, the
perfect group of mavericks to manoeuvre and help others manoeuvre
through, don't be sad at this moment in time, be the ingredient of
your region's change! You don't need any financial or strategic
support, you just need to group up with the right likeminded Deal
Makers and progress forward!?

He leaves me thinking, I was pitching an idea based around social
innovation for youth and mid career professionals amidst a technology
setting and seeking possible support but this guy after many online
conference calls leaves me to think about something that I've never
thought of. To date, I have gone about the country and to over 12
abroad, advising, sharing, discussing and giving out ideas and working
with people to make their plans transform into something doable but
never thought of actually turning the tables around. Those friendships
are one side of the case and I have friends across this country that
can make wonderful things happen in terms of progress and growth for
their organizations as well as the region, but we never got together
to pitch our deals, we are blinded by selfish needs, despite that, we
can still make the deal for innovation while achieving social and
economic growth! Yes, be the Deal Makers for Change.

It's supposed to be a mix of Intellect applied to innovate and then
create a deal with human development and fair business networks. Be
the maverick of change and growth. How? has always been the question
for me I guess and I don't know why I have stuck to that. My thought's
deadlock was recently broken and it was changed due to something that
struck the outside world from our inside world. Only moments after the
discussion in question ends, someone sends me a link showing this
http://www.nytimes.com/slideshow/2009/03/15/world/20090316-PSTAN_7.html.
Just two days ago, they saw kids battered on the street as part of a
crackdown in Pakistan. Is this battered kid even eligible to vote? Has
he reached that age yet? But what?s the deal for getting beaten up?
Definitely, it?s not a case of sheer public entertainment? No, not at
all! It was the deal being made. This is a recent picture that the
world grasped from our region. We took the beating! We broke the old
deal and pitched a better one! I know it must have hurt pretty bad, I
got it once and boy does it hurt but its always been for the good.

Everyone seems to be at it today, where they group, they pitch, where
they standalone, they suffer. Where they are vocal, they break
barriers and have the other side lend them their attention. The Deal
Makers, they are the magic, the mavericks, an ingredient of the mix
for change. They have shown what it takes to make the new deal, to
understand its importance, to value what we have and to struggle for
what is needed . Its not about social and economic change, its about
making the right case for change whatever the context may be. They
were out there taking the beating, others were sitting behind the tube
enjoying a battle of the odds but each heart pounded skipping a beat
to be engulfed by the emerging change.

Some of us took a beating too but we weren't on television for that
matter. I was stuck in Malaysia when the Bangkok Airport was locked
down by the opposition but some people back home were struggling for a
policy makeover with reference to technology and innovation. What were
their concerns? Simple, they were striking a deal for a fair public
policy framework that brought 67% of the 'outsiders' in to context
with the '33%' insiders. The larger figure wasn't witnessing what was
happening two days ago and the smaller figure was behind the tube in
true shock. Anyway, I was getting phone calls from 'Deal Makers'
complaining the ongoing trouble of getting the powerful to listen to
the poor and to create the right balance of fair play and social
equity in national progress. They said, they were missing their
beloved Deal Maker to make the fair move.

So what is the deal going to be for me now? What will I pitch next or
should it be us as a group that makes the pitch? I know this
discussion seems awfully crazy but I am pretty much sane and not naive
to say, I have a better deal to pitch in my area of Technology and
Innovation for positive social and economic change. My problem I guess
is that you who have are also deal makers in the similar sense just
don't want to get together, a feature of our people discussed all over
the world that we are good at tugging each other?s legs but when it
comes to common positive change or causes for improvement, we are good
at pulling.....but not good at making a collective to pitch the deal
that affects us all.

I plan to wear shorts this time and summer while offer other Deal
Makers to join in, placing the tugging part aside, we may be able
pitch the right deal for the right amount of change. Don?t mind my
optimism, its about time!

--

Regards.
--------------------------
Fouad Bajwa
@skBajwa


パキスタンが政局で揺れています。
#更に国家破産の危機も。
こういう技術系のメーリングリストでも熱く思いのたけを語る人も出てきます。
日本にはこういう流れはないかな。