Worth Reading: IPv6 Renumbering == Pain in the …

Johannes Weber was forced to stress-test the IPv6 networks are easy to renumber nonsense and documented his test results – a must-read for everyone deploying IPv6.

He found out that renumbering IPv6 in his lab required almost four times as many changes as renumbering (outside) IPv4 in the same lab.

My cynical take on that experience: “Now that you’ve documented everything that needs to be changed, make sure it’s automated the next time ;)”

Recent posts in the same categories

9 comments:

  1. Anonymous 07 September 2018 10:28
    Cisco has some magic for you: IPv6 Generic Prefix
    Replies
    1. Ivan Pepelnjak 07 September 2018 11:50
      I remember that feature. I either wrote about that a long while ago, or covered it in IPv6 design & configuration webinar: https://www.ipspace.net/Building_Large_IPv6_Service_Provider_Networks

      However, AFAIK, while you can use generic prefix to number interfaces, you can't use in an IPv6 ACL (even on the same box) or anywhere else in the network. Have I missed something?
  2. Eric Duplantis 10 September 2018 23:10
    Interesting read. I couldn't help but feel like this is an apples-to-oranges test, though. I can't deny that not having to renumber private IPv4 is less work than having to renumber IPv6, but I don't think that means that IPv6 is intrinsically all that much harder to renumber. How well does IPv4 fare when you do a merger/acquisition and have to renumber or internally NAT to avoid overlapping use of RFC 1918 addresses? What's even worse is that the addresses might not be as obviously wrong in ACLs/firewall rules/service configurations because you're still using 10 space, but that same prefix now means something different than it used to.

    Another thing is that a lot of the config files and firewall rules that had to be modified here were governing internal access (mail, logs, DNS, firewall rules to reach those things, etc.). To me this strikes me as a good case study on the importance of deploying ULA prefixes alongside global unicast. I suppose it's doubly important if you can foresee having to renumber (not having PI space, for example). Also, ULA's randomized prefixes help it avoid the circumstance above where you might be forced to readdress your private space.

    Nonetheless, still a good reminder that the existence of RAs and preferred lifetimes doesn't automagically trivialize re-addressing.
    Replies
    1. Johannes Weber 11 September 2018 14:17
      Hey Eric,

      yes, you are totally correct that the comparison between "using RFC 1918 for IPv4 <- no renumbering" to "using IPv6 GUI <- renumber" is not fair. Indeed, renumbering an IPv4 network with public addresses *inside* your network would be the same work as for IPv6.

      Hence the post at least shows that the current practice (RFC 1918 for IPv4 while GUA for IPv6) is unequal when it comes to an ISP change.

      And yes, it forces another discussion whether ULAs are good/useful or not. To my mind it is still recommended to avoid any kind of NAT/NPT/whatever to decrease the complexity of your network. You SHOULD go for PI space. However, not having PI space you must balance reasons whether to use ULAs (and NAT) or GUAs with the risk of renumbering...

      Thanks for your note anyway. I'll add a sentence to the blog post stating that it is not an "IPv6 is bad" thing, but rather an "since we don't use public IPv4 addresses inside our networks, we have new challenges with IPv6 when it comes to an ISP change".

      Ciao,
      Johannes
    2. Eric Duplantis 11 September 2018 17:49
      Hi Johannes, thanks for the note. Yes, I definitely got your original point as written --- the current addressing reality isn't changing so the asymmetry in difficulty still exists in practice. Adding a note might help misunderstanding for folks who are still on the fence about whether they should be deploying v6 at all :)

      And yes, I completely agree. NAT should be avoided unless absolutely necessary (AS multihoming with 2 sets of non-PI space?). The goal for ULAs is not to NAT66 it to the outside, but rather to put RFC 6724 to the test. If you construct your ACLs/rules around the ULA addresses and make sure that your DNS resolvers give out ULA addresses for local clients, they should make the right choice and connect with ULA even when a global address exists.
    3. Ivan Pepelnjak 11 September 2018 18:32
      "If you construct your ACLs/rules around the ULA addresses and make sure that your DNS resolvers give out ULA addresses for local clients, they should make the right choice and connect with ULA even when a global address exists." << I'm afraid that people who tested real-life implementations don't necessarily share your optimism ;))
  3. Eric Duplantis 11 September 2018 19:30
    I suppose that's why I phrased it as "put[ting] RFC 6724 to the test." I'm not as optimistic as the narrative I suggest...

    Do you know of any test results regarding implementations that have problems using multiple address classes? A lot of the case studies I've read have more been focused on Happy Eyeballs I and II with v4 rather than source v6 address choice. I haven't done my own testing (yet) as to how well implementers actually did ...
    Replies
    1. Enno Rey 11 September 2018 19:39
      Hi Eric,

      we did some RFC 6724 related testing a while ago. The results can be found here:
      https://static.ernw.de/whitepaper/ERNW_Whitepaper57_IPv6_lab_source_address_selection_signed.pdf
      slides of talk at RIPE74: https://ripe74.ripe.net/wp-content/uploads/presentations/108-ERNW_RIPE74_IPv6_AddressSelection.pdf
      video of that one: https://ripe74.ripe.net/archives/video/98/

      hope this helps,
      best

      Enno
    2. Eric Duplantis 11 September 2018 22:10
      Enno, this is a fantastic resource. Thanks for chiming in with this. I'm also pleasantly surprised to see that the real world implementations aren't actually as bad as they could have been considering the complexity of the rules.
Add comment
Home
Sidebar