5/20/2009

AusNOG@May 19, 2009

date Tue, May 19, 2009 at 2:41 PM
subject [AusNOG] PPC1 landing





Cheers,

jsl


写真の添付のみっていうメールはメーリングリストでははじめて見たな(笑)
PPC-1の陸揚げの光景だと思うのですが。

5/19/2009

viops@May 18, 2009

date Mon, May 18, 2009 at 8:10 AM
subject [viops:245] Oracle Buys VirtualIron 13.May.2009


なんとなく忘れそうなのでメモ。


OracleがVirtualIronを買収
------------------------------------------------------------
http://www.oracle.com/virtualiron/index.html
On May 13, 2009, Oracle announced it has agreed to acquire
Virtual Iron Software, Inc. (Virtual Iron),
a provider of server virtualization management software.

The transaction is subject to customary closing conditions
and is expected to close this summer.
Until the deal closes, each company will continue to operate
independently.
------------------------------------------------------------

次はKVM(Kernel-base Virtual Machine)+QEMUあたりが、話題になる
可能性?
Unified I/O と Virtual Switch Consolidation(統合)が、
ちゃくちゃくと進んできている様子。

--
Naoto


オラクル、元気ですね。
景気がいいのか、底値で買えるチャンスと踏んだか・・・
#昔、拡大路線のキャリアは粉飾で自滅していきました・・・。オラクルは固定客がいるからキャリアとは違うでしょうが。

denog@May 18, 2009

Date: Mon, 18 May 2009 09:06:13 +0200
Subject: Beering Köln


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

Moin,
hat jemand von Euch Lust am Donnerstag um 19 Uhr ein DENOG-Beering/Futtern in
Köln zu machen?
Mr6Tux hat als Location das Tacoloco IV (http://www.tacoloco.de/) in Hürth
vorgeschlagen.
Wir sind jetzt schon zu viert. Wer noch dazu kommen will kann sich ja kurz hier
oder im IRC melden damit wir ggf. einen Tisch reservieren können.
Gruß
--Kay / frapzzt
-----BEGIN PGP SIGNATURE-----


久々にdenogだ!と思ったらBeeringEventのお誘いだった。
さすがドイツ人。
日本でもなぜかこの時期に日比谷で"オクトーバーフェスト"やってますね。
オクトーバー・・・

5/17/2009

JANOG@May 16, 2009

date Sat, May 16, 2009 at 1:41 AM
subject [janog:08906] IPv6 Firewall

許です。

この間、IPv6のFirewallを書いててちょっと気がついたので、ここにも
書いておきます。
# きっかけは、某所のWebサービスが見られない場所があると言う話を
# 某所で聞いたことですが。
IPv6は、IPv4と違ってパケットをFragmentしません。その代わり、
Path-MTU Discoveryを行ってpacket sizeを決める(表現は微妙ですが)
わけですが、このPATH-MTU DiscoveryってICMPなんですよね。
というわけで、以下悲しいシナリオ。
1) IPv4では、今時、ICMPを全部たたき落とす設定がしばしば行われる
2) IPv4では、DF bitを立てていない限り、それでも問題なく通信できる。
一応、ICMP type UNREACH code NeedFragmentが帰ってくるので
Path-MTU Discoveryと同等の処理は出来るが、そこまでのFilterはあ
まり書かれていないと思う。
3) IPv6でもIPv4と同じようなPacket Filter Ruleを書いてしまう
4) 従って、Path-MTU Discoveryをたたき落としてしまう
5) そのせいで見られないWeb Pageが発生することがある

で、僕自身はipfwとかiptablesの実装を知らないので、それらの
filter ruleは書けませんが、OpenBSDに(NetBSD/FreeBSDにも)実装されて
いるpfのRuleは判った(つもりな)ので、一応メモ代わりに。
(NetBSD 5.0で試したつもり。転記ミスがあったらごめん)
pass in quick inet6 proto ipv6-icmp from $from to $to icmp6-type toobig

# これが問題になるって事は、下手をしたらNeighbor Discoveryも問題に
# なるってことかしらん?ってことで、Neighbor DiscoveryとRouter Solicitation
# さらに、Who-Are-Youに関する部分も一応。
# pass in quick inet6 proto ipv6-icmp from $from to $to icmp6-type {routersol, routeradv}
# pass in quick inet6 proto ipv6-icmp from $from to $to icmp6-type {neighbrsol, neighbradv}
# pass in quick inet6 proto ipv6-icmp from $from to $to icmp6-type {wrureq, wrurep}
# 但し、これは、Externalには返さない方がいいと思います。
# Who-Are-Youは、返してくれると凄く嬉しいけど。

