I sat with Greg Ferro over at Packet Pushers for a few minutes at the Prague IETF. We talked about Openfabric and how we are overusing BGP in many ways, as well as other odds and ends.
‘net neturality has been much in the news recently; a while back I did a piece for Tech Target on some of the complexities here, and I ran across three other articles that provide a contrarian view—not what you are likely to hear from the major edge providers. Since I am always trying to understand both sides of an issue, I am always looking for solid, well written views on both sides. It is hard to dig behind the hype in our 140 character world, but it is also important.
Hence this post, with pointers to my older post and three other articles of interest. Warning: some of these are more trenchant and contrarian than others.
The primary foundation of net neutrality explained is this: Providers should not be able to give services they offer any advantage over a competing service running over their network. The perfect example might seem to be voice services. Suppose you purchase access to the internet from a company that not only sells internet access, but also voice services. Now, suppose the provider decides to sell its voice service as superior in quality to any other available voice service — and guarantee its service is better by degrading the handling of traffic to and from every other known over-the-top voice provider. For example, the access provider could choose to drop every 10th voice packet not sourced from, or destined to, one of its voice servers. —Russ White @ Tech Target (note this article is behind a registration wall)
Yet Mozilla (and many others) are building their case for net neutrality around the fear that other, bad corporations are going to impose “censorship” that is so much worse the benevolent speech patrols of the corporations they like. On Mozilla’s landing page, that’s the obsession of just about every anonymous quote from a “Concerned Internet Citizen.” —Robert Tracinski @ The Federalist
Over the next decade which companies do you think will be better able to exercise monopoly power? Amazon, T&T, Comcast, Facebook, Google, Regional phone companies, or Verizon? If you’d asked me this question in 2000, I would’ve picked AT&T, Comcast, Verizon, and regional phone companies. They are part of local duopolies for wired infrastructure. They had a comfortable relationship with the FCC which regulated them nationally and with most of the state regulators. They saw the Internet as potentially disruptive and would’ve preferred to have its potential for innovation slowed by regulation. Amazon and Google (and most of the Internet community of the day) were against FCC regulation of the Internet exactly because that would chill innovation. —Tom Evslin @ CircleID
Ironically, the world’s leading winner-take-all Internet platforms — Google, Amazon, and Facebook — are the leading voices of the July 12th “Internet-wide Day of Action to Save Net Neutrality.” They want to pressure the U.S. FCC to maximally regulate ISPs as Title II telephone utilities, even though they don’t believe in operating neutral networks themselves. Even more ironic, is this 1 min. Google-YouTube video — by the Internet Association, “the unified voice of the Internet economy.” It defines net neutrality and what it wants the FCC to ban ISPs from doing. However, those banned behaviors closely describe how Google, Facebook and Amazon often operate. Awkward. —Scott Cleland @ Somewhat Reasonable
Last week, activists proclaimed a “NetNeutrality Day”, trying to convince the FCC to regulate NetNeutrality. As a libertarian, I tweeted many reasons why NetNeutrality is stupid. NetNeutrality is exactly the sort of government regulation Libertarians hate most. Somebody tweeted the following challenge, which I thought I’d address here. —Robert Graham @ Errata Security
The IETF published RFC8200 last week, which officially makes IPv6 an Internet Standard. While this move was a long time coming—IPv6 has now reached about 20% deployment—a more interesting question is: what has changed since RFC2460, which was a draft standard, was published in 2013? After all, the point of moving from the experimental to the draft standard to the internet standard states is to learn more about the protocol as it operates on the wire, and to make changes to improve deployability and performance.
Where would you look to determine what these changes might be? The IETF draft tracker tool, of course. If you look at the data tracker page for RFC8200, you will find a tab called history. From there, you have the option of looking at the revision differences, as shown below.
When you click on the wdiff button, you will see something like this—
In this case, I went back to the original version of the RFC2460bis draft (which just means the draft was designed to replace RFC2460). There are earlier versions of this draft from before it was accepted as a working group document, but even this comparison should give you some idea of the major changes between the original document and the new document that replaces it. If you want a more complete diff, you will need to download the documents and run a diff in a tool like Atom or Notepad++.
Looking through the diffs, the major changes from the earliest 2015 version and the current 2017 version are in the area of extension headers.
First, according to section 4 of the new RFC, “the first one that is not an extension header [IANA-EH] indicates that the next item in the packet is the corresponding upper-layer header.” While older revisions of IPv6 actually carried a TLV that essentially said “the next header is TCP, and it begins in X octets,” the new revision assumes that if a header is reached that does not fit into the number range of an extension header indicates the next header is an upper layer protocol header.
What if you want to format a packet that is carrying no upper layer protocol? A new extension header is defined in section 4.7 of the new RFC for just this purpose. An implementation can end the chain of extension headers with a no next header extension header, which effectively tells the receiver to stop processing the packet. This allows you to form an IPv6 packet that carries only headers and extension headers, and no actual data.
Second, the way the extension headers are processed has been changed. In fact, this is probably the most far reaching change in the document from 2015 to the currently published version. Three specific changes have taken place here—
- Extension headers are not to be modified in any way by intermediate nodes (normally known as routers). This not only rules out fragmentation, but any modification of any extension header, including hop-by-hop headers. This is considered in the main body of section 4, before the beginning of the first subsection.
- There is note in this same area that changes the default behavior of intermediate nodes towards hop-by-hop headers. In RFC2460, each node was required to examine and process any hop-by-hop headers in the packet. In the newly published standard, intermediate nodes are only expected to examine these headers if they are configured to do so. Implementations cannot expect intermediate nodes to examine, or act on, hop-by-hop headers.
- In section 4.8, there are several paragraphs pointing out that because of these changes, no new extension headers will be defined without strong justification. While the text is in lower case (which generally means it is not “binding” on compliant implementations), a note here says: “New extension headers that require hop-by-hop behavior must not be defined…”
Instead of new extension headers, the new RFC recommends that any extensions be placed into Destination Headers, which are only processed by the destination. This recommendation is towards the bottom of section 6.8.
There are also a good number of changes in the fragmentation section, but these appear (primarily) to be changes in the way the text is organized. The basic concept—that fragmentation can only be performed by the originating host—has not been changed.
While it might seem like it took a long time for IPv6 to move from a draft standard to a “real” standard, it takes experience with a protocol to actually understand what it will look like in real deployments, and to work out those little details that make a huge difference in the usefulness of the protocol over the long term. Welcome to Internet Standard status, IPv6.
And now there is no excuse to not deploy IPv6 in your network today.
Just a short note: I’ve updated the sixty book section of the site with a new plugin designed to keep track of book libraries. Along the way, I’ve added an Amazon affiliate code, so maybe I can buy a cup of hot chocolate and a piece of banana nut bread at some point in the future. 🙂 The look should really be a bit nicer, though, and it is easier to add books to this system than manually adding them as I was doing before.
Remember that the idea of sixty books is not that there are actually 60 books on the list, but rather this is what I read in an average year—and hence what I am challenging you to work up to.