Xu Xiaohu escribió: > >> -----邮件原件----- >> 发件人: marcelo bagnulo braun [mailto:[email protected]] >> 发送时间: 2009年12月10日 9:26 >> 收件人: Xu Xiaohu >> 抄送: 'Christian Huitema'; [email protected]; [email protected] >> 主题: Re: [BEHAVE] Reason(s) for Modified EUI-64 format to apply to ALL >> non-0::/3 IPv6 addresses ? >> >> Xu Xiaohu escribió: >> >>>> -----邮件原件----- >>>> 发件人: [email protected] [mailto:[email protected]] 代表 >>>> marcelo bagnulo braun >>>> 发送时间: 2009年12月9日 21:24 >>>> 收件人: Christian Huitema >>>> 抄送: [email protected]; Xu Xiaohu; [email protected] >>>> 主题: Re: [BEHAVE] Reason(s) for Modified EUI-64 format to apply to ALL >>>> non-0::/3 IPv6 addresses ? >>>> >>>> Christian Huitema escribió: >>>> >>>> >>>>>> 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. >>> >>> >>>>> The well known prefix is easy to recognize, so there is no problem >>>>> >>>>> >>> there. >>> >>> >>>> For stateless, the design makes sure that the IPv4 translatable >>>> > addresses > >>> can >>> >>> >>>> be routed natively, which means there is no reason to not prefer them. >>>> >>>> >>> That >>> >>> >>>> leaves a pretty small domain of applicability for any scheme that would >>>> >>>> >>> reserve >>> >>> >>>> identifier patterns... >>>> >>>> >>>> In addition, in the NSP case, the host can configure the RFC3484 policy >>>> table to preffer native connectivity. >>>> >>>> >>> However, when one configures such a policy that native IPv6 connectivity >>> should be preferred to IPv4 connectivity. How could the dual-stack host >>> distinguish synthesized IPv6 addresses from native IPv6 addresses? If >>> > there > >>> are some bits to tell whether it is an IPv4-embeded IPv6 address or not >>> (even which type of IPv4-embeded IPv6 address), the above issue can be >>> solved easily. >>> >>> >> for the NSP, what the host needs to know is the NSP itself, that is what >> needs to be included in the policy table >> > > Even so, if a dual-stack host obtains a synthesized IPv6 address as a > response to its DNS query for AAAA record at first, will it send a DNS query > for A record later due to the above policy table? >
mmm two comments about this. First in general, except some rare excpetions, the dual stack hosts should not have a dns64 capable server as their dns server, so in general this should not happen Second, you don't solve this problem by adding some bits in the middle for recognizing the synthetic addresses. The point is that i am making is that having them in the rpefix or in the iid achieve the same capability (and have the same limitations) Regards, marcelo > Xiaohu > > >>> >>>> Regards, marcelo >>>> >>>> >>>> >>>> >>>>> -- Christian Huitema >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Behave mailing list >>>>> [email protected] >>>>> https://www.ietf.org/mailman/listinfo/behave >>>>> >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> Behave mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/behave >>>> >>>> >>> >>> > > > -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
