IETF Discusses Deprecating IPv6 Fragments

By: Bill Cerveny -

The IETF IPv6 maintenance working group has begun discussions about deprecating IPv6 fragmented packets, spurred by the IETF Internet-Draft, “IPv6 Fragment Header Deprecated”. As one can guess, this draft has generated a lot of discussion (Although the Internet Draft discusses deprecation of the IPv6 fragment header, deprecation of the header would effectively deprecate IPv6 fragmented packets).

As I noted in an earlier posting here, fragments in IPv6 can create havoc in networks from an operational and a security perspective, just like they do with IPv4. Unlike IPv4, only the source host computer can fragment IPv6 packets and IPv6 fragmented packets require a special fragment extension header.

In addition to observing the general problems with fragments, the Internet draft noted that fragments may be dropped by firewalls and network operators, which could make network traffic that includes IPv6 fragmented packets fragile. Commenters to the draft noted that fragments are in fact being dropped, regardless of what the IETF or anyone else states is a good operational practice (some of the reasons operators filter fragments is discussed here).

Nobody particularly likes fragments, but it isn’t clear how to outright eliminate them. It appears there are some specific cases where no good alternatives exist to the use of IP fragments. In my opinion, the next steps should be identifying these specific cases and begin working on solutions to eliminate fragments in these cases.

“IPv6 Fragment Header Deprecated” is a worthwhile read for those who have already implemented IPv6 networks and those implementing IPv6 networks. Updates to this draft are promised. It will be interesting to see the path this discussion takes and the impact that it has on the evolution of the Internet Protocol.

Accelerating IPv6 Growth and Sunsetting IPv4

By: Bill Cerveny -

The next-generation Internet Protocol, IPv6, has experienced more growth in the last 2 years than in any other period in its 18-year existence . While there are many challenges ahead in the deployment of IPv6, IPv6 is a certain, although eventual, replacement for the currently dominant IP protocol, IPv4. As deployment of IPv6 gains momentum worldwide, the Internet Engineering Task Force (IETF) has begun examining how to accelerate IPv6 as the dominant IP version and how to handle the ramping down of IPv4.

The IETF has made an important step forward by stating that IPv6 support is no longer optional in an IP- or Internet-capable device. As envisioned by IETF RFC 6540, “IPv6 Support Required for IP Capable Nodes,” all devices that claim to be IP-capable or Internet-capable must support IPv6 and may optionally support IPv4.

In defining its guidance, RFC 6540 states that best practices should be:

• New IP implementations must support IPv6.
• Updates to current IP implementations should support IPv6.
• IPv6 support must be equivalent or better in quality and functionality when compared to IPv4 support in a new or updated IP implementation.
• New and updated IP networking implementations should support IPv4 and IPv6 coexistence (dual-stack), but must not require IPv4 for proper and complete function.
• Implementers are encouraged to update existing hardware and software to enable IPv6 wherever technically feasible.

It is hoped that this RFC sends a strong message to the Internet community that IPv4 support should now be considered optional and IPv6 support mandatory.

From a number of perspectives, it is easier to maintain a network based on a single version of the Internet Protocol. Running a network with only one IP version should be the end-goal of any IPv6 deployment effort. Although there are many similarities in how IPv4 and IPv6 are designed, in many cases the two Internet Protocol versions operate as “ships in the night.” That said, there are some situations where duplicity of efforts can be mitigated. For example, an IPv6 addressing plan could leverage an existing IPv4 address plan.

Infrastructure for the two IP versions must be mostly managed separately. Addressing for IPv4 must be managed separately than addressing for IPv6. Routing must generally be handled and managed separately for IPv4 and IPv6, even if the same team manages both IP versions and the routing occurs across the same physical network links. Node connectivity must be assured separately for each IP version supported by the enterprise or service provider; ensuring that a node is reachable via IPv6-transport does not confirm that the node is also reachable via IPv4-transport. Security considerations must be made for both IPv4 and IPv6 networks; in some cases the security concerns will be similar between IP versions, and in other cases, there will be security vulnerabilities unique to the IP version that must be evaluated. Scott Hogg has an excellent discussion of these issues at Network World.

