Subject: [Issue 1]: Preferred use of configured to v4LL

From: Bernard Aboba <[email-masked]>
Date: Mon, 17 Feb 2003 08:13:03 -0800 (PST)

I support the proposed resolution, subject to the constraint that a host
would not initiate new connections from the v4LL once a configured address
is acquired, but would not have to immediately drop old ones.

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 17 Feb 2003 09:52:53 -0800 (PST)

Now that I've realized that Issue 1 and Issue 23 are mutually exclusive,
I'd like to advocate that Issue 1 be rejected, and that the problems
described there be solved via the approach of Issue 23 instead.

---

From: "Philip Nye" <[email-masked]>
Date: Wed, 19 Feb 2003 12:31:22 -0000

I support the principle of both these - that a node should not try and
obtain or use a LL address when a routable address is available. However, I
note that both these only reference section 1.5 while there are other places
that this principle needs to be mentioned - including section 2.6 "Source
Address Selection" (see LL26).

Comparing the two: LL23 better describes the issue of transition from
zero-config to configured networks but the same behaviour is not precluded
by LL1; LL23 says "don't configure" a LL address while LL1 just says "don't
use" it.

Neither option directly tackles the more difficult issue of transition from
configured to zero-config but LL23 might conflict with sensible attempts to
solve this issue (what if you have a routable address but it no longer seems
to work) so I currently favour LL1.

Philip

---

From: Keith Moore <[email-masked]>
Date: Wed, 19 Feb 2003 12:33:09 -0500

> configured to zero-config 

this is an interesting case.  IMHO it should only happen when a network is
losing its external address prefix, or by explicit decision of the network
admin. if the routable addresses remain valid (i.e. they're not being
reassigned)  it's better for the network to use routable addresses (even if
the network is isolated) than to use LL addresses.

I suppose it would be useful to define ways for DHCP to say "stop using your
DHCP assigned address and start using LL" in addition to the other things we'd
like it to be able to say (e.g. "don't use LL" or "it's okay to use LL in
addition to whatever routable addresses you've been assigned").

I'd strongly argue for using DHCP as the mechanism to do this, because DHCP is
already used for network config purposes, and DHCP authentication is already
defined (thus saving us the trouble of defining a new kind of authentication).

---

From: Ted Lemon <[email-masked]>
Date: Wed, 19 Feb 2003 11:57:55 -0700

> the network is isolated) than to use LL addresses.

How about when the DHCP server fails?

---

From: Keith Moore <[email-masked]>
Date: Wed, 19 Feb 2003 14:18:15 -0500

> > this is an interesting case.  IMHO it should only happen when a 
> > network is losing its external address prefix, or by explicit decision of
> > the network admin. if the routable addresses remain valid (i.e. they're
> > not being reassigned)  it's better for the network to use routable
> > addresses (even if the network is isolated) than to use LL addresses.
> 

when the DHCP server fails, you want your hosts to keep using the same
addresses they were using before.  switching to LL will not in general 
allow the apps to contiune to work, because most hosts support at least
one app that needs resources that are not on the local link.  proper 
configuration of the DHCP service, including selection of lease times,
helps a lot.

Keith

---

From: "s. goswami" <[email-masked]>
Date: Wed, 19 Feb 2003 14:46:18 -0500 (EST)

let me join the frey, what happens if there are multiple DHCP
servers, one saying use LL and another saying do not use LL ?
so the final decision to LL or not LL depends on the node itself.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 19 Feb 2003 13:00:08 -0700

> configuration of the DHCP service, including selection of lease times,

"DHCP server fails" means "DHCP server fails to renew a client's lease 
before it expires," and also "DHCP server fails to provide a lease for 
a new client, and the client doesn't have a valid lease it can attempt 
to use".  When either of these events occurs, the DHCP client MUST stop 
using its IP address, to avoid interoperability problems (e.g., when 
there is a shortage of IP addresses, the DHCP server is permitted to 
round-robin the addresses to the clients).

Since we have allowed the camel's nose under the tent by saying that a 
DHCP-allocated IP address trumps an IPv4ll address, then we have to 
account for what happens in both of the above cases.   So far we have 
accounted for what happens in only one of these cases.

---

From: Keith Moore <[email-masked]>
Date: Wed, 19 Feb 2003 15:00:26 -0500

> servers, one saying use LL and another saying do not use LL ?

garbage in, garbage out.

but this group isn't chartered to solve problems with DHCP configuration.

Keith

---

From: "s. goswami" <[email-masked]>
Date: Wed, 19 Feb 2003 15:13:39 -0500 (EST)

if you are saying DHCP is garbage, then make use of DHCP optional.
ideally DHCP should have no bearing on LL. by tying DHCP with LL
usage we are trying to solve DHCP configuration problems
among other things.

---

From: Keith Moore <[email-masked]>
Date: Wed, 19 Feb 2003 15:12:30 -0500

> accounted for what happens in only one of these cases.

Okay, the reason that we want hosts to use LL only when DHCP doesn't answer
is that we want these hosts to play well on configured networks.  Having
hosts configure LL when DHCP fails is not the same thing.  In the latter
case the host already knows its on a configured network, and that it is
seeing a failure.   Though it may work in limited instances, configuring LL 
is not in general a good means of recovering from such failures.

If hosts want to configure an LL address when DHCP doesn't renew their
leases, that's their own business.  The LL standard doesn't have to 
define what happens in that case, and probably shouldn't.  The right
behavior will differ from one host/app to another.  So I'd say that a
host MAY configure LL if it cannot renew its DHCP lease, but if it does
so it MUST continue attempting to acquire an address using DHCP,
and cease using the LL address once such an address acquired.

The point is that LL is not a suitable backup for DHCP server failure, 
nor for failure of network admins to properly configure their DHCP servers.
This is such a frequent point of confusion that it needs to be explicitly
said in the RFC.

Keith

---

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

> but this group isn't chartered to solve problems with DHCP configuration.

Come to think of it, this group isn't chartered to solve problems with
LL nodes connecting to managed networks.

	MikaL

---

From: Ted Lemon <[email-masked]>
Date: Wed, 19 Feb 2003 13:35:26 -0700

> but this group isn't chartered to solve problems with DHCP 

No, but neither is it chartered to *create* problems with DHCP 
configuration!

---

From: Keith Moore <[email-masked]>
Date: Wed, 19 Feb 2003 15:44:06 -0500

> if you are saying DHCP is garbage, then make use of DHCP optional.

nope, I'm saying that if you feed hosts broken DHCP configuations then
it's silly to expect them to behave in a useful fashion.

> usage we are trying to solve DHCP configuration problems

ideally LL should have no bearing on connected networks.  by tying LL to DHCP
we avoid many cases where LL would interfere with operation of those networks,
or of hosts or apps on those networks.

---

From: Keith Moore <[email-masked]>
Date: Wed, 19 Feb 2003 15:47:33 -0500

> LL nodes connecting to managed networks.

if LL nodes aren't going to be connected to the Internet, this group
has no business at all existing in IETF, except perhaps to avoid address
assignment conflicts as in RFC 1918.  but the LL protocol would not be in
scope for IETF.

on the other hand if LL nodes are going to be connected to the Internet, 
as is already happening, then IETF clearly has an interest in making sure
that those nodes don't interfere with IP networks more than necessary.

it's called "damage control".  why do you think this group was chartered?

Keith

---

From: Ted Lemon <[email-masked]>
Date: Wed, 19 Feb 2003 14:08:17 -0700

> This is such a frequent point of confusion that it needs to be 

I don't think anybody is disputing whether or not LL is a suitable 
backup for DHCP server failure, and I have not heard one person on this 
mailing list express anything that suggested that they were confused 
about this.   My personal opinion is that it is a mistake for there to 
be any interrelationship between IPv4ll and DHCP - the two should be 
orthogonal, because they do different things.

Perhaps a better way to frame this issue is: what happens if the 
network stack is configured with a routable IP address, and then later 
that address is unconfigured?   Does the IPv4ll agent at that point 
immediately go out and get an IPv4 address and start using it?   I 
think it does.   I agree with you that this is no substitute for having 
a routable IP address, but that's not the point.   The routable IP 
address is being *used* as by IPv4ll while it exists.   When it goes 
away, in order to avoid losing *IPv4ll* functionality, the IPv4ll agent 
needs to go get an IPv4ll address again.   Or if there is still an 
IPv4ll address lying around, the stack needs to start using it, and it 
needs to be published in LLMNS.

---

From: Keith Moore <[email-masked]>
Date: Wed, 19 Feb 2003 16:09:18 -0500

> immediately go out and get an IPv4 address and start using it?  

the device does whatever it wants to do.  LL might or might not
be suitable for its purposes.  we shouldn't insist that a device 
configure or use LL when it's attached to a connected network.

---

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

> it's called "damage control".  why do you think this group was chartered?

Well, if I had to venture a guess I would say this group was chartered
to do what the charter states:

"The goal of the Zero Configuration Networking (ZEROCONF) Working Group
is to enable networking in the absence of configuration and
administration. Zero configuration networking is required for
environments where administration is impractical or impossible, such as
in the home or small office, embedded systems 'plugged together' as in
an automobile, or to allow impromptu networks as between the devices of
strangers on a train. "

Note some of the highlights:

"in the absence of configuration and administration"

"where administration is impractical or impossible"

"embedded systems 'plugged together'"

"impromptu networks"

You may not agree with the charter but don't try to rewrite it to your
liking. Zeroconf exists, therefore it is within IETF scope.

Now, I have nothing against considering the issues with connecting to
managed networks and I agree that they are relevant, even if not part of
the charter. However, let's not step into the realm of the absurd and
claim that zeroconf itself is outside the scope of IETF.

IP has two key properties: interoperability and link-layer agnosticity.
InterNETworking is a byproduct, even if it was a nice buzzword some 20
years ago.

	MikaL

---

From: Ted Lemon <[email-masked]>
Date: Wed, 19 Feb 2003 14:22:35 -0700

> or of hosts or apps on those networks.

You have yet to offer an example of these many cases where LL would 
interfere with operation of connected networks, so this is not a valid 
reason to say that we need to tie LL to DHCP.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 19 Feb 2003 14:23:24 -0700

> it's called "damage control".  why do you think this group was 

In order to create value.   Anyway, that's why I'm here.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 19 Feb 2003 14:26:26 -0700

> we shouldn't insist that a device

Maybe it's not a connected network anymore.   Maybe the reason the 
configured address went away is that the network connection went away.

---

From: Keith Moore <[email-masked]>
Date: Wed, 19 Feb 2003 16:25:20 -0500

> Well, if I had to venture a guess

there's the stated reason and then there's the real reason.  different things.

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 19 Feb 2003 16:27:28 -0500

> interfere with operation of connected networks,

no, you have yet to listen to them.

---

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

> there's the stated reason and then there's the real reason.  different things.

They say that reality is a subjective thing.

	MikaL

---

From: Keith Moore <[email-masked]>
Date: Wed, 19 Feb 2003 16:41:08 -0500

