Subject: Re: The IPv4ll draft updates RFC2131

From: Bernard Aboba <[email-masked]>
Date: Tue, 4 Mar 2003 03:54:32 -0800 (PST)

Here's what RFC 2131 says (Section 3.1):

"If the client
receives neither a DHCPACK or a DHCPNAK message after employing
the retransmission algorithm, the client MAY choose to use the
previously allocated network address and configuration parameters
for the remainder of the unexpired lease."

Note that the behavior is a MAY, not a SHOULD.

Nevertheless, I do think that there is a valid point here -- particularly
relating to mobile computing such as hosts that implement IEEE 802.11 or
a Mobile IP Mobile Node (MN).

On detecting movement at L2, a MN  will typically attempt to determine
whether it has moved subnets by seeing if it can obtain a Care of Address
(CoA). It is possible that the MN did not change subnets (e.g. WLAN
roaming), and in that case you want the MN to retain its DHCPv4 address
and to do so as quickly as possible. Here is what Section 3.7 of RFC 2131
says:

"  A client SHOULD use DHCP to reacquire or verify its IP address and
   network parameters whenever the local network parameters may have
   changed; e.g., at system boot time or after a disconnection from the
   local network, as the local network configuration may change without
   the client's or user's knowledge."

The recommended verification should probably occur on *reconnection*,
not after a *disconnection*, but the principle is a valid one. After all,
a host that is disconnected from the network probably won't be able to
obtain a new IP address until it reconnects, and if taken literally, the
advice above would result in a failure to obtain an address and possible
use of LLv4, inappropriately in my opinion.

RFC 2131 continues:

"  If a client has knowledge of a previous network address and is unable
   to contact a local DHCP server, the client may continue to use the
   previous network address until the lease for that address expires.
   If the lease expires before the client can contact a DHCP server, the
   client must immediately discontinue use of the previous network
   address and may inform local users of the problem."

So if the lease is still valid then the host MAY continue to use it,
absent any reason to change it. If instead the MN were to obtain an LLv4
address (and not continue to configure the DHCPv4 assigned address), then
if there is a glitch at L2 (e.g. delay in putting IEEE 802.11 keys in
place, for example) then the DHCPv4 address could be (incorrectly)
be disabled and a considerable delay (5 minutes by default) will
occur between DHCPv4 attempts. This leaves the MN without connectivity for
a considerable period when it could have continued to use the existing
IPv4 address. That seems wrong to me. Part of the problem may come in
defining what "reconnect" means (such as having a fully functional link
layer, not just a "link up") but another part of the issue may be that
DHCPv4 retransmission time is not actually very long (60 seconds).
However, in practice we do see this problem occur quite often with current
implementations (in fact, I'd guess that the majority of LLv4 usage occurs
due to this problem).

Note that there are reasons for a DHCPv4 server not to respond to a
DHCPREQUEST even if it is available. For example, RFC 2131, Section 4.3.2
states:

"  If the network is correct, then the DHCP server should check if
   the client's notion of its IP address is correct. If not, then the
   server SHOULD send a DHCPNAK message to the client. If the DHCP
   server has no record of this client, then it MUST remain silent,
   and MAY output a warning to the network administrator. This
   behavior is necessary for peaceful coexistence of non-
   communicating DHCP servers on the same wire."

So if you have two DHCPv4 servers on the same network (for resiliency),
and they do not communicate, then if one goes down the other will not
respond for it. The last thing you would want in that circumstance would
be for hosts to stop using their DHCPv4 address, since that would take
away the resiliency that you're attempting to achieve in that
configuration.

One way out of this might be to continue to use the DHCPv4 address for
existing connections, but initiate new connections from LLv4. This is
similar to what we talked about doing for the case where a host obtains a
DHCPv4 address after initially using LLv4.

On the other hand, I think that it doesn't *always* make sense to keep the
DHCPv4 address. There are situations in which *really long* lease times
can be assigned. For example, at home my DHCP server assigns leases of
several days. If I want to set up an adhoc 802.11 network, then I
don't want to wait until lease expiration to get going :)

