Skip to main content

IPv6 Address Allocation BCP

Best Current Practices in for IPv6 Address Allocation
This Best Practices document aims to provide IPv6 Address allocation guidelines that a network operator can follow while planning the IPv6 sub-netting for its network (based on the issues faced and learning’s from IPv6 implementation in NKN and NIC network).

Best Current Practice:
1. Sub-netting
        IPv6 addresses generally written in Hex format. Each Hex number represents 4 bit, commonly known as nibble. A nibble boundary is a network mask that aligns on a 4-bit boundary. Sub-netting the v6 address at nibble boundary improves efficiency and make it easier to understand for humans* (Machine will anyway read it binary format J).

Example of Nibble and non-Nibble Boundaries Sub-netting
From the above example, we can clearly see that Sub-netting at the Nibble boundaries is easier to manage and do the sub-netting.
* Condition may arise where you may have to do non-Nibble based sub-netting. It depends on case-to-case basis But Nibble boundaries based sub-netting is the recommended one.

2. Every LAN segment should be assigned /64 prefix
        A /64 IPv6 segment provides 64 bits for network and hosts both. Every LAN segment should be provided /64 prefix regardless the size of the same. An IEEE’s 64-bit Extended Unique Identifier EUI-64 format (method by which host can automatically assign itself a unique ipv6 address) needs a LAN segment of /64.
/64 subnet is also required for Stateless Address Auto Configuration (SLAAC, refer RFC 4862).


3. Point-to-point Network

In case of point-to-point network, there is a flexibility of using /64 or /126 or /127 segment. As ip addresses are generally assigned manually in point-to-point link, so no benefit in using /64. If addresses are assigned to point-to-point link through SLAAC or EUI-64, then /64 is the only available option.
In case of manual assignment, /127 is the subnet which comes in mind. In some cases, we may face an issue called “subnet-router anycast” in routers while using /127 for point-to-point link (refer rfc 3627 for more details). The best available option will be using /126 for Point-to-point Links.


4. /48 blocks for every Site/Region/Customer

        For multi-homing in IPv6, minimum /48 segment is required. Every customer/Site should be allocated a /48 segment, irrespective of the size/LAN of the Region/Customer.
Next /48 should be reserved for every Customer/Site so as allocate the same if needed in future.


5. Hierarchical address planning

        There should always be a scope for further expansion of the network. Inefficient planning and little or no scope for expansion will led to end up in inefficient v6 address allocation and will also led to increase in the v6 routing table. As mentioned above, every site/region should be allocated /48 v6 block. In addition of this next /48 block should be reserved for that site. Continuous allocation helps in aggregation two /48 into single /47 segment (which will help us in minimizing the size of the v6 routing table).



6. Infrastructure Segment
       
        Infrastructure incl. Loopback addresses, WAN Links and others. First /48 from ISP resource pool should be reserved for this. We can further subnet this /48 into multiple /64 segments.

a. Loopback Addresses
Loopback is the most common address and in majority of times, it is used in configuration. It should be as concise as possible so as to help human in remember the same. Using first /48 from an ISP pool of /32 or /30 (or whatever the pool is) helps in suppressing the address to the maximum extent.
As for example, Suppose 2405:8A00::/32 is the ISP ipv6 address block, then we will have a following /48 subnet from the same :-

2405:8A00::/32
2405:8A00::/48
2405:8A00:0001::/48
2405:8A00:0002::/48
(snip)
2405:8A00:FFFF::/48

As clearly visible in above example, first /48 contains all zeros which can be combining to represent the segment in best concise manner. Loopback address needs to be /128 only. First /48 can be further segmented into multiple /64 and first /64 block will be used for loopback address allocation.
By using /64 segment, a scope is there for 2^64 unique loopback v6 addresses (which is more than enough for whole internetJ). As per current practice, use numeral only in last octet and leave alphabets altogether.

