# Beware of IPv6 Transition Techniques as Endgame

By now, even the non-technical folks out there are aware of IPv4 address exhaustion (The IPocalype), thanks to the problem finally coming into the consciousness of the mainstream media. As organizations plan how to deal with this exhaustion, those who do the right thing and choose to deploy IPv6 (instead of trying to teach the IPv4 elephant how to dance using NAT) at some point are likely to choose and deploy one or more transition techniques. These are mechanisms that are supposed to smoothen the migration from IPv4 to IPv6… or will they? They certainly have the potential to do so (smoothen the transition), but network architects must make sure that these transition techniques don’t end up as the seeds of a new problem by becoming ends in themselves rather than a means to an end (full native IPv6).

Failure in transition techniques do and will result in a backlash from users that give the end-game (IPv6) a bad reputation (when you hear comments like “IPv6 is not yet operational”, “It doesn’t work” in various forums, look close by and you’ll find a bad IPv6 experience lurking not far away).

My focus on this post is to caution us that the general human tendency to focus on the short term, look for quick-fix solutions, combined with the reluctance to change could turn these well-meaning transition techniques into obstacles to full blown native IPv6 deployment. There is a precedent for this kind of thing happening – Network Address Translation (NAT) and it’s sibling Network Address and Port Translation (NAPT). In response to the impending issue of IPv4 shortage in the early 1990s, Egevang and Francis proposed NAT as a solution (see RFC 1631). The authors of NAT were well aware of the dangers I am highlighting here, hence their warning:

“NAT has several negative characteristics that make it inappropriate as a long term solution, and may make it inappropriate even as a short term solution.” – K. Egevang and P. Francis – RFC 1631

Looking at where we stand today, network engineers ignored that warning and today NAT is so ingrained in the thought processes of network engineers that it (in its various forms) is being pitched as an alternative to implementing IPv6 despite various documentation that the NAT-path isn’t the way to sustainable Internet growth and innovation.

The problem in this scenario was (and still is) “IPv4 Depletion”, and the two solutions are IPv6 (the fundamental solution – addresses the root cause) and NAT (the symptomatic solution – addresses the symptoms only). The symptomatic solution was supposed to be used temporarily to buy us time while we implemented the fundamental one. But we now know that the success of NAT is the a key reason that IPv4 lived longer than it was supposed to, which in turn kept IPv6 stagnant for about 20 years after being standardized.

This pattern of events fits perfectly the “Shifting the Burden” archetype in Systems Thinking which is described thus in the “The 5th Discipline” by Peter Senge

“A short term solution is used to correct a problem, with seemingly positive immediate results. As this correction is used more and more, more fundamental long term corrective measures are used less and less. Over time, the capabilities of the fundamental solution may atrophy or become disabled, leading to even greater reliance on the symptomatic solution“

An early warning symptom that you are dealing with this pattern of events can be spotted in statements like:

“Look here, this solution has worked so far, what do you mean there is trouble down the road?”

Here is a diagram of the “Shifting the Burden” model adapted to the IPv4, IPv6 context.

Shifting burden of IPv6 Deployment to transition techniques

Does this pattern of events look/sound familiar? … that’s because it is. As we have relied on NAPT more and more, fewer organisations have thought about implementing IPv6, some of the inertia simply based on the huge investments (financial, emotional and intellectual) that have been made in IPv4 and NAPT. When folks complain of the lack of feature parity of IPv4 with IPv6, they often fail to see that the said lack of feature parity is a direct consequence of the fact that they have not deployed and tested IPv6 to build operational competence with it. IPv4 did not mature overnight, it was through progressive use, improvements, feedback and re-use that it got it’s rich feature set. The end game of falling into this kind of thinking is that we will at some point end up with a system that is stuck at a mediocre level of performance (think sub-par IPv6 and all the problems that result when NAPT is over-used).

I make the case that all the current transition techniques we currently have are different variations of that sub-par system that we might end up in. Of course, some clueful folks will tell me there are no performance issues with some transition techniques, but I think there’s a reason we call them ‘transition’ techniques – they are a move towards an end-game, not the end-game itself.

The vicious cycle is perpetuated further by another occurrence: as the transition technique starts to work ‘better’ than broken implementations of native IPv6, organizations invest more resources in it to optimize it better, all of this investment happens at the expense of native IPv6 deployment which further makes the later less attractive while increasing the financial and emotional investments in the transition technique. This is a classic “Success to the successful” archetype in Systems Thinking which is illustrated below.

Impact of potential resource competition

So what can we do? (apart from building a time machine, going back to 1994, nipping NAT in the bud and directing all efforts into IPv6!). Here are a few ideas:

