Network Working Group E. Vyncke
Request for Comments: 5514 Cisco Systems
Category: Experimental 1 April 2009
IPv6 over Social Networks
Status of This Memo
このメモのステータス
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。それはどんな種類のインターネット標準を指定しません。改善のための議論や提案が要求されています。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書では、BCP 78と、この文書（http://trustee.ietf.org/license-info）の発行日に有効なIETFドキュメントに関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
Abstract
抽象
There is a lack of IPv6 utilization in early 2009; this is partly linked to the fact that the number of IPv6 nodes is rather low. This document proposes to vastly increase the number of IPv6 hosts by transforming all Social Networking platforms into IPv6 networks. This will immediately add millions of IPv6 hosts to the existing IPv6 Internet. This document includes sections on addressing and transport of IPv6 over a Social Network. A working prototype has been developed.
2009年初頭でのIPv6利用の欠如があります。これは、部分的にIPv6ノードの数がかなり低いという事実にリンクされています。この文書では、大幅にIPv6ネットワークにすべてのソーシャルネットワーキングプラットフォームを変換することにより、IPv6ホストの数を増やすことを提案します。これはすぐに既存のIPv6インターネットへのIPv6ホストの何百万人を追加します。この文書では、ソーシャルネットワーク上でのアドレス指定とIPv6の輸送上のセクションが含まれています。ワーキングプロトタイプが開発されました。
While the IPv6 protocols are well-known for years, not every host uses IPv6 (at least in March 2009), and most network users are not aware of what IPv6 is or are even afraid by IPv6 because it is unknown.
IPv6プロトコルは何年も、よく知られているが、必ずしもすべてのホストは（少なくとも2009年3月）IPv6を使用し、ほとんどのネットワークユーザーは、IPv6が何であるかを認識していないか、それが不明であるためのIPv6でさえ恐れています。
On the other hand, Social Networks (like Facebook, LinkedIn, etc.) are well-known by users and the usage of those networks is huge.
一方、（などのFacebook、LinkedInの、など）ソーシャルネットワークはユーザーがよく知られており、これらのネットワークの利用は巨大です。
This document describes how to leverage Social Networks in order to make more people aware of IPv6 and to add several thousands of IPv6 routers to the Internet.
この文書は、IPv6を意識し、より多くの人々を作るためにソーシャルネットワークを活用し、インターネットへのIPv6ルータの数千を追加する方法について説明します。
With IPv6 over Social Network (IPoSN):
ソーシャルネットワーク上のIPv6（IPoSN）の場合：
o Every user is a router with at least one loopback interface;
Oすべてのユーザーには、少なくとも一つのループバックインターフェイスを備えたルータです。
o Every friend or connection between users will be used as a point-to-point link.
Oユーザー間のすべての友人や接続はポイントツーポイントリンクとして使用されます。
On social networks, users want to have multiple friends, partners, or relations with other users. Therefore, it can be expected that there is a heavily meshed network among these users. This will provide for good IPv6 connectivity because each user (IPoSN router) will be IPv6 connected to all his/her friends (IPoSN neighbor routers).
ソーシャルネットワークでは、ユーザーが複数の友人、パートナー、または他のユーザーとの関係を持っていると思います。したがって、これらのユーザーの間で頻繁にメッシュネットワークがあることを期待することができます。各ユーザー（IPoSNルーター）がIPv6はすべての彼/彼女の友人（IPoSNネイバールータ）に接続されますので、これは良いIPv6接続を提供します。
Several Social Network Applications (SNAs) allow for plug-ins or for other applications to be mashed with the social network. Those applications can then generate IPv6 packets on the behalf of the users. Those packets can then be transferred hop by hop, or rather user by user, over the mashed SNA/IPv6, until they reach their destination.
いくつかのソーシャルネットワークアプリケーション（SNAS）プラグインまたはソーシャルネットワークでマッシュする他のアプリケーションを可能にします。これらのアプリケーションは、ユーザーに代わってIPv6パケットを生成することができます。彼らは彼らの目的地に到達するまで、これらのパケットはその後、マッシュポテトSNA / IPv6の上、ホップ、またはむしろ、ユーザーによるユーザーによってホップを転送することができます。
The usual policy of an SNA is to only allow the account owner to modify an account. Therefore, the IPv6 processing of a packet received by an SNA account must be explicitly executed by the account owner using a web action; this action will give the router CPU a nudge to process all received IPv6 packets. This behavior has two impacts on the IPv6 network:
SNAの通常のポリシーは、アカウント所有者はアカウントを変更できるようにすることです。したがって、SNAアカウントで受信したパケットのIPv6処理を明示的にウェブアクションを使用してアカウント所有者によって実行されなければなりません。このアクションは、ルータのCPUをすべて受信したIPv6パケットを処理するためにナッジを与えるだろう。この動作は、IPv6ネットワーク上の2つの影響があります。
1. the account owner must explicitly 'run the CPU' in order to forward or to receive IPv6 packets; this is an opportunity for IPoSN to detail all its operation (one goal is education)
1.アカウントの所有者が明示的に転送するか、IPv6パケットを受信するために、「CPUを実行する」必要があります。これは細部にIPoSNのための機会であるそのすべての操作は、（一つの目標は、教育です）
2. the latency between two nodes over such a network can be very high, and timers (especially the routing timers; see Section 3) will have to be modified.
2.このようなネットワークを介して2つのノード間の待ち時間が非常に高くすることができ、タイマー（特にルーティングタイマーは、セクション3を参照）を変更しなければなりません。
A latency of several hours has an impact on the transport protocols. UDP SHOULD be used, and TCP SHOULD NOT be used.
数時間の待ち時間は、トランスポートプロトコルに影響を与えます。 UDPを使用する必要があり、TCPを使用しないでください。
In SNA, all users have a unique numerical identification. Assuming that there are less than 2**64 users on the SNA, the IPv6 global address of the router loopback will be a /64 prefix (such as 2001: db8:face:b00c::/64) followed by the SNA identification. As this address is a loopback address, the prefix length will always be /128. As the same /64 prefix is used for all SNA users, they will all appear as being part of the same /64 network.
SNAでは、すべてのユーザーが一意の数値IDを持っています。 SNA上の2人の未満** 64のユーザが存在すると仮定すると、ルータのループバックのIPv6グローバルアドレスがあろう/ 64プレフィックス（例えば2001のように：DB8：顔：b00c :: / 64）SNA識別続きます。このアドレスはループバックアドレスであるとして、プレフィックス長は常に/ 128になります。同じ/ 64プレフィックスがすべてのSNAのユーザーのために使用されているので、それらはすべて同じ/ 64ネットワークの一部として表示されます。
On each interface, the link-local address will be generated by appending the SNA identification to the fe80::/64 prefix.
各インターフェイス上で、リンクローカルアドレスは、FE80 :: / 64プレフィックスにSNA識別情報を付加することにより生成されます。
For example, here are two IPoSN addresses generated for the user 620147832 (this is 0x24f6b478 in hexadecimal):
例えば、ここでユーザ620147832（これは16進数で0x24f6b478である）のために生成された二IPoSNアドレスは、次のとおり
o Global: 2001:db8:face:b00c::24f6:b478/128
Oグローバル：2001：DB8：顔：b00c :: 24f6：b478 / 128
o Link-local: fe80::24f6:b478/64
Oリンクローカル：FE80 :: 24f6：b478 / 64
With the choice of the example prefix for all global addresses, an IPv6-to-IPv6 Non-Carrier Grade NAT (NCGN) must be implemented and linked to at least one 'edge' SNA user whose account will be used to pass (and translate) IPv6 packets between IPoSN and the real IPv6 Internet. The gateway and NAT functions are out of scope of the present document.
すべてのグローバルアドレスのための一例プレフィックスの選択により、IPv6のツーのIPv6非キャリアグレードNAT（NCGN）を実装する必要があり、そのアカウント渡すために使用される少なくとも一つの「エッジ」SNAユーザーにリンクされている（と翻訳しますIPoSNと実際のIPv6インターネットとの間に）IPv6パケット。ゲートウェイとNAT機能は、本文書の範囲外です。
As seen in the architecture section (Section 2, the propagation of IPv6 packets only happens when a user activates the IPoSN application linked to his/her SNA account. Therefore, propagation delays are measured in hours or days compared to microseconds over the Internet fishbone. Moreover, the jitter is also very high as different users have different habits regarding the use of SNA.
アーキテクチャセクション（セクション2に見られるように、ユーザが彼/彼女のSNAアカウントにリンクされているIPoSNアプリケーションを起動すると、IPv6パケットの伝播にのみ発生します。そのため、伝搬遅延は、インターネットフィッシュボーンの上にマイクロ秒に比べて、数時間または数日で測定されています。別のユーザーがSNAの使用に関するさまざまな習慣を持っているようにまた、ジッタも非常に高いです。
IPoSN SHOULD implement RIPng [RFC2080], which is relatively immune to jitter and does not rely on flooding messages to all neighboring routers. OSPFv3 [RFC5340] SHOULD NOT be used over IPoSN.
IPoSNは、ジッタに比較的耐性であり、すべての隣接ルータにフラッディングメッセージに依存していないのRIPng [RFC2080]を、実装する必要があります。 OSPFv3は[RFC5340]はIPoSNは使用してはいけません。
Routing protocols for Delay Tolerant Networks MAY be use for IPoSN.
遅延耐性ネットワークのルーティングプロトコルは、IPoSNのために使用してもよい（MAY）。
A working prototype has been developed by the author and is freely available: IPv6 over Facebook Social Network [IPv6overFacebook]. It uses the LAMP architecture.
ワーキングプロトタイプは、著者によって開発され、自由に利用できるされていますFacebookのソーシャルネットワークを介したIPv6が[IPv6overFacebook]。それはLAMPアーキテクチャを採用しています。
Some statistics as of March 26, 2009 (pre-standard implementation of course):
2009年3月26日（もちろん事前に標準実装）のようないくつかの統計情報：
o Packet rate: 160 packets per minute
Oパケット率：毎分160個のパケット
o Number of nodes: 3800
ノードのO数：3800
o Largest FIB: 1352
O最大のFIB：1352
o NAT66 packet counters:
O NAT66パケットカウンタ：
* to the Internet: 8,500
*インターネットへ：8500
* from the Internet: 53,000
*インターネットから：53000
The extreme value of the latency makes network operation and trouble-shooting quite interesting.
レイテンシーの極端な値は、ネットワークの運用とトラブルシューティングは非常に興味深いです。
A high latency ICMP echo request/reply:
高遅延ICMPエコー要求/応答：
2009-02-24 10:23:01: Ping to 2001:db8:face:b00c::2a42:4346 2009-02-26 21:52:24: Got a PING reply from 2001:db8:face:b00c::2a42:4346
2009年2月24日午前10時23分01秒：Pingの2001：DB8：顔：b00c :: 2a42：4346 2009-02-26 21時52分24秒：2001からPING応答を得た：DB8：顔：b00c :: 4346：2a42
A high latency UDP-based traceroute:
高レイテンシーUDPベースのtraceroute：
2009-02-25 13:38:05: Traceroute to 2001:db8:face:b00c::21ca:5ab1 2009-02-25 13:40:41: 2001:db8:face:b00c::28ef:7c60, intermediate node 2009-02-25 18:04:21: 2001:db8:face:b00c::312a:c8cb, intermediate node 2009-02-26 00:55:32: 2001:db8:face:b00c::2707:a4a0, intermediate node 2009-02-26 00:55:33: 2001:db8:face:b00c::1e21:338b, intermediate node 2009-02-26 00:56:25: 2001:db8:face:b00c::4c13:9577, intermediate node 2009-02-26 07:44:17: 2001:db8:face:b00c::5422:2f57, intermediate node 2009-02-27 10:16:45: 2001:db8:face:b00c::5422:2f57, intermediate node 2009-02-27 10:16:45: 2001:db8:face:b00c::2726:8ed8, intermediate node 2009-03-01 15:41:50: 2001:db8:face:b00c::21ca:5ab1, destination reached 2009-03-01 16:22:54: 2001:db8:face:b00c::3e22:92b9, intermediate node
2009年2月25日午後1時38分05秒：2001へのTraceroute：DB8：顔：b00c :: 21ca：5ab1 2009-02-25午前13時40分41秒：2001：DB8：顔：b00c :: 28ef：7c60、中間ノード2009-02-25午後06時04分21秒：2001：DB8：顔：b00c :: 312A：c8cb、中間ノード2009-02-26午後12時55分32秒：2001：DB8：顔：b00c :: 2707：a4a0中間ノード2009-02-26夜十二時55分33秒：2001：DB8：顔：b00c :: 1E21：338B、中間ノード2009-02-26 0時56分25秒：2001：DB8：顔：b00c :: 4c13 ：9577、中間ノード2009-02-26 7時44分17秒：2001：DB8：顔：b00c :: 5422：2f57、中間ノード2009-02-27 10時16分45秒：2001：DB8：顔：b00c： ：5422：2f57、中間ノード2009-02-27 10時16分45秒：2001：DB8：顔：b00c :: 2726：8ed8、中間ノード2009年3月1日夜03時41分50秒：2001：DB8：顔： b00c :: 21ca：5ab1、先に2009年3月1日午前16時22分54秒に達し：2001：DB8：顔：b00c :: 3e22：92b9を、中間ノード
As the users cannot really control what they are sending (they send IPv6 packets through a well-controlled web interface), there is no threat to send spoofed packets. The only exception is at the NAT66 gateway where packets from the real Internet can be received; therefore, NAT66 gateway MUST implement anti-spoofing.
ユーザーが本当に彼らが（彼らはよく制御されたWebインターフェイスを介してIPv6パケットを送信する）送信するかを制御することができないため、偽装されたパケットを送信するために何の脅威はありません。唯一の例外は、実際のインターネットからのパケットを受信することができるNAT66ゲートウェイです。従って、NAT66ゲートウェイは、アンチスプーフィングを実装しなければなりません。
Denial of service (packet flooding) can happen if a malicious user uses a web tool to request a ping diagnostic every second. Therefore, implementation SHOULD implement a rate limit on each web page that can generate an IPv6 packet.
悪意のあるユーザーが、診断のpingを毎秒を要求するWebツールを使用している場合、サービス拒否（パケットフラッディング）が発生する可能性があります。そのため、実装は、IPv6パケットを生成することができ、各Webページ上のレート制限を実装する必要があります。
Denial of service (packet flooding) can also happen at the NAT66 gateway from the real Internet. A rate limiter SHOULD also be implemented at the NAT66 gateway.
サービス拒否（パケットフラッディング）も、実際のインターネットからNAT66ゲートウェイで発生することができます。レートリミッタはまた、NAT66ゲートウェイで実施されるべきです。
Many thanks to all first users of the IPv6 over Facebook [IPv6overFacebook] application: Isabelle Dehousse, Yves Hertoghs, Thomas Kernen, Simon Leinen, and so many others.
イザベルDehousse、イヴHertoghs、トーマス・ケルネン、サイモンLeinen、および他の多くの人々：Facebookの[IPv6overFacebook]アプリケーション経由のIPv6のすべての最初のユーザーに感謝します。
[RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, January 1997.
[RFC2080]マルキン、G.およびR. Minnear、 "IPv6のためのRIPng"、RFC 2080、1997年1月。
[RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002.
[RFC3428]キャンベル、B.、ローゼンバーグ、J.、Schulzrinneと、H.、のHuitema、C.、およびD. Gurle、 "インスタントメッセージングのためのセッション開始プロトコル（SIP）拡張子"、RFC 3428、2002年12月。
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, July 2008.
[RFC5340] Coltun、R.、ファーガソン、D.、モイ、J.、およびA. Lindem、 "IPv6のためのOSPF"、RFC 5340、2008年7月。
[IPv6overFacebook] Vyncke, E., "IPv6 over the Facebook Social Network", <http://apps.facebook.com/ipoverfb/>.
[IPv6overFacebook] Vyncke、E.、 "Facebookのソーシャルネットワーク上のIPv6"、<http://apps.facebook.com/ipoverfb/>。
Author's Address
著者のアドレス
Eric Vyncke Cisco Systems De Kleetlaan 6a Diegem 1831 Belgium
エリックVynckeシスコシステムズKleetlaan図6aディーゲム1831ベルギー
Phone: +32 2 778 4677 EMail: evyncke@cisco.com
電話：+32 2 778 4677 Eメール：evyncke@cisco.com