In practice there may be reasons for a host to believe that it
has moved networks, and that the DHCPv4 assigned address is no longer
valid. For example, the host can attempt to ping the router from the
DHCPv4 assigned address and fail. Or an 802.11 card can be switched from
infrastructure mode to adhoc. Or RS traffic might be heard indicating
a change of network. These might be reasons to configure an LLv4
address after a DHCPREQUEST is not answered.

In practice, most of the places in which I've used LLv4 successfully (as
opposed to all the times where LLv4 addresses were assigned when they
shouldn't have been, which is most of the time) fall into the "prior
knowledge" category. So in practice, I think we may be able to come up
with a workable solution.

---

From: Mika Liljeberg <[email-masked]>
Date: 04 Mar 2003 15:48:34 +0200

Presumably we should be talking about routes here. Configuring and
unconfiguring addresses is a side issue. We should probably have
something like the following:

169.254/16 --> local link   [always on designated LL interface]
a.b.c.d/x --> local link    [from DHCP]
0.0.0.0/0 --> default GW    [from DHCP]
0.0.0.0/0 --> local link    [always on designated LL interface]

The above routes should be matched in the order they are written. When
the default GW is determined to be unreachable, the node would fall back
on the on-link default route.

	MikaL

---

From: Robert Elz <[email-masked]>
Date: Wed, 05 Mar 2003 19:29:41 +0700

Date:        04 Mar 2003 15:48:34 +0200
    From:        Mika Liljeberg <[email-masked]>
    Message-ID:  <1046785713.1902.8.camel@devil>

  | Presumably we should be talking about routes here. Configuring and
  | unconfiguring addresses is a side issue.

Actually, it isn't, it is the primary issue.

Routing, as you showed, isn't difficult to handle, given a suitable
address to use, implementations will normally be able to come up with
an appropriate way to use it.

The complexity all seems to relate to which addresses the host should
use, and when.  If it abandons a routable address (using LL instead)
then in many cases that will needlessly cause connections to fail, and
new connections to be unable to be made (despite the rationale of this
WG, in the wild, nodes rarely ever want to actually communicate with
something on the same link).

On the other hand, if a node persists on using a routable address when
it shouldn't (say, just because its lease is still valid) then it won't
be able to communicate with anyone at all (be even worse than having
just an LL address).

There is nothing in 2131 that mandates or even recommends that a node
fall into either of those traps however - it would be surprising if
there were.   That some common implementations have gone full bore in
one of those directions or the other to me just means lack of thought
at the implementation level.

I agree with Bernard ...

	So in practice, I think we may be able to come up
	with a workable solution.

I believe we can - all that's needed is for implementors to be more
intelligent when choosing whether to keep using an existing routable
address (from a DHCP lease, or otherwise) and when to abandon that
and fall back to LL addresses.

Neither of the extremes "I might be on a new link, and there is no
DHCP server responding to reassure me I'm not" nor "my lease is
still valid, no-one is telling me not to use it" are appropriate.

What's needed is some rational validation of the efficacy of the
lease (which has not expired) before deciding to continue using it.
If the address looks like it should still work (which is likely if
anyone responds to an ARP request for the default router, and no-one
replies to an ARP request for the host's own address - this at
least implies that the host is on a LAN with compatible addresses, and
isn't usurping someone else's address - even if the address technically
belongs elsewhere).

On the other hand, if someone else claims the address I think I should
be able to use, or nothing is answering at the address I believe is
my default gateway, then most likely the host shouldn't be using the
address, and should fall back to LL (if there is no default router, it
has little to use).

The actual mechanisms that the hosts use can be tuned with experience.
They don't need to be standardised - no harm comes if different hosts
use different methods to work out whether an address is still functional
or not.

No updates to 2131 are needed for any of this.   Updates to some (client)
implementations of 2131 may well be, but that's a completely different
thing.

kre

---

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