To advance the ramp-down of IPv4 and to facilitate scenarios where IPv6 is the only IP version, the IETF has chartered the “Sunsetting IPv4” (sunset4) working group to “standardize technologies that facilitate the graceful sunsetting of the IPv4 Internet in the context of the exhaustion of IPv4 address space while IPv6 is deployed.”

Marc Blanchet, network engineering consultant at Viagénie, co-chairs the Sunsetting IPv4 working group. According to Marc, “One may be surprised how much IPv4 is so glued into our protocols, provisioning, applications, tools, products and networks, that it will require some work to remove it gracefully. In a nutshell, this is the mission of the IETF sunset4 working group.”.

For example, with today’s desktop computers, it is common for the computer to keep asking the network (via DHCP for IPv4) for an IPv4 address, even after a perfectly acceptable, routable IPv6 address has been configured on the computer. While this behavior is a correct in a dual-stack IPv4/IPv6 network, how should the network or computer react in a network for which an IPv4 address will never be provided by a DHCP?

In another example, the working group is pondering what to do in the case where IPv4 is not configured on the LAN. When a computer requests an address for a DNS name, an A record (containing the IPv4 address for the DNS name) is typically requested by default on a dual-stack host in addition to a AAAA record (containing the IPv6 address for the name). In an IPv6-only network, requesting the A record is simply unnecessary.

The IETF designed the eventual replacement for IPv4 in the mid-1990s when it became obvious that there weren’t sufficient addresses in the IPv4 design to support the global growth of the onetime research project called the Internet. It is truly amazing that the Internet continues to be a common communications link among the world’s cultures and nations. IPv6 ensures that the Internet continues to scale internationally. Like an airplane, the Internet is hampered by the “drag” caused by network address translation (NAT) and conservative IPv4 address allocation. When IPv6 can be implemented and IPv4 “obsoleted”, the global community can realize the full efficiencies that the Internet can offer.

Putting Your Intelligent DDoS Mitigation System to the Test

By: Gary Sockrider -

If you are reading this, it’s likely you have already deployed an Intelligent DDoS Mitigation System or plan to do so soon. It’s a great feeling to know you are seeing and stopping attacks. It’s also important to know that you have the systems properly tuned and your operators are prepared to deal with attacks in the future. As with any type of response activity, practice makes perfect. To that end it’s a good idea to have a DDoS simulator on hand.

By simulating a DDoS attack you can verify that you are catching the real ones. It’s also a great way to fine tune your mitigation for optimal performance. Last and most importantly, you can run drills at regular intervals. In this way your team can practice identifying and dealing with threats in real time without having to put production resources at serious risk. Drills can also be useful for training new employees.

We know that DDoS attacks can be multi-dimentional and even though you have the right tools in place, you really don’t know if your team is up to the challenge.  You need some sort of multi-dimentional tool to simulate real world attacks.  It isn’t enough to simply use a script that sends SYN packets towards a single host.  In order to know how to use countermeasures, you need a tool that can send multiple types of attacks. Ideally, that tool will also be easy to use.

Recently, I got to spend some time the folks at BreakingPoint. What I liked about their solution was the combination of simplicity and power. They have pre-configured Denial of Service attacks to evaluate your defenses.These include application-layer, VoIP and brute force attacks such as: HTTP Fragmentation, SlowLoris, SSL Renegotiation, UDP Flood, VoIP Flood, and  IPv6 Extension Header Fragmentation among others. They can also simulate legitimate traffic combined with multiple types of DDoS for a very realistic test environment.

Last month at Cisco Live! in San Diego, Arbor and BreakingPoint teamed up for a live demonstration at the World of Solutions. Using BreakingPoint’s Firestorm system, Arbor Consulting Engineer, Scott Rikimaru, was able to easily create a DDoS attack profile simulating SlowLoris. During the live demonstrations Scott would initiate the attack from the Firestorm against an Arbor Pravail APS appliance. The attack immediately became visible on the Pravail APS and then Scott began mitigation by switching into “Active Mode”.  The audience got to see the  mitigation in real time with attack traffic being dropped and legitmate traffic passed.

