[要約] RFC 5514は、ソーシャルネットワーク上でのIPv6の利用に関するガイドラインです。その目的は、ソーシャルネットワークプラットフォームでIPv6の採用を促進し、IPv6の普及を支援することです。
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 処理は、アカウント所有者が Web アクションを使用して明示的に実行する必要があります。 このアクションにより、ルーターの 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 がすべての運用を詳述する機会です (1 つの目標は教育です)。
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:face:b00c::/64 など) の後に SNA 識別が続きます。 このアドレスはループバック アドレスであるため、プレフィックス長は常に /128 になります。 すべての SNA ユーザーに同じ /64 プレフィックスが使用されるため、すべて同じ /64 ネットワークの一部として表示されます。
On each interface, the link-local address will be generated by appending the SNA identification to the fe80::/64 prefix.
各インターフェイスで、fe80::/64 プレフィックスに SNA ID を追加することにより、リンクローカル アドレスが生成されます。
For example, here are two IPoSN addresses generated for the user 620147832 (this is 0x24f6b478 in hexadecimal):
たとえば、ユーザー 620147832 に対して生成された 2 つの IPoSN アドレスは次のとおりです (16 進数では 0x24f6b478 です)。
o Global: 2001:db8:face:b00c::24f6:b478/128
o グローバル: 2001:db8:face: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) を実装し、少なくとも 1 つの「エッジ」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) で見られるように、IPv6 パケットの伝播は、ユーザーが自分の SNA アカウントにリンクされた IPoSN アプリケーションをアクティブにした場合にのみ発生します。したがって、伝播遅延は、インターネット フィッシュボーンではマイクロ秒と比較して、時間または日単位で測定されます。 さらに、ユーザーごとに 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.
実用的なプロトタイプが著者によって開発されており、自由に利用できます: IPv6 over Facebook Social Network [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
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
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.
悪意のあるユーザーが Web ツールを使用して毎秒 ping 診断を要求すると、サービス拒否 (パケット フラッディング) が発生する可能性があります。 したがって、実装では、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