Re: shim6 @ NANOG (forwarded note from John Payne)

[Erik Nordmark <erik.nordmark@sun.com>]

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 
> application.

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 
this.

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.

   Erik

> 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.