We all know the threat landscape is constantly changing. Make sure you test your IDMS deployment regularly so you can keep it running in top condition and get the most out of your investment.

 

World IPv6 Launch: How did we get here?

By: Arbor Networks -

By Darren Anstee, Solutions Architect for EMEA and Scott Iekel-Johnson, Product Manager

Now that we are in the thick of IPv6 Launch Day and seeing the payoff to a lot of hard behind-the-scenes work on the part of many ISPs and content providers, we thought it would be interesting to take a longer look at how we got here. Was IPv6 Launch Day a flick of the switch that suddenly turned on large volumes of IPv6 traffic? Or has it been a more gradual process of testing, service enablement, and gradual rollout of IPv6 connectivity?

To answer these questions we pulled IPv6 traffic data for the last year from the same 15 native IPv6 providers that have been included in our detailed IPv6 Launch Day reports. This graph shows the amount of native and tunneled IPv6 traffic these providers have carried over the last year, expressed as a percentage share of all Internet traffic. Please note that in order to capture longer term trends, this graph is showing the daily peak rate from each provider, which may not correspond exactly to the short-term measurements provided in our other data.

The first thing we noticed was a steady increase in IPv6 traffic volume over the past year (dating back to last year’s IPv6 Day). This slow but steady growth continued up until about 1 week ago, at which point it suddenly took off. Presumably, this is due to providers testing and then turning on IPv6 services in preparation for IPv6 Launch Day.

We are very pleased to see an overall bump of up to 33% in IPv6 usage in the runup to IPv6 Launch Day. Because we are measuring IPv6 as a share of all IPv6 traffic, this means that not only was there an increase in the overall IPv6 traffic volume, but this shift represents users who were using IPv4 actually migrating to IPv6 for at least some of their Internet usage. This is exactly the type of trend we need to see if IPv6 is going to become an accepted and standard part of how people use the Internet.

World IPv6 Launch: Break-Out Time for IPv6

By: Arbor Networks -

By Darren Anstee, Solutions Architect for EMEA and Scott Iekel-Johnson, Product Manager

We are now starting to drill down into the data we have on the native IPv6 traffic that is out there today. Interestingly, the break-down of the traffic does not appear to have shifted that much from what we have been seeing in recent samples, with HTTP being dominant as we would now expect (based on previous IPv6 observation data),

Figure 1.

However, a few things do leap out from the graph above. Firstly there seems to be much more use of ‘Other UDP’ since early on Tuesday this week, Figure 2. We are continuing to investigate what this might be, but we have seen an increase in file sharing (Bittorrent) traffic over IPv6 so far today based on UDP port analysis.

There has also been a general increase in other TCP application usage. From port-based analysis, some of this traffic appears to be an increase in SMTP traffic over IPv6, rising from negligible levels yesterday to 1.3% of TCP traffic today. This may indicate that with IPv6 Launch Day some email services as well as web-based services have successfully transitioned into IPv6.

There also seemed to be an initial increase in the use of HTTPS, and other SSL services over IPv6, just after midnight last night although this appears to have reduced to ‘normal’ (as per yesterday) levels now,

Figure 3.

As the day goes on we’ll continue looking more deeply into the data to identify patterns as they emerge.

World IPv6 Launch Day: Early Returns

By: Arbor Networks -

By Darren Anstee, Solutions Architect for EMEA and Scott Iekel-Johnson, Product Manager

IPv6 Launch Day has now been ongoing for several hours and we are starting to see trends emerge in the traffic data we are collecting from our ATLAS data participants.  For this analysis we have chosen to examine only those ATLAS participants who are reporting native IPv6 traffic.  This allows us to make clear and consistent comparisons between usage of native IPv6 connectivity and the use of IPv6 tunneling.  Other providers may be carrying native IPv6 traffic but are simply unable to report it due to technical limitations  (some router platforms that don’t support exporting traffic data for native IPv6 traffic).

