Network Working Group                                          E. Vyncke
Request for Comments: 5514                                 Cisco Systems
Category: Experimental                                      1 April 2009
        
Network Working Group                                          E. Vyncke
Request for Comments: 5514                                 Cisco Systems
Category: Experimental                                      1 April 2009
        

IPv6 over Social Networks

基于社交网络的IPv6

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.

版权所有(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和IETF信托在本文件出版之日生效的与IETF文件有关的法律规定的约束(http://trustee.ietf.org/license-info). 请仔细阅读这些文件,因为它们描述了您对本文件的权利和限制。

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 Internet添加数百万个IPv6主机。本文档包括有关通过社交网络寻址和传输IPv6的章节。已经开发了一个工作原型。

1. Introduction
1. 介绍

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,并向Internet添加数千个IPv6路由器。

2. Architecture
2. 建筑学

With IPv6 over Social Network (IPoSN):

通过社交网络(IPoSN)使用IPv6:

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

在社交网络上,用户希望拥有多个朋友、合作伙伴或与其他用户的关系。因此,可以预期在这些用户之间存在一个高度网状的网络。这将提供良好的IPv6连接,因为每个用户(IPoSN路由器)将通过IPv6连接到他/她的所有朋友(IPoSN邻居路由器)。

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网络有两个影响:

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. 帐户所有者必须明确地“运行CPU”,以便转发或接收IPv6数据包;这是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. 在这样的网络上,两个节点之间的延迟可能非常高,并且必须修改计时器(尤其是路由计时器;参见第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。

2.1. Addressing
2.1. 寻址

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.

在每个接口上,将通过将SNA标识附加到fe80::/64前缀来生成链路本地地址。

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

例如,以下是为用户620147832生成的两个IPoSN地址(十六进制为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

2.2. Address Translation
2.2. 地址转换

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 Internet之间传递(和转换)IPv6包。网关和NAT功能超出了本文档的范围。

3. Choice of IGP
3. 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],它相对不受抖动的影响,并且不依赖于向所有相邻路由器发送泛洪消息。OSPFv3[RFC5340]不应在IPoSN上使用。

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

用于延迟容忍网络的路由协议可用于IPoSN。

4. Working Prototype
4. 工作原型

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-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的高延迟跟踪路由:

 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-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
5. 安全考虑

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数据包的每个网页上实现速率限制。

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网关上还应安装速率限制器。

6. Acknowledgments
6. 致谢

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.

非常感谢Facebook上IPv6[IPv6overFacebook]应用程序的所有首批用户:伊莎贝尔·德豪斯、伊夫·赫托格斯、托马斯·克南、西蒙·莱宁和其他许多人。

7. References
7. 工具书类
7.1. Normative References
7.1. 规范性引用文件

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

[RFC2080]Malkin,G.和R.Minnear,“IPv6的RIPng”,RFC20801997年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]Campbell,B.,Rosenberg,J.,Schulzrinne,H.,Huitema,C.,和D.Gurle,“即时消息的会话启动协议(SIP)扩展”,RFC 34282002年12月。

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

[RFC5340]Coltun,R.,Ferguson,D.,Moy,J.,和A.Lindem,“IPv6的OSPF”,RFC 53402008年7月。

7.2. Informative References
7.2. 资料性引用

[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

Eric Vyncke Cisco Systems De Kleetlaan 6a Diegem 1831比利时

   Phone: +32 2 778 4677
   EMail: evyncke@cisco.com
        
   Phone: +32 2 778 4677
   EMail: evyncke@cisco.com