[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: shim6 @ NANOG (forwarded note from John Payne)
Iljitsch van Beijnum wrote:
True enough, and I certainly hope that frameworks, libraries and the
like that implement a connect-by-name type call do this. However, this
isn't the only way to solve this. One very interesting feature that I
discovered this summer when finally upgrading to a more recent version
of FreeBSD was the address selection policy mechanism (see the
ip6addrctl command, Windows also has it as netsh interface ipv6 show/set
prefixpolicy). With this, it's possible to control address preferences
system-wide. I'm not sure how it's implemented exactly, but apparently
this policy is applied somewhere between the DNS resolver and the
ip6addrctl is an implementation of the configurable policy table which
is suggested in RFC 3484. Thus it provides a static table.
One way to put this mechanism to good use is when a DNS lookup for an
AAAA record returns more than one address, is to go out and check which
address is alive and/or apply local, remote and in-the-middle traffic
engineering policies. Since the application hasn't committed to any
particular address choice yet, this should work very well. The only
downside is that all of this will take an extra roundtrip.
Implementations of the RFC 3484 policy table do not have a way to
execute some extra code as part of doing the address selection, thus to
do what you suggest one would have to hack around.
So the existence of ip6addrctl doesn't seem to help to do something like
I also question doing extra work each time a DNS lookup is performed;
the lookup might only be done to put an address/name in a log file;
checking reachability and TE policy for such a lookup would be wasteful.
I imagine that we can send out some kind of quick reachability check /
information request to the other side, maybe even towards all the
addresses returned by the DNS. I have to read up on the R1/R2 stuff, but
I imagine this could be an R1, without necessarily completing the full
handshake at this time.
If an I1/R1 exchange was extended to return all the locators and their
preferences in the R1 message (currently this isn't required), then such
an exchange could be used to find out the peer's preferences.
But doing this for all peer IP addresses would be expensive since the
number of packets could be large and the ULP communication might be
quite short. So we would be trading off better TE capability against the
benefits of deferred context establishment.
Since we're waiting for information to come back from the correspondent
anyway, we can use this time to query a policy server that's local to
the site or is located at one or more of the site's ISPs. If the servers
don't waste time, the answer for this should be back by the time the
correspondent answers anyway.
Another advantage of checking reachability at this stage is that we can
easily avoid ingress filtering: simply try the reachability check
towards the correspondent with the cartesian product of all local and
remote addresses at the same time. The probes with an ingress filtered
source address shouldn't even take up any non-local bandwidth if the
egress routers also perform this filtering.