First, let’s look at the overall volume of IPv6 traffic as observed at the peering edge of those providers which are reporting both native and IPv6 traffic to us.  These providers cover a range of sizes and locations, from Tier 1 and tier 2 ISPs, MSOs, and smaller regional providers across North America and EMEA.

As we can see, the overall volume of IPv6 traffic peaked at a higher rate last night due to an approximately 20% increase in native IPv6 traffic.  This would seem to represent an increase in the number of users and the amount of content being delivered over native IPv6 connections as providers enable more of their services for native IPv6 access.  Since then, traffic has decreased back to typical levels for the overnight low. This may indicate that participation for IPv6 day is lower in Europe, which should already be showing an increase now that Europe is well into the business day.  It could also reflect bias in the set of providers that are able to provide IPv6 measurements due to infrastructure limitations in reporting of native IPv6 traffic.

As more of North America starts it’s day we will be following the trends to see if IPv6 traffic continues to grow today to even higher levels after the official start of World IPv6 Launch Day.

 

World IPv6 Launch Day: The view from ATLAS

By: Arbor Networks -

By Darren Anstee, Solutions Architect for EMEA and Scott Iekel-Johnson, Product Manager

With the arrival of World v6 Day it’s time to see how far down the trail to IPv6 adoption we have come in the past year. Arbor will be utilising data from some of its customers, via our ATLAS Internet monitoring infrastructure, to measure the traffic changes during (and after) World IPv6 Launch. We will be looking at a number of different data sets to compare and contrast what is going on, and to illustrate both how far IPv6 adoption has come and how far it has to go. Before we start to look at what is going on right now, it is worth taking a quick recap so that we can see what has changed in the past year – as the Internet Society states ‘The World is Different Now…’

So, what did we see last year? Well we saw a doubling of the amount of IPv6 traffic tracked by the ATLAS system during the day, which represented a change from approximately 0.012% of internet traffic to 0.024% of internet traffic,

Figure 1:

Where are we today? Well, things are moving forward over the past year with the amount of IPv6 traffic we are tracking having increased substantially. IPv6 now peaks at around 0.1% , Figure 2, of the traffic we track from operators who are capable of generating telemetry for native IPv6 traffic – this represents a 20x growth over the past year, before World v6 Launch. Overall though, despite this rapid growth rate, the amount of IPv6 traffic out there is still very low in comparison to IPv4. In the last week the maximum volume of IPv4 traffic tracked from all Arbor ATLAS participants was 189.81Tbps, in comparison the maximum level of IPv6 traffic (native and tunnelled combined) was 24.07Gbps – a big difference.

Arbor will be tracking any changes in IPv6 traffic throughout World v6 Launch using data gathered from ATLAS participants. The ATLAS system is continuously gathering data from around 228 Arbor customers, and 124 of those are providing some information on the level of IPv6 traffic on their networks. However, of those, only 32 provide statistics on Native IPv6 traffic – maybe due to lack of native IPv6 support, lack of traffic or more likely lack of visibility (an issue highlighted by 60% of respondents in this year’s WorldWide Infrastructure Security Report). We will be focusing in on a subset of these thirty-two ATLAS participants for the majority of our statistics today – let’s see what happens.

World IPv6 Day: Final Look and “Wagon’s Ho!”

By: Rob Malan -

After reflecting on the data from IPv6 day, the phrase the best comes to mind is: “Wagon’s Ho!” It’s going to be a long hard slog to IPv6-Land. Yesterday’s IPv6 flag day looks to have been a success. After a decade of implementation work by the infrastructure vendors in building towards IPv4 functional parity, combined with the months of preparation by the content and service providers in constructing the routing and namespace frameworks, IPv6 day came off successfully. For a 24 hour period starting at midnight UTC, anyone with IPv6 access connectivity could get to some of the largest content providers’ data through their v6 stacks. With six of our customers’ help, we were able to get a glimpse into some of the details of the day.

