Subject: Re: Turning off link-locals?

From: Ian Lister <[email-masked]>
Date: Tue, 21 Jan 2003 15:46:19 +1000 (EST)

On Tue, 21 Jan 2003, Keith Moore wrote:
>On Tue, 21 Jan 2003 14:46:24 +1000 (EST) Ian Lister <[email-masked]> wrote:
>> On Mon, 20 Jan 2003, Keith Moore wrote:
>> >rendezvous is a disaster.
>>
>> Oh good, then you'll be able to point to specific things that it has
>> broken.
>
>I've already listed several specific problems with LL addressing.

You have gone on and on about two problems:

1. Use of IPv4LL addresses on hosts with assigned addresses allegedly
   `breaks' applications. You listed a few, but I don't see how IPv4LL
   breaks any of them. You identified address referral as a major source
   of potential breakage, but automatic address referrals work because
   they typically use the likes of getsockname() to determine an address,
   and manual address referrals (e.g. configured lists of hosts to use in
   distributed systems) only break if somebody manually refers IPv4LL
   addresses.

   Rendezvous does not assign IPv4LL addresses when other (DHCP or static)
   addresses are available, so clearly you are not referring to this
   alleged problem anyway.

2. A host without an administratively assigned address can still
   communicate with hosts with such addresses. While most consider this a
   feature, you have argued that in some contexts the inability to
   communicate may be used as a socially enforced security measure, and
   that the IETF should support this use.

   Rendezvous allows hosts to be configured so as not to communicate with
   IPv4LL-only hosts on the network - simply remove the 169.254.0.0/16
   entry from the routing table.

So, which problems with Rendezvous are you referring to? Any relating to
IPv4LL at all?

>the problems with name lookup are matters for other WGs.

Acknowledged.

Ian

---

From: "Philip Nye" <[email-masked]>
Date: Tue, 21 Jan 2003 11:32:47 -0000

> From: "Ian Lister" <[email-masked]>
>

Keith has pointed up two genuine protocol level issues and I will try and
summarise them again and why they are particular to v4LL:

1. Scoped addresses.

Given an interface with two addresses, which one does an application use? In
the traditional case, it doesn't matter much but in the case where one
address is of limited scope it does. This still doesn't cause much trouble
in a straight two way exchange but in a three way exchange (a referral) the
only way to solve the problem seems to be for the app to be aware of address
scoping (which many such apps are not).

Hitherto, scoped addresses are manually configured (either at the host or
the network level) and so the limitations are implicitly accepted when
configuring that way. Mandating that LL be on by default means that scoped
addresses will be present whether the limitations are accepted or not.

So far I have seen no rebuttal to this issue except to deny its existence,
to insult Keith (who can be pretty forthright himself), or to blame those
who write those apps - none of which are appropriate responses.

2. Security

Any host using v4LL on two interfaces has trouble knowing which interface to
route LL packets to as discussed in section 3 of the draft. As the solutions
to this involve defending addresses on all interfaces the interfaces are no
longer fully independent. This opens a new vulnerability where access to one
link allows attacks on an adjacent one.

In both these cases some might argue that the scale of the problem is small
and the benefit of v4LL is great so that the disadvantages are acceptable.
However, denying the problem is not the same thing and the argument would
have to be backed with some hard information anyway.

The option to turn v4LL off when a global address is present in a flexible
way (via a DHCP option or by Erik N's strawman protocol) goes a long way to
answering these issues:

It does not prevent communication (on the local link) between hosts with
global addresses and those with LL; It ensures that configuration can
override the default behaviour of those hosts which are capable of obtaining
and using global addresses; It presumes that hosts which can only use LL
addresses implicitly accept the limitations. It would even be possible for
the draft to place explicit limitations on LL only hosts such as "no apps
requiring referrals" or "no multiple interfaces".

For a while I thought these discussions were getting somewhere but then the
mudslinging prevailed - at least it is familiar!

Philip Nye

---

From: "John C. Welch" <[email-masked]>
Date: Tue, 21 Jan 2003 07:06:55 -0500

> who write those apps - none of which are appropriate responses.

Actually, if an application is ignoring OS services, and bypassing APIs
because the writer wishes to be clever, I find it wholly appropriate to lay
the blame on the developer.

Right now, if you have a multiple addresses on a single interface, how does
it get handled? There are a number of issues.

1)  Does the application even care? If it's a client, 99% of the time, it
doesn't. It connects to a server via OS services. Fetch doesn't know which
interface it's using. I tell it to connect to ftp.tackyshirt.com, and if
either interface can make that connection it does. If either interface has
multiple addresses, it *still* doesn't care. In other words, it's going to
use the OS services to communicate with an interface. Which one, which
address is immaterial, as long as it can make the connection. If it can't,
you get a user error, and you go from there. If a client is binding to a
specific address at a specific interface, it's a bug, not a feature.

2)  The application cares about addresses. It's a server, it's listening at
a given address on a given port. Note the lack of interface in the preceding
sentence. Why? Because it's immaterial, or it should be. The application has
no business binding to a specific interface, and I have yet to see an
argument that says it should in this case. If it does, what happens when an
interface is added or removed? You have to reconfigure the app. Again, this
is a sign of the developer getting 'cute', and should be treated as a bug.
If this seems harsh, well, that's how overly clever developers need to be
treated. In any event, the OS handles the routing services to ensure that
the right packets get to the interface on the right address/port. If it
can't, then the OS has a bug, and needs to be fixed, and in the meantime,
another OS should be used.

3)  The application *does* care about addresses and interfaces. Packet
sniffers, config utilities, etc. So now we hit the cases that will be most
affected by it. I really don't see this as being an issue. Simple human
greed bears this out. If you are a commercial entity, then you'll update to
handle this, or go out of business. If you are a non-commercial entity, then
if you don't update, someone else will, and no one will use your app. Either
way, it's going to get fixed.

I'm amazed that no one has thought to actually test this beyond relying on
data from Apple's shipping code, especially the people screaming doom. Real
data taken over time is more compelling than any theoretical fears.

> link allows attacks on an adjacent one.

Right. But this is not a major problem, unless you have an insecure network
anyway. If you do, LL is not your problem, you have far greater problems.

> have to be backed with some hard information anyway.

Who can tell. I've yet to see hard info from either side.

> requiring referrals" or "no multiple interfaces".

Well, those limitations will be ignored if a vendor has a customer need. We
all know this, or should. Turning LL off is a bad idea unless you *require*
two things:

1)  Obvious, continuing and annoying user notification that you've just
killed a service they assume is working. Stealth DOS configs, (and that's
what killing LL is), are not acceptable to the humans. So when the computer
is powered up, woken up, or the network link is changed, the the user MUST
be notified, with no options to not notify.

2)  There HAS to be a timer on this. No killing LL until some random service
tells it to come back on. The signal to stay off must be resent at regular
intervals. That way, the user is not at home, off the "No LL" network, and
now unable to communicate with their home LL devices. Additionally, there
MUST be a manual way to re-enable LL as a backup to the timer.

Not that turning off LL solves anything other than the fears of app and OS
developers who don't want to update code, but at least it's not as onerous.
This makes it...acceptably silly.

As well, has anyone thought about manual configs here at all, or are we all
assuming that the entire world uses DHCP?

john

-- 
John C. Welch
Consultant III
Administrative Computing
(617) 253 - 1368 work
(508) 579 - 7380 cell
bynkii2          AIM

---

From: John Schnizlein <[email-masked]>
Date: Tue, 21 Jan 2003 07:30:11 -0500

At 07:06 AM 1/21/2003, John C. Welch wrote:
>...

Is my impression that the goal of the ZeroConf WG is to minimize manual configuration not universally shared? It seems the pursuit of particular mechanisms such as link-local (IPv4 auto-generated) addresses has taken precedence for some arguments.

The practical fact is that DHCP does reduce manual configuration today, and people are working to make it easier to operate while maintaining its ability to provide host configuration in compliance with local policy and the existing address structure of the Internet. It would be a mistake to invent new mechanisms that circumvent local policy because the host (actually vendor of the host operating system) does not like to be bound by local policy.

John

---

From: Keith Moore <[email-masked]>
Date: Tue, 21 Jan 2003 08:42:32 -0500

> the blame on the developer.

it's infeasible for an application writer to "bypass APIs".  they're merely
choosing which APIs to use.  or do you really think they're shipping their own
kernel mods?

as for the rest of your message, all I can say is that John Welch's opinion
about what is proper programming and what is appropriate security are not good
justifications for screwing the installed base.

---

From: Scott Lawrence <[email-masked]>
Date: 21 Jan 2003 09:41:50 -0500

John Schnizlein <[email-masked]> writes:

> The practical fact is that DHCP does reduce manual configuration
> today, and people are working to make it easier to operate while
> maintaining its ability to provide host configuration in compliance
> with local policy and the existing address structure of the
> Internet. 

My mother-in-law will _never_ learn to run a DHCP service, no matter
how long you work on it.  Let's not loose sight of the fact that this
is true of _most_people_; just because we think it's easy doesn't make
it easy for them.  The goal of enabling zero-configuration networks is
a good one, _even_though_ there are some things they won't be able to
do as well as configured ones.  That includes possibly not being able
to communicate with global Internet services as well.

> It would be a mistake to invent new mechanisms that
> circumvent local policy because the host (actually vendor of the
> host operating system) does not like to be bound by local policy. 

It's not about circumventing policy - it's about providing a mechanism
for those cases in which there _is_no_policy_ because the ordinary
people who own the network don't know an IP address from a PO Box.  

The notion of 'disabling' or 'preventing' LL by sending some
contra-indication on the network, whether DHCP or something else, is
silly - no sensible network administrator would trust that to work.
If nothing else, there are already lots of systems deployed that do
some variation on LL that won't be inhibited by it.  If an
administrator really doesn't want any LL packets on the network, they
are going to have to sniff for them or set filters to impede them, or
be otherwise inventive - just as they must do now if they want to
prevent Appletalk or Netbios or whatever protocol they dislike most.
Putting a rule about this in our spec won't change that.

The simple fact is that vendors are going to provide products for
ordinary people who don't understand addressing and don't want to,
because there are a _lot_ more of them than there are of us.  We can
accept that, and use the IETF to help to ensure that the way that they
do it is interoperable at least within the local scope, and its
limitations are well understood; or we can just sit here and compose
email about how bad it is and they'll do it less well without us (hint
- this is what has been happening for the last few years).  I don't
think that we should be even trying for a perfect world - getting
there is too slow, and the goal keeps moving.  Find solutions that
work - make sure they don't mess up things that are already there -
improve them as you go along; I don't think LL violates these
principles because the cases that have been cited so far that it
'breaks' are cases that only work now on networks that already have
global addressing - not the target for LL at all.

---

From: "Philip Nye" <[email-masked]>
Date: Tue, 21 Jan 2003 14:50:53 -0000

> From: "John C. Welch" <[email-masked]>

> ... There are a number of issues.
>
> doesn't. It connects to a server via OS services...
>
> a given address on a given port...

These demonstrate the reasons why this "doesn't cause much trouble in a
straight two way exchange" which is what I said. The issue in a three way
exchange is that the OS cannot know the scoping and routing of a third
party - it simply has a host address. That address may be OK for the first
and second parties but not so for a third party. Such applications exist and
work.

> way, it's going to get fixed.

So the solution you are advocating is to update those applications which
currently work but will be broken by v4LL.

This is possible, but the issue goes beyond simply updating applications IF
you want them to work with v4LL because with v4LL turned on all the time it
will intrude even on those who don't care about it and would rather use
manual configuration and not re-write their apps (assuming they could).

Secondly, this presupposes that such an update is possible. I am not at all
sure that that is the case with third party referrals such as happen in many
distributed processing schemes - at least not without a means to discover
the scoping of any arbitrary address and to discover alternative addresses
where necessary.

The simple guarantee that v4LL can be turned off in the presence of a
configured address means that there is at least a choice as to which should
work. Not allowing v4LL to be turned off denies that choice.

> Well, those limitations will be ignored if a vendor has a customer need...

Or we could try and overcome the limitations.

> ... Turning LL off is a bad idea unless you *require*
> two things:
>

Sorry to be dense but I don't understand this. When you say "killed a
service" do you mean by simply changing an IP address? or do you mean
something else?

> tells it to come back on.

If the signal to turn v4LL off is implicit in being assigned another address
then it would last as long as that other address. If that assignment is DHCP
then there is a timer (lease expiry) and a manual option (manually attempt
to renew the lease). If that assignment is static then you are into user
level configuration and the world is your oyster.

Either of the two suggestions (DHCP option or Erik's "strawman") add the
ability to turn LL on _despite_ there being another address and they would
both be subject to a timer.

> developers who don't want to update code,...

Or of users who have no ability to update code and also have little control
over what is happening in the OS but who have working applications now. It
would be disingenuous to suggest that such people shouldn't update their
OS - they frequently have no option.

Philip Nye

---

From: Keith Moore <[email-masked]>
Date: Tue, 21 Jan 2003 10:00:56 -0500

On 21 Jan 2003 09:41:50 -0500
Scott Lawrence <[email-masked]> wrote:

> how long you work on it.  

That's an odd statement.   There are a number of home network routers and NAT
boxes out there that provide DHCP by default, and it never needs to be
configured.  Hosts that try DHCP by default just work, they never need to be
configured.  The only thing the user needs to avoid is having multiple routers
on the same network, due to current limitations of DHCP.  But even this could
be fixed in time.

> Let's not loose sight of the fact that this

The goal is a good one.  But if the resulting service is so dysfunctional that
it impairs the ability of much of the Internet to support applications, then
the technology which is supposed to implement that goal is not a good one. 

Just because we acknowledge that the goal is good, and just because LL has
been
hashed out in the context of a working group named "zeroconf" does not mean
that LL is a constructive step toward usable zero configuration networks.

> people who own the network don't know an IP address from a PO Box.  

The same device can either be hooked to a network where there is no policy, or
to a network where there is policy.  The question is, how does the device tell
the difference and do the appropriate thing in each case?

> silly - no sensible network administrator would trust that to work.

It's no more silly than having DHCP assign impaired addresses, or having DHCP
refuse to assign addresses, and lots of networks place some degree of "trust"
in that.  We all acknowledge that this has limited security value, but some
networks still find it useful.

> some variation on LL that won't be inhibited by it. 

Those are not in our purview.  This WG is discussing what the standard version
of LL will require.

> If an administrator really doesn't want any LL packets on the network, they

It's about minimizing cost and complexity.  If the vast majority of platforms
out there will honor an indication from the network to not use LL, then we
won't need bridges and hubs to filter out LL traffic.  If the platforms don't
do that, then more sites will need filtering bridges and hubs, and this will
cost more.  Similarly, if sites don't have a way to keep LL from breaking
their applications, then the applications will have to be modified to be
configurable to either ignore LL addresses or not, and this will cost money,
and it will increase the burden on users. OTOH if this WG does its job
responsibly then the impact can be minimized.

> do it is interoperable at least within the local scope,

Having things interoperate only "within the local scope" does not meet the
requirements of RFC 2026.  Furthremore the introduction of scoped addresses
into IPv4 changes the behavior of existing interfaces and thus will break
programs that expect to work in the global scope.

>  I don't

Your last statement is only true if LL only affects isolated networks.  If
this were the case I wouldn't be objecting to LL.  But LL as currently
specified affects all networks.  And there are some people here who believe
the "target" for LL is all networks because they want an easier way to
configure plug-and-play devices than DHCP.

Keith

---

From: "John C. Welch" <[email-masked]>
Date: Tue, 21 Jan 2003 10:09:11 -0500

On 01/21/2003 07:30, "John Schnizlein" <[email-masked]> wrote:

> Is my impression that the goal of the ZeroConf WG is to minimize manual
> configuration not universally shared? It seems the pursuit of particular
> mechanisms such as link-local (IPv4 auto-generated) addresses has taken
> precedence for some arguments.
> 
> The practical fact is that DHCP does reduce manual configuration today, and
> people are working to make it easier to operate while maintaining its ability
> to provide host configuration in compliance with local policy and the existing
> address structure of the Internet. It would be a mistake to invent new
> mechanisms that circumvent local policy because the host (actually vendor of
> the host operating system) does not like to be bound by local policy.

Manual configs are still a reality, and will be forever. Reasons are
unimportant for this WG. So we need to deal with it in an intelligent
fashion, and it raises some different issues.

john

-- 
John C. Welch
Consultant III
Administrative Computing
(617) 253 - 1368 work
(508) 579 - 7380 cell
bynkii2          AIM

---

From: "Philip Nye" <[email-masked]>
Date: Tue, 21 Jan 2003 15:17:56 -0000

> From: "Scott Lawrence" <[email-masked]>
>

DHCP raises the configuration from the host level to the network level. This
is often very useful but not always the right thing hence John's comments.
However, a locally configured address implies that the user rather than the
network administrator is performing manual configuration and the implication
is that they could also re-enable v4LL if required.

> how long you work on it...

The scenario is this: if your mother-in-law plugs her machine into a managed
network, it is assigned an address by DHCP and so far as she is concerned
"it just works". If it is an unmanaged network v4LL steps in and again "it
just works".

If she plugs into a managed network which denies her access, this is
presumably the intent of the network manager. In the unmanaged network this
will not happen (unless there is a malicious host denying access which could
happen in either case).

> some variation on LL that won't be inhibited by it.

So far as I can tell, recent versions of Mac OS are the only ones which do
not quietly disable v4LL if they get a DHCP address (or a static one).

> ... or we can just sit here and compose
> - this is what has been happening for the last few years).

So what is wrong with the scenario above? Why should your mother-in-laws
machine insist on grabbing a LL address even though it has another perfectly
good one and the network has asked it not to use LL?

Philip Nye

---

From: "John C. Welch" <[email-masked]>
Date: Tue, 21 Jan 2003 10:17:40 -0500

On 01/21/2003 09:50, "Philip Nye" <[email-masked]> wrote:

>> 2)  There HAS to be a timer on this. No killing LL until some random
> >service tells it to come back on.
> 

Static configs are why LL needs to be able to be on all the time. DHCP
leases can be quite long, and are therefore an unacceptable timer.

> both be subject to a timer.

But who runs the timer. It needs to be, "Unless I get a signal to keep LL
off, then it comes back on", and something on the scale of a DHCP lease is
not fast enough.

> OS - they frequently have no option.

Then the people in charge of those updates need to be on top of changes. We
can't do anything about that, and shouldn't try.

john

-- 
John C. Welch
Consultant III
Administrative Computing
(617) 253 - 1368 work
(508) 579 - 7380 cell
bynkii2          AIM

---

From: "John C. Welch" <[email-masked]>
Date: Tue, 21 Jan 2003 10:10:55 -0500

> choosing which APIs to use.  or do you really think they're shipping their own

Does the term "undocumented calls" sound familiar? Or the concept of
'hacking'?

john

-- 
John C. Welch
Consultant III
Administrative Computing
(617) 253 - 1368 work
(508) 579 - 7380 cell
bynkii2          AIM

---

From: Keith Moore <[email-masked]>
Date: Tue, 21 Jan 2003 10:23:16 -0500

> leases can be quite long, and are therefore an unacceptable timer.

why?  if the local network policy is that LL is not permitted, then why
shouldn't the time interval on this bit be quite long? 

> off, then it comes back on", 

again, why?  what is the justification for giving LL more preference than the
policies of the local network administrator?

> >> Not that turning off LL solves anything other than the fears of app and
> >OS> developers who don't want to update code,...
> > 
> > Or of users who have no ability to update code and also have little
> > control over what is happening in the OS but who have working applications
> > now. It would be disingenuous to suggest that such people shouldn't update
> > their OS - they frequently have no option.
> 

yes we can.  we can stop trying to break existing facilities in the name of
some misguided idea of progress.

---

From: Keith Moore <[email-masked]>
Date: Tue, 21 Jan 2003 10:29:19 -0500

>  Why should your mother-in-laws

More generally, why shouldn't your mother-in-law's applications, machines,
and networks coexist peacefully rather than interact destructively?   Isn't it
more desirable to have an address configuration facility which is flexible
enough to accomodate diverse needs (managed networks vs. unmanaged), than to
have one which impairs the operation of the network and/or applications and
forces them to work around the limitations of the address configuration
facility (say by filtering LL addresses in hardware or by requiring proxies
for applications)?

---

From: Keith Moore <[email-masked]>
Date: Tue, 21 Jan 2003 10:30:43 -0500

> Does the term "undocumented calls" sound familiar? Or the concept of

yes, I'm familar with both of these. neither of them are apropos here.

Keith

---

From: Scott Lawrence <[email-masked]>
Date: 21 Jan 2003 11:00:54 -0500

> good one and the network has asked it not to use LL?

I didn't mean to imply that it should.  

I do think that we'd serve the needs of users better by making
progress, and, on this issue at least, this working group manifestly
is not doing that (some would obviously say that's a good thing).  I'd
been on this list since the early BOFs, and am just returning from a
hiatus of several months.  I just spent a few days perusing the
archive and reading all the traffic for the last couple of months.  As
far as I can tell, almost nothing has changed in about a year, except
that vendors have shipped another generation or two of systems that
have thier own versions of some LL scheme.

Indeed, the suggested rule from early drafts was that systems should
attempt a DHCP address and not use LL if they get one - a fine
suggestion.  My main points are:

- Such system configuration constraints as "try DHCP first and don't
  use LL if it is present" can in practice be no better than
  suggestions.  We don't write protocol specs that have rules for what
  your nsswitch.conf file MUST be.  We do have rules about documenting
  the implications of poor configuration choices, and I think that is
  where the responsibility of the IETF ends.

- Get done with it and approve _some_ specification, or admit that you
  can't and drop the effort.  In that case, vendors will likely choose
  to standardize somewhere else, or just muddle along as they've been
  doing.  If you think either of those is likely to produce a better
  result than the world has already got, or if you think that you'd
  rather preserve your own integrity and sleep better at night by not
  endorsing any IETF v4LL scheme, ok.  Don't kid yourself that it will
  prevent such schemes from being deployed - that's already history.

I suspect that if this WG had gotten a PS done with the "try DHCP"
suggestion in it, that Apple would have built OSX that way; maybe not,
but now we'll never know.

---

From: "Philip Nye" <[email-masked]>
Date: Tue, 21 Jan 2003 16:03:32 -0000

> leases can be quite long, and are therefore an unacceptable timer.

So is your concern that the DHCP server has turned off LL at work, you now
go home and find your machine no longer works at home because LL is off?

Couldn't the OS attempt a renewal on the lease at this point? It needs to
take action anyway since it is on a different network.

Philip

---

From: "John C. Welch" <[email-masked]>
Date: Tue, 21 Jan 2003 11:36:07 -0500

> take action anyway since it is on a different network.

Or I go to a different subnet that isn't using DHCP, and I just need to
print. Or I have a manual config, but I'm at a different subnet and I just
need to print. Or maybe I just want to print, and I don't want to have to be
a network geek to print to a networked printer.

john

-- 
John C. Welch
Consultant III
Administrative Computing
(617) 253 - 1368 work
(508) 579 - 7380 cell
bynkii2          AIM

---

From: "John C. Welch" <[email-masked]>
Date: Tue, 21 Jan 2003 11:38:23 -0500

> "it just works". If it is an unmanaged network v4LL steps in and again "it

Only if she's using DHCP. Stop making this assumption, it's a bad one.

john

-- 
John C. Welch
Consultant III
Administrative Computing
(617) 253 - 1368 work
(508) 579 - 7380 cell
bynkii2          AIM

---

From: "John C. Welch" <[email-masked]>
Date: Tue, 21 Jan 2003 11:42:19 -0500

> shouldn't the time interval on this bit be quite long?

Because then how do you reset it after you get off that DHCP network. Or the
DHCP server goes down. Or any one of a hundred conditions that no one can
plan for.

> policies of the local network administrator?

Because they have these laptop things...that actually move about. As well, I
haven't seen any safeguards that ensure the off signal is legitimate, and
not some schmuck having fun.

john

-- 
John C. Welch
Consultant III
Administrative Computing
(617) 253 - 1368 work
(508) 579 - 7380 cell
bynkii2          AIM

---

From: "John C. Welch" <[email-masked]>
Date: Tue, 21 Jan 2003 11:43:41 -0500

> yes, I'm familar with both of these. neither of them are apropos here.

It happens all the time. Adobe got bit by this. It will happen, and I no
longer care if someone doing something 'clever' gets broken by LL, or
anything else. 

john

-- 
John C. Welch
Consultant III
Administrative Computing
(617) 253 - 1368 work
(508) 579 - 7380 cell
bynkii2          AIM

---

From: Keith Moore <[email-masked]>
Date: Tue, 21 Jan 2003 11:48:04 -0500

> > So is your concern that the DHCP server has turned off LL at work,
> > you now go home and find your machine no longer works at home
> > because LL is off?
> > 
> > Couldn't the OS attempt a renewal on the lease at this point? It
> > needs to take action anyway since it is on a different network.
> 
> Or I go to a different subnet that isn't using DHCP, and I just need
> to print. Or I have a manual config, but I'm at a different subnet and
> I just need to print. Or maybe I just want to print, and I don't want
> to have to be a network geek to print to a networked printer.

in general, whenever a host moves relative to the network, there's potentially a need to reconfigure that host's interfaces.  LL doesn't, and cannot, change that.

Now if you want to have a way that a host can detect that it has moved, 
that's a potentially useful idea, but it needs to be independent of LL.

Keith

---

From: Keith Moore <[email-masked]>
Date: Tue, 21 Jan 2003 11:58:11 -0500

>   your nsswitch.conf file MUST be.

well, it wouldn't necessarily be out of scope for us to do so.  
if nsswitch.conf had a setting to allow TCP retransmit timeouts to be
changed, changing them would still be a violation of the protocol specs.

at the same time, I haven't seen anyone insisting that local host configuration shouldn't take precedence for whether to use LL; the disagreements are about what the behavior should be in the absence
of local host configuration.

>   can't and drop the effort.  

approving a bad specification is worse than not approving one.  maybe vendors will ship bad code anyway - they often do.  but at least IETF is not endorsing it.  the alternative - for IETF to endorse bad code - makes IETF's endorsement mean nothing and doesn't make the deployment situation any better. 

-- 
I tried enlightenment but it kept crashing.

---

From: "Subrata Goswami" <[email-masked]>
Date: Tue, 21 Jan 2003 08:55:18 -0800

1. Is it possible to make LL independent of DHCP ?
   Yes. As LL only uses addresses 169.254/16, DHCP can keep 
   itself out of handing out those addresses.

2. Is there any responsibility from the infrastructure in LL ?
   Yes, it should let all connected (at the link level) node
   know that it is possible to do LL. One LL node should decide
   to broadcast/multicast (say 169.254.255.255) a response message  
   to a inquery by a LL capable node.....

3. Should the client decide between using DHCP and LL ?
   Yes. If it can do either then let it have the choice, other
   wise the choice is obvious.

4. Is it possible to have two IP subnet running over the same link 
   network ?
   Yes.

5. Can one link  have multiple IP addresses ?
   Yes. It is being used in IPSec VPN's.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of John C. Welch
> Sent: Tuesday, January 21, 2003 8:38 AM
> To: Zeroconf
> Subject: Re: Turning off link-locals?
> 
> 
> > The scenario is this: if your mother-in-law plugs her 
> machine into a 
> > managed network, it is assigned an address by DHCP and so 
> far as she 
> > is concerned "it just works". If it is an unmanaged network 
> v4LL steps 
> > in and again "it just works".
>

---

From: "Philip Nye" <[email-masked]>
Date: Tue, 21 Jan 2003 17:03:07 -0000

...
> Because they have these laptop things...that actually move about...

If you have changed network, then reconfiguration is needed - this applies
with LL too.

Re-configuration in this context does not necessarily mean manual
configuration - most common network interfaces are capable of detecting
disconnection and reconnection which can trigger reconfiguration. In the
case of laptops a simple user interface "rediscover" button is also an
option.

> As well, I

A schmuck can "have fun" with or without this mechanism as has been well
established.

Philip Nye

---

From: "John C. Welch" <[email-masked]>
Date: Tue, 21 Jan 2003 12:10:20 -0500

> case of laptops a simple user interface "rediscover" button is also an

I haven't seen this in either of the two majority desktop OS's. It may be in
some version of Linux somewhere.

> A schmuck can "have fun" with or without this mechanism as has been well

So we make it *easier* because this is a politically correct DOS?

No automatic configuration without notification or authentication.

john

-- 
John C. Welch
Consultant III
Administrative Computing
(617) 253 - 1368 work
(508) 579 - 7380 cell
bynkii2          AIM

---

From: "John C. Welch" <[email-masked]>
Date: Tue, 21 Jan 2003 12:07:06 -0500

On 01/21/2003 11:48, "Keith Moore" <[email-masked]> wrote:

> in general, whenever a host moves relative to the network, there's potentially
> a need to reconfigure that host's interfaces.  LL doesn't, and cannot, change
> that.

I don't want it to. I just want to know that when someone needs to use LL,
they *know* if they can or not. Stealth DHCP signals are bogus.

john

-- 
John C. Welch
Consultant III
Administrative Computing
(617) 253 - 1368 work
(508) 579 - 7380 cell
bynkii2          AIM

---

From: "Philip Nye" <[email-masked]>
Date: Tue, 21 Jan 2003 17:20:40 -0000

> No automatic configuration without notification or authentication.

LL is automatic configuration too!

In the case where a user is using manual configuration, then we are not even
remotely zero-config and have to assume she (or someone advising her) has
some skill and - assuming the option is there - should know whether to turn
LL on or not.

Philip

---

From: "Philip Nye" <[email-masked]>
Date: Tue, 21 Jan 2003 17:26:33 -0000

> is not doing that (some would obviously say that's a good thing).

There has been some progress in that some credible methods have been
suggested for a compromise between the "LL is always on" position and the
"LL always goes off in the presence of another address" positions.

I rather think recent posts have lost sight of this.

Philip

---

From: "Philip Nye" <[email-masked]>
Date: Tue, 21 Jan 2003 17:33:36 -0000

> some version of Linux somewhere.

Interesting. Is there an obvious flaw with attempting to detect whether the
network has changed when a re-connection is detected?

I would have thought that sending a DHCP discovery and possibly a renew
would make sense - as would sending an ARP probe for LL.

For statically configured hosts then pinging (or ARPing) the default route
would be equivalent.

Philip

---

From: Brad Davis <[email-masked]>
Date: Tue, 21 Jan 2003 10:46:43 -0700

> to communicate with global Internet services as well.

You think that millions of households world-wide today know how to run DHCP 
servers?  They still run them.  The server comes pre-configured in those DSL, 
Cable, or Ethernet to Ethernet routers that have been shipping and sold by the 
boatloads over the past few years.  DHCP works for these people, and while it 
may be imperfect, it works well enough that broadband service providers that 
support home networking require DHCP (on by default) and NAT (address being in 
short supply).

The home networking requirements are very different from John Welch's MIT 
requirements.  One major requirement is that all devices that are plugged into a 
home network must be able to talk to every other device on the home network so 
the service provider doen't have to take support calls that can cost $50 to $100 
per call.  If this requirement isn't met, the service provider will stop 
supporting home networking or will charge so much on monthly bills that 
networking will die (and all you little embedded guys will go out of business). 
  Their other option will be charge for support and then people will throw away 
those $50 devices rather than spend $100 to find out that they can't get them 
running.

Brad Davis

---

From: Ted Lemon <[email-masked]>
Date: Tue, 21 Jan 2003 10:45:19 -0800

> The application cares about addresses. It's a server, it's listening at

In effect, here you are saying that DHCP servers are not useful network 
applications.   In practice, DHCP servers need to do precisely what 
you've suggested, and they can't be implemented without this 
capability.   One of the big problems getting DHCP working is that 
there are no standard APIs that provide this functionality, so you have 
to do something different on every UNIX-like operating system.   
However, as I've said previously, the DHCP server implementors are 
aware of this problem, and provide knobs for the user to tweak to avoid 
getting into trouble.   Furthermore, as others have pointed out, you 
don't need an IPv4LL address to communicate with IPv4LL hosts on the 
local wire, so this scenario shouldn't even come up.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 21 Jan 2003 10:48:29 -0800

> the scoping of any arbitrary address and to discover alternative 

Link-local addresses are well-defined numbers.    This is a non-problem.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 21 Jan 2003 10:56:43 -0800

> and networks coexist peacefully rather than interact destructively?

This is just more of the wife-beater rhetoric.   You have never 
demonstrated any such destructive interaction, so I suggest that you 
stop using this terminology and stick to the facts.

---

From: Joshua Graessley <[email-masked]>
Date: Tue, 21 Jan 2003 11:00:32 -0800

> not quietly disable v4LL if they get a DHCP address (or a static one).

Versions of Mac OS that support link-local will only acquire link local 
addresses when configured to use DHCP and the DHCP server does not 
respond. Various versions of the Mac OS will continue to send DHCP 
requests. If a DHCP server does appear, the Mac will use the address 
from the DHCP server but it will also continue to use the IPv4LL 
address. The IPv4LL address is maintained to avoid unnecessarily 
killing already established connections.

The Mac OS will watch for link changed events to determine if DHCP 
should be tried again or the IPv4LL address assignment should occur 
again.

> good one and the network has asked it not to use LL?

If DHCP is present, I don't see any reason to acquire a LL address.

On the other hand, if my machine or some other device for whatever 
reason can't get an address from DHCP, or if it doesn't implement DHCP, 
then I'd like it get an IPv4LL address. This assures me that I have 
some way of communicating with the device. I don't want my machine to 
silently refuse to acquire an address because some guy in the dorm 
playing a prank is sending out some magic packet to disable IPv4LL. I 
don't think we need to design a special protocol either. If someone is 
so disgusted with IPv4LL, they can write or use a utility that 
conflicts with the ARP probes that IPv4LL addresses send before self 
assigning an address. That will effectively eliminate IPv4LL on the 
local link.

I think some people are hugely exaggerating the need for a way to 
disable IPv4LL. To date, I'm not aware of any device shipped that will 
acquire an IPv4LL address when a DHCP server is present or the device 
is manually configured (or configured through bootp or some other 
mechanism). The only thing Keith needs to do to keep IPv4LL off his 
networks is keep his DHCP server running. If, in the future, someone 
does develop a device that only uses IPv4LL addresses, then people like 
Keith can choose not to buy such devices or tell people not to put 
those devices in the network in much the same way one might tell people 
not to use an AppleTalk or IPv6 printer. There is no protocol to tell 
devices not to acquire IPv6LL addresses, AppleTalk address, or IPX 
addresses (yeah yeah, everything but IPv6 is outside the scope of the 
IETF).

-josh

---

From: Keith Moore <[email-masked]>
Date: Tue, 21 Jan 2003 14:01:36 -0500

On Tue, 21 Jan 2003 10:48:29 -0800
Ted Lemon <[email-masked]> wrote:

> > Secondly, this presupposes that such an update is possible. I am not
> > at all sure that that is the case with third party referrals such as
> > happen in many distributed processing schemes - at least not without
> > means to discover the scoping of any arbitrary address and to
> > discover alternative addresses where necessary.
> 

there are two problems:

1. compatibility with existing software that is not LL aware

2. trying to make the app work both in cases where LL addresses need to be used and in cases where they need to be avoided.  for instance, you may want to make your conferencing app workable on ad hoc networks, but it also needs to be able to work across the public Internet.  

if you tell the app to ignore LLs you prevent its use on ad hoc networks; 

if you allow it to use LLs you prevent it from being used across the public Internet; 

if you allow the app to be configured as to which mode it is in you have lost whatever benefit you would have gained from the supposed "zero configuration" provided by LL - and your app *still* cannot work with a mixture of LL-only hosts and hosts elsewhere on the Internet.

this is one reason why LL-only hosts are a bad idea, though this particular argument against LL-only hosts only applies to general-purpose programmable hosts.  
-- 
I tried enlightenment but it kept crashing.

---

From: Joshua Graessley <[email-masked]>
Date: Tue, 21 Jan 2003 11:23:47 -0800

> who write those apps - none of which are appropriate responses.

This problem is not as significant as it may seem. If IPv4LLs are only 
acquired on an interface when no global address can be (no DHCP, manual 
config, or other config method), the device will be unable to 
communicate with anything off of the local link through that interface.

Most applications don't actively participate in picking a local address 
to communicate using. In fact, on a lot of multi-homed systems, if 
applications, did this would most likely lead to a number of problems. 
If an application tries to pick a source address to use for 
communication, and it picks an address that is not on the same subnet 
as the default gateway and it sends to a device which leads to routing 
the packet through the default gateway and the local machine does not 
implement the strong end system model, there is a good chance the 
communication will fail, especially if a router along the way supports 
ingress filtering.

We offer suggestions to our developers. For a number of reasons, mostly 
related to multi-homed machines, we recommend that our developers avoid 
knowing anything about the local IP addresses unless they absolutely 
must. For an outgoing connection, the network stack figures out the 
best local IP address to use. For incoming connections, a server can 
bind to the all zeros address (any addr) and accept from any interface. 
A server could also bind to every local address.

The real problem IPv4LLs cause is referrals. In the case of most 
referral services, a connection is opened to the server. FTP and AIM 
can be used as examples. If the program is written to get a list of 
addresses assigned to the local device and use those in the referral, 
it usually has to pick one of those addresses. FTP only allows you to 
specify one address, I imagine AIM tracks only one address as well. 
Picking the right address is already a challenge. As an app developer, 
I'd take the simple solution and just call some function like 
getsockname on the connected socket to find the local address I should 
use in my referral. In the case of a device with IPv4LL, the initial 
connection to any server off of the local link would fail, so we are 
unlikely to send an IPv4LL address to the remote side. In the case of a 
multi-homed device with an IPv4LL address assigned to one interface and 
a global address assigned to another interface, getsockname is going to 
return the global address if the connection is to a global address.

Referrals where an intermediary party registers the existence of a 
device may lead to problems, but problems that could not be otherwise 
solved. If we have three devices, A, B, and C. A and B are both on the 
same link. A has only an IPv4LL address. B has only a global address. C 
has a global address and is on a different link. Without IPv4LL, A 
would be unable to communicate with B. With IPv4LL, A and B can 
communicate. If B refers C to A by A's IPv4LL address, C will be unable 
to communicate with A. This is irrelevant because C would never be able 
to communicate with A since they are not both on the same local link.

IPv4LL address are simple to detect. In time, applications which are 
found to not work with IPv4LL addresses can be modified to ignore them 
or handle them as appropriate. FTP has problems with NAT and firewalls 
(though it will work with IPv4LL, if the client is written properly). 
FTP has since been modified to work better with NAT and firewalls 
through the addition of passive connections. Finding all of the 
applications that break may take time. I'm not convinced that common 
applications will break, especially since we haven't had any report of 
broken apps and we've been shipping for years now.

-josh

---

From: Ted Lemon <[email-masked]>
Date: Tue, 21 Jan 2003 11:38:35 -0800

> if you allow the app to be configured as to which mode it is in you 
> have lost whatever benefit you would

In the event that you need to do this, you use your non-IPv4ll address 
in all cases where you have one, because it can be used to communicate 
both to IPv4ll hosts and non-IPv4ll hosts.   If you have no non-IPv4ll 
address, you use your IPv4ll address, and you can only communicate on 
your local network, unless you have some kind of NAT setup that works 
with IPv4ll, in which case you couldn't have forwarded your IP address 
through the NAT if you were using a NATted IP address anyway.

Manually configuring the app is the wrong answer - having it 
programmatically differentiate between IPv4ll and non-IPv4LL addresses 
is the right answer.

---

From: Keith Moore <[email-masked]>
Date: Tue, 21 Jan 2003 14:42:10 -0500

> I don't want my machine to 
> playing a prank is sending out some magic packet to disable IPv4LL.

well, for that matter, I don't want machines to be open to attacks just
because the machine happens to support v4LL or because an attacker is
sending out signals to enable IPv4LL.

> I don't think we need to design a special protocol either. If someone
> is so disgusted with IPv4LL, they can write or use a utility that
> assigning an address. That will effectively eliminate IPv4LL on
> the local link.

I examimed this and concluded that this imposed an unreasonable penalty on network bandwidth.

> disable IPv4LL. 

I think some people are hugely exaggerating the value of having LL on managed networks.

> To date, I'm not aware of any device shipped that will 
> mechanism). 

that's fine w/me as a mechanism, but we need a standard mechanism, not one which is at the whim of an implementation.  networks need a uniform way to disable LL, not one which varies from one device to another.

---

From: Keith Moore <[email-masked]>
Date: Tue, 21 Jan 2003 14:43:02 -0500

On Tue, 21 Jan 2003 10:56:43 -0800
Ted Lemon <[email-masked]> wrote:

> > More generally, why shouldn't your mother-in-law's applications, 
> > machines, and networks coexist peacefully rather than interact  > > destructively?
> 

I've done so many times.  And frankly, your abuse is way out of line.

---

From: Keith Moore <[email-masked]>
Date: Tue, 21 Jan 2003 14:50:15 -0500

> same link. A has only an IPv4LL address. B has only a global address.
> C has a global address and is on a different link. Without IPv4LL, A 
> communicate. If B refers C to A by A's IPv4LL address, C will be
> unable to communicate with A. This is irrelevant because C would never
> be able to communicate with A since they are not both on the same
> local link.

for the specific case of NetSolve - if C is the netsolve agent trying to mediate between a netsolve server on A and a netsolve client on B, then it's difficult for C to permit referrals to B for A, even though A and B are both on the same link and should be able to talk to each other.

if the agent filters LL addresses from referrals, it will filter A's address.  if the agent allows referrals containing LL addresses, it may pass A's address into realms in which it is not valid.

> or handle them as appropriate.

no good way has been found to do this.  both passing the scoped addresses in referrals nor filtering them from referrals breaks things.

Keith

---

From: Ted Lemon <[email-masked]>
Date: Tue, 21 Jan 2003 11:53:19 -0800

> I've done so many times.  And frankly, your abuse is way out of line.

No, no, *your* abuse is out of line!

(You see the problem with this kind of talk?   :')

This is why I'm asking you to stick to the facts, and simply not use 
negative rhetoric.   It doesn't work, it doesn't get you what you want, 
what it gets is people just deleting your comments without reading 
them, which is what I did yesterday because there was so much volume on 
this topic, most of it from a very few people, most of it reiterating 
emotional points and not making any new informational points.

---

From: Keith Moore <[email-masked]>
Date: Tue, 21 Jan 2003 15:00:48 -0500

> > if you allow it to use LLs you prevent it from being used across the
> > 
> > public Internet;
> >
> both to IPv4ll hosts and non-IPv4ll hosts. 

It depends on how hosts work when they only have an LL address.  If all such hosts can communicate with routable addresses as easily as they can communicate with the same remote host and interface using a LL address, then yes, any time you have a routable address for a host you should use it in a referral instead of an LL address for that host.  OTOH if there are any cases where it is necessary to use an LL address to talk to a host that also has a routable address, this strategy fails.

Which seems like a good argument for insisting that hosts have a way to talk to routable addresses even when they only have an LL address.

> programmatically differentiate between IPv4ll and non-IPv4LL addresses

I was told that such a configuration bit was the best that Microsoft people had come up with for dealing with site-local addresses in v6.  I need to think some more to understand whether these two cases are different.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 21 Jan 2003 13:12:19 -0800

> It depends on how hosts work when they only have an LL address.  If 
> all such hosts can communicate with routable addresses as easily as 
> they can communicate with the same remote host and interface using a 
> LL address, then yes, any time you have a routable address for a host 
> you should use it in a referral instead of an LL address for that 
> host.  OTOH if there are any cases where it is necessary to use an LL 
> address to talk to a host that also has a routable address, this 
> strategy fails.

Hm, right.   So here's the code from the draft:

    If the destination address is a unicast address outside the
    169.254/16 prefix, then the host SHOULD 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.

So I guess it's possible for an implementation to not support this 
capability, and I have to admit that this seems like a mistake to me.

Can anyone explain the reasoning behind making this a MAY instead of a 
MUST?

---

From: "Adam MacBeth" <[email-masked]>
Date: Tue, 21 Jan 2003 13:12:21 -0800

> If DHCP is present, I don't see any reason to acquire a LL address.

Determining if DHCP is present may take a while.  For example, IP
address autoconfiguration in Windows takes a few minutes to give up on
DHCP and assign a LL address, which makes adhoc networking pretty
unusable.  The timeout could be configurable, but anything longer than a
few seconds is a hassle.  Is there a way to make this usable without
immediately acquiring a LL address when a new interface is brought up?

---

From: "Philip Nye" <[email-masked]>
Date: Tue, 21 Jan 2003 21:18:41 -0000

Joshua,

> communicate with anything off of the local link through that interface.

Your analysis is reasonable - but it is rather off the track because the
current draft recommends that IPv4LL be turned on even when a global address
IS found - and this is the source of the problems.

Philip

---

From: Ted Lemon <[email-masked]>
Date: Tue, 21 Jan 2003 13:23:00 -0800

> So far I have seen no rebuttal to this issue except to deny its 
> existence, [...]

That's because the current draft does not require that you have a 
link-local address in order to communicate with link-local nodes.   The 
only reason this is a problem at all is that the draft has a MAY where 
I think it should have a MUST, as I mentioned in my recent message to 
Keith.

> route LL packets to as discussed in section 3 of the draft.

I can think of a few scenarios here:

First, in all cases consider it a constant that host A has two 
interfaces.   Host B is on the network attached to one of these 
interfaces, and host C is on the network attached to the other 
interface.   Hosts B and C are both using the same IPv4LL IP address.

Problem 1:   Host B tries to establish a TCP connection to host A.   
How does host A decide to which host to send the SYN+ACK?
Solution:  Stash the interface ID in the TCP control block.

Problem 2: Host B sends a UDP packet to host A.   Host A needs to 
respond to host B, but UDP is connectionless so we don't know which ARP 
cache entry to use.
Solution: The draft says that host A should only talk to the first of 
host B or host C from which it gets an ARP reply when it ARPs for the 
address that B and C share.   In practice, this will probably be the 
one that it ARPs for first, since it needs to send two ARP packets.   
So it won't be able to talk to one of these hosts, and it will not be 
obvious to the user why this is so.

Problem 3: Host A needs to send a packet to a host called B.local.   It 
looks up B.local using MDNS, and gets the IP address that B and C are 
both using.   It got the address from B, but there's no way to 
communicate this through the API.   How does it connect to B?
Solution: Here it's not clear what to do - we may have done MDNS to 
host B when host C is the one we actually have in our ARP cache, 
because MDNS doesn't use ARP - it uses multicast.   Here again we have 
a case where the user will be unable to communicate with host B, and 
there will be no obvious explanation for why this is so.

I can think of solutions to this problem, possibly involving an ICMP 
message and multiple IPv4ll addresses on the same interface.   That is, 
host A detects the conflict and sends host B an ICMP message saying 
"dude, can you acquire a second IPv4LL address so I can talk to you?"   
This would work, but it's complicated.

These problems  aren't addressed by the draft, except by the rather 
drastic option of simply not doing IPv4LL on two interfaces at once.   
The problem with this is that I think it doesn't work - I may have a 
wireless printer and an unmanaged wired connection, and I want both of 
them to work.   On which interface does the O.S. not do IPv4LL?   On 
what basis does it decide?

> mudslinging prevailed - at least it is familiar!

I have seen some mudslinging, mostly between a few individuals.   I've 
also seen a lot of constructive conversation, mostly from other 
individuals.   If you just filter out the mudslinging, I think you'll 
do fine.

---

From: Daniel Senie <[email-masked]>
Date: Tue, 21 Jan 2003 16:33:07 -0500

>immediately acquiring a LL address when a new interface is brought up?

Windows (at least recent versions) appears to always assign a LL address 
when an interface is brought up. If/when DHCP completes, the address is 
replaced with the assigned address. The degree to which that address is 
actually used by Windows while waiting for DHCP is unclear.

---

From: Ian Lister <[email-masked]>
Date: Wed, 22 Jan 2003 10:01:30 +1000 (EST)

>IS found - and this is the source of the problems.

It is not off track if the draft is amended to specify the behaviour
Joshua described (which is currently implemented in Mac OS and IMO is the
most appropriate behaviour). With that behaviour IPv4LL is used only where
there is no alternative, so there can be no accusations of breakage. Is
there anybody who actually wants to argue against this?

Ian

---

From: "s. goswami" <[email-masked]>
Date: Tue, 21 Jan 2003 19:17:02 -0500 (EST)

See inline

> there anybody who actually wants to argue against this?

So you are professing a preference level for each method: DHCP 1, Manual
2, LL 3 ? Correct ?

Subrata

---

From: Keith Moore <[email-masked]>
Date: Tue, 21 Jan 2003 19:27:58 -0500

On Wed, 22 Jan 2003 10:01:30 +1000 (EST)

> there anybody who actually wants to argue against this?

now I'm losing track of what is meant by "used" -

- when should an IPv4LL address be configured by a host?

  suggest: if the host is explicitly configured to do so, OR
  if the host has attempted and failed to acquire a routable address via DHCP

  (alternative: provide a lighter weight mechanism by which a host can acquire a
   routable address, netmask, and default route, in response to its attempt to claim
   an IPv4LL address)

- when should an IPv4LL address be used by a host as a source address?

  suggest: when the only addresses available to the host are IPv4LL addresses, OR
  when the application has explicitly specified the source address to use, OR
  when the application has explicitly specified the interface to use and the IPv4LL address
  is the only address associated with that interface.

- when should a host honor an attempt to connect to an IPv4LL address that was once
  configured by that host?

  suggest: anytime the address is still valid (e.g. there have been no conflicting claims)
  and there is a process listening for connections either specifically to that address or
  for incoming connections at any of the host's addresses.

- when should an application attempt to connect to a IPv4LL address?

  suggest: only when the address is literally specified, or if there are no other routable
  addresses for the destination host known to the application.

- when should an application send an IPv4LL address in a referral to another host?

  suggest: only when there are no routable addresses for the destination host known to the 
  application.  even then, care needs to be taken that a host reached at a particular
  IPv4LL address is really the one intended - since IPv4LL addresses can be reassigned
  without notice and/or reused on different network segments.

---

From: Ian Lister <[email-masked]>
Date: Wed, 22 Jan 2003 10:44:25 +1000 (EST)

>So you are professing a preference level for each method: DHCP 1, Manual

I am expressing a preference level for:

1. Configured/managed mechanisms

     This is manual, DHCP, or whatever is configured using a host's normal
     configuration mechanism (/etc/hostname.if, Network control panel, etc)

2. Zero configuration mechanisms

     IPv4LL

Note that by `use' I am referring to acquiring an address, not to ability
to communicate with other hosts using such an address.