というわけで、tcpとかudpはIPv4と同じ考え方でいいと思うんだけど、ICMP
は気をつけた方がいいかもしれません。

# 常識だったらごめんなさい。

追伸: 一応。proto ipv6-icmpの部分は、/etc/protocolsを見て下さ
い。もしかして、表現が違う可能性があるので。
二伸: Path-MTU Discoveryの正確な挙動は、ここには書いていません。
そう言うICMPがあるわけではなくpacket too bigを利用して、
途中経路のMTUを知る術がある(と言っていいのかしらん?)と
言うことに過ぎないはず。
(自信がないので、識者のコメントが欲しいです。呑んでいる
のでRFC当たる気合いは今は無い…)


JANOGで話題のIPv6ICMPフィルタ話。
こういう情報ってほかの国であまり大々的に議論されているのを見たことがない・・・

5/16/2009

JANOG@May 15, 2009

date Fri, May 15, 2009 at 11:00 AM
subject [janog:08881] [Fwd: (JPNIC-IP-USERS 1696) JPOPM16 ご提案募集!]



JPNIC 奥谷です。

転送します。重複ご了承ください。


みなさま、

第16回JPNICオープンポリシーミーティングでのプレゼンテーションを募集いた
します。

JPNICオープンポリシーミーティングでは、みなさんからご応募いただいた発
表をもとにIPアドレス・AS番号の管理に関わる議論を進めています。

これまでは例えばIPv6 PIアドレスの新設やIPv4アドレスの枯渇に向けた最後の
ブロックの分配方法等について、ご応募いただいた提案に基づき議論を行ってき
ました。

また、提案に限らず、情報提供を目的としたプレゼンテーションもお受けしてい
ます。

「発表に興味はあるけれど内容がかたまっていない」
「問題意識はあるけれどどう発表すればよいのかわからない」

等のご相談も受け付けていますので、その他ご応募にあたってのご不明な点もあ
わあせて、お気軽にポリシーWG(jpopf@venus.gr.jp)までご連絡ください。

なお,今回,開催日は,ご提案がございました場合,APNICミーティングへのエ
スカレーションを想定して7月1日(水)を予定しておりますが,この時期ですと
APNIC ミーティングにおけます提案が出そろっていないため,ご提案の有無,
APNICへのエスカレーションの必要性を鑑み,皆様からのご応募に基づき,ご提
案者と相談の上最終決定することにいたしました.開催情報のご案内は5月下旬
に予定しています.


■プレゼンテーション募集要項

募集内容:日本におけるIPアドレス・AS番号のポリシーに関するプレゼンテー
ション

応募締切:2009年5月29日(金)

応募先 :jpopm-apply@venus.gr.jp

応募方法:下記に添付する応募フォームに記入の上,ご応募ください.

通知 : 当日プレゼンテーションをお願いする方には,2009年6月5日(金)
までにご本人にご連絡いたします.

開催情報:決定次第後日改めてご案内いたします。

※下記応募フォームにて頂いた個人情報は,ポリシーワーキンググループに
おけます,第16回オープンポリシーミーティングの議題検討,及び,応募者
との連絡目的以外には使用致しません.

※ご提案内容に関します理解を深め,議論を進めるために,内容,及びプ
レゼンテーション資料をミーティング開催前から公開させて頂きますこと
をご了承下さい.公開方法はWeb掲載、当MLへの周知を予定しております.
掲載URL等は後日お知らせ致します.

※プレゼンテーションをご応募は内容に沿うものであれば基本的にお受けし
ておりますが,時間枠の都合上,残念ながらお断りさせていただくことも
ありますことをご了承ください.


■応募フォーム

------------------------------------------------------------------------
第16回オープンポリシーミーティングプレゼンテーション応募フォーム

ご氏名  :

ご所属 :

タイトル :

カテゴリー:□情報提供(I) □提案(P)
※上記のどちらかをご選択ください 

必要時間(分):

内容 :
ポリシー提案(P)の場合、以下の項目を明記下さい。
・ご提案内容の概略
・ご提案理由
- 現状の問題点
- 改善したいポイント
- 想定されるメリット、デメリット
・ご提案が採択された場合の影響範囲
(指定事業者、JPNIC、ユーザなど)
・コミュニティに対し,合意を得たいポイント

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

