Subject: Re: [Issue 19] Use v4LL source address for non-V4LL destination

From: Bernard Aboba <[email-masked]>
Date: Sun, 9 Feb 2003 13:58:39 -0800 (PST)

I accept the problem description of this issue, as far as it
goes. Essentially, this is really about determining whether
the destination host supports v4LL or not. If it does, then
there is not a problem with using a v4LL source address,
since the response will go on the local link. If it doesn't,
then the response goes to the router, which is undesirable.

However, one must ask the question "How was the address
of the non-V4LL destination obtained in the first place?"
It could have been learned as the result of receiving
a packet from that host. However, in that case we know
that the host supports v4LL, since otherwise, the packet
would have been sent to the gateway router instead, and
would not have arrived.

Another way it could have been learned is via LLMNR.
That is the v4LL sent an LLMNR request and received
the routable address in response. Assuming that LLMNR
also requires implementation of v4LL (a reasonable
assumption, I believe), again we can assume that the
destination host is v4LL capable.

In fact, the only way it would appear to me that the
v4LL host could learn a routable address without
also knowing that the destination host was v4LL
capable would be if the DNS server is on the local link
with a v4LL address, and the v4LL host is somehow
configured to use it. In this case, I believe it is
also reasonable to assume that the v4LL host also
has a routable address -- and I agree that the routable
address MUST be used in that case.

Given this, here is how I would proposed to modify
Section 2.6, paragraph 4:

"If the destination address is a unicast address outside the
169.254/16 prefix, then the host MUST use an appropriate routable
source address, if it has one. If the host does not have a routable
source address, then it MAY choose to ARP for the destination address
and then send its packet, with a link-local source IP address and a
routable destination IP address, directly to its destination on the
same physical link. The host MUST NOT send the packet to any router
for forwarding."

---

From: Keith Moore <[email-masked]>
Date: Sun, 9 Feb 2003 18:59:37 -0500

On Sun, 9 Feb 2003 13:58:39 -0800 (PST)
Bernard Aboba <[email-masked]> wrote:

> the destination host supports v4LL or not.

Not really.  Even if the destination supports v4LL, the source SHOULD use a
routable source address if it has one.  The only exception that comes to mind
is for diagnostic tools - to test the ability of the destination to reply to a
v4LL address.

> If it does, then
> since the response will go on the local link.

Actually that's not true.  First, the effect of using a v4LL source address is
not limited to the destination host.  Second, the destination host could move
off-link but still stay connected to the Internet.

> of the non-V4LL destination obtained in the first place?"

That's irrelevant, or should be, for a number of reasons.  There are many ways
that a host can obtain an address, including some that don't necessarily use
v4LL.  It's highly undesirable to limit the ways in which addresses propagate,
and it's also highly undesirable to make source address selection dependent on
the source from which the destination address was obtained.

> would have been sent to the gateway router instead, and

No, because even a host that doesn't know how to configure its own LL address
can still be programmed or configured to ARP for an LL address, and it's
probably desirable for hosts to do so.

> destination host is v4LL capable.

a) LLMNR is a mess; we need to scrap it and start completely over.
b) no, it's not reasonable to assume that LLMNR (or its successor) uses v4LL. 
It could as easily use IPv6, and we really don't want to build more "v4-only"
assumptions into the architecture.

> configured to use it. 

You appear to be assuming that a host can learn an LL address through only a
small number of paths (of your choosing), which is completely false.  Nor
would it be desirable to bulid such a limitation into the architecture.

> same physical link. 

That's really not a good idea.  Use of LL source addresses should be avoided
as much as possible, to minimize their potential for leakage and harm.

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 9 Feb 2003 15:15:52 -0800 (PST)

> is for diagnostic tools - to test the ability of the destination to reply to a

I'd agree with this.

> not limited to the destination host.

I don't understand what you mean by this. If the destination host is V4LL
capable, then the packet will not go to the router. So other than the
destination and source hosts, who else does the packet effect?

> Second, the destination host could move

That is true, but if the destination host is V4LL capable, this will only
result in it ARP'ing for the v4LL address, and not getting a reply. No
harm done.

> That's irrelevant, or should be, for a number of reasons.