Ian

---

From: Ian Lister <[email-masked]>
Date: Wed, 22 Jan 2003 11:35:20 +1000 (EST)

On Tue, 21 Jan 2003, Keith Moore wrote:
>On Wed, 22 Jan 2003 10:01:30 +1000 (EST) Ian Lister wrote:

Sorry, I was ambiguous. As I just clarified in a mail a minute ago, I
meant acquiring an IPv4LL address, not communicating with a host with an
IPv4LL address.

>  if the host has attempted and failed to acquire a routable address via DHCP

This seems fair enough.

>   routable address, netmask, and default route, in response to its attempt to claim

I'm not sure what this is aimed at, or what its purpose is over and above
DHCP, but given that the first suggestion seems fine I won't dwell on it.

>  is the only address associated with that interface.

That seems fine. Also when the destination address is IPv4LL there doesn't
seem to be any reason not to use an IPv4LL source address.

>  for incoming connections at any of the host's addresses.

Seems straightforward enough.

>  addresses for the destination host known to the application.

OK. Also if the source has only an IPv4LL address and the destination
IPv4LL address is known to be in-scope (i.e. on the same link) I don't see
a good reason not to use the IPv4LL destination address.

>  without notice and/or reused on different network segments.

This seems fair enough.

So, it seems for the most part we agree on these things. Does anybody care
to disagree?