> be able to communicate with anyone at all (be even worse than having

I think you missed the main point, which was that the fallback onlink
default route kicks in when the default gateway becomes unreachable. 

With the above routes, a node can just keep its routable address for as
long as the lease time says and that same address can be used for all
link-local communication. Validation of the address only has to be done
on reconnection to a managed network.

[I think there was an issue about ARPing for all addresses, but
www.spybeam.org is unreachable at the moment, so I can't check.]

	MikaL

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 5 Mar 2003 03:48:19 -0800 (PST)

> on reconnection to a managed network.

So how do we know if we're on a "managed network" if the DHCP server
doesn't answer, and the previous gateway doesn't respond to an ARP
request?

If we take this advice, then the host would not obtain a new routable
address until the lease time expires.

Seems to me that it makes more sense to periodically attempt to obtain a
routable address (and at less than 5 minute intervals, please).

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 5 Mar 2003 03:51:08 -0800 (PST)

> still valid, no-one is telling me not to use it" are appropriate.

This is very good advice -- so much so that it probably should be in the
draft.

> isn't usurping someone else's address - even if the address technically

Yes, this seems sensible.

> use different methods to work out whether an address is still functional

Given the problems with existing implementations, it seems to me that
at least some advice is needed to achieve our goal of "doing no harm".

> implementations of 2131 may well be, but that's a completely different

I agree.

---

From: Mika Liljeberg <[email-masked]>
Date: 05 Mar 2003 15:15:08 +0200

> doesn't answer, and the previous gateway doesn't respond to an ARP

If the DHCP server isn't responding, I would just go on using whatever
configuration I have at the moment. If the gateway isn't responding, I
would mark the default gateway route unreachable and fall back on the
link-local default route.

> address until the lease time expires.

I wasn't suggesting this. A node should try to validate its
configuration on reconnection (however that is detected).

A node could use any number of means to decide when to try to connect to
a DHCP server: media sense, sniffing the network, retransmissions every
now and then. This is a simpler issue to solve.

> routable address (and at less than 5 minute intervals, please).

This would be fine with me.

	MikaL

---

From: Mika Liljeberg <[email-masked]>
Date: 05 Mar 2003 16:11:34 +0200

> This is very good advice -- so much so that it probably should be in the

So what am I missing? Why exactly is the latter statement not
appropriate? Why should we try to second guess the lease time?

If the lease is valid, the address is mine. I may not be in the right
position in the network topology for it to work but, assuming I can't
get a new routable address, why exactly should I stop using the old one?

	MikaL

---

From: Thomas Narten <[email-masked]>
Date: Wed, 05 Mar 2003 09:08:18 -0500

Popping up a level.

I'm not sure how much detail the LL document should get into with
regards to DHC and how to perhaps clarify what a client should do when
it disconnects/reconnects to a network. I tend to think that this
document should not be updating 2131.

I actually suspect that the general topic of connection/disconnection,
how to detect this, how to do so quickly, etc., is a general enough
topic to warrant a separate document/effort to clarify what clients
should do. This may involve clarifying and updating parts of 2131.

This topic is not specific to LL addressing. It is a generic DHC issue
(one can argue that the guidance in 2131 is insufficient and that we
have much more experience today and should collect that experience
into a document).

Moreover, the same general topic also crops up in mobility, where folk
want to be able to learn *very* *quickly* if they have moved to a new
link (e.g., do they need a new address? new gateway? additional
parameters?). So, some of the mobility documents get into this space
too.

IMO, this is a generic issue and it would be good to document/address
it in one place, with input from all the communities that have
concerns with what is done today or the lack of clear guidelines to
handle existing concerns.

Thoughts? Do others thing that a separate effort is needed in this
space?

Thomas

---

From: Robert Elz <[email-masked]>
Date: Wed, 05 Mar 2003 21:17:26 +0700

Date:        05 Mar 2003 14:43:37 +0200
    From:        Mika Liljeberg <[email-masked]>
    Message-ID:  <1046868217.14873.15.camel@devil>

  | With the above routes, a node can just keep its routable address for as
  | long as the lease time says and that same address can be used for all
  | link-local communication. Validation of the address only has to be done
  | on reconnection to a managed network.

No, that doesn't work if the address is an "invalid" one for the net
it is connected to.

That is, if I take a host that is 10.1.2.3 and move it to a net where
the DHCP server either doesn't exist, or is down, but where the
address that should be used is 192.168.1.5 then it doesn't help that
the node simply ARP's for everything using the fallback default route,
as while that would allow its packets to reach its peer, reply packets
from the peer are going to go somewhere wild.

The address is important, you can't just ignore it.

kre

---

From: Robert Elz <[email-masked]>
Date: Wed, 05 Mar 2003 21:24:08 +0700

Date:        05 Mar 2003 16:11:34 +0200
    From:        Mika Liljeberg <[email-masked]>
    Message-ID:  <1046873494.14850.36.camel@devil>

  | So what am I missing? Why exactly is the latter statement not
  | appropriate? Why should we try to second guess the lease time?

It depends what exactly "second guess" means.

I certainly don't mean that the lease should be abandoned, you never
know, the node might move back to a link where the lease still works,
and in that case, it is fine to use it again.

  | If the lease is valid, the address is mine. I may not be in the right
  | position in the network topology for it to work but, assuming I can't
  | get a new routable address, why exactly should I stop using the old one?

See my more recent mail...

kre

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 5 Mar 2003 05:15:54 -0800 (PST)

> should do. This may involve clarifying and updating parts of 2131.

This seems reasonable. It may also relate to the ACD document.

> have much more experience today and should collect that experience

Yes, I think a separate document probably is required. At the same time,
current implementations of LLv4 are doing some unwise things, so that some
guidance is probably appropriate in the LLv4 document, so as to "do no
harm".

---

From: Mika Liljeberg <[email-masked]>
Date: 05 Mar 2003 16:30:58 +0200

> from the peer are going to go somewhere wild.

So the case you're trying to solve is this [just so I understand]:
1) the DHCP server is down
2) the default GW is up
3) all the other nodes on the link are configured and holding on to
their routable addresses
4) my address is from a different subnet