Figure 1. Application breakdown for native IPv6 traffic from our six carrier partners.
click to view full size image

For a bright 24 hour period, shown in Figure 1, the IPv6 network looked a little bit more like its IPv4 big brother. As we have shown in some of our previous posts, the traffic mix for the IPv6 network could be best described as flotsam and jetsam: encrypted file transfers, peer to peer traffic, and experimental protocols. However, during yesterday’s v6 day the mix was dominated with web traffic. The proportion of web traffic grew during the day up until the midnight cutoff point where some of the major content providers withdrew their namespace support. At midnight UTC the web traffic falls off the cliff and the traffic mix returns to its pre-v6-day chatter.

Figure 2. Percentage of IPv6 traffic of all Internet traffic in our six carrier partners.
click to view full size image

Figure 3. Proportion of Native IPv6 traffic versus total IPv6 traffic in our six carrier partners.

click to view full size image

The good news shown in Figure 2 is that IPv6 traffic roughly doubled during the v6-day period. However, doubling a fraction of a percent, is still a fraction of a percent. These datasets correlate anecdotally with those from a lot of providers that we’ve talked with at our customer summit this week in Amsterdam. Combined with the results shown in Figure 3, they lead us to think more about the access side of the Internet. Even with a quad-A record in their DNS response, we just didn’t see Internet clients switching over in mass to the IPv6 content servers. It’s not surprising when you think about the level of indirection almost all subscriber side internet connections use. Unless you plug your home PC directly into the cable/dsl modem (another potential point for v4/v6 breakage), you probably have at least a mediating DNS caching device (home router or wireless basestation) that may not elegantly switch back and forth from v4 to v6. The inertia and complexity of changing this element of the Internet is massive.

Again, I’m left thinking of a Wagon train metaphor. Yesterday was the start of a long road that will take us to IPv6-land. It will pass through the more efficient use of IPv4 address space due to market forces; the operational pressures to not run two separate networks that need debugging and maintenance; and the not insignificant security threats introduced by the incredible complexity and new boundary conditions of the juncture of v4 and v6 networks. I have no doubt that the wagons will eventually get there, but it will not be easy.

Additional resources:
Internet Society: Participant Dashboard
RIPE NCC: World IPv6 Day Measurements
Google: World IPv6 Day
Akamai: IPv6 Statistics
Comcast: IPv6 Day Q&A
Comcast Leverages Arbor Peakflow SP to Facilitate IPv6 Transition: Featuring John Brzozowski, Comcast’s Chief Architect for IPv6

IPv6 – Is 2010 the year of the big plunge?

By: Carlos Morales -

IPv6 is one of the biggest topics of hallway conversations at the Austin, TX NANOG conference last week ranking right up there with “what I did last night” and “did you try the barbeque from xxxx?”

The questions on many people’s lips are “What are you doing with IPv6″ and “when are you rolling it out?” 

This is a change from past meetings I’ve attended where IPv6 was talked about but it clearly wasn’t foremost on most people’s minds.   This year, most folks seem to be doing a lot more thinking and planning around IPv6.  I spoke to a smattering of ISPs, content providers and eyeball (MSO and DSL) networks and all were along the path of putting an IPv6 framework in place – peering agreements being reviewed, IPv6 network technology being analyzed or implemented, costs being analyzed.    

The heavy IP address users, the content providers and the eyeballs, are the ones that will drive the mass migration.   They see the signs of IP address exhaustion and see the wall coming; the countdown timers show that IANA will run out of space in 576 days and estimates say that the RIRs will run out of space in ~ 2.5 years.  One challenge is that ARIN is still handing out IP address blocks with little to no resistance.   This ensures business continuity but it also makes it so that some people, particularly those responsible for the bottom line,  don’t perceive the gravity of the situation and hold back major IPv6 initiatives.  The evidence of IPv4 exhaustion is so overwhelming that it is only a matter of time before the objections are overcome and major IPv6 initiatives begin across the Internet community.