■応募に関するお問い合わせ
応募内容、記述方法など、応募にあたってご不明な点、ご相談がありました
らお気軽にご連絡ください。

ポリシーワーキンググループ
jpopf@venus.gr.jp

■参考
「JPNICオープンポリシーミーティングについて」
http://www.nic.ad.jp/ja/basics/terms/jpopm.html

「第15回JPNICオープンポリシーミーティング」
http://www.venus.gr.jp/opf-jp/opm15/opm15-program.html

「JPNICにおけるIPアドレスポリシー策定プロセス」
http://www.nic.ad.jp/doc/policy-process.html


さてと。ARIN,RIPE,LACNIC,AfriNICが春にポリシー策定シーズンを終えたこの時期に、
日本のポリシー活動が熱くなる。
#APNICが夏と冬っていう季節はずれなのが原因で、日本がとくにどうというわけでもないのですが。

提案したいことがあればガンガン提案を出してみるといいですよ。
ポリシーWGの面々が優しくフォローしてくれるはずです。(突拍子のないポリシー以外は)

GTER@May 15,2009

Date: Fri, 15 May 2009 09:00:18 -0400
Subject: [GTER] Google ontem


http://www.wired.com/epicenter/2009/05/when-google-goes-down-it-goes-down-hard/
http://www.networkworld.com/community/node/41880

Pequena diferenca no grafico :-)


OutageやNANOGで話題になったGoogleIssueがここにも報告されています。
世界はつながっているんだねぇ。
自分が著名サイトを運営していて、チョンボや障害を引き起こすと世界中にバレるということ。

Outages@May 15, 2009

date Fri, May 15, 2009 at 12:56 AM
subject [outages] Google Issue


We've been noticing issues for the past hour accessing Google's sites. Sluggish responses mostly.

Other sites are fine. We connect through Level3 and Bell Canada.


Googleは既に主要インフラと化していますね。
NANOGでも同様に熱い話題になっているようです。

5/13/2009

Gore/ESNOG@May 12, 2009

Date: Tue, 12 May 2009 18:48:52 +0200
Subject: [Gore] Ficheros video y streaming de GORE 3


Gracias a la gente del DIT UPM que nos acompañó ayer (Abel y Monica)
estan en linea los videos del las ponencias del GORE3, como ficheros
para bajar o via streaming.

Ver los URLs en la pagina del GORE 3: http://www.esnog.net/gore3.html

Saludos
Joao


先日行われたGore3のビデオアーカイブも公開された。
全篇スペイン語だが。勉強にいかが?

5/12/2009

Gore/ESNOG@May 11, 2009

Date: Mon, 11 May 2009 11:44:12 +0200
From: joao damas
Subject: [Gore] Cambio en servidor jabber para GORE3


Utilizad la sala xmpp://gore3@conference.jabber.org para comunicaros
si quereis hacer preguntas a los ponentes de GORE3 y no estais en la
sala pero si siguiendo el streaming.

El de esnog esta caido por gremlins que no consigo eliminar por ahora

Joao


もうすぐ開催されるGore3のJabberも準備された。
JANOGにも欲しいよね。

NANOG@May 11, 2009

Date: Mon, 11 May 2009 22:29:27 +0200
Subject: two interfaces one subnet


Hi,

This is a pretty moronic question, but I've been searching RFC's on-
and-off for a couple of weeks and can't find an answer. So I'm hoping
someone here will know it offhand.

I've been looking through RFC's trying to find a clear statement that
having two interfaces in the same subnet does not work, but can't find
it that statement anywhere.

The OS in this case is Linux. I know it can be done with clever
routing and prioritization and such, but this has to do with vanilla
config, just setting up two interfaces in one network.

I would be grateful for a pointer to such an RFC statement, assuming
it exists.

Thanks!

Chris


とりあえずやってみればいいことなのにRFCを調べるなんて素晴らしい。
色々やった結果、挙動が異なるので調べてるならそれも納得。
コメントがたくさん出てきています。

5/09/2009

AfNOG@May 8, 2009

Date: Fri, 8 May 2009 07:12:21 -0700 (PDT)
Subject: [afnog] Breaking News: Kenyan Internet Community comes face
to face with new Legislation


