Can I Use Shared (RFC 6598) IPv4 Address Space Within My Network?

Andrew sent me the following question: “I'm pushing to start a conversation about IPv6 in my organization, but meanwhile I've no RFC 1918 space left. What's your take on 100.64.0.0/10 - it's seems like this is available for RFC 1918 purposes, even if not intentionally?

Short answer: Don’t even think about that!

What is shared IPv4 address space?

The shared IPv4 address space (defined in RFC 6598) is non-private IPv4 address space that the service providers can use to deploy carrier-grade NAT (CGN) services.

Why do they need it?

Imagine the following scenario: your SOHO router (CPE) is connected to a residential ISP network. The ISP ran out of IPv4 addresses and deployed CGN to offer at least some IPv4 connectivity to new customers.

Unless the ISP uses MAP-E or DS-Lite (both of them use IPv6 in the physical access network), they still have to assign an IPv4 address to the outside interface of the CPE, but they don’t have any public addresses left. They cannot use RFC1918 address space because the outside IPv4 address assignment might overlap with whatever you’re using internally. The only solution is another block of non-public IPv4 addresses – 100.64.0.0/10.


IPv4-only CGN compared with DS-Lite or MAP-E

Why can’t I use 100.64.0.0/10 within my network?

Imagine the scenario from the previous paragraph in reverse: you’re using 100.64.0.0/10 within your enterprise network and a remote site gets assigned an IP subnet from the same address block on the outside interface. Someone is bound to be confused – first a router (or a few of them), then the poor engineer troubleshooting weird connectivity failures.

You could “solve” the problem by using VRFs on the remote site routers – put the Internet interface in a separate VRF (separating internal and public address spaces), use inter-VRF NAT for direct Internet access, and run IPsec tunnel with your corporate network across a transport VRF.

Scratch that! Stop being MacGyver and tell your manager it’s high time to move to IPv6 because you have the same problem as everyone else: you ran out of IPv4 addresses.

New to IPv6?

Start with Enterprise or Service Provider introduction webinars, the work your way through the whole IPv6 webinars roadmap. You can also get them all by buying IPv6 trilogy or the yearly subscription.

18 comments:

  1. Hi Ivan,

    Please correct typo, you used twice 10.64.0.0/10.
    It might be confusing to other readers.

    BTW, excellent post. It's nice to learn something new everytime visiting your blog.
  2. We have used (in albeit mostly non-routed networks) the 11.0.0.0/8 range. It belongs to the US Defence department, so we reason it's unlikely to be used by our customers to route to over the public Internet...
  3. I do not understand why Andrew's internal enterprise network cannot use a shared space that service providers use. He will not leak it to internet and he will NAT it as well. Just like them.
    Replies
    1. The routing "confusion" will happen if Andrew's network uses the shared range internally, and his own ISP also uses it for CGN purposes... Customers with CGN breakout IPS won't be reachable from Andrew's net... If I understood the whole story correctly :)...
    2. it still escapes me. I must be very dense. If Andrew is NATing that space where the confusion would arise? And If I am correctly understanding the NAT444, his ISP is double natting that possibly shared space as well before the packets are routed to Andrew.
    3. okay, my "confusion" was that I positioned Andrew's enterprise network to the right of the LSN node. I assumed that NAT444 is for home/soho broadband connections only. If you connect Andrew's network to that CPE though, it'll of course be confusing.
  4. Also don't forget about the good old 198.18.0.0 network ;)
  5. An odd recommendation, considering that RFC 6598 specifically states that 100.64/10 *can* be utilized as non-globally routable IP space.

    "Shared Address Space is IPv4 address space designated for Service Provider use with the purpose of facilitating CGN deployment. Also, Shared Address Space can be used as additional non-globally routable space on routing equipment that is able to do address translation across router interfaces when the addresses are identical on two different interfaces."

    That's hardly MacGyvering a solution together when the recommendation is right there in the RFC.
    Replies
    1. "Shared Address Space can be used as additional non-globally routable space on routing equipment that is able to do address translation across router interfaces when the addresses are identical on two different interfaces."

      Yeah, that's really easy to troubleshoot, isn't it? Not to mention the routing issues - have you tried to configure the same subnet on two LAN interfaces on Cisco IOS? When was the last time you were trying to fix something like that at 2AM on a Sunday morning?

      Subscribe to a few IETF mailing lists for a few months and you'll understand how "recommendations" like the one you quoted make it into the RFCs.
  6. This question made me cringe when I read it. I will fully admit that I have a pretty significant dislike for NAT and in general tend to be an IPv6 evangelist, but utilizing address space not meant for this private purpose is a long term disaster waiting to happen and sooner or later, it will cause problems. It may show up as odd routing inconsistencies, debugging nightmarish translation tables or something else equally unpleasant, you're essentially black holing that address space internally. It may come after you're long gone, but, again, it will happen.
    I was always taught that just because you *can* do something doesn't mean you *should* do it.
  7. The big question i have is: how did anyone manage to fill 10.0.0.0/8?
  8. Not just 10.0.0.0/8 but also 172.16.0.0/12 and 192.168.0.0/16!
    Replies
    1. Yes, it had me scratching my head.
  9. One of the biggest uses of this space I see outside of the intended CGN is as a NAT migration space to merge large enterprises with overlapping subnets. It functions as a transition space that is easily recognizable and the two networks can be renumbered without having to workaround migration address reservations in the renumbering process. If your Internet connectivity is solely based on BGP peerings/assigned RIR space, then there isn't much chance you would run into an issue with this IP block.
  10. I guess you have never considered the number of CM, MTA, QAM, ST Boxes in an MSO SP network with over 12 million subscribers
  11. Why not just do super-netting. Then you would get back some IP addresses. Say you make the network as 10.10.0.0/12, then you would have possible IPs such as 10.11.0.0 and 10.10.0.255 as usable IPs. Plus you wouldn't waste IPs for router interfaces such as 10.10.254.1.
Add comment
Sidebar