The other traditional objection to IPv6 migration was that vendors did not support it.  That’s not the case anymore.  Most vendors are delivering now on IPv6 roadmaps.  There’s definitely not the extent of technologies and tools that there are for IPv4 but providers now have choices.   

That brings me back to NANOG where lots of folks are talking to each other to find out who is doing what, when.  IPv6 requires extensive cooperation between providers and customers so unlike other technologies, mass adoption is a mandate for it to be successful.  Aside from the cost of moving to IPv6, there’s considerable nervousness within the community about moving forward because of the unknowns involved in IPv6.  Complexity, training, performance, security and interoperability are all major factors in the fact that the mass IPv6 migration hasn’t happened even after over 15 years of availability and after it became clear that the ultimate exhaustion of IPv4 space was imminent.

The analogy I can think of is that the Internet community is a set of people crowded onto a long pier.  The community is now taking up most of the pier and it will soon be filled.   The folks on the peer can jump in the water and get endless room.   There are some known challenges with jumping: the water is cold, some of the people don’t swim very well and they know that they’ll get their clothes wet.  There are a number of unknowns:  What else is in the water that can hurt me?  Will a fellow swimmer latch onto me and make me drown, is there a strong current that’ll carry me away?    Sure, some folks are in the water already but they waded in from the shore and most are only ankle or knee deep.  Only a small handful are over their heads.  Eventually, everyone is going to jump in the water but everyone is waiting for someone else to take the first plunge. 

In September 2009, my colleague Craig Labovitz reported that IPv6 still represents much less than 1% of all Internet traffic.  Is 2010 the year that we see the first mass migration and we start seeing a more significant amount of IPv6?   From what I’m hearing here at Nanog, it just might be…

For those who are considering the plunge, a report was just published by NIST about the considerations when deploying IPv6.

IPv4 Exhaustion::Trading Routing Autonomy for Security

By: Danny McPherson -

To see who’s been paying attention, let’s kick this off with a quiz. What do the following three items have in common:

  1. Allocation authentication (i.e., titles) for Internet numbers (i.e., IPv4 & IPv6 addresses, AS Numbers)
  2. Inter-domain routing security on the Internet
  3. IPv4 exhaustion

If your answer was along the likes of:

  • 2 requires 1
  • 3 requires 1 if IP addresses become resources
  • 3 has implications on 2, in particular from a scalability perspective

Then you’re pretty close.

One of the big problems with securing inter-domain routing on the Internet is that no central authoritative verifiable source exists for who owns a particular routing domain identifier or set of IP addresses, and which routing domain(s) are authorized to advertise that address space. Now, I know you’re thinking, what about IANA, and Regional Internet Registries (RIRs) such as APNIC, ARIN and AfriNIC, and all that stuff? Well, true, IANA allocates blocks of addresses and AS numbers to RIRs, who subsequently allocate those numbers to Local Internet Registries (LIRs), National Internet Registries (NIRs), or directly to ISPs or other network operators.

However, that’s pretty much as far as it goes. That is, allocations from RIRs have no impact on what’s actually routed on the Internet, or who uses what IP address space. We’d all like to think it does, especially the RIRs, and a sort of MAD model suggests it to be the case, but it isn’t. To illustrate this point consider The CIDR Report, which suggests 317 potentially bogus AS numbers, and 392 potentially bogus route announcements that are being advertised in the global routing system today. Note that ‘bogus’ in this case refers to unallocated by IANA or an RIR, or no record of allocation exists.

Basically, if you’ve got an AS number and a BGP session with a willing peer or two, you could advertise into the routing system pretty much whatever IP space you’d like and start using that space – as illustrated with the YouTube and Africa Online Kenya route hijacks as of late. Heck, you could even register it in one of 50 or so Internet Routing Registries (IRRs) as yours, assuming they don’t verify actual RIR allocations (e.g., as RIPE does). It’s not something I’d recommend, but if there’s not contention for that advertisement and use of that address space (i.e., someone else is using it, either legitimately or not) then it’s all yours – until it’s legitimately allocated (or not) and someone else starts using it – then there’s contention.