Apologies for cross-posting:

It took a KENIC (KEnya Network Information Center, www.kenic.or.ke) Annual General Meeting for the Kenyan Internet community to digest the implication of the a Kenyan ICT Legislation passed more than five months ago. The law which included sections that touched on the Media, IT, Telecommunication and Postal Services has faced stiff resistance from the Media fraternity while the Internet Community kept a low if not a dead profile.



It was at the KENIC general meeting held today in Nairobi that the Internet Community grappled with the implication of the IT section on the operation of the .KE namespace. The law specifies that all second level .KE internet domain names must be licensed by the country's converged Regulator, Communication Commission of Kenya. The law requires that all Registries - those who manage the internet domains - must apply for a license by the 2nd of June 2009.



KENIC, a public-private-partnership has under the ICANN Policies been managing the .KE namespace including the 2nd level sub-domains such as xyz.CO.KE, xyz.OR.KE, etc. From 2nd June 2009, KENIC must seek permission from the Regulator to continue managing these sub-domains. In an effort to comply with the law, the KENIC Board requested the community to support a resolution that a new legal entity (Special Purpose Vehicle, SPV) be created in order to apply for the license from the Regulator as well as compete with other potential entities that are set to fight in that space.



The proposals opened up heated discussions with some members wondering if KENIC was ceding its hard-won rights & control over the .KE namespace to an exclusive and single entity. The current governance structure for KENIC provides for a Multistakeholder Partnership over the whole .KE namespace and has the Govt, Academia, Private Sector/Telcos and Civil Society Board Representation that is wholly accountable to Internet Users during Annual General Meetings. Effectively, the new law takes part of this mandate and places it under one or two of these Stakeholders that is the Regulator/Govt.



Members wondered about the criteria that would be used by the Regulator to award the management licenses to various competitors. Others wondered about the potential conflict between the local legislation and the ICANN policies given that KENIC has currently been operating under ICANN policies but now has to take cognizance of the local law. For example, if the Regulator granted a license to someone else to manage the "co.ke" subdomain BUT the local internet community for one reason or the other instructed the KENIC Board NOT to accept and transfer the delegation from KENIC how would that be resolved? And yet other members wondered to what extend the proposed SPV would cannibalize their existing markets and services.



It has taken five months of silence but clearly, the Kenyan Internet community is just beginning to understand and feel the heat of some sections in the ICT law that had previously been hijacked and labeled "Media law" at the expense of IT practitioners. It will be interesting to see how this plays out before and after the 2nd of June 2009 - the date when all subdomain managers must be licensed by the Regulator.



walu


ケニアにてメディアに関するIT関連の法律の適用に関して。
今後こういう動きが増えてくるのかな。

GTER@May 8, 2009

Date: Fri, 8 May 2009 00:59:35 -0300
Subject: [GTER] Internautas ficam temporariamente sem acesso ao Google
no Brasil


http://ultimosegundo.ig.com.br/economia/2009/05/07/internautas+ficam+temporariamente+sem+acesso+ao+google+no+brasil+6002915.html

O Google Brasil informou h? pouco que um problema t?cnico, surgido durante
manuten??o de rotina dos roteadores, tirou do ar o site de buscas hoje ?
tarde.

Segundo a empresa, a falha interferiu no tr?fego de informa??es de parte dos
usu?rios brasileiros.

De acordo com nota ? imprensa, a pane durou "instantes" e rapidamente foi
solucionada. Boa parte dos internautas, no entanto, passou pelo menos duas
horas sem acesso ao site de buscas. E a impossibilidade de conex?o perdurava
no in?cio da noite.


Googleブラジルの接続障害でここのところGTERが活発でしたが、レポートが出てきました。
ようやく収束かな。

5/08/2009

RIPE-address-policy-wg@May 7, 2009

Date: Thu, 7 May 2009 14:15:03 +0200
Subject: [address-policy-wg] IPv4 PI assignment statistics

Dear Colleagues,

During the Address Policy Working Group session at RIPE58, statistics
were requested about the number and size of IPv4 PI prefixes that the
RIPE NCC has assigned over the last few years.

NOTE: The numbers for 2009 contain data up to May 2009.

