Subject: Re: LL1, LL23

From: "Philip Nye" <[email-masked]>
Date: Fri, 21 Feb 2003 22:49:58 -0000

> ...   If it has both an IPv4ll address and a global address, and
> is contacting an SLP server that has a global address, why is it giving
> the SLP server its IPv4ll address?

In the beginning the app says to its OS "what is my IP address". This
happens with lots of apps.

The OS cannot answer "who do you want to send it to?" or "what do you want
to do with it?". It cannot answer "local or global?". What does it answer?

Philip

---

From: Mika Liljeberg <[email-masked]>
Date: 22 Feb 2003 01:06:10 +0200

> happens with lots of apps.

So why doesn't the OS give the global one?

> to do with it?". It cannot answer "local or global?". What does it answer?

It should give the highest scope address first.

	MikaL

---

From: Markku Savela <[email-masked]>
Date: Sat, 22 Feb 2003 01:42:57 +0200

> From: "Philip Nye" <[email-masked]>

> happens with lots of apps.

Above is a serious API problem with multihomed hosts in any
case. Which address from the multiple interfaces OS will return? And,
even funnier, will it return IPv4 or IPv6 global?

Perhaps, a more correct way to ask the question is "what is my IP
address if I would connect to X?"

And, in fact, to support simple applications, the original question
should be internally translated into "what is my IP address for global
estination".

Relating to topic: the ZEROCONF RFC must not include any wording that
would make OS "unconformant", if allows and works fine with both LL
and global addresses at same time.

I accept wording "MAY stop using LL when global address is present"
for those unfortunate ones, that can't handle the situation :-)

---

From: Ted Lemon <[email-masked]>
Date: Fri, 21 Feb 2003 16:50:33 -0700

> happens with lots of apps.

Really?   Given how differently most operating systems support 
answering this question, I suspect that you are wrong.   Most apps bind 
to 0.0.0.0, not to a specific IP address.   There are some few apps 
that do use system-specific APIs to discover IP addresses.   It is only 
this second group of apps that is going to have a problem with 
application-discovered addresses.   Can you give us an example of an 
app that both has the quality that it checks to see what addresses the 
system has, _and_ sends these addresses to other services that might 
publish them?

I can give you one example - the ISC DHCP server does this.   We had a 
problem with this about four or five years ago, and I had to hack the 
server to allow the user to specify which address to advertise.   This 
was very easy.   It would also be very easy to hack the ISC DHCP server 
to simply discard the IPv4ll address, since it is never correct for the 
DHCP server to advertise this address.   The server already has a code 
path that eliminates addresses that shouldn't be advertised, so this 
would involve something like four lines of code.

ISC BIND also uses SIOCGIFCONF to get a list of IP addresses, but it 
doesn't ever publish them.   Likewise with sendmail.

Can you give us an example that isn't easy to fix, like ISC DHCP, and 
that is actually a problem, unlike BIND and sendmail?

> to do with it?". It cannot answer "local or global?". What does it 

Actually, as I say, usually the app doesn't ever tell the O.S. which 
address to use - it trusts the O.S. to choose.   The application 
programmer has to be fairly knowledgeable just to know how to ask the 
O.S. what addresses are configured on its various interfaces.   We've 
already described an excellent rule for how the O.S. should choose 
which source address to use - if the destination is scoped, use our 
scoped address.   If it is not scoped, use our non-scoped address.

In the case where the client uses something like SIOCGIFCONF to get a 
list of IP addresses on an interface, you have a harder problem.   As I 
say, the ISC DHCP server already solves this problem.   I suspect that 
most applications that use SIOCGIFCONF, which are few, would be easy to 
modify so that they did the right thing.   It would also be possible 
for the O.S. vendor to modify the SIOCGIFCONF ioctl so that it didn't 
return link-local addresses in a way that made them look identical to 
global addresses.   I suspect that this would be a good choice - it's 
likely that in most cases the app that is getting the address doesn't 
want to see the link-local address, and the app that wants the 
link-local address will know to ask for it.

Can you think of an application that we would *want* to advertise the 
link-local address, but that would not know to ask specifically for it?

---

From: Ted Lemon <[email-masked]>
Date: Fri, 21 Feb 2003 17:13:41 -0700

> should be internally translated into "what is my IP address for global

There _is_ no API of which I am aware through which you can ask the 
question "what is my IP address?"   The only one that I know of answers 
the question, "what are my interfaces and the IP addresses configured 
on them?"   Server programs that enumerate IP addresses have to be 
prepared to understand a lot about the connectivity of the host.  This 
is not a new problem that's caused by IPv4ll.   I speak from personal 
experience, having had to write code to handle this on a wide variety 
of operating systems.

---

From: Keith Moore <[email-masked]>
Date: Sat, 22 Feb 2003 00:34:48 -0500

> on them?" 

the other thing that is commonly done is to feed the output of
gethostname (or uname, whatever) to gethostbyname ().
note that this does not necessarily result in a DNS query.