It's very relevant -- because my claim is that there are no ways that this
can be accomplished by a host with a only a v4LL address that also don't prove
that the destination host is v4LL capable.

> probably desirable for hosts to do so.

There are no such hosts today -- and the spec can be written so that such
hosts do not exist in the future if we choose to do so.

> would it be desirable to bulid such a limitation into the architecture.

If it is completely false -- why don't you provide a counterexample?

---

From: Keith Moore <[email-masked]>
Date: Sun, 9 Feb 2003 19:45:53 -0500

> > Actually that's not true.  First, the effect of using a v4LL source
> > address is not limited to the destination host.
> 

any other host that the destination host sends the address to.
 
> result in it ARP'ing for the v4LL address, and not getting a reply. No

it just means that the routable address would have been a better choice
for the source address.

> can be accomplished by a host with a only a v4LL address that also don't
> prove that the destination host is v4LL capable.

that's false.  any app that does referrals can refer an LL address, either
deliberately or because it doesn't know better than to not do so.
 
> > No, because even a host that doesn't know how to configure its own LL
> > address can still be programmed or configured to ARP for an LL address,
> > and it's probably desirable for hosts to do so.
> 

it's been argued that you can configure a UNIX box to arp for LL addresses on
a link.  have you tried it yourself?

Keith

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 9 Feb 2003 16:09:58 -0800 (PST)

> it just means that the routable address would have been a better choice

Absolutely. We agree that if the source host has a routable address, it
should use that instead. This is about the situation in which it *doesn't*
have a routable address -- just a v4LL one.

The question is whether it is  possible to communicate between hosts with
*only* a routable address, and hosts with *only* a v4LL address. I believe
that this is valuable -- because there can be simple devices that will
only want to use v4LL addresses even when a DHCP server is available. If
they can't communicate with hosts with routable addresses, then they would
have to obtain a routable address -- and they may not want one.

> deliberately or because it doesn't know better than to not do so.

Say a host with a routable address gets a referral to a v4LL address, then
attempts to contact a host at that address. If the host was not v4LL
capable, then it will send the packet to the gateway and it will go
nowhere. However, if the host is v4LL capable then it will ARP for the
v4LL address and possibly deliver it. In that case, the host has
demonstrated that it is v4LL capable.

So your counterexample doesn't work.

Care to try another one?

> a link.  have you tried it yourself?

The point is that it isn't configured this way out of the box. And I'd
argue that it shouldn't be if the box doesn't support v4LL.

---

From: Keith Moore <[email-masked]>
Date: Sun, 9 Feb 2003 21:55:40 -0500

On Sun, 9 Feb 2003 16:09:58 -0800 (PST)
Bernard Aboba <[email-masked]> wrote:

> only want to use v4LL addresses even when a DHCP server is available. 

such devices should not be permitted by the standard.  period.

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 9 Feb 2003 18:18:47 -0800 (PST)

> such devices should not be permitted by the standard.  period.

Then the standard should say so explicitly.

---

From: Alex Karahalios <[email-masked]>
Date: Mon, 10 Feb 2003 00:56:04 -0700

Hi Keith,

I guess putting the word "period." at the end of your sentence makes it 
more definitive ;) But I think the standard should permit such simple 
devices. Not every device has the luxury of implementing a DHCP client. 
And there is no requirement for a DHCP server on an IP network. There 
are many cases for simple IP devices coexisting with more complex ones.

For example, in HVAC control, devices can communicate with each other 
using v4LL addresses and be oblivious of a DHCP server. Usually a 
machine is set up as a master controller that communicates with the 
devices and a more global scoped IP network. These devices may be 
physically on the same network cable as other full fledged IP devices, 
although logically they only see each other.

Alex Karahalios

---

From: Robert Elz <[email-masked]>
Date: Mon, 10 Feb 2003 16:03:15 +0700

Date:        Sun, 9 Feb 2003 15:15:52 -0800 (PST)
    From:        Bernard Aboba <[email-masked]>
    Message-ID:  <[email-masked]>

  | It's very relevant -- because my claim is that there are no ways that this
  | can be accomplished by a host with a only a v4LL address that also don't
  | prove that the destination host is v4LL capable.

That's obviously not true.

