IPv6 over Social Networks
RFC 5514

Document Type RFC - Experimental (April 2009; Errata)
Last updated 2013-03-02
Stream ISE
Formats plain text pdf html bibtex
Stream ISE state (None)
Consensus Boilerplate Unknown
Document shepherd No shepherd assigned
IESG IESG state RFC 5514 (Experimental)
Telechat date
Responsible AD (None)
Send notices to (None)
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.

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.

Vyncke                        Experimental                      [Page 1]
RFC 5514                         IPoSN                        April 2009

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.

   On the other hand, Social Networks (like Facebook, LinkedIn, etc.)
   are well-known by users and the usage of those networks is huge.

   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.

2.  Architecture

   With IPv6 over Social Network (IPoSN):

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

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

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

   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.

   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:

   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)

Vyncke                        Experimental                      [Page 2]
RFC 5514                         IPoSN                        April 2009

   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.

   A latency of several hours has an impact on the transport protocols.
   UDP SHOULD be used, and TCP SHOULD NOT be used.

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.

   On each interface, the link-local address will be generated by
   appending the SNA identification to the fe80::/64 prefix.
Show full document text