>  Server programs that enumerate IP addresses have to be 
> prepared to understand a lot about the connectivity of the host.

not necessarily.  obviously it depends on how they use those addresses.  it is
also the case that fairly simple approaches (e.g. take an address of the
interface to which the default route is attached) often work well.

> This is not a new problem that's caused by IPv4ll. 

no, but the introduction of v4LL will break software that currently works.

the vast majority of IPv4 hosts do not have multiple network interfaces, or if
they do, do not use more than one of those interfaces at a time.  and the vast
majority of IPv4 hosts do not have multiple IPv4 addresses assigned to them. 
a lot of software will break in the presence of multiple addresses on a host.

(I just saw a patch go by for netsolve which allows a server to have its local
address specified on the command-line when it is started, to handle the case
where the server has multiple addresses assigned to it and they don't all work 
well.  The fix is still a kludge in that it can only advertise a single address 
even though this address might not be sufficient for all clients.  basically
netsolve does not have the ability to deal with scoped addresses, and it's
impractical to fix netsolve so that it does deal with them robustly.)

---

From: Keith Moore <[email-masked]>
Date: Sat, 22 Feb 2003 00:41:33 -0500

> to 0.0.0.0, not to a specific IP address.   

true, in my experience.  but the app may still depend on being reachable
via a single address by any peer.

> There are some few apps 
> that do use system-specific APIs to discover IP addresses. 

the socket APIs are actually fairly portable across UNIXen, and there
are lots of ways to determine IP addressees to be used in referrals:

- ioctl SIOCGIFCONF - to get your own interfaces/addresses
- getlocalname on an open socket - to get a local IP address
- getpeername on a connection with a peer  -to get the peer's
  address to use in referrals
- gethostbyname (gethostname ()) - get an address associated with
   the host's idea of its name

note that it's really unreasonable to expect everyone to have to fix their
software in order to keep working in the presence of LL, especially when
there's no standard way to disable LL on a network.

Keith

---

From: Keith Moore <[email-masked]>
Date: Sat, 22 Feb 2003 00:44:44 -0500

> should be internally translated into "what is my IP address for global

actually gethostbyname (gethostname ()) often works quite well for this -
because, if necessary, the host can be configured with a host name
and a hostname->address mapping (say in /etc/hosts) that selects one
address that works "everywhere".

> for those unfortunate ones, that can't handle the situation :-)

it's not acceptable for this WG to standardize behavior that breaks things.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 21 Feb 2003 23:30:15 -0700

> no, but the introduction of v4LL will break software that currently 

When DEC put a DNS resolver into Ultrix, it broke a lot of stuff too.   
I remember all the stuff I had to do to make things work.   Subtle 
changes to the way the resolver worked in later releases had 
significant effects on how various applications behaved.   In 
particular, it badly broke NFS and rsh.    If you installed a hostname 
that wasn't an FQDN, things broke all over the place.   Yet I think you 
would be hard pressed to argue either that NFS and rsh should have been 
doing the thing that broke them, or that we shouldn't have deployed DNS 
for fear of breaking NFS and rsh.   The hostname bugs were all actual 
bugs, not just broken behavior.

Now, the net win for DNS is *much* bigger than the win for IPv4ll, but 
the principle is the same.   You compare the costs to the benefits.   
You do not just say "this breaks something, so it shall not pass."

So what we are trying to do here is identify specific cases where 
IPv4ll would break things, and consider how we might fix the problem.   
Then we can really compare the costs to the benefits.

> basically netsolve does not have the ability to deal with scoped 
> addresses, and it's impractical to fix netsolve so that it does deal 
> with them robustly.

So, with the above in mind, would you care to characterize this 
further?   Is it impossible to add code that eliminates IPv4ll 
addresses from the interface list?   Would it not help to make 
SIOCGIFCONF not return IPv4ll addresses, and require that instead 
require that server software that needs to advertise IPv4ll addresses 
use a separate system call to get a list of IPv4ll addresses?   
Wouldn't this latter solution actually require zero change to netsolve?

---

From: Ted Lemon <[email-masked]>
Date: Fri, 21 Feb 2003 23:41:40 -0700

> via a single address by any peer.

Applications that depend on being reachable by a single address are 
already broken in the context of existing protocols, because many hosts 
have more than one interface, and therefore more than one address.   In 
many cases, particularly when a host has both IPv4 and IPv6 addresses, 
the addresses are not interchangeable.   I don't think you can argue 
that an application with this problem is bug-free in the absence of 
IPv4ll.

> - ioctl SIOCGIFCONF - to get your own interfaces/addresses

Doesn't work on Linux.   Or at least it didn't in 2.2 - maybe they 
fixed that in 2.4.   The API for doing this in 2.2 is completely 
different.   Various different Unices have slightly different versions 
of SIOCGIFCONF, and there is no standard behavior, although the 
behaviors of most non-Linux stacks are fairly similar.   The point is, 
if you are using SIOCGIFCONF, you're not a neophyte.