> configured address went away is that the network connection went away.

those are two separate cases.  but the argument remains the same.

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 19 Feb 2003 16:47:52 -0500

> They say that reality is a subjective thing.

True.  But I was on the IESG at the time the group was chatered.  You weren't.

Of course it's likely that different ADs had different reasons for not
objecting to the creation of the WG.   But from the NITS BOFs it was obvious
that this group was going to be a real headache, and we usually try to avoid
headaches except when we think that doing so will create bigger headaches.
Sadly, "damage control" is a motivation for a lot of WG approvals.

---

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

> Sadly, "damage control" is a motivation for a lot of WG approvals.

Fair enough.

However, having not been there, I'm sure you'll forgive me if I proceed
on what is stated.

	MikaL

---

From: Ted Lemon <[email-masked]>
Date: Wed, 19 Feb 2003 14:59:04 -0700

> no, you have yet to listen to them.

I heard you say a bunch of stuff, Keith.   I spent a substantial effort 
trying to see if what you were saying was correct.   I determined that 
what you were claiming was not true.   I explained why.   Not agreeing 
with you is not the same thing as not listening to you.

---

From: Keith Moore <[email-masked]>
Date: Wed, 19 Feb 2003 16:59:20 -0500

> what you were claiming was not true. 

you did no such thing.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 19 Feb 2003 15:14:44 -0700

> those are two separate cases.  but the argument remains the same.

If the reasons given to support an argument have been shown to be 
incomplete, and no additional reasons have been given that complete 
what is missing, then the argument is invalid.

This working group is in the business of producing an IPv4ll draft that 
works consistently, predictably and reliably.   You are saying that we 
should not specify how an IPv4ll-aware node should operate in a certain 
situation that we can reasonably expect to occur.   You are 
recommending that we leave it up to the implementor to choose what 
happens in this case.   If we follow your recommendation, the behavior 
of IPv4ll will be neither consistent nor reliable.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 19 Feb 2003 15:34:03 -0700

>> what you were claiming was not true.

Sure I did.   You just didn't accept my reasons for disagreeing with 
you.   That's not the same thing.

---

From: Keith Moore <[email-masked]>
Date: Wed, 19 Feb 2003 17:33:56 -0500

> what is missing, then the argument is invalid.

you haven't shown the reasons to be incomplete. 

> works consistently, predictably and reliably.   

it's not even close, though I'd be happy if it took that task on.

> You are saying that we 
> situation that we can reasonably expect to occur.  

no, what I'm saying is that the node should not presume that failure 
to renew a DHCP lease is an indication that a network partitioning has
occured, and the WG should not presume that using LL is a useful failure 
mode for a device even if such a partitioning really did occur.

folks should stop trying to impose LL in places where it gets in the way.

> You are 

the behavior of hsots is not consistent.  different hosts serve different
purposes.  the behavior of hosts in response to network failures will also
need to vary depending on the needs of that host and the apps that it
supports.

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 19 Feb 2003 17:37:57 -0500

> Sure I did.  

bullshit.  I know the code I work with, I know the problems it has with
scoped addresses.   you don't know what the hell you're talking about.

Keith

---

From: "Philip Nye" <[email-masked]>
Date: Wed, 19 Feb 2003 23:11:10 -0000

> From: "Keith Moore" <[email-masked]>
>

There is no chance of imposing LL. Compliance with v4LL is not going to be
obligatory and configuration and use of a LL address is certainly optional
even if you are LL aware. However, for those who would prefer a LL address
to no functional address at all, there is nothing in the document - not even
vague guidance - as to when you might start to consider starting to use
v4LL.

Philip

---

From: "Philip Nye" <[email-masked]>
Date: Wed, 19 Feb 2003 23:14:24 -0000

> the network is isolated) than to use LL addresses.

It could easily happen when your NAT router with DHCP server goes down or is
unplugged. Those DHCP leases will run out eventually.

The case where you unplug from one network and plug into another is closely
related to this. It is a transition from one state to another which might be
zero-config. If you have been running in zero-config mode, the requirement
to periodically try DHCP will ensure a transition. If you have been running
configured, there is nothing to trigger a reconfiguration and no guideline
in the document so say when it is OK to start trying for LL again.

Waiting till your lease runs out and you fail to renew it could be a long
time. That is OK if your address continues to work for that time but this
won't necessarily be the case.

These are both cases of detecting the absence of valid configuration which
is harder than detecting its presence - what makes you start? how long do
you try for?

Philip

---

From: Keith Moore <[email-masked]>
Date: Wed, 19 Feb 2003 18:22:02 -0500

> obligatory 

