Subject: New issue: When to configure a LL address

From: Mika Liljeberg <[email-masked]>
Date: 06 Mar 2003 18:03:08 +0200

Description of issue:	When to configure a LL address
Comment type: 		'T'echnical
Priority: 		'S' Must fix
Section: 		1.5

Rationale/Explanation of issue:

A node with a manually configured address is unable to communicate if
taken outside its home link. It is also prohibited from configuring a
link-local address.

Lengthy description of problem:

If a node having a manually configured routable address and netmask is
connected to a link where other nodes have a different netmask, it will
be unable to communicate with those nodes. The node is also prohibited
from configuring itself a LL address, because it already has an address
configured.

The above also applies to scenarios, where a node has configured an
address using DHCP, or any other such mechanism, and fails to detect
that the address has become unusable in the current context.

The following text in section 1.5 is inaccurate, as it does not consider
the configured netmask:

"A node with any address assigned for a link can communicate with all
other devices on that link, whether those other devices use link-local
addresses, or routable addresses."

Requested change:

Delete the current text in section 1.5 and replace it with:

"Having addresses of multiple different scopes assigned to an interface
with no adequate way to determine in what circumstances each address
should be used leads to complexity for applications and confusion for
users. For this reason, a host that obtains, or is configured with, a
valid routable address on an interface, should not attempt to configure
a link-local address on the same interface.

Determining whether an address is valid is problematic, as this cannot
be deduced from the scope of the address. The presence of a valid
default gateway, however, is a good indication that the node is
connected to a routed network and has the appropriate network
configuration.

A default gateway address is determined to be valid if a) the address
matches the netmask of the interface, and b) the gateway is determined
to be reachable on the local link. A gateway is determined to be
reachable if it responds to ARP on the local link. Other means of
determining gateway reachability may also be employed.

Where an address and a valid default gateway are configured on an
interface, a host SHOULD NOT attempt to configure a link-local address
on the same interface.

Where a valid default gateway is not configured on an interface, or the
configured gateway becomes unreachable, the host SHOULD configure a
link-local address on the same interface and it SHOULD advertise that
link-local address on the local link in place of any other addresses it
may have.

Where a link-local address has been configured on an interface, and a
valid default gateway is later configured on the same interface, or
becomes reachable, the host SHOULD always use the routable address when
initiating new communications, and SHOULD 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."

---

From: Ted Lemon <[email-masked]>
Date: Thu, 6 Mar 2003 11:32:35 -0600

The problem with your proposed text, Mika, is that it means that 
whenever I reboot my airport base station, all my connections break, 
because my airport base station is both the router and the DHCP server, 
and rebooting it causes my network connection to make the up-to-down 
and down-to-up transition.

---

From: Mika Liljeberg <[email-masked]>
Date: 06 Mar 2003 19:51:31 +0200

> and down-to-up transition.

Hmm, I'm not sure which part of the proposed text you mean. Can you be
more specific?

The text I added basically gives the node a permission to configure a LL
address in certain situations but does not suggest that it should
unconfigure its routable address. The other constraints come from the
LL23, painful as they are.

Whether you lose your connections booting your base station depends on
how fast it reboots and how quickly your applications time out. TCP
keeps on plugging for quite a while, so that should not be a problem.

	MikaL

---

From: Ted Lemon <[email-masked]>
Date: Thu, 6 Mar 2003 12:14:26 -0600

> LL23, painful as they are.
Hm, I didn't get that from reading your text - sorry.  I should have 
read more carefully.   Unfortunately I don't think this solves the 
problem, because with the current changes to IPv4ll, it's unlikely that 
it will work correctly in the case that a host has both an IPv4ll 
address and an address acquired from DHCP.

> keeps on plugging for quite a while, so that should not be a problem.

As long as you never unconfigure your DHCP-acquired address, this is 
probably true.   However, once you unconfigure it, all bets are off - 
if you're lucky nothing will happen; if you're not, your TCB will be 
pointing at a dangling route, and even after you get your address back 
you won't be able to use it.

---

From: Mika Liljeberg <[email-masked]>
Date: 06 Mar 2003 20:31:17 +0200

On Thu, 2003-03-06 at 20:14, Ted Lemon wrote:
> read more carefully. 

I was trying to keep DHCP out of it. Unconfiguring the address is, IMHO,
always the responsiblity of the mechanism that configured it in the
first place.

>   Unfortunately I don't think this solves the 

Yes, it's a mess. We would need to say something more about source
address selection as well. Any suggestion regarding the text would be
welcome.

I put this proposal out to kick off some discussion. I don't think
ignoring the problem in zeroconf is the right thing to do. This is not
only about DHCP.

> you won't be able to use it.

Agreed, although I guess a good DHCP server will still try to give you
the same address you had before? But anyway, this one *is* a DHCP
specific problem.

	MikaL

