> > 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)
Can the DNS server be automatically configured according to whether the
client is dual-stack or not? If not, I don't think this is the best choice.
> > 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.
If I understood it correctly, the basic precondition of this approach is the
NSP is known to the hosts in IPv6 realm. Hence, I wonder whether this
approach is still suitable for the IPv6 Internet to an IPv4 network scenario
where NSPs used by different IPv4 sites are much various.
> 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
There are three choice for the WKP in the address-format draft:
o reuse the IPv4-mapped prefix, ::FFFF:0:0/96, as specified in RFC
2765 Section 2.1;
o request IANA to allocate a /32 prefix,
o or request allocation of a new /96 prefix.
Could you tell me which one is equivalent to the specific NSP I mentioned,
which starts with a special binary value?
Best wishes,
Xiaohu
> > 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
--------------------------------------------------------------------