> - getlocalname on an open socket - to get a local IP address

This is going to give you the IP address that you are using to 
communicate.   Can you give an example of when this would be the wrong 
address to use?

>   address to use in referrals

Again, this is going to give you the IP address you're using to 
communicate with the peer.   If the peer has a global address, and you 
have a global address, you're going to get a global address here.   If 
the peer doesn't have a global address, or you don't have a global 
address, you're going to get an IPv4ll address.   In none of these 
cases are you going to get an address that is not appropriate to use in 
referrals.

>    the host's idea of its name

This doesn't even promise to get you the host's IP address.   There is 
no guarantee at all that your domain search list and the hostname are 
going to be such that the IP address you get back from this will not be 
some other computer's IP address.   So I would say that any application 
that does this is simply broken, and this brokenness has nothing to do 
with IPv4ll.

---

From: Mika Liljeberg <[email-masked]>
Date: 22 Feb 2003 11:42:39 +0200

> note that this does not necessarily result in a DNS query.

That's good. You're not supposed to put LLs into DNS, so this will keep
on working.

> interface to which the default route is attached) often work well.

This too will keep on working, with a little help from the OS. If the
implementation is such that each IPv4 address is configured on a
separate virtual interface, your default route will still point to the
interface in which you have the routable address.

> no, but the introduction of v4LL will break software that currently works.

We're trying to establish what that software might be, but so far I have
not seen even a single good example. By "good" I mean detailed enough to
undestand the failure mode and discuss it.

> a lot of software will break in the presence of multiple addresses on a host.

Show an example of software that will break.

> even though this address might not be sufficient for all clients.

If that address is a global one, why would it not be sufficient for all clients?

> basically

Excellent, a concrete example! How does netsolve normally determine the
address it advertises?

	MikaL

---

From: Keith Moore <[email-masked]>
Date: Sat, 22 Feb 2003 10:10:21 -0500

> That's good. You're not supposed to put LLs into DNS, so this will keep

well, you wouldn't want gethostbyname (gethostname ()) to return an LL
address under any circumstances where a routable address were associated
with the host, because this would cause apps to advertise the LL address
as a way to reach that host.

> > not necessarily.  obviously it depends on how they use those addresses. 
> > it is also the case that fairly simple approaches (e.g. take an address of
> > the interface to which the default route is attached) often work well.
> 

agreed that it can help if the OS is clever about how it represents LL
address-to-interface bindings.

> undestand the failure mode and discuss it.

when have had such discussions.  people seem to want to disregard them,
and then later claim that they haven't happened.

> > the vast majority of IPv4 hosts do not have multiple network interfaces,
> > or if they do, do not use more than one of those interfaces at a time. 
> > and the vast majority of IPv4 hosts do not have multiple IPv4 addresses
> > assigned to them. a lot of software will break in the presence of multiple
> > addresses on a host.
> 

I just did.

> > (I just saw a patch go by for netsolve which allows a server to have its
> > local address specified on the command-line when it is started, to handle
> > the case where the server has multiple addresses assigned to it and they
> > don't all work well.  The fix is still a kludge in that it can only
> > advertise a single address even though this address might not be
> > sufficient for all clients.
> 

globally scoped does not mean globally reachable.

> Excellent, a concrete example! How does netsolve normally determine the

I'll have to look at the code again to be sure, but from memory, it does
different things in different parts of the code

a. getpeername()
b. gethostbyname (gethostname ())

---

From: Mika Liljeberg <[email-masked]>
Date: 22 Feb 2003 18:01:29 +0200

> as a way to reach that host.

I agree. Even if LLMNR were implemented behind the gethostbyname() API,
the implementation should not try LLMNR if the name is found in DNS. I
believe the LLMNR specification already states that the resolver has to
try DNS first.

So, I expect no problems with applications that use gethostbyname().

> and then later claim that they haven't happened.

I can't speak for others but that is not my intention. I want to
understand the exact failure modes you're seeing with specific
applications, in order to get a feel for the problem. My own reasoning
is telling me that there is no major problem and you are saying that
there is. I want to understand why.

This discussion is already improving, IMHO, now that we're now talking
about concrete APIs and how they behave.

> > Show an example of software that will break.

I guess you mean the netsolve case? That's good, let's explore it.

> globally scoped does not mean globally reachable.

That's a problem that exists independently of LL addresses. I don't see
how that is relevant to the discussion.

> different things in different parts of the code

Would you be so kind? It would be good to have something concrete to go
on.

> a. getpeername()

This could be a problem if the peer is somehow selecting an LL source
address. 

Under current rules, this would only happen if the it was attempting to
connect to an LL destination address, or if the application was
explicitly binding to the LL address. 

Which one of these would be the case with netsolve?

> b. gethostbyname (gethostname ()) 

This will return a global address on any but LL-only nodes.

If this is the way in which each netsolve node discovers its own IP
address, then every node will only be advertising its global address
(again assuming there are no LL-only nodes involved). Am I correct?

	MikaL

---

From: Keith Moore <[email-masked]>
Date: Sat, 22 Feb 2003 11:26:09 -0500

> believe the LLMNR specification already states that the resolver has to

don't get me started about LLMNR.  it's an even bigger mess than LL.
but that's for another group to deal with.

> So, I expect no problems with applications that use gethostbyname().

that's an overgeneralization.  there are lots of problems with scoped
addresses that have nothing to do with where the app gets the address from.

> about concrete APIs and how they behave.

IMHO looking at a few concrete examples tends to misses the point - because
you cannot analyze the behavior of all network applications.

> > > > the vast majority of IPv4 hosts do not have multiple network
> > > > interfaces, or if they do, do not use more than one of those
> > > > interfaces at a time. and the vast majority of IPv4 hosts do not have
> > > > multiple IPv4 addresses assigned to them. a lot of software will break
> > > > in the presence of multiple addresses on a host.
> > > 

well, you asked a specific question, and I gave a specific answer.  frankly I
don't see how your question is relevant to the discussion, but it was easy to
answer.

> > > > basically
> > > > netsolve does not have the ability to deal with scoped addresses, and
> > > > it's impractical to fix netsolve so that it does deal with them
> > > > robustly.)
> > > 

