The presentation is an interesting dive down into the technical weeds of what exactly is causing this bufferbloat problem and how it could be fixed with a combination of factors, most noticeably the CoDel (Controlled Delay) active queue management technique. I found it a useful explanation of many facets of the problem and solution and would encourage folks interested in this topic to give it a look. I'll also note as I did in my earlier post that more info about the bufferbloat problem in general can be found at www.bufferbloat.net.

Written by Dan York, Author and Speaker on Internet technologies

http://www.internetsociety.org/events/inet-denver/inet-denver-livestream

Sessions include:

• IPv4 Exhaustion Update
• IPv4 Exhaustion at ARIN
• Address Policy Workshop
• Evaluation of Current Transfer Market
• TCO of IPv6
• Internet Society Initiatives and How To Get Involved

The list of speakers includes people from ARIN, CableLabs, Internet Society, Time Warner Cable, Google and more.

It sounds like a great event and I'm looking forward to watching it remotely.  It will be recorded so that you will be able to watch it later if you cannot view it live.

Written by Dan York, Author and Speaker on Internet technologies

While I was sitting there very much enjoying the music, I was also thinking about the technology that enabled a space station to participate as they did — and the role the Internet infrastructure played in enabling the creation — and subsequent sharing of this music video. Naturally several of us were immediately wondering about latency and how much post-production was done… but regardless, it was great to see and enjoy! Listen yourself:

Not to be outdone by the Canadians, of course, NASA had their own Google+ Hangout with the I.S.S. last week, too, and if you watch the replay the connection with the station occurs about 30 minutes into the hangout. (Prior to that questions are being handled by astronauts on the ground.) The I.S.S. crew take questions from the moderator and from videos submitted through YouTube. One of the questions was about social media and the crew spoke about how the technology enabled them to collaborate with people all around the world.

On one level this is all mundane, "normal" collaboration that perhaps doesn't warrant being called out… I mean, it's just an IP network, right? But it's an IP network that includes a space station and, at least to me, that's very cool and something to celebrate!

P.S. And as an added bonus, the music video and Google+ Hangout are both available to me over IPv6, as it should be.

Written by Dan York, Author and Speaker on Internet technologies

Two articles give some perspective on this milestone for the Internet:

30 Years of TCP – and IP on everything!
Internet Society Tech Matters Blog: Leslie Daigle writes about preparation for the day and changes since that time including the growth of IPv6

Marking the birth of the modern-day Internet
Official Google Blog: Vint Cerf tells the story of what happened on that momentous day

It is amazing to think that it was only 30 years ago that TCP/IP was switched on… and it will be fascinating to see what the next 30 years bring!

Written by Dan York, Author and Speaker on Internet technologies

Up till now home networks have been fairly simple; a single home router and one LAN. A single WAN IP address, DHCP RFC 1918 space in the LAN, and NAT on the home router. If the user needed extra Ethernet ports or more WiFi coverage they simply hooked up another home router, which DHCP'd it's own RFC 1918 LAN and NAT'd that into the "primary" LAN.

For the most part this seems to work, so why fix what ain't (too) broke? Why is this an interesting area now?

What's New?

Home networks are starting to be bombarded by a plethora of new use cases:

• Ever increasing devices in the subscriber home: Tablets, smartphones, laptops, smart-TVs, game consoles, smart appliances, the list goes on and on.
• Separation of guest users from home users: As more and more of our lives become digital, the need to keep guests from accessing your personal data (photos, tax returns, etc.) is growing. More and more homes require a trusted network for their own use and a guest network to grant visitors Internet access.
• Community Wi-Fi: Another new wireless use-case is the addition of a Wi-Fi GW (or additional SSID) in the subscriber home is used to provide Wi-Fi roaming services to folks passing by outside of the home.
• Femto cell: A GW in the subscriber home used to provide cellular services over the existing Internet connection.
• Smart grid: Home routers providing connectivity to utility company equipment.
• Security, Monitoring, & Automation: More and more sensors and other devices are becoming IP enabled and need network connectivity to function.
• Multi-homing: Users who are increasingly dependent on Internet access may choose to reduce their odds of failure by having two distinct connections, maybe Cable and DSL, or Cable with an LTE backup, etc.
• IP video streaming from the Internet: Video is going IP. Netflix, Youtube, Hulu, HBO-Go, and soon perhaps even your cable channels, IP video is the largest consumer of Internet bandwidth today and shows no sign of slowing.
• Video content sharing and streaming between the devices inside the home: Home movies, downloaded content, ripped DVDs, etc. We need ways to play any content from any source any time.
• Telecommuting and corporate IT requirements: As more people choose to work from home, more companies are requiring strict security measures for their employees home networks, including completely separate networks for telecommuting.
• Emergence of Heterogeneous link layer technologies: ZigBee, Bluetooth, and others are making plays for home device connectivity, and these devices will need to communicate with the rest of the home network to provide the most benefit.