Ian

---

From: "s. goswami" <[email-masked]>
Date: Tue, 21 Jan 2003 20:44:53 -0500 (EST)

So a relevant question is can LL coexist with DHCP/Manual ?

1. In different subnets (or physical link). Absolutely.
2. In the same physical link (i.e. mix 169.254/16 with say 192.168/16 )?
   A 169.254 interface can talk to a 192.168 host sitting on the same
   physical link without a router.  DHCP servers can handout 169.254/16
   addresses if they want.

Subrata

---

From: Keith Moore <[email-masked]>
Date: Tue, 21 Jan 2003 22:01:51 -0500

On Wed, 22 Jan 2003 11:35:20 +1000 (EST)
Ian Lister <[email-masked]> wrote:

> >> most appropriate behaviour). With that behaviour IPv4LL is used only
> >where> there is no alternative, so there can be no accusations of breakage.
> >Is> there anybody who actually wants to argue against this?
> >
> >   routable address, netmask, and default route, in response to its attempt
> >   to claim an IPv4LL address)
> 

the idea is to lower the implementation burden for fixed-function devices that
can't afford to dedicate much code space to address allocation, to minimize as
much as possible the split between routable and v4LL worlds, and to discourage
vendors from making devices that can only talk to hosts on the local link.

> >  suggest: when the only addresses available to the host are IPv4LL
> >  addresses, OR when the application has explicitly specified the source
> >  address to use, OR when the application has explicitly specified the
> >  interface to use and the IPv4LL address is the only address associated
> >  with that interface.
> 

actually I disagree, because a v4LL source address might be used by the
destination host in a referral to another host which is not on the same link. 

> >  suggest: only when the address is literally specified, or if there are no
> >  other routable addresses for the destination host known to the
> >  application.
> 

same reason as above - because it might be used by the destination in a
referral to another node.

basically life is much simpler if:
a. every host on a managed network gets a routable address, and
b. hosts and apps avoid using scoped addresses whenever possible.

Keith

---

From: "John C. Welch" <[email-masked]>
Date: Tue, 21 Jan 2003 22:10:27 -0500

> there anybody who actually wants to argue against this?

Yes, actually. Because now, so that you avoid dictating behavior to network
managers, you're dictating behavior to end users. So we need to decide who
has priority for the standard, end users or network managers.

john

-- 
John C. Welch
Consultant III
Administrative Computing
(617) 253 - 1368 work
(508) 579 - 7380 cell
bynkii2          AIM

---

From: "John C. Welch" <[email-masked]>
Date: Tue, 21 Jan 2003 22:15:19 -0500

>    routable address, netmask, and default route, in response to its attempt to

Now, here's a monkey wrench, and a fairly logical one...printers...

WHY do you need to have printers with routable, global addresses in all
cases? Normally, you don't. So printers with LLv4 - only addressing actually
makes a fair bit of sense, especially behind a firewall and a NAT. (Yes,
keith, we KNOW how you feel about NAT, but they exist, so sticking fingers
in ears and yelling loudly won't change that).

Again, HOW do you easily override the DHCP = OFF condition here?

This is NOT the simple conditional some think it is.

john

-- 
John C. Welch
Consultant III
Administrative Computing
(617) 253 - 1368 work
(508) 579 - 7380 cell
bynkii2          AIM

---

From: Keith Moore <[email-masked]>
Date: Tue, 21 Jan 2003 22:20:44 -0500

On Tue, 21 Jan 2003 22:10:27 -0500

> has priority for the standard, end users or network managers.

my assumption is that we're specifying a default behavior in the absence of
explicit per-host configuration.  IMHO it should be possible for explicit
per-host configuration to override essentially anything that can be obtained
by DHCP, because much of what is obtained through DHCP really doesn't have any
relationship to the location in the network.

Keith

---

From: Keith Moore <[email-masked]>
Date: Tue, 21 Jan 2003 22:33:10 -0500

> cases? Normally, you don't. 

You might or might not want your printers to be potentially accessible from
anywhere in the world (mine are and it really can be quite useful). 
But there's no real reason to assume that a printer need only be accessible
from the local link.  If I want to use my palm pilot with a CDMA connection to
print a file from the workstation in my office, to a printer in the same room
as I am, that's a very convenient and perfectly reasonable thing to do. 
Similarly, I often find myself sending print jobs to printers on remote
subnets, because the printer can duplex, or print high-quality color.

> So printers with LLv4 - only addressing actually
> makes a fair bit of sense, especially behind a firewall and a NAT.

Even that only makes sense if either the local link and the realm behind the
NAT are identical, or the realm from which you want to be able to print
happens to be some subset of the local link.

> Again, HOW do you easily override the DHCP = OFF condition here?

Devices that aren't explicitly configurable have to accept whatever the
network tells them to do.  If the network admin (whether by DHCP or some other
mechanism) wants to tell different devices to do different things, based on
their MAC addresses or whatever, that's his business.

Of course the point isn't to insist that all devices be accessible from
everywhere, but to avoid building limitations into devices that are
unnecessary and which aren't a good match to users' needs.

Keith

---

From: Ian Lister <[email-masked]>
Date: Wed, 22 Jan 2003 14:01:05 +1000 (EST)

>makes a fair bit of sense, especially behind a firewall and a NAT.

That is true, but I don't see anything in Keith's proposal that causes a
problem with this. If you have a managed network (DHCP or manual) then you
get to choose whether or not your printers are going to get global
addresses. If you give them global addresses then they have no need of
IPv4LL addresses (remember, visiting laptops and the like can still talk
to them). If you don't give them global addresses then they will fail to
acquire one and Keith's suggestion above allows them to acquire an IPv4LL
address (and everything on the link can still talk to them).

Perhaps I've missed something but I don't think there's a problem here.

>Again, HOW do you easily override the DHCP = OFF condition here?

The condition is `if you get a global address then don't get a local
address too'.

>This is NOT the simple conditional some think it is.

If I've missed something, please explain more.

Ian

---

From: Ian Lister <[email-masked]>
Date: Wed, 22 Jan 2003 14:09:24 +1000 (EST)

>their MAC addresses or whatever, that's his business.

IOW, along the lines of Subrata's earlier mail, there's a precedence:

1. Host configuration
2. Network configuration
3. Zero configuration

Ian

---

From: Keith Moore <[email-masked]>
Date: Tue, 21 Jan 2003 23:05:50 -0500

> >cases? Normally, you don't. So printers with LLv4 - only addressing
> >actually makes a fair bit of sense, especially behind a firewall and a NAT.
> 

more generally, you can give such devices whatever netmasks and default routes
you want, so you can restrict their scope fairly flexibly.  and you can of
course filter their packets also, since you know which addresses you are
assigning to which devices.

it is *much* better to let the network decide the scope from which the device
may be used than to encourage devices to assume that all networks are alike.

Keith

---

From: Ian Lister <[email-masked]>
Date: Wed, 22 Jan 2003 14:09:37 +1000 (EST)

>vendors from making devices that can only talk to hosts on the local link.

I see. I thought it might be that, but I don't think we're going to get
very far trying to create a new `lighter weight' DHCP or BOOTP to slip in
between IPv4LL and DHCP/BOOTP (and nor would it be worth it IMO, given the
simplicity of BOOTP). YMMV.

>referral to another node.

OK. I was trying to be tolerant of hosts that have only IPv4LL addresses
but treat only 169.254.0.0/16 as being on the local link (and 0.0.0.0/0 as
unroutable), but your consideration may be more widely applicable.

>b. hosts and apps avoid using scoped addresses whenever possible.

Yes, I think I agree with that.

Ian

---

From: "Philip Nye" <[email-masked]>
Date: Wed, 22 Jan 2003 08:55:13 -0000

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

Keith, this is interesting.

Is the idea that in response to an ARP probe claiming a new address, the
Zeroconf device receives a message along the lines of "Don't use that one -
use this one" along with a default route?

Who would send the message? an "almost DHCP" server? Why is this lighter
weight than BOOTP? What advantage does it have over BOOTP/DHCP? How does it
scale?

Philip

---

From: Robert Elz <[email-masked]>
Date: Wed, 22 Jan 2003 16:33:38 +0700

Date:        Tue, 21 Jan 2003 11:00:32 -0800
    From:        Joshua Graessley <[email-masked]>
    Message-ID:  <[email-masked]>

  | Versions of Mac OS that support link-local will only acquire link local 
  | addresses when configured to use DHCP and the DHCP server does not 
  | respond. Various versions of the Mac OS will continue to send DHCP 
  | requests. If a DHCP server does appear, the Mac will use the address 
  | from the DHCP server but it will also continue to use the IPv4LL 
  | address. The IPv4LL address is maintained to avoid unnecessarily 
  | killing already established connections.

If the "to avoid" is correct exactly as it reads (and I assume it is, as
that is the easiest and simplest way to make this work) then that's
exactly what is wanted I believe.

That is, this is what the draft should say should happen.   Why doesn't
it now?

  | The Mac OS will watch for link changed events to determine if DHCP 
  | should be tried again or the IPv4LL address assignment should occur 
  | again.

Again, that is both correct, and necessary, and (usually) pretty easy.

  | On the other hand, if my machine or some other device for whatever 
  | reason can't get an address from DHCP, or if it doesn't implement DHCP, 
  | then I'd like it get an IPv4LL address.

Unless it is a human configurable device (in which case its vendor can
decide to just let humans manage the addresses if it wants) it should
implement DHCP.   Otherwise it is simply useless on many networks.

  | I don't want my machine to 
  | silently refuse to acquire an address because some guy in the dorm 
  | playing a prank is sending out some magic packet to disable IPv4LL.

In that case, you're going to have to start all over again with IPv4LL
as the way it is currently proposed to work (and does work in those
products that use it), this is impossible to achieve.

  | I don't think we need to design a special protocol either. If someone is 
  | so disgusted with IPv4LL, they can write or use a utility that 
  | conflicts with the ARP probes that IPv4LL addresses send before self 
  | assigning an address. That will effectively eliminate IPv4LL on the 
  | local link.

Exactly.    But as a recommended standard way of disabling IPv4LL, don't
you think that's a bit crude?

Given that you have demonstrated that there is a way that can't be
defeated, that disables LL addresses, clearly those wanting to deny
that such a method should be permitted now have to go away - the method
exists whether they like it or not.

The question now is whether that is the method that should be suggested,
or whether a new one is better to suggest.

Specifying the method you outlined above, along with a general recommendation
that for any kind of low config IP node, client dhcp (or at a minimum, bootp)
is really essential, seems like a much nicer, and cleaner, method than
the ARP attack way of disabling v4LL - what's more, it allows your apps
that acquired a LL address to keep function, the ARP attack method (if
implemented to do so) would break that.

  | I think some people are hugely exaggerating the need for a way to 
  | disable IPv4LL. To date, I'm not aware of any device shipped that will 
  | acquire an IPv4LL address when a DHCP server is present or the device 
  | is manually configured (or configured through bootp or some other 
  | mechanism).

That's fine - the problem is that the current draft says that that is
what devices should do - that  they should all go give themselves a LL
address, in addition to anything they get from elsewhere.

You should also be aware that the reason that (I think most of us) want
a way to disable LL addresses, is not because we're worried about packets
flying around on the LAN with some stray address in them - that's harmless
(even the traffic doesn't matter, as one must assume that would be there
with some address or other anyway).

The reason that there's a desire to be able to disable LL addresses is
because we know that they're simply not going to work well enough in the
relevant environment to achieve anything at all - the user (or device)
would be better to simply close down if it is unable to get some other
address, rather than carry on in the hope that its LL address will somehow
be useful for it.

Other LANS aren't like that of course, and having a LL address might be
useful there.   This is why a method to disable them when the local network
administrator knows that is best is the right thing to do.

kre

---

From: Ralph Droms <[email-masked]>
Date: Wed, 22 Jan 2003 06:09:08 -0500

Note that there already is a "lightweight DHCP" - the DHCPINFORM/DHCPACK 
message is a two-message exchange for use when the client does not need to 
acquire an IP address.  This variation on DHCP requires no dynamic state on 
the part of either the client or the server.

I've never seen a DHCPINFORM-only client or server, but I imagine those 
implementations would be *much* smaller than DHCP for address assignment.

- Ralph

---

From: "Philip Nye" <[email-masked]>
Date: Wed, 22 Jan 2003 11:14:22 -0000

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

Is it feasible to mandate (or recommend) that where two addresses are
present the OS always returns the global address to applications first?
(e.g. in gethostbyname) so that where both are present the LL address is not
used by the app unless it tries really hard.

> implement DHCP.   Otherwise it is simply useless on many networks.

What does the machine do if the DHCP server is present but refuses it an
address? This probably indicates that the network manager does not want this
machine on the link.

Philip

---

From: "John C. Welch" <[email-masked]>
Date: Wed, 22 Jan 2003 07:23:43 -0500

> relationship to the location in the network.

<sigh>...so you really aren't going to shut off LL if the user says, "Bugger
off, I want it on". What's the default setting, allow pcDOS or don't allow
pcDOS? If the human can easily override the pcDOS, *why bother* with pcDOS
in the first place? It's a waste of time and packets.

john

-- 
John C. Welch
Consultant III
Administrative Computing
(617) 253 - 1368 work
(508) 579 - 7380 cell
bynkii2          AIM

---

From: "John C. Welch" <[email-masked]>
Date: Wed, 22 Jan 2003 07:32:41 -0500

> anywhere in the world (mine are and it really can be quite useful).

I didn't say they weren't. I said it wasn't the majority case. It's *far*
more common not to see this, and if you are dealing with chargebacks for IP
addresses and whatnot, (again, not 100%, but rather common), LL - only
printers do make a lot of sense.

> as I am, that's a very convenient and perfectly reasonable thing to do.

Right...because it's far easier than doing a sync and using Ethernet....I
can write some AppleScripts that use the motion sensors in BTV to activate
my WebCam to scan a document, pass it through an OCR app, then print it. But
why make life harder.

> subnets, because the printer can duplex, or print high-quality color.

Again, not questioning that. But, printer prices are coming down. You can
get a high-res, color, duplexing printer for under $5K US. This is not an
aberrant trend. But beside that, there are points for both methods of
printing, and what I'm saying is, consider that an LL - only device would
not be some bizarre abberation, but a common potential.

> happens to be some subset of the local link.

I've dealt with a LOT of companies that have printers for each work group,
and due to chargebacks, you aren't *allowed* to print on someone else's
printer. Or if you work in a classified environment, you may only be able to
print from your printer. It doesn't have to be something you or I use
regularly. But it does happen, and we need to think about it.

> their MAC addresses or whatever, that's his business.

But earlier you said that it should be manually overridable...so again, What
do you do about situations that don't fit your model?

> unnecessary and which aren't a good match to users' needs.

But you assume that global accessibility is always wanted or needed, and
that simply isn't true. Most military organizations DON'T want this.

john

-- 
John C. Welch
Consultant III
Administrative Computing
(617) 253 - 1368 work
(508) 579 - 7380 cell
bynkii2          AIM

---

From: "John C. Welch" <[email-masked]>
Date: Wed, 22 Jan 2003 07:36:00 -0500

> Yes, I think I agree with that.

But since reality shows that WON'T happen, we need to deal with *reality*
not "What we dream about"

john

-- 
John C. Welch
Consultant III
Administrative Computing
(617) 253 - 1368 work
(508) 579 - 7380 cell
bynkii2          AIM

---

From: "John C. Welch" <[email-masked]>
Date: Wed, 22 Jan 2003 07:34:46 -0500

> address (and everything on the link can still talk to them).

Because you have a reason to not want the world to be able to get to your
printers, so a LL - only device satisfies this need nicely. So they CAN'T
get global addresses.

Now, how do you deal with this case?

john

-- 
John C. Welch
Consultant III
Administrative Computing
(617) 253 - 1368 work
(508) 579 - 7380 cell
bynkii2          AIM

---

From: "John C. Welch" <[email-masked]>
Date: Wed, 22 Jan 2003 07:41:16 -0500

> implement DHCP.   Otherwise it is simply useless on many networks.

Because I don't want to *have* to buy a DHCP device on a two node network.
Maybe I bought a cheapie little networkable inkjet, and all I have is my
laptop. I've got a little dumb switch, but not a cable modem router, because
I don't feel I need one. (Hypothetically). I don't *want* to pay for my
printer to have an IP address from my ISP, just my computer.

But since my computer is using DHCP under your schemes, I now *have* to buy
a router with DHCP capability, because my computer will not use v4LL, since
it has a global address. Great...so now I have to set up a DHCP server on
the internal interface, configure the external interface, I HAVE to use NAT,
probably set up the router I HAD to buy to spoof the MAC address of my
computer on the external interface...

This is simpler?

john

-- 
John C. Welch
Consultant III
Administrative Computing
(617) 253 - 1368 work
(508) 579 - 7380 cell
bynkii2          AIM

---

From: "Philip Nye" <[email-masked]>
Date: Wed, 22 Jan 2003 12:48:30 -0000

> Now, how do you deal with this case?

You hand them a scoped address,  or you only allow them to acquire a LL
address,  or you configure your routers so they can't get in/out,  or...

In none of these cases is it necessary that the printer is LL only by
design.

As a designer of small embedded devices, I know that I cannot afford to make
my devices only accessible on the local link by design - that is far too
restrictive for them to have much market.

I AM interested in having them as easily configured as possible and if they
are likely to required to be accessible only on the local link then I will
try to ensure that this option is _easily_ configured either at the host or
at the network level or probably both.

Philip

---

From: Ian Lister <[email-masked]>
Date: Wed, 22 Jan 2003 22:48:23 +1000 (EST)

>computer on the external interface...

He said these devices should implement DHCP, not that they should do
nothing else except DHCP. Nobody is saying you should have to have a DHCP
server on a network - that's the whole point of zeroconf!

Ian

---

From: "Philip Nye" <[email-masked]>
Date: Wed, 22 Jan 2003 12:57:02 -0000

> computer on the external interface...

There appears to be a misunderstanding here.

With the proposed scheme, your computer and the cheapie printer do not find
a DHCP server and so assign themselves a LL address. They then talk nicely.

Even if the computer has a manually assigned global address it is "LL aware"
and so knows to ARP for the printer. Similarly the draft currently describes
how the printer can talk to the computer.

The obligation is simply to look for a DHCP server not to provide one.

Philip

---

From: Keith Moore <[email-masked]>
Date: Wed, 22 Jan 2003 08:08:41 -0500

On Wed, 22 Jan 2003 08:55:13 -0000
"Philip Nye" <[email-masked]> wrote:

> > the idea is to lower the implementation burden for fixed-function devices
> > that can't afford to dedicate much code space to address allocation, to
> > minimize as much as possible the split between routable and v4LL worlds, and to
> > discourage vendors from making devices that can only talk to hosts on the local link.
> 

I haven't had time to sit down and compare them yet. 

Keith

---

From: Robert Elz <[email-masked]>
Date: Wed, 22 Jan 2003 21:29:03 +0700

Date:        Wed, 22 Jan 2003 11:14:22 -0000
    From:        "Philip Nye" <[email-masked]>
    Message-ID:  <009001c2c207$6ad70030$131010ac@aldebaran>

  | Is it feasible to mandate (or recommend) that where two addresses are
  | present the OS always returns the global address to applications first?

I suspect that would be a good idea.   That or strike "first" from that.

  | (e.g. in gethostbyname)

but it seems a little unlikely that gethostbyname() would ever encounter
the situation.   LL addresses in the DNS are a horrid idea, for the same
reason that IPv6 SL addresses there are.   LL addresses in even less dynamic
databases (/etc/hosts, NIS, ...) would be a nightmare (how do they get there?)
So, it is likely that LL addresses will only ever be discovered via some
mechanism like mDNS.   Then it is up to the owner of the address to decide
what to return, and if there's a global address, I'd suggest, returning
just that is optimal.

  | so that where both are present the LL address is not
  | used by the app unless it tries really hard.

The harder problem isn't which address for a remote system gets used,
but which of my addresses gets used when I have both.   And for that we
need to consider both active and passive socket opens (ie: connect &
bind/listen)

  | What does the machine do if the DHCP server is present but refuses it an
  | address? This probably indicates that the network manager does not want this
  | machine on the link.

Squawk, flash its red led, and emit liquids in small drops down its
front panel...

If it isn't supposed to be on the link, then it shouldn't automatically
put itself there (if some human wants to explicitly configure it to
exist there, if that is possible for the device in question, then that
person takes responsibility for that).

To get it to work, either it would need to be moved to a new link, or
the network manager would need to permit it to get an address.  Either
of those may be appropriate in different circumstances.

kre

---

From: "John C. Welch" <[email-masked]>
Date: Wed, 22 Jan 2003 09:39:53 -0500

> In none of these cases is it necessary that the printer is LL only by

But what about when it happens. Or some other device that we don't know
about yet? Maybe a home MP3 server?

> restrictive for them to have much market.

Okay, that's you. 

> at the network level or probably both.

By disabling v4LL in the face of any and all other configuration mechanisms,
you are now *forcing* everyone with a small home network to buy a DHCP
server of some kind. Great, that's so much easier.

john

-- 
John C. Welch
Consultant III
Administrative Computing
(617) 253 - 1368 work
(508) 579 - 7380 cell
bynkii2          AIM

---

From: "John C. Welch" <[email-masked]>
Date: Wed, 22 Jan 2003 09:43:52 -0500

> server on a network - that's the whole point of zeroconf!

BUT...you are ALSO saying that if *any* other address configuration
mechanism is present, then v4LL is *turned off*.

So that means, that to work in this environment, EVERY device HAS to support
both DHCP and manual addressing...and bootp too. Which means that if your
ISP uses manual or DHCP configuration, then your computer will not use v4LL.
That means that you either get additional addresses from your ISP, and have
every device on your system globally visible, OR, you buy a little home
router, set up your own DHCP server...which is NO different than it is now.

Maybe Keith's right, but for a different reason. The IETF should just leave
this stuff alone. You don't seem to get why it's important.

john

-- 
John C. Welch
Consultant III
Administrative Computing
(617) 253 - 1368 work
(508) 579 - 7380 cell
bynkii2          AIM

---

From: Robert Elz <[email-masked]>
Date: Wed, 22 Jan 2003 21:43:09 +0700

Date:        Wed, 22 Jan 2003 07:41:16 -0500
    From:        "John C. Welch" <[email-masked]>
    Message-ID:  <[email-masked]>

I have no idea why I am replying to you - you have constantly shown a
complete inability to even attempt to understand what anyone else is
saying, and an almost complete lack of understanding of how networks
actually work - and Ian Lister and Philip Nye have already done a
pretty good job of answering, but ...

  | Because I don't want to *have* to buy a DHCP device on a two node network.

When did anyone ever say that you had to?   If there's no DHCP server
you won't get a DHCP response, nothing will disable LL addresses, and
you'll just go and allocate yourself one.

  | But since my computer is using DHCP under your schemes,

Huh?   How is it doing that?   Do you mean that is attempting to get
an address via DHCP ("using DHCP") or that it is actually obtaining one?

I assume obtaining one from ...

  | I now *have* to buy a router with DHCP capability,

Huh, why?

  | because my computer will not use v4LL, since it has a global address.

If it has its global address, why would it possibly need a v4LL addr?
One address is enough for (just about) any (singly-homed) system, and
the global one will allow it to talk to everyone (including your other
device that has only v4LL).

You're imagining all kinds of absurdities that simply don't exist.

I suspect (though you didn't actually make it clear) that you are connected
directly to your ISP, both your printer and computer are connected to the
ISP's LAN, so all your printer's noise packets are being dumped on the ISP
(but you're refusing to pay the ISP anything for that) the ISP will allocate
you one address for your computer via DHCP, but will refuse to give your
printer a global address, is that the scenario?

If that's it, then why would the ISP also be telling your LAN to disable
LL addresses?    Whether the "default" state is "DHCP server implies no
LL" or whether a DHCP option is required to disable LL (either way is
fine, and each has advantages and disadvantages), the ISP isn't going to
care that you have other stuff out there that doesn't connect through them.
So, why would they be disabling your LL addresses (or not enabling them
if that's what it takes).

If you just have a cantankerous ISP, you switch to another right?

The ISP wants to minimise customer help calls - they'll do whatever config
is going to make that happen, and stopping v4LL from working on their
customers' private LANS isn't going to achieve that aim, is it?  So, why?

kre

---

From: "John C. Welch" <[email-masked]>
Date: Wed, 22 Jan 2003 09:48:28 -0500

> a DHCP server and so assign themselves a LL address. They then talk nicely.

That's only if you have a home network with no form of public internet
connection. This is really not going to be common.

> how the printer can talk to the computer.

No, because everything I've seen says, "In the face of any other
configuration methodology, disable v4LL" Now, disabled is rather clear. It
means off. Off is off. Not sort of on, not kind of on, but off. You cannot
use a v4LL address, because it is disabled. You can ARP for anything, but
since v4LL is disabled, you can't talk to that device.

> The obligation is simply to look for a DHCP server not to provide one.

Right...now, show me an ISP that doesn't require you to configure a device
with some form of addressing. v4LL will *always* be off.

john

-- 
John C. Welch
Consultant III
Administrative Computing
(617) 253 - 1368 work
(508) 579 - 7380 cell
bynkii2          AIM

---

From: Thomas Narten <[email-masked]>
Date: Wed, 22 Jan 2003 09:45:28 -0500

"John C. Welch" <[email-masked]> writes:

> cases?

Because this is the norm today, it works, and we understand it's
limitations. There are fewer problems in general if a device has a
global address. LL addresses only work in limited circumstances --
namely, on a single link.

> Normally, you don't. So printers with LLv4 - only addressing actually

You are making a bunch of assumptions here that I don't think
generalize, and I suspect we do not want to mandate or suggest is The
Right Way for the future.

Recall, LL addresses only work on a single link. If a printer has only
a LL address, one can no longer print on it from behind a router. This
may not be a limitation in typical home networks *today*, but
certainly is in small offices, and future homes. Thus, we need to be
very careful about encouraging such a direction for the future. I'd be
rather suprised of printer (and other small device) vendors thought it
made business sense to not implement DHC on the client.

I do not believe this WG should be legitimizing LL-only hosts. If
vendors want to ship such devices, we can't stop them, but blessing
such behavior, and encouraging it *in* *general* is also not something
we need to allow.

General comment: there is a long history of folk wanting to "simplify"
TCP/IP for a device with limited capabilities. That is not the goal of
this WG. It might be a fine topic for a different WG. But it is not in
the charter for this WG. On the other hand, when looking at limited
functionality devices, the IETF has historically said, after getting
to the underlying technical issues, "the arguments about limited code
space, etc. are bogus, you need to implement full TCP/IP". For
example, crying that DHCP is too expensive to implement in a small
device that also includes TCP/HTTP and a limited web server (e.g., for
configuration) just doesn't sway a lot of folk. Or for a printer that
implements the IPP protocols (no lean-and-mean protocol). But again,
that topic is a distraction for this WG.

Thomas

---

From: Thomas Narten <[email-masked]>
Date: Wed, 22 Jan 2003 09:50:01 -0500

Folks,

This WG needs to declare consensus on some basic issues, or it will
never get done.

The note below from Keith summarizes what I see a lot of other folk
seeming to agree with.

So, I would like to ask the WG to answer the following questions:

1) Should the ID recommend that LL addresses only be configured as per
   below. Please answer clearly, along the lines of

   a) yes, I think this is what the document should say (maybe with
      some small tweaks, which then need to be explained)
   
   b) no, this is a showstopper for me (and explain why, so the rest
      of the WG can understand and then agree or disagree with your
      position)

   c) Not my first choice, but I can live with it.

