> -----邮件原件----- > 发件人: behave-boun...@ietf.org [mailto:behave-boun...@ietf.org] 代表 Brian > E Carpenter > 发送时间: 2009年12月9日 5:40 > 收件人: Xu Xiaohu > 抄送: eric.bur...@orange-ftgroup.com; x...@cernet.edu.cn; beh...@ietf.org > 主题: [BEHAVE] address-format: bits 64 to 71 > > On 2009-12-08 21:54, Xu Xiaohu wrote: > > > >> -----邮件原件----- > >> 发件人: behave-boun...@ietf.org [mailto:behave-boun...@ietf.org] 代表 > >> Christian Huitema > >> 发送时间: 2009年12月8日 2:52 > >> 收件人: eric.bur...@orange-ftgroup.com; x...@cernet.edu.cn; > beh...@ietf.org; > >> behave-cha...@tools.ietf.org > >> 主题: Re: [BEHAVE] address-format: null suffix, consensus check > > ... > > Hi Christian, > > > > I noticed the following statement in your draft "...Bits 64 to 71 of the > address are reserved for compatibility with the host identifier format defined > in the IPv6 addressing architecture. These bits MUST be set to zero. The > corresponding octet is noted "u" in the above diagram. When using a 96 prefix, > the administrators MUST ensure that the bits 64 to 71 are compatible with the > IPv6 addressing architecture..." > > > > 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.
Yes, we had discussed that in both SOFTWIRE and BEHAVE WG mailing-lists (see the previous discussion thread: http://www.ietf.org/mail-archive/web/softwires/current/msg00850.html.). However, we have not got any reasonable enough answer. > 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. The following statement is quoted from RFC 4291: "IPv6 nodes are not required to validate that interface identifiers created with modified EUI-64 tokens with the "u" bit set to universal are unique. The use of the universal/local bit in the Modified EUI-64 format identifier is to allow development of future technology that can take advantage of interface identifiers with universal scope." Till now, we haven't known the real usage of this constraint yet. So we should reverently obey such a constraint whose future usage is still uncertain. Maybe a compromised way is to release this constraint on the IPv4-embeded IPv6 addresses which can be used for stateless IPv4/IPv6 translation and 6over4 automatic tunneling while remaining it for native IPv6 address auto-configuration in case using a /64 prefix. > Also, this WG doesn't own the address format. Changing this would need the > consensus of 6man. OK, I have added the 6man in the cc. Look forward to a clear conclusion after discussing it in the 6man mailing-list. Xiaohu > > Brian > > _______________________________________________ > Behave mailing list > beh...@ietf.org > https://www.ietf.org/mailman/listinfo/behave -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
