Design and Concept of IPv6 addresses
ON THIS PAGE: Design and Concept of IPv6 addresses
-
Allowing a poor design to sabotage the deployment project is a bad idea.
-
Designing with Simplicity in Mind
-
Creating for Scale
-
Future-proofing the design
-
Efficiencies in Design
-
What's the deal with the Interface-ID?
Allowing a poor design to sabotage the deployment project is a bad idea.[ps2id id='Allowing a poor design to sabotage the deployment project is a bad idea.' target=''/]
Bad DNS preparation, inadequate monitoring, unanticipated programme activity, and poor IPv6 help in peripheral support, management, or protection systems are only a few of the factors that lead to IPv6 implementation projects being delayed or failing. When the initial IPv6 address design is discovered to be incomplete, several implementation programmes are temporarily halted – in several circumstances, the address design has had to be reworked several times.
Perhaps worse than an IPv6 address configuration that puts a project on hold is one that is only nice enough to get the job done but horrible enough to cause the network to have costly operational issues for years.
The address architecture should be viewed from the start of the IPv6 implementation planning process. This article goes into some of the things you can think about while designing an IPv6 address.
IPv6 is an Internet Layer protocol for packet-switched internetworking that enables end-to-end datagram transfer over different IP networks while closely following to the architectural principles established in the protocol's previous version, Internet Protocol Version 4. (IPv4).
IPv6 not only provides additional addresses, but it also includes capabilities not seen in IPv4. When switching network connection providers, it simplifies elements of address setup, network renumbering, and router notifications. It simplifies packet processing in routers by delegating responsibility for packet fragmentation to end points. By limiting the size of the host identification part of an address to 64 bits, the IPv6 subnet size is standardized.
RFC 4291 defines IPv6's addressing architecture, which allows for three kinds of transmission: unicast, anycast, and multicast.
Most network architects are too young to recall a time when IPv4 address space was not a scarce resource. We're all vulnerable to any indication of waste in an IPv4 address architecture, but we tackle new projects with the expectation of thoroughly analysing each network segment and providing only enough addresses to satisfy requirements. VLSM (Variable Length Subnet Masking) is used to carefully carve out adequate subnet space while attempting to ensure that each subnet has enough host addresses.
One of the most difficult aspects of designing IPv6 addresses is abandoning much of those conservative design ethics. Consider the standard practise of assigning a /64 to a subnet in an IPv6 network, even point-to-point connections. The benefit of doing that is that your subnetting would be consistent around the board, eliminating the VLSM headaches. However, it still leaves them itchy: The thought of providing a subnet of 1.8446744074 x 1019 usable addresses and just utilising two of them – understanding that you would never, ever use more than two – seems absurd.
It's even inefficient. However, since most networks' IPv6 address space is so big, you can tolerate a surprising amount of waste in return for accuracy, simplicity, size, and performance. With a /32 prefix, you will build 4.3 billion /64 subnets, this is the same number of subnets as there are IPv4 addresses. Trying to apply standard IPv4 address saving techniques to an IPv6 design may be akin to investing $200 to save $2.
While much of your complaint about address wasting may be dismissed, current IPv4 address management should be reviewed. There are two perspectives on this problem. In the one side, the more IPv6 addressing can be integrated with existing procedures, the better it would be for your operations staff. If, on the other side, the current address management activities are ineffective, now is the time to make improvements.
Many, if not most, of my clients are willing to leave what they perceive to be an insufficient, unreliable, or non-existent IPv4 address management workflow.
Such policies that filter on an IP address must be examined in addition to address management procedures. Routing, summarization, and compliance policies are examples of these. Again, the research can strike a compromise between what is familiar and valuable and what has been in need of change for a long time.
If you're one of the many network administrators who still handles IP addresses using spreadsheets, now is a smart time to invest in IP Address Management tools. Excel has little hex help beyond a basic formula that transforms decimal to hexadecimal inside a single cell. Hex numbers must be inserted as text, and inserting long hex number strings is time-consuming and error-prone. In designing IPv6 address templates for my clients, I've spent many a sleepless night mindlessly typing thousands of hex numbers into cells.
A decent IPAM kit not only simplifies and secures IPv4 and IPv6 address management, but also DNS and DHCP management.
Designing with Simplicity in Mind[ps2id id='Designing with Simplicity in Mind' target=''/]
Technical and operations staff will have to glance at and attempt to make sense of those hideous IPv6 addresses every day, even though they have a cool IPAM programme. The simpler your addresses are to decipher, the less common errors you'll create.
Begin by sketching out the sections of the address space that you have to deal in. You can have a prefix that is often the same – normally 29, 32, 48, or 56 bits, depending on the scale of the network. Except for such types of addresses, such as loopbacks, the last 64 bits, the Interface-ID, can normally be ignored. The parts you have to deal with are the ones between the allocated prefix and the Interface-ID.
The 8 bits between a 56-bit prefix and the Interface-ID obviously has much less stability than the 32 bits between a 32-bit prefix and the Interface-ID. However, if you have a 56-bit prefix, you still have a limited network and don't need anything more than plain subnet numbers.
Class the pieces in your workable space by hex digit when you plot them out (four bits per digit). Then determine what "meanings" you'll like in your addresses to make them easier to understand. Geographic positions (such as country, neighbourhood, POP, or office), conceptual topologies (such as OSPF area or basic subnet number), form designations, and consumer / user IDs are all possible meanings.
Then, rather than individual bits, attempt to fit your given definitions to hex digits. The trick to maintaining your concept straightforward is to do the following: Time is saved and danger is minimised if the employees may decode the significance of one or more hex digits without needing to translate the address to the bit stage.
Consider the following scenario: your network is divided into nine zones, each of which has 100 offices and 75 subnets. You might use one hex digit as a Field ID (one hex digit is 4 bits, giving you 16 Country IDs), two hex digits as an Office ID (two hex digits is 8 bits, giving you 256 Office IDs per area), and two digits as a Subnet ID (two hex digits is 8 bits, giving you 256 Subnet IDs per region) (256 Subnet IDs per office). A /44 prefix is required at the very least; a /40 will leave you with plenty of space.
Your engineers can soon learn to concentrate only on the hex digits that are relevant to the job at hand – those between the allocated prefix and the Interface-ID. Instead of having to pull in 32 hex digits (128 bits), they just look at the 8 digits following a /32 prefix, 6 digits following a /40, 4 digits following a /48, or 2 digits following a /56.
Lower-order bits' format can differ depending on the "meaning" specified in higher-order bits in larger networks needing more design sophistication. Assume you have two data centres, each with 2000 subnets, in addition to the nine regions in the illustration above. Region IDs E and F could be used to locate data centres, and instead of a two-digit Office ID and two-digit Subnet ID, a four-digit Subnet ID could be used (for 65,536 subnets per data center).
But don't go overboard with the number of "meanings" in your plan. If four layers are enough to teach your engineers what they need to know about an address, there's no need to introduce ten layers of hierarchy to your address architecture. This leads to yet another easy solution: As far as practicable, use sequences of zeroes in your emails. 2001:DB8:2405:C:27 is a lot better to interpret and write down than 2001:DB8:2405:83FC:72A6:3452:19ED:4727. Why use the second address if the first has ample details to handle the network?
Creating for Scale[ps2id id='Creating for Scale' target=''/]
“Scale” and “scalability” are two of the most overused terms in the network architecture language, and I'm sure I've contributed to them being cliched buzzwords. Regardless, if we're concerned about protocols, computers, logical topologies, or addresses, the idea of scaling is critical to successful architecture. You don't want anything that won't evolve with you.
The wonderful thing about IPv6 is that you can always get away with being inefficient in certain ways, such as having subnets with much more addresses than would actually be used, while also leaving space for development at the subnet level and beyond.
A /40 prefix, as I said, will allow our basic (and admittedly simplistic) example design some breathing space. I have said that you can use zero space to shorten the total address as far as possible. The zero space should be labelled "Reserved" and scattered around your design so that several fields will extend into it if necessary.
The Area, Office, and Subnet IDs in the example design need 5 hex digits (20 bits). You have 6 hex digits (24 bits) to deal with whether you have a /40 prefix. Place the Reserved digit between the Region ID and the Office ID, rather than make the 11th hex digit the Region ID, the 12th and 13th digits the Office ID, the 14th and 15th digits the Subnet ID, and the 16th digit Reserved.
The positioning of the 4-bit Reserved digit between the Region and Office IDs not only makes the Office and Subnet IDs fall on more tidy borders, but it also allows you consistency if you ever need it: If you underestimated future development, then the Region or Office IDs will expand into that room, or you can use the space to introduce another layer of hierarchy if future requirements demand it.
Future-proofing the design[ps2id id='Future-proofing the design' target=''/]
Trying to predict potential uses because you don't realise what the future holds is a problem for any network architecture. Anticipating the unexpected seems to be a futile task, and it is at times. However, if you allow reasonable use of reserved room and allocate it well, you'll have a greater chance of accommodating potential needs with a basic extension of definitions within the current architecture rather than needing to do a full overhaul.
Most IPv6 allocations have a wide working area, which helps you “future-proof” your address architecture. You will often reserve an entire space behind your allocated prefix, allowing you to introduce a new format without abandoning your current one.
Another thing to remember is that IPv4 will become redundant at some stage in the future – no one knows when, although I believe it will be earlier than most people predict. The cost, danger, and complexity of running two versions of IP in a network would be the trigger for accelerated IPv4 obsolescence. Since IPv6 is the only way forward, network operators can make a concerted attempt to phase IPv4 out of their networks at some stage.
Given the presumption, only use IPv4 addresses in your IPv6 template if there is a compelling cause to do so. Any engineers, for example, can make the last 32 bits of an IPv6 loopback address the same as the IPv4 loopback address of the computer. Is this, though, really beneficial?
After all, the IPv4 bits would be stored in hex, making them inaccessible to operations personnel: Is it obvious that the last 32 bits of the IPv6 address 2001:DB8:1305:7C::C0A8:53E5 are the IPv4 address 192.168.83.229?
An attempt to "integrate" IPv4 addresses into IPv6 addresses is a step backwards in time, rather than forwards to an IPv4-free future. If IPv4 is finally phased out of your network, a poor design could force you to use an out-of-date addressing scheme.
Efficiencies in Design[ps2id id='Efficiencies in Design' target=''/]
Your preliminary analysis of routing, summarization, and protection policies pays off in terms of assisting you in developing an address architecture that maximises the performance of any system that must filter on the source or destination address of an IPv6 packet. If a filter has to search a long way into an address to locate the bits that cause a "hit," your list of filter rules will quickly expand. As you consider the amount of possible addresses inside your IPv6 prefix, the list may quickly become unmanageable.
To reflect as many individual addresses as possible, aim to plan the addresses such that any “bits of interest” to a filter occur early in the address (either the prefix portion or the Interface-ID part).
What's the deal with the Interface-ID?[ps2id id='What's the deal with the Interface-ID?' target=''/]
With the potential (and debatable) exception of point-to-point device addresses, the majority of Interface-IDs in your network would be 64 bits. If you choose to use stateless address autoconfiguration (SLAAC) somewhere in your network, it's critical that the Interface-IDs in those segments stay 64 bits.
Whether you're assigning addresses statically or via DHCPv6, this is another way to use a lot of allocated zero bits to make the addresses simpler. You might, for example, allocate just the last 12 bits and leave the other 52 bits unassigned. Isn't that enough? It offers you 4,096 addresses per subnet.
12 or 16 bits often allows you to have any randomization of your Interface-ID allocations, reducing the sensitivity to port scans that start at the lowest Interface-ID and work their way up to locate functioning devices on a subnet.
At the same time, certain identifier digits within the Interface-ID might be needed, either for subnet level filtering or for quick recognition of system types within a subnet. In this scenario, use any of the Interface-leading ID's bits on the opposite end of the interface-specific bits, and again leave zero space between them. If you're going to use identifiers in the Interface-ID, make sure they're category identifiers. The first 64 bits of the address preceding the Interface-ID should include all position definitions.
The Interface-massive ID's 64-bit capability gives you plenty of space for identifiers, plenty of addresses per subnet, and the freedom to keep the total address minimal.
When I used to teach networking fundamentals lessons, I always told my students to be cautious about interpreting IPv4 addresses at the dotted decimal level; instead, they could practise translating each of the four decimal numbers into their binary equivalents before they could look at a list, say 240, and instantly see 11110000. The patterns of the bits, not the decimal value defining the bits, determine how a router interprets an IP address.
IPv6 is a little simpler to read at the hex level with a decent interface and no VLSM to obfuscate anything. However, there are always loads of legitimate reasons to search for patterns in individual bit values from time to time. As a result, being able to easily convert between hex and binary is just as critical when operating with IPv6 as it is when working with IPv4.
This transformations can be made quickly and easily using a few basic tricks. (And no, you can't depend on a mathematical calculator to do the conversions for you all of the time.)
What do you think about Ipv6? do you use at your home or your business? leave your opinion in this comment section and don't forget to bookmark this website if you don't want to loose any update about Cisco lessons, exercise and all news about Technology.
https://www.techguruhub.net/2021/05/11/design-and-concept-of-ipv6-address/?feed_id=76617&_unique_id=62a47a6623399
Comments
Post a Comment