10-01-2011 02:49 AM - edited 03-07-2019 02:33 AM
Hi,
I have a few queries regarding IPv6 as mentioned below. Can someone please clarify these to me ?
1... Can we borrow bits from the Last 64 bits (Interface ID) into the network bits like we do in case of IP v4 ?
2.. I have found certain explanations regarding the Aggregatable Global Unicast IPv6 Addresses format as mentioned below:
(a) Some documents state that the Aggregatable Global Unicast Addresses are structured in FP, TLA ID, NLA ID, SLA ID and Interface ID
(b) Some documents define the Aggregatable Global Unicast Addresses to have a format of
GLOBAL ROUTING PREFIX + SUBNET ID +INTERFACE ID
Which one is valid?
Best Regards,
Solved! Go to Solution.
10-01-2011 03:15 AM
Hi Daud,
1... Can we borrow bits from the Last 64 bits (Interface ID) into the network bits like we do in case of IP v4 ?
Yes, we can. However, the RFC 5375 - "IPv6 Unicast Address Assignment Consideration" says in the Section 3:
Using a subnet prefix length other than a /64 will break many features of IPv6, including Neighbor Discovery (ND), Secure Neighbor Discovery (SEND) [RFC3971], privacy extensions [RFC4941], parts of Mobile IPv6 [RFC4866], Protocol Independent Multicast - Sparse Mode (PIM-SM) with Embedded-RP [RFC3956], and Site Multihoming by IPv6 Intermediation (SHIM6) [SHIM6], among others. A number of other features currently in development, or being proposed, also rely on /64 subnet prefixes. Nevertheless, many IPv6 implementations do not prevent the administrator from configuring a subnet prefix length shorter or longer than 64 bits. Using subnet prefixes shorter than /64 would rarely be useful; see Appendix B.1 for discussion.
An extremal use is using /127 prefixes on point-to-point links. It has been strongly discouraged in RFC 3627 along with description of what could go wrong. However, the RFC 6164 reevaluates that policy, and suggests that the /127 prefixes should again be allowed on point-to-point links, along with slightly changed IPv6 operations.
2.. I have found certain explanations regarding the Aggregatable Global Unicast IPv6 Addresses format as mentioned below:
(a) Some documents state that the Aggregatable Global Unicast Addresses are structured in FP, TLA ID, NLA ID, SLA ID and Interface ID
(b) Some documents define the Aggregatable Global Unicast Addresses to have a format of
GLOBAL ROUTING PREFIX + SUBNET ID +INTERFACE ID
Which one is valid?
According to the most recent IPv6 addressing architecture described in RFC 4291, the (b) option is correct. The (a) option was originally proposed with earlier revisions of IPv6 addressing architecture - RFCs 1884, 2073, 2373, 2374, 3513, but in RFC 3587, this approach of structuring IPv6 address was dropped.
The formatting according to (a) may actually be still used internally among ISPs and with allocating IPv6 address blocks because it is still valid according to the current IPv6 addressing architecture, but it does not have to be upheld that way. The (b) option is much more relaxed in this sense.
Best regards,
Peter
10-01-2011 03:11 AM
Hi,
1) No we can't. the 48 first bits is global prefix then we have 16 bits to subnet and then 64 bits for host part.
2) both are correct but I think the first one is now deprecated in favor of latter one.
Regards.
Alain.
10-01-2011 03:15 AM
Hi Daud,
1... Can we borrow bits from the Last 64 bits (Interface ID) into the network bits like we do in case of IP v4 ?
Yes, we can. However, the RFC 5375 - "IPv6 Unicast Address Assignment Consideration" says in the Section 3:
Using a subnet prefix length other than a /64 will break many features of IPv6, including Neighbor Discovery (ND), Secure Neighbor Discovery (SEND) [RFC3971], privacy extensions [RFC4941], parts of Mobile IPv6 [RFC4866], Protocol Independent Multicast - Sparse Mode (PIM-SM) with Embedded-RP [RFC3956], and Site Multihoming by IPv6 Intermediation (SHIM6) [SHIM6], among others. A number of other features currently in development, or being proposed, also rely on /64 subnet prefixes. Nevertheless, many IPv6 implementations do not prevent the administrator from configuring a subnet prefix length shorter or longer than 64 bits. Using subnet prefixes shorter than /64 would rarely be useful; see Appendix B.1 for discussion.
An extremal use is using /127 prefixes on point-to-point links. It has been strongly discouraged in RFC 3627 along with description of what could go wrong. However, the RFC 6164 reevaluates that policy, and suggests that the /127 prefixes should again be allowed on point-to-point links, along with slightly changed IPv6 operations.
2.. I have found certain explanations regarding the Aggregatable Global Unicast IPv6 Addresses format as mentioned below:
(a) Some documents state that the Aggregatable Global Unicast Addresses are structured in FP, TLA ID, NLA ID, SLA ID and Interface ID
(b) Some documents define the Aggregatable Global Unicast Addresses to have a format of
GLOBAL ROUTING PREFIX + SUBNET ID +INTERFACE ID
Which one is valid?
According to the most recent IPv6 addressing architecture described in RFC 4291, the (b) option is correct. The (a) option was originally proposed with earlier revisions of IPv6 addressing architecture - RFCs 1884, 2073, 2373, 2374, 3513, but in RFC 3587, this approach of structuring IPv6 address was dropped.
The formatting according to (a) may actually be still used internally among ISPs and with allocating IPv6 address blocks because it is still valid according to the current IPv6 addressing architecture, but it does not have to be upheld that way. The (b) option is much more relaxed in this sense.
Best regards,
Peter
10-01-2011 12:56 PM
Hi Peter,
It seems I still need to strenghten my IPv6 knowledge.
Thanks for making me a more knowledgeable man.
Regards.
Alain.
10-01-2011 01:18 PM
Hi Alain,
These addressing issues are good for us academics to lead neverending debates, but in real life, you see, the simplest form has won, and I guess it will be that way in most cases. Oh, and do not overestimate my contribution to your knowledge. I happened to stumble across these RFCs earlier so I vaguely recalled seeing them. I merely did my Google homework here...
You are welcome, and you may not believe it but you are helping me to advance further. Thank you!
Best regards,
Peter
10-01-2011 11:36 PM
Thanks Peter for such a wonderful explanation as usual.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide