JPNIC News & Views vol.1531【定期号】特集:APNICにおけるRPKIトラストアンカーの移行

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
    __
    /Ｐ▲        ◆ JPNIC News & Views vol.1531【定期号】2017.9.15 ◆
  _/ＮＩＣ
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
---------- PR --------------------------------------------------------
【NTTコミュニケーションズ株式会社】
 ┏・・■複数ISPに発生するDDoS攻撃をまとめて対策しませんか？■・・━┓
 ┃NTT Com回線以外からのDDoS攻撃もまとめて対処
 ┃経験豊富なDDoS対策専門部隊が24時間365日対応！詳しくはこちら↓
 ┗ http://www.ntt.com/business/lp/m_ddos.html
----------------------------------------------------------------------
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆ News & Views vol.1531 です
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

毎月15日(土日祝の場合はその翌日)に発行している定期号では、特集記事の
みならず、業界メンバーのコラムや用語解説、統計などもお届けしています。

本号の特集では、APNICで実施される、リソースPKI (RPKI)において重要な役
割を果たしている、トラストアンカーに関する変更についてお知らせします。
RPKIをご利用になっている方、RPKIの技術に関心のある方は、ぜひご一読く
ださい。

News & Views Columnでは、一般社団法人JPCERTコーディネーションセンター
の西野究氏に、自らのトラブル経験を元にした、オンラインショッピングで
のリスクマネジメントについて語っていただきました。また、インターネッ
ト用語1分解説では、通信の際のフラグメンテーション発生に大きく関係す
る、「MTU」について解説しています。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆ 目次
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

【 1 】特集 「APNICにおけるRPKIトラストアンカーの移行」
【 2 】News & Views Column
       「インターネットショッピングのリスクマネジメント」
         一般社団法人JPCERTコーディネーションセンター  西野究氏
【 3 】インターネット用語1分解説
       「MTUとは」
【 4 】統計資料
         1. JPドメイン名
         2. IPアドレス
         3. 会員数
         4. 指定事業者数
【 5 】イベントカレンダー

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
【 1 】特集 「APNICにおけるRPKIトラストアンカーの移行」
                                                 JPNIC 技術部 木村泰司
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

APNICでは、これまで五つあったリソースPKI (Resource Public Key
Infrastructure; RPKI)のトラストアンカーを一つにまとめるという、大きな
構成変更が行われようとしています。RPKIは、アドレスの分配構造に応じて
リソース証明書を発行する仕組みであるため、その大本に位置付けられるト
ラストアンカーが変わると、下位認証局である国別インターネットレジスト
リ(NIR)のリソース証明書が影響を受ける恐れがあります。本稿では、現在進
められている、トラストアンカーの移行について解説します。


■ RPKIにおけるトラストアンカー

トラストアンカーとは、電子証明書を利用する者が、証明書の有効性を判断
するためにあらかじめ指定しておく認証局の証明書のことで、PKIにおける
電子証明書を使うときには必ず必要になるものです。ある電子証明書が正し
いかどうかを確認するときに、"証明書チェーン"がトラストアンカーに繋が
るかどうかを確認することで、偽の認証局が発行した電子証明書を誤って有
効だとみなさないようにします。証明書チェーンとは、ある証明書を発行し
た認証局の証明書が、他の認証局によって発行されていて、さらにその認証
局証明書が他の認証局によって発行されているような状態の、一連の証明書
を意味しています。

Webのサーバ認証の場合には、まずサーバ証明書の発行元の認証局証明書を
探し、さらにその認証局証明書の発行元を探します。それを繰り返して、証
明書チェーンがトラストアンカーにたどり着くことができれば、有効とみな
すという処理が行われます。トラストアンカーは、Webブラウザなどにデフォ
ルトでインストールされていますが、元来はユーザーが"トラスト"する認証
局証明書を指定します。

RPKIでは、一連の証明書を集める処理を上から行います。はじめに、トラス
トアンカーが発行している認証局証明書を集め、さらにその認証局が発行し
ている証明書を集めます。すべてのトラストアンカーに対してこの処理を行
い、リソース証明書の鍵を使って電子署名されたROA（Route Origin
Authorization)を含めて、すべてのファイルを集めます。特定の証明書を検
証するためにトラストアンカーを使うのではなく、トラストアンカーを基点
としてすべての証明書の検証をします。集めた後に署名検証を行い、有効な
ものだけを抽出します。すなわち、RPKIの場合には、トラストアンカーに関
連する処理に失敗した場合、その証明書チェーンはすべて無効になってしま
います。