or if the peer did not currently have a routable address.
 
> This will return a global address on any but LL-only nodes.

not clear.  for instance, my powerbook insists on setting its hostname based
on its own whims. fortunately, most UNIX hosts are better behaved than that.

also, when you say LL-only nodes do you mean nodes which cannot have a
routable address (which IMHO should not exist) or do you mean nodes which
currently do not have a routable address?

> (again assuming there are no LL-only nodes involved). Am I correct?

no.  just because it's often possible to arrange things so that 
gethostbyname (gethostname ()) produces an address of one's choosing,
does not mean that this is a reliable way to get a global address.

---

From: Mika Liljeberg <[email-masked]>
Date: 22 Feb 2003 19:13:39 +0200

> but that's for another group to deal with.

Heh. I agree. Let's just say that LLMNR is a potential source of LL
addresses and leave it at that.

> addresses that have nothing to do with where the app gets the address from.

Granted, but you know what I meant: I expect no problems due to
applications using gethostbyname() on nodes having both LL and routable
addresses.

> you cannot analyze the behavior of all network applications.

I'm not looking to generalize isolated examples. Concrete examples are
necessary to support a viewpoint. If a problem is prevalent, coming up
with concrete example cases should be quite easy. It goes to
establishing credibility.

> don't see how your question is relevant to the discussion, but it was easy to

Ok, my bad. I was just trying to understand what you meant by your
reference to the netsolve bind-to-specific-address kludge. I guess there
was no particular significance hidden there.

> or if the peer did not currently have a routable address.

True. However, that is not relevant to the discussion, since neither LL1
nor LL23 can change that.
 
> on its own whims.

In other words, gethostbyname (gethostname ()) can fail to return an
address even if the node only has a routable one. Clearly this can
happen if the hostname is not registered in DNS, but I would say that is
an unrelated problem.

>  fortunately, most UNIX hosts are better behaved than that.

I guess any host can be misconfigured to return a bad hostname.

> currently do not have a routable address?

The latter (or both).

> does not mean that this is a reliable way to get a global address.

True. However, if gethostbyname (gethostname ()) fails to produce a
global address it will do so regardless of whether the node has an LL
address or not. I.e., the LL address is not the cause of the problem.

	MikaL

---

From: Mika Liljeberg <[email-masked]>
Date: 22 Feb 2003 19:24:00 +0200

> > Would you be so kind? It would be good to have something concrete to go

Before I forget, can we conclude that nodes having both LL and routable
addresses would not break netsolve? Or do you plan to provide additional
evidence?

	MikaL

---

From: Keith Moore <[email-masked]>
Date: Sat, 22 Feb 2003 12:40:23 -0500

> applications using gethostbyname() on nodes having both LL and routable

actually, no, that wasn't obvious.

even then, I'm not sure it's true  on hosts (like my powerbook) that
arbitrarily set the hostname.

> > IMHO looking at a few concrete examples tends to misses the point -
> > because you cannot analyze the behavior of all network applications.
> 

part of the problem is that some of the examples are obscure, so people argue
that it's okay to screw the net so that these obscure apps fail. what they
fail to see is the harm that this does to the network's utility, and that
obscure apps, and apps that don't exist yet, can be important also.   also, it
takes time to document examples, and when I've done so in the past people in
this WG have conveniently forgotten about them.

> > well, you asked a specific question, and I gave a specific answer. 
> > frankly I don't see how your question is relevant to the discussion, but
> > it was easy to answer.
> 
> reference to the netsolve bind-to-specific-address kludge. 

basically that existing apps do have problems when multiple addresses are
assigned to a host and not all of them are globally usable.

> nor LL23 can change that.

