> -----邮件原件----- > 发件人: behave-boun...@ietf.org [mailto:behave-boun...@ietf.org] 代表 Ré mi > Després > 发送时间: 2009年12月8日 19:26 > 收件人: beh...@ietf.org; ipv6@ietf.org > 抄送: Xu Xiaohu > 主题: [BEHAVE] Reason(s) for Modified EUI-64 format to apply to ALL non-0::/3 > IPv6 addresses ? > > Hi all, > > Xu Xiaohu wrote (in the Behave discussion thread) : > > > 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? > > +1 in favor of this question being answered by those who know the history. > (This question is a recurring one, AFAIK not answered so far.)
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.). > > (In other words, is there any practical meaning/usage for that > > constraint in the IPv4/IPv6 translation process?) > > If no reason for the current constraint is reported, the real constraint > could be weaker, becoming for example: Agree. > "...For all unicast addresses other than those that start with the > binary value 000, and that are used as destinations on IPv6 links having > /64 subnet prefixes, Interface IDs are required to be constructed in > Modified EUI-64 format." How about the IPv4 translatable addresses for IPv6 hosts in the stateless translation case? Obey the constraint or not? > To be complete, it could be added that: > > "If new formats are defined in the future for such Interface IDs, they > should be distinguishable from the Modified EUI-64 format, i.e. should > have their two lower bits of the first octet both set to 1" > > NOTE: IPv4-translatable and IPv4-converted IPv6 address formats are > being defined in conformance with the Modified EUI-64 format constraint. > *This doesn't need to change.* > (Even if not technically necessary, this conformance permits to freeze > the specification, which is urgent, without waiting for the above > question to be resolved.) It seems ok to redefine the specification once the constraint on IPv4-embeded IPv6 addresses has been removed, just as what we are now doing on SIIT. (E.g., replacing the IPv4-Compatible IPv6 Address and IPv4-Mapped IPv6 Address with IPv4-translatable IPv6 address and IPv4-converted IPv6 address respectively). Xiaohu > Regards, > > RD > > _______________________________________________ > 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 --------------------------------------------------------------------