Note that two things need to happen. First, get general agreement on
the direction, second, agreement on the exact text to go in the
document.

It would be helpful if folk would post their views (including lurkers)
but also to restrict themselves to answering the above questions. If
only a small number of the usual suspects post, we will risk not have
enough input to make a clear consensus call. Thus, everyone who cares
should speak up.

Thomas

---

From: "Philip Nye" <[email-masked]>
Date: Wed, 22 Jan 2003 14:59:49 -0000

> since v4LL is disabled, you can't talk to that device.

Perhaps this is the cause of the confusion. I believe that most of the
people advocating this mean "Do not claim a LL address" and not "Do not
communicate using LL addresses in any way"

If this is not the case I am sure they will say so.

Philip

---

From: "John C. Welch" <[email-masked]>
Date: Wed, 22 Jan 2003 10:05:37 -0500

> the direction, second, agreement on the exact text to go in the

v4LL communication should always be available and usable without manual
intervention by the user.

That is my position.

john

-- 
John C. Welch
Consultant III
Administrative Computing
(617) 253 - 1368 work
(508) 579 - 7380 cell
bynkii2          AIM

---

From: John Schnizlein <[email-masked]>
Date: Wed, 22 Jan 2003 10:13:09 -0500

Yes to all 5 rules, but with the tweak that the alternative "lighter weight mechanism" is too poorly specified to be considered at this time.

Thank you for your concrete path forward.
John

At 09:50 AM 1/22/2003, Thomas Narten wrote:
>Should the ID recommend that LL addresses only be configured as per
>   below. 
>
>   a) yes, I think this is what the document should say (maybe 
>      with some small tweaks, which then need to be explained)
>
>   b) no, this is a showstopper for me (and explain why, so the 
>      rest of the WG can understand and then agree or disagree 
>      with your position)
>
>> 1 when should an IPv4LL address be configured by a host?
>
>>   suggest: if the host is explicitly configured to do so, OR if the 
>>   host has attempted and failed to acquire a routable address via DHCP
>
>>   (alternative: provide a lighter weight mechanism by which a host 
>>    can acquire a routable address, netmask, and default route, in 
>>    response to its attempt to claim an IPv4LL address)
>
>> 2 when should an IPv4LL address be used by a host as a source address?
>
>>   addresses, OR when the application has explicitly specified the 
>>   source address to use, OR when the application has explicitly 
>>   specified the interface to use and the IPv4LL address is the 
>>   only address associated with that interface.
>
>> 3 when should a host honor an attempt to connect to an IPv4LL 
>>   address that was once configured by that host?
>
>>   suggest: anytime the address is still valid (e.g. there have 
>>   been no conflicting claims) and there is a process listening 
>>   for connections either specifically to that address or
>> 4 when should an application attempt to connect to a IPv4LL address?
>
>>   suggest: only when the address is literally specified, 
>>   or if there are no other routableaddresses for the destination 
>>   host known to the application.
>
>> 5 when should an application send an IPv4LL address in a referral 
>>   to another host?
>
>>   suggest: only when there are no routable addresses for the 
>>   destination host known to the application.  
>>   Even then, care needs to be taken that a host reached at a particular 
>>   IPv4LL address is really the one intended - since IPv4LL addresses 
>>   can be reassigned without notice and/or reused on different network 
>>   segments.

---

From: Thomas Narten <[email-masked]>
Date: Wed, 22 Jan 2003 10:11:42 -0500

> intervention by the user.

To be 100% sure I understand, are you saying that devices should
always configure a LL address (whether or not they have a global
address), and it is fine for a device to configure and use both
simultaneously?

Thomas

---

From: "John C. Welch" <[email-masked]>
Date: Wed, 22 Jan 2003 10:16:05 -0500

> address), and it is fine for a device to configure and use both

yes

john

-- 
John C. Welch
Consultant III
Administrative Computing
(617) 253 - 1368 work
(508) 579 - 7380 cell
bynkii2          AIM

---

From: Robert Elz <[email-masked]>
Date: Wed, 22 Jan 2003 22:26:45 +0700

Date:        Wed, 22 Jan 2003 09:50:01 -0500
    From:        Thomas Narten <[email-masked]>
    Message-ID:  <[email-masked]>

  | So, I would like to ask the WG to answer the following questions:
  | 
  | 1) Should the ID recommend that LL addresses only be configured as per
  |    below. Please answer clearly, along the lines of
  | 
  |    a) yes, I think this is what the document should say (maybe with
  |       some small tweaks, which then need to be explained)

Yes

With tweaks, as below...

  | > - when should an IPv4LL address be configured by a host?
  | 
  | >   suggest: if the host is explicitly configured to do so, OR
  | >   if the host has attempted and failed to acquire a routable
  | >   address via DHCP

This needs to be adjusted to make it clear that "failed to acquire"
isn't "was refused an address" but means "found no-one able to
allocate addresses" (and "routable" is unnecessary - a 1918 address
is just fine too - in fact any address the DHCP server decides to
assign is just fine, if any at all, if there's an operating DHCP server).

Also, add "OR is configured to do so via DHCP", so even if a DHCP
address is assigned, or explicitly not assigned, the DHCP server can
tell the device to go ahead and allocate itself a LL address.

(No objection if there is support for the DHCP option being inverted
so an explicit option is required to prevent hosts assigning themselves
LL addresses).

  | > - when should an IPv4LL address be used by a host as a source address?
  | 
  | >   suggest: when the only addresses available to the host are IPv4LL addresses, OR
  | >   when the application has explicitly specified the source address to use, OR
  | >   when the application has explicitly specified the interface to use and the IPv4LL address
  | >   is the only address associated with that interface.

This isn't going to work in many cases - a host with a global address on
one interface, and only LL on another, wanting to talk to a LL device on
the LL interface, almost certainly shouldn't be using its global address
as the source address - sometimes that will work (if the host is willing
to answer ARP on the "wrong" interface), but it isn't reliable.

If there's no specified source address, the stack should work like stacks
tend to do now, and assign an address from the interface through which the
packet is to be sent - then if that interface happens to have both LL and
other address, take the other.

The rest are fine as Keith wrote them I believe.

kre

---

From: Keith Moore <[email-masked]>
Date: Wed, 22 Jan 2003 10:34:44 -0500

On Wed, 22 Jan 2003 07:32:41 -0500
"John C. Welch" <[email-masked]> wrote:

> >> WHY do you need to have printers with routable, global addresses in
> >all> cases? Normally, you don't.
> > 
> > You might or might not want your printers to be potentially
> > accessible from anywhere in the world (mine are and it really can be
> > quite useful).
> 
> I didn't say they weren't. I said it wasn't the majority case. 

Perhaps being able to access your printer from anywhere in the world is currently unusual, but this may also change - as better print spooling protocols (with useful authentication) are deployed, there is no inherent need to restrict who can access the printer based on the source address.  And print spooling with appropriate authentication is a much better way of transferring high-quality documents than fax.

And it's certainly not the majority case that access to networked printers is restricted to the local link.  The local subnet, perhaps, but not the local link.

> > But there's no real reason to assume that a printer need only be
> > accessible from the local link.  If I want to use my palm pilot with
> > a CDMA connection to print a file from the workstation in my office,
> > to a printer in the same room as I am, that's a very convenient and
> > perfectly reasonable thing to do.
> 
> Right...because it's far easier than doing a sync and using
> Ethernet.

The document never touches my palm pilot.  I'm just using it as a terminal to cause the document to be spooled from another remote host.

> and what I'm saying is, consider that an LL -
> only device would not be some bizarre abberation, but a common
> potential.

And what I'm saying is, it's not a very useful potential.  Restricting access to the local link means that you have to organize your network topology so that every device that needs to access something is on the same link as all of the things it needs to access.  Far better to let the network decide what things the device can access (for the managed case) and you can still have LL for the unmanaged ad hoc networks.

> > Even that only makes sense if either the local link and the realm
> > behind the NAT are identical, or the realm from which you want to be
> > able to print happens to be some subset of the local link.
> 
> I've dealt with a LOT of companies that have printers for each work
> group, and due to chargebacks, you aren't *allowed* to print on
> someone else's printer.

That's fine for them if they want to do things that way, but it's not a justification for forcing large numbers of networks and applications every to have to worry about link scope.

If the network admin wants the device to be limited to link scope, he simply arranges for the device to have no default route, and/or for the device's traffic to be filtered.  Or he can just have the network not respond to the device's request for an address and let the device default to LL.  In other words, LL will still be available for those managed networks that want to use it.

> > Devices that aren't explicitly configurable have to accept whatever
> > the network tells them to do.  If the network admin (whether by DHCP
> > or some other mechanism) wants to tell different devices to do
> > different things, based on their MAC addresses or whatever, that's
> > his business.
> 
> But earlier you said that it should be manually overridable...so
> again, What do you do about situations that don't fit your model?

no, I said that for devices that are explicitly configurable, local configuration needs to take precedence over network configuration or LL.
if the network admin wants to prevent such devices from talking outside of a particular scope, he/she needs to install filters, just as for any other configurable host.  this is nothing new.

OTOH, for devices that aren't explicitly configurable, it's useful if the network admin can provide minimal configuration over the network.  again, this is nothing new - except that it would be nice to have a clean mechanism for allowing a device to automagically "do the right thing" on either a managed network or an unmanaged network, and one with less code overhead than requiring the device to implement DHCP.

> > Of course the point isn't to insist that all devices be accessible
> > from everywhere, but to avoid building limitations into devices that
> > are unnecessary and which aren't a good match to users' needs.
> 
> But you assume that global accessibility is always wanted or needed,
> and that simply isn't true. 

no I don't assume that, and if you take the trouble to read what I wrote, it's obvious that I don't assume that.

---

From: Keith Moore <[email-masked]>
Date: Wed, 22 Jan 2003 10:36:01 -0500

> But since reality shows that WON'T happen, we need to deal with > *reality* not "What we dream about"

whenever someone insists on dealing with reality, what they generally mean is "you should accept my delusions as truth".

---

From: Keith Moore <[email-masked]>
Date: Wed, 22 Jan 2003 10:41:30 -0500

> > In none of these cases is it necessary that the printer is LL only
> > by design.
> 
> But what about when it happens. Or some other device that we don't
> know about yet? Maybe a home MP3 server?

I definitely want my home mp3 server to be able to talk to my car,
which will not be on the same link.

you are grasping at straws.  there is no good reason for a device to assume that its access should be limited to the local link.

---

From: "John C. Welch" <[email-masked]>
Date: Wed, 22 Jan 2003 10:47:05 -0500

On 01/22/2003 10:41, "Keith Moore" <[email-masked]> wrote:

> you are grasping at straws.  there is no good reason for a device to assume
> that its access should be limited to the local link.

There is no logic in assuming that there won't be either.

john

-- 
John C. Welch
Consultant III
Administrative Computing
(617) 253 - 1368 work
(508) 579 - 7380 cell
bynkii2          AIM

---

From: "John C. Welch" <[email-masked]>
Date: Wed, 22 Jan 2003 10:46:12 -0500

On 01/22/2003 10:36, "Keith Moore" <[email-masked]> wrote:

> whenever someone insists on dealing with reality, what they generally mean is
> "you should accept my delusions as truth".

In my case, it means "I'm absolutely cynical about people doing the right
thing. I assume they won't, and it is *far* better to deal with it now, than
hope for the best and get burned yet again"

The Kerberos folks learned this the hard way.

john

-- 
John C. Welch
Consultant III
Administrative Computing
(617) 253 - 1368 work
(508) 579 - 7380 cell
bynkii2          AIM

---

From: "Philip Nye" <[email-masked]>
Date: Wed, 22 Jan 2003 16:00:25 -0000

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

Yes

With tweaks exactly as outlined by Robert Elz (22 Jan 2003)

Philip Nye

---

From: Scott Lawrence <[email-masked]>
Date: 22 Jan 2003 11:26:57 -0500

> 1) Should the ID recommend that LL addresses only be configured as per

Thank you, Thomas.

>   if the host has attempted and failed to acquire a routable address via DHCP

Agreed, but I think that 'a routable' should be changed to just 'an';
routing is not the issue here; getting some address is.  If I get a
non-routable 10.x.y.z address, I don't need a LL address.

>   is the only address associated with that interface.

Fine.

>   for incoming connections at any of the host's addresses.

I'm not sure why this needs to be said - it seems to me to be the
normal behaviour for an IP interface, but fine.

>   addresses for the destination host known to the application.

I think that this question should be 'when should a host use an IPv4LL
destination address?'.  The answer given is fine.

>   without notice and/or reused on different network segments.

I think that both this and the previous question are obvious to any
reasonable person who understands what a link-local address means, but
if the WG feels that explicit text for this case is needed, fine.

---

From: "Subrata Goswami" <[email-masked]>
Date: Wed, 22 Jan 2003 08:23:52 -0800

Yes to 1.
No  to 2,3,4,5 as they are unduly restrictive, confusing in multiple
interface hosts, and requires the hosts to be more intelligent then they
need to be.

> [mailto:[email-masked]] On Behalf Of John Schnizlein
> Sent: Wednesday, January 22, 2003 7:13 AM
> To: Thomas Narten
> Cc: [email-masked]
> Subject: Re: WG decision: when to configure LL addrs
> 
> 
> Yes to all 5 rules, but with the tweak that the alternative 
> "lighter weight mechanism" is too poorly specified to be 
> considered at this time.
>

---

From: Ted Lemon <[email-masked]>
Date: Wed, 22 Jan 2003 10:13:27 -0800

> what to return, and if there's a global address, I'd suggest, returning

In order for mDNS to be really useful, gethostbyname("foo.local.") has 
to work.   So unfortunately your reasoning here doesn't work.

> person takes responsibility for that).

DHCP doesn't provide a protocol message that says "I'm here, but I'm 
not going to give you an IP address."   So a client that can't contact 
a DHCP server has no way of telling whether this is because there is no 
DHCP server, or because the DHCP server doesn't like it.

---

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