it's hard to keep track of discussion contexts.

> > not clear.  for instance, my powerbook insists on setting its hostname
> > based on its own whims.
> 
> address even if the node only has a routable one. 

or it can fail to return a routable address even if the node has one.

it's *often* (perhaps not always) possible for a user to work around this, say
by putting an entry in /etc/hosts.  (I think there's an equivalent for
windows, but it's fairly obscure).

> I guess any host can be misconfigured to return a bad hostname.

some hosts are shipped with code that overrides the user's specified hostname.

> address or not. I.e., the LL address is not the cause of the problem.

I suppose it depends on the implementation.  my powerbook kept insisting
on setting its hostname to something like keith-moores-computer.local.
whether or not it was binding that to an LL address I can't tell any longer -
I did my best to disable all of that crap.

Keith

---

From: Keith Moore <[email-masked]>
Date: Sat, 22 Feb 2003 12:42:30 -0500

On 22 Feb 2003 19:24:00 +0200
Mika Liljeberg <[email-masked]> wrote:

> > > > > > netsolve does not have the ability to deal with scoped addresses,
> > > > > > and it's impractical to fix netsolve so that it does deal with
> > > > > > them robustly.)
> > > > > 
> > > > > Excellent, a concrete example! How does netsolve normally determine
> > > > > the address it advertises?
> > > > 
> > > > I'll have to look at the code again to be sure, but from memory, it
> > > > does different things in different parts of the code
> > > 

no, we can't conclude that.   there is emperical evidence that having scoped +
global addresses on a host can break netsolve.   that doesn't mean that I'll
find the time to investigate and report in detail.

Keith

---

From: Mika Liljeberg <[email-masked]>
Date: 22 Feb 2003 19:51:23 +0200

> find the time to investigate and report in detail.

In other words the WG should just take your word for it. That's too bad.

	MikaL

---

From: Keith Moore <[email-masked]>
Date: Sat, 22 Feb 2003 12:51:41 -0500

> > no, we can't conclude that.   there is emperical evidence that having
> > scoped + global addresses on a host can break netsolve.   that doesn't
> > mean that I'll find the time to investigate and report in detail.
> 

the problems are obvious to anyone who looks for them.

---

From: Mika Liljeberg <[email-masked]>
Date: 22 Feb 2003 20:28:00 +0200

> arbitrarily set the hostname.

As I said, any node can be misconfigured to return a bogus hostname. The
presence or absense of an LL address has no bearing on this. An
application relying on the hostname would fail regardless.

> obscure apps, and apps that don't exist yet, can be important also.

I'm prepared to take your word that there are obscure examples. I expect
there is. Obscure examples, however, don't support the claim that the
problem would be prevalent and would somehow "cripple the net".

I also agree that apps which don't exist yet are important. However, if
they want to stick to routable addresses they can easily do so. They
don't have the excuse of not knowing about LL addresses.

I would even be prepared to take some reasonable measures to mitigate
the obscure problems if I knew what is the right thing to do and if it
was simple to do. Currently, I'm not convinced that LL1 or LL23 is it.
Until I am, the added implementation complexity will cause me to reject
them.

>    also, it

I freely admit that I probably haven't seen those examples. If you can
provide a pointer to the archive I would be happy to review them. In the
interest of resolving issues LL1 and LL23, however, it would be better
to discuss them on the list.

> assigned to a host and not all of them are globally usable.

Ok. A general argument against scoped addressing, then. Valid, perhaps,
but not useful for determining the technical soundness of LL1 and LL23.

> or it can fail to return a routable address even if the node has one.

Indeed. Fail is the operative word.

> I did my best to disable all of that crap.

Well, sounds like a Windows specific problem. Maybe Christian can
comment? :-)

	MikaL

---

From: Mika Liljeberg <[email-masked]>
Date: 22 Feb 2003 20:28:44 +0200

> the problems are obvious to anyone who looks for them. 

Well, you have to admit that I'm trying very hard to understand your
point of view.

Are we going to be left without any concrete examples to support your
view?

	MikaL

---

From: Keith Moore <[email-masked]>
Date: Sat, 22 Feb 2003 14:33:05 -0500

> As I said, any node can be misconfigured to return a bogus hostname. 

my point is that some nodes do this out of the box, and are not easily
fixed to not do this.

> The presence or absense of an LL address has no bearing on this. An

not true in the case of my powerbook, which will at least in some cases
choose a host name that is only associated with an LL address. 

> problem would be prevalent and would somehow "cripple the net".

actually they do - as long as the apps fail for reasons that would be
commonly encountered.  what causes one app to fail can cause another app to
fail.

> they want to stick to routable addresses they can easily do so. 

only if all hosts on which the app is running have routable addresses.
 
> Until I am, the added implementation complexity will cause me to reject

the specific language of both proposals may be broken, but in general avoiding
use of LL when a host has a routable address will greatly minimize the
problems associated with LL. 

> but not useful for determining the technical soundness of LL1 and LL23.

