This topic is to discuss the following lesson:
Looks like the third example have mistakes. The summary address should be 2001:DB8::/60. can you confirm??
Got it. I have done the same mistake which have mentioned. I have calculated wrongly before reading details.
“Be careful that you don’t accidently convert number 12 from decimal to binary.”
It should be /59. In the 4th hextet, we have 11 similar bits.
16 + 16 + 16 + 11 = 59
Good that you have found it It’s easy to see 12 (twelve) instead of 12 (one two).
Wow. Rene, Thank you.
OMG I cannot believe how easy IPV6 is. Granted this is my first time passing through these lessons and if I didn’t recover or think about what I just learned it could easily be forgotten but you really have me looking at it differently.
I like to count backwards from right to left when doing my summaries and one thing about hex that makes it easy is that its in blocks of 4 “0000” so its always “8 4 2 1” those are easy numbers to work with and that part is just simple math but more pattern and grouping really and I love patterns and groupings its how my mind tends to associate and think.
so find the like pattern then count from left to right (that’s your first pattern grouping) then count backwards from right to left and stop just where your pattern ends and blam you have your summary. Now the tricky part was what you mention about making sure to not go from decimal to binary. I did that as well treating the 12 as the first octet. when it was actually a “1” and a “2” but other than being careful with that summarization is easy with IPV6.
who would have thought I would be able to do that when I first started looking at IPV6 for my COMPTIA and even later for my CCENT and then CCNA I was like this is something only some really crazy smart person could get its not ever going to be usable or practicable but now with these lessons something has just clicked into place and I went from that to wow I can do this and really its easy…
Excellent excellent lesson. The prefixes are really starting to make sense. It’s only a matter of realizing you’re dealing with hex and not with decimal when converting to binary. Just keep working with the nibbles.
Glad to hear you like it Max!
It takes time to get used to hex/nibbles. When you just started, it’s easy to forget you are working with hex, not decimal. A common trap is to translate something like 10 (decimal) to 00001010 while it should be 0001 0000 since it’s hexadecimal.
Keep practicing and it will become much easier.
I understand that 2001:DB8:1234:AB80::/57 is the “optimal” summarization of 2001:DB8:1234:ABA2::/64 and 2001:DB8:1234:ABC3::/64. but I see this summarization include all the pool [2001:0db8:1234:ab80:0000:0000:0000:0000 - 2001:0db8:1234:abff:ffff:ffff:ffff:ffff] …which must be precised in the documentation
then, if there is no constraint in the exibit asking to exclude all before 2001:db8:1234:ab7f:ffff:ffff:ffff:ffff
and all after 2001:0db8:1234:ac00:0000:0000:0000:0000, I think an “industrial” summarization may be 2001:DB8:1234:AB00::/56 (pool from AB00 to ABFF) or, more of that, 2001:DB8:1234:AA00::/55 . then, with a good, industrial (but ip expensive) IP hierarchical organization, no documentation at all must be done.
(I think, for example, about a ccna question asking "is 2001:db8:1234:aa00::/55 a possible summarization of 2001:DB8:1234:ABA2::/64 and 2001:DB8:1234:ABC3::/64)
Am I right ?
I understand that 2001:DB8:1234:AB80::/57 is the “optimal” summary of 2001:DB8:1234:ABA2::/64 and 2001:DB8:1234:ABC3::/64. but I see that this summary includes the whole pool [2001:0db8:1234:ab80:0000:0000:0000:0000 - 2001:0db8:1234:abff:ffff:ffff:ffff:ffff] … which must be specified in the Lan documentation.
Then, if there is no constraint in the exibit asking to exclude everything before 2001:db8:1234:ab7f:ffff:ffff:ffff:ffff and everything after 2001:0db8:1234:ac00:0000:0000:0000:0000 I thinks that an “industrial” summary can be 2001:DB8:1234:AB00::/56 (pool from AB00 to ABFF) or, even more , 2001:DB8:1234:AA00::/55. then, with a good industrial IP hierarchical organization (but expensive in IP), no Lan documentation should be made.
(I think, for example, a question from the ccna that poses "is 2001:db8:1234:aa00 : 55 a possible summary of 2001:DB8:1234:ABA2 : 64 and 2001:DB8:1234:ABC3 : 64)
Am I right ?
Yes, you are correct in your logic. The purpose of the exercise was to further understand how prefixes work. The most precise or optimal summary is indeed /57 however, a /56 would be easier to work with, and would be what you would most likely choose in a real life example (unless you are restrained due to the use of neighbouring addresses.
I hope this has been helpful!