[Joke-RFC] RFC5514 IPv6 over ソーシャルネットワーク

はじめに

• この文書は RFC5514 を勉強と好奇心のため適当に訳したものです。
• 翻訳の正確さは全く保証しません。
• 誤字誤訳等の指摘はいつでも大歓迎です。

IPv6 over Social Networks（IPv6 over ソーシャルネットワーク）

• Network Working Group
• Request for Comments: 5514
• Category: Experimental

• E. Vyncke
• Cisco Systems
• 1 April 2009

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.

このメモでは、インターネットコミュニティのための実験的なプロトコルを定義している。
このメモは、いかなる種類のインターネット標準も規定しない。
改善のための議論と提案が望まれる。
このメモの配布は無制限である。

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   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.

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のアドレス指定と転送に関するセクションが含まれている。
また、実用的なプロトタイプを開発した。

1. Introduction（はじめに）

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プロトコルは何年も前から知られているが、すべてのホストがIPv6を使用しているわけではなく（少なくとも2009年3月現在）、ほとんどのネットワークユーザーは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ルータを増設する方法について説明する。

2. Architecture（アーキテクチャ）

With IPv6 over Social Network (IPoSN):

• Every user is a router with at least one loopback interface;

• Every friend or connection between users will be used as a point-to-point link.

IPv6 over Social Network（IPoSN）とは。

• 全てのユーザは、少なくとも1つのループバックインタフェースを持つルータである。

• すべての友人またはユーザー間の接続は、「ポイント・ツー・ポイント」リンクとして使用される。

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ルーター）はすべての友人（IPoSN近隣ルーター）にIPv6接続されるため、これは良好な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.

いくつかのソーシャルネットワークアプリケーション（SNA）では、プラグインや他のアプリケーションをソーシャルネットワークとマッシュアップさせることができる。
これらのアプリケーションは、ユーザーの代わりに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)

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.

1. アカウント所有者は、IPv6 パケットを転送したり受信したりするために明示的に「CPU を実行」する必要がある。これは IPoSN がそのすべての操作を詳述する機会である（一つの目的は教育である）。

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は使うべきではない(SHOULD NOT)。

2.1. Addressing（アドレッシング）

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では、すべてのユーザーがユニークな数値の識別情報を持っている。
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の識別子を付加してリンクローカルアドレスを生成することになる。

For example, here are two IPoSN addresses generated for the user 620147832 (this is 0x24f6b478 in hexadecimal):

• Global: 2001:db8:face:b00c::24f6:b478/128

• Link-local: fe80::24f6:b478/64

例えば，ユーザ 620147832（これは16進数で 0x24f6b478）に対して生成された2つのIPoSNアドレスは以下のとおりである。

• グローバル: 2001:db8:face:b00c::24f6:b478/128 (これは16進数で 0x24f6b478)

• リンクローカル：fe80::24f6:b478/64

2.2. Address Translation（アドレス変換）

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-to-IPv6 Non-Carrier Grade NAT（NCGN）を実装し、IPoSNと実際のIPv6インターネット間でIPv6パケットの通過（および変換）に使用するアカウントを持つ少なくとも1人の「エッジ」SNAユーザーにリンクする必要がある。
ゲートウェイおよびNAT機能は、本ドキュメントの範囲外である。

3. Choice of IGP（IGPの選択）

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] を実装するべきである(SHOULD)。
OSPFv3 [RFC5340] はIPoSN上で使用されるべきではない(SHOULD NOT)。

Routing protocols for Delay Tolerant Networks MAY be use for IPoSN.

遅延耐性ネットワークのためのルーティングプロトコルは、IPoSNに使用してもよい。

4. Working Prototype（動作確認したプロトタイプ）

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):

• Packet rate: 160 packets per minute

• Number of nodes: 3800

• Largest FIB: 1352

• NAT66 packet counters:

  • to the Internet: 8,500

  • from the Internet: 53,000

2009年3月26日時点（標準実装前）の統計データを一部紹介する：

• パケットレート 160パケット/分

• ノード数 3800

• 最大FIB：1352

• NAT66のパケットカウンタ。

  • インターネットへ 8,500

  • インターネットから 53,000

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

5. Security Considerations（セキュリティに関する考察）

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.

ユーザーは送信内容を実際に制御することができないので（彼らはよく制御されたウェブインタフェースを介してIPv6パケットを送信する）、なりすましパケットを送信する脅威はない。
唯一の例外は、実際のインターネットからのパケットを受信できるNAT66ゲートウェイである。したがって、NAT66ゲートウェイは、アンチスプーフィングを実装しなければならない(MUST)。

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ツールを使って1秒ごとにPing診断を要求した場合、サービス拒否（パケットフラッディング）が発生する可能性がある。
したがって，IPv6 パケットを生成できる各ウェブページにレート制限を実装すべきである(SHOULD)．

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ゲートウェイにもレートリミッターを実装すべきである(SHOULD)。

6. Acknowledgments（謝辞）

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.

IPv6 over Facebook [IPv6overFacebook] アプリケーションの最初のユーザの皆様に感謝します。
Isabelle Dehousse, Yves Hertoghs, Thomas Kernen, Simon Leinen, とその他の方々。

7. References

7.1. Normative References

   [RFC2080]           Malkin, G. and R. Minnear, "RIPng for IPv6",
                       RFC 2080, January 1997.

   [RFC3428]           Campbell, B., Rosenberg, J., Schulzrinne, H.,
                       Huitema, C., and D. Gurle, "Session Initiation
                       Protocol (SIP) Extension for Instant Messaging",
                       RFC 3428, December 2002.

   [RFC5340]           Coltun, R., Ferguson, D., Moy, J., and A. Lindem,
                       "OSPF for IPv6", RFC 5340, July 2008.

7.2. Informative References

   [IPv6overFacebook]  Vyncke, E., "IPv6 over the Facebook Social
                       Network", <http://apps.facebook.com/ipoverfb/>.

Author's Address

   Eric Vyncke
   Cisco Systems
   De Kleetlaan 6a
   Diegem  1831
   Belgium

   Phone: [phone]
   EMail: [e-mail]