1. All IPv6 deployment plans should have as their objective native IPv6, any transition techniques deployed should be milestones to that end game. So project managers and CIOs, look out for that and demand it from suppliers, vendors and contractors and from your network engineers.
2. Leverage normal equipment and software refresh cycles to ensure that network and application elements support native IPv6. This builds end-game capability in existing systems, thus making sure that transition mechanisms will progressively not be needed.
3. Educators and trainers must continue to inform the world of the sub-optimal solution that non-native IPv6 is.

More importantly, I will like to know your suggestions and strategies for making sure this doesn’t happen or even if you think it’s a problem t beware of.

# Calculating IPv4 Summary Prefixes

Given a list of IPv4 prefixes of the same length, how do you find the summary address (or addresses) for them? This post describes a method and uses some worked examples to illustrate. The post draws deeply from the CCIE Routing and Switching Exam Certification Guide by Wendel Odom, with lots additions of mine for clarity as well as some procedures that are not described in the text. I assume that you already understand the standard terminology associated with IPv4 addressing in general.

## Definitions

• Block (B): Different subnet numbers are multiples of the block (B).
• The block for prefix length (P) is given by: $B(P) = 2^{8-P\%8}$.
• The modulo (MOD or %) operation simply finds the remainder of dividing one number by another. We are dividing by 8 here because each octet of an IPv4 address is 8 bits in length.
• Inclusive summary address: A summary that includes prefixes outside the range of prefixes you are summarizing.
• Exclusive summary address: A summary address (or addresses in some cases) that only includes prefixes within the range you are summarizing.
• Interesting Octet: the octet within the IPv4 address in which the prefix length falls. To find this, simply divide the prefix length by 8 and round to the next whole integer.

## General procedure

The general procedure to find the exclusive summary address(es) is as follows:

1. Find the inclusive summary route and use this as the first candidate exclusive address.
2. Determine the range of addresses of the candidate exclusive address. If it totally encompasses all the component prefixes, then this candidate is the exclusive summary address. If not, split the component candidate address into two with a new prefix length P’ = P + 1
3. Repeat step #2 for each half of the candidate summary address. As you do this several times, you will eliminate prefixes from the bottom and top of the range till you are left with just the exact prefixes that encompass all the candidate prefixes.

## Calculating the inclusive summary route

You should know (from your routing table) or from the problem set in an exam the following information

• A list of prefixes to summarize i.e. the component prefixes.
• The prefix length of the prefixes (P). This is the same for all component prefixes.

You use the given prefixes to find the inclusive summary route as follows:

1. Let the number of component prefixes be ‘s’
2. The number of bits required to give ‘s’ prefixes is given by ‘y’ where: $2^{y}$ ≧ s (take the next whole integer)
3. Calculate a new prefix length P’ = P – y
4. Calculate S0 – the subnet number when you take the lowest numeric subnet (e.g 192.168.20.0 is less than 192.168.25.0) in the list as an IP address with prefix length P’.
5. Calculate S1 – the subnet number when you take the highest numeric subnet in the list as an IP address with prefix length P’
6. If S0=S1 then this is the best summary route.
7. If S0≠S1, then repeat steps #4 and #5 with a new (shorter) prefix length P’= P’ – 1

## Calculating the exclusive summary route

1. Find the inclusive summary prefix and use it as a candidate exclusive summary prefix
2. Determine the range of the candidate summary, if all candidates prefixes fall within the range, then this is the exclusive summary prefix and you are done.
3. If the range of the candidate prefixes includes prefixes outside the component prefixes, split the candidate into two parts with length P’ = P +1 and repeat step #2 with each half.

## How to split a prefix into two parts

1. Find the new prefix length: P’ = P + 1
2. Calculate the block that corresponds to this new prefix length B(P’)
3. First part = candidate prefix
4. Second part = candidate prefix + B(P’) on the interesting subnet

## Worked Example #1 : Inclusive summary route

Find the inclusive summary prefix for: 172.31.20.0/24, 172.31.21.0/24, 172.31.22.0/24, 172.31.23.0/24

• Number of prefixes s = 4
• Prefix length of components P = 24
• Bits required y: 2^y >= s => 2^y >=4 thus y = 2
• New prefix length P’ = P – y = 24 – 2 = 22

Taking smallest component prefix as an address with new prefix length, we have 172.31.20.0/22

• Block B(22) = 2^(8-22%8) = 2^2 = 4
• Thus subnet number are multiples of 4 i.e. 4 , 8 , 12, 16, 20 , 24, etc
• Interesting octet is 3rd octet (22/8 = 2R6 = 3)
• This address belongs to subnet 172.31.20.0/22 = S0

Taking the highest component prefix as an address with new length, we have 172.31.23.0/22

• Block B(22) = 2^(8-23%8) = 2^2 = 4
• Thus subnet number are multiples of 4 i.e. 4 , 8 , 12, 16, 20 , 24, etc
• Interesting octet is 3rd octet (22/8 = 2R6 = 3)
• This address belongs to subnet 172.31.20.0/22 = S1