I disagree,  because without a way to disable LL when routable addresses
are in use, this condition that causes app failures will crop up considerably
more often than it does now.

> > whether or not it was binding that to an LL address I can't tell any
> > longer - I did my best to disable all of that crap.
> 

how would a powerbook failure be windows-specific?  it runs macos.

Keith

---

From: Keith Moore <[email-masked]>
Date: Sat, 22 Feb 2003 14:35:37 -0500

> Are we going to be left without any concrete examples to support your

I would like to supply such examples.  But I doubt I'll have time to
investigate and write them up in detail within the next several days.

---

From: Mika Liljeberg <[email-masked]>
Date: 22 Feb 2003 22:12:29 +0200

> choose a host name that is only associated with an LL address. 

That's still an OS specific problem. We don't put vendor specific bug
workarounds into IETF specifications.

> commonly encountered.  what causes one app to fail can cause another app to

If the failures were common they wouldn't be obscure. You can't have it
both ways.

> only if all hosts on which the app is running have routable addresses.

I agree that configurations with LL-only nodes will fail. This is not
relevant to the LL1/LL23 discussion.

> problems associated with LL. 

It's not a problem of language. It's a problem of implementation
complexity versus usefulness. At the moment the tradeoff does not favor
LL1/LL23.

> more often than it does now.

We're degenerating to generalities again. We have yet to see any proof
of this.

> how would a powerbook failure be windows-specific?  it runs macos.

Oops, brain fart. Sorry, Christian! Maybe Stuart can comment? :-)

	MikaL

---

From: Ted Lemon <[email-masked]>
Date: Sat, 22 Feb 2003 13:28:33 -0700

> choose a host name that is only associated with an LL address.

If true, this is a bug.   The right thing to do about it is to fix the 
bug, not to break the protocol.

---

From: Keith Moore <[email-masked]>
Date: Sat, 22 Feb 2003 16:26:05 -0500

> workarounds into IETF specifications.

disagree.  installed base compatibility is often a design issue in IETF specs.

> > commonly encountered.  what causes one app to fail can cause another app
> > to fail.
> 

the failures are common to several apps, but the individual apps are obscure.
but because the failures are associated with obscure apps, they might not
be recognized as different symptoms of the same problem.

> relevant to the LL1/LL23 discussion.

yes it is, because even nodes capable of having routable addresses will 
sometimes fail to have them, or fail to use them, unless we specify 
the conditions under which routable addresses are preferred over LLs.

> > the specific language of both proposals may be broken, but in general
> > avoiding use of LL when a host has a routable address will greatly
> > minimize the problems associated with LL. 
> 

strongly disagree.  it's not acceptable for LL to break apps, especially
not without providing a workaround.
 
> > > > basically that existing apps do have problems when multiple addresses
> > > > are assigned to a host and not all of them are globally usable.
> > > 
> > are in use, this condition that causes app failures will crop up
> > considerably more often than it does now.
> 

proof has been given more than once.  

Keith

---

From: Mika Liljeberg <[email-masked]>
Date: 23 Feb 2003 00:06:13 +0200

> disagree.  installed base compatibility is often a design issue in IETF specs.

Bug workarounds aren't. Bugs should be fixed, not coddled.

> be recognized as different symptoms of the same problem.

If there are a lot of these obscure problem apps I might be familiar
with some of them. Suppose you mention a few and I say if anything rings
a bell?

> the conditions under which routable addresses are preferred over LLs.

The draft already does that. LL1/LL23 just seeks to define different
rules. What we're trying to determine is whether that change is worth
the trouble.

> not without providing a workaround.

We can't possibly provide a workaround for every broken app out there.
That's simply impossible, not to mention a poor design philosophy.
 
> proof has been given more than once.  

I haven't seen any proof that LL1/LL23 is a good idea.

	MikaL

---

From: Keith Moore <[email-masked]>
Date: Sat, 22 Feb 2003 17:18:24 -0500

> Bug workarounds aren't. 

sure they are.  it's just being pragmatic.

> with some of them. Suppose you mention a few and I say if anything rings

most of them are obscure to me, too.  but netsolve, PVM, and SIP certainly
qualify.  others worth looking at are MPI implementations, various distributed
games, distributed simulations, conferencing software.
 
> The draft already does that.

the current draft does it in such a way as to *cause* problems.

> That's simply impossible, not to mention a poor design philosophy.

the apps aren't broken. scoped addresses are broken.
 
> I haven't seen any proof that LL1/LL23 is a good idea.

that's just because you don't want to see it.

---

From: Mika Liljeberg <[email-masked]>
Date: 23 Feb 2003 01:04:39 +0200

> games, distributed simulations, conferencing software.

Ok, these are apps that might have problems with scoped addresses, at
least. SIP and H.323 are probably the most likely candidates. Don't know
too much about MPI implementations but the rest don't look like referral
apps. Multiplayer games typically just use centralized servers. LL will
probably just benefit LAN gaming.