One way is that I type "ifconfig -a" (or some other OS equivalent)
on the system I am intending to be the destination, notice an address
assigned to the network interface, swivel in my chair, and type

	telnet ip.add.re.ss

on the other system.

Not all IP address discovery uses any kind of network protocol.

For ad-hoc type connectivity, this kind of communication is actually likely.
Eg: someone comes into my office with a system, connects to my local LAN,
and asks me "tell me your IP address and I will send you this file", so
I do just that.   My IP address is a global/routable one, but being an unknown
outsider, my DHCP server didn't give him an address, so he's just got a
LL address.   In this scenario whether my system is LL aware or not is
completely unknown.

kre

---

From: Robert Elz <[email-masked]>
Date: Mon, 10 Feb 2003 16:14:14 +0700

Date:        Sun, 9 Feb 2003 16:09:58 -0800 (PST)
    From:        Bernard Aboba <[email-masked]>
    Message-ID:  <[email-masked]>

  | The question is whether it is  possible to communicate between hosts with
  | *only* a routable address, and hosts with *only* a v4LL address. I believe
  | that this is valuable

So do I.   I take it from this that you're opposing LL19?   That hasn't
been clear in any of your other messages...

The text you proposed in your original message is fine, except the
"MAY choose to ARP" should turn into "MUST ARP".   (That's more or
less LL17, in reverse, and that issue should be discussed under that subject).

  | -- because there can be simple devices that will
  | only want to use v4LL addresses even when a DHCP server is available.

Keith's "such devices shouldn't exist" (whether true or not) is irrelevant
here.   The issue isn't whether a DHCP server is available or not, nor
whether the device is able to, or actually does, request a routable addr, but
whether the DHCP server offers an address to the node.   If the DHCP server
doesn't offer an address, and also doesn't say "don't use LL", then
clearly the node gets an LL address, and that's all it has.

On most established (managed) networks, this will be the normal case for
LL addresses to exist and be used.

There's no reason I can see to prohibit such a device from communicating with
devices which (for whatever reason) don't have a LL address.

Issue LL19 prohibits it.   So, reject LL19.

We don't need to stray into all of the other side issues on this one.

kre

---

From: Markku Savela <[email-masked]>
Date: Mon, 10 Feb 2003 11:32:37 +0200

If I have an interface configured with three addresses (and nets)

  10.0.0.1 10/8
  169.254.2.3 169.254/16
  global-addr global/net

then, if I'm connecting to 10/8 destination I want my source address
to be 10.0.0.1, and for global destination the source should be
global-addr. This appears to be the way my linux works, and this is
how I use it at home (I want my internal connections between home
machines to use 10/8 addresses, even if each of them has also global
address).

Why should 169.254/16 be anything different and require exception
handling in the source address selection? If destination is in
169.254/16, the source should be also 169.254.2.3 (if host has a
matching address).

Picking an ip.ad.re.ss which happens to be LL from host and trying

  telnet ip.ad.re.ss

on other host will fail miserably, if ip.ad.re.ss is LL, unless "other
host" is also LL aware and has 169.254/16 onlink route
installed. (Similar failure occurs with 10/8 addresses, LL brings
nothing new to the situation).

---

From: Erik Guttman <[email-masked]>
Date: Mon, 10 Feb 2003 10:45:15 +0100 (CET)

Markku,

[WG cochair hat on]

Do you accept issue 19 or reject it?  (Please state this!)

[WG participant hat on]

Note that LL1 would prefer the a non-LL address and LL17 would enable
a host with a non-LL address to communicate with a LL device.  We are 
discussing changing (conforming) hosts.  Thus, the argument that Linux 
works a certain way (today) is not very cogent.

Erik

-----

> If I have an interface configured with three addresses (and nets)

._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._.
 E r i k   G u t t m a n                        
 N1 Installation and Provisioning               cell: +49 172 865 5497 
 Sun Microsystems                     pager: [email-masked]

---

From: "Philip Nye" <[email-masked]>
Date: Mon, 10 Feb 2003 10:44:56 -0000

> From: "Bernard Aboba" <[email-masked]>
>
> attempts to contact a host at that address...
> ... if the host is v4LL capable then it will ARP for the
> v4LL address and possibly deliver it...

