Category: RFCs

Apr 07

Celebrating 50 Years of the RFCs That Define How the Internet Works

First page of RFC 1

50 years ago today, on 7 April 1969, the very first “Request for Comments” (RFC) document was published. Titled simply “Host Software”, RFC 1 was written by Steve Crocker to document how packets would be sent from computer to computer in what was then the very early ARPANET. [1]

Steve and the other early authors were just circulating ideas and trying to figure out how to connect the different devices and systems of the early networks that would evolve into the massive network of networks we now call the Internet. They were not trying to create formal standards – they were just writing specifications that would help them be able to connect their computers. Little did they know then that the system they developed would come to later define the standards used to build the Internet.

Today there are over 8,500 RFCs whose publication is managed through a formal process by the RFC Editor team. The Internet Engineering Task Force (IETF) is responsible for the vast majority (but not all) of the RFCs – and there is strong process through which documents move within the IETF from ideas (“Internet-Drafts” or “I-Ds”) into published standards or informational documents[2].

50 years ago, one of the fundamental differences of the RFC series from other standards at the time was that:

  • anyone could write an RFC for free.
  • anyone could read the RFCs for free. They were open to all to read, without any fee or membership

As Steve Crocker notes in his recollections, this enabled the RFC documents to be widely distributed around the world, and studied by students, developers, vendors and other professionals. This allowed people to learn how the ARPANET, and later the Internet, worked – and to build on that to create new and amazing services, systems and software

This openness remains true today. While the process of publishing a RFC is more rigorous, anyone can start the process. You are not required to be a member (or pay for a membership) to contribute to or approve standards.  And anyone, anywhere, can read all of the RFCs for free.  You do not have to pay to download the RFCs, nor do you have to be a member of any organization. 

More than anything, this open model of how to work together to create voluntary open standards is perhaps the greatest accomplishment of the RFC process. The Internet model of networking has thrived because it is built upon these open standards.

Standards may come and go over time, but the open way of working persists.

While we may no longer use NCP or some of the other protocols defined in the early RFCs, we are defining new protocols in new RFCs.  The next 1,000s RFCs will define many aspects of the Internet of tomorrow.[3]

We may not know exactly how that future Internet will work, but it’s a pretty good guess that it will be defined in part through RFCs.

[1] See our History of the Internet page for more background.

[2] For more explanation of the different types of RFCs, see “How to Read a RFC“.

[3] As noted in our 2019 Global Internet Report section on “Takeaways and Observations”, we are concerned that an increasing number of new services and applications on the Internet are relying on application programming interfaces (APIs) controlled by the application or platform owner rather than on open standards defined by the larger Internet community.

The post Celebrating 50 Years of the RFCs That Define How the Internet Works appeared first on Internet Society.

Oct 24

New RFC 7381: Enterprise IPv6 Deployment Guidelines

RFC 7381Would you like guidelines for how IPv6 can best be deployed in an enterprise environment?  Yesterday the IETF published a new informational RFC 7381, “Enterprise IPv6 Deployment Guidelines” available at:

https://tools.ietf.org/html/rfc7381

The abstract for the document reads:

Enterprise network administrators worldwide are in various stages of preparing for or deploying IPv6 into their networks. The administrators face different challenges than operators of Internet access providers and have reasons for different priorities. The overall problem for many administrators will be to offer Internet-facing services over IPv6 while continuing to support IPv4, and while introducing IPv6 access within the enterprise IT network. The overall transition will take most networks from an IPv4-only environment to a dual-stack network environment and eventually an IPv6-only operating mode. This document helps provide a framework for enterprise network architects or administrators who may be faced with many of these challenges as they consider their IPv6 support strategies.

The document then goes on to outline several phases of IPv6 deployment within an enterprise.  The Table of Contents gives a good sense of what is in the document:

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Enterprise Assumptions . . . . . . . . . . . . . . . . . 5
1.2. IPv4-Only Considerations . . . . . . . . . . . . . . . . 5
1.3. Reasons for a Phased Approach . . . . . . . . . . . . . . 6
2. Preparation and Assessment Phase . . . . . . . . . . . . . . 7
2.1. Program Planning . . . . . . . . . . . . . . . . . . . . 7
2.2. Inventory Phase . . . . . . . . . . . . . . . . . . . . . 8
2.2.1. Network Infrastructure Readiness Assessment . . . . . 8
2.2.2. Application Readiness Assessment . . . . . . . . . . 9
2.2.3. Importance of Readiness Validation and Testing . . . 9
2.3. Training . . . . . . . . . . . . . . . . . . . . . . . . 10
2.4. Security Policy . . . . . . . . . . . . . . . . . . . . . 10
2.4.1. IPv6 Is No More Secure Than IPv4 . . . . . . . . . . 10
2.4.2. Similarities between IPv6 and IPv4 Security . . . . . 11
2.4.3. Specific Security Issues for IPv6 . . . . . . . . . . 11
2.5. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.6. Address Plan . . . . . . . . . . . . . . . . . . . . . . 14
2.7. Tools Assessment . . . . . . . . . . . . . . . . . . . . 16
3. External Phase . . . . . . . . . . . . . . . . . . . . . . . 17
3.1. Connectivity . . . . . . . . . . . . . . . . . . . . . . 18
3.2. Security . . . . . . . . . . . . . . . . . . . . . . . . 19
3.3. Monitoring . . . . . . . . . . . . . . . . . . . . . . . 20
3.4. Servers and Applications . . . . . . . . . . . . . . . . 20
3.5. Network Prefix Translation for IPv6 . . . . . . . . . . . 21
4. Internal Phase . . . . . . . . . . . . . . . . . . . . . . . 21
4.1. Security . . . . . . . . . . . . . . . . . . . . . . . . 22
4.2. Network Infrastructure . . . . . . . . . . . . . . . . . 22
4.3. End-User Devices . . . . . . . . . . . . . . . . . . . . 23
4.4. Corporate Systems . . . . . . . . . . . . . . . . . . . . 24
5. IPv6 Only . . . . . . . . . . . . . . . . . . . . . . . . . . 24
6. Considerations for Specific Enterprises . . . . . . . . . . . 26
6.1. Content Delivery Networks . . . . . . . . . . . . . . . . 26
6.2. Data Center Virtualization . . . . . . . . . . . . . . . 26
6.3. University Campus Networks . . . . . . . . . . . . . . . 26
7. Security Considerations . . . . . . . . . . . . . . . . . . . 28
8. Informative References . . . . . . . . . . . . . . . . . . . 28