So what does this mean for home networks?

Tomorrow's Home Network

These emerging use cases for the home network, along with the facilitating technologies (including IPv6), seem to be pushing us away from the simple, single router home network of the past to a much more complicated multi-router future.

For one example, I think it will become common to buy a pre-packaged "home security system in a box" that will include a multitude of door and window sensors, motion detectors, glass break sensors, etc. all IP enabled and ready to connect wirelessly (perhaps with 6LoWPAN) to the included router / gateway. This home security router will then be plugged in (likely quite arbitrarily) to the existing home network, alongside a home theater router, a smart kitchen router (perhaps embedded in an eFridge), etc.

Of course, adding routers to a network increases its complexity. In enterprise and service provider networks, increased complexity can be dealt with by training or hiring network engineers (or bringing in contractors). In the home however, I do not believe that we can assume that network users will increase in complexity themselves (nor will they hire engineers). This is the crux of the home network problem statement; how do we deal with increasing network complexity in home networks without increasing the complexity of operating a home network? We must design a network that is completely self-configuring in (almost) every situation. This raises several problems that must be solved.

Opportunities for Innovation

There are a number of problems, er opportunities, that must be addressed to enable this multi-router, arbitrary-topology, configuration-less home network:

• Prefix-distribution & Routing: The first problem that likely needs to be considered when developing a multi-router home-network architecture is how to distribute IP prefixes throughout the home, and how to route packets within and out of the home network once it's established. The current default with IPv4 home routers is NAT-stacking, where each router creates its own private (RFC 1918) LAN addresses and NATs into the upstream network, and bridging, where the home router recognizes a private address on its WAN port and stops routing altogether. Some proposed options (focused on Pv6) are recursive DHCPv6 PD, DHCPv6 relay, and a routing protocol (yes, OSPF in your Grandmothers house). More work is needed.
• Network Detection: This problem can be split into two; edge detection and up detection. Edge detection is important for routers to understand if they are a Customer Edge Router (CER) connected to an ISP, or an Internal Router (IR). This is necessary information for many other decisions like whether to activate a firewall, when to perform NAT, etc. Up detection could facilitate "directionless" home routers, common in other environments, and allow hierarchical logical topologies to be built over looped, meshy or other non-linear physical topologies.
• Multi-homing and Failover: Having multiple Internet connections greatly complicates routing, especially if the desire is for active/active load-balancing over multiple ISPs. Without introducing BGP and complex routing and forwarding tables, how can we get functional auto-configuring multi-homing? Do we need to?
• Service Discovery: Most current service discovery technologies assume a single broadcast domain (a single home LAN). The introduction of multiple home routers will make it more challenging for networked devices to discover each other, especially when they are several hops away from each other (when there are several routers between them). We need solutions for whole-home service discovery that "just work." This could mean additional multicast support, centralized service discovery services, etc.
• RF Interference: As we add multiple SSIDs, technologies that utilize multiple channels, and multiple new wireless protocols, how do we avoid service impacting RF interference?
• Non-IP Gateways: There are additional challenges that may arise when connecting Zigbee, Bluetooth, and other non-IP networks into your home IP network.
• Troubleshooting: After all this is working, we must be able to keep it working. What is an ISP call center going to do to help customers with networking problems in this more complicated environment? How will hired-geeks be able to quickly analyze and mitigate network issues?
• And More...This is just the tip of the iceberg, as we start designing, building, and deploying these networks in earnest, there are likely to be plenty of surprises and more "opportunities for innovation."

Moving Forward

As network engineers begin to address the future of home networking, we should keep the principle of Occam's razor and the words of Antoine de Saint-Exupéry top of mind. We need to ask ourselves about the expected level of sophistication, for both devices and users. I think we can generally agree that while home networks will become more complex, home users will not (and the gear can't get more expensive either). We should remember that while we may have gained our experience and expertise working on enterprise, campus, or service provider networks; home networks are a new and different challenge, requiring a new and different approach. We must also consider the 80/20 rule and not let exceptions (often our own "home networks") rule the conversation and spoil the solution for everyone else. Finally, like any design endeavor, we should fight to keep the solution(s) as open and extensible as possible - while we need to solve for an unmanaged network, we mustn't close the door on configurability for more advanced users and uses.

For a bit more on this problem statement, you can watch my recent talk at NANOG 56, and/or check out the slides.