It will also possibly deliver it to a fourth host which just happens to have
the same LL address but an another link (a different scope)!

I'm not a security expert but isn't there a possible arcane new mechanism
for attack from off-link here?

Philip

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 10 Feb 2003 04:52:39 -0800 (PST)

> assigned to the network interface, swivel in my chair, and type

Actually, this is also not a counter-example. If TCP actually
completes the three-way handshake, then the system on which you typed
telnet 169.254.X.Y supports LLv4. If it didn't, the TCP SYN would have
been sent to the gateway and routed off into nether-space.

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 10 Feb 2003 04:54:39 -0800 (PST)

> been clear in any of your other messages...

Yes, I oppose LL19.

> less LL17, in reverse, and that issue should be discussed under that subject).

Yes.

> clearly the node gets an LL address, and that's all it has.

I agree.

---

From: Keith Moore <[email-masked]>
Date: Mon, 10 Feb 2003 09:39:33 -0500

On Mon, 10 Feb 2003 04:52:39 -0800 (PST)
Bernard Aboba <[email-masked]> wrote:

> telnet 169.254.X.Y supports LLv4. 

not necessarily.  it could have been configured to ARP for that prefix.
or it could be programmed to ARP for that prefix even if it could not
configure an LL address by itself.

as far as I can tell it would be a good idea to recommend that v4 hosts
arp for LL addresses even if they don't have code to configure LL addresses. 
That would allow them to communicate with hosts that, for whatever reason,
don't have a routable address.  however I want to think more about the
multiple interface case before I'm confident of that. and I wonder how many
platforms would "partially" implement LL rather than doing either all or
nothing.

---

From: "Philip Nye" <[email-masked]>
Date: Mon, 10 Feb 2003 15:49:14 -0000

> From: "Robert Elz" <[email-masked]>
>

Given that the text also says you MUST NOT forward to a router what is the
alternative(s) suggested by "MAY choose to ARP"? Without rewording, the only
alternative I can see is to drop the packet so I don't think the rewording
is as big an issue as you suggest.

Philip

---

From: Thomas Narten <[email-masked]>
Date: Mon, 10 Feb 2003 08:13:03 -0500

Question: to what degree is the above supported by existing IPv4
clients? Granted, I don't doubt linux supports this, but there are no
IETF documents AFAIK that talk about IPv4 devices needing to support
multiple addresses per interface and all the details that implies. I
suspect that many plaforms don't, or do it in an ad hoc way. We (in
this WG) are not going to change that.

In IPv6 we've specified the desirable behavior for multiple addresses
on an interface, and it's fairly complicated. There is an entire
document on address selection rules
(draft-ietf-ipv6-default-addr-select-09.txt), for instance.

I don't believe we want to have to do the equivalent of that document
for IPv4 as part of specifying LL addresses.

What I think we're trying to do here is make LL addresses work
reasonably well with one other global address, since we expect that to
happen at times, even if we don't really want that to be the normal
(or recommended) behavior. Certainly, we want the intended behavior to
be clear, if a device has only a LL address and attempts to
communicate with a device having only a non-LL address.

> 169.254/16, the source should be also 169.254.2.3 (if host has a

Because we don't really have general address selection rules for IPv4,
and we probably don't want to go there.

Thomas

---

From: Keith Moore <[email-masked]>
Date: Mon, 10 Feb 2003 11:27:14 -0500

> I guess putting the word "period." at the end of your sentence makes
> it more definitive ;) But I think the standard should permit such
> simple devices. Not every device has the luxury of implementing a DHCP
> client.

I strongly disagree.  IETF's job is to explain how hosts and apps can
interoperate.  Standardizing crippled behavior does not facilitate
interoperation.  If implementing enough of DHCP to allow a device to
acquire a routable address, a netmask, and a default route is too
onerous, then we need another mechanism - but other people have claimed
that this burden is not unreasonable.  But we do not need to standardize
dysfunctional behavior.

Here's how I would phrase it.  Every device that expects to be able to
automatically configure itself MUST support DHCP, and MAY support v4LL.

A device that expects to be manually configured MAY support an
option to be configured by DHCP, and MAY support an option to be
configured by v4LL.

