Xu Xiaohu escribió: > >> -----邮件原件----- >> 发件人: 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? yes, that's how they should be configured. Please note that this does not require two dns servers, you can run them in the same box as two separate process, and use two different ip addresses. That would be the best configuration (especially cause it would work with legacy nodes, either dual stack or v6 only). (please note that other mechanisms recognizing some bits, either the prefix or some bits in the iid would require updating the node, and that is why this method is superior)
> 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. the NSP itself is what needs to be learned by the hosts that want to recognize a synthetic address! I mean, in particular with the rfc3484 poilicy table, you need to configure the NSP in the policy table, so that native connectivity is preferred. the main difference between this iand having a fix set of bits is that these need to be learnt by the hosts in order to recognize the NSP. Note that there is ongoing work to dynamically configure the rfc3484 policy table, which would deal with this issue. Another option is to use the WKP which can be hardcoded. > 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. we have that, and that is the WKP Regards, marcelo > 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 --------------------------------------------------------------------
