Building network automation solutions

9 module online course

Start now!

Category: IPv6

Worth Reading: Is IPv6 Faster Than IPv4?

In a recent blog post, Donal O Duibhir claims IPv6 is faster than IPv4… 39% of the time, which at a quick glance makes as much sense as “60% of the time it works every time”. The real reason for his claim is that there was no difference between IPv4 and IPv6 in ~30% of the measurements.

Unfortunately he measured only the Wi-Fi part of the connection (until the first-hop gateway); I hope he’ll keep going and measure response times from well-connected dual-stack sites like Google’s public DNS servers.

add comment

Video: IPv6 RA Guard and Extension Headers

Last week’s IPv6 security video introduced the rogue IPv6 RA challenges and the usual countermeasure – RA guard. Unfortunately, IPv6 tends to be a wonderfully extensible protocol, creating all sorts of opportunities for nefarious actors and security researchers.

For years, the networking vendors were furiously trying to plug the holes created by the academically minded IPv6 designers in love with fragmented extension headers. In the meantime, security researches had absolutely no problem finding yet another weird combination of IPv6 headers that would bypass any IPv6 RA guard implementation until IETF gave up and admitted one cannot have “infinitely extensible” and “secure” in the same sentence.

For more details watch the video by Christopher Werny describing how one could use IPv6 extension headers to circumvent IPv6 RA guard

You need Free ipSpace.net Subscription to watch the video.
add comment

Video: Rogue IPv6 RA Challenges

IPv6 security-focused presentations were usually an awesome opportunity to lean back and enjoy another round of whack-a-mole, often starting with an attacker using IPv6 Router Advertisements to divert traffic (see also: getting bored at Brussels airport) .

Rogue IPv6 RA challenges and the corresponding countermeasures are thus a mandatory part of any IPv6 security training, and Christopher Werny did a great job describing them in IPv6 security webinar.

You need Free ipSpace.net Subscription to watch the video.
add comment

IPv6 Unique Local Addresses (ULA) Made Useless

Recent news from the Department of Unintended Consequences: RFC 6724 changed the IPv4/IPv6 source/destination address selection rules a decade ago, and it seems that the common interpretation of those rules makes IPv6 Unique Local Addresses (ULA) less preferred than the IPv4 addresses, at least according to the recent Unintended Operational Issues With ULA draft by Nick Buraglio, Chris Cummings and Russ White.

End result: If you use only ULA addresses in your dual-stack network1, IPv6 won’t be used at all. Even worse, if you use ULA addresses together with global IPv6 addresses (GUA) as a fallback mechanism, there might be hidden gotchas that you won’t discover until you turn off IPv4. Looks like someone did a Truly Great Job, and ULA stands for Useless Local Addresses.

read more see 3 comments

Video: Practical Aspects of IPv6 Security

Christopher Werny has tons of hands-on experience with IPv6 security (or lack thereof), and described some of his findings in the Practical Aspects of IPv6 Security part of IPv6 security webinar, including:

  • Impact of dual-stack networks
  • Security implications of IPv6 address planning
  • Isolation on routing layer and strict filtering
  • IPv6-related requirements for Internet- or MPLS uplinks
You need Free ipSpace.net Subscription to watch the video.
add comment

OMG: Hop-by-Hop Path MTU Discovery

Straight from the “Bad Ideas Never Die” (see also RFC 1925 Rule 11) department: Geoff Huston described a proposal to use hop-by-hop IPv6 extension headers to implement Path MTU Discovery. In his words:

It is a rare situation when you can create an outcome from two somewhat broken technologies where the outcome is not also broken.

IETF should put rules in place similar to the ones used by the patent office (Thou Shalt Not Patent Perpetual Motion Machine), but unfortunately we’re way past that point. Back to Geoff:

It appears that the IETF has decided that volume is far easier to achieve than quality. These days, what the IETF is generating as RFCs is pretty much what the IETF accused the OSI folk of producing back then: Nothing more than voluminous paperware about vapourware!

see 1 comments

Soap Opera: SRv6 Is Insecure

I heard about SRv6 when it was still on the drawing board, and my initial reaction was “Another attempt to implement source routing. We know how that ends.” The then-counter-argument by one of the proponents went along the lines of “but we’ll use signed headers to prevent abuse” and I thought “yeah, that will work really well in silicon implementations”.

Years later, Andrew Alston decided to document the state of the emperor’s wardrobe (TL&DR: of course SRv6 is insecure and can be easily abused) and the counter-argument this time was “but that applies to any tunnel technology”. Thank you, we knew that all along, and that’s not what was promised.

You might want to browse the rest of that email thread; it’s fun reading unless you built your next-generation network design on SRv6 running across third-party networks… which was another PowerPoint case study used by SRv6 proponents.

add comment

Do We Need Multiple Global IPv6 Addresses Per Interface (RFC 7934)

I was happily munching popcorn while watching the latest season of Lack of DHCPv6 on Android soap opera on v6ops mailing list when one of the lead actors trying to justify the current state of affairs with a technical argument quoted an RFC to prove his rightful indignation with DHCPv6 and the decision not to implement it in Android:

[…not having multiple IPv6 addresses per interface…] is also harmful for a variety of reasons, and for general purpose devices, it’s not recommended by the IETF. That’s exactly what RFC 7934 is about - explaining why it’s harmful.

If you’re new to this discussion, you might want to start with Why Does DHCPv6 Matter blog post
read more see 1 comments

Why Does DHCPv6 Matter?

In case you missed it, there’s a new season of Lack of DHCPv6 on Android soap opera on v6ops mailing list. Before going into the juicy details, I wanted to look at the big picture: why would anyone care about lack of DHCPv6 on Android?

Please note that I’m not a DHCPv6 fan. DHCPv6 is just a tool not unlike sink plunger – nobody loves it (I hope), but when you need it, you better have it handy.

The requirements for DHCPv6-based address allocation come primarily from enterprise environments facing legal/compliance/other layer 8-10 reasons to implement policy (are you allowed to use the network), control (we want to decide who uses the network) and attribution (if something bad happens, we want to know who did it).

read more add comment

Worth Reading: Do We Need Segment Routing?

Etienne-Victor Depasquale sent me a pointer to an interesting NANOG discussion: why would we need Segment Routing. It’s well worth reading the whole thread (until it devolves into “that is not how MPLS works” arguments), which happens to be somewhat aligned with my thinking:

  • SR-MPLS makes perfect sense (excluding the migration-from-LDP fun)
  • SRv6 (in whatever incantation) is mostly a vendor ploy to sell new chipsets.

Enjoy!

add comment

MUST Read: Operational Security Considerations for IPv6 Networks (RFC 9099)

After almost a decade of bickering and haggling (trust me, I got my scars to prove how the consensus building works), the authors of Operational Security Considerations for IPv6 Networks (many of them dear old friends I haven’t seen for way too long) finally managed to turn a brilliant document into an Informational RFC.

Regardless of whether you already implemented IPv6 in your network or believe it will never be production-ready (alongside other crazy stuff like vaccines) I’d consider this RFC a mandatory reading.

add comment
Sidebar