IPアドレスなどの番号資源は、IANAを起点として分配されるものですが、IANA
にはトラストアンカーとなる認証局はなく、現在も運用には至っていません。
そのため、RPKI ToolsをはじめとするRPKIのソフトウェアでは、デフォルト
でRIRの認証局証明書が使われています。


■ IPアドレス移転とAPNICにおけるトラストアンカー

五つのRIRが、トラストアンカーとなる認証局を運営していますが、認証局証
明書の数は五つではありません。これはAPNICだけが、IANAから割り振られた
番号資源を含む認証局証明書の他に、他のRIRから移転を通じてAPNIC管理下
になった番号資源のリソース証明書を発行する、認証局証明書を別に設けて
いるためです。つまり、APNICだけで五つの認証局証明書があります。

APNICが五つの認証局証明書を設けている理由は、APNICの技術者によってIETF
SIDR (Secure Inter-Domain Routing) WGでたびたび説明されてきました。IP
アドレスの移転中にもリソース証明書の有効性を保つためには、IANA由来の
番号資源を記載した認証局証明書とは、別に扱う必要があるということです。
SIDR WGではあまり理解を得られず、他のRIRでも行われていないことですが、
ともあれAPNICでは五つの認証局証明書を、トラストアンカーとして提供する
形で運用されてきました。RPKIの利用者は、APNICの五つのトラストアンカー
と、他のRIRの四つのトラストアンカーを指定する必要がありました。


■ グローバルトラストアンカー(GTA)と、RIRによる「Multiple "All
   Resources" Trust Anchors」

本来、IPアドレスのような番号資源の分配は、IANAを大本としたレジストリ
によって行われています。RIR間における番号資源が重複しないことは、IANA
による管理を根拠としています。技術的には、IANAの認証局証明書をトラス
トアンカーとすることで、シンプルかつ分配の構造と一致した形になると考
えられます。

IANAでRPKIの認証局を運用し、トラストアンカーとして提供すること(GTA -
グローバルトラストアンカーと呼ばれています)については、実現までの調整
に時間がかかることが、RIRのRPKIサービス提供の始まった2010年の時点には
分かってきていました。その後、GTAの議論はRIR内だけでなく、NRO (Number
Resource Organization)やIETFの関係者でも行われてきましたが、いまだGTA
は実現していません。

GTAに変わるものとして出てきた案が、「Multiple "All Resources" Trust
Anchors」です。RIRですべての番号資源が記載された認証局証明書を持ち、
これをトラストアンカーとして利用できるように提供するというものです。
IANAからRIRへと番号資源が割り振られ管理するという形に沿った認証局証
明書ではありませんが、これによってトラストアンカーの総数は減ることに
なります。

  RPKI Multiple "All Resources" Trust Anchors Applicability Statement
  https://www.ietf.org/archive/id/draft-rir-rpki-allres-ta-app-statement-01.txt

この認証局証明書が使われるようになると、アドレス移転中の番号資源が記
載されたリソース証明書の有効性が途切れない、つまり、一時的に他のRIRの
リソース証明書を発行することで、移転前と移転後のリソース証明書の有効
性を、重複させることができるようになります。

2017年8月14日にAPNICのブログで、APNICにおける従来の五つのトラストアン
カーから、一つのトラストアンカーにする構造への、移行計画が公表されま
した。

  Transitioning to a single trust anchor
  https://blog.apnic.net/2017/08/14/transitioning-single-rpki-trust-anchor/


■ トラストアンカー移行の影響

トラストアンカーが変わるということは、その認証局によって発行された証
明書、NIRの認証局証明書も変わることになります。証明書は内容を変更する
と、その署名が無効になってしまうため、改めて別の証明書を発行し、前の
証明書の有効期間中に、移行していくということになります。

