> -----邮件原件----- > 发件人: Christian Huitema [mailto:huit...@microsoft.com] > 发送时间: 2009年12月9日 10:26 > 收件人: Xu Xiaohu; 'Rémi Després'; beh...@ietf.org; ipv6@ietf.org > 主题: RE: [BEHAVE] Reason(s) for Modified EUI-64 format to apply to ALL > non-0::/3 IPv6 addresses ? > > > 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). > > Any revision of the IPv6 addressing rules in 6MAN is going to take a long time. > Maybe several years. I would rather not wait that long before we publish the > addressing format document. Beside, complying with the rule is not that hard. > So why bother?
I wonder whether one could use that octet (bit 64 to 71) of IPv4-embeded IPv6 address for identifying different types of IPv4-embeded IPv6 address than just using it to obey a constraint whose future usage is still uncertain. That is to say, the IPv4-embeded IPv6 addresses can be identified by some bits (e.g. the binary value of bit 64 to 66 is a specific value, which is not conflicted with any used OUIs). Furthermore, different types can also be distinguished by the remaining bits for that octet (e.g., bit 67 to 71). At least the former usage has some certain applications. For example, in case of NAT64, if a dual-stack host could distinguish synthesized IPv6 addresses from native IPv6 addresses, it will not prefer a synthesized IPv6 address to an IPv4 address for initiating a communication with an IPv4 host. Another usage is to avoid routing loops when using ISATAP and 6to4 (for more details, please see http://www.ietf.org/proceedings/09nov/slides/v6ops-2.ppt). Xiaohu -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