2005 2006 2007 2008 2009
/16 0 1 0 0 1
/17 0 1 1 0 0
/18 1 2 3 10 1
/19 3 7 4 12 7
/20 25 28 23 44 14
/21 51 56 89 100 26
/22 260 261 261 402 111
/23 385 464 778 571 159
/24 726 897 973 1046 292
/25 10 22 8 8 5
/26 7 6 8 5 0
/27 5 8 7 7 2
/28 0 8 0 1 0
/29 2 1 0 8 0

Total 1475 1762 2155 2214 618

Please let us know if you require any further information.

Best regards,

Alex Le Heux
RIPE NCC


欧州地域でのプロバイダ非依存IPv4アドレス割当ての状況についての報告。
/25以下も結構あるけど、何に使っているんだろうか。使えているんだろうか。

LACNIC-Anuncios@May 7, 2009

Date: Thu, 07 May 2009 18:34:06 -0300
Subject: [LACNIC/Anuncios] Nueva Informacion LACNCI XII/Update LACNIC
XII


~スペイン語版はばっさりと略~

Dear colleagues of the Latin American and Caribbean community:

More than 250 people have already registered to attend the LACNI XII
meeting in Panama. The event will be held on 24 - 29 May 2009, at the
Hotel El Panama. The registration fee discount is valid until tomorrow,
8 May. Register now at:
http://www.lacnic.net/en/eventos/lacnicxii/registro.html

Accommodation
-----------------
The Hotel Riande Continental, located just a few blocks away from the
hotel where the event will be held, has announced new promotional rates
valid as of today! If you have not yet made your reservations you can
check out this and other accommodation options at the following address:
http://www.lacnic.net/en/eventos/lacnicxii/hospedaje.html

Program
----------
The meeting?s program is available at:
http://www.lacnic.net/en/eventos/lacnicxii/programa.html

Social Events
--------------
New information about the social events has been published. Find out
about the welcome cocktail that will be held on Monday the 25th
sponsored by Tiscali International Network and the social event that
will take place on Wednesday the 27th at a spectacular location.
http://www.lacnic.net/en/eventos/lacnicxii/eventossociales.html

Safety - H1N1 Flu
--------------------
In view of the inquiries we have received from numerous members of the
community and potential attendants to the event regarding the H1N1 FLU,
the event?s organizers would like to inform that the possibility of
suspending or postponing the meeting has not been considered.

We advise those travelling to Panama to take all relevant precautions
that have been made public. We would also like to present the
information provided by the Panamanian Health Ministry regarding the
measures Panama has adopted in relation to this problem, which is
available on the Health Ministry?s website: http://www.minsa.gob.pa/

For updated information, visit the event?s website regularly:
http://www.lacnic.net/en/eventos/lacnicxii/

See you in Panama!

LACNIC XII Organization Committee


LACNICミーティングが再来週に迫っていますが。
新型インフルエンザ(旧名:豚インフルエンザ)の情報が出ています。
参加される方はご注意を。新型インフルエンザのメッカ、メキシコシティからも多数参加のはずです。

ARIN-ppml@May 7, 2009

Date: Thu, 7 May 2009 12:58:50 -0500
Subject: [arin-ppml] general vendor comment


First I apologize to the list in advance if this is not an appropriate place
for this comment.

I am making a point of ending any conversation with a vendor with the
question "What is your roadmap for IPv6. Future purchase and renewal
decisions will be affected.". Almost invariably the answer is "Gee, you are
the first person that has asked. We don't have a roadmap. I will forward
this on to our development team and when there is a need I am sure we will
pursue it."

I would suggest to everyone that we all start requesting IPv6 information
from our vendors, and submit feature requests when appropriate. Hardware
and software vendors are not going to spend money to address this issue
until they see a widespread business case to do so.

Kevin


使用している機器のIPv6機能導入予定を問い合わせよう!という呼びかけ。
返事として既にRFPには長らく記載されていて、機能はある。だれも使わないだけ、という
ちょっと悲しいものも。
ま、IPv6だけで生活してみると色々わかることもあるけどね。

5/07/2009

NZNOG@May 6, 2009

Date: Wed, 6 May 2009 10:34:50 +1000
Subject: [nznog] Wholesale DSL Opportunity


All,

We are looking at expanding our national Australian network into New Zealand, and as such we are looking for a partner to assist us with this.
In the short term, we are looking for Transit and also access to Telecom NZ DSL tails(to be handed off as L2TP sessions over Ethernet preferably).
Handoff location would be Sky Tower.

Is there anyone interested in this opportunity - please contact me off list

Thanks