8月14日のAPNICブログによると、手順は次の通りです。

  2017年9月18日
    従来のIANA由来の番号資源が記載された、トラストアンカーの認証局証
    明書を再発行し、すべての番号資源が記載された状態にします。その下
    位認証局として中間認証局証明書を発行しつつ、IANA由来の番号資源が
    記載された認証局証明書を発行します。

  2017年9月25日
    中間認証局を使って、転入してきた番号資源を扱う認証局証明書を発行
    します。

  2017年9月27日
    従来のトラストアンカーである、四つの認証局証明書に記載された番号
    資源を削除して、再発行します。

  2018年1月8日
    最後に、従来の四つの認証局証明書が利用されないように、認証局証明
    書をリポジトリから削除します。

この手順の中で影響が出るのは、2017年9月27日と2018年1月8日だと考えられ
ます。アジア太平洋地域で、MyAPNICを使ってROAを作成しているアドレスホ
ルダーの方々は、2017年9月18日から技術的な変更が起きることになります。
JPNICのROA Webを使って、リソース証明書の発行とROAの作成を行なっている
方々は、特にこの移行のために手続きを行う必要はありません。JPNICのRPKI
システムも、ROA Webを使って入力されたROAの記載情報に基づいて、自動的
に必要なリソース証明書やROAを発行するためです。しかし、リソース証明書
とROAを含む署名付きファイルの、チェーンの構造が変わります。


■ JPNICのRPKIへの影響と対策

APNICでは、NIRの認証局との連携について技術的なテストを行うことができ
る、テストベッドと呼ばれるRPKIシステムを設けています。JPNICでは、この
テストベッドと連携するRPKIシステムを稼働させており、トラストアンカー
の移行の影響を調査しています。2017年8月下旬に行われた移行テストでは、
移行の前後で連携は継続し、JPNICのリソース証明書を発行しなおすことで、
通常の状態が維持されました。APNIC 44(2017年9月12日から14日に、台湾・
台中にて開催)の間にこの振り返りが行われ、その他のテストを継続していま
す。

最後に、RPKIご利用の上での対策についてまとめます。

 JPNICのROA Webを使われている方:
   手続きの必要はありません。

 JPNICのパブリックROAキャッシュサーバを利用している方:
   設定変更などの対応作業は必要はありません。

 ROAキャッシュサーバを設置している方(RPKI ToolsやRIPE RPKI Validator
 など):
   2017年9月27日以降、2018年1月8日までの間に、トラストアンカーをIANA
   由来のアドレス資源が記載された、認証局証明書(従来の五つの中の一つ)
   にします。APNICでは、ご利用のソフトウェアをアップデートすることで
   対応できると説明されています。もう一つの対策として、JPNICの認証局
   証明書を、トラストアンカーとして指定する方法があります。APNICと
   JPNICのRPKIシステムの連携ができないような場合でも、JPNIC管理下の番
   号資源が記載された、リソース証明書およびROAの検証を行うことができ
   ます。トラストアンカーを指定するためのファイルは、下記からダウン
   ロードできます。

   https://serv.nic.ad.jp/capub/rpki/jpnic-preliminary-ca-s1.tal

RPKIシステムの構造上、従来のトラストアンカーを指定したままで、新たな
構成のリソース証明書とROAが利用できる見込みです。しかし、RPKIにおいて
トラストアンカーの移行が行われるのは初めてです。お気づきの点や、ご質
問やご意見がありましたら、下記までお寄せいただければと思います。

  JPNIC RPKI担当
  rpki-query@nic.ad.jp

JPNICが試験提供を行っているRPKIシステムのご利用については、下記Webペー
ジをご参照ください。みなさまからのご利用をお待ちしています。

   リソースPKI(RPKI)に関する情報提供ページ
   https://www.nic.ad.jp/ja/rpki/


 ┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
 ┃     ◆◇◆◇◆  本特集のご感想をお聞かせください  ◆◇◆◇◆     ┃
 ┃良かった                                                          ┃
 ┃  http://feedback.nic.ad.jp/1531/d74546884fa084f384db19d0bda5c9f5 ┃
 ┃                                                                  ┃
 ┃悪かった                                                          ┃
 ┃  http://feedback.nic.ad.jp/1531/edb132d6df2b4b7bf7196d0508c44938 ┃
 ┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