---

From: Ted Lemon <[email-masked]>
Date: Thu, 6 Mar 2003 13:44:30 -0600

> always the responsiblity of the mechanism that configured it in the

BTW, I don't think you *can* keep DHCP out of it and get anything 
remotely resembling reliable behavior.   Even if you bring DHCP into 
it, you still don't get wonderful behavior, but my point is that like 
it or not, correct DHCP behavior *is* being constrained by the new 
changes to IPv4ll.

---

From: Mika Liljeberg <[email-masked]>
Date: 06 Mar 2003 22:18:11 +0200

> it or not, correct DHCP behavior *is* being constrained by the new 

Oh I agree, the DHCP case needs to be solved but I want a solution for
manually configured addresses as well. That's what I wanted to explore.
Unfortunately, the DHC WG won't solve manual configuration for us.

If we have to discuss DHCP as well to get a good solution, let's do it. 

	MikaL

---

From: Ted Lemon <[email-masked]>
Date: Thu, 6 Mar 2003 15:51:15 -0600

> Unfortunately, the DHC WG won't solve manual configuration for us.

It seems like in the manual case, it's not such a big problem, because 
there the user is actively engaged in the configuration process, so 
s/he is not going to be surprised if some manual adjustment is required 
when changing networks.

---

From: Mika Liljeberg <[email-masked]>
Date: 07 Mar 2003 00:06:24 +0200

> s/he is not going to be surprised if some manual adjustment is required 

I disagree. A mobile device could easily have a static manually
configured address and the user might not have the administrator rights
for it, or might not have the technical skills to change the
configuration.

	MikaL

---

From: Ted Lemon <[email-masked]>
Date: Thu, 6 Mar 2003 16:35:29 -0600

> for it, or might not have the technical skills to change the

Eek.   But what's the failure scenario there?   If it's got a static IP 
address, and is doing IPv4ll with that address, why is it a problem to 
communicate with it?

---

From: Mika Liljeberg <[email-masked]>
Date: 07 Mar 2003 00:38:39 +0200

> address, and is doing IPv4ll with that address, why is it a problem to 

Same as with DHCP. Wrong netmask.

	MikaL

---

From: Ted Lemon <[email-masked]>
Date: Thu, 6 Mar 2003 17:01:25 -0600

> Same as with DHCP. Wrong netmask.

I'm still not getting it.   Why would a device that's manually 
configured and not user-configurable move to a new network?   How would 
it be the case that it had the wrong netmask to communicate with some 
device on the local network?

---

From: Mika Liljeberg <[email-masked]>
Date: 07 Mar 2003 01:17:38 +0200

On Fri, 2003-03-07 at 01:01, Ted Lemon wrote:
> configured and not user-configurable move to a new network?

It could simply be a laptop with a manually configured address. Or a
mobile handset that takes its IP address from the SIM card. Either way,
chances are that it was configured by the by the local computer support
person and that the user is not a nerd.

>    How would 

Your own example: the user meets somebody over lucnh and they plug their
devices together with a cross-over cable [Nah, they'll probably just use
Bluetooh or WLAN]. The netmasks don't match ==> no connectivity.

	MikaL

---

From: Ted Lemon <[email-masked]>
Date: Thu, 6 Mar 2003 17:35:11 -0600

> Bluetooh or WLAN]. The netmasks don't match ==> no connectivity.

This seems like severe pilot error to me, not a protocol issue.   I 
don't think we can armor this protocol against malicious behavior on 
the part of knowledgeable admins.   A mobile handset with an IP address 
in a SIM card is just broken - that makes no sense at all for a mobile 
device.   Likewise a laptop with an address hard-coded by an admin - is 
the admin stupid, or just looking for a new job?

---

From: Mika Liljeberg <[email-masked]>
Date: 07 Mar 2003 02:03:06 +0200

On Fri, 2003-03-07 at 01:35, Ted Lemon wrote:
> the part of knowledgeable admins.

If I've bought a few static IP addresses from my ISP, that's what I'll
use. I'd still like my laptop to be able use a LL address when
necessary. Preferably without manual intervention.

>    A mobile handset with an IP address 
> device.

It does make sense if the device normally uses it as the home address
with MIP, or if the network handles mobility below the IP layer.

>    Likewise a laptop with an address hard-coded by an admin - is 

If the company has a small single site network, the administrator might
as well go with manual addressing. There's no particular reason to set
up a DHCP server.

The point is, we can't assume that everyone configures their routable
addresses using DHCP.

	MikaL

---

From: "Philip Nye" <[email-masked]>
Date: Fri, 7 Mar 2003 09:24:13 -0000

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