Thanks, I see the problem. Do you think this is a common enough
situation to worry about?

> The address is important, you can't just ignore it.

That's why I still think LL23 was a bad idea. :) Our current
implementation wouldn't have any problem with the above configuration.
LL23 introduced this one.

	MikaL

---

From: "Philip Nye" <[email-masked]>
Date: Wed, 5 Mar 2003 14:35:15 -0000

> From: "Thomas Narten" <[email-masked]>
>

It has become clear to me that these issues extend well beyond LL - although
LL is part of the picture. It has become much more widespread recently, to
move a host from one network to another over short timescales and wireless
has accelerated this tendency and will continue to do so.

Also the success of DHCP has meant that peoples expectations are that things
should work without explicit configuration at the host (DHCP is zero-config
from most users' viewpoint).

So - yes, I think that this would be timely and useful.

Philip

---

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

I agree with Thomas that a review (not specific to any protocol) of
procedures related to detecting disconnection/connection events
would be a worthwhile initiative.  As Thomas points out, such
a review would likely provide input to at least DHCP, link-local
addressing and mobility.

The dhc WG has initiated a review of RFC2131; seems like there would
be an opportunity for information exchange between that review and
the review that Thomas proposes.

- Ralph

At 09:08 AM 3/5/2003 -0500, Thomas Narten wrote:
>[...]

---

From: Ralph Droms <[email-masked]>
Date: Thu, 06 Mar 2003 03:35:03 -0500

My comments are in line ... I agree that, because of the
specific use of "MAY" that Bernard pointed out in RFC2131,
we can likely work out a reasonable solution without
updating or revising RFC2131...

- Ralph

>at the implementation level.

Excellent summary - the situation is complex and can't be readily
captured in a single rule like "always continue to use the address
obtained through DHCP" or "always immediately configure an LL address".

>and fall back to LL addresses.

I agree completely - the various protocols have to be specified in
such a way as to allow a device to make a more intelligent decision,
and we should (for example, through an initiative like Thomas
suggested) document whatever current wisdom we can agree on to
guide device developers and users.  The default behavior of my
laptop is likely to be different than the default behavior of
a light switch; the default behavior I choose for my laptop
may well be different from the default behavior you choose for
your laptop; the choice I make about the behavior of my laptop
might be different if I *know* I'm trying to use an ad hoc
network than if I *know* I'm trying to use an overloaded wireless AP.

As kre points out, none of this requires any changes to RFC2131,
and may provide input to related specifications for LL and mobility.

- Ralph

---

From: Robert Elz <[email-masked]>
Date: Thu, 06 Mar 2003 18:14:39 +0700

Date:        05 Mar 2003 16:30:58 +0200
    From:        Mika Liljeberg <[email-masked]>
    Message-ID:  <1046874657.14873.46.camel@devil>

  | That's why I still think LL23 was a bad idea. :) Our current
  | implementation wouldn't have any problem with the above configuration.
  | LL23 introduced this one.

For this it makes no difference.   If you're able to tell that the
routable addr that you had is no longer viable, then (even with LL23)
you're supposed to use an LL address (if you can't get a new routable).