Now, as you might suspect, if you’re an RIR and your whole reason for existence is management of Internet number resources, you might consider this a threat. Or, if you’re me, you might consider it something that’s been fundamentally broken and in need of attention for a long time now, but mostly ignored because the appropriate folks didn’t have the right incentive to invest in the egg part of this chicken/egg problem.

Enter the egg incentive::IPv4 exhaustion. Consider this:

Then one might surmise that the value of an IPv4 address is about to increase considerably. Not only is the value going to increase, a market for trading of IP numbers resources is about to emerge. Don’t believe me? Have a look at the last ten thousands or so emails on ARIN’s public policy mailing list (PPML) – which is full of network engineers turned economists. But wait, isn’t management of IP resources the responsibility of RIRs? But they don’t actually have any control over this today, and as such, how could they possibly maintain some semblance of control?

Ahh, enter Resource PKI and SIDR, with community and specifically RIR work on Resource Certification. In short, this work is aimed at providing an infrastructure that enables certification of “Right of Use” for IP addresses and AS numbers with X.509 Resource Certificates. If this infrastructure exists then it can be used by RIRs to maintain control of IP numbers resources. It could also be used by folks for informational purposes, or to define routing policies based on a verifiable source, or even directly employed by the routing system itself through protocols such as SBGP.

Upon full employment of such a system, the fundamental change here is that the IP resources allocation hierarchy that exists today, which is sort of an out of band function that has no direct consequence on what’s actually routed, now could have direct control over what’s routeable, what’s actually routed on the Internet, and perhaps most importantly, what’s not. So, if you don’t pay your RIR membership fees, your address allocations could actually be revoked, and this could trickle its way into the routing system, where filters might be augmented to discard your route announcements, or into a protocol like SBGP where it’s actually automated.

This to me represents a fundamental change – RIRs will be taking on an operational role they’ve never had. If their systems are compromised or unavailable, or have some policy mandated by government or other entities, it could have considerable consequences.

With that, let’s take a step up. With this RPKI thing who’d be the trust anchors (TAs) in the certificate hierarchy? Well, IANA gives address space to RIRs, so maybe they should be the root? Or should RIRs be the root TA for space they’ve been allocated from IANA? Or is it a multi-TA system with the RIRs and IANA? Surely IANA will need to be the root for at least the legacy space they allocated that pre-dates RIRs, as well as reserved IPv4 and IPv6 space, and all that space that has yet to be allocated to RIRs.

OK, so IANA and/or the RIRs “hold the keys”. But wait, doesn’t IANA fall under an ICANN umbrella? Doesn’t ICANN operate under an agreement from the US government, specifically, the Department of Commerce, something from which they’d prefer to become more independent? Wasn’t there some reluctance from the DNSSEC community because of perceived Internet governance by the US?

If this RPKI thing exists, and folks use it to secure the routing system, could sanctions or embargoes now include what essentially results in revocation of a country’s Internet address space and associated Internet connectivity privileges? That’s certainly a feature that does NOT exist in today’s Internet routing system. And such a capability is actually far more powerful than that of a DNS corollary, as you could have multiple root DNS systems on the same IP infrastructure (ask China), but you can’t have multiple disjoint IP allocation structures in the same routing system (which one might argue we have today).

I’ve been rambling for a bit, I should probably wrap this up. Takeaways:

  • SIDR and RPKI work are being driven by the RIRs for reasons well beyond that of simply enabling secure routing on the Internet
  • IPv6 is coming, IPv4 address space exhaustion is for real, and we’ll all likely be feeling some pain from this very soon
  • If you operate a network, you’d better be paying attention, as some fundamental changes to your world are on the horizon.

FWIW, I think the SIDR and related work is, as evidenced, necessary. It’s just that we need to be well aware of what we’re trading off.