IPv6 global unicast addressing using vlsm

[jc8342]

hello,

Two questions.

1) understood that we have 1st 64 bits to identify the network ID (global routing and subnet ID) and the last 64 to identify the network identifier. It seems like an awful waste of space to use the last 64 bits. Can the netmask be slid out to something more akin to IPv4, such as a /96 netmask or a /112 etc. I have set this up in the lab and it works fine. My question is how would that work in the route table of an Internet router. I can see sliding the mask over for serial links etc., but curious if this netmask is carried onto the Internet. My assumption is that we can legitimately move the mask of an organizations assigned space and the ISP will aggregate within their route table. Is this correct, or are we restricted to using 64 bits for all network identifiers, even when only 2 IP addresses are need such as a network link?

2) I have seen lots of commentary on the math regarding IPv6, but looks incorrect to me. I see many references to 2*(128) but that would not account for a quadrillion addresses. It seems to me the correct mathematical numbering would be 2*(16) X 2*(16)....repeated 128 times, since we are dealing with hexadecimal in each bit. Am i correct?

[maayre]

Hi there,

1) I think that it does seem like a lot f addresses but remember that IPv4 is 322 and the global prefix is 642, this is not double, it's a lot more! So there are 32^2 more /64 prefixes than IPv4 addresses. This struck me as odd too but I think this is how it is

2) So you wrote a "*", it should be "^" as in to the power of, eg;

2^8=256 (one byte)

EDIT: some of my ^ symbols didn't work first post

EDIT2: it might just be displaying wrong on my phone but were it says 322 and 642 it should be 32 'up arrow' 2 etc

[Peter Paluch]

Hi John,

To your first question, it is possible to make the prefix longer, and consequently to save addresses. However, there are some mechanisms inside IPv6 that expect to have full 64 bits available in the host part of the address, and may not work correctly if the host part is made shorter. Please read more in this thread:

https://supportforums.cisco.com/message/3456735#3456735

In short, technically, yes, enlarging the network part and shortening the host part of an IPv6 address is possible but must be done cautiously with respect to not breaking certain things that depend on the default length of the host part (if those mechanisms are not in use, you are free to do the "VLSM").

 I have seen lots of commentary on the math regarding IPv6, but looks  incorrect to me. I see many references to 2*(128) but that would not  account for a quadrillion addresses. It seems to me the correct  mathematical numbering would be 2*(16) X 2*(16)....repeated 128 times,  since we are dealing with hexadecimal in each bit. Am i correct?

No, this would not be correct - in each bit, you are not dealing with hexadecimal, as each bit can always hold only two values - 0 and 1, regardless how the value of a grouping of bits is written out (decimal or hexadecimal). Correctly, however, the total number of IPv6 addresses is 2^128, i.e. 2 raised to the 128th power. Using Python to compute the result, we get:

>>> 2**128

340282366920938463463374607431768211456L

Best regards,

Peter

[daudparvez]

Its not a good idea to shorten the last 64 host bits and add some of these into the network (Global Routing Prefix) part.

The reason behind this is that many router functions are performed on the assumption of host part=64 bits. An example is the automatic calculation of the Link Local Addresses by the router as soon as we enable the IPv6 on an interface. Also, the EUI 64 method of IPv6 Global Unicast Address assignment works on the assumption of host part=64 bits.

So its better to leave the host part at the recommended 64 bits boundary.

Irrespective of the the representaion of any no. in binary, decimal or hexadecimal, we can find the combinations represented by that no using the following simple eqation:

                                                ( BASE ) exponent (No. of Digits/Bits)

Lets find the combinations ( no.s) in a four bits binary no. As per above eqation, we have, (2) exp 4 = 16

Lets find the combinations (no.s) in a four digit decimal no. As per above eqation, we have , (10) exp 4 = 4000

Lets find the combination (no.s ) in a four digint Hexadecimal No. As per above equation we have , (16) exp 4 =  65635

From the above maths, we can derive,

No. of combinations in 128 bit no. = (2) exp 128 =  3.4 exp 38

If we represent it in Hexadecimal, it is represented int 32 digits hexadecimal no. In this case we find the no. of possible

combinations = (16) exp 32 = 3.4 exp 38

WE CAN SEE THAT BOTH ARE THE SAME. THUS IT'S JUST REPRESENTING A NO. IN DIFFERENT WAYS/BASES. THE HEXADECIMAL REPRESENTAION JUST PROVIDES US EASE OF USE BUT DOES NOT CAUSE ANY ADDITION OR REDUCTION IN THE NO. OF COMBINATIONS WHICH 28 BITS WILL REPRESENT.