> In my case, it means "I'm absolutely cynical about people doing the
> right thing. I assume they won't, and it is *far* better to deal with
> it now, than hope for the best and get burned yet again"

I share your cynicism about people doing the right thing.  But if we don't do the right thing when we ship a spec (which means to give due consideration to how it will affect IP applications, networks, and users), how can we even hope to avoid giving people even more difficult choices down the road, where the "right thing" will not be nearly so obvuious?

---

From: Keith Moore <[email-masked]>
Date: Wed, 22 Jan 2003 13:19:27 -0500

> > there is no good reason for a device to assume

actually there is plenty of reason to assume that - it is almost never the case today that a single link is chosen as a trust boundary, and with greater use of wireless it becoming less and less useful to assume that network topology has anything to do with trust boundaries.
-- 
I tried enlightenment but it kept crashing.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 22 Jan 2003 10:24:44 -0800

>>   if the host has attempted and failed to acquire a routable address 

This doesn't satisfy me because it requires that an arbitrary delay 
before I can use my zeroconf network.   I say arbitrary because the 
DHCP protocol doesn't really say how to determine that the client is 
not going to win, so the delay here could be anywhere from three 
seconds to five minutes or longer.   Zeroconf should Just Work, and in 
order for that to happen, the delay here has to be short.   I would be 
satisfied if the delay were shorter than ten seconds.

>> destination host known to the
>> can be reassigned

How about only when the IP destination to which the referral is being 
sent is an IPv4LL address?   If you send the referral to a routable IP 
address that may be on another network, it's quite possible that the 
referral could *work* on that remote network - to connect to an IPv4LL 
address on that remote network.

---

From: "John C. Welch" <[email-masked]>
Date: Wed, 22 Jan 2003 13:35:43 -0500

On 01/22/2003 13:18, "Keith Moore" <[email-masked]> wrote:

> I share your cynicism about people doing the right thing.  But if we don't do
> the right thing when we ship a spec (which means to give due consideration to
> how it will affect IP applications, networks, and users), how can we even hope
> to avoid giving people even more difficult choices down the road, where the
> "right thing" will not be nearly so obvuious?

That's why I like manual only control...it is a simple, yet flexible way to
make us both, (and we are kind of the poles in this imbroglio) happy.

john

-- 
John C. Welch
Consultant III
Administrative Computing
(617) 253 - 1368 work
(508) 579 - 7380 cell
bynkii2          AIM

---

From: Ted Lemon <[email-masked]>
Date: Wed, 22 Jan 2003 10:43:53 -0800

> intervention by the user.

v4LL communication _is_ always available, even if you don't have a v4ll 
IP address, IF YOUR STACK SUPPORTS IT.   I think this is the disconnect 
that's causing a lot of this back-and-forth.   There are two referents 
for the phrase "v4ll is enabled."   The first is, the stack is allowed 
to and does acquire a v4LL IP address.   The second is, the stack is 
able to communicate with devices that have a v4LL IP address.   I think 
that to some degree you have been confusing these two meanings.

This is understandable, because we are talking about disabling the 
acquisition of v4ll addresses on links.   In the case you describe, if 
the DHCP server is following the standard, but only has one address to 
allocate to you, what will happen is that it will assign an IP address 
to whichever device requests it first - your printer, or your computer. 
   The other device will hear no response from the DHCP server, and thus 
will just use IPv4ll.   If you are lucky, the device that gets the 
routable address will be your computer.

So to make this scenario work, you need two things:

1. You need the IP stack on your computer to support communicating with 
v4ll devices when it has a routable address.
2a. You need to be able to configure your printer not to attempt DHCP, 
and instead only use v4LL, or
2b. You need to convince your ISP to give your one IP address to your 
computer (many ISPs do this by default anyway, even though it's not 
specifically recommended in rfc2131).

I think in your scenario you are assuming 2b, and so things will Just 
Work.   But 2b isn't standardized, nor is it a given, so in fact the 
situation you describe is likely not to Just Work.

---

From: Joshua Graessley <[email-masked]>
Date: Wed, 22 Jan 2003 10:46:42 -0800

>    c) Not my first choice, but I can live with it.

A. My only comment is that the alternative from the first section 
should be dropped entirely.

>> can acquire a
>> addresses, OR

---

From: Luke Diamand <[email-masked]>
Date: Wed, 22 Jan 2003 18:48:39 +0000

Ted Lemon wrote:
> Zeroconf should Just Work, and in order for 
> that to happen, the delay here has to be short.   I would be satisfied 
> if the delay were shorter than ten seconds.

I thougt an earlier poster made the point that if you try to acquire a 
V4LL address on a network bridged using a spanning tree bridge, you 
*have* to wait for 45 seconds while the spanning tree algorithm does 
its thing.

Otherwise you might well pick an address that's already in use on the 
other side of the bridge.

I think you are going to have to live with the existing delay of a 
minute (or thereabouts) unless you can find a way to (manually?) turn 
it down if you know that spanning tree bridge is not in use on this 
network.

Luke Diamand

---

From: Keith Moore <[email-masked]>
Date: Wed, 22 Jan 2003 13:54:54 -0500

> v4LL communication _is_ always available, even if you don't have a
> v4ll IP address, IF YOUR STACK SUPPORTS IT.   I think this is the
> disconnect that's causing a lot of this back-and-forth.   There are
> two referents for the phrase "v4ll is enabled."   The first is, the
> stack is allowed to and does acquire a v4LL IP address.   The second
> is, the stack is able to communicate with devices that have a v4LL IP
> address.   I think that to some degree you have been confusing these
> two meanings.

it's even better if v4LL doesn't get used at all in those cases where the network is willing to assign addresses to hosts.

actually it's hard to imagine why a managed network would prefer use of v4LL addresses when it can explicitly control the scope of addresses that it assigns.  v4LL seems far less reliable.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 22 Jan 2003 11:21:23 -0800

> *have* to wait for 45 seconds while the spanning tree algorithm does 

This kind of spanning tree delay also breaks DHCP.   It has to be 
disabled in order to make DHCP work.   We get support questions about 
this pretty frequently, and indeed the new version of the DHCP Handbook 
has a specific note about this in the debugging chapter.   AFAIK it 
only works reliably with a completely manually-configured network.

---

From: Aidan Williams <[email-masked]>
Date: Thu, 23 Jan 2003 11:40:12 +1100

>       some small tweaks, which then need to be explained)

Mostly, yes.  Some tweaks.  Some of it seems to re-write/re-word text
that is already in the draft.

>>  if the host has attempted and failed to acquire a routable address via DHCP

The word "routable" is not relevant and should be dropped.
A host may also choose not to use DHCP and use a LL address instead,
but perhaps that is adequately covered by "explicitly configured".

>>  is the only address associated with that interface.

I don't agree with the "only address associated with the interface" part.
If you *have* an IPv4-LL address it should be used when connecting to
IPv4-LL destinations.
I'm happy with Section 2.6, "Source Address Selection" as it is.

>>  for incoming connections at any of the host's addresses.

This seems needlessly verbose.  Stating that connections should only
succeed to the current valid address seems enough.

There is existing text in the draft which suggest that existing
connections to LL addresses should continue to work when a DHCP
server becomes available (Section 1.5, Supporting Multiple
Addresses per Interface).  I think that is reasonable and should
remain.

>>  addresses for the destination host known to the application.

Literally specified?  By whom?

I would be happier with:

   An application with a choice between connecting to LL address and
   non-LL address SHOULD prefer the non-LL address.

>>  without notice and/or reused on different network segments.

Most of these issues seem to be covered already.

   Section 7.2, Limited Forwarding of Locators
   Section 7.3, Address Ambiguity
   Section 2.9, Higher-Layer Protocol Considerations

A host always need to take care the host reached at a particular address
is really the one intended.  The IPv4-LL case is a difference in degree
only.  The "correctness" or "stability" of the name to address mapping
seems much more important to me and that is out of scope of this document.

- aidan

---

From: Ian Lister <[email-masked]>
Date: Thu, 23 Jan 2003 11:40:38 +1000 (EST)

>1) Should the ID recommend that LL addresses only be configured as per

Generally, yes.

As others have pointed out, there should probably be some tweaks to the
use of the term `routable addresses', and the `alternative' from the first
section is not required.

Most of the subsequent comments from other people seem OK, but I'm not
convinced by Robert Elz's argument for disabling IPv4LL when a DHCP server
exists but does not assign an address.

(The point about picking a source address based on the interface the
packet will be sent on is fine, though)

Ian

---

From: Ralph Droms <[email-masked]>
Date: Wed, 22 Jan 2003 20:43:18 -0500

>       some small tweaks, which then need to be explained)

Yes, with changes as suggested below.

> >   if the host has attempted and failed to acquire a routable address 

"Routable" may not be clear, here.  Is routable == non-LLv4?  Or routable 
== non-RFC1918?  I would suggest just dropping "routable".

"Failed to acquire" may also be problematic, as RFC2131 does not give a 
precise definition of when to declare DHCP "failed".  How about "until the 
host has successfully obtained an address through DHCP"?

> >    routable address, netmask, and default route, in response to its 

This proposed alternative is a red herring; consideration of it will lead 
only to more rat-holing.  DHCP is here, it's been deployed for years and 
nobody has had a well-defined set of requirements and strong enough 
motivation to come up with something "lighter weight", yet.

> >   is the only address associated with that interface.

When the only addresses available to the host are IPv4LL addresses.

> > 3 when should a host honor an attempt to connect to an IPv4LL address 
> that was once
> >   configured by that host?
>

When the only addresses available to the host are IPv4LL addresses.

> >   addresses for the destination host known to the application.

I agree with the suggested text.

> > 5 when should an application send an IPv4LL address in a referral to 
> another host?
>

I agree with the suggested text.

---

From: Ralph Droms <[email-masked]>
Date: Wed, 22 Jan 2003 22:17:02 -0500

Seems to me LLv4 is a short-term solution that will not serve in the long 
run - assuming the long run is homes, offices and other sites with multiple 
links connected by routers.  In fact, LLv4 might turn out to be an obstacle 
to progress, as it might encourage bridging or some other way of flattening 
networks for LLv4.  I can imagine a future in which LLv4 addresses are 
bridged across an entire site - to allow use of LLv4-only devices across 
the entire site - while non-LLv4 addresses are routed in the familiar way.

"Simplification" without looking at wider impact sounds like a variant of 
the NAT-virus to me.

- Ralph

---

From: Rod <[email-masked]>
Date: Wed, 22 Jan 2003 20:59:49 -0600

>       some small tweaks, which then need to be explained)

I Agree. Eliminating "routable"  from the first part, as well as the 
"lighter weight mechanism."

I also like Aidan's suggestion of:

"An application with a choice between connecting to LL address and
   non-LL address SHOULD prefer the non-LL address."

instead of what was previously suggested.

Also:

> addresses

Shouldn't this read "when the only addresses available to the host on 
that interface are IPv4LL addresses?"

It wouldn't make sense to send the host's global address if it's on a 
different interface than the one communicating with the LL device.

Still, I disagree.

I agree with Aidan, that if a host has an IPv4LL address, it should use 
that to communicate with an IPv4LL destination, even if it's not the 
only address specified for that interface.

I disagree with Robert Elz's suggestion that if a host was refused an 
address it should not configure an IPv4LL address, since it's both 
unfeasible at the moment and pointless, as one can assign a manual IP 
address anyway.

-Rod Lopez

---

From: Aidan Williams <[email-masked]>
Date: Thu, 23 Jan 2003 14:30:42 +1100

Keith Moore wrote:
>>is really the one intended. 
> 
> There's no way that a host can know this, because the only identifier that a
> host has to recognize another host is the IP address, which is precisely what
> is ambiguous.  If the application has a better identifier which is independent
> of the IP address, the application may be able to verify the identities of its
> peers. However most application protocols don't have a mechanism for doing
> this.
> 

Great!  Then I would be happy to dispense with this text entirely:

   > even then, care needs to be taken that a host reached at a
   > particular IPv4LL address is really the one intended

There are plenty of scenarios where non-IPv4LL IP addresses change
frequently.  Cryptographic techniques are the only real answer to
authenticating identity and those techniques can be applied over
the top of IPv4-LL if necessary.

> 
>>The IPv4-LL case is a difference in degree
> The stability of the name-to-address binding and the stability of the
> address-to-host binding are two separate issues which are easily confused.  
> Either binding can change independently of the other.  This document only
> deals with the address-to-host binding, but both bindings are relevant,
> because a change to either binding will generally cause the application to
> fail.

I disagree with you on the emphasis you place on address stability.
I think IPv4-LL addresses are likely to be more stable in a given
environment that you give them credit for.  I also think that the
stability of link-local addresses is less important than you seem
to believe.

I am not inclined to rat-hole further on the subject.

- aidan

---

From: Keith Moore <[email-masked]>
Date: Wed, 22 Jan 2003 22:12:26 -0500

On Thu, 23 Jan 2003 11:40:38 +1000 (EST)

> use of the term `routable addresses', and the `alternative' from the first

note that 'routable' was intended in the sense that it is used in the current
LL draft - it doesn't mean global, it means something that can be routed.  LL
addresses cannot be routed, not even within a private network.  RFC 1918
addresses can be routed, just not on the public internet.

as for the 'alternative' - I'd be curious to hear from those who want to use
this for simple plug-and-play fixed-function devices whether they think a
requirement to implement DHCP is too onerous.

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 22 Jan 2003 22:09:50 -0500

clarification here:

> >>  suggest: only when the address is literally specified, or if there are
> >no other routable>  addresses for the destination host known to the
> >application.
> > 
> 

by a user.  in other words, if for some reason a user types in a v4 address
literal (and there are indeed times when this is appropriate), the application
should honor it.  I certainly don't want the standard to forbid talking to a 
v4LL address that was explicitly specified by a user.

>    non-LL address SHOULD prefer the non-LL address.

that is certainly more brief, and it might be sufficient.

> >>  suggest: only when there are no routable addresses for the destination
> >host known to the >  application.  even then, care needs to be taken that a
> >host reached at a particular>  IPv4LL address is really the one intended -
> >since IPv4LL addresses can be reassigned>  without notice and/or reused on
> >different network segments.
> 
>

---

From: Keith Moore <[email-masked]>
Date: Wed, 22 Jan 2003 22:57:58 -0500

On Thu, 23 Jan 2003 14:30:42 +1100
Aidan Williams <[email-masked]> wrote:

> > There's no way that a host can know this, because the only identifier that
> > a host has to recognize another host is the IP address, which is precisely
> > what is ambiguous.  If the application has a better identifier which is
> > independent of the IP address, the application may be able to verify the
> > identities of its peers. However most application protocols don't have a
> > mechanism for doing this.
> > 
> 

It depends on your point-of-view.  If you're implementing IPv4LL in a host
stack, there's nothing you can do about the potential for address-to-host
bindings changing.  If you're implementing an application with a pre-defined
protocol, there's not likely to be much you can do about it.  If you're
designing a new application and you want it to be tolerant of v4LL addresses,
you can do a bit more.

> frequently. 

Yes- misconfigured DHCP servers, and hosts with intermittent dialup
connections
where the connections fail often.  Often the DHCP servers can be fixed, and we
tend to not expect dialup connections to support long-running appliations.

But basically the fact that LL can introduce additional failures due to
changing address-to-host bindings does not bother me much as long as we don't
use LL except on isolated networks.  It's when LL is touted as suitable for
general-purpose use (e.g. as a replacement for DHCP) that I get concerned.  Ad
hoc networks are always going to be somewhat less functional than their
managed cousins, and there's simply no way for a configurationless, isolated
v4
network to assign a unique address that isn't subject to change.  

So I accept the current limitations of v4LL address stability as the best that
can be done given the available address space in v4, and (regarding stabliity)
I mostly ask that we don't use v4LL addresses when better addresses are
available, and we don't try to pretend that v4LLs are as (stable, useful,
unambiguous) as v4 addresses assigned by a managed network.

> stability of link-local addresses is less important than you seem

Again, it depends on what you are doing.  The current draft is probably about
as good as we can do at providing automatic assignment of stable addresses in
v4.  At the same time, if you are writing a distributed application, or an
application that uses long-lived connections, it cannot so easily be dismissed
as unimportant.

Keith

---

From: Scott Lawrence <[email-masked]>
Date: 22 Jan 2003 23:23:13 -0500

> requirement to implement DHCP is too onerous.

That's a space I've spent a lot of time in the last several years.

No, I don't, which is part of why I thought developing an alternative
was not a good idea.  A very constrained implementation could dispense
with recognizing most options, since only a few would be relevant.  In
effect, it could be BOOTP with lease timers.  I doubt that many
product managers would choose to have thier devices ignore DHCP in any
event, because they wouldn't want to risk not being able to
communicate with devices that couldn't figure out that the LL address
was reachable (as simple as that is, I certainly wouldn't bet against
someone having gotten it wrong).  As has been pointed out, in this
sort of product one support call can more than wipe out the profit on
the sale; it's gotta just work.

---

From: Keith Moore <[email-masked]>
Date: Wed, 22 Jan 2003 22:59:38 -0500

> only address specified for that interface.

have to disagree here.  there should be as little use of v4LL addresses as
possible, because the more exposure of such addresses, the greater the
potential for them to leak outside of their realms.

---

From: Aidan Williams <[email-masked]>
Date: Thu, 23 Jan 2003 16:11:30 +1100

> potential for them to leak outside of their realms.

Danger Will Robinson!  Danger!

Since we'll be preferring globals, again I think that the problem
is much larger in your head than in real life.

Once again, lets agree to disagree and stop ratholing.

- aidan

---

From: Erik Guttman <[email-masked]>
Date: Thu, 23 Jan 2003 10:25:32 +0100 (CET)

Thomas,

Yes.
 
>       some small tweaks, which then need to be explained)

I agree, after consideration and voluminous reading.  

The arguments for keeping an IPv4LL address configuration despite having
a global one are weak if one considers that the host supporting IPv4LL
already has to support address renumbering.  If a host can already find
a peer and continue communicating with it despite IPv4LL address
renumbering events (using service discovery or a multicast name
resolution protocol), the hosts should be able to transition to
communication via IPv4 global addresses as well.

Thanks for your intervention, Thomas.

Erik

---

From: "Philip Nye" <[email-masked]>
Date: Thu, 23 Jan 2003 09:56:39 -0000

> From: "Aidan Williams" <[email-masked]>
>

There is an issue with scoped addresses which goes beyond address stability
over time. Namely that many applications have no way of knowing what the
scope of the address is or what the "viewpoint" of another host is. This
causes a breakage mode in distributed apps - if I refer you to a third party
X, you may successfully contact a different X to the one I can see - while
both Xs have stable addresses.

Philip

---

From: Robert Elz <[email-masked]>
Date: Thu, 23 Jan 2003 22:34:47 +0700

Date:        Wed, 22 Jan 2003 10:13:27 -0800
    From:        Ted Lemon <[email-masked]>
    Message-ID:  <[email-masked]>

Answering two of your messages in one reply, to try and keep this
list a little quieter....

  | In order for mDNS to be really useful, gethostbyname("foo.local.") has 
  | to work.   So unfortunately your reasoning here doesn't work.

Of course, but I think you missed my point.   If mDNS is used, the host
owning the name supplies the address to be used - if it has a non-LL
address, it should just supply that one - we don't need to have gethostbyname()
do some rule based algorithm to handle things.

  | DHCP doesn't provide a protocol message that says "I'm here, but I'm 
  | not going to give you an IP address."   So a client that can't contact 
  | a DHCP server has no way of telling whether this is because there is no 
  | DHCP server, or because the DHCP server doesn't like it.

That's a good point.   I should know enough about DHCP to have known that.

So, I guess we can't have a "I'm here but I'm not going to give you an
address, and you should not use v4LL either" mode, and so clearly no
language like that in the doc is required.

I guess the functionality can always be had by having the DHCP server
assign 0.0.0.0 or 127.0.0.1 as the address though...

Even if the client decides to DHCPNAK (or ignore the DHCPOFFER) then
at least it knows there is a DHCP server out there that can assign addresses.
In that case, it should not give itself a LL address (if the DHCP
message included the "no LL" option, or didn't include the "allow LL"
option, depending which way that question goes).

[email-masked] said:
  | This doesn't satisfy me because it requires that an arbitrary delay
  | before I can use my zeroconf network.

For zeroconf you have to have that, because of the spanning tree problem.

If you go and assign yourself an address, you're quite likely going to
get a duplicate (sometimes anyway) and so cause problems to some other
innocent device, for no good reason at all (this is much more common than
the "two isolated halves of a link reconnecting" issue that can also cause
problems).

So, unless the node can be *certain* that there cannot possibly be something
running the spanning tree algorithm, it must wait long enough for that to
have completed before it decides that there is no other user of the address
it wants.

You said in yet another message that this breaks DHCP too.   It doesn't.
It breaks some clients, that don't wait long enough to receive an offer.
If the client just keeps on doing its DISCOVER eventually (server able and
willing) an offer will appear.   Nothing actually breaks here.

Even in the face of impatient client code however, the only breakage is
to the client itself.   That's relatively harmless.

kre

---

From: "Philip Nye" <[email-masked]>
Date: Thu, 23 Jan 2003 15:44:03 -0000

> language like that in the doc is required.

Digging around in DHCP I found RFC2563 which appears to give precisely this
message.
Is it no longer valid?

Philip

---

From: "John C. Welch" <[email-masked]>
Date: Thu, 23 Jan 2003 11:35:51 -0500

> Digging around in DHCP I found RFC2563 which appears to give precisely this

The problem here, and with relying solely on DHCP for this is
implementation. There are a lot of options within DHCP that may not be
included with a server, or turned on if included. It may not be desireable,
but that's the way things go, and it's unrealistic to expect that you can
force anyone to implement every option of everything unless it's required.

With that in mind, how about including two methods...DHCP shutdown with a
manual override. That way, the network manager/user can avoid any problems
due to the idiot neighbor kid discovering phrack as an alternative to
pulling wings off of flies.

john

-- 
John C. Welch
Consultant III
Administrative Computing
(617) 253 - 1368 work
(508) 579 - 7380 cell
bynkii2          AIM

---

From: Scott Lawrence <[email-masked]>
Date: 23 Jan 2003 11:48:21 -0500

> Digging around in DHCP I found RFC2563 which appears to give precisely this

The RFC Editor lists it as Proposed Standard status with no updates or
obsoletes... seems to me that all this debate could be resolved by
just putting a reference into the current draft to that and removing
any conflicting text we have now.

Personally, I don't agree that a DHCP server should be able to both
deny my system an address and prevent me from allocating a LL address,
and if building a product would likely just ignore the prohibition.
If that increased the likelyhood that my product would work for some
circumstances, I would happily trade that for not being able to claim
perfect conformance.

---

From: "Philip Nye" <[email-masked]>
Date: Thu, 23 Jan 2003 17:04:13 -0000

> circumstances, I would happily trade that for not being able to claim

Of course a network administrator who wanted to deny access to your devices
would have to go a lot further than simply turning on a DHCP option.
However, it might be an indication that having got your IP anyway, you are
likely to find it of very limited use. DHCP is generally your first point of
contact with local network policy.

I notice that section 2.2 of RFC2563 only _requires_ a client which is
refused an IP to examine this option. However, a client granted an IP could
also examine the option to see if it should get a LL address as well
(although the only good argument I have seen here as to why a host with a
global address should want both is one of continuity of existing
connections).

This RFC certainly looks very relevant to the IPv4LL draft which should
probably reference it in some way.