Written by Chris Grundemann, Network Architect, Author, and Speaker

As is always the case, the IETF meeting will feature groups focusing on pretty much all the various technical aspects of Internet infrastructure: IPv6, DNS, DHCP, security, VoIP, SIP, WebRTC, routing, "Internet of Things", P2P, HTTP, TCP, video conferencing, congestion control, energy management… basically pick any Internet protocol acronym and you'll probably find some group there talking about the topic. If you just scan down the IETF 85 agenda, you will get a sense of the breadth of topics being covered.

If you can't get to Atlanta next week to participate face-to-face, the good news is that the IETF provides a variety of ways that you can participate remotely in the meetings. I recently wrote up instructions that you may find useful: How To Participate In IETF 85 Remotely.

Out of this meeting, new standards will emerge, new drafts will be created, new efforts will be started… and the multistakeholder open standards process that drives the Internet will continue. If you get a chance, the IETF meetings are open to anyone to attend — and anyone can also follow along remotely.

P.S. If you have not had any prior exposure to the IETF, you may want to first read The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force to understand a bit more about how it all works.

Written by Dan York, Author and Speaker on Internet technologies

Read full story: Network World

With the number of ASes connected to the Internet constantly increasing, one could expect that the length of the AS paths would also increase as the network as a whole gets wider. However, this doesn't seem to be the case. Also, with IPv6 being more widely deployed, how does the interconnectedness of the IPv6 portion of the Internet compare to IPv4?

We analysed data collected at several of the RIPE NCC route collectors located at various places around the globe, starting in 2005. We extracted the average length of all the AS paths found and separated the IPv4 from the IPv6 routes¹.

Figure 1: Average AS path length for IPv4 and IPv6 excluding AS prepending

This update shows that during the last two years, even though the overall number of ASes on the Internet is steadily increasing, the average AS path length for IPv4 networks not getting longer. In fact, it has been decreasing slightly. That means, the Internet is not becoming wider per se, but more dense, and therefore more interconnected.

For IPv6 networks, the paths are generally still shorter than in IPv4 networks by more than .5 hops, but this is increasing slightly. As IPv6 deployment progressively reaches the edges of the Internet it might stabilise and reach the same density level as IPv4.
The practice of AS prepending seems to be increasing progressively, even though it is still rarer in IPv6 than in IPv4.

For more analysis and the methodology used to produce these graphs, please refer to the background article on RIPE Labs: Update on AS Path Lengths Over Time.

¹AS prepending is a method of making routes less attractive by artificially lengthening the AS path. Because the most common routing protocol tends to send traffic over the shortest path, an artificially prepended path is taken less often. For the purpose of these statistics, we removed the prepended ASes from the count.

Written by Mirjam Kuehne

IEEE, IAB, IETF, Internet Society & W3C Invite Other Standards Organizations, Governments and Companies to Support Modern Paradigm for Global, Open Standards

The principles comprise a modern paradigm in which the economics of global markets — fueled by technological innovation — drive global deployment of standards, regardless of their formal status within traditional bodies of national representation. The OpenStand principles demand:

• cooperation among standards organizations;
• adherence to due process, broad consensus, transparency, balance and openness in standards development;
• commitment to technical merit, interoperability, competition, innovation and benefit to humanity;
• availability of standards to all, and
• voluntary adoption.

Leslie Daigle, chief Internet technology officer with the Internet Society says: "International standards development for borderless economics is not ad hoc; rather, it has a paradigm — one that has demonstrated agility and is driven by technical merit. The OpenStand principles convey the power of bottom-up collaboration in harnessing global creativity and expertise to the standards of any technology space that will underpin the modern economy moving forward."

Such networks need to operate more on a horizontal level, rather than the usual vertical connection between a computing device and the users. M2M communication will dominate the networks of the future and for that reason alone a much more sophisticated structure of network intelligence is needed. We have outgrown the networks that we are using at the moment, based as they are on the technologies that were available in the 1960s. They have done a terrific job but it is now time to move on. The millions of routers that are dominating these networks have become an impediment to change; they can be compared to what the old mainframes were in computing.

The new concept of programmable networking is known as Software Defined Networks (SDN), a technology concept that has been discussed now for several years. The concept behind this totally changes the nature of the network — from a configuration of devices that are passing messages on to each other based on proprietary controlled software embedded in these devices, to one where these devices are independently managed within an open network and where the hardware is split from the software. The software is then deployed in a different, independent and more central way in data centres that will allow for a more intelligent way of managing the overall network (instead of managing individual software/hardware integrated devices within the network). This virtualisation of the network is, of course, a radically different approach and requires an industry transformation.