Without LL23, if you had a routable addr, and weren't able to tell it
was non-functional, and you wanted to talk to someone else's routable
address (ie, the normal kind of thing) then you're going to use your
broken routable addr as the source, and fail exactly the same way.

Nodes simply need to be able to tell whether their (old) routable addr
is still viable to use or not, and they need that, regardless of LL
addressing (LL just provides an alternative addr when there is no
available workable routable addr to use).

Where LL23 makes a difference is when you have a working routable addr.
Which is fine, as having a working routable addr, you need no more.

As to how likely this all is - not very likely in most situations these
days I suspect, DHCP tends to exist everywhere, and DHCP servers tend to
be fairly reliable, so it isn't going to happen often that there will be
no server to reply to your address request (the server may ignore your
attempt to renew your old addr, but it won't ignore a DISCOVER to start
finding a new one usually).   In the past, when less nets had DHCP servers,
and the code for them wasn't nearly as reliable as now, this was
probably more of an issue.

Yet, there are still enough windows & macos users who (occasionally)
bitch about the way their system works that this clearly isn't something
that should simply be ignored as "too unlikely to ever happen".   It does
happen, occasionally, and nodes need to be aware of it.

kre

---

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

> you're supposed to use an LL address (if you can't get a new routable).

It does make a difference. With the two-addresses model this would have
worked. Let me illustrate with an example:

A is visiting B's network. A and B have both LL and routable addresses
(the model I was campaining for). B's routable address is in DNS and B
is advertising it's LL address via LLMNR.

A has the following routes:
169.254.0.0./16 --> local link
a.b.c.d/x       --> local link  [INVALID]
0.0.0.0/0       --> default GW  [INVALID, GW UNREACHABLE]

Note: A is also using a DNS server from its home network, which it can't
reach at the moment.

A tries to contact B. First it has to find B's address by resolving its
name. The name resolver runs the destination address selection
algorithm:

1) It asks DNS to get a routable address for B. This fails, because A
does not have a valid route for its DNS server in the home network ==>
go to step 3)
2) If A *had* been able to talk to DNS, in this step it would check if
there is a valid source address for B's routable address. This would
still fail, because there is no matching route.
3) It tries LLMNR and gets B's LL address.
4) It checks if there is a valid source address. This time there is.
5) The resolver returns the LL address to the application and discards
the routable address.

The application on node A connects to B's LL address and works just
fine. The only real hitch is that it takes a little while to mark the
gateway route unreachable. The ARP timeouts determine how long that is.

Note also that there is no dependency to DHCP whatsover. It just works.
If, later on, the DHCP client manages to get the node valid parameters
again, the above algorithm will still keep working.

> was non-functional,

You can easily tell if an address is unusable: you either have a route
for it or you don't. You *do* need proper reachability detection for
this to work, though.

>  and you wanted to talk to someone else's routable

That's why intelligent API implementation is important, for naive
applications at least. A smarter application would simply try all
destination addresses until it found one that works.

	MikaL

---