Philip

---

From: Scott Lawrence <[email-masked]>
Date: 23 Jan 2003 12:08:08 -0500

> the "two isolated halves of a link reconnecting" issue that can also cause

You and I seem to have a very different notions of 'quite likely'.  If
I did my math right (probablility is not my strong suit - someone
correct me please if I've gotten this wrong), there's slightly less
than a 1% chance on a link with 50 nodes on it.  So, given that:

- Nodes on the same link off the ST bridge will detect collisions
  immediately, so that the above <1% is only a problem when there are
  50 nodes on other links off the same ST bridge.

- Collision detection will step in as soon as the bridge concatentates
  the links and fix this situation.

I'll take my chances and make a better user experience by not
waiting for a bridge that may not even be there. 

--
Scott Lawrence        
  http://world.std.com/~lawrence/

---

From: Joshua Graessley <[email-masked]>
Date: Thu, 23 Jan 2003 10:40:15 -0800

> circumstances, I would happily trade that for not being able to claim

I agree whole heartedly with Scott. I think the idea that the mere 
existence of a DHCP server be a signal that IPv4LL should not be self 
assigned is a huge mistake. It would lead to things not working in 
cases where they otherwise could. I haven't seen a compelling argument 
for it. If the draft were changed to suggest such a ridiculous thing I 
would most certainly ignore that recommendation.

-josh

---

From: Keith Moore <[email-masked]>
Date: Thu, 23 Jan 2003 15:56:57 -0500

> > deny my system an address and prevent me from allocating a LL
> > address, and if building a product would likely just ignore the
> > prohibition. If that increased the likelyhood that my product would
> > work for some circumstances, I would happily trade that for not
> > being able to claim perfect conformance.
> 

what if there were a DHCP message that said "you don't have permission
to talk to this network"?  would you ignore that also?

---

From: Scott Lawrence <[email-masked]>
Date: 23 Jan 2003 16:06:12 -0500

> to talk to this network"?  would you ignore that also?

Yes.  As has been pointed out, such a message would be a perfect DOS
tool, and since systems that don't know about it (including such
common protocols as Netbios and Appletalk) will disregard it anyway, I
don't think it would actually be valuable as a management tool.

If a network owner really wants to control what packets are on the
network, only monitors with alarms and filters can hope to work.

---

From: Joshua Graessley <[email-masked]>
Date: Thu, 23 Jan 2003 13:11:43 -0800

> to talk to this network"?  would you ignore that also?

There is no such DHCP message, and such a message seems like it's 
outside the scope of this working group.

Off Topic:
If there were such a message, and our customers were asking for support 
or it made sense to us, we would certainly consider supporting such a 
thing. I would hope the DHC working group wouldn't attempt to tackle 
such a thing. It seems ridiculous to assume that a malicious client 
wouldn't just ignore the message.

-josh

---

From: Keith Moore <[email-masked]>
Date: Thu, 23 Jan 2003 16:20:53 -0500

On 23 Jan 2003 16:06:12 -0500
Scott Lawrence <[email-masked]> wrote:

> > what if there were a DHCP message that said "you don't have
> > permission to talk to this network"?  would you ignore that also?
> 

So if you're walking through an unfamiliar building and you see a sign
that says "NO TRESPASSING BEYOND THIS POINT", do you say to yourself
"I must assume I'm not permitted beyond this point"?

Or do you say to yourself "This sign is probably a forgery.  I'll just
keep going and see if something or somebody actually tries to stop me"?

What about if you're writing the code in a TCP stack that deals with
receipt of a SYN packet?   Do you assume that it's probably legitimate
and allocate a connection block, etc., or do you assume it's probably a
DoS attack and ignore it?  Yes, DoS attacks are possible, but what is
your default assumption?

Your code is not smarter than the network administrator.  It is not more
aware of network policy than the network.  It should not be trying to
second guess what the network is saying.

---

From: Keith Moore <[email-masked]>
Date: Thu, 23 Jan 2003 16:22:06 -0500

> If there were such a message, and our customers were asking for
> support or it made sense to us, we would certainly consider supporting
> such a thing. I would hope the DHC working group wouldn't attempt to
> tackle such a thing. It seems ridiculous to assume that a malicious
> client wouldn't just ignore the message.

do you think the purpose of protocol messages is to communicate to
malicious parties, or to communicate between cooperating parties ?

---

From: "Adam MacBeth" <[email-masked]>
Date: Thu, 23 Jan 2003 13:36:35 -0800

> > what if there were a DHCP message that said "you don't have
permission
> network, only monitors with alarms and filters can hope to work.

Exactly.  It's equally futile to have a message telling manually
configured hosts not to use a manually configured address.  Maybe
there's a reason such a message doesn't exist.

I really can't see how this is any different from a LL address in terms
of controlling its use.  Can't I just plug in my laptop and manually
configure an address?  How can the network admin stop me from doing
this?  If I have physical access to the network, I have access to the
local link at the very least.

It's possible that rogue (or misconfigured) hosts with manually
configured addresses could be detected and labeled as such based on
their IP address, whereas hosts with LL addresses can't really be
labeled as trusted, unless you want to use MAC address based access
control.  Is there any other difference?

---

From: Ted Lemon <[email-masked]>
Date: Thu, 23 Jan 2003 13:49:31 -0800

> second guess what the network is saying.

Actually, the NetBSD stack has code to detect SYN floods, and in fact 
does assume that when it receives a SYN, it's an attack.   Only when it 
gets the ACK to its SYN+ACK does it actually instantiate a tcp control 
block to manage the connection.   And it's careful about sequence 
numbers so that it's not easy to guess what the sequence number of its 
SYN+ACK will be.

I think this code originally came from BSD/os (it's been long enough 
since I integrated it that I can't remember anymore).   Linux probably 
has something similar.

We are coming to the point where in most cases the code has better 
heuristics than the network administrator, not so much because the code 
is really great, but because the lowest common denominator in system 
adminstration isn't very high (by which I do not mean to cast 
aspersions on sysadmins who are reading this - if you are reading this, 
you aren't part of the LCD).

---

From: Keith Moore <[email-masked]>
Date: Thu, 23 Jan 2003 16:50:33 -0500

> Can't I just plug in my laptop and manually configure an address? 

if a human user manually does something on a network without permission,
presumably that's a conscious action on his part and he can accept
responsibility for it.

otoh, if a specification or code writer breaks the network's rules
without the user doing anything to cause that, who is responsible then?

bottom line is network operators have reasons to restrict access to
their networks.  this group has no business trying to insist that they
have no right to do so, or that the mechanisms they are currently using
to do so are not valid.

---

From: Keith Moore <[email-masked]>
Date: Thu, 23 Jan 2003 16:55:21 -0500

> does assume that when it receives a SYN, it's an attack.   Only when
> it gets the ACK to its SYN+ACK does it actually instantiate a tcp
> control block to manage the connection.   And it's careful about
> sequence numbers so that it's not easy to guess what the sequence
> number of its SYN+ACK will be.

well, if you can write code so that a device that gets a DHCP response
does the right thing no matter whether the DHCP message is legitimate or
a forgery, my hat's off to you. 

but I don't buy the idea that the host has a right to run LL whether the
network wants it to or not.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 23 Jan 2003 13:56:16 -0800

> would most certainly ignore that recommendation.

There's a problem in the draft, which I've mentioned several times 
here, but which nobody has commented on (this is from section 2.6):

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

If this MAY were a MUST, your complaint would not be valid.   That is, 
if this MAY were a MUST, we could be sure that all IPv4ll-aware stacks 
would be able to interoperate with all other IPv4ll stacks on the same 
wire, regardless of whether any given stack was configured with a 
non-IPv4ll IP address.   Because this is a MAY, your objection is valid.

That is, because this says "MAY", you are right that things may not 
work in the case where one stack is configured with a non-IPv4ll 
address and the other is not.   It depends on whether or not the 
implementor decides to implement this optional functionality.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 23 Jan 2003 14:03:30 -0800

> do some rule based algorithm to handle things.

Does the mDNS spec say that this is what should happen?   Does the 
IPv4ll spec say it?   :'}

---

From: Ted Lemon <[email-masked]>
Date: Thu, 23 Jan 2003 13:59:46 -0800

> Digging around in DHCP I found RFC2563 which appears to give precisely 

It passed through the DHC working group a few years ago, but AFAIK 
nobody implemented it, and it's not referenced by anything.   Last time 
it was discussed in the DHC working group, nobody was willing to defend 
its existence anymore.   It should probably be declared obsolete.

---

From: Keith Moore <[email-masked]>
Date: Thu, 23 Jan 2003 17:09:25 -0500

>     If the destination address is in the 169.254/16 prefix (including
>     the 169.254.255.255 broadcast address), the host SHOULD use its
>     link- local source address, if it has one. If the host does not
>     have a link-local source address, then it MAY choose to ARP for
>     the destination address and then send its packet, with a routable
>     source IP address and a link-local destination IP address,
>     directly to its destination on the same physical link. The host
>     MUST NOT send the packet to any router for forwarding.
> 

mumble.  it shouldn't be expressed in MUST terms, because the protocol
for normal routing of packets to destinations isn't expressed in MUST
terms either.  

instead of MAY or MUST, say something like:

the way a host with a routable address sends a packet to an LL address
on a link is to ARP for that packet as if the destination address were
local to that link, determine the MAC address for that packet, and then
forward the IP packet to that MAC address.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 23 Jan 2003 14:19:08 -0800

> forward the IP packet to that MAC address.

Right, fair enough.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 23 Jan 2003 14:22:42 -0800

> Seems to me LLv4 is a short-term solution that will not serve in the 
> long run - assuming the long run is homes, offices and other sites 
> with multiple links connected by routers.  In fact, LLv4 might turn 
> out to be an obstacle to progress, as it might encourage bridging or 
> some other way of flattening networks for LLv4.  I can imagine a 
> future in which LLv4 addresses are bridged across an entire site - to 
> allow use of LLv4-only devices across the entire site - while non-LLv4 
> addresses are routed in the familiar way.

This seems like an argument against llv4-only, not against llv4.

---

From: "John C. Welch" <[email-masked]>
Date: Thu, 23 Jan 2003 17:53:03 -0500

> you aren't part of the LCD).

Most sysadmins, YT included, welcome smarter code. We just really want an
'on/off' switch for it as well.

john

-- 
John C. Welch
Consultant III
Administrative Computing
(617) 253 - 1368 work
(508) 579 - 7380 cell
bynkii2          AIM

---

From: "John C. Welch" <[email-masked]>
Date: Thu, 23 Jan 2003 17:56:16 -0500

> network wants it to or not.

Well, to be precise, the network can't want anything. The network admin
does. And if the network admin wants v4LL off, then it should be off,
*regardless* of the alternate config method.

By the same token, if they want it on, then it should be on, *regardless* of
the alternate config method. If the admin wants it on, then DHCP shouldn't
be able to override this, because no on here knows everything about every
network need until the end of v4.

In either case, the DHCP switch doesn't fully meet either need.

john

-- 
John C. Welch
Consultant III
Administrative Computing
(617) 253 - 1368 work
(508) 579 - 7380 cell
bynkii2          AIM

---

From: Ralph Droms <[email-masked]>
Date: Thu, 23 Jan 2003 18:18:43 -0500

Check out draft-droms-rfc2563-deprecate-00.txt

- Ralph

---

From: Ralph Droms <[email-masked]>
Date: Thu, 23 Jan 2003 18:22:27 -0500

Ted,

Yeah, I can understand your logic.  Will all vendors and customers all 
understand and believe the same logic?

- Ralph

At 02:22 PM 1/23/2003 -0800, Ted Lemon wrote:
>>run - assuming the long run is homes, offices and other sites with 
>>multiple links connected by routers.  In fact, LLv4 might turn out to be 
>>an obstacle to progress, as it might encourage bridging or some other way 
>>of flattening networks for LLv4.  I can imagine a future in which LLv4 
>>addresses are bridged across an entire site - to allow use of LLv4-only 
>>devices across the entire site - while non-LLv4 addresses are routed in 
>>the familiar way.
>

---

From: Alf Watt <[email-masked]>
Date: Thu, 23 Jan 2003 13:54:59 -0800

Thanks, Thomas, for the consensus call.

1) not my first choice, but I can live with it.

I tend to agree with Subrata Goswami that 2,3,4,5 are restrictive and
confusing. Aidan's suggestion that they be the least preferred address on
the link seems like the right text for the standard.

Best,
Alf

On 1/22/03 6:50 AM, "Thomas Narten" <[email-masked]> wrote:

>> other routable

---

From: Keith Moore <[email-masked]>
Date: Thu, 23 Jan 2003 18:28:13 -0500

> network need until the end of v4.

I find myself imagining that in the DHC working group someone is saying about
now "if the admin wants to use DHCP to specify whether and how the network is
to be used by a host, then LL shouldn't be able to override this..."

---

From: Keith Moore <[email-masked]>
Date: Thu, 23 Jan 2003 18:31:19 -0500

> draft-droms-rfc2563-deprecate-00.txt

I don't follow the argument in the draft.  How is this attack different than
any other DoS attack mounted by supplying false information via DHCP, for
instance, by supplying bogus addresses or too-short lease times or whatever? 
If the logic in this document were followed, shouldn't DHCP itself be
deprecated?

---

From: Ted Lemon <[email-masked]>
Date: Thu, 23 Jan 2003 15:40:19 -0800

> understand and believe the same logic?

Possibly not.   The question is, are you proposing that ipv4ll be 
killed to avoid this, or that language be added to the draft to 
recommend against ipv4ll-only devices?

TBH, given the way people use networks now, and uses that I can 
anticipate, I really don't see this being a big problem - at this point 
I think that the ability to have global IP addresses is sufficiently 
important to the average computer user that ipv4ll will, in practice, 
wind up being used exactly as I think this wg intends.   I think it's 
very unlikely that we're going to see a proliferation of ipv4ll-only 
devices with which one could meaningfully communicate outside of a very 
small area.   E.g., you might see an ipv4ll-only iPod, but you're not 
going to see an ipv4ll-only printer, and  you're definitely not going 
to see an ipv4ll-only desktop or laptop computer.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 23 Jan 2003 15:42:51 -0800

> to be used by a host, then LL shouldn't be able to override this..."

Nope, the folks in the DHCwg are probably just relieved that this 
discussion isn't going on on that mailing list.   The mailing list has 
been quiet the last few days as all the email<->brain bandwidth of the 
several of the more frequent contributors has been consumed by the 
zeroconf mailing list.

---

From: Ralph Droms <[email-masked]>
Date: Thu, 23 Jan 2003 18:53:34 -0500

And some of the other regular contributors have been consumed by DHCPv6 
testing at TAHI...

Ted, I came *this close* to cross-posting the discussion about 
draft-droms-rfc2563-deprecate-00.txt to the dhcwg list.  Perhaps what I'll 
do is point out to the dhcwg list that this discussion is taking place on 
zeroconf and that folks who are interested might want to join in.

- Ralph

---

From: Ralph Droms <[email-masked]>
Date: Thu, 23 Jan 2003 19:01:07 -0500

I actually wasn't proposing any particular course of action, just thinking 
ahead a little to where LLv4 might lead.  What started off my speculation 
was the observation that single-link networks are a pretty limited special 
case.  In reality, just how useful is the ability to set up single-link 
networks, how often will single-link networks really stay isolated from 
other networks and how can participants in a single-link network operate 
continue to operate reliably in the case that the single-link network joins 
a larger network.

Another thing that concerns me is the amount of time I've spent trying to 
figure out what's going on when my computer has silently used a 192.168.0.0 
address in a situation where I expected to be connected to a multi-link 
network.  Perhaps that problem will be solved by the "odn't-ever-use-LLv4" 
switch?  Will that switch fix the problem for un-knowlegdeable users?

- Ralph

At 03:40 PM 1/23/2003 -0800, Ted Lemon wrote:
>Possibly not.   The question is, are you proposing that ipv4ll be killed 
>to avoid this, or that language be added to the draft to recommend against 
>ipv4ll-only devices?
>
>anticipate, I really don't see this being a big problem - at this point I 
>think that the ability to have global IP addresses is sufficiently 
>important to the average computer user that ipv4ll will, in practice, wind 
>up being used exactly as I think this wg intends.   I think it's very 
>unlikely that we're going to see a proliferation of ipv4ll-only devices 
>with which one could meaningfully communicate outside of a very small 
>area.   E.g., you might see an ipv4ll-only iPod, but you're not going to 
>see an ipv4ll-only printer, and  you're definitely not going to see an 
>ipv4ll-only desktop or laptop computer.
>

---

From: Ralph Droms <[email-masked]>
Date: Thu, 23 Jan 2003 19:09:42 -0500

Well, as someone once said, "it seemed like a good idea at the time"...

So, now the idea is written up as a draft and we can discuss it.  Or let it 
expire if it's no longer a good idea.

- Ralph

---

From: Rod <[email-masked]>
Date: Thu, 23 Jan 2003 18:42:02 -0600

On Thursday, January 23, 2003, at 03:55 PM, Keith Moore wrote:

> I don't buy the idea that the host has a right to run LL whether the

If the network admin -gives- physical access to a host, the host can 
use that link in pretty much whichever way it pleases. It is up to the 
administrator to enforce access policies on the network. Ways to turn 
off every single protocol are not the answer. That's why we don't have 
ways of turning off TCP/IP. There are ways of enforcing these policies, 
and the admin should be aware of the appropriate ones to use. Denying 
an ip address from DHCP is not a way to guarantee that use of a network 
link will be restricted.

We are not trying to dictate which ways are correct or not, we are just 
saying that a protocol should not be designed around ways that are 
inherently not guaranteed nor intended to work for a certain purpose.

DHCP was never designed or intended to restrict access to all kinds of 
communication on a link.

You say that the difference between IPv4LL and assigning an IP manually 
is that one requires user interaction. Plugging into a network and 
using stuff also requires user interaction. The fact that we make this 
easier to work doesn't mean that we are bypassing any security measures 
the admin might want to use to restrict access/communication.

Must every single protocol the IETF endorses have an OFF switch? I can 
understand the need for it to not conflict with other protocols (hence 
the -not on when DHCP address assigned- idea), but I don't think there 
HAS to be a way to turn every protocol off, when they can be blocked or 
restricted trough other methods. If you don't want someone to come into 
your house, you don't send a "don't come into my house" note to every 
person in the block, you lock your house down.

I don't think it's smart to rely on the hosts (and protocols) to 
restrict themselves in this manner when you have ways of doing it 
externally.

-Rod Lopez

---

From: Scott Lawrence <[email-masked]>
Date: 23 Jan 2003 20:15:34 -0500

> second guess what the network is saying.

Not giving me an IP address _is_ denying me access to the network -
any policies that have been established based on the addresses handed
out by DHCP have been denied me; most emphatically routability.

By getting an LL address, I'm settling for just the Link, knowing that
I can't do better, but that still might be useful.

---

From: Keith Moore <[email-masked]>
Date: Thu, 23 Jan 2003 20:26:25 -0500

> use that link in pretty much whichever way it pleases. 

Uh, no.  The fact that a network admin provides an Ethernet jack for my host
does not authorize my host to impersonate another host, to consume excessive
bandwidth by violating the TCP specifications, to mount attacks on other hosts
or the network itself, or to choose an address for itself.

Of course the notion of giving someone physical access is less meaningful for
a wireless network.  But even using a wireless network often still involves
dedicated resources like access points - resources which may require
permissions and have policies associated with their use.

>It is up to the administrator to enforce access policies on the network. 

Enforcement is not the issue at hand.  The purpose of a protocol is to
communicate between cooperating parties.  We are (or should be) talking about
a protocol that allows a host to cooperate with a network in order to allow
the host to determine whether and how it can use the network.  The host is
not axiomatically assured carte blanche access.  Because the network is
typically a limited resource that is shared between competing concerns it is
likely that there will be some constraints on its use.  

Many existing networks have acceptable use policies; many have mechanisms for
requesting and granting access.  Violating those policies or circumventing
those mechanisms is often seen as theft or tresspass or some other crime
punishable by fine, imprisonment, job termination, or other sanction.  Perhaps
those sanctions would not be applied in the case where the violation was
caused by a software vendor, but the point is that these policies exist for
good reasons and they are frequently taken seriously.

> Ways to turn 

Like it or not, use of DHCP for this purpose is common.  The most obvious
alternative, PPPoE, has enough problems that DHCP remains attractive in some
cases.  Communicating policy and enforcing policy are different things, and
it's up to each network's admins to determine how best to enforce policy
according to the risks and the needs of its users. 

> inherently not guaranteed nor intended to work for a certain purpose.

The protocol should be designed to let the host communicate what it needs and
the network communicate what the host gets, and also to allow communication
between hosts in the absence of an engine that assigns addresses on the
network.  "correct" means that the host has a way to ask for things that hosts
normally require of networks - things like addresses, netmasks, routes - and
the network has a way to say to hosts things that networks need to say to
hosts - things like addresses, netmasks, routes; but also things like "sorry,
you're not authorized".

> DHCP was never designed or intended to restrict access to all kinds of 

True.  But it's not being used to restrict.  It's being used to communicate
policy, which is more subtle.  Arguably DHCP wasn't designed for this either,
but the fact that it's being widely used to do this means that there's a need
for it.  Screwing with facilities that network administrators need, and
forcing them to solve these problems in a more complex or more costly way (or
a way that is less convenient to users) is not a good way to win acceptance
for your new protocol - not in IETF nor in the marketplace.

> using stuff also requires user interaction. 

Not in the case of wireless it doesn't.  And even when a wire is plugged in,
it doesn't necessarily require users to be involved with mundane details like
address allocation and stack configuration.

> The fact that we make this 

If this group says "yes, it's okay to use this network even if DHCP refused to
give you an address", or "... even if DHCP told you that you couldn't use the
network", or "...even if DHCP told you you couldn't use LL", then it may not
be breaking security measures (depending on how you define security) but it
certainly *is* violating policy.

> Must every single protocol the IETF endorses have an OFF switch? 

Ask the question in another way.  Given that large numbers of networks already
have demonstrated the need to communicate certain kinds of policies to hosts -
like which addresses the hosts will use - and chosen DHCP to do that, should
IETF then standardize the practice of ignoring such communication? 

> I can 
> HAS to be a way to turn every protocol off,

Again, we are not talking about forcing protocols off.  That can be done with
filters on the wire.   We are talking about giving the network a way to
communicate commonly useful policies and assignments to hosts and expecting
well-behaved hosts to honor those policies and assignments.

> when they can be blocked or 

Actually you might put a "no tresspassing" sign on the fence outside your
house, even if the gate is unlocked.  It's useful to have an unlocked gate;
it's also useful to put passers-by on notice that they're not welcome to pass
through the gate without permission.

> restrict themselves in this manner when you have ways of doing it 

Why do we rely on hosts to obey protocols at all, then?  Why don't we see
large numbers of hosts violating TCP timer or window specs so they can get
more bandwidth?  Should we expect the network to prevent that, too?

The main reason the network works at all is that most hosts follow the
protocols willingly.  The network does not force them to do so; in most cases
it's not feasible to force them to do so.

---

From: Keith Moore <[email-masked]>
Date: Thu, 23 Jan 2003 20:28:41 -0500

> I can't do better, but that still might be useful.

even assuming that you have the right to access the Link is a stretch.
especially if you've been told (by DHCP) that you don't have that right.

Keith

---

