Twelve Steps to Enable IPv6 in Government and Enterprise Networks
• 10 min read
In the first part of this two-part series, I shared a recent IPv6 deployment case study I worked on for a government network in the LACNIC region, concentrating on the hereditary peculiarities in the network that we had to overcome, many of which are common among government and organisational netwo…
“Good job, Jordi. I see that at the WAN level for point-to-point connections more than 60% of ISPs use a / 64. Some believe that a / 127 or / 124 is better for configuring the interfaces at each WAN end. ¿ What explanation will you find for this?. ¿ You recommend that each point-to-point WAN interface be configured with masks of / 127, / 124 or / 64 ?. Tks”
The point here is that in some situations, there is a need for other layer 3 devices to be in that link, so if you use a /127 you can't number them. Also, there are features that you may not use today, and require 64 bits, and if in the future you want to use, you will need to renumber. ¿What happens with technologies that today are point-to-point and later can become point-to-multipoint, or need addresses for redundancy, etc.?, again you will need to renumber. I think planning ahead and using /64 is not wasteful on IPv6 resources, but can save a lot of headaches and human resources later on. Last but not least, there are hardware architectures that if you use a /127 (or something else), is actually taking two slots, one for the /64, one for the /127, so this also means saving resources if you use /64. One possibility, that many ISPs are using, already mentioned in the article, simplifies many things, is using the /64 from the customer /48 for the point-to-point. So definitively I will encourage to use GUA /64, either from the same pool, a different pool, or the customer pool.
“Thanks for this Jordi, I just tweeted it out.”
Tks!
“Regarding monitoring, I've just recently have had a interessing experience. The just recently brought out Flow and Packet performance suite Steel Central from Riverbed is still lacking proper IPv6 support. I was very surprised that IPv6 isn't still not handled at the same priority as IPv4 in terms of development. So it's not always the engineers that may hesistate the extra or double effort when setting monitoring up, sometimes it's just the lack of IPv6 support in the monitoring tools. However, the post-sales guy from Riverbed promised improvement of IPv6 support on the road map.”
You're right, I should have mention that in most situations is not the engineer, are the tools. However, there are many "free" tools that may alleviate this, in case your vendor still didn't got it.
Showing 23 comment(s)