LL is already being imposed on people who buy windows or mac boxes (which is
to say, the vast majority of computer users) and the networks that these
boxes connect to.  the least we can do is try to standardize LL in such a way
as to minimize problems.  (apparently vendors have already tried to do that,
by favoring DHCP over LL, and I'm glad they did that)

> and configuration and use of a LL address is certainly optional
> even if you are LL aware. 

not in the current document it isn't.

> However, for those who would prefer a LL address to no functional address at
> all, there is nothing in the document - not even vague guidance - as to when
> you might start to consider starting to use v4LL.

this is not a decision that can be made at this level of granularity.  since
scoped addresses break some apps and isolation breaks others, whether or not
to use LL should be an application-specific choice.  similarly, whether or
not to attempt to recover from DHCP failure by using LL is an 
application-specific choice.  currently neither the host nor the app has 
any way of knowing whether the DHCP failure is a server failure, a network
partitioning, or a network reconfiguration - but a given app may want to
deal with each of these in different ways.  at least the app implementor
knows the  consequences of making the wrong choice for his app.  the OS
implementor has no idea what those consequences are for the apps on that host.

Keith

---

From: Ted Lemon <[email-masked]>
Date: Wed, 19 Feb 2003 16:55:03 -0700

> won't necessarily be the case.

Actually, as long as you have a valid routable IP address, you can 
continue to use that address for IPv4ll, so that's not a problem.   If 
you are connected to a network and get an IP address from a DHCP 
server, and then are plugged into another network with no DHCP server, 
you will be able to interoperate with IPv4ll-aware nodes on that 
network, as long as those nodes have not been configured with 
non-IPv4ll IP addresses.

There _is_ the problem of doing IPv4ll with your routable IPv4 address 
when you move to another network on which there is a DHCP server that 
just won't talk to you.   There's also the problem of doing IPv4ll once 
your lease on your routable address expires, in the case that you are 
connected to a network where only IPv4ll is supported.

Adoption of LL1 breaks the first case.   Adoption of LL23 breaks the 
second case.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 19 Feb 2003 17:05:54 -0700

> implementor has no idea what those consequences are for the apps on 

Earlier you were saying that you think the application shouldn't have 
to be aware of whether it is using an IPv4ll address or a non-scoped 
address.   Here it seems like what you are saying is that an app that 
needs to care which kind of address gets used (e.g., one that is doing 
a referral) is going to _have_ to make the decision itself - there is 
no way the O.S. can make the decision for it.   Am I understanding you 
correctly?

---

From: Keith Moore <[email-masked]>
Date: Wed, 19 Feb 2003 19:07:23 -0500

> > Waiting till your lease runs out and you fail to renew it could be a 
> > long time. That is OK if your address continues to work for that time but 
> > this won't necessarily be the case.
> 
> continue to use that address for IPv4ll, so that's not a problem.  

> If you are connected to a network and get an IP address from a DHCP 

...and as long as apps on those nodes don't try to use your IP address
in referrals to other nodes.  i.e. it might work in a pinch but
you shouldn't depend on it.

somehow I don't think this WG is going to solve all of the problems that
can crop up when DHCP servers fail, networks renumber abruptly, or hosts
move from one network to another - whether or not LL is involved.

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 19 Feb 2003 19:14:44 -0500

> address.   

not sure what context you are referring to.  

no, I don't think apps should have to special-case handling of addresses. 
and yet scoped addresses work differently than globals.  so if scoped
addresses exist, it's unavoidable that some apps are going to need to deal
with them.  some apps will deal with LL by trying to avoid using LL addresses,
some will go to elaborate means to try to make things work in a mixture of LL
and routable addresses, and some apps can be blissfully ignorant of LL and
work about as well as they ever did.

> Here it seems like what you are saying is that an app that 

yes, I think you're understanding at least part of what I'm saying.
note that there are multiple decisions here - whether to listen to an LL
address, whether to send to an LL address, whether to use an LL address
as a source address (by explicitly binding either an LL or another address
to the local end of the socket), whether to send a referral containing
an LL address, and whether to try to use LL addresses for some of these
purposes when routable addresses cease to work.  

and there's no way (at least with current APIs) that the OS can reasonably
make these decisions on an app's behalf.

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 19 Feb 2003 22:51:51 -0500

> > somehow I don't think this WG is going to solve all of the problems 
> > that can crop up when DHCP servers fail, networks renumber abruptly, or 
> > hosts move from one network to another - whether or not LL is involved.
> 
> No, we definitely can't.   But that's not what we're trying to do, so 
> it's okay.  But is _is_ possible to write the document so that  IPv4ll 
> connectivity isn't prevented in cases where it doesn't need to be.

I'm not sure that it is possible to do so in all cases without making some
fairly bogus assumptions about the nature of failures.

Keith

---

From: Ted Lemon <[email-masked]>
Date: Wed, 19 Feb 2003 18:03:34 -0700

> you shouldn't depend on it.

Yup.   If you only have link-local connectivity, you can't communicate 
off the link.   And the case where you have an invalid IP address for 
network to which you're connected, if you have a mix of devices with 
link-local and non-link-local addresses, you won't be able to 
communicate with the devices that have non-link-local addresses either 
directly or by referral.

> that

---

From: "Philip Nye" <[email-masked]>
Date: Thu, 20 Feb 2003 09:38:52 -0000

> move from one network to another - whether or not LL is involved.

This group is chartered to provide a LL configuration scheme which provides
functionality in ad-hoc networks. If the requirements of an irrelevant
administered network to which a host is no longer connected can obstruct
this, it is clearly something which the spec should fix if it can.

Philip

---

From: "Philip Nye" <[email-masked]>
Date: Thu, 20 Feb 2003 09:51:58 -0000

> From: "Ted Lemon" <[email-masked]>
>

There is also the problem of a handful of people who bring their laptops
from their various company networks and try and set up an ad hoc network in
a conference room. Each might have a different "valid" configuration and
each _could_ talk using LL rules if only they knew those other addresses
were on the same link. But since none of them are 169.254 addresses they
can't.

The presumption in allowing configured addresses to talk directly with LL
addresses has always been that those configured addresses are sensible and
that they can talk with each other without any help from LL. But this breaks
down when previously condigured devices are thrown together in a new ad-hoc
network. This doesn't necessarily mean that a device has been physically
moved or power cycled.

I can see that some of these issues are out of scope for LL but it seems to
be a hole in the spec that it somehow assumes that you are always starting
the configuration process from a clean slate - when in fact this is
frequently not the case.

Would adding something like this be pertinent?

"If a host loses its configured address (e.g. by lease expiry) or has reason
to believe that its configured address is no longer working (e.g. from media
sense), it MAY test the network configuration (e.g. using ARP) to see if its
default route or any other applicable route is still reachable. If it is
unable to reach any configured routers the host MAY recommence the LL
configuration scheme from the start."

Philip

---

From: Robert Elz <[email-masked]>
Date: Thu, 20 Feb 2003 20:06:46 +0700

Date:        Wed, 19 Feb 2003 16:55:03 -0700
    From:        Ted Lemon <[email-masked]>
    Message-ID:  <[email-masked]>

  | There _is_ the problem of doing IPv4ll with your routable IPv4 address 
  | when you move to another network on which there is a DHCP server that 
  | just won't talk to you.   There's also the problem of doing IPv4ll once 
  | your lease on your routable address expires, in the case that you are 
  | connected to a network where only IPv4ll is supported.
  | 
  | Adoption of LL1 breaks the first case.   Adoption of LL23 breaks the 
  | second case.

LL23 is not intended to break the second case.   If it needs more words
to make that clear, suggest what they should be.   If a node which has
had a routable address ceases to have one, then it can start the whole
allocation process again (just as it did before LL addresses were invented).
If that fails, there's no reason it cannot acquire an LL address for
itself (or resume using one it had previously acquired).   [Aside: note that
LL23 does not say that a host should stop defending its LL address, so
once having acquire it, it will retain it in most cases.   It also doesn't
say, but in this case probably should, that if some other node usurps a LL
address that is "dormant" the node should just forget it ever existed, and
not go allocate another - or not until working routable addresses fail].

Philip Nye <[email-masked]> said:
  | Would adding something like this be pertinent?
  |
  | "If a host loses its configured address (e.g. by lease expiry) or has reason
  | to believe that its configured address is no longer working (e.g. from media
  | sense), it MAY test the network configuration (e.g. using ARP) to see if its
  | default route or any other applicable route is still reachable. If it is
  | unable to reach any configured routers the host MAY recommence the LL
  | configuration scheme from the start." 

No problem with that, but I'm not sure it is needed.   That is, I wold have
thought that to be obvious - nothing from outside can ever tell what is
going on inside a host, it can decide that it wants to attempt to re-validate
its lease whenever it feels inclined (for all the outside world knows, it
may have just crashed and rebooted).   Doing so because it has tested its
net configuration and not liked the results seems like an intelligent idea.
If the host believes that it may have moved networks (because the link has
gone done and reappeared) ought probably just go re-validate its lease
without bothering with the extra ARP (not that that is costly, as in most
cases it can be a unicast request, or can at least start that way).

kre

---

From: Keith Moore <[email-masked]>
Date: Thu, 20 Feb 2003 10:05:03 -0500

> a conference room.

that's why laptops need a button to say "connect to ad hoc network".

---

From: Ted Lemon <[email-masked]>
Date: Thu, 20 Feb 2003 08:40:17 -0700

> configuration scheme from the start."

The problem I have with language like this is that it requires the 
IPv4ll agent to have its hands too deeply in the guts of the routing 
table code.

What MacOS X does is to immediately reconfirm with the DHCP server and 
drop its configured address if the carrier sense drops.   I'm not sure 
what it does when the wireless network changes.   This is a rather 
draconian response to carrier sense changes.   It means that if you 
want to move from one connected location to another where both are 
connected to the same physical network, you can reasonably expect all 
your connections to be lost while you are walking from one location to 
the other.   It has a similar result if, for example, you are plugged 
directly into your gateway and you need to reboot the gateway for some 
reason (I had this happen to me a couple of days ago).

I would rather choose a less extreme solution than that - e.g., keep 
your IPv4ll address when you have a routable address and use the IPv4ll 
address when communicating with other IPv4ll hosts, and use your 
routable address at all other times, if you have one.   Unfortunately, 
LL19 has already been dropped, so we don't have that as an option 
anymore.

---

From: "Philip Nye" <[email-masked]>
Date: Thu, 20 Feb 2003 16:09:03 -0000

> reason (I had this happen to me a couple of days ago).

The fact that the principle proponents of LL: Apple and Microsoft both use
very simplistic algorithms (at opposite extremes it seems) which cause
trouble in one situation or another indicates that some guidance would be
useful. How much general guidance can go into a standard is questionable -
this standard seems to have quite a bit.

I suggested trying to ARP your router because this seems a much lower level
indication that you are still on the same network than a DHCP request does.
If the DHCP server is down or busy, you can still usefully use your
configuration provided it has not expired. However, if your default router
is not reachable, then you either need to find a new one or you might as
well use LL (or nothing) since you can't get off the link anyway. Since you
probably start reconfiguration by looking for a DHCP server anyway, this
seems to make sense.

Philip

---

From: Keith Moore <[email-masked]>
Date: Thu, 20 Feb 2003 11:36:59 -0500

> indication that you are still on the same network than a DHCP request does.

except in one case - where you are on a private network using RFC 1918 addresses.
it's very common for the NAT/router to have the .1 address on such networks,
and even if not, it's common for the .1 address to be assigned to some host.
hence, an ARP reply from that address doesn't mean you are on the same network.

---

From: Mika Liljeberg <[email-masked]>
Date: 20 Feb 2003 20:31:37 +0200

> IPv4ll agent to have its hands too deeply in the guts of the routing 

Exactly. Not to mention that language like that is far too vague to
implement anything sensible.

> LL19 has already been dropped, so we don't have that as an option 

We do have this option.

I tried to get matching scopes for source and destination addresses
mandated via LL19, but the current text in the draft is acceptable too:
the requirement is SHOULD rather than MUST. This allows communication
between LL-only and routable-only, which seems to be the big thing now,
while maintaining reasonable clarity of implementation. ==> reject both
LL1 and LL23.

	MikaL

---

From: Mika Liljeberg <[email-masked]>
Date: 20 Feb 2003 21:27:09 +0200

On Thu, 2003-02-20 at 15:06, Robert Elz wrote:

>    [Aside: note that

So, LL23 allows the node to keep and defend its LL address (dormant)
after acquiring a routable one. This being the case, it seems rather
pointless to put in additional complicated rules about when to configure
and when to unconfigure a LL address.

	MikaL

---

From: Keith Moore <[email-masked]>
Date: Thu, 20 Feb 2003 14:30:54 -0500

> pointless to put in additional complicated rules about when to
> configure and when to unconfigure a LL address.

I would rather nodes not continue to defend addresses on connected
networks, if only because this consumes potentially scarce network
resources.  (think of an ethernet bridged over ISDN BRI, for instance)
Using DHCP to give the node an address is an acceptable workaround for
this problem only if the node then stops maintaining its LL address.

---

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

> this problem only if the node then stops maintaining its LL address.

I see the point, but I doubt a few extra ARPs are going to make that
much difference. If the alternative is that each node has to constantly
probe its gateway routes to check whether it still has connectivity, the
DADs actually seem like the lesser evil.

	MikaL

---

From: Keith Moore <[email-masked]>
Date: Thu, 20 Feb 2003 15:05:44 -0500

> > resources.  (think of an ethernet bridged over ISDN BRI, for
> > instance) Using DHCP to give the node an address is an acceptable
> > workaround for this problem only if the node then stops maintaining
> > its LL address.
> 
> much difference. If the alternative is that each node has to
> constantly probe its gateway routes to check whether it still has
> connectivity, the DADs actually seem like the lesser evil.

those are separate concerns.  defending an LL address doesn't relieve
a host of whatever necessity (if it has any, which I doubt) to
probe nearby routers.

and I don't think probing nearby routers is a good way to determine
whether to start using an LL address.  address validity and external
connectivity are separate things.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 20 Feb 2003 13:12:54 -0700

> resources.  (think of an ethernet bridged over ISDN BRI, for instance)

You know, there are a lot of things that I think the IETF should be 
working on.   Making sure that this particular configuration works well 
simply isn't one of them.   The solution that I think the IETF, if it 
were a sentient being capable of recommending solutions, would make for 
this configuration is that the bridge should be replaced with a router, 
and the network should be subnetted.   There are a lot of parts of the 
IP protocol suite that don't react well to mixed-media broadcast 
domains where one medium is wildly different than the other.   This can 
be *made* to work, but we shouldn't be surprised when it doesn't work 
well, any more than we should be surprised that NAT, for example, 
doesn't work well in some situations.

---

From: Keith Moore <[email-masked]>
Date: Thu, 20 Feb 2003 15:22:46 -0500

> > instance)
> working on.   Making sure that this particular configuration works
> well simply isn't one of them. 

perhaps not.  then again, LL-only devices are probably even more
deserving of being excluded.

I do think it's reasonable for IETF to be somewhat concerned about the
impact of its standards on existing networks, even if those networks
aren't laid out exactly as we think best.  e.g. we try to make software
NAT-tolerant where feasible even though NAT violates IP.

Keith

---

From: Erik Guttman <[email-masked]>
Date: Thu, 20 Feb 2003 22:15:36 +0100 (CET)

> is harder than detecting its presence - what makes you start? how long do

We need to think about this, but not necessarily in the context of LL1
or LL23.  Both say if you have a configured address you should stop
using the autoconfigured address (with SHOULD and MAY under certain
conditions, for certain functions).  Neither say what you should do whne
you do not have an address or how to determine that.  I think we should
have a new issue for this.

Erik

---

From: Mika Liljeberg <[email-masked]>
Date: 20 Feb 2003 23:31:34 +0200

> have a new issue for this.

I disagree. These problems go to show that LL23 is probably not a good
idea.

	MikaL

---

From: Ted Lemon <[email-masked]>
Date: Thu, 20 Feb 2003 15:42:08 -0700

> I disagree. These problems go to show that LL23 is probably not a good

I agree with Mika on this one.   I think we should just drop LL1 and 
LL23.

---

From: Mika Liljeberg <[email-masked]>
Date: 21 Feb 2003 08:59:26 +0200

On Fri, 2003-02-21 at 00:49, Keith Moore wrote:
> > > I disagree. These problems go to show that LL23 is probably not a
> > > good idea.
> > 
> nobody has proposed a better solution to the problems that LL causes
> for applications.

There's just two points I'd like to make to that:

1) The attitude here is that "the problem" should be taken for granted.
Despite repeated requests, no compelling cases of common situations
where users would be seriously inconvenienced have been presented. This
fact merely strengthens my belief that "the problem" is in fact a fairly
minor one.

2) "The problem" is such a convenient one that we could debate it
endlessly and still not come up with a satisfactory solution. As such,
it simply delays the work of the WG and serves no useful purpose.

> to reject LL23 is to make LL unsuitable for standardization.

Hardly that. LL23 describes what is fundamentally an implementation
approach. Rejecting issue LL23 does not prevent OS vendors from applying
it in their implementation if they want to. There is no need to foist it
on OS vendors who don't. OS vendors are perfectly capable of taking in
user feedback and deciding for themselves.