From: Ted Lemon <[email-masked]>
Date: Thu, 23 Jan 2003 17:32:14 -0800

> So, now the idea is written up as a draft and we can discuss it.  Or 
> let it expire if it's no longer a good idea.

As far as I know, nobody's implemented it in all this time, even though 
clients using IPv4 link-local addressing have been around for a long 
time.   I've never heard anybody ask for the functionality described in 
the RFC, other than the person who advanced it in the first place.   In 
retrospect it seems like it was a hasty response to a non-problem.   I 
think there's little chance that the RFC is going to continue to 
advance as a standard - if nobody's implemented it yet, it seems 
unlikely that anybody is going to.   So IMHO we should in fact 
deprecate it - it's confusing that it's there, because people think 
it's a standard when it's really not.

---

From: Keith Moore <[email-masked]>
Date: Thu, 23 Jan 2003 22:15:59 -0500

On Thu, 23 Jan 2003 17:32:14 -0800
Ted Lemon <[email-masked]> wrote:

> the RFC, other than the person who advanced it in the first place.

well, you've heard several people ask for similar functionality here.

Keith

---

From: Ted Lemon <[email-masked]>
Date: Thu, 23 Jan 2003 19:22:59 -0800

> especially if you've been told (by DHCP) that you don't have that 

Computers do not make moral decisions.   Humans do.   Choosing not to 
access a link because you are not authorized to do so is a moral 
decision, not a protocol decision.   Therefore, it is up to the human 
to make the decision.   The human makes this decision by connecting to 
the network, or by not connecting to the network.

The reason for this distinction is that computer decisions have to be 
enforced.   For example, if it's not okay for a non-root user to 
scribble in /etc, you make sure that /etc is protected so that only 
root processes can write to it.   It doesn't make sense to tell the 
computer program "you shouldn't do that" but allow it to do it.

Likewise, with network access, if the network administrator wishes to 
control access to the link, s/he must actually control access to the 
link using some mechanism that can't be defeated simply by ignoring it.

If there is a reason to have a DHCP message that stops link-local 
addresses from being used, it should be for a protocol reason, not 
because of some mechanism that is called an access control mechanism 
but that does not actually control access.

---

From: Rod <[email-masked]>
Date: Thu, 23 Jan 2003 21:42:08 -0600

I can understand your points Keith, I just don't think it should be up 
to -each- protocol to disable itself according to whatever the network 
admin's policies are. See below.

> or the network itself, or to choose an address for itself.

I said it can, I didn't say it was ok for it do do so.

> permissions and have policies associated with their use.

Exactly.

> Like it or not, use of DHCP for this purpose is common.

It's use is common to restrict access to the routed network, not to the 
local link. In fact I don't think that's common at all.

> between hosts in the absence of an engine that assigns addresses on the

The host might not need anything from the network other than physical 
access.

> "correct" means that the host has a way to ask for things that hosts

Hosts might not need an address, netmask, routes, from the network. The 
introduction of DHCP to make things easier doesn't mean it's a link 
restriction mechanism because all hosts depend on it. They don't.

> for it.

And that need is being addressed by mechanisms to restrict access on a 
link and 'communicate policy', not by each and every protocol that may 
be used on it once you have access.

> certainly *is* violating policy.

And using FTP or HTTP might be against my network's policy, yet no one 
is asking for these protocols to specify a way to disable themselves.

> IETF then standardize the practice of ignoring such communication?

No, it should suggest appropiate ways of communicating (and/or 
enforcing) this policy.

> through the gate without permission.

Yes, but you can't rely on that to be certain no one will come in, 
intentionally or unintentionally. And you also can't expect people who 
design cars to implement some way to disable their cars if that sign is 
present, just because you or other people choose that as their way of 
communicating policy.

> more bandwidth?  Should we expect the network to prevent that, too?

That's why I tried to make a distinction between what a protocol needs 
and what a network (in the sense of the word we're using) needs. If the 
network wants to disable its usage in some way, it should do so without 
relying on a protocol having an off switch or disabling itself. The 
protocol should address its own functional needs, and the network 
should address its own.

> especially if you've been told (by DHCP) that you don't have that 

I think it's unreasonable to assume DHCP should or can be used to tell 
someone they don't have the right to access a -link-. Not only was it 
not designed with this purpose, we're talking about different layers 
and/or scopes. And if an admin still wants to use it for that purpose, 
it doesn't mean all protocol designers should implement ways for DHCP 
to disable their protocols. Coexist with it, yes, but be disabled by it 
just for the sake of "communicating the admin's policies", no.

You always argue about how horrendous NAT is, and about how it's not 
standarized and so it's wrong to consider it as an example or 
justification for doing things, yet thousands of people and networks 
use NAT. Now you are arguing that because lots of networks use DHCP for 
a purpose it was not intended for, we should consider this and use this 
as a justification for doing things. And, as I stated previously, I 
don't think a lot of admins will tell you they use DHCP to 
"communicate" to a person or host that access to that link is not 
authorized. They'll tell you they use it to "communicate" that access 
to that "managed/routed" network is not authorized.

I, as a user and/or software designer, would not see a DHCP deny signal 
as something that tells me "you are not allowed to use this link." Just 
as I would not see a certain region of a city fenced down and think "I 
am not allowed to be on this city." If an admin wants to communicate 
that his network should not be used, he should go further than just 
communicating that access to a certain part of that network is 
restricted. He should use a method that communicates and/or enforces 
that no part or functionality of the network shall be used. There are 
appropriate tools to do so.

-Rod Lopez

---

From: Keith Moore <[email-masked]>
Date: Thu, 23 Jan 2003 22:47:59 -0500

On Thu, 23 Jan 2003 19:22:59 -0800
Ted Lemon <[email-masked]> wrote:

> Computers do not make moral decisions.   Humans do. 

and human standards-writers do.  and human code implementors do.

we're not discussing what a computer will autonomously decide to do, we're
discussing what the computer should be told to do as a matter of standards
conformance.

> Choosing not to access a link because you are not authorized to do so is a
> moral decision, not a protocol decision. 

we're talking about what a computer should do in the absence of explicit
configuration by a human user.  nobody is saying that a human user should not
be able to override the computer's behavior (and suffer the consequences, if
any)

> Therefore, it is up to the human 

no.  the decision to plug a wire into a network is not the same as a decision
to use it, any more than the decision to knock on a door is the same as a
decision to enter whether or not the door is opened.

> enforced. 

no they don't, any more than KEEP OUT signs have to be enforced.  and even if
these rules are enforced, different parties may choose different levels of
enforcement, depending on their needs.  some do spot checks, others post a
guard.  some chase off trespassers, others shoot them on sight.

>  For example, if it's not okay for a non-root user to 

It's useful to make a difference between what a computer should do
automatically and what a computer is able to do with explicit human input. 
It's like an unlocked gate on a fence with a KEEP OUT sign.   It doesn't
prevent you from opening the gate and entering, but it does tell you that the
mere fact that you can physically open the gate doesn't mean you're authorized
to enter.  

So the network tells the host "you can't have an address".  The host
reports this to the human - "the network won't give me an address".  Human
says "override" because he has explicit authorization from elsewhere (maybe he
is the network admin, maybe he's the repair guy needing to run diagnostics.) 
But the human also gets to deal with the consequences.  This might mean that
if he's caught using the network without authorization he loses his job.  Or
it might simply mean that he's trying to use the network in a way that its
maintainers didn't provide for, so things aren't guaranteed to work.  For
intance, a host with a LL address might not be able to reach any printers or
DNS servers.

If you think about it, it's really stupid for a host to automatically assume
that an LL address is suitable for *any* purpose in a managed network.  If you
didn't design the network with LL in mind, if you didn't place essential
services where LL-only hosts could reach them, what good is it for the host to
acquire an LL address? 

> link using some mechanism that can't be defeated simply by ignoring it.

bull.  I've seen DHCP used in this way, and it's largely effective at forcing
most people to get their laptops' addresses registered.  It's not for us to
determine whether a particular site's policy enforcement mechanism is adequate
to their needs, any more than it's for us to determine how strong a lock is
needed on the network closet door.

> but that does not actually control access.

I've been trying to call it a way to communicate policy.  And what is a
protocol if not a way to communicate something?

---

From: Ian Lister <[email-masked]>
Date: Fri, 24 Jan 2003 13:55:36 +1000 (EST)

>services where LL-only hosts could reach them, what good is it for the host to

It might not be useful for anything, but it's really stupid for a host to
automatically assume that a LL address is *not* suitable for anything just
because the DHCP server doesn't want to give it a global address.

Ian

---

From: Rod <[email-masked]>
Date: Thu, 23 Jan 2003 22:07:11 -0600

> decision to enter whether or not the door is opened.

The decision to configure an IP address when it's plugged in is not the 
same as the decision to use it then.

> services where LL-only hosts could reach them, what good is it for the 

You might just want to transfer a file between two laptops.

> It's not for us to determine whether a particular site's policy 
> enforcement mechanism is adequate
> to their needs

Exactly. So why do you want to do this? Let them determine that DHCP is 
not adequate to their needs if what they want to do is completely 
restrict access to the link.

> protocol if not a way to communicate something?

Something, not everything.

-Rod Lopez

---

From: "John C. Welch" <[email-masked]>
Date: Thu, 23 Jan 2003 23:26:51 -0500

> to be used by a host, then LL shouldn't be able to override this..."

Hence my previous paragraph in that email agreeing with you in this. The
admin should decide on how and when LL is used, not random DHCP servers.

john

-- 
John C. Welch
Consultant III
Administrative Computing
(617) 253 - 1368 work
(508) 579 - 7380 cell
bynkii2          AIM

---

From: "John C. Welch" <[email-masked]>
Date: Thu, 23 Jan 2003 23:27:55 -0500

On 01/23/2003 18:40, "Ted Lemon" <[email-masked]> wrote:

> you might see an ipv4ll-only iPod, but you're not

I'll give you even odds on the printer.

john

-- 
John C. Welch
Consultant III
Administrative Computing
(617) 253 - 1368 work
(508) 579 - 7380 cell
bynkii2          AIM

---

From: Keith Moore <[email-masked]>
Date: Thu, 23 Jan 2003 23:27:20 -0500

> admin's policies are. See below.

Perhaps not.  But different protocols have different impacts, and IP is more
fundamental than most.  Furthermore, discussion of ways to disable other
protocols are not in scope for the zeroconf WG.  If we needed a way for the
network to tell hosts to not use DHCP we'd be discussing it in the DHC working
group.

We're talking about providing a mechanism which can circumvent measures that
are already in place to communicate policy.  Given that mechanisms to
communicate policy about how to use a network are already in place, I don't
think we should tell implementors that it's okay to ignore them.  If we were
talking about a completely new facility for configuring addresses on hosts
(where no facility existed before), backward compatibility would not be an
issue.

> It's use is common to restrict access to the routed network, not to the 

Perhaps.  But the assumption is that, having failed to get an address, the
host will not try to access the link (at least not with IP) in the absence of
explicit configuration by a human.  (and the human typically doesn't know what
address to use - so this can be an sufficiently effective access control
mechanism for some purposes.)

> > The protocol should be designed to let the host communicate what it 
> > needs and the network communicate what the host gets, and also to allow 
> > communication between hosts in the absence of an engine that assigns
> > addresses on the network.
> 

that's silly.  what's the purpose of a network if not to communicate with
other hosts?  layer 1 is useless to a host without at least layer 2.

> restriction mechanism because all hosts depend on it. They don't.

If there are no other resources on a net than IP-accessible resources, it's
pretty difficult to do anything with those resources (or the net) without an
IP address.

> > True.  But it's not being used to restrict.  It's being used to
> > communicate policy, which is more subtle.  Arguably DHCP wasn't designed
> > for this either, but the fact that it's being widely used to do this means
> > that there's a need for it.
> 

The 'every protocol' argument is specious.  We're not talking about 'every
protocol', 'every protocol' is not in scope for this working group, and there
are unique characteristics of LL that do not apply to 'every protocol'.

> is asking for these protocols to specify a way to disable themselves.

Various means to disable these already exist.  The needs for disabling them
are different than the needs for disabling LL.  And they're not the problem of
this working group.
 
> > Ask the question in another way.  Given that large numbers of networks 
> > already have demonstrated the need to communicate certain kinds of
> > policies to hosts - like which addresses the hosts will use - and chosen
> > DHCP to do that, should IETF then standardize the practice of ignoring
> > such communication?
> 

I submit that DHCP is within epsilon of an appropriate way of communicating
the policy of which address to use, which netmask to use, which default route
to use, or whether no address should be used by a host.  If it needs tweaks to
accomodate LL, let's tweak it.  But when we've got existing networks using
DHCP as a means of saying "you don't have access to this network", let's not
tell vendors that it's okay to program hosts to access the network anyway
using LL.  Or let's at least give network admins a way to less ambiguously say
"no access", and expect the vendors to adhere to *that*.  (note that backward
compatibilty with current practice is highly desirable)

> > Actually you might put a "no tresspassing" sign on the fence outside 
> > your house, even if the gate is unlocked.  It's useful to have an unlocked
> > 
> > gate; it's also useful to put passers-by on notice that they're not
> > welcome to pass through the gate without permission.
> 
> intentionally or unintentionally.

If you really wanted to be certain of that, you'd have bricked your doors and
windows shut. The purpose in putting up a no trespassing sign next to an
unlocked gate is *not* to be certain that nobody can come in, but to put
people on notice that by default, they're not welcome.  The sign doesn't mean
you want the fireman to stay outside when the house is on fire.  Neither does
the absence of a lock mean that neighboorhood kids are welcome to come in the
house and rummage through your closets.   Ambiguity and appeals to human
judgement are useful, when dealing with humans.

> And you also can't expect people who 

In fact people designing autonomous vehicles have worked on having those
vehicles respect various kinds of road markings (like solid center lines),
while allowing humans to override the vehicles. 

> > Why do we rely on hosts to obey protocols at all, then?  Why don't we 
> > see large numbers of hosts violating TCP timer or window specs so they can
> > 
> > get more bandwidth?  Should we expect the network to prevent that, too?
> 
> relying on a protocol having an off switch or disabling itself.

no.  It's expensive, and often unnecessary, to have every network access port
be able to filter traffic.  I shouldn't have to replace all of my dumb hubs
with remotely controllable ones, and implement network monitors, just to deal
with vendors who insist on being agressive about imposing LL on my networks. 
Or at least, IETF shouldn't be endorsing such practices.

> someone they don't have the right to access a -link-. 

Like it or not, that's how it's being used today.  You may think that only
access to the network beyond the link is being restricted, but that is not
necessarily what the admins intend.  

> use NAT.

Yes, and I've also argued that standard protocols should not assume that they
have the right to subvert NAT when NAT is used as a firewall.

> And, as I stated previously, I 

I assure you that our admins treat it as access control to the entire network,
not just the portion beyond the link.  They do not want unregistered hosts on
the network, period.

Keith

---

From: "John C. Welch" <[email-masked]>
Date: Thu, 23 Jan 2003 23:29:22 -0500

On 01/23/2003 19:42, "Rod" <[email-masked]> wrote:

> ways of turning off TCP/IP.

Ifconfig en0 off

john

-- 
John C. Welch
Consultant III
Administrative Computing
(617) 253 - 1368 work
(508) 579 - 7380 cell
bynkii2          AIM

---

From: Keith Moore <[email-masked]>
Date: Thu, 23 Jan 2003 23:33:59 -0500

> > no.  the decision to plug a wire into a network is not the same as a 
> > decision to use it, any more than the decision to knock on a door is the
> > same as a decision to enter whether or not the door is opened.
> 

it depends.  does the computer have any processes running on it that
periodically try to do things on the network?

> > If you think about it, it's really stupid for a host to automatically 
> > assume that an LL address is suitable for *any* purpose in a managed
> > network. If you didn't design the network with LL in mind, if you didn't
> > place essential services where LL-only hosts could reach them, what good
> > is it for the host to acquire an LL address?
> 

and you just might not want your network to be used by unauthorized hosts.

> > enforcement mechanism is adequate to their needs
> 

they've determined that it's good enough for now.  people in this group are
essentially proposing to change the meaning of a DHCP server's refusal to
assign an address. 

Keith

---

From: Rod <[email-masked]>
Date: Thu, 23 Jan 2003 23:56:49 -0600

> network to tell hosts to not use DHCP we'd be discussing it in the DHC 

The consideration of mechanisms that other protocols use to do things 
as examples is not out of the scope of this WG.

> But the assumption is that, having failed to get an address, the

Whose assumption? Should we proceed according to assumptions? Even if 
they are wrong? Why would anyone assume that being denied a DHCP 
address, the host will not try to access the link anyway, if Appletalk, 
NetBIOS, IPX, etc. have been in existance for decades and are widely 
used, not to mention shipping with all major desktop operating systems?

> other hosts?  layer 1 is useless to a host without at least layer 2.

I meant physical access to the network, not access to the physical 
layer only.

> pretty difficult to do anything with those resources (or the net) 

My point was that the host might not need to ask the network for an IP 
address, so nobody should assume it will.

> are unique characteristics of LL that do not apply to 'every protocol'.

The consideration of mechanisms that other protocols use to do things 
as examples is not out of the scope of this WG.
There are unique characteristics of LL that do not apply to every 
protocol, but the characteristic of "the admin might want to restrict 
it" does apply to most.

> are different than the needs for disabling LL.  And they're not the 

And the means to disable them are not a part of the protocols 
themselves, which was my point. Taking this as an example is not out of 
the scope of this working group.

> accomodate LL, let's tweak it.

I disagree, because nobody ever said that DHCP is the only way to use 
IP and the only way to configure an IP address, and nobody ever said 
that if you don't get an IP address from DHCP then IP ceases to work, 
or the local link ceases to work. I also don't think anyone assumes 
this. It's ok with me if you submit an idea for DHCP to be able to 
restrict what IP addresses can be used on a link, but I don't think 
that's related to this WG.

> But when we've got existing networks using

1) I really don't think anyone is using DHCP as a means of saying "you 
don't have access to this network" while implying "you don't have 
access to this link." To assume this would be very unreasonable.

2) There are ways for network admins to say "no access to this link." 
DHCP is not one of them and never has been. If you want to work on new 
ways to do so (including using DHCP to restrict access and/or what IP's 
can be used) you are welcome to do so under the appropriate WG.

> while allowing humans to override the vehicles.

It's ok with me if people use DHCP to communicate "I don't want to give 
you an IP." But I refuse to accept that this is also supposed to tell 
people/machines "you can't use this link at all."

> Or at least, IETF shouldn't be endorsing such practices.

You have to anyway if you want to completely restrict access to a link 
or communicate that it shouldn't be used. When you bought those hubs 
you knew that they would not be useful in controlling access to the 
local link. This doesn't change at all with the introduction of IPv4LL.

> Like it or not, that's how it's being used today.

No, it's being used to deny IP addresses on a network, not to tell 
people they don't have the right to access a link.

> You may think that only

They should do what they intend then, and not expect users or protocols 
to try to interpret, guess, or figure out what they intend to do and 
what their policies are. Also, we should not design protocols based on 
assumptions of these things. We should base them on facts and how 
things really work, not how admins believe they work, or what admins 
believe will be communicated by the ways they decide to use them.

> not just the portion beyond the link.  They do not want unregistered 

They are not using the appropriate methods then. Not because this group 
dictates it, but because they are not accomplishing their goal if 
anyone can come in and share files via Appletalk or a manual IP. IPv4LL 
won't change this either.

-Rod Lopez

---

From: Rod <[email-masked]>
Date: Fri, 24 Jan 2003 00:10:05 -0600

>> ways of turning off TCP/IP.

Nice try John, but no, that's not turning TCP/IP off via a mechanism 
defined in its specs, that's turning the ethernet interface off. You 
can do that to disable IPv4LL as well, yet you are still asking for a 
switch to disable it aren't you? :-)

You're actually backing up my point, that the way to block/disable a 
protocol should not be the job of the protocol itself.

-Rod Lopez

---

From: Ted Lemon <[email-masked]>
Date: Thu, 23 Jan 2003 23:01:28 -0800

> well, you've heard several people ask for similar functionality here.

Right, and zero of them have sent a patch to the ISC.   And even if 
they did, there would still be the small matter of deploying this to 
all the existing ipv4ll implementations, and getting it into new ones.  
  There is no business case for this - no customers are requesting it.   
So it won't happen.

---

From: Erik Guttman <[email-masked]>
Date: Fri, 24 Jan 2003 11:04:33 +0100 (CET)

> network, only monitors with alarms and filters can hope to work.

If a host fails to get an address configured with DHCP, it will stop
using IPv4LL according to the current proposal, right?  (The host sends
a series of DHCPREQUEST and gets only DHCPNAK replies, for example.) 
This means that a host will neither have a DHCP assigned address, nor a
IPv4LL address.  It will be unable to communicate. 

There was concern that home gateway / cable modem vendors would abuse
this option to make home networking impossible unless managed by the
network service provider.  It should be possible, the argument goes, to
do home networking irregardless of the provider's policy.  

It is *very strange* that Internet Standardization Veterans are arguing
that stronger central administration and control of LANs should be
mandatory, while network administrators from 2 universities and consumer
client networking computer vendors continue to argue that this is
neither desirable nor necessary. 

It *is desirable* for hosts to be required to reconfigure to using
global instead of LL addresses when DHCP, etc makes the global address
available because this offers *architectural advantages,* as it
simplifies

 - source address selection
 - application interoperability with the rest of the network

This reconfiguration comes at a significant cost of autonomy for the
consumer. It means that if a DHCP server is present on the link (due to
an attacker, an incompetent, greedy or intolerant service provider, etc)
networking can be made impossible.  There are even disadvantages for
local administrators:  In conditions where DHCP fails (due to
misconfiguration, for example) it will be impossible to reach hosts on a
LAN to administer them except by a serial cable, an out-of-band IP
network or some other expensive and improbable mechanism. 

Erik

---

From: Erik Guttman <[email-masked]>
Date: Fri, 24 Jan 2003 11:23:35 +0100 (CET)

> used, not to mention shipping with all major desktop operating systems?

It is very likely that by requiring IPv4LL to be turned off in the
presence of DHCP we will prolong the life of AppleTalk and NetBIOS.
Users will be unwilling to give up their ability to do local area
networking on whatever link they are attached to, irrespective of 
whether DHCP can or will grant them an address.  

Note well:  I have been to the IETF terminal room in several cities
where the only users who could print were those with Macs running
appletalk. 

Aren't there emerging IEEE protocols for granting access to networks?  I
know of some universities which require users to register their mac
addresses or the switches will simply refuse to grant them access to the
network.  If administrators want to prevent access to the link, why
not use L2 access control.

I submit it is reasonable for a host to continue using a v4LL address
*until it has been assigned a global address* by DHCP or some other
means.  We still get the advantages of removing the complexity of source
address selection and application interoperability simplification.

Erik

---

From: "Philip Nye" <[email-masked]>
Date: Fri, 24 Jan 2003 10:49:06 -0000

> From: "Erik Guttman" <[email-masked]>
>
> using IPv4LL according to the current proposal, right?

rfc2563 is rather more explicit - the DHCP server has to actively reply
"Address=0 AND dont autoconfigure either". Simply not granting an address
would not be enough. However despite rfc2563 saying autoconfiguring hosts
MUST implement and honor this option I don't think any do.

> network service provider.
> It should be possible, the argument goes, to

The answer to this issue is entirely political and has no technical content.
Ultimately it will be resolved by commercial decisions - see above. Is this
working group going to make a difference or is it simply deciding which
horse to back?