The benefits are worth it:

• there is much greater control of traffic management over the network;
• there is much more flexibility regarding the increasingly different number of requirements for all the different activities that are taking place in all the different parts of the network;
• there are higher levels of transparency which give customers (corporates) more control over what happens with their applications;
• possibilities will exist to include more targeted and much more sophisticated levels of security and privacy;
• there are lower operational costs.

OpenFlow is the protocol that facilitates the implementation of SDNs. It creates virtual networks that are ideal for collaboration, and at the same time it considerably reduces the cost of infrastructure. Google recently re-engineered its network based on 'OpenFlow'.

The Open Networking Foundation is the key promoter of these concepts and they are widely supported by the industry.

Written by Paul Budde, Managing Director of Paul Budde Communication

The reason this is such an important question is that it's very easy to get IPv6 subnetting wrong by doing it like you do in IPv4. The problem is that there is a paradigm shift needed from IPv4 subnetting to IPv6 subnetting — you simply can't approach them the same way. The reason for this harkens back to the primary driver for deploying IPv6 in the first place: More addresses! So many more in fact that individual addresses become essentially meaningless in IPv6 address planning and subnetting. A single IPv6 /64 subnet contains roughly ten quintillion addresses, quite obviously more than you will ever need in one IP network segment. Even considering machine to machine communications and all the myriads of devices which will someday be IP enabled, you are extremely unlikely to ever put more than 10,000,000,000,000,000,000 hosts on a single bridged network.

So, the first thing you must do when approaching IPv6 subnetting is to wrap your head around the new paradigm of address abundance, leaving behind the mentality of IPv4 address scarcity. While IPv4 subnetting is all about addresses, IPv6 subnetting is all about networks. Instead of counting hosts, and sizing individual subnets based on the number of addresses needed (managing scarcity), we now count routers and build hierarchy based on the networks they support. We know that a /64 can address any number of hosts we'll through at it, so why worry about how many there are? The answer is that you don't. You simply assign one subnet to each network and move on.

Another great aspect of address abundance is that hierarchy I just mentioned. In IPv4 you obtain just the addresses that you need for the next year or so and then go back for more, over and over again as you grow your network. This means fractured subnets, broken up and used where addresses are needed, often in a manner that does not allow aggregation within your network. With IPv6 we can flip this on its head and build our networks with true hierarchy, allowing aggregation at each level. Each region/campus/building/floor/etc. has it's own identifying prefix, fitting one inside the other like a Matryoshka. This simplifies filters, firewall rules and ACLs. It shrinks our core routing tables and facilitates traffic engineering. It also simplifies operations and troubleshooting.

Another way we can simplify network operations a little by shifting our subnetting paradigm is to use nibbles. A nibble, for those unfamiliar, is half a byte or four bits. Starting at /64, the nibble aligned subnet masks are /60, /56, /52, /48, etc. Subnetting on nibble boundaries means only using nibble aligned subnet masks. Basically if you need more than one /64 you should jump to a /60 and don't try to use /63, /62, nor /61. Yes, this may cause some "waste" but that's one of the great things about this new paradigm of address abundance — we don't care! Using nibble boundaries makes your subnetted prefixes much easier to read. When you see 2001:db8:2000::/36 you know that it comes after 2001:db8:1000::/36 and before 2001:db8:3000::/36. Because one 4-bit hex digit increments linearly when using nibbles, its easy to do the math in your head (plus one, minus one). This is not true if you use a non-nibble-aligned subnet like /37 or /35.

You can combine these practices and take it a step further by building homogenous hierarchies such that each prefix within a given level is the same size. Talk about an address planners wet dream! For example, you may want to give every department within each building a /56, each building a /48, and each campus on your network a /40. Now, these numbers are not arbitrary, they need to be carefully planned out ahead of time to ensure that your largest department, building, campus, etc. has room to grow within its assigned subnet.

