10 Jul

Calculating IPv6 subnets outside the nibble boundary

Often this comes into the subnetting discussion by my friends who are deploying IPv6 for the first time. How do you calculate subnets outside the 4-bit nibble boundary? This also happens to be one of starting points of APNIC IPv6 routing workshop where I occasionally instruct as community trainer.

 

So what is a Nibble boundary?

In IPv6 context, it refers to 4 bit and any change in multiple of 4 bits is easy to calculate. Here’s how: Let’s say we have a allocation: 2001:db8::/32. Now taking slices from this pool within 4 bit boundry is quite easy.

/36 slices (1 x 4 bits)
2001:db8:0000::/36
2001:db8:1000::/36
2001:db8:2000::/36
and so on…

 

/40 slices (2 x 4 bits)
2001:db8:0000::/40
2001:db8:0100::/40
2001:db8:0200::/40

 

/44 slices (3 x 4 bits)
2001:db8:0000::/40
2001:db8:0010::/40
2001:db8:0020::/40

 

/48 slices (4 x 4 bits)
2001:db8:0000::/40
2001:db8:0001::/40
2001:db8:0002::/40

 

Clearly, it seems much simple and that is one of the reasons we often strongly recommend subnetting within the nibble boundary and not outside for all practical use cases. However understanding why it’s easy this way, as well as things like how to subnet outside nibble boundary for cases, say if you are running a very large network and have a /29 allocation from RIR.

 

Going back to fundamentals

IPv6 address consists of 128 bit addressing and is represented in hexadecimal.
IPv6 address:  _ _ _ _: _ _ _ _ :_ _ _ _ :_ _ _ _ :_ _ _ _ :_ _ _ _ :_ _ _ _ :_ _ _ _ 

Each dash here represents is written in hexadecimal and represents 4 bits, thus 4+4+4+4 = 16 bits in each block and 16 x 8 = 128 bit addressing. This brings that magical 4-bit nibble boundary.

So if we expand 4 bits into binary, we can have following combinations for each “dash” in above representation:

 

Here I have simply represented 4 bits from lowest to highest. Remember just like in the decimal system with base 10 (which we all are familiar with), we follow same logic in binary system where we start from lowest (0 0 0 0) and go to next digital (0 0 0 1) and now since it’s base 2, we go to next logical number which is (0 0 1 0) and so on. Now when we modify these 4 bits together, we do not have to worry about the decimal part but as soon as we try to go inside the 4-bit zone, we have to deal with the decimal counting.
So let’s take a real-world case of American Cable & broadband provider Comcast. They have an allocation 2001:558::/31:

 

What exactly /31 means here?

Going back by CIDR fundamentals /31 means 31 bits are reserved and remaining (128-31 i.e 97 bits) are available. How can they generate /32 or say /36 out of this allocation?

2001:558::/31
Writing in expanded form:

2001:0558::/31
(16 bits + 15 bits)

In above, first 16 bits are reserved for 2001 but for next part “0558” only 15 bits are reserved. Let’s expand the 2nd block further:

0 5 5 8 – 15 bits reserved

Here “0” gives 4 bits (and in binary is 0 0 0 0)
5 gives 4 bits (and in binary is 0 1 0 1)
Next 5 also reserves 4 bits
So far we are at (4 + 4 + 4) 12 bit count. Now that 15 bits are reserved, basically from “8” 3 bits are reserved and rest 1 bit is available for modification.

Let’s expand 8:

8 in hexadecimal = 1 0 0 0 in binary. Here 1 0 0  is reserved (each representing one binary bit and hence the three bits) and 4th bit can vary.
Hence possible combinations in binary are:
1 0 0 0
1 0 0 1

The remaining first three bits (1 0 0 ) cannot be altered as they are part of network mask. Now 1 0 0 0 in binary gives us “8” in hexadecimal and 1 0 0 1 gives us “9”. Thus possible /32s out of this /31 allocation are:

2001:558::/31 = 2001:558::/32  and 2001:559::/32

 

Similarly to calculate /36 slices from it, we can basically vary this 1 bit (as we just did) as well as next 4 bits altogether (5-bit variation). Hence possible /36 slices are:

2001:558:0000::/36
2001:558:1000::/36
2001:558:2000::/36
2001:558:3000::/36

and so on until 2001:558:f000::/36 (16 pools here)
and next,
2001:559:0000::/36
2001:559:1000::/36
2001:559:2000::/36
2001:559:3000::/36

and so on until 2001:559:f000::/36 (16 pools here). Thus we get these 32 /36 blocks out of /31 allocations.

 

That’s all about IPv6 subnetting. Once you understand this part, you should be just fine with subnetting in the future. 🙂

24 Feb

APNIC Hackathon at APRICOT 2018

APNIC and RIPE NCC are doing a hackathon at APRICOT 2018. It just started today with some light interaction with various participating members yesterday.

https://2018.apricot.net/program/hackathon/

The theme of the hackathon is around IPv6. Many cool projects were suggested yesterday and teams started working today on certain shortlisted projects like:

  1. A tool for ranking CDNs – A tool based on RIPE Atlas data to rank CDNs based on latency across different regions.
  2. An IPv6 fun word game – Where anyone with a member account can suggest a word, and compete with other members who share more IPv6 addresses. It may include things like showcasing creative use of hexadecimal strings in an IPv6 address like Facebook popularly does face:b00c in their IPv6 pools.
  3. IPv4 and IPv6 network security  – Study of attacks and overall security in IPv6. It would involve study and possibly a report on various attack vectors in the IPv6 domain.
  4. A countrywide report on IPv6 deployment – I have yet to see how it is different from existing other reports.
  5. IPv6 tunnel detection – Figuring out where tunnels used and figuring out the IPv4 address of those endpoints via a javascript plugin and possibly comparing IPv4 Vs IPv6 performance.

Let’s see how things go in next 12hrs. Super fun. Things should show up on Github in next few hours. 🙂

Disclaimer and misc points:

  1. It’s a hackathon and final thing may vary greatly from the original idea. Let’s see how things evolve.
  2. The final tool which uses such idea/code may be awesome but for next 12hrs it will be more around proof of concept and small demo instead of a full-fledged tool in certain cases.
  3. I am part of the jury for the hackathon.