LL23 has also been shown to introduce a number of new difficulties,
which would need to be solved to make the specification suitable for
standardisation. The implementation complexity implied by LL23 just
makes me wince. Well, this patient is not feeling particularly ill and
doesn't much like the medicine.

LL1 OTH is a fairly indifferent proposition. Taking what is currently in
the draft, LL1 only makes a difference with connections where the peer
is LL-only. For LL-only nodes "the problem" is insoluble anyway. Since
the ineffectiveness is coupled with some implementation issues, I feel
no compunction in putting LL1 aside as well.

	MikaL

---

From: "Philip Nye" <[email-masked]>
Date: Fri, 21 Feb 2003 10:21:25 -0000

> I agree with Mika on this one.   I think we should just drop LL1 and

We are in severe danger of starting round the same futile loop once again.

It is only a month ago or so that this list seemed to have finally accepted
the principle that running both LL and routable addresses together in a host
on a routed network is A BAD IDEA, largely because of apparently
unresolvable issues for applications.

We also recognised that it is not possible to stop this case altogether
because of transitions but that the best compromise is for hosts to cease
using LL addresses if they have a routable one and to stick to the principle
of just one address per interface (multihoming for other reasons excepted).
This has given rise to LL1 and LL23 which are both variations on precisely
how to do this.

LL1 is more brutal. LL23 attempts to spell things out more and to soften the
disruption when an operating LL host gains a configured address.

Personally I see little to choose between them and if someone wants to
suggest a better way to make this happen then fine. But if we are to go back
round the loop on the idea of running LL and routable addresses concurrently
then someone had better bring something new to the table!

Philip

---

From: Keith Moore <[email-masked]>
Date: Fri, 21 Feb 2003 06:02:27 -0500

> fact merely strengthens my belief that "the problem" is in fact a fairly

I disagree with your assessment of what is "compelling" or "common".
Users are seriously inconvenienced if the Internet is made less capable
of supporting applications that don't exist yet,  and there are compelling
applications like conferencing and internet telephony that are made less
deployable by use of scoped addresses.  To claim otherwise is disingeneous.

> it simply delays the work of the WG and serves no useful purpose.

The work of this WG is not to cripple the Internet.

> on OS vendors who don't.

I refer you to RFC 2026's requirements for proposed standard, the part about
"no known technical omissions".

---

From: Erik Guttman <[email-masked]>
Date: Fri, 21 Feb 2003 13:47:32 +0100

Philip,

[WG hat off]
I agree with your assessment. The problems caused by apps being
run by hosts who are in different scopes is real. Since LL19 was 
rejected, we must consider how to contain them.

I completely agree with Stuart:  there has been nothing specific
said about what the risks are.  We will have to take this up soon
in other issues (specific applications which are at risk or not at risk).

To support your statement, we need to bring up concrete examples
of apps which would break in mixed-scope environments - so we can
get away from admonishments and dismissals of abstract risks.

     A    B               C   D
     +----+-R-[network]-R-+---+

A is a host running a HTTP service - with a link local scope address
B is a http proxy - on the same link as A with a global scope address
C is a http client on a different link with a global scope address
D is a host with a link-local scope address (same as A's)

C contacts B requesting an HTML document. B contacts A and
retrieves the document, sending it to C.

There are many modes in which C cannot now get the rest of
the document.  B goes away, for example, or C follows a link
in the document it received to obtain data directly from A.
C could also attempt to reach A and get a completely different
host D on the link where C is located, which also cannot return
the document requested.

This is not a HTTP specific issue.  It is possible to create
examples of many other services in which referrals, pointers,
links, redirects and locators will fail.  These examples are
harder for me to construct (SMTP, LDAP, SIP, FTP, IPP... are
likely brittle in this regard).  Please either give concrete
examples or continue discussing the example above.

Erik

-----------------------------------------------------------

---

From: Robert Elz <[email-masked]>
Date: Fri, 21 Feb 2003 19:53:08 +0700

Date:        Thu, 20 Feb 2003 08:40:17 -0700
    From:        Ted Lemon <[email-masked]>
    Message-ID:  <[email-masked]>

  | The problem I have with language like this is that it requires the 
  | IPv4ll agent to have its hands too deeply in the guts of the routing 
  | table code.

I don't think so.    But all of this is in the IP layer anyway, if
needed, routing table code, and/or ARP access, needs to be available
(v4LL can't function if the LL code can't interface to ARP).  Discovering
what is the IP address of the default router isn't what most people would
regard as "deep in the guts of the routing code", and (aside from the
ability to ARP) that's all that was requested here.

It also isn't really the LL module that needs to do this, but the address
management module.

That is, something needs to be done when a node moves from one LAN
to another in any case - just continuing to use your old address
(whether DHCP assigned, or LL) without verifying it isn't going to
work.   There needs to be code to take care of these issues.   When
appropriate that code will invoke the LL module to assign an LL
address.

  | What MacOS X does is to [...]

That sounds broken to me.    Demonstrating that it is possible to
do something badly doesn't mean that the idea is poor, just the
particular implementation.

Nothing requires a node to cease using an address, or break any
connections, just because a DHCP server doesn't respond.

kre

---

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

> unresolvable issues for applications.

The list doesn't accept anything.   Individual members of the list 
accept arguments.   For me, what happened a month ago is that I decided 
to stop arguing about it because I couldn't think of any reason other 
than personal prejudice why this position was incorrect.    I didn't 
feel that it was right for me to try to sway the group toward my own 
personal preferences when I couldn't justify them.

Further debate with kre and various others has helped to clarify my 
thinking on this point.  I now understand precisely why it is a bad 
idea for an IPv4ll host to relinquish its IPv4ll address when it gets a 
routable address.   So I no longer feel that I have to censor myself, 
since I have a logical basis for asserting that this is so.   So in my 
mind, rejecting LL1 and LL23 represents forward progress.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 21 Feb 2003 09:51:43 -0700

> "no known technical omissions".

This does not compel us to accept LL23.   You could argue on the basis 
of the text you're quoting that if we do not accept LL1 or LL23, we 
need to have a note explaining the issues you've raised, and how 
vendors and applications should deal with them.

---

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

On Fri, 2003-02-21 at 13:02, Keith Moore wrote:
> of supporting applications that don't exist yet,

That is a fine abstract argument against scoped addressing in general
but it is of no help whatsoever when trying to decide whether proposals
like LL1 and LL23 are technically sound. I call again for you and others
to present some concrete cases, so that we can assess them on factual
basis.

	MikaL

---

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

> connections, just because a DHCP server doesn't respond.

I don't know what the implementors at Apple had in mind, but it looks 
like Apple is forced to do this because they have chosen not to keep 
their IPv4ll address around all the time.   A network carrier 
transition, up to down and then down to up, implies that the client has 
been connected to a new network.   In the case that the device has 
simply been moved to a new physical location and plugged into the same 
network, assuming that the client is on a new network is a mistake.   
However, this is the less likely case - usually when you move a device 
around, it's connected to a different network.   If Apple assumes the 
device is connected to the same network, IPv4ll won't work until the 
DHCP lease expires.   If they assume that the device is connected to a 
different network, IPv4ll will work immediately.   So they make the 
assumption that is most likely to be correct, and get good performance 
in that case, at the expense of somewhat pathological performance in 
the case where their guess is wrong.

If we accept LL1 and LL23, everybody who implements IPv4ll has to make 
this choice.   If we reject them, then no such choice has to be made - 
the IPv4ll and DHCP state machines can be completely separate, and so 
IPv4ll can work immediately after a link state transition, whilst DHCP 
follows the usual rules and also continues to work after the link state 
transition.

---

From: Mika Liljeberg <[email-masked]>
Date: 21 Feb 2003 19:35:04 +0200

> get away from admonishments and dismissals of abstract risks.

I support this wholeheartedly. Let's discuss concrete issues instead of
ideology.

> host D on the link where C is located, which also cannot return

This example has two v4LL-only nodes and therefore has problems. This
clearly argues against LL23. If nodes A and D had LL and routable
addresses both, would the problem still exist?

	MikaL

---

From: Ted Lemon <[email-masked]>
Date: Fri, 21 Feb 2003 11:18:01 -0700

> addresses both, would the problem still exist?

Another way to put this is that the example shows a case where 
communications between an off-link node and a node that has only an 
IPv4ll address fails.   But why is B proxying A in the first place?   
Is it accidental?   I don't see how this would happen.

If the idea is that A has both an IPv4ll address and an IPv4 global 
address, and that A put its IPv4ll address instead of its domain name 
or global IP address into a web page, I can see where this would be a 
problem, but it's a violation of accepted practice in setting up web 
pages anyway - generally it's poor form to hard-code IP addresses or 
even domain names into an HTML referral.   This causes no end of 
problems even in situations where the HTTP server has an unscoped IP 
address.

Furthermore, it's unlikely that anybody would hand-code an IPv4ll 
address into a web page.   So the only way for this to happen is for a 
CGI script that generates the web page to generate a bogus HREF.   I 
don't think this is a likely scenario.   In this case, in order to 
accept that this describes a real problem, I'd want to see an actual 
example of a real-world application making this mistake, and then we 
could analyze why it made the mistake, how likely such a mistake is, 
and how the mistake could be prevented.

---

From: "Philip Nye" <[email-masked]>
Date: Fri, 21 Feb 2003 19:21:46 -0000

> ...   But why is B proxying A in the first place?

In general because the proxy app in B and the HTTP server in A don't know
anything about scoped addresses.

> generally it's poor form to hard-code IP addresses or
> even domain names into an HTML referral.

This sort of thing happens when a dynamic web page is created in response to
conditions discovered locally.

For example - I have a NAT router which displays ARP tables on a web page.
It doesn't actually make links to them, but some other configuration page
might well do so.

Philip

---

From: Ted Lemon <[email-masked]>
Date: Fri, 21 Feb 2003 12:42:28 -0700

> anything about scoped addresses.

I don't mean in general.   I mean specifically.   How does B know that 
A is an http server?   Was B configured to proxy A?   Did it discover 
it automatically?   How?

> It doesn't actually make links to them, but some other configuration 

That's true, but a web page on a web server can refer to another web 
page on the same server without specifying an IP address, and this is 
generally the best way to do it.   You say <A HREF="/foo.html"> to 
refer to /foo.html, rather than saying '<A 
HREF="http://myserver.example.com/foo.html">'.   You would never say 
'<A HREF="http://192.168.0.1/foo.html">'.

So I'm looking for a specific example where an HTTP server would 
generate a reference to a page by providing an IPv4ll address.   The 
reason it's important to have specific examples is that we've been told 
that this is a significant problem, and that we should act on it as if 
it is a significant problem.   So if nobody can come up with a specific 
example of where the problem would happen, then the assertion that the 
problem is significant is clearly called into question.   Such an 
assertion can't logically be used as a reason for justifying reducing 
the functionality of the protocol.

---

From: "Philip Nye" <[email-masked]>
Date: Fri, 21 Feb 2003 20:15:51 -0000

> A is an http server?   Was B configured to proxy A?   Did it discover

Some examples:
1. A is advertising a service via SLP
2. A is a printer and is discovered via a printer discovery protocol (e.g.
CUPS)
3. A is found via a netbios

There are lots of ways to discover hosts other than by DNS and many of them
only give you an IP address.

> '<A HREF="http://192.168.0.1/foo.html">'.

My point was that the router lists _other_ hosts on the local net by their
IP address on an HTML page. It doesn't have any other information in that
context except their MAC address.

Philip

---

From: "Philip Nye" <[email-masked]>
Date: Fri, 21 Feb 2003 20:51:05 -0000

Another example:

A   B(LL)   C                D
+----+------+---+routing+---+

A, C and D have routable addresses
B is LL only.

A, B, C and D are running a collaborative service.

1. A and B communicate
2. B passes A's address on to C
3. C and A communicate
4. C passes A's address on to D
5. D communicates with A

Under LL1/LL23 this all works even though B doesn't have global connectivity
(no one would expect D to communicate successfully with B anyway).

Under LL19 this would not work. Although A has a routable address it is A's
LL address which gets propagated through the system because that is the
address it used to communicate with B.
It is already starting to break down at 3. because C only knows A by the LL
address even though by LL19 rules it should be using a routable one.

Philip

---

From: Mika Liljeberg <[email-masked]>
Date: 21 Feb 2003 22:57:17 +0200

Discussing this particular example leads nowhere.

The connectivity problem is caused by the fact that some of the nodes
are LL-only. Neither LL1 nor LL23 can do anything to change that.

Because of the above, I won't even *try* to figure out why anyone would
consider this a compelling use case.

First we need to see a plausible scenario with some of the following
types of nodes:
- a node having both LL and routable addresses
- a LL compliant node having only a routable address
- a non-LL compliant node having a routable address

LL-only nodes should not be included. It is clear that referral apps
will not work with them and there is nothing we can do about it.
Therefore, they are out of scope for this exercise.

Then we need to consider whether the scenario presents an actual use
case. In order to qualify it should satisfy the following:
- It is something that a number of people will clearly want to do
- There is no other reasonable way to accomplish the same thing without
running into referral problems

Given the above we would have a plausible use case. Then we would need
to consider, whether either LL1 or LL23 or actually solves the referral
problem. Finally, we would need to evaluate whether the use case is
compelling enough to warrant the medicine.

LL1 and LL23 supporters are hereby called to build the use case.
LL1 and LL23 opponents are hereby called to try and shoot it down.

Let's try be specific with the arguments.

	MikaL

---

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

> 4. C passes A's address on to D

Ok. You've shown that it is possible to construe a theoretical scenario
where there is a referral issue (although caused by a v4LL node). Now
answer the following:

Does this map into a specific real world application?
Why does B only have a LL address?
Why does B, having only a LL address, participate in a referral
application?
Is the use case common and compelling enough that complicating the
specification with LL1 or LL23 is clearly justified, when we know there
are unsolved issues with (at least) the LL23 solution (we haven't really
considered LL1 in as much depth)?

	MikaL

---

From: Ted Lemon <[email-masked]>
Date: Fri, 21 Feb 2003 14:11:29 -0700

> running into referral problems

I think it's worth also considering cases where existing applications 
would break and it would not be easy to modify those applications so 
that they do not break.   I don't think these are as compelling as 
cases where there is simply no other reasonable way to accomplish the 
same thing, but they're still interesting.

---

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

> same thing, but they're still interesting.

You're right, we should consider those as well. Existing applications
make good use cases, and they become more compelling if there is no
straightforward administrative recourse around the problem.

	MikaL

---

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

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

Keith has mentioned Netsolve and Gnutella (I think). I am not familiar with
either.
I have developed embedded applications which pass IP addresses around - they
don't live in a world with DNS.

However, these hosts don't all have to be running the same application.

For example:

A is a printer advertising itself via SLP
B is running an SLP Directory Agent.
C is running a web page with links to printers which it discovers through
SLP

> Why does B only have a LL address?

Because the DHCP server didn't hand it an address.
Or because it is an LL only device.
Or because it has a manually configured address which worked doesn't work on
this network.
Or because it was in a transitional state at the time.

> Why does B, having only a LL address, participate in a referral

Because the poor schmuck who is trying to use it is not a geek.
And because the app doesn't know about scoped addresses - nor should it.

> considered LL1 in as much depth)?