Of course, nothing stops a device vendor from implementing only v4LL. 
But they shouldn't be able to claim that IETF said it was okay to do
that.

Keith

---

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

> platforms would "partially" implement LL rather than doing either all or

If you put this in the specification you're sending people a message
that it is standard operating procedure to have v4LL-only nodes as part
of routed networks and configure servers to listen at v4LL addresses.

It would be much better to just restrict v4LL addresses for
communication with other nodes that have v4LL addresses. Nodes on routed
networks should use routable addresses, always.

	MikaL

---

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

> this WG) are not going to change that.

There is nothing particularly hard about supporting multiple addresses
per interface in an implementation. We could require that all v4LL
compliant nodes must support this.

I agree that you're not going to change this for non-v4LL compliant
nodes. There will be a *lot* of such nodes around, no matter what this
specification states. Such nodes will be able to communicate with
v4LL-only nodes only if you're lucky, i.e., only if they support manual
configuraton of a 169.256/16 route and only if someone has happened to
do so.

Therefore, a v4LL address should never be used as source address when
connecting to a routable address. There is simply no reliable way to
know whether the target node will be able to respond.

> (draft-ietf-ipv6-default-addr-select-09.txt), for instance.

Well, that particular draft is overly complex, no disagreement there. We
don't need to replicate that. A simple equivalent of the longest prefix
match algorithm will suffice.

> for IPv4 as part of specifying LL addresses.

Making the rules extremely simple and predictable is what LL19 is all
about.

Single rule: the scopes of source and destination addresses MUST match

This makes the possible failure modes extremely simple to understand. 
Mixing LL addresses with routable addresses, on the other hand, creates
a much more complex situation with a bunch of different failure modes
that can cause intermittent connectivity problems.

> (or recommended) behavior.

I think that philosophy is flawed. We should make it crystal clear, in
which situations it is safe and appropriate to use v4LL addressing and
in which not.

>  Certainly, we want the intended behavior to

The behaviour will soon come clear to the user: it often won't work.

> and we probably don't want to go there.

Source and destination scopes MUST match.

	MikaL

---

From: Keith Moore <[email-masked]>
Date: Mon, 10 Feb 2003 15:29:26 -0500

On 10 Feb 2003 21:15:32 +0200
Mika Liljeberg <[email-masked]> wrote:

> > as far as I can tell it would be a good idea to recommend that v4
> > hosts arp for LL addresses even if they don't have code to configure
> > LL addresses. That would allow them to communicate with hosts that,
> > for whatever reason, don't have a routable address.  however I want
> > to think more about the multiple interface case before I'm confident
> > of that. and I wonder how many platforms would "partially" implement
> > LL rather than doing either all or nothing.
> 
> that it is standard operating procedure to have v4LL-only nodes as
> part of routed networks and configure servers to listen at v4LL
> addresses.

I don't think so, because for a variety of reasons other than
v4-only hosts v4LL and routable addresses will co-exist on the same
network. but this probably does need explaining somewhere.

> communication with other nodes that have v4LL addresses. Nodes on
> routed networks should use routable addresses, always.

it won't happen unless you can figure out how to instantly reconfigure
everything when the DHCP server comes back up.

Keith

---

From: Markku Savela <[email-masked]>
Date: Tue, 11 Feb 2003 12:11:06 +0200

[changed the topic on this reply]

In short: if LL19 is rejected, then LL1 is not acceptable either.

> From: Thomas Narten <[email-masked]>
>
> Because we don't really have general address selection rules for
> IPv4, and we probably don't want to go there.

I'm looking this issue from already implemented IPv6/IPv4 stack, which
does have address selection code (e.g. select LL source for LL
destination, even if it also has global IPv4 addresses).

To avoid "code bloat", IPv4 is handled as true subset of IPv6,
exceptional handling IPv4 case is minimized.

It is unacceptable that ZEROCONF RFC would make this suddenly
"illegal".

The "SHOULD NOT" in requested change of [L1] is too strong.

---

From: Keith Moore <[email-masked]>
Date: Tue, 11 Feb 2003 12:01:32 -0500

I disagree.  first because v6 source selection is broken and we should
not propogate this error; second because the issues are different for v4
and v6 source address selection.  v6 does not have the backward
compatibility problem that v4 does.