S0 = S1 thus the inclusive summary prefix is 172.31.20.0/22

## Worked Example #2 : exclusive summary route

Find the exclusive summary of 172.31.20.0/24, 172.31.21.0/24, 172.31.22.0/24, 172.31.23.0/24 ,172.31.24.0/24

We start of by finding the inclusive summary prefix first and using it as a candidate exclusive summary prefix.

• Number of prefixes s = 5
• Prefix length of components P = 24
• Bits required y: 2^y >= s => 2^y >=5 thus y = 3
• New prefix length P’ = P – y = 24 – 3 = 21
• Block B(21) = 2^(8-21%8) = 2^3 = 8
• Thus subnet number are multiples of 8 i.e. 8 , 16 , 24, 32 etc
• Interesting octet is 3rd octet (21/8 = 2R5 = 3)

Taking smallest component prefix as an address with new prefix length, we have 172.31.20.0/21 which belongs to subnet 172.31.16.0/21 = S0

Taking the highest component prefix as an address with new length, we have 172.31.24.0/21, which belongs to subnet 172.31.24.0/21 = S1

S0 ≠ S1 we repeat with prefix length decremented by 1

• New prefix length P’ = P’ – 1 = 21 – 1 = 20
• Block B(20) = 2^(8-20%8) = 2^4 = 16
• Thus subnet number are multiples of 16 , 32 , 48 etc
• Interesting octet is 3rd octet (20/8 = 2R4 = 3)

Taking smallest component prefix as an address with new prefix length, we have 172.31.20.0/20 which belongs to subnet 172.31.16.0/20 = S0

Taking the highest component prefix as an address with new length, we have 172.31.24.0/20 which belongs to subnet 172.31.16.0/20 = S1

S0 = S1 = 172.31.16.0/20 is the inclusive summary prefix

Now that we have the inclusive summary prefix, we can proceed to find the exclusive prefix using this as our first candidate.

First we establish the range of 172.31.16.0/20

• We know block is B(20) = 16 and the third octet is the interesting one
• The next subnet higher than 172.31.16.0/20 is 172.31.32.0/20
• Therefore range of 172.31.16.0/20 is 172.31.16.1 – 172.31.31.255 (this being the last address before 172.31.32.0/20)
• This range includes more prefixes than are in the component list (e.g .16.0/24 and .28.0/24)

We split 172.31.16.0/20 into two parts

• New prefix length P’= P’ + 1 = 20 + 1 = 21
• B(21) = 8
• Thus 172.31.16.0/20 = 172.31.16.0/21 & 172.31.24.0/21
 Split #1 172.31.16.0/21 172.31.24.0/21 Range 172.31.[16.1 – 23.255] 172.31.[24.1 – 31.255] Comments Includes .16.0/24 so we’ll need to split this again Only 24.0/24 is within range Thus 172.31.24.0/24 is one of the exclusive summary prefixes

Note: We use the block (B) to determine the component subnets and thus know what prefixes are included that shouldn’t be.

We split 172.31.16.0/21 into two parts

• New prefix length P’= P’ + 1 = 21 + 1 = 22
• B(22) = 4
• Thus 172.31.16.0/21 = 172.31.16.0/22 & 172.31.20.0/22
 Split #1 172.31.16.0/22 72.31.20.0/22 Range 172.31.[16.1 – 19.255] 172.31.[20.1 – 23.255] Comments Totally out of range, so we discard this Includes the remaining component prefixes apart from .24.0/24

Therefore, the exclusive summary prefixes for 172.31.[20-24].0/24 are 172.31.20.0/22 AND 172.31.24.0/24

## Worked Example #3 : Exclusive summary route

Find the exclusive summary prefix for 10.22.12.0/23, 10.22.14.0/23, 10.22.16.0/23 10.22.18.0/23

We start of by finding the inclusive summary prefix first and using it as a candidate exclusive summary prefix.

• Number of prefixes s = 4
• Prefix length of components P = 23
• Bits required y: 2^y >= s => 2^y >=4 thus y = 2
• New prefix length P’ = P – y = 23 – 2 = 21
• Block B(21) = 2^(8-21%8) = 2^3 = 8
• Thus subnet number are multiples of 8 i.e. 8 , 16 , 24, 32 etc
• Interesting octet is 3rd octet (21/8 = 2R5 = 3)

Taking smallest component prefix as an address with new prefix length, we have 10.22.12.0/21 which belongs  to subnet 10.22.8.0/21 = S0

Taking the highest component prefix as an address with new length, we have 10.22.18.0/21 which belongs to subnet 10.22.16.0/21 = S1

S0 ≠ S1 we repeat with prefix length decremented by 1

