On Mar 9, 2:05 pm, ma...@ntp.org (Danny Mayer) wrote: > As far as I am aware there is no way to change the list of addresses > returned via any available knobs so how are site policies involved? You > cannot change getaddrinfo() unless you implement your own and there is > no purpose to doing so. The order of addresses records is indeterminate > by DNS standards and anything that is being done by getaddrinfo() is > implementation/OS specific and cannot be depended upon. See the > discussion in namedroppers. > [...] > Because there is no way to change the order. That's not a site policy, > it's an O/S-specific implementation
I take your word that RFC 3484 is being discussed on namedroppers. If they are not already aware, you might want to point them in the direction of http://tools.ietf.org/wg/6man/draft-ietf-6man-node-req-bis/ where you can find that current draft IPv6 node requirements include RFC 3484 compliance. Looking at the abstract of RFC 3484, quoting, "All IPv6 nodes, including both hosts and routers, must implement default address selection as defined in this specification." If you dig just a little further you will see that in fact sorting of entries returned by getaddrinfo is the heart of RFC 3484. So it is true the order is implementation specific, but only within the bounds set by RFC 3484 and optionally with local configuration via a "policy table". > >>>>> It sounds like you use a disconnected IPv6 network alongside a > >>>>> connected RFC1918 v4 network internally. I wonder if you could get by > >>>>> using only link-local addresses for your internal IPv6 network? I > >>>>> believe that would solve the problem because your stack would know it > >>>>> can't connect to a global v6 address from a machine with only link- > >>>>> local v6 addresses. > >>>> The stack has no knowledge of whether it can connect to a global IPv6 > >>>> address. Only the routers will be able to do that. > >>> Since link-local addresses by definition are not routable, routers do > >>> not come into play. Any IPv6 stack understands the difference between > >>> link-local and global addresses, and will not attempt to connect to a > >>> global remote address using a link-local local address. Hence the > >>> results Martin saw that only machines with IPv6 global addresses were > >>> having trouble with names returning AAAA as well as A. > > > I'm not sure why you quoted this, but since you failed to respond I > > take it you're no longer claiming IPv6 stacks need routers to discern > > link-local from global addresses. > > site-local addresses should be sufficient to reach global addresses. > Routers are needed for that but the site-local prefix needs to be > configured so that auto-config finds it. You are bringing site-local into the conversation? Since site-local is routed, from the stack perspective it's pretty much like global. Link-local IPv6 addresses being fundamentally unable to connect to global addresses is why their presence doesn't trigger attempts to follow AAAA records. I look forward to the fruits of your IPv6 labors in ntpd. Cheers, Dave hart _______________________________________________ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