The point is that addresses are acquired in lots of ways, not just through
DNS or neat two way apps and since virtually nothing in IPv4 except routers
considers the scope of an address before using it.

You are right that this has to be balanced against other issues but I am not
clear what simply maintaining a LL address alongside your routable one
solves.

If the stack and API successfully suppress the LL address in the presence of
a routable one AND all hosts have routable addresses then it really doesn't
matter whether those hosts are technically retaining their LL addresses or
not - they just don't get used. However, the purpose of retaining them must
be to use them and deciding where and when is a whole can of worms.

Ted seems to be suggesting that if your routable configuration is not
working, at least you still have LL. But if you can determine that your
routable configuration is not working, then you can also choose to try
reconfiguring and maybe end up with just LL. OTOH if you use your LL address
even though your routable configuration is valid you run straight into the
mixed scopes problems again.

Philip

---

From: Markku Savela <[email-masked]>
Date: Sat, 22 Feb 2003 00:43:30 +0200

> From: "Philip Nye" <[email-masked]>
> 
> If the stack and API successfully suppress the LL address ...

I thought the issue of this practise was to show us a real application
where the stack retaining and fully using both LL and global address
at same time would break something.

So far this example only shows that bringing in LL-only node has
problems. But this is nothing new.

The only example I can find, that comes close is:

   A ----- B ---- router ---- C  -- D

On local net:

   A is host running IRC client
   B is host running IRC server

On global internet

   C is host running IRC server
   D is host running IRC client

B needs to have a global address to talk to C. But, if it also has LL
address and accepts client connections to this LL address, then A can
connect with LL address.

The resulting problem is:

   if A initiates client-to-client DCC connection with D, it will
   probably take it's own address from the A-B connection and passes
   this within IRC message over to D. D will try to use this address
   to connect A.

If A had only global address it would only connect with global
address. The insteresting case is when A has both LL and global
addresses, and the question: why did A pick LL instead of global?

In my system this would depend in DNS resolver, and if B:s name
resolves to global address, then it would have used global address
anyway. If there is no global DNS, then it would try LLMNR and perhaps
get LL address, things would work at least for normal IRC (only DCC
requests out of site would fail -- as they fail with net-10 and kind
addresses).

Thus the text should not have any strong "SHOULD or MUST" that prevent
simulataneous use of LL and gloabl address. There can be MAY for those
operating systems that have problems handling multiple levels of DNS
servers and scoped addressing.

---

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

> Keith has mentioned Netsolve and Gnutella (I think). I am not familiar with

I figured peer-to-peer applications and distributed directories would be
a likely case. I'm not familiar with netsolve, but gnutella is a p2p
file sharing application.

Gnutella would be a compelling application, since a lot of people are
inrested in file sharing. However, I would bet that a p2p node would
advertise their own address via the p2p protocol, rather than relying on
a neighbour to advertise it. Thus, a p2p client having both LL and a
routable address would be advertising its routable address. A LL-only
node would be out of luck (I'm sure no-one expects otherwise).

The other thing with p2p applications is that they are under intense
research and development, which means that new constraints like
understading LL addresses can be easily handled as part of the
development process. For this reason any new and non-traditional
applications make somewhat less convincing use cases, since their
implementors should be aware of LL addresses.

> don't live in a world with DNS.

Would you be willing to give a concrete example using one of those
applications?

> B is running an SLP Directory Agent.

This doesn't make sense. A directory agent would most certainly have a
routable address as well.

> Or because it was in a transitional state at the time.

Forgive me for sticking to the specific, but you gave an SLP directory
agent as example. None of these alternatives make sense in that context.

> Because the poor schmuck who is trying to use it is not a geek.

The poor schmuck running the SLP directory agent? :-)

> And because the app doesn't know about scoped addresses - nor should it.

That's fine. The OS should know. I'm trying establish if this is truly a
problem.

> considers the scope of an address before using it.

We're meandering into the realm of the abstract again. These arguments
sound consistent on their own, but they have to be connected to the real
world. Let's try to do that with concrete examples. It should be easy
enough to come up with one, if this is really major problem.

> clear what simply maintaining a LL address alongside your routable one

Well, my claim all along has been that LL23 introduces a lot of
additional implementation complexity. There are thorny issues related to
switching between configured/unconfigured states and monitoring the
reachability situation. Also, LL23 does not address multihomed hosts at
all. An LL address could be configured on interface A, while a routable
one could be configured on interface B. How does LL23 relate to this?

I'm fairly convinced that having both LL and routable addresses does not
cause any real problems as opposed to only having a single address per
interface. If I'm wrong, supporters of LL1 or LL23 should easily be able
to prove it by presenting a quick concrete example.

> not - they just don't get used.

This is what I argued with LL19. In the majority of cases, these APIs
are used to find a destination address for a connection. If source
address selection works in such a way that the scope of the selected
source address matches the destination address, there should be no major
problem with bi-directional communication. People who believe there
would be a problem with referral apps should prove it with a few
concrete examples.

>  However, the purpose of retaining them must

The purpose of retaining them would be to have them indepenently of the
routable address. If the routable address happens to go away, the LL
address is there and immediately usable. No complex implementation
interdependencies, unless *really* needed.

> reconfiguring and maybe end up with just LL.

You could but why would you want to go to all that trouble if you can
just keep the LL address all the time? The principle is "keep it
simple". "Make it more complex" must always have compelling reasons.
Besides, you even win the 10 seconds it takes to configure a LL address.
That's a (admittedly small) advantage in usability.

>  OTOH if you use your LL address

Back to abstract arguments? If you have both addresses, you use the
routable one to communicate with destinations of equal scope.

	MikaL

---

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

> C is running a web page with links to printers which it discovers 

Why is B, a host with only an IPv4ll address, apparently not a 
legitimate user of the network, since other devices on the network have 
routable addresses, acting as an SLP DA?   Why do we care if this 
configuration doesn't work?

> Because the DHCP server didn't hand it an address.
I.e., it's not a legitimate user of the network, but it's acting as a 
server on the network.   We can't generally protect against this 
problem other than by using authentication in our server-discovery 
protocols.   This is true whether IPv4ll is present or not.

> Or because it is an LL only device.
Why would an LL-only device act as an SLP DA?   Why does the 
manufacturer have room in the ROM for an SLP DA implementation, but not 
a DHCP implementation?

> Or because it has a manually configured address which worked doesn't 
Why does a server on this network have a bogus manually-configured 
address?   Why is it our problem that it does?   Would removing IPv4ll 
from this device have the result that it would then begin to function 
properly?   If not, why is this an interesting example when we are 
talking about the IPv4ll draft?

> Or because it was in a transitional state at the time.
LL1 and LL23 do not eliminate the problem of transitional states.   Why 
is this example a reason to support LL1 and/or LL23?