Anyone know one of these well enough to give a concrete example
supporting LL1 or LL23? I don't want to impose on Keith too much, since
he is pressed for time.

(Netsolve we already did; didn't seem to be a problem. )

> that's just because you don't want to see it.

You don't give up, do you?

	MikaL

---

From: "Philip Nye" <[email-masked]>
Date: Sat, 22 Feb 2003 23:35:50 -0000

> From: "Mika Liljeberg" <[email-masked]>

It is highly relevant because the issue of allowing LL only nodes has not
yet been discussed and may go either way so far as I can tell. If LL1 and
LL23 are rejected and then LL-only nodes are allowed then we are really in
trouble.

As it is LL-only nodes will exist anyway - because of configuration issues
and because of transition issues (and because there is sufficient commercial
pressure that they will be built whether or not this standard blesses them).

Why define a standard which falls over in their presence when with a little
more effort it can be a lot more robust?

Why define a standard which relies heavily on things like LLMNS (itself not
a standard ) when with a little more effort it can be far more generic?

I can only conclude that you don't want to put in that effort.

LL23/LL1 are not over complex and the principle behind them provides the
best (though imperfect) interoperability in the widest range of situations.

Philip

---

From: Keith Moore <[email-masked]>
Date: Sun, 23 Feb 2003 00:22:42 -0500

> apps. 

you don't know what you're talking about.  

> Multiplayer games typically just use centralized servers. 

some, not all.

> LL will probably just benefit LAN gaming.

consider a game on a LAN with a mixture of LL and routable addresses.
now add one or more hosts from another link and see what happens.

> (Netsolve we already did; didn't seem to be a problem. )

netsolve does have problems with scoped addresses. 

> You don't give up, do you?

nor you.  but apparently you don't mind telling outright lies.

Keith

---

From: Mika Liljeberg <[email-masked]>
Date: 23 Feb 2003 10:49:24 +0200

On Sun, 2003-02-23 at 01:35, Philip Nye wrote:
> yet been discussed and may go either way so far as I can tell.

Looks like we have a different definition of LL-only. I mean a node that
doesn't have a routable address at the moment, while you seem to mean a
node that cannot have a routable address at all. Correct?

>  If LL1 and

This claim is familiar. Please explain what you mean by "really in
trouble" and back it up with a concrete example.

> more effort it can be a lot more robust?

Generalities and exaggeration again. Christian's address leakage
argument is the most compelling general argument I've seen so far.
However, the WG has already dismissed that concern by dismissing LL19.

> a standard ) when with a little more effort it can be far more generic?

I don't see anything that relies on LLMNR. The discussion you're
probably referring to concerned name resolver API behaviour on compliant
nodes.

> I can only conclude that you don't want to put in that effort.

You're not being entirely fair, there. I'm putting a good deal of effort
into reaching a design I feel would be simple and clean. Implementation
complexity is nearly always a sign of shoddy design.

> LL23/LL1 are not over complex

LL23 is extremely difficult to implement in a manner that provides a
satisfactory user experience. LL1 would be simple enough, even though it
creates an alternate exceptional code path for source address selection,
and I could probably live with it if that made the WG happy.

>  and the principle behind them provides the

Only extensive deployment experience can give grounds to such a claim.
What experience is the claim based on?

	MikaL

---

From: Mika Liljeberg <[email-masked]>
Date: 23 Feb 2003 10:57:12 +0200

Keith,

That's certainly a civil way to end a discussion. I would have liked to
discuss the applications one by one, but it looks like further argument
with you would not be very productive.

	MikaL

---

From: Erik Guttman <[email-masked]>
Date: Sun, 23 Feb 2003 11:18:31 +0100

> investigate and write them up in detail within the next several days. 

It is in no way unfair to say that this process must come to an
end - soon - and that we have all had months to gather evidence
for our arguments and innumerable calls for concrete examples
of applications which fail due to link-local.

After we conclude our last call, further arguments may of course
be submitted directly to the IESG for their consideration.  Our goal
is to settle on a revisions and give the IESG a revised draft ASAP.
We must achieve at least rough consensus to conclude our WG last call
with a recommendation, however.

 > disagree.  installed base compatibility is often a design issue

I agree with Keith here.  If we break the installed base, this is a
bad, potentially unacceptable thing.   How *precisely* do we break
the installed base?

 > most of them are obscure to me, too.  but netsolve, PVM, and SIP
 > certainly qualify.  others worth looking at are MPI implementations,
 > various distributed games, distributed simulations, conferencing
 > software.

SIP has increasing mechanisms for working around NAT that allow
SIP to function over address scope boundaries.  Netsolve has been
discussed and the problems raised have not yet been made clear or
convinced the list.  What is PVM and MPI?  What are the specific
issues which would make use need to accept LL1 or LL23?

Erik

---

From: Mika Liljeberg <[email-masked]>
Date: 23 Feb 2003 12:41:19 +0200

> bad, potentially unacceptable thing.   How *precisely* do we break

The specific issue that was being discussed here was MacOS returning an
invalid hostname, apparently in conjunction with the use of a link local
addressing or name resolution. As such, I don't think it qualifies as an
example of installed base. It only qualifies to point out the immaturity
of said implementation (which is understandable as the specifications
are not ready either).

I also agree that breaking the installed base is a very bad idea if
there is a clear understanding that such breakage is likely to take
place.

	MikaL

---

From: Erik Guttman <[email-masked]>
Date: Sun, 23 Feb 2003 11:48:33 +0100

> of said implementation (which is understandable as the specifications

This is not an issue with link-local autoconfiguration which is being
discussed here.  The behavior you are referring to is that of Apple's
Rendezvous product.

Erik

---

From: Mika Liljeberg <[email-masked]>
Date: 23 Feb 2003 13:15:36 +0200

> discussed here.  The behavior you are referring to is that of Apple's

I understand that. I took the problem to be related to transitions
between LL-configured/LL-unconfigured states and MacOS trying to be
smart in what it returns as its own hostname.

Be as it may, rendezvous is a variant of LLMNR (or perhaps the other way
around), which is not yet an accepted IETF specification. Allowing the
installed base based of a work-in-progress to sway specification of said
or other Internet drafts does not seem like a smart thing to do. It
seems likely that Apple will fix these problems as a matter of course.
But I don't know enough about their product, so I won't say more than
that. Perhaps Stuart can offer a view.

	MikaL

---

From: Keith Moore <[email-masked]>
Date: Sun, 23 Feb 2003 07:32:12 -0500

> with you would not be very productive.

funny, I'd reached the identical conclusion about you.

---

From: Keith Moore <[email-masked]>
Date: Sun, 23 Feb 2003 07:38:40 -0500

> discussed here.  The behavior you are referring to is that of Apple's

actually it's less than that - it's just a statement about how reliable
gethostbyname (gethostname ()) is at finding a routable IP address.
people have been trying to make overgeneralizations of the form 
"LL will not break apps", and this is a counterexample.

Keith

---

From: Keith Moore <[email-masked]>
Date: Sun, 23 Feb 2003 07:50:49 -0500

> of applications which fail due to link-local.

Such concrete examples have been given more times than I can count.
(or at least, I'm not willing to cull through the archives to do so)

Of course, responding to posts to this list only takes minutes per post, while
providing detailed analysis of failures for applications takes several hours
of focused work per application.  Actually testing the apps for failures under
controlled conditions takes a lot of time also.  It's much harder to find
those chunks of time, and given past experience with an attempt to provide
detailed analysis it's hard to believe that such an investment is worthwhile.

That and I object to the entire line of argument.  It's not unreasonable to
want examples of things that break, but those have been given.  It is
unreasonable to dismiss those examples out-of-hand because there is a fix for
one specific app, or because an app doesn't fail under one artifical set of
conditions that you specify, and then claim that there's no general problem.

Keith

---

From: Ted Lemon <[email-masked]>
Date: Sun, 23 Feb 2003 11:36:39 -0700

> "LL will not break apps", and this is a counterexample.

This is an example of how gethostbyname(gethostname()) breaks apps.   
Gethostbyname(gethostname()) is never the right way to get a host's IP 
address.   When it works, it's a happy coincidence.   The fact that 
people use it as much as they do is a result of the fact that there 
isn't a nice API that says "what's my address," which is in turn a 
result of the fact that it is usually not possible to give a good 
answer to that question.   My point is that the fact that IPv4ll might 
in some cases break gethostbyname(gethostname()) isn't a very 
compelling worry.

BTW, note that in the specific case you were talking about, with LLMNS 
working the way I suggested, gethostname(gethostbyname()) does in fact 
return a global IP address if you have one, and an IPv4ll address if 
you don't - that is, it's actually *more* reliable than usual, not less.

---

From: Erik Guttman <[email-masked]>
Date: Mon, 24 Feb 2003 14:06:22 +0100 (MET)

On Sun, 23 Feb 2003, Keith Moore wrote:

> Date: Sun, 23 Feb 2003 07:50:49 -0500
> From: Keith Moore <[email-masked]>
> To: Erik Guttman <[email-masked]>
> Cc: [email-masked], [email-masked], [email-masked],
>     [email-masked], [email-masked], [email-masked]
> Subject: Re: LL1, LL23
> 

Concrete examples have to be given here or pointed to in the mailing
list in order to weigh as evidence of a problem.  We have a document
which has gone through WG and IETF last call multiple times.  There were
objections that the WG had not considered problems.  It is in no way
inappropriate to demand specific examples.

Erik

---

From: Keith Moore <[email-masked]>
Date: Mon, 24 Feb 2003 08:06:18 -0500

> inappropriate to demand specific examples.

it's not inappropriate to demand specific examples, but these have been
given.  it is inappropriate to try to disregard the general problem
by saying that there are workarounds for those specific examples, or that 
they don't fail in every case.