Ben Cornish
National Network Manager


OZがNZに進出しようとしている?!
国を跨いでのネットワーク敷設って、法令とか監督官庁との兼ね合いとか、大変じゃないのかな?

RIPE-address-policy-wg@May 6, 2009

Date: Wed, 06 May 2009 11:22:53 +0200
Subject: [address-policy-wg] RIPE NCC Now Accepting Requests for IPv6 PI Assignments

[Apologies for duplicate emails.]

Dear Colleagues,

We are pleased to announce that the RIPE NCC now accept requests for
IPv6 Provider Independent (PI) assignments.

This follows the accepted policy proposal 2006-01 "Provider Independent
(PI) IPv6 Assignments for End User Organisations".

The request form and supporting notes are available from the RIPE
Document Store at:
http://www.ripe.net/ripe/docs/ipv6.html

Requests can also be made via the LIR Portal, which is available at:
https://lirportal.ripe.net/

IPv6 PI assignments will come from reserved block 2001:678::/29. You may
want to update your filters.

Regards,

Scott Donald

Registration Services
RIPE NCC


RIPE地域ではIPv6のPI(Provider非依存)アドレスの要望を受け入れ始めました。
IPv6で未来永劫リナンバしたくないよ、という方はRIPE NCCメンバーになってリクエストするといいですよ。

NANOG@May 6, 2009

Date: Wed, 6 May 2009 11:41:55 -0400
Subject: Minnesota Sends List of Blacklisted Gambling Sites to ISPs,
Telcos


With regard to the recent discussion...

"Late last month the Minnesota Department of Public Safety announced
it would require ISPs and telcos to block computers located in the
state from accessing gambling sites, and said non-compliant companies
would be referred to the FCC. Now, the state has sent each ISP and
telco the enclosed blacklist of sites and URLs."

http://www.govtech.com/gt/articles/656645

--
Jeremy L. Gaddis


ミネソタ州の公安局がギャンブルサイトのURLをブラックリストとして各ISPに送付した、と。
実行しないとFCCに報告。
ようやく無秩序な事態から変化が起こるか。

5/06/2009

Gore/ESNOG@May 5, 2009

Date: Tue, 5 May 2009 09:49:00 +0200
Subject: [Gore] GORE-3: participación remota y difusión.


Estimados colegas,

Podemos confirmar que habrá webcasting del GORE-3, a través de la
herramienta ISABEL del DIT-UPM. Se podrá acceder desde la página del
evento (http://www.esnog.net/gore3.html), aunque también la incluyo en
este mensaje:

> mms://stream1.dit.upm.es/isabel

También habilitaremos una sala de chat Jabber para facilitar la
participación remota. Los detalles de acceso estarán disponibles desde
la página del evento, así como las normas de "netiquette" para poder
participar.

Intentaremos que las presentaciones estén disponibles antes de las
charlas, para facilitar el seguimiento.

Estamos a vuestra disposición para cualquier duda o problema que
podais tener.

Saludos,

Voluntarios de ESNOG


Gore-3のリモート参加のお知らせ。
ストリーミングも行うようですね。JANOGもこういう取り組みがあってもいいのになぁ。

NANOG@May 5, 2009

Date: Tue, 5 May 2009 13:38:17 -0700
Subject: DHCPv6 PD chains vs bridging

On Tue, May 05, 2009 at 04:22:04PM -0400, Paul Timmins wrote:
> Sorry for the top post, but as a crazy thought here, why not throw out an
> RA, and if answered, go into transparent bridge mode? Let the sophisticated
> users who want routed behavior override it manually.

Customer premise gear has a 'front side' and a 'back side', and it is
already well ingrained behaviour for 'back-to-back port chaining' to
create a single large bridged network in the home. What is the
customer's anticipated result from front-to-back chaining?

That seems much more reliable a hint to me than conditional behaviour.


DHCPv6 PD is applicable to the ISP customer premise. DHCPv6 PD
'chaining' however is probably only applicable in some promised future
where there are alternative home network medias to Ethernet, or to the
Enterprise where the boundaries drawn in broadcast domains are
administrative in nature and not technical (but still, all automated).

--
David W. Hankins


DHCPv6PD(PrefixDelegation)にするかブリッジ(RA(RouterAdvertise))にするかはやはり悩むポイント。
法人向けサービスならDHCPv6PDかな。個人向けならRAでもいいじゃん?って個人的に思います。