> clear what simply maintaining a LL address alongside your routable one
It means that IPv4ll is always available, even when external events 
have created a situation where IP routing isn't functional and nodes 
can't interoperate using their invalid, yet configured, global 
addresses.

> But if you can determine that your
Who is "you"?   How does "you" determine that "you" don't have a 
working routable configuration?   For example, is "you" the DHCP client 
or the IPv4ll agent or some other entity?   Or do we require that the 
IPv4ll agent and the DHCP client be the same thing?   Unless you can 
write this down in the draft in a way that a reasonable person can 
understand (and LL1 and LL23 do not do this), you can't use this as an 
argument either.

> mixed scopes problems again.
Right.   This mixed scope problem for which we have yet to see a 
specific example.   :'/

This shouldn't be that hard.   It should be possible to come up with a 
real world configuration, with specific software and specific 
protocols, where it doesn't work because a node has an IPv4ll address 
and also a global address, where the problem isn't simply a 
configuration error.   There shouldn't be a need to resort to 
hypothetical examples.

---

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

> like LL1 and LL23 are technically sound.

no, you have it backwards.  you can't decide whether something is technically
sound based on concrete examples.  concerete examples might demonstrate that
it is unsound, but they cannot demonstrate soundness.

what you seem to want to do is feel free to dismiss any example that you
personally find insignificant.  I disagree that you or anyone in this WG has
the right to determine that certain applications are insignificant enough to be
broken by linklocal.

Keith

---

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

> it is unsound, but they cannot demonstrate soundness.

Nothing other than deployment can demonstrate soundness.   That is why 
we are challenging you to come up with some concrete example that 
demonstrates unsoundness.   If you can do that, then we can stop 
arguing.   Otherwise, the only way we can proceed is to, well, proceed, 
and see what happens.

---

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

> it is unsound, but they cannot demonstrate soundness.

It has already been demonstrated that, in addition to increasing
implementation complexity, LL1/LL23 also create new potential problems
e.g. with swithing between configured and unconfigured states.

What has not been demonstrated at all, beyond insistent assertions, is
that either LL1 or LL23 is needed in the first place.

> the right to determine that certain applications are insignificant enough to be

That is uncalled for. We're all professionals here, I hope.

	MikaL

---

From: "Philip Nye" <[email-masked]>
Date: Sat, 22 Feb 2003 13:37:45 -0000

> e.g. with swithing between configured and unconfigured states.

How? Give me a concretre example where keeping a LL address solves the
switching issue which can't be solved under LL1/LL23?

You can't have it both ways. If you can stop hosts with both addresses
"advertising" the LL one, then that basically means it can't be used. As
soon as it is used it gets picked up by aopplications and into the system.

Philip

---

From: Mika Liljeberg <[email-masked]>
Date: 22 Feb 2003 15:47:35 +0200

> switching issue which can't be solved under LL1/LL23?

There is no switching between configured and unconfigured states if LL23
is rejected.

If you mean the source address selection algorithm, I believe that a
source address with a scope matching the destination address is always
the most appropriate one, as it ensures bi-directional communication
between the hosts.

> "advertising" the LL one, then that basically means it can't be used.

No it doesn't. It can still be used as source address with LL-only
destinations (which *cannot* directly pass the peer address off-link).

That's all I want. No unconfiguring/reconfiguring addresses on the fly.
No funny exceptions to source address selection rules.

	MikaL

---

From: Ted Lemon <[email-masked]>
Date: Sat, 22 Feb 2003 11:21:43 -0700

> switching issue which can't be solved under LL1/LL23?

You are on a network with a DHCP server, and you get a lease.   Your 
friend is on a different network with a DHCP server, and gets a lease.  
  You meet for lunch.   You plug your computers into each other.   
Neither lease has yet expired.   With LL1/LL23, the two computers 
cannot interoperate.   Without LL1/LL23, they can.

> As

That's right.   It has to be advertised using LLMNS.   It doesn't have 
to be provided to applications, except applications like the LLMNS 
agent that explicitly ask for it, and applications that connect to 
link-local destinations, which can get it with getlocalname().

---

From: "Philip Nye" <[email-masked]>
Date: Sat, 22 Feb 2003 19:38:24 -0000

> cannot interoperate.   Without LL1/LL23, they can.

How does the system know that it is now safe to use a LL address because the
DHCP addresses aren't working? This question is the same whether you have
LL1/LL23 or not. If you know that LL is the only thing which will work, then
you are free to use it. If you don't know this but use it anyway then you
will break things.

> link-local destinations, which can get it with getlocalname().

So generic applications (like ftp) cannot use the LL network? Only apps
which use LLMNS and NEVER refer to a peer other than by its LLMNS name? This
seems particularly broken to me.

The only point in having a LL address is to use it. If you use it then it
will get into the application layer and some applications will pass it
around. If LL is all you have then that is fair enough but if you have a
routable address then you (and possibly the whole system) will suffer if
your LL address gets out. Which means don't use it.

There is a misconception here that the only way applications get IP
addresses is via DNS and its derivatives. This is complete tosh - there are
lots of ways that applications get hold of addresses - and whole networks
without named hosts. The very idea of having to give a host a name is by
definition not zero-config! If you send a packet to me using your LL address
than I have that address and you have already lost control of where it gets
to.

Philip

---

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

> you are free to use it. If you don't know this but use it anyway then 

It's always safe to use an IPv4ll address to communicate with another 
device with an IPv4ll address.   I think that the right way to fix this 
is in the LLMNS resolver - if you get back an IP address that's not 
locally reachable, you don't provide that address to the application.   
So if you have two devices that both do link-local, and both also have 
global addresses, then each device advertises both addresses using 
LLMNS.   If both devices are configured to use the same IP subnet, then 
LLMNS returns the global IP address.   If the devices are configured to 
use different subnets, LLMNS returns the IPv4ll address.   The 
application doesn't ever even see an inappropriate address - it's 
handled in the resolver.

Unfortunately, this solution is somewhat off-topic, since we're talking 
about IPv4ll, but this is how I would solve the problem.   I think that 
solving the problem by adding a great deal of complexity to IPv4ll 
isn't going to be satisfactory for anybody who uses IPv4ll.

> seems particularly broken to me.

All apps use both LLMNS and DNS, according to the rules of those 
protocols.   If you don't use LLMNS or some other link-local node 
discovery protocol, you can't use IPv4ll addresses anyway.   The 
transparency of IPv4ll depends specifically on LLMNS in most cases, 
like it or not.

> than I have that address and you have already lost control of where it 

Sure, you can use any sort of resource-discovery protocol, as long as 
it works.   Or you can just type in IP addresses.   What's your point?

---

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

> application doesn't ever even see an inappropriate address - it's 

That's an excellent idea. A convenient way to support this is on the OS
is to add a system call that returns a valid source address for a given
destination address (running it through route selection and source
address selection). If a valid source address can be found, the tested
address can be returned from the LLMNR resolver.

> isn't going to be satisfactory for anybody who uses IPv4ll.

Very much agreed.

	MikaL

---

From: "Philip Nye" <[email-masked]>
Date: Sat, 22 Feb 2003 21:20:56 -0000

> transparency of IPv4ll depends specifically on LLMNS in most cases,

I don't buy this at all. If the IP world was a cozy place where apps dealt
only with names and relied on a narrow DNS/LLMNS system to work out the
details then what you propose might work. However this is only a small part
of the IP world.

There are many applications in the embedded world where LL is very
attractive, but for which LLMNS (or DNS) is a complete irrelevance. Things
like SLP and a host of specialist small scale discovery protocols are much
more relevant.

Don't get me wrong - I am as concerned about the case of transition from
configured to LL as you are - as my previous posts show. I just don't see
that running LL concurrently really helps unless you sacrifice a lot of
applications. If there is a way to tell when it is safe to switch over, then
that applies in all cases and I would like to explore that.

> it works.   Or you can just type in IP addresses.   What's your point?

My point is that unless you make each and every one of these myraiad ways
that apps discover each other LL aware, and secure against mis-scoping, then
you can't be sure that LL addresses will be confined to scope. If all those
ways NEVER reveal a LL address when a configured one is present then it is
true that those addresses will not leak out of scope - but a whole lot of
applications will not be able to communicate using LL either.

Philip

---

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

> the right to determine that certain applications are insignificant enough to be

The working hypothesis is:  It is possible for hosts with link-local
configuration to communicate with those with non-link-local
configuration and for them to successfully use existing IETF
standard protocols.

Keith is right that examples cannot be used to prove this hypothesis
(or any other *general assertion.*)  However, we need concrete counter
examples which either disprove it or show its limitations.  Abstract
arguments against this hypothesis have not conclusively or convincingly
moved our discussion forward.

Unless we can conclude or get convinced that there are real concrete
problems with the above hypothesis, we will not ammend it further than
has already been done in the applicability statement and app consider-
ations sections.

Erik

---

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

> details then what you propose might work. However this is only a small part

Concrete examples, please?

> applications will not be able to communicate using LL either.

[WG chair hat off]

If a host already is able to use service discovery protocols and naming
services to obtain a peer's location, what more do we have to do?

My concern is that most apps today get the address of a peer, or even
for their own interface, and cache it.  Worse, they may forward this
information to others.  This happens for example in
   http referrals and redirects
      Here we are pointing at content or service elsewhere in
      static documents.
   SLP service advertisements from a DA, entries in an LDAP server
      Here we are pointing at services elsewhere which may not
      be available in the future at the same address.  This is
      different from them not being available *ever* since the
      advertisement is only good in one scope but is obtainable
      in another.  See RFC 3111 on SLPv2 for IPv6.
   pop3 and imap client configuration
      This is the 'heart of the matter'.  Today clients take
      hard coded parameters for their servers.  We assume that
      this server will continue to remain available, otherwise
      we have a problem.  Generally we give a name for the
      server, which gets resolved before use of the client-server
      protocol.  Service discovery could be used instead, but in
      practice seldom is.

      The problem is that the client-server binding is made
      once and for all.  If the client moves (reboots, ip mobility,
      whatever) and the *service* has only a link-local address,
      the client loses the ability to contact the server.

Question:  Is the real problem when a *service* uses a LL
address?  Services are the only application entities which offer
a L3 access point which might get moved or used outside of the
scope in which it is valid.

Could we solve this by stating in the applicability statement
that application software services which register themselves
with dynamic discovery protocols should be aware of the scope
which they perform these advertisements?   This does *not*
break existing standards or implementations, since today, very
few apps use these facilities.

As indicated above, the way I attempted to address this so far
(RFC 3111) was *within the service discovery standard* so the app
does not need to care about its address scope.  The service discovery
or address registration protocol can limit the propogation of an
advertisement to the scope it is valid in without the application
needing to be changed in any way.

This could be an additional requirement for dynamic update of DNS
and LLMNR.  Alternatively:  This could be a requirement we have
on application services which use link-local configuration.  But
isn't this a bad alternative?

Erik

---

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