I can only partially agree with this. I know of plenty of people who have
their laptops configured for them - in a surprising number of cases with
static addresses - by some comopany sys-admin, but who would like very much
to be able to do zero-config stuff too.

The point here is that there is active configuration, but not necessarily by
the user.

Philip

---

From: "Philip Nye" <[email-masked]>
Date: Fri, 7 Mar 2003 09:44:42 -0000

> and down-to-up transition.

I would think that whether this is the desired behaviour or not depends on
how long your base station is down for. If that is a long time (whatever
that means) this is probably the desired behaviour.

This begs other questions like why do you need to reboot the base station
anyway? Wouldn't you expect connections to be broken when you are rebooting
your router?

What Mika is rightly looking for is a sensible indication of when to decide
that a routable address is "not working". This would seem easy enough at
first sight but is actually quite difficult.

Perhaps active testing of the available connectivity (ARPing the gateway,
pinging the DHCP server etc) should only take place if no unicast packets
from other hosts (possibly just routable addresses) are received for some
idle time. This would mean that if existing connections are up and running,
then the host isn't going to suddenly reconfigure, but on start-up or after
sleep etc, the interface will have been idle for a while and testing can
proceed immediately.

Philip

---

From: Mika Liljeberg <[email-masked]>
Date: 07 Mar 2003 14:37:42 +0200

> first sight but is actually quite difficult.

It is. This is basically a movement detection problem and I don't think
it is possible to do this reliably with existing protocols. As Thomas
suggested, movement detection probably deserves a work item of its own
[Or maybe we should just give up and go with IPv6 :-)]. Meanwhile, we
need something sensible to make things work at all.

My view is that, whenever the validity of the routable address is in
doubt, a host should be allowed to have both routable and LL addresses
configured at the same time. If I had my way, I would just do that all
the time but it has become clear that others violently disagree with
that approach.

> idle time.

For outgoing packets, gateway reachability is normally tested only when
trying to send packets to the gateway. If the ARP entry for they gateway
times out and cannot be renewed, the gateway is unreachable. Having all
configured gateways suddenly become unreachable is, to my mind, a pretty
good indication that the host is not in the topological position it s

What you're proposing is something different. Doing active probing of
the gateway while the node is otherwise idle does not make any sense to
me.

[Active probing of a DHCP server might make sense but figuring that part
out is something I'd rather leave to the DHC WG. When to configure or
unconfigure a routable address is not really up to this WG to decide].

>  This would mean that if existing connections are up and running,

I agree with the sentiment. We need to be very careful to not force a
node to suddenly unconfigure the routable address. I'm more interested
in a model that lets use configure a LL address on the side, when one
may be needed.

	MikaL

---

From: Ralph Droms <[email-masked]>
Date: Thu, 06 Mar 2003 22:04:30 -0500

After reading the discussion about this new issue, I've come to the 
conclusion that the IPv4ll specification simply can't say anything more 
about when to configure various types of addresses than to proscribe 
situations in which IPv4ll addresses cause applications to fail or cause 
the failure of other nodes to communicate on a link.

As an example, at present I don't ever want my laptop to configure an 
IPv4ll address.  I have no way to make sensible use of IPv4ll addresses, 
and any attempt by my laptop to configure an IPv4ll address is wrong and 
will cause me to spend cycles trying to debug a network problem.

And I know what to look for in my interface configuration to figure out 
that I've been "helped out" with an IPv4ll address.  Please correct me if 
I'm wrong, but I imagine there are many users who can't use a network, know 
enough to check the interface configuration and see a non-zero IP address, 
and go looking elsewhere to solve the problem.

I don't claim this should be everyone's preference for using IPv4ll 
addresses.  And that's exactly my point.  I have yet to see any set of 
requirements or recommendations that won't cause trouble for someone.  I am 
annoyed enough at the times when my laptop decides to configure an IPv4ll 
address now.  I *certainly* don't want some stronger recommendation that 
will cause my laptop to be *more* likely to configure an IPv4ll address.  I 
want to turn off IPv4ll until I decide I have a reason to use IPv4ll addresses.

I'm not trying to dictate how every device uses IPv4ll.  If you have a good 
reason to try IPv4ll aggressively, that's fine.  Don't make me do it.

- Ralph

---

From: Mika Liljeberg <[email-masked]>
Date: 07 Mar 2003 14:57:44 +0200

> the failure of other nodes to communicate on a link.

I would go with that!

> and go looking elsewhere to solve the problem.

True enough, although that's a usability issue that has nothing to do
with the protocol itself. If the OS gave the user better feedback, such
confusion wouldn't arise.

> reason to try IPv4ll aggressively, that's fine.  Don't make me do it.

I fully agree. If you don't want v4LL, you should have a way to disable
it completely. On the other hand, if I choose to enable it, I want it to
"just work".

	MikaL