RE: Thinking differently about the site local problem (was: RE: site local addresses (was Re: Fw: Welcome to the InterNAT...))

["Jeroen Massar" <[e-mail]>]

Keith Moore [mailto:[e-mail]] wrote:

> > > > Indeed, correctly coded applications will use a getaddrinfo()
> > > > and then a connect() in a loop until succesful. 
> > > 
> > > it's perfectly reasonable to connect to an address without first
> > > doing a DNS lookup.
> > 
> > I think nobody can't help you if you are using hardcoded IP's.
> > The only case you have an IP without DNS is when you get it
> > passed from another layer/entity (eg in a FTP from the server).
> 
> uh, no.   you can get IP addresses from any number of sources 
> other than DNS, including from other processes that exist on
> other nodes.  It's a perfectly reasonable thing to do.

Note the line about other layer/entity :)
Which is also one of the reasons why multi-faced dns isn't
the solution to this problem.

> > Can you identify those so that getaddrinfo() can be expanded
> > to fix these cases?
> 
> getaddrinfo() cannot be fixed.  it's major premise - that the host has
> the knowledge to make decisions about which of several 
> addresses is best to use - is fundamentally flawed, except in a
> few corner cases.

Effectively this could be resolved by having one globally
unique identifier per node. The underlying protocols should
then take care that messages are delivered to the host
described by the unique locator. The underlying protocols
could then, in case of your so called corner cases, or routing
troubles, based on all kinds of external information change
the underlying protocols so that the connection stays active
and messages can still be sent from A to B. Enter SCTP and
multihoming ? :)

This has nothing to do with sitelocal but more with the
fact that a host can have multiple paths from A to B: internet ;)

Greets,
 Jeroen