Start at the bottom, whatever your most granular network division is, and work up. Our example starts with department, so you take the largest department in your organization and count how many networks will be needed to support the next 5 years of growth. One nibble up from /64 is /60, which gives you a maximum of 16 /64s. If you need more than that, jump to the next nibble; a /56, which gives you up to 256 /64 networks to work with — perfect! Now move up the hierarchy to the building level and again take the largest building in your organization (which may not house that largest department — that's OK). This time you're counting departments to see how many /56 subnets are required to sustain the building's growth. A /48 again provides up to 256 /56 subnets (being two nibbles, or 8 bits, larger), so you pick that because you need more than the 16 that a /52 would yield. Repeat the process again by counting buildings in your largest campus and fitting that number to a nibble-aligned subnet size. Finally, count your campuses, round up to a nibble, and you know the size of prefix your organization needs! Of course this is just one example. Your network may logically be divided in different ways, perhaps your campuses need to be further grouped into regions or buildings are your lowest level. Maybe you start with headend or central office at the bottom level and work up through geographical regions. Obviously you'll need to fit your IPv6 subnetting plan to your own network — what really matters is understanding the paradigm.

Once you have shifted your paradigm and are ready to go forth and subnet, I highly recommend starting with this Best Current Operational Practice on IPv6 subnetting written by engineers, for engineers. You'll probably also want to look into IP Address Management (IPAM) software if your network is a large one (or if that last paragraph scared the bejesus out of you) as abundance can certainly bring some complexity along with it's benefits. Happy subnetting!

Written by Chris Grundemann, Network Architect, Author, and Speaker

"The most tedious part of DDI and IPAM deployment is often associated with the migration of existing Excel spreadsheets," said the Director of Technical Operations at Nixu Software, Ville Kummu. "The problem is two folds. Firstly, as the size of the organisation grows, so does the number of spreadsheets with various data structures. Secondly, there are many cases where some of the information in these spreadsheets are out-dated which means that without sifting through them there is no way to know what is still valid and what is not. We designed a product that solves this problem. Nixu NEE automatically pulls the subnets and clients from the network equipment and integrates them with Nixu IPAM, making the migration process a whole lot smoother," he added.

When integrated with Nixu NameSurfer IPAM, Nixu NEE presents organisations with location-aware IPAM that greatly speeds up the response time for internal service requests. It also provides real-time views of the active IP allocations, which allows organisations to maintain an accurate inventory of their IP addresses and take appropriate measures against unauthorized use of their network resources.

Find out more about Nixu NEE and download a free 30-day trial.

This was not the only conflicting information which came out of the At-Large and Compliance meeting in Prague. In this discussion Compliance staff repeatedly asks At-Large representatives to cite specific examples of problems, but when a question concerning certain complaints (at minute 01:19:27) is asked and the room goes silent. To further the point, a specific case concerning BizCN is read aloud but not addressed specifically by Compliance. Compliance presented a number of process enhancements and improvements in automation at this meeting but the issue on the table was actual enforcement of the contract which seems to be lacking. Setting the tone for this missing enforcement was the apparent removal from ICANN's website of a flowchart entitled "ICANN Compliance Program for Registries and Registrars” which had no enforcement phase documented in the flow, only compliant dismissal, closure and circular shuffling. However, this has been replaced with three new charts which show significant improvement in stated process. Unfortunately, the question is still open as to if these processes will actually be used as stated. So far we do not have a good track record of real follow-through. The three legs of Compliance are Prevention through collaboration, Transparency through communication, and Enforcement. But it feels like this chair is going to drop us on the floor.

Written by Garth Bruen, Internet Fraud Analyst and Policy Developer

The error code: 451.

From the Internet Draft, if the user tries to access a page, but access to the page is restricted by the government, display the following (for example):

HTTP/1.1 451 Unavailable For Legal Reasons

Unavailable For Legal Reasons

This request may not be serviced in the Roman Province of Judea due to Lex3515, the Legem Ne Subversionem Act of AUC755, which disallows access to resources hosted on servers deemed to be operated by the Judean Liberation Front.

The IETF draft is a head nod to Ray Bradbury's book Fahrenheit 451, a novel about someone living in society where books are censored by the government.

While this is a common interpretation of the book — government seizure of books — it is not one that Bradbury himself identified as the main theme. Quoting from Wikipedia:

The novel is frequently interpreted as being critical of state-sponsored censorship, but Bradbury has disputed this interpretation. He said in a 2007 interview that the book explored the effects of television and mass media on the reading of literature. Bradbury went even further to elaborate his meaning, saying specifically that the culprit in Fahrenheit 451 is not the state — it is the people. Yet in the paperback edition released in 1979, Bradbury wrote a new coda for the book containing multiple comments on censorship and its relation to the novel.

In other words, the 451-degrees-Fahrenheit-at-which-paper-burns refers to people's disinterest in books and literature, and more interest towards easier, shorter forms of communication such as radio and television (and today would be Facebook, instant messaging, Twitter… but not blogs, of course). He reiterated this opinion in a New York Times article in 2009.

On the other hand, what everyone thinks that the book is about, even if you haven't read it, is government censorship of books, and blocking access to material that the state feels its citizens shouldn't read. Given how pervasive that perception is, I think that the IETF draft is a clever play on the idea, even if the original writer of the book wouldn't approve.

Written by Terry Zink, Program Manager