Subject: Oppose: LL1 Preferred use of configured to v4 LL address

From: Stuart Cheshire <[email-masked]>
Date: Sun, 23 Feb 2003 14:00:30 -0800

I do not support requiring the host to always use its "global" address, 
if it has one.

There are a number of problems with this:

1. How does the host know what address is truly global? What about 
addresses that are being translated by a NAT gateway? Saying, "This 
Working Group refuses to acknowledge the existence of NAT because there 
is no IETF standard for NAT," is not of any practical use to companies 
that are trying to sell products to real customers in the real world. 
Like it or not, the fact is that in today's world, all IPv4 addresses are 
scoped, with no reliable programmatic way to tell what scope each has. At 
least with v4LL addresses, the scope is clearly defined.

2. What about stale DHCP addresses, or manually configured addresses that 
are just plain wrong? People have said that it is outside the charter of 
this Working Group to try to make devices that work reliably even in the 
face of accidental misconfiguration. That may be true, but developing 
devices that work reliably even in the face of accidental 
misconfiguration is a high priority for Apple, and most of the consumer 
electronics companies adding networking to their home Hi-Fi equipment. 
This Working Group should give at least some small consideration to those 
companies.

The benefit of sending a packet with a v4LL source address to a 
v4LL-compliant peer is that the peer will always reply directly back to 
you, because all v4LL addresses are defined to be on-link. There is no 
way for the peer to be accidentally misconfigured, because you can't have 
a configuration error when there is no configuration. (This is the point 
of "zero configuration".)

If you send a packet with a routable address, then whether the peer 
replies to you can be dependent on things like whether that peer has the 
correct subnet mask set, what routing table entries are present, etc.

Possibly it may make sense to attempt a connection first using the 
routable address first, and then, if that fails, after a short interval 
(half second?) try with the LL address as well.

Stuart Cheshire <[email-masked]>
 * Wizard Without Portfolio, Apple Computer, Inc.
 * www.stuartcheshire.org

---

From: Robert Elz <[email-masked]>
Date: Tue, 25 Feb 2003 19:23:08 +0700

Date:        Sun, 23 Feb 2003 14:00:30 -0800
    From:        Stuart Cheshire <[email-masked]>
    Message-ID:  <[email-masked]>

  | 1. How does the host know what address is truly global?

LL1 is badly worded.   It means "routable" in the same sense that is
used in the document (where I would actually prefer to say "non-link-local"
in all uses for extra clarity, as routable suggests other things in
many minds).   But this just amounts to definitions of terms, and isn't
very important.

I'd reject LL1 just because (IMNSHO) LL23 achieves the same objective,
better.

  | 2. What about stale DHCP addresses, or manually configured addresses that 
  | are just plain wrong?

My opinion is that a node with a "wrong" address has no address, and can go
on to assign a LL address (unless LL2 mechanisms tell it not to).

  | People have said that it is outside the charter of 
  | this Working Group to try to make devices that work reliably even in the 
  | face of accidental misconfiguration. That may be true, but developing 
  | devices that work reliably even in the face of accidental 
  | misconfiguration is a high priority for Apple, and most of the consumer 
  | electronics companies adding networking to their home Hi-Fi equipment. 
  | This Working Group should give at least some small consideration to those 
  | companies.

That's fine, I wouldn't like to do anything that makes this impossible.

But for me, home Hi-Fi equipment that doesn't work (fully) using routable
addresses (in the sense defined in the draft) is plain useless.

That said, I also accept the responsibility that if I arrange to
configure addresses for that equipment, it is my job to get it correct.
I do not want the nodes attempting to outsmart me.   If they are
misconfigured, I want them to fail, so I can easily detect that they
are misconfigured.   I don't want them ignoring me, and going on and
doing their own thing anyway, seemingly working.   When that happens I
end up with a half-functional network, which makes it truly difficult
to discover that I made a stupid typo in some configuration.   If the
device simply failed to work as soon as I configured it, then I'd have
a pretty good chance of realising that I was the cause, and so fix
my error.

In your more average house though, there is likely to be nothing doing
any configuration, LL gets used, and everyone is happy.

If there is any config happening, then it is most likely from one of
those "turn me on and I do DHCP" boxes that are common these days,
which are basically designed to never give out bad information (they
tend to have very little config info that the user can play about with,
they just give addresses in the same (1918 usually) range to anyone who
asks).

  | Possibly it may make sense to attempt a connection first using the 
  | routable address first, and then, if that fails, after a short interval 
  | (half second?) try with the LL address as well.

The question here might be, how did you discover the peer's address
in the first place?    Does it have a LL address or a routable one,
and which was advertised to you?

If you contact it using its LL address, then it knows that you are
on link, and can (must) reply to you directly (if it is LL aware, if
it isn't, all of this is irrelevant anyway).

If you (attempt to) contact it using its routable address, then how
do you tell the difference between its config being incorrect, and yours?
You might be sending to some bogus location in each case.  Trying again
using a LL source address doesn't help.

kre