• New prefix length P’ = P’ – 1 = 21 – 1 = 20
• Block B(20) = 2^(8-20%8) = 2^4 = 16
• Thus subnet number are multiples of 16 , 32 , 48 etc
• Interesting octet is 3rd octet (20/8 = 2R4 = 3)

Taking smallest component prefix as an address with new prefix length, we have 10.22.12.0/20 which belongs to subnet 10.22.0.0.0/20 = S0

Taking the highest component prefix as an address with new length, we have 10.22.18.0/20 which belongs to subnet 10.22.16.0.0/20 = S1

Still, S0 ≠ S1 we repeat with prefix length decremented by 1

• New prefix length P’ = P’ – 1 = 20 – 1 = 19
• Block B(19) = 2^(8-19%8) = 2^4 = 32
• Thus subnet number are multiples of 32 , 64, etc
• Interesting octet is 3rd octet (19/8 = 2R4 = 3)

Taking smallest component prefix as an address with new prefix length, we have 10.22.12.0/19 which belongs to subnet 10.22.0.0.0/19 = S0

Taking the highest component prefix as an address with new length, we have 10.22.18.0/19 which belongs to subnet 10.22.0.0.0/20 = S1

S0 = S1 = 10.22.0.0/19 is the inclusive summary prefix

Now that we have the inclusive summary prefix, we can proceed to find the exclusive prefix using this as our first candidate.

First we establish the range of 10.22.0.0/19

• We know block is B(19) = 32 and the third octet is the interesting one
• The next subnet higher than 10.22.0.0/19 is 10.22.32.0/19
• Therefore range of 10.22.0.0/19 is 10.22.0.1 – 10.22.31.255 (this being the last address before 10.22.32.0/19)
• This range obviously includes more prefixes than are in the component list so we split it

We split 10.22.0.0/19 into two parts

• New prefix length P’ = P’ + 1 = 19 + 1 = 20
• B(20) = 16
• Thus 10.22.0.0/19 —> 10.22.0.0/20 & 10.22.16.0/20
 Split #1 10.22.0.0/20 10.22.16.0/20 Range 10.22.[0.1 – 15.255] 10.22.[16.1 – 31.255] Comments Includes ranges below 10.22.12.0/24 Includes ranges above 10.22.18.0/24 We’ll need to split this to trim the range from above

We split 10.22.0.0/20 into two parts

• New prefix length P’= P’ + 1 = 20 + 1 = 21
• B(21) = 8
• Thus 10.22.0.0/20 –> 10.22.0.0/21 & 10.22.8.0/21
 Split #2 10.22.0.0/21 10.22.8.0/21 Range 10.22.[0.1 – 7.255] 10.22.[8.1 – 15.255] Comments Totally out of range Includes the .12.0, 14.0 and 16.0 prefixes Still includes the prefixes below .12.0 and so needs to be split this prefix to trim it from the bottom

We split 10.22.8.0/21 into two parts

• New prefix length P’= P’ + 1 = 21 + 1 = 22
• B(22) = 4
• Thus 10.22.8.0/21 –> 10.22.8.0/22 & 10.22.12.0/22
 Split #3 10.22.8.0/22 10.22.12.0/22 Range 10.22.[8.1 – 11.255] 10.22.[12.1 – 15.255] Comments Totally out of range Contains the .12, .14 prefixes and nothing else

We split 10.22.16.0/20 from split #1 into two parts

• New prefix length P’= P’ + 1 = 20 + 1 = 21
• B(21) = 8
• Thus 10.22.16.0/20 –> 10.22.16.0/21 & 10.22.24.0/21
 Split #4 10.22.16.0/21 10.22.24.0/21 Range 10.22.[16.1 – 23.255] 10.22.[24.1 – 31.255] Comments Contains .16.0 and .18.0 but also .20 which we don’t want Split this again Totally out of range – discard

We split 10.22.16.0/21 from split #4 into two parts

• New prefix length P’= P’ + 1 = 21 + 1 = 22
• B(22) = 4
• Thus 10.22.16.0/21 –> 10.22.16.0/22 & 10.22.20.0/22
 Split #5 10.22.16.0/22 10.22.20.0/22 Range 10.22.[16.1 – 19.255] 10.22.[20.1 – 23.255] Comments Contains only .16.0 and .18.0 Totally out of range – discard

Therefore, the exclusive summary prefixes for 10.22.[12, 14 , 16, 18].0 /23 are 10.22.12.0/22 AND 10.22.16.0/22

## Conclusion

1. Be aware that when you summarize to certain prefix lengths, some operators might not accept them. Inefficient summary routes lead to bigger BGP tables.
2. Most ISPs and Regional Internet Registries (RIRs) will allocate you address space along boundaries that can easily be summarized neatly
3. The Block (B) will always increase in the progression: 2 , 4, 8, 16 , 32 , 64 , 128