Ted Lemon wrote:
> Neither lease has yet expired.   With LL1/LL23, the two computers cannot 
> interoperate.   Without LL1/LL23, they can.

Ted,

[WG chair hat off]

This email explores the possibility that one could accept LL1/LL23 and
avoid the problem you state above.

What about LL1/LL23 precludes the host(s) from determining that
though they have a valid DHCP lease, they cannot reach the gateway,
nor the DHCP server and since, for example, they have woken up.  They
assume they must be 'somewhere else.'  They then go back to link-local 
configuration.

As Philip has brought up - this transition from configured to 
unconfigured needs thinking through.  But nothing in LL1 or LL23
precludes a host from interpreting:
   LL1  A host should use an IPv4LL address as a source address
        when the only addresses available to the host are IPv4LL
        addresses.

what *available* means

and
   LL23  For this reason, a host that obtains, or is configured with, a
         routable address on an interface, SHOULD NOT attempt to
         configure a link-local address on the same interface.

         Where a link-local address has been configured on an interface,
         and a routable address is later configured on the same
         interface, the host MUST always use the routable address when
         initiating new communications, and MUST cease advertising the
         availability of the link-local address through whatever
         mechanisms that address had been made known to others.

         A host SHOULD continue to use the link-local address for
         communications underway when the routable address was
         configured, and MAY continue to accept new communications
         addressed to the link-local address.

what *is configured with* means.  Or - is there a requirement that a
DHCP client retain a lease even if it the host is powered off, loses
carrier sense, goes to sleep, determines that it has entered a new
foreign network, etc?

Isn't this left to the implementor's discretion?

[WG chair hat on]

I am fine adding a new issue like "A host may transition to use of
link-local addresses if it determines it is on a foreign network"

Thanks,

Erik

---

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

> assume they must be 'somewhere else.'  They then go back to link-local 

What LL1/LL23 do is to create an interdependency between IPv4ll and 
DHCP that is sufficiently strong that we would have to say that this 
draft now updates RFC2131.   Neither LL1 nor LL23 provides sufficient 
detail to really update RFC2131.   So if either is accepted, then we 
need to go through this draft very thoroughly and tweak it so that it 
is actually a complete update to RFC2131.   We have to examine all the 
states that a DHCP client can get into, and update RFC2131 to describe 
how the client makes transitions to and from the state of running 
IPv4ll rather than a DHCP-supplied address.

You are correct that it is possible to do this.   I think it would work 
pretty nicely.   However, it is a big job, if we do it right, and I 
don't think it's correct to just pretend that this draft, with the 
addition of LL1 and LL23, doesn't update RFC2131, so doing it right is 
a significant amount of additional work.   So the question is, is it a 
big win to go through all this extra work, or is it easier just to make 
IPv4ll and DHCP independent of each other?   What are the benefits to 
making DHCP and IPv4ll interdependent?   What are the drawbacks?

Several benefits have been raised, but none of these are very 
convincing.   For example, Christian, Philip and Kevin are all 
concerned about address leakage.    Another benefit that's been 
described is that LL1 and LL23 make the application's life easier, 
because the application isn't going to have to know how to choose 
between the IPv4ll address and the global address.   But these 
objections are not convincing, because in order for them to be valid, 
it would have to be the case that LL1 or LL23 made it so that a node 
_never_ had both an IPv4ll address and a global address, and this is 
not what either proposal actually does.

If there were no better way to solve this problem, we could all shrug 
our shoulders and get back to the business of updating RFC2131, but I 
don't believe this is necessary.   I think the problems with multiple 
addresses are (a) already being dealt with for other reasons and (b) 
not as bad as some participants in this discussion theorize.

Christian mentions the problem with queries for net 10 addresses at the 
root, and implies that allowing a node to have both an IPv4ll and a 
global address will result in similar problems.   But the fact is that 
LL1/LL23 do not solve this problem - it's still possible that my 
IPv4ll-aware device that happens to have a global address will do a PTR 
lookup when it gets a connection from my IPv4ll device that doesn't 
currently have a routable address.   In fact, I'm not sure in what case 
an actual reduction in the number of queries to the root would happen 
as a result of accepting LL1/LL23.

Christian also mentions the problem of a multiply-connected node which 
does IPv4ll on both connections, and suggests that if we can in some 
cases reduce the number of interfaces over which we communicate using 
IPv4ll, this will in some way address the problem.   This is a solution 
that we can't really depend on - there's no guarantee that one network 
will be managed and the other not.  Even if one network is managed, 
there is no guarantee that some hosts on that network will not have 
IPv4ll addresses - for example, if there is a shortage of addresses on 
the DHCP server, some devices might get addresses and some not.  And in 
fact, the problem he describes is small.

In order to do IPv4ll over multiple interfaces, the IP stack must be 
smart enough to ARP on all interfaces that support IPv4ll when it is 
asked to communicate with IPv4ll address that is not currently in the 
ARP cache.   For addresses that *are* in the ARP cache, the stack just 
sends the packet out whichever interface the ARP reply that created the 
cache entry was received.

This isn't very hard to do, and it works perfectly, *except* in the 
case where there are devices on both links that have the same IPv4ll 
address.   In this case, LL1/LL23 do not help at all, because they 
address the multihomed device, not the two devices that have 
conflicting addresses.   This is a problem with any IPv4ll multihomed 
environment, and I have yet to see any proposal for how to fix it.   
But in fact with LL19 instead of LL1/LL23, if the device has both an 
IPv4ll and a routable IP address, we will always connect to its 
routable address, so the fact that its IPv4ll address is in conflict 
will never be a problem.

It is unfortunate that LL19 was discussed and rejected separately from 
LL1/LL23, because the two are strongly interconnected.   LL19 solves a 
lot of the problems that LL1/LL23 try to solve, in a much better way.   
Taken by itself, with the assumption that LL1 and LL23 would be 
accepted, LL19 sounds like a really bad idea, but considered as an 
alternative to LL1/LL23, it makes a lot of sense.

---

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

> like SLP and a host of specialist small scale discovery protocols are 

The thing is, I've been through the scenarios for how an address would 
get into SLP, for example, and I don't see how it would be the case 
that the wrong address would find its way into SLP, except in cases 
where there is no right address to put into SLP.

To be more precise, *if* the O.S. presents both the IPv4ll and the 
global address as the same kind of address, I can see how SLP could get 
the wrong data.   But the solution to this is easy - just don't present 
both addresses the same way.

Most applications of which I am aware aren't even smart enough to 
notice address transitions.   You start them up, they (maybe) check to 
see what addresses are configured, and they assume that whatever 
addresses they saw remain configured for all time.   If for some reason 
the system's addresses change, the application simply stops working.   
The only reason this isn't a bigger problem is that most server 
applications simply listen on 0.0.0.0, not on specific IP addresses, 
unless the user requests otherwise, and then they just do what they're 
told, which is usually the right thing.

Resource discovery applications are an exception to this.   To make 
them work most smoothly, they should be IPv4ll-aware.   I would think 
that the authors of such apps would *want* to support IPv4ll.   But we 
can make it so that even if they are not IPv4ll-aware, they still work 
in the cases where they're expected to work in the absence of IPv4ll, 
and in many cases where IPv4ll is present.   So I don't think this is a 
problem, and so I don't think it can be used as a reason to justify 
accepting LL1 or LL23.

---

From: "Philip Nye" <[email-masked]>
Date: Sun, 23 Feb 2003 18:35:04 -0000

> From: "Erik Guttman" <[email-masked]>
>

Of systems which don't get IP addresses through DNS/LLMNS?

Networks where names are used but do not use DNS - Popular alternatives are
netbios (and appletalk?), NIS etc.

Networks where names are not used at all - generally other hosts are
contacted not directly by resolving names but by service discovery. Most
service discovery protocols including SLP, SSDP, Salutation (I think), SIP
and probably Jini use URLs to locate services. In a system with no names,
these URLs contain raw addresses. I quote from the SIP spec:

   ...many end systems do
   not have registered domain names, so IP addresses are permitted.

In such systems, services are frequently distinguished using UUIDs which
effectively take the place of names. However, these are not resolved to
addresses in the DNS system, but through the service discovery protocol
itself.

Where such service discovery protocols are or can be mediated by some sort
of server (as is the case in SLP, SIP, Jini and Salutation) these addresses
are passed on - often multiple times (c.f. SIP and mesh enhanced SLP).

My requirement is not for LL1/LL23 to succeed - that is only a means to an
end. My requirement is that these systems work including LL networks such
that the *only* restriction is the obvious one that hosts with only LL
connectivity cannot themselves communicate off-link.

Now as I understand it Mika and Ted believe that somehow the LL addresses of
hosts will not get into such systems. I fail to understand how they will
stop this and yet allow these systems to operate over and across LL where
appropriate.

Concrete examples?
I gave one in
http://www.merit.edu/mail.archives/zeroconf/2003-02/msg00527.html
I'd like some concrete answers in return.

Mika and Ted,
The response to my example makes me think that you have in their minds other
restrictions or rules which have not been understood or you are assuming a
different set of axioms than I am - in particular in terms of what you
expect to work and what you regard as an abberation.

What is the set of rules which makes LL work without LL addresses getting
out of scope? Simply restating LL19 (which has been rejected anyway) is not
enough. Refer to my pervious example above if possible.

Are permanently LL-only devices allowed, even on configured networks? Are a
mixed set of LL-only and routable hosts allowed to co-operate? What is
expected to happen when a DHCP server pops up on a LL network? What happens
if a DHCP server refuses to supply addresses to some but not all hosts? If
all hosts have configured addresses, when and why would they decide to use
their LL addresses? How are misconfigured routable addresses dealt with?

Philip

---

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

> enough. Refer to my pervious example above if possible.

The rules I had in mind in an unsolidified form (before LL19 got
rejected) are roughly as follows:

a) Legacy nodes MUST NOT be configured with an LL addresses (or with an
169.254/16 on-link route)

b) Only a node having a LL address can be assumed to be LL-compliant
(barring misconfiguration). This depends on a).

c) LL-complaint nodes MUST NOT use a LL address unless they can
ascertain that the peer is LL-compliant. Recognition of an LL-compliant
peer depends on b).

d) If a LL-compliant node has a routable address, the system APIs on the
node MUST make a reasonable attempt to hide LL addresses from non
LL-aware applications (i.e., the application must either explicitly
request to see LL addresses or at least routable addresses must be
returned first by any enumeration APIs)

e) An LL-compliant node MUST NOT advertize any of its addresses beyond
the reachability of that address. The service discovery APIs provided by
the OS must enforce this, because we don't expect the applications to
honor this rule.

f) All LL-compliant nodes should configure a LL address, regardless of
whether they have a routable one or not.

[You can substitute SHOULD for MUST in the above if you like, with the
understanding that it makes the address leakage more likely.]

Now, it is clear that the rules above are not bullet proof. If any
single one is violated, there is risk of leakage. However, no solution
is really is. The question is, would these rules work well enough?

Let's examine some of the properties of those rules:

