> > > > My question is: Should the IPv4-embeded IPv6 address still be in > accordance with the specification defined in RFC4291 as "...For all unicast > addresses, except those that start with the binary value 000, Interface IDs > are required to be 64 bits long and to be constructed in Modified EUI-64 > format..."? If the answer is yes, why? (In other words, is there any > practical meaning/usage for that constraint in the IPv4/IPv6 translation > process?) > > I thought we'd discussed that a lot. Maybe it was not on the BEHAVE list. > > The idea of protecting the semantics of the u/g bit (which is most cleanly > done by skipping the whole byte) is that it is a very fundamental part of > the IPv6 design and we simply do not know when or how it might be relied > on. It may have no value in currently understood cases of 1:1 communication > via a NAT64, but we don't know where it might be important in p2p > communications, > referrals, etc. >
I have a concern about that specified rule of "bits 64 to 71" doesn't protect the semantics of the u/g bit. In the case of adopting WKP, the U-bits should be 1, since WKP is only concatenated with global IPv4 address to guarantee the uniqueness of IPv4-Converted IPv6 addresses. Following statement is quoted from draft-ietf-bahave-address-format-03. "When using a /96 prefix, the administrators MUST ensure that the bits 64 to 71 are set to zero." If this rule is applied to WKP case, it might even break the semantics of the u/g bit. BRs Gang
-------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