The document is a good one for all people involved with enterprises to read and we’ll be adding the document to our “IPv6 for Enterprises” page soon.  We’d encourage you to read this RFC 7381 and share it with others.  Please do also check out other resources that are available for enterprises looking to make the move to IPv6.

 

Nov 27

A Very Useful New RFC 7059 – A Comparison of IPv6-over-IPv4 Tunnel Mechanisms

RFC 7059If you can’t get a native IPv6 connection for your network from your local Internet Service Provider (ISP), what kind of “tunneling” mechanism can you use to get IPv6 connectivity for your network?  Today a new Informational (non-standard) RFC 7059, A Comparison of IPv6-over-IPv4 Tunnel Mechanisms, was published that explores exactly these issues. It walks through a wide range of available IPv6 tunneling mechanisms and explains the merits (or not) of the various mechanisms, while also providing plenty of links for people to learn more.  The list of  tunneling mechanisms includes:

  • Configured Tunnels (Manual Tunnels / 6in4)
  • Automatic Tunneling
  • IPv6 over IPv4 without Explicit Tunnels (6over4)
  • Generic Routing Encapsulation (GRE)
  • Connection of IPv6 Domains via IPv4 Clouds (6to4)
  • Anything In Anything (AYIYA)
  • Intra-Site Automatic Tunnel Addressing (ISATAP)
  • Tunneling IPv6 over UDP through NATs (Teredo)
  • IPv6 Rapid Deployment (6rd)
  • Native IPv6 behind NAT44 CPEs (6a44)
  • Locator/ID Separation Protocol (LISP)
  • Subnetwork Encapsulation and Adaptation Layer (SEAL)
  • Peer-to-Peer IPv6 on Any Internetwork (6bed4)

If you are frustrated with being unable to obtain native IPv6 connectivity for your network, this RFC may provide a good place to start to learn more about how you can use one of these transition mechanisms to connect your network to the rest of the IPv6-enabled Internet!

 

Apr 25

Want To Make Your Web Content Available over IPv6? Check Out The Excellent RFC 6589

IETF Logo Are you a “content provider,” such as a website operator, seeking to understand how to ensure your content is available over IPv6? Would you like to know what challenges you can expect? What kind of migration strategies you can use?  What you should do for an implementation plan?

If so, the IETF recently published an excellent guide in RFC 6589, “Considerations for Transitioning Content to IPv6“ available at:

http://tools.ietf.org/html/rfc6589

The primary author is Jason Livingood of Comcast but many others have contributed to creating an excellent document! It explains both the issues with moving content to IPv6 and offers suggestions for migration plans and implementation tactics. With World IPv6 Launch fast approaching on June 6, 2012, it is excellent to have this document available to help content providers understand what they need to do!

From the introduction to the RFC:

This document describes considerations for the transition of end-user content on the Internet to IPv6. While this is tailored to address end-user content, which is typically web-based, many aspects of this document may be more broadly applicable to the transition to IPv6 of other applications and services. The issues explored herein will be of particular interest to major web content sites (sometimes described hereinafter as “high-service-level domains”), which have specific and unique concerns related to maintaining a high-quality user experience for all of their users during their transition to IPv6. This document explores the challenges involved in the transition to IPv6, potential migration tactics, possible migration phases, and other considerations. Some sections of this document also include information about the potential implications of various migration tactics or phased approaches to the transition to IPv6.

You can see from the table of contents the range of topics covered in the document:

1. Introduction
2. Challenges When Transitioning Content to IPv6
3. IPv6 Adoption Implications
4. Potential Migration Tactics
5. Potential Implementation Phases
6. Other Considerations
6.1. Security Considerations
6.2. Privacy Considerations
6.3. Considerations with Poor IPv4 and Good IPv6 Transport

The document is an excellent guide for content providers and anyone seeking to understand how to make their content available over IPv6. We’ve now added RFC 6589 to our list of resources and look forward to learning how it may help many of you get your content ready for IPv6!