RFC 5514

IPv6 over Social Networks

📅 published April 2009, from ietf

IPv6 over Social Networks 🦋

Okay bestie, let's start with the title block 💖. This is RFC 5514, from the Network Working Group. The author is E. Vyncke of Cisco Systems. It's an Experimental doc dated 1 April 2009 🌸. The header doesn't list anything it obsoletes or updates, so it isn't replacing or changing any other RFC. (The date is 1 April, so make of that what you will 👀.)

Status of This Memo ✨

This memo is an Experimental Protocol for the Internet community, and it does not specify an Internet standard of any kind. They're asking for discussion and suggestions for improvement 🫶. Distribution of this memo is unlimited 💅.

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 as they stood on the date of publication (http://trustee.ietf.org/license-info). Please read these carefully, because they spell out your rights and restrictions for this document 📜.

Abstract 🌈

Okay so, early 2009 had a lack of IPv6 utilization, and that's partly because there just aren't many IPv6 nodes 😭. This document wants to vastly increase the number of IPv6 hosts by turning all Social Networking platforms into IPv6 networks. That would immediately add millions of IPv6 hosts to the existing IPv6 Internet 🚀. It covers addressing and transport of IPv6 over a Social Network, and a working prototype has been built ✨.

1. Introduction 🧚

IPv6 has been around for years, but not every host uses it (at least as of March 2009). Most network users have no idea what IPv6 is, or they're even kind of scared of it because it's unfamiliar 🙈.

Meanwhile, Social Networks like Facebook, LinkedIn, and friends are super well-known, and people use them a lot 🔥.

So this document explains how to use Social Networks to make more people aware of IPv6 and to add several thousands of IPv6 routers to the Internet. Main character energy 👑.

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 is used as a point-to-point link 🔗.

Users on social networks want lots of friends, partners, and relations, so you can expect a heavily meshed network among them 🕸️. That gives good IPv6 connectivity, because each user (an IPoSN router) is IPv6 connected to all their friends (IPoSN neighbor routers) 🫶.

Several Social Network Applications (SNAs) allow plug-ins, or let other applications get mashed up with the social network. Those applications can then generate IPv6 packets on behalf of the users. The packets get transferred hop by hop, or really user by user, over the mashed SNA/IPv6, until they reach their destination 🦋.

The usual SNA policy is to only let the account owner modify an account. So the IPv6 processing of a packet received by an SNA account has to be explicitly run by the account owner using a web action. That action gives the router CPU a nudge to process all received IPv6 packets 💀. This has two impacts on the IPv6 network:

  1. The account owner has to explicitly 'run the CPU' to forward or receive IPv6 packets. This is an opportunity for IPoSN to explain how it all works (one goal is education 🎓).
  2. The latency between two nodes over such a network can be very high, so timers (especially the routing timers; see Section 3) will have to be modified ⏰.

A latency of several hours really affects 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 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. Because this is a loopback address, the prefix length will always be /128. The same /64 prefix is used for all SNA users, so they'll all appear to be part of the same /64 network 🌸.

On each interface, the link-local address is generated by appending the SNA identification to the fe80::/64 prefix ✨.

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

  • Global: 2001:db8:face:b00c::24f6:b478/128
  • Link-local: fe80::24f6:b478/64

2.2. Address Translation 🔁

With the example prefix chosen for all global addresses, an IPv6-to-IPv6 Non-Carrier Grade NAT (NCGN) must be implemented. It's linked to at least one 'edge' SNA user, whose account gets used to pass (and translate) IPv6 packets between IPoSN and the real IPv6 Internet 🌍. The gateway and NAT functions are out of scope for this document 🙅‍♀️.

3. Choice of IGP 🛣️

As we saw in the architecture section (Section 2), IPv6 packets only propagate when a user activates the IPoSN application linked to their SNA account. So propagation delays are measured in hours or days, compared to microseconds over the Internet fishbone 🐟. The jitter is also very high, since different users have totally different habits when it comes to using SNA 😩.

IPoSN SHOULD implement RIPng [RFC2080], which is relatively immune to jitter and doesn't rely on flooding messages to all neighboring routers ✅. OSPFv3 [RFC5340] SHOULD NOT be used over IPoSN. 🚫

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

4. Working Prototype 🧪

A working prototype was developed by the author and is freely available: IPv6 over Facebook Social Network [IPv6overFacebook]. It uses the LAMP architecture 💜.

Here are some stats 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

The extreme latency makes network operation and troubleshooting super interesting 🤯.

A high latency ICMP echo request/reply:

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:

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 🔐

This part is serious, bestie 😤. Users can't really control what they send (packets go through a well-controlled web interface), so there's no threat of spoofed packets. The only exception is at the NAT66 gateway, where packets from the real Internet can come in. Therefore, the NAT66 gateway MUST implement anti-spoofing.

Denial of service (packet flooding) can happen if a malicious user uses a web tool to request a ping diagnostic every second. Therefore, implementations SHOULD implement a rate limit on each web page that can generate an IPv6 packet. 🛑

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

6. Acknowledgments 🫶

Many thanks to all the first users of the IPv6 over Facebook [IPv6overFacebook] application: Isabelle Dehousse, Yves Hertoghs, Thomas Kernen, Simon Leinen, and so many others 💖.

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

Author's Address 🌷

Eric Vyncke Cisco Systems De Kleetlaan 6a Diegem 1831 Belgium

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

📦 where this page comes from