From: Mika Liljeberg <[email-masked]>
Date: 06 Mar 2003 14:23:33 +0200

On Thu, 2003-03-06 at 14:11, Mika Liljeberg wrote:

Responding to my own mail...

> for it or you don't. You *do* need proper reachability detection for

I didn't say this very well.

The right question to ask is: do I have a usable source address for this
destination address? A TCPIP stack can answer this question as a matter
of course. The key thing is to have reacability detection for gateway
routes.

Btw, applying LL23 to my example: How would A get B's address?

	MikaL

---

From: Robert Elz <[email-masked]>
Date: Thu, 06 Mar 2003 20:44:00 +0700

Date:        06 Mar 2003 14:11:57 +0200
    From:        Mika Liljeberg <[email-masked]>
    Message-ID:  <1046952716.26795.49.camel@devil>

  | Note: A is also using a DNS server from its home network, which it can't
  | reach at the moment.

That's an assumption which isn't necessarily true.   You can't assume
it will work that way.   A might have a DNS cache embedded in it, full
of addresses whose TTL has not yet expired, all ready to be used, without
needing to send any packets.   Or A might simply be attempting to contact
an IP address.

I have no doubt but that there are scenarios when almost anything would
work - but to be useful as "the answer" it needs to work in all the
scenarios (as well as they allow).

Detecting that a routable address has "gone bad" allows that.

kre

ps this also answers the "btw" question in your followup message.

---

From: Mika Liljeberg <[email-masked]>
Date: 06 Mar 2003 15:56:05 +0200

On Thu, 2003-03-06 at 15:44, Robert Elz wrote:
> needing to send any packets.

That's why I put in step 2). This doesn't change a thing.

>    Or A might simply be attempting to contact
> an IP address.

That is a corner case. We can compare the corner cases when you can show
a solution for the common case with LL23.

> Detecting that a routable address has "gone bad" allows that.

Sure. I showed how to do that with my model. How do you do it with LL23?

Question for you: Do you accept that the example I showed is correct and
that it works even if A has a manually configured address+netmask and no
DHCP client implementation at all (which LL23 also breaks)?

	MikaL

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 6 Mar 2003 04:51:17 -0800 (PST)

> The default behavior of my
> a light switch;

Yes. Presumably the light switch is not mobile and therefore there is
less downside to it keeping a DHCPV4 assigned address in the absence
of a response to a DHCPREQUEST.

There also might be a difference in behavior for a wired Ethernet
interface (where the L2 indications are likely to be reliable) versus an
802.11 interface (where they can be quite unreliable).

> the default behavior I choose for my laptop
> your laptop;

I'm curious why you think this might be the case, assuming that they both
have the same interface types (say, 802.11).

---

From: Ralph Droms <[email-masked]>
Date: Thu, 06 Mar 2003 09:13:33 -0500

Regarding default behavior for a laptop - I might use IPv4ll so
infrequently that I always want my laptop to pop up a dialog
box to let me control the use of IP4ll, while you might use
IPv4ll more frequently so that you want your laptop to choose
silently IPv4ll any time you reconnect to a network and can't get
a response from a DHCP server.

- Ralph

---

From: "Philip Nye" <[email-masked]>
Date: Thu, 6 Mar 2003 17:18:33 -0000

> From: "Bernard Aboba" <[email-masked]>
>
> Yes. Presumably the light switch is not mobile...

Its a bit off topic, but this presumption is not correct. While many light
switches are not mobile, some of the most volatile networks around occur in
entertainment lighting (and audio special effects etc.) where networks with
hundreds or thousands of nodes are regularly taken down, shipped across the
country and rebuilt in different configurations for the next night's show.

This is an area where I am engaged in trying to push forward and develop the
use of IP and where automatic configuration has huge potential.

Philip

---

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

> probably more of an issue.

The place where this is going to break, and break frequently, is in 
ad-hoc and home networking environments.   You're right that it's never 
going to happen on your network.   I just find the idea of defining a 
protocol that is most likely to break in the situation where the 
end-user is least likely to be prepared to handle it, well, kind of 
unfortunate.