Re: Move forward

[marcelo bagnulo <marcelo@it.uc3m.es>]

On Mon, 2003-03-17 at 18:00, Iljitsch van Beijnum wrote:
> On 17 Mar 2003, marcelo bagnulo wrote:
> 
> > > > However in IPv6, considering "Default
> > > > Address Selection mechanism" i was hoping that application used the list
> > > > of addresses generated by the mechanism and try to use them to
> > > > communicate
> 
> > > Actually this may make it worse, as the "best" address is always
> > > selected. If the "best" address is unreachable, no dice. At least with
> > > random or round robin you can hit reload to try again.
> 
> > From RFC 3484
> 
> > 6. Destination Address Selection
> 
> >    The destination address selection algorithm takes a list of
> >    destination addresses and sorts the addresses to produce a new list.
> >                                                                   ^^^^
> > I guess that applications now obtain a list of addresses, after the
> > default address selection mechanism has sorted them.
> 
> Yes. But then the application still has to go through the trouble of
> trying every address. I don't think web browsers typically do that. (And
> if the user has to wait for a timeout, it might not matter anyway.)
> 
> For your experimentation pleasure I have created some DNS names with 7
> IPv4 and/or IPv6 addresses, only one of which works. It's a Cisco, so
> you can telnet, but HTTP is probably more interesting (if it works,
> you'll get an authentication requester). The names are:
> 
> tryme.bgpexpert.com trymev4.bgpexpert.com trymev6.bgpexpert.com
> 

Thank you very much !!!

We have tried it with the Konqueror browser.
Its behaviour was:

It tried with the first address => it was a "fake" address so it failed
but it received a host unreachable message (almost immediately)
Then it tried with the next one => it was the good one Ok!

This seems to be an suitable behaviour for our needs, right?

(What i didn't told you is that it only tries with 2 addresses, so if
the real one was the third, it would have failed)

So it seems to me that different aps have different behaviour.

I still think that this is reasonable mechanism for selecting the first
address, it is pretty fast if the host unreachable message is sent,
also. 
But i do agree with you that it is application dependent. Perhaps we
need more feedback from application developers?

> > Moreover, the first rule of the mechanism discards unreachable
> > destinations, so if one of multiple is unreachable it will be included
> > last.
> 
> How does the resolver library know which addresses are reachable? Or
> usable for the application in question?

It tries and if it is not working, this result is cached for next
attempts (this is one possible mechanism included in the spec)

Regards, marcelo

-- 
marcelo bagnulo <marcelo@it.uc3m.es>
uc3m