1) Rule a) is the only one that legacy nodes are expected to follow.
This is reasonable, since by default they are configured that way. Only
configuration by an administrator can cause them to break rule a).
However, we cannot expect legacy nodes to follow any of the other rules.

2) Since legacy nodes cannot be expected to enforce rule e), they are a
likely source of address leakage if they get hold of a LL address. One
example of such behaviour was given in the LL19 problem statement. A DNS
PTR query on an LL adress is another one. We must prevent that.

3) Rule c) ensures that legacy nodes will not get an LL address from
getpeername(). That leaves application protocols and service discovery
protocols. [And manual configuration as well as other obscure ways.]

4) Rule d) ensures legacy nodes will not receive LL addresses from non
LL-aware applications running on an LL-compliant node, which has a
routable address. Conversely, rule d) ensures that a legacy application
running on a LL-compliant node, which also has a routable address, will
not inadvertently advertise the node's LL address.

5) Rule e) ensures that legacy nodes will not get a LL address via a
service discovery protocol. Conversely, rule e) ensures that OS services
running on a LL-aware node will not inappropriately advertise the LL
address.

I think I misread your example a bit before, thinking more about
plausibility than the referral chain. Let's try again by linking the

> > 4. C passes A's address on to D

1) we know that B is a LL-node, so it would honor all the rules above. 

2) If A and C don't have LL addresses, node B would be breaking rule c)
by communicating with them [since it can't be sure they are
LL-compliant]. However, due to rule f) A and B would also have LL
addresses.

3) If A and C have both LL and routable addresses, A may legally
communicate with them and hence A's address can be passed to C via B.

4) C appears to be a multihomed host. Christian pointed out that there
are problems having LL addresses on multiple interfaces. So, let's
assume that C has LL+routable on B's side and only routable on D's side.

5) Node C would be breaking rule d) by advertising A's LL address to D
(which is beyond the scope of the address). However, passing A's
routable address to D doesn't violate the rule.

The rules are somewhat harsher than I had initially envisioned, but as
you can see that they would work in your scenario while effectively
curtailing address leakage.

> Are permanently LL-only devices allowed, even on configured networks?

Permanently LL-only nodes are likely to be very restricted devices,
which do not need to participate in complex applications. In practise,
they should not have any need to participate in routed networks. If
there was a use case, the manufacturer would surely provide a mechanism
to configure a routable address.

However, I don't think we can assume that such would never be connected
to a link that is also part of a routed network. In fact, they probably
will. What we coud do, though, is say that their utility in routed
networks is limited; that they can only connect to other LL-compliant
nodes. LL19 would have enforce this and thus effectively contained any
problems that such LL-only nodes might cause in a routed network.

>  Are a
> mixed set of LL-only and routable hosts allowed to co-operate?

Under my proposed rules, only if the routabe nodes also have LL
addresses. All LL-compliant nodes would have one. Legacy nodes would
not.

>  What is
> expected to happen when a DHCP server pops up on a LL network?

All nodes that can configure a routable address will do so, leaving
their LL addresses on the side.

>  What happens
> if a DHCP server refuses to supply addresses to some but not all hosts?

Some nodes will have routable addresses, and all compliant nodes will
also have an LL addresses. Legacy nodes may or may not have a single
routable address, depending on the DHCP server.

>  If
> their LL addresses?

Normally they wouldn't, since the applications would be using the
routable addresses (rule d). An application could explicitly try a
LL-address.

>  How are misconfigured routable addresses dealt with?

They aren't exactly, as the rules for LL are completely independent of
the configuration of routablea addresses. However, all compliant nodes
will have a LL address and are able to interoperate using those. A
LL-aware application could explicitly switch to using a LL destination
address if the

	MikaL

---

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

> LL-aware application could explicitly switch to using a LL destination

...routable address of the peer was not working.

---

From: "Philip Nye" <[email-masked]>
Date: Sun, 23 Feb 2003 22:46:33 -0000

> 169.254/16 on-link route)

By legacy I think you mean ones with no LL sense at all?

Where do the large numbers of nodes with Apple/Windows LL implementations
fit in?

Philip

---

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

> By legacy I think you mean ones with no LL sense at all?

Correct.

> Where do the large numbers of nodes with Apple/Windows LL implementations

We'll find a free spot somewhere among the legacy nodes. :)

Seriously, there'll be lots of legacy nodes around, since not everyone
runs Windows or Macos and many of those who do don't really update their
machines all that often.

I probably overemphasized the legacy nodes a bit, but if we're talking
about address leakage, legacy nodes and legacy apps are the obvious
culprits.

	MikaL

---

From: "Philip Nye" <[email-masked]>
Date: Mon, 24 Feb 2003 09:43:03 -0000

Mika,

> rejected) are roughly as follows:

Thank you for taking the trouble to give such a complete description of your
vision of LL. It helps clear up a lot of misunderstanding.

I can see that under the full set of conditions you describe, that it could
be made to work.

However, I don't find all these conditions acceptable or even achievable.
Firstly, I think interoperation with the vast number of Mac and Windos hosts
running their own form of LL is important.

Secondly, I think that your solution relies too heavily on making a lot of
application level software LL aware. In particular with respect to rule e),
service discovery protocols are numerous (many of them in little niches),
are already deployed, and are not generally a part of the OS. Therefore you
are effectively imposing a requirement to rewrite and update all of them.

Since last call for these issues is in and I have placed my vote, I will now
shut up on these issues on the list.

regards,
Philip

---

From: Mika Liljeberg <[email-masked]>
Date: 24 Feb 2003 20:20:42 +0200

> running their own form of LL is important.

Interoperability would not be a problem, since a host following my model
would have both addresses and would just use the appropriate one to
communicate with a Mac or a Windows system regardless of its current
mode of operation.

> application level software LL aware. 

Not really. The key control points are the APIs on a compliant node.
Those should protect legacy applications from making any typical
mistakes. This is a good practise to adopt regardless of whether LL23 is
accepted or not.

> In particular with respect to rule e),

As Erik pointed out, the service discovery mechanisms are not yet that
widely used. I don't think it would be a huge problem in practise. The
LL23 approach is not exactly leak proof either.

> shut up on these issues on the list.

I respect your choice, but I feel that adopting LL23 is clearly an
implementation decision and should not be mandated for every OS. It may
be a good approach for Windows and Macos, but on another type of device
(e.g. with a more controlled set of applications) it might be more
appropriate to have both LL and routable addresses active.

Rejecting L23 does not preclude OS vendors from implementing it, if they
consider it justified.

	MikaL

---

From: Robert Elz <[email-masked]>
Date: Tue, 25 Feb 2003 20:04:21 +0700

Date:        Sun, 23 Feb 2003 11:15:15 -0700
    From:        Ted Lemon <[email-masked]>
    Message-ID:  <[email-masked]>

  | What LL1/LL23 do is to create an interdependency between IPv4ll and 
  | DHCP that is sufficiently strong that we would have to say that this 
  | draft now updates RFC2131.

This is certainly not the case with LL23.   LL23 just talks about having
a routable address, how that address is obtained is not considered.
It may be via DHCP, in which case what DHCP considers to be assigning
a routable address is for DHCP to define (receiving an ACK to a REQUEST
would usually be that I think, and not getting any answer at all from
a DHCP server, would be not getting an address).

What's important is that the node tries to obtain a routable address.
Having tried, and failed, then go ahead, and use the LL address.  I'm
even not adverse to having something which says that if the routable
address seems to fail (and the node hasn't been explicitly configured
not to use LL) then it should attempt to renew its routable address
using whatever means exist (there are none for a manually configured
address of course), and if that fails, then go ahead and configure LL.

The mechanisms by which a node discovers that an address it has been
assigned is no longer working are really outside the scope of this WG,
and what's more, I see no need to standardise them at all.  Different
nodes can do this in their own ways.

Further, nothing in this requires any changes to 2131, which does not
require nodes to keep on using assigned addresses until the lease
runs out, or not even until the initial renewal timer goes off.   A node
can decide to renew its address any time it feels inclined to do so.
If that fails, then it has many options - including just continuing to
use the address while it tries more agressively to renew, but if coupled
with any other evidence of the address being unworkable (rather than just
the DHCP server being rebooted or something) it can assign itself a LL
address, and use it, if that seems best (nothing in LL23 prohibits that).

  | Neither LL1 nor LL23 provides sufficient detail to really update RFC2131.

For LL23, that's good, as updating 2131 was never its aim.

  | So if either is accepted, then we 
  | need to go through this draft very thoroughly and tweak it so that it 
  | is actually a complete update to RFC2131.

Nonsense.

  | Christian mentions the problem with queries for net 10 addresses at the 
  | root, and implies that allowing a node to have both an IPv4ll and a 
  | global address will result in similar problems.   But the fact is that 
  | LL1/LL23 do not solve this problem

That's probably true, but ...

  | - it's still possible that my 
  | IPv4ll-aware device that happens to have a global address will do a PTR 
  | lookup when it gets a connection from my IPv4ll device that doesn't 
  | currently have a routable address.

That indicates an implementation bug in your node, surely?   If it is LL
aware, than aside from someone explicitly using some diagnostic tool,
it should never be doing DNS lookups for LL addresses.   It knows it
can't succeed, and deliberately executing code that cannot work is almost
the definition of a bug...    (nb: we are assuming LL aware there, LL
unaware nodes will be doing PTR lookups for LL addresses for sure - they'll
fail,  and inconvience the roots, but the only way to avoid that would be
to not have LL addresses - we can minimise it though by having LL aware
nodes not use LL addresses except when that is essential, then the other
nodes won't see LL addresses very often, and the root load will at least
be lower).

  | In fact, I'm not sure in what case 
  | an actual reduction in the number of queries to the root would happen 
  | as a result of accepting LL1/LL23.

If I don't have an LL address, then no peer node will ever see that
non-existing LL address, and so will never do a PTR lookup of it.
If I do have an LL address (when I don't have to have it) then some
peer node (unaware of LL) might see that address, and attempt to
determine a hostname from it.   This should be obvious.

  | In order to do IPv4ll over multiple interfaces, the IP stack must be 
  | smart enough to ARP on all interfaces that support IPv4ll when it is 
  | asked to communicate with IPv4ll address that is not currently in the 
  | ARP cache.

This is unreliable.   I would consider any such implementation
horribly broken.   What's needed is for the v4 stack to grow
address scoping capabilities in its address identifier, as has
been done in v6, so the application can be told, and/or tell the
stack, which particular link this link local address belongs to.

I'd be tempted to add this as an absolute requirement before allowing
a node with multiple interfaces to communicate using LL out more than
one of them.

  | It is unfortunate that LL19 was discussed and rejected separately from 
  | LL1/LL23, because the two are strongly interconnected.   LL19 solves a 
  | lot of the problems that LL1/LL23 try to solve, in a much better way.

Unfortunately, it was impractical, regardless of what it solves.
In some idealised world where everything understands LL, it might
have been practical, but that world, and our world, are not the same thing.

kre