Philip

---

From: Keith Moore <[email-masked]>
Date: Fri, 24 Jan 2003 07:02:32 -0500

>   There is no business case for this - no customers are requesting it.   

that might change if LL finds wider use.

---

From: Keith Moore <[email-masked]>
Date: Fri, 24 Jan 2003 07:00:42 -0500

Rod,

The arguments are getting circular, and we're not resolving anything, so we're
simply going to have to disagree on this.  I've seen several examples of cases
where DHCP was used as the means to specify (and in some sense control, though
not in a strict sense) whether a host had access to a network (effectively
including the link).  Maybe the mechanisms were imperfect, and maybe they
didn't do anything to stop or even influence use of other protocols besides
IP, but they are still found to be useful.  And I don't think it's useful to
pretend that LL is a separate protocol than IP and not subject to the controls
present for IP.

Keith
(trying to minimize use of bandwidth!)

---

From: Keith Moore <[email-masked]>
Date: Fri, 24 Jan 2003 07:57:49 -0500

> networking can be made impossible.

No, not impossible.  It just requires a human user to say "do it anyway".
what is being asked for is a way for DHCP to set the automatic behavior,
not a way for DHCP to prevent a host from connecting.

Personally I don't want my computer to go around attempting to connect to any
random network that it can talk to.  I want to specify explicitly when to
connect. If it's a wired network then media sense is probably sufficient.  But
if it's a wireless network then I want to say "yes, connect" and I probably
want to specify which network I'm connecting to (since there can be more than
one).  

Just because it's an ad hoc network doesn't mean that everybody wants to
connect, or for that matter, that anybody who wants to connect is welcome to
do so.  If I plug my computer into a hub on a table top, or if I tell it to
connect to some group of hosts with wireless interfaces, I'm making a decision
to do that based on whether I think it is useful for me to do so and whether I
trust the other people on that network.  If anybody is allowed to join without
being noticed, the trust level goes way down.

The whole concern about attacking an ad hoc network seems to be misplaced. 
It's not that ad hoc networks can't be attacked (they certainly can); it's
the idea that preventing a DoS attack via DHCP reduces the threat at all. 
Or more generally, that it is feasible for ad hoc networks to resist attack.
(Is the attacker really going to say, "well since the hosts will ignore a 
DCHP message telling them not to use the network, I'll just give up", or 
is he going to say "I think I'll foil any attempt to claim a new IP address"?)

In a managed network, when you can't connect because DHCP won't assign you an
address, you call tech support.  In an ad hoc network, when you can't connect
because a DHCP server says "don't use LL", you look at the other folks using the
network and ask "which one of you idiots has a DHCP server running?"

---

From: "John C. Welch" <[email-masked]>
Date: Fri, 24 Jan 2003 07:51:15 -0500

> switch to disable it aren't you? :-)

I am, because there are clear needs to have that level of control in a high
security environment where every packet has to be accounted for. This is not
a maybe, those environments exist today. They existed years ago when I
worked in them.

> protocol should not be the job of the protocol itself.

I don't actually *care* where the switch is. I even suggested it *be* a new
option for ifconfig, i.e. ifconfig en0 nov4LL

But there is a need to have an explicit off switch. DHCP killing addressing
while allowing communication isn't going to be enough, and a manual switch
here allows for far more flexibility in controlling v4LL if you need to.

john

-- 
John C. Welch
Consultant III
Administrative Computing
(617) 253 - 1368 work
(508) 579 - 7380 cell
bynkii2          AIM

---

From: "John C. Welch" <[email-masked]>
Date: Fri, 24 Jan 2003 08:01:57 -0500

> neither desirable nor necessary.

I'm arguing for real control, as you illustrate very neatly below why the
DHCP option *alone* has real problems that aren't theoretical.

> network or some other expensive and improbable mechanism.

Right...without some manual override, grammy is royally screwed, and most
likely, going to not be happy with her computer vendor.

There actually is a very clear example of what happens when you totally rely
on automatic systems: The F-16

It's one of the only planes, civilian or military with a fly-by-wire *only*
system. If the plane loses its electrical systems, or total power, there is
no way to control it and you eject. The f-16 has a three-level power backup
system, and still the things crash regularly because if the power goes, it's
an uncontrollable brick. With other aircraft, such as the B-1B, (pardon the
military focus, I have experience here.), you have a cable/manual backup.
You don't normally use it, but when it is needed, it's there.

You need a manual backup. Even Appletalk allowed for manual addressing. You
didn't always use it, in fact, it was pretty silly *to* normally use it. But
when you needed it, it was there. We cannot assume that an automatic system
such as DHCP control over v4LL will always work. So a manual backup is
needed. Making it a required part of the spec is responsible. Note that I am
not saying we dictate implementation. That would be dumb. If the vendor
wants to modify something like ifconfig, include a button on an embedded web
config, make it a physical button on the back of the device, *whatever*, as
long as it is there. I would prefer a non-physical method, but if enough
customers complain, the vendor will change it.

john

-- 
John C. Welch
Consultant III
Administrative Computing
(617) 253 - 1368 work
(508) 579 - 7380 cell
bynkii2          AIM

---

From: Robert Elz <[email-masked]>
Date: Fri, 24 Jan 2003 21:45:10 +0700

Date:        Thu, 23 Jan 2003 14:03:30 -0800
    From:        Ted Lemon <[email-masked]>
    Message-ID:  <[email-masked]>

  | Does the mDNS spec say that this is what should happen?   Does the 
  | IPv4ll spec say it?   :'}

What they say now, and what they will say before they're completed, is
part of what is being worked on here...

kre

---

From: Robert Elz <[email-masked]>
Date: Fri, 24 Jan 2003 21:44:16 +0700

Date:        Thu, 23 Jan 2003 19:09:42 -0500
    From:        Ralph Droms <[email-masked]>
    Message-ID:  <[email-masked]>

  | So, now the idea is written up as a draft and we can discuss it.  Or let it 
  | expire if it's no longer a good idea.

Yes, that's fine.

I agree with Keith - the draft makes no sense...

In addition to what he said, the analysis of the problem in the draft seems
incorrect to me.

It is absurd for me to explain DHCP to you (or to Ted) but ...

How can a rogue DHCP server possibly deny access using the mechanisms in
RFC2563 (assuming a rationally constructed client).

If there's no other DHCP server, then such a server could prevent a node
from assigning itself a LL address, which it would otherwise do in the
absence of a DHCP server.   But there's no need to go to all the work of
emulating a DHCP server to achieve that - all that's needed is to answer
ARP requests for LL addresses (either those coming from anyone, or those
from a specific MAC address, depending upon the desire).   So, in this
case (no other DHCP servers) 2563 is no worse than what already exists.
[The rogue DHCP server needs to be on the link, or have a rogue relay agent
on the link, so ARP attacks work just fine].

If there is another DHCP server, then the client is going to get two (or
more) offers.   It then chooses the one it wants to use.   I know that if
I was writing a client, and I got an offer which said "no addresses for you"
and another that said "here's an address you can use" (or even "configure
yourself a LL address") then I know which offer would be the one I'd be
picking.   Even a "dumb" client that simply takes the first offer it
receives and uses it could easily learn to ignore "no address" offers
and wait for something better - if something better arrives, then fine,
if not, there's no great harm done, the network isn't going to work anyway.

If anything, the problem with RFC2563 is that it allows a rogue DHCP server
to enable LL addresses that the "real" DHCP server is attempting to prevent,
but as Keith said, this is just a general issue with the use of DHCP (or
any other automatic configuration mechanism for that matter) and nothing
at all specific to 2563.

The justification in the draft for deprecating that RFC is inadequate.

On the other hand ...

[email-masked] said:
  | As far as I know, nobody's implemented it in all this time, even though
  | clients using IPv4 link-local addressing have been around for a long  time. 

That would be a much better justification for deleting it.   Except that there
are only a couple of IPv4 link local implementations (I believe), which have
been implemented with little guidance of how they should be done (they don't
even agree with each other, or interoperate properly if I have read this
list correctly).   That's what this WG is trying to fix.

If this WG were to say "the right way is to implement RFC2563" then I
suspect that you'd start to see implementations.

[email-masked] quoted Keith Moore and then said:
| > well, you've heard several people ask for similar functionality here.
| Right, and zero of them have sent a patch to the ISC.

Huh?   Why would anyone be sending ISC a patch for this?

The ISC server already supports the option, all that is needed is

	option useLL code 116 = boolean;

in the dhcpd.conf file, along with
		option useLL on;
or		option useLL off;
as required.

The ISC client doesn't configure LL addresses, last time I looked anyway,
so the option is irrelevant to it.

If the ISC client starts autoconfiguring LL addresses when it fails to get
a DHCP address, you can be sure that you'll get a patch to allow that to be
disabled.

kre

---

From: Ian Lister <[email-masked]>
Date: Sat, 25 Jan 2003 02:52:36 +1000 (EST)

>address selection and application interoperability simplification.

I concur.

(fwiw)

Ian

---

From: Ted Lemon <[email-masked]>
Date: Fri, 24 Jan 2003 10:36:33 -0800

> I know that if

DHCP cant' say "configure yourself an LL address."

I've got a couple of problems with what you've said, and agree with 
other things you've said.   The DoS problem is definitely not the only 
reason to deprecate RFC2563, and I will give some other reasons to 
deprecate it.   I will also point out some reasons why the DoS attack 
enabled by RFC2563 is easier to do than the a direct IPv4ll DoS attack. 
   Finally, I will point out why the RFC2563 DoS is a more difficult 
attack from which to recover.

1. Non-DoS reasons to deprecate RFC2563.

- It's voluntary, so it doesn't work - if you really want this, RFC2563 
isn't the way to get it.
- It requires a change to the DHCP protocol state machine - a response 
is generated by the server according to RFC2563 in a case where no 
response would be generated according to RFC2131.   This requires 
significant changes to clients and servers, which I think is one reason 
why nobody has implemented RFC2563 to date.
- Customers are not asking for it, and nobody has implemented it, even 
though the theoretical need for such a mechanism after almost five 
years of deployment.
- RFC2563 demands that the client operate in conflict with the wishes 
of the owner of the client.   So it is difficult for a client vendor 
(e.g., Microsoft or Apple) to justify implementing RFC2563 - it is 
likely to cost them business, or generate support calls that will cost 
them money.   I think this is the main reason RFC2563 has not been 
implemented.

2. RFC2563 enables off-network attacks

Having said that, I think you underestimate the value of the DoS attack 
that RFC2563 enables.   RFC2563 enables off-network DoS attacks, 
whereas without RFC2563 the only possible attacks require that the 
attacker be attached to the network.   There are two kinds of 
off-network attacks that it enables:

- Speculative attacks, where you guess the MAC address and transaction 
ID of a device and send it DHCP packets in the hopes that it will be in 
the right state to be disabled by these attacks.
- Relay agent-based attacks, where you listen to the relay agent and 
supply a bogus response that shuts off IPv4ll.

This second attack is quite significant, as some folks have mentioned, 
because we know of ISPs who perform this kind of attack on their 
customers already.   Currently they do it by providing bogus IP 
addresses rather than by using the RFC2563 mechanism, but if RFC2563 
were widely implemented by clients, we have reason to suspect that it 
would be used to attack and disable legitimate networks.

One reason why ISPs may perform this attack is because when you don't 
respond to a DHCP client, it keeps asking, and never shuts up.   If you 
can send it a "shut up" response, you eliminate all these clients.   So 
if we give ISPs rfc2563, that is, if it becomes widely implemented, it 
will be used to shut up clients.   The effect of this will be to break 
networks that ought to work.   So in fact the DoS argument against 
RFC2563

3. It is harder to identify and eliminate an RFC2563 attacker

Another problem with RFC2563 is that it's easy to use it to deny 
service.   A client pipes up with a DHCPDISCOVER.   You tell it to shut 
up.   End of story.   With IPv4ll, in order to shut up a client, you 
have to be constantly listening for ARPs and defending IP addresses.   
So a DoS attack of this kind would be very easy to track down.   By 
contrast, an RFC2563 attacker can attack at an opportune moment, 
disable one or more clients, and then go silent for an extended period 
of time, so there's no easy way to track it down.

4. No automatic recovery from an RFC2563 DoS attack.

Once you have identified an attacker that is using the 
defend-all-addresses attack, you can unplug  attacker from the network, 
and the network immediately starts working again.   In comparison, the 
RFC2563 DoS requires you to physically manipulate every computer on the 
network - you either have to power cycle them, or if they can detect 
link state transitions, disconnect and reconnect each device from the 
network.   This is because once the client has been told to shut up, it 
shuts up, so there's no automatic recovery mechanism.

---

From: Robert Elz <[email-masked]>
Date: Sat, 25 Jan 2003 18:40:40 +0700

Date:        Fri, 24 Jan 2003 10:36:33 -0800
    From:        Ted Lemon <[email-masked]>
    Message-ID:  <[email-masked]>

  | DHCP cant' say "configure yourself an LL address."

That's what 2653 says isn't it - or perhaps more accurately, 2653
assumes that if nothing is said, then not getting an address from
DHCP (the DHCP server ignores the DHCPDISCOVER) is implicitly telling
the client to go configure a LL address (if it wants to do that of
course).

  | 1. Non-DoS reasons to deprecate RFC2563.
  | 
  | - It's voluntary, so it doesn't work - if you really want this, RFC2563 
  | isn't the way to get it.

Huh?   Everything here is voluntary - I (at the very least) do not
mean to imply coercion.   It is no different than assuming that clients
that are offered an address via DHCP will actually configure the address
they're offered, rather that some other address they pick that is on
the same network (using the subnet-mask from the DHCPOFFER to work that out).

If the client deliberately decides to ignore the advice, that's its
choice.   If the user has told it to do that, fine.   If the vendor has
implemented it to always do that, that's their choice, but they wouldn't
be able to claim conformance with 2563 obviously, and not with the LL
std if that ends up requiring 2563 be implemented (or something like it).

  | - It requires a change to the DHCP protocol state machine - a response 
  | is generated by the server according to RFC2563 in a case where no 
  | response would be generated according to RFC2131.

I am pretty sure that I can make the ISC server generate 2563 responses
with no changes at all, but I haven't yet tested it.   To work "easily"
from the servers point of view, yes, that would require some modifications
I suspect.

  | - RFC2563 demands that the client operate in conflict with the wishes 
  | of the owner of the client.

No it doesn't.   It can't, nothing the IETF produces can require that.

  | So it is difficult for a client vendor 
  | (e.g., Microsoft or Apple) to justify implementing RFC2563 - it is 
  | likely to cost them business, or generate support calls that will cost 
  | them money.

Only if servers start supplying the option, right?   And your thesis above
was that none do or ever will.   So, how could this possibly cost anything
more than the implementation cost (like 50 lines of code, max).   On the
other hand, if servers do start supplying this option, because their operators
want them to, and then the servers are configured to generate the option,
and the option says "no LL addresses" when sent, and the clients ignore
that, don't you think that would generate support calls ?

  | 2. RFC2563 enables off-network attacks
  | 
  | Having said that, I think you underestimate the value of the DoS attack 
  | that RFC2563 enables.   RFC2563 enables off-network DoS attacks, 
  | whereas without RFC2563 the only possible attacks require that the 
  | attacker be attached to the network.   There are two kinds of 
  | off-network attacks that it enables:

  | This second attack is quite significant, as some folks have mentioned, 
  | because we know of ISPs who perform this kind of attack on their 
  | customers already.

Hmm - this doesn't follow, first you say that 2563 enables these attacks,
and then that they're already being carried out, without 2563.

  | Currently they do it by providing bogus IP 
  | addresses rather than by using the RFC2563 mechanism, but if RFC2563 
  | were widely implemented by clients, we have reason to suspect that it 
  | would be used to attack and disable legitimate networks.

If I were to be subject to such an attack, I'd much rather it was carried
out using 2563 than by handing me a bogus IP address.   That way at least
I could easily see what was happening, my system would tell me (you were
refused an IP address), rather than proceeding happily with an IP address
that looks to be just fine, but doesn't actually work.

So, if this is the threat, then bring on 2563, please!

  | One reason why ISPs may perform this attack is because when you don't 
  | respond to a DHCP client, it keeps asking, and never shuts up.

It doesn't matter why they might choose to do this, if they do it now, and
can do it now, and will still be able to do it (in a different way) using
2563 (if clients implemented it) then nothing has really changed, except
2563 makes things more obvious (so if the "attacker"/ISP is trying to be
as nice as they can, while keeping down the load on their server, they'd
use 2653, if they're really trying to hide what they're doing, they'll
keep doing it the way they are now).

This is just another aspect of Keith's reply to Ralph's first message on
this general thread - the DoS potential of 2563 is really identical to the
DoS potential of DHCP without 2563.

  | 3. It is harder to identify and eliminate an RFC2563 attacker
  | 
  | Another problem with RFC2563 is that it's easy to use it to deny 
  | service.   A client pipes up with a DHCPDISCOVER.   You tell it to shut 
  | up.   End of story.

Until it decides to try again, and assuming there is no other DHCP
server that actually offers an address.   The story continues...

  | With IPv4ll, in order to shut up a client, you 
  | have to be constantly listening for ARPs and defending IP addresses.

So?   You have to keep watching for DHCPDISCOVERS anyway, watching for
ARP is not really all that hard to do.
  
  | So a DoS attack of this kind would be very easy to track down.   By 
  | contrast, an RFC2563 attacker can attack at an opportune moment, 
  | disable one or more clients, and then go silent for an extended period 
  | of time, so there's no easy way to track it down.

Huh?   You just have the client do a DHCPDISCOVER and watch what happens
next time.   If the attacker is being silent, then the client goes ahead
and gets its LL address after all this time - that's no different from an
ARP attack running for a short while, then going silent for a while in the
hopes of avoiding detection.

You're also assuming that the client is not recording the information
about who (mac & IP addr) of the node that sent the "shut down" DHCP
message.   Why would you assume that?   It seems like that would be the
obvious thing for a node to record for later analysis.

On the other hand, getting a reply to an ARP probe for an address is
"normal" - that's what is supposed to happen if you happen to pick an
address that is in use already.   There's no particular reason for a
client to believe it needs to remember anything about where that came
from, and without that, it can't tell that all the ARP responses seem
to be coming from the same place (even assuming that the ARP attacker
isn't just randomising its MAC source address).

Once again, the 2563 DoS attack is the one I'd much rather carried
out against me, it is the one that is much easier to detect and
analyse.

  | 4. No automatic recovery from an RFC2563 DoS attack.
  | 
  | Once you have identified an attacker that is using the 
  | defend-all-addresses attack, you can unplug  attacker from the network, 
  | and the network immediately starts working again.

That's true for any attacker.

You have a hidden assumption here that a node wanting a LL address is
going to continue ARP'ing (probing) for one, forever, until it eventually
is received.   I kind of doubt that (and would like the implementors of
the current implementations, or those who know about them, to tell us if
they just continue forever, or if they give up after a while).

  | In comparison, the 
  | RFC2563 DoS requires you to physically manipulate every computer on the 
  | network - you either have to power cycle them, or if they can detect 
  | link state transitions, disconnect and reconnect each device from the 
  | network.   This is because once the client has been told to shut up, it 
  | shuts up, so there's no automatic recovery mechanism.

There's no reason that a client can't try again from time to time, after
either of these failures.   Explicit try again commands (from some user,
perhaps using one of the methods you mention, or something else) might,
be required for either of those methods.   I see nothing in 2563 that
says "never try again without detecting link state changes" or anything
like that.

In fact, anything of that nature would be very un-DHCP like - it is normal
for a DHCP client to re-validate (extend) its lease from time to time,
the only control DHCP has over this really is to send back timers that
control the max time the address is valid (and the suggested rebind time).

There's nothing in 2563 that mentions timers at all, there probably should
be.   One might assume that the lease validity timer of the yiaddr=0 is
intended to be the validity period of the "no autoconfigure", but there's
nothing in the doc that says that, nor is there anything anywhere that
prevents the client validating its address sooner (as soon as it likes).

I use your client Ted (the ISC client that is), and I quite often renew
leases very much sooner than the reply from the server would lead me to
otherwise do (for all kinds of reasons).

Nothing in your message suggests to me that 2563 should be deprecated,
nor that the LL doc shouldn't mandate its use in LL clients.

kre

---

From: Robert Elz <[email-masked]>
Date: Sat, 25 Jan 2003 20:28:15 +0700

Date:        Sat, 25 Jan 2003 18:40:40 +0700
    From:        Robert Elz <[email-masked]>
    Message-ID:  <[email-masked]>

  |   | DHCP cant' say "configure yourself an LL address."
  | 
  | That's what 2653 says isn't it

I meant 2563 (of course).

  |   | - It's voluntary, so it doesn't work - if you really want this, RFC2563 
  |   | isn't the way to get it.

And I missed your meaning there at first reading - you mean that clients
don't need to include the option, in which case the server won't include
it in its reply (it being one of the few "only supply when asked" options).

First, that's one thing I would change in the 2563 - there's no reason I
see for the server not to send the option any time it feels inclined.
There's no more reason this would cause a problem to a random client than
if the server should decide to supply the well known impress printer option.
Ignoring unknown/unwanted options is easy.

Second, even ignoring that, a client that intends to "play by the rules"
(assuming the rules and up as "don't configure yourself a LL address if
the DHCP server says not to, even if it hasn't given you an address" will
include the option in its DISCOVER (and REQUEST) packets, and so get the
response (assuming the server wants to send it).

Clients that have decided to take no notice, including clients implemented
before the LL staandard (or I-D of what it might be eventually) suggest
doing this will obviously not send the option, and if the server obeys
2563 as written now, won't get the "no LL option", and so will go ahead and
configure a LL address anyway.

Once again, I am not wanting to prohibit LL addresses because I think that
LL addresses will magically destroy my network.   I want the client to
not use one (in some cases where I decide) because I know that the client
will be better off with no address, than believing it has an address, which
will not then work (at all).   I want a way to tell the client that.  If
the client believes it knows better than I do (or is simply too old to
know anything at all) then so be it, it won't get the information that I
am trying to convey to it.

kre

---

From: Ted Lemon <[email-masked]>
Date: Sat, 25 Jan 2003 10:11:45 -0800

> Ignoring unknown/unwanted options is easy.

The server is generating a bogus DHCPOFFER.   Sending this to a 
non-rfc2563-compliant client would have unpredictable results.
q

---

From: Robert Elz <[email-masked]>
Date: Sun, 26 Jan 2003 15:18:43 +0700

Date:        Sat, 25 Jan 2003 10:11:45 -0800
    From:        Ted Lemon <[email-masked]>
    Message-ID:  <[email-masked]>

  | The server is generating a bogus DHCPOFFER.   Sending this to a 
  | non-rfc2563-compliant client would have unpredictable results.

If you mean, sending address 0, then yes, but that wasn't what I
meant in the text you quoted.

All I meant was that it would do no harm to include option 116 in
a DHCPOFFER, no more than any other option the server is configured
to send (that is, option 116 along with a normal IP address).

But even in the case where the server sends a full 2563 response,
with addr=0.0.0.0 and option 116, why would I care what the results
are in the client?   (Anything from crashing, to thinking it owns
address 0, to ...)

The only point of sending such a response is when it isn't intended to
work on the net in the first place, what happens to it (especially if
it has a poor dhcp client implementation with no sanity checking) shouldn't
bother anyone overly much.

kre