> -----邮件原件----- > 发件人: marcelo bagnulo braun [mailto:marc...@it.uc3m.es] > 发送时间: 2009年12月10日 23:41 > 收件人: Xu Xiaohu > 抄送: 'Christian Huitema'; beh...@ietf.org; ipv6@ietf.org > 主题: Re: [BEHAVE] Reason(s) for Modified EUI-64 format to apply to ALL > non-0::/3 IPv6 addresses ? > > Xu Xiaohu escribió: > > > >> -----邮件原件----- > >> 发件人: marcelo bagnulo braun [mailto:marc...@it.uc3m.es] > >> 发送时间: 2009年12月10日 9:26 > >> 收件人: Xu Xiaohu > >> 抄送: 'Christian Huitema'; beh...@ietf.org; ipv6@ietf.org > >> 主题: Re: [BEHAVE] Reason(s) for Modified EUI-64 format to apply to ALL > >> non-0::/3 IPv6 addresses ? > >> > >> Xu Xiaohu escribió: > >> > >>>> -----邮件原件----- > >>>> 发件人: behave-boun...@ietf.org [mailto:behave-boun...@ietf.org] 代表 > >>>> marcelo bagnulo braun > >>>> 发送时间: 2009年12月9日 21:24 > >>>> 收件人: Christian Huitema > >>>> 抄送: beh...@ietf.org; Xu Xiaohu; ipv6@ietf.org > >>>> 主题: 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
Consider a scenario where dual-stack hosts coexist with IPv6 only hosts (IPv6 only stack or dual-stack with only IPv6 address), should they be configured with different DNS servers? That is to say, should dual-stack hosts be configured with a normal DNS server, while IPv6 only hosts configured with a DNS64 capable server? Or do you believe the above scenario itself is rare? > 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) There seems no bit in a NSP to tell whether an IPv6 address is a synthetic address or not in the current address-format draft. On the contrary, we could use some bits in the IID to achieve that goal. Another possible way is as follows: the NSP used for synthesizing IPv6 address should be a specific prefix, e.g. starting with the binary value 00010101. In this way, the constraint on IID format mentioned before is removed due to starting with the binary value 000. In addition, this address is also provider aggregatable because the remaining part between the above binary value and the last four octets (i.e., IPv4 address to be embedded) is network specific. Comments? Best wishes, Xiaohu > > > > > >>> > >>>> Regards, marcelo > >>>> > >>>> > >>>> > >>>> > >>>>> -- Christian Huitema > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> Behave mailing list > >>>>> beh...@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/behave > >>>>> > >>>>> > >>>>> > >>>>> > >>>> _______________________________________________ > >>>> 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 --------------------------------------------------------------------
