Since the following email is not successfully received by some subscribers, so I resend it.
Xiaohu > -----邮件原件----- > 发件人: [email protected] [mailto:[email protected]] 代表 Brian > E Carpenter > 发送时间: 2009年12月9日 5:40 > 收件人: Xu Xiaohu > 抄送: [email protected]; [email protected]; > [email protected] > 主题: [BEHAVE] address-format: bits 64 to 71 > > On 2009-12-08 21:54, Xu Xiaohu wrote: > > > >> -----邮件原件----- > >> 发件人: [email protected] [mailto:[email protected]] 代表 > >> Christian Huitema > >> 发送时间: 2009年12月8日 2:52 > >> 收件人: [email protected]; [email protected]; > [email protected]; > >> [email protected] > >> 主题: 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 -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