For e.g.:- Suppose loopback segment is 2405:8A00::/64. Loopback  addresses will be 2405:8A00::1/128, 2405:8A00::2/128, 2405:8A00::3/128, ……   2405:8A00::9/128. The next sequential address will be 2405:8A00::A/128. But as per best practice, this will be ignored (having alphabet in last octet).

Useful loopback addresses will be like:-

2405:8A00::/64
2405:8A00::1/128
2405:8A00::2/128
(snip)
2405:8A00::9/128
2405:8A00::10/128
(snip)
2405:8A00::9999/48
        b. WAN Links
Point-to-point links or WAN links requires only 2 useful addresses. Here any of the /127 or /126 or /64 can be used. It depends on the network design altogether. Whatever be used, uniformity should be maintained. As per practice, /126 is the optimal option as it save us from ‘subnet-router anycast’ and also use the address space from efficiently. /64 can be separated out from the Infrastructure pool for this purpose.
         For e.g.:-
                       
2405:8A00:0:1::/64
2405:8A00:0:1::0/126
2405:8A00:0:1::4/126
(snip)
2405:8A00:0:1::C/126
2405:8A00:0:1::10/126
(snip)
2405:8A00:0:1::1C/126


                

Popular posts from this blog

Is APNIC policy of Members Voting Rights doing the Justice with NIRs and Corresponding Countries

APNIC (the Asia Pacific Network Information Centre) is the regional Internet address registry (RIR) for the Asia-Pacific region, service 56 economies, including India, Bangladesh, China, Australia, Japan and others. APNIC is one of the world's five RIRs and is part of the Number Resource Organization (NRO). As of date, the following 7 NIRs (National Internet Registries) are registered with APNIC for serving the local community a b c -- NIR Serving Economy Member under each NIR d APJII (ID) Indonesia 2916 e CNNIC (CN) China  1399 IRINN (IN) India  3368 JPNIC (JP) Japan   474 KISA (KR) Korea Not Available TWNIC (TW) Taiwan   299 VNNIC (VN) Vietnam   624 APNIC Membership is classified into 7 tiers depending on the IP holding by each member. Each membership tier has voting rights. These voting rights play a crucial role in governance and policies matt
Read more

Identity PSK ( iPSK)

With the evolution of IoT (Internet of Things), devices that connect wirelessly have increased many folds. From webcams, Smartwatches, fitness bands, firestick, Alexa, Google Home, and many more.., everything is going wireless for connectivity and so does the security threat. The main concern with IoT devices is the unavailability of the full wireless protocol stack (and in the majority of devices, support of 802.1x is not available). So, previously we only have the WPA-PSK option for connecting the IoT devices.  In WPA*-PSK (WPA or WPA2) WLAN, a Pre-Shared Key (PSK) is configured and distributed to all the clients that connect to the WLAN. This leads to PSK leakage, and it can be accessible to unauthorized users (due to the nature of common PSK across all the devices).  Therefore, there was a need to provision unique PSK or Multiple PSK per SSID. Identity-PSKs are unique pre-shared keys created for clients/groups on the same WLAN. Features of iPSK:-   1.Unique PSK for individual Cli
Read more

Flaw in ServerKeyExchange messages of TLS Protocol

Here we will discuss the flaw in the ServerKeyExchange messages of the TLS protocol which caused the Logjam attack over TLS while using Diffie-Hellman Key Exchange. Before SSLv3, we don't use to authenticate the ServerKeyExchange messages where server negotiates with client regarding usage of cipersuite and parameters. From onwards SSLv3, TLS send the signed message where it mention about parameters it will use but remain silent over ciphersuite. Or in other words, signed portion contains parameters but not contain information about ciphersuite the server will going to use. Now just to remind you, the difference between DH and DH-EXPORT is the size of parameters only. So how to use this flaw - If the server supports DH-EXPORT, an attacker (Men-in-the-Middle) can edit the negotiation sent by the client (even if client doesn't support DH-EXPORT), and replace the list of client supported ciphersuite with DH-EXPORT only. The server will in turn send back a
Read more