【 2 】News & Views Column
       「インターネットショッピングのリスクマネジメント」
                   一般社団法人JPCERTコーディネーションセンター 西野究
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

読者の皆さんは日々の生活、特にインターネットを使用したリスクに関して、
どのような考えを持たれていますか。私はインターネット、とりわけインター
ネットショッピングについては、リスクマネジメントの四つの区分での管理
(「回避」「移転」「低減」「保有」）(*1)を参考に、以下のように当ては
め、利用しています。

「回避」…… サイトの安全性と信頼性を確認し、怪しいサイトで購入しない
「移転」…… 補償や保険の利用
「低減」…… 初めて使うサイトでは高額商品を買わない。匿名性の高い決済
             方法を使用する。
「保有」…… 個人情報(住所、氏名、連絡先)は流出するものと考える

このような考えに基づいてインターネットショッピングを利用しているもの
の、補償や保険(移転)に甘えるあまり、サイトの安全性のチェック(回避)が
少しおろそかになっていたなと思う出来事がありました。

先日エアコンを買うために、ネット検索をしていました。そして、ついに他
のどのショッピングサイトより2割も安いサイトにたどりつき、「いいところ
を見つけた！」と心が躍りました。

……偽ショッピングサイトでした。

そのサイトは、補償や保険を適応できないサイトでしたので利用しませんで
したが、サイトの情報をいろいろとチェックすると、偽ショッピングサイト
の特徴(*2)に複数当てはまりました。補償や保険は最後の砦なので、"保険が
使えないから購入しない → よく見ると偽ショッピングサイトだった"という
順序は、褒められたものではありません。偽ショッピングサイトを見抜く知
識が古く、中途半端だったことを痛感して、最新知識にアップデートしてお
きました。

もう一つ、某大手ショッピングサイトを利用した時の話です。欲しかった商
品を、ショッピングサイト内のテナントショップが、極端に安い価格で販売
していました。値段が安すぎるので「大丈夫かな」という心配はあったもの
の、このショッピングサイトはテナントショップで発生した金銭トラブルを
補償する制度がある安心感から、そのテナントショップで注文しました。

……商品は届きませんでした。

注文はキャンセル扱いとなり、金銭的な被害はありませんでしたが、注文と
同時に、個人情報がテナントショップへ提供されてしまいました。

その後、問題のテナントショップを利用された多くの方が、同じような被害
にあったことを、インターネットに書き込みされていました。このことから
考えると、悪意がある(可能性が高い)運営者に、個人情報を提供してしまっ
たことになります。個人情報の流出は日頃から覚悟していましたが、流出し
たことを実感した初めての出来事です。今後、個人情報を悪用される可能性
がありますし、気持ちのいいものではありません。

読者の方は、安全性を見抜く力をお持ちで「回避」について、高いレベルの
方が多いと思います。一方で「移転」「低減」「保有」についてはいかがで
しょうか？ 深く考えていなかったと思われる方は、この機会にご自身のリス
ク管理を見つめ直してみてはいかがでしょうか。

(*1) 独立行政法人情報処理推進機構(IPA)「リスク対応の種類」
     https://www.ipa.go.jp/security/manager/protect/pdca/risk.html

(*2) 警視庁「通信販売サイトでのトラブルにご用心！」
     http://www.keishicho.metro.tokyo.jp/sodan/nettrouble/jirei/net_order_site.html

     消費者庁「インターネット通販トラブル」
     http://www.caa.go.jp/adjustments/internet_trouble/internet.html


■筆者略歴

西野 究(にしの きわむ)

一般社団法人JPCERTコーディネーションセンター 分析センター所属。
企業のサーバインフラやネットワークインフラの提案と構築の経験を経て、
2013年より同センターのシステム管理に従事。
2016年よりInternet Weekプログラム委員を務める。


━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
【 3 】インターネット用語1分解説
         「MTUとは」
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

MTU (Maximum Transmission Unit)とは、ノードが隣接したネットワークへ、
1回の通信で転送可能な最大のデータグラムサイズです(*1)。

TCP/IPの階層モデル(*2)においては、リンク層の通信メディア(Ethernetなど)
の違いによってMTUのサイズが異なるため、その上位のインターネット層にお
けるIPデータグラム(IPパケット)のサイズもこのMTUに合わせて決められま
す。さらにトンネリングなどの追加ヘッダを利用する通信方式を利用する場
合には、増えたヘッダの分だけペイロードを減らす必要があるので、MTUが
ネットワーク層において、より小さな値となります。ある伝送区間でMTUを超
えるサイズのデータグラムを伝送する場合には、ホストやネットワーク機器
が分割して送信可能な単位に変換する対応が必要です。これをフラグメンテー
ションと呼びます。

また、送信元と送信先のネットワークが離れている場合は、単一の伝送路で
は無いため、途中にMTUが異なる機器・媒体が介在している可能性がありま
す。送信元ホストから送信先ホストへの経路中で、中継するネットワーク機
器が分割しないで送信できるMTUを探す技術を、Path MTU Discovery(経路MTU
探索)(*3)(*4)と呼びます。

IPv4ではMTUを超えるパケットについて経路の途中にあるルータが分割をする
ことがありますが、IPv6では経路の途中では分割をしない仕様となっており、
Path MTU Discoveryにて送信可能なMTUサイズを確認することが重要となりま
す。

TCPでは通信を始める際、MTUからTCPヘッダ・IPヘッダのサイズを除いたMSS
(Maximum Segment Size)(*5)を計算し、ホスト間で伝送可能なデータの最大
サイズを確認してからホストが適宜データのフラグメンテーションを実施し、
送信する仕組みがあります。一方、UDPではこの仕組みが無いため、大きな
データが送られると、経路途中のMTUに応じてフラグメンテーションが発生し
ます。発生したフラグメンテーションについて適切に対応できない場合は、
通信に障害が起こるときがあります。

(*1) RFC 791: INTERNET PROTOCOL
     https://tools.ietf.org/html/rfc791

(*2) RFC 1122: Requirements for Internet Hosts -- Communication Layers
     https://tools.ietf.org/html/rfc1122

(*3) RFC 1191: Path MTU Discovery
     https://tools.ietf.org/html/rfc1191

(*4) RFC 8201: Path MTU Discovery for IP version 6
     https://tools.ietf.org/html/rfc8201

(*5) RFC 6691: TCP Options and Maximum Segment Size (MSS)
     https://tools.ietf.org/html/rfc6691


■ 参考

   RFC 1983: Internet Users' Glossary
   https://tools.ietf.org/html/rfc1983


━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
【 4 】統計資料
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

1. JPドメイン名

o 登録ドメイン数(2017年4月～2017年9月)
--------------------------------------------------------------------------------------------
日付｜  AD  AC    CO    GO   OR    NE   GR   ED   LG   GEO   GA     GJ     PA   PJ   TOTAL
--------------------------------------------------------------------------------------------
  4/1｜260 3589 394523 586 34202 13742 6349 5176 1882 2295 878628 113398  9026 2408 1466064
  5/1｜259 3594 395501 581 34288 13708 6323 5185 1882 2293 880968 112884  9126 2394 1468986
  6/1｜257 3597 396756 578 34385 13698 6302 5195 1883 2287 883182 112272  9223 2367 1471982
  7/1｜257 3599 397897 580 34511 13675 6279 5212 1883 2283 885942 111957  9364 2384 1475823
  8/1｜259 3601 398752 582 34587 13652 6270 5220 1883 2278 888414 111315  9381 2381 1478575
  9/1｜259 3602 399816 584 34693 13618 6254 5237 1883 2273 891623 110751  9395 2382 1482370
--------------------------------------------------------------------------------------------

 GA：汎用ドメイン名 ASCII(英数字)
 GJ：汎用ドメイン名 日本語
 PA：都道府県型ドメイン名 ASCII(英数字)
 PJ：都道府県型ドメイン名 日本語


2. IPアドレス

o JPNICからのIPv4アドレス割り振りとJPNICへのIPv4アドレス返却ホスト数
  (2017年3月～2017年8月)
------------------------------------------
  月 |   割振   |   返却   | 現在の総量
------------------------------------------
   3 |    11264 |    14336 |   93102536
   4 |     9216 |        0 |   93111752
   5 |     5120 |        0 |   93116872
   6 |     4096 |        0 |   93120968
   7 |     6144 |     2048 |   93125064
   8 |     2048 |        0 |   93127112
------------------------------------------


□統計情報に関する詳細は → https://www.nic.ad.jp/ja/stat/


3. 会員数  ※2017年9月14日 現在

 ---------------------
  会員分類  | 会員数 |
 ---------------------
  S会員     |      3 |
  A会員     |      1 |
  B会員     |      2 |
  C会員     |      2 |
  D会員     |     94 |
  非営利会員|     10 |
  個人推薦  |     33 |
  賛助会員  |     41 |
 ---------------------
  合計      |    186 |
 ---------------------

□会員についての詳細は → https://www.nic.ad.jp/ja/member/list/


4. 指定事業者数  ※2017年9月13日 現在

   IPアドレス管理指定事業者数           422


━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
【 5 】イベントカレンダー
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

  2017.9.14(木)～15(金)        APTLD72 Members Meeting (Tbilisi,
                               Georgia)
  2017.9.17(日)～22(金)        LACNIC 28/LACNOG 2017
                               (Montevideo, Uruguay)
  2017.9.26(火)                Security Day Fall 2017 大阪 [後援] /
                               第16回迷惑メール対策カンファレンス
                               [後援] (大阪、ナレッジキャピタル・カン
                               ファレンスルーム)

  2017.9.27(水)～29(金)        Security Day Fall 2017 東京 [後援]
                               (東京、JPタワーホール＆カンファレンス)
  2017.9.29(金)                第17回迷惑メール対策カンファレンス
                               [後援] (東京、JPタワーホール＆カンファ
                               レンス)
 ---------------------------------------------------------------------
  2017.10.2(月)～6(金)         JPNIC技術セミナー(東京、JPNIC会議室)
  2017.10.2(月)～4(水)         NANOG 71 (San Jose, U.S.A.)
  2017.10.4(水)                58th CENTR General Assembly (Brussels,
                               Belgium)
  2017.10.5(木)～6(金)         ARIN 40 (San Jose, U.S.A.)
  2017.10.19(木)～20(金)       初心者向け「インターネット入門」フォ
                               ローアップ研修(東京、JPNIC会議室)
  2017.10.22(日)～26(木)       RIPE 75 (Dubai, United Arab Emirates)
  2017.10.28(土)～11.3(金)     ICANN60 (Abu Dhabi, United Arab
                               Emirates)
 ---------------------------------------------------------------------
  2017.11.12(日)～17(金)       IETF 100
                               (Singapore, Republic of Singapore)
  2017.11.28(火)～12.1(金)     Internet Week 2017 (東京、ヒューリック
                               ホール＆ヒューリックカンファレンス)


     ～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～
       わからない用語については、【JPNIC用語集】をご参照ください。
             https://www.nic.ad.jp/ja/tech/glossary.html
     ～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
■■■■■  JPNICの活動はJPNIC会員によって支えられています  ■■■■■
  :::::  会員リスト  ::::: https://www.nic.ad.jp/ja/member/list/
  :::: 会員専用サイト :::: https://www.nic.ad.jp/member/ (PASSWORD有)
□┓ ━━━  N e w s & V i e w s への会員広告無料掲載実施中 ━━━┏□
┗┛          お問い合わせは  jpnic-news@nic.ad.jp  まで          ┗┛
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 JPNIC News & Views vol.1531 【定期号】

 ＠ 発行  一般社団法人 日本ネットワークインフォメーションセンター
          101-0047 東京都千代田区内神田3-6-2 アーバンネット神田ビル4F
 ＠ 問い合わせ先  jpnic-news@nic.ad.jp
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
            本メールを転載・複製・再配布・引用される際には
        https://www.nic.ad.jp/ja/copyright.html をご確認ください
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
登録・削除・変更   https://www.nic.ad.jp/ja/mailmagazine/
バックナンバー     https://www.nic.ad.jp/ja/mailmagazine/backnumber/
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
■■■■■     News & ViewsはRSS経由でも配信しています！    ■■■■■
::::: https://www.nic.ad.jp/ja/mailmagazine/backnumber/index.xml :::::
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣

■■◆                          ＠ Japan Network Information Center
■■◆                                     ＠  https://www.nic.ad.jp/
■■

Copyright(C), 2017 Japan Network Information Center
このページを評価してください
