Subject: WG consensus action: when to configure LL addrs

From: erik guttman <[email-masked]>
Date: Wed, 05 Feb 2003 12:54:16 +0100

This messages is an assessment of working group consensus from
discussion on the WG mailing list in the past weeks as a response
to Thomas Narten's posting below.

The summary of the consensus follows.

ACCEPTED:
   IPv4 LL configuration of interfaces has restricted applicability
   to the case where an interface does not obtain configuration in
   any other way (such as manual configuration, DHCP, etc.)  A host
   obtaining such a configuration MUST NOT continue using the IPv4
   LL configuration as well.

   NOTE WELL:  This is a major change to the existing draft.

ACCEPTED:
   Hosts conforming to the specification which receive an datagram
   with an IPv4 LL source address MUST NOT reply by sending a datagram
   to a router for forwarding.  The host MUST use ARP to resolve the
   address and forward the datagram to the destination the IPv4 LL
   address resolves to.

   NOTE WELL:  A compliant host can communicate with a peer which has
   IPv4 LL address even if the host has a global address by applying
   this datagram forwarding policy.

WG chair assessment:
   On both of these points there was clear WG consensus.  This resolves
   a number of issues of source address selection.  The above also
   ameliorates issues arising from application interoperability when
   using addresses of mixed scopes since (a) systems will not operate
   with both link-local and global scope addresses and (b) it is likely
   that if DHCP or manual configuration is performed, it will be to all
   (not some subset) of hosts on the network *eventually.*

   Further:  This is how IPv4 LL autoconfiguration works today in Windows
   systems and most versions of Apple Macintosh.

REJECTED:
   This specification will define or require some additional mechanism
   to disable IPv4 LL autoconfiguration.

WG chair assessment:
   This suggestion has been brought up in past last calls and again in
   this discussion.  There again fails to be anything like working group
   consensus to support or introduce this feature.  There are very clear
   and unchallenged technical arguments from Ted Lemon indicating that
   there are severe security considerations with coercive deactivation
   IPv4 LL autoconfiguration.

These changes will result in changes to the IPv4 LL specification
(the text of which is not included in this message).

A few comments are interspersed with Thomas's original message.

Sender: Thomas Narten <[email-masked]>
Date: 22.01.03 15:50
Subject: WG decision: when to configure LL addrs

 > 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)

1a received general support.

 >   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
 >
 > Keith Moore <[email-masked]> writes:
 >
 >
 >>> On Wed, 22 Jan 2003 10:01:30 +1000 (EST)
 >>> Ian Lister <[email-masked]> wrote:
 >>> On Tue, 21 Jan 2003, Philip Nye wrote:
 >>>>Joshua,
 >>>>
 >>>>> 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.
 >>>>
 >>>> 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.
 >>>
 >>> 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?
 >>
 >> 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)

Aidan Williams suggested:
 > 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".

This was generally agreed to by those who responded.  I take this to
imply that an interface will be configured with an IPv4 LL address
*only if it does not obtain address configuration by some other means.*
This takes Keith's text and generalizes it, removing the 'routable'
qualifier to the address and the mention of DHCP.  (There are other
ways to obtain an address - RARP, manual configuration, etc).

 >> - 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.

Aidan responded:
 > 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.

Given that an interface will now only have an IPv4 LL address
configured if it does not have any other address configuration,
I do not see that there is any difference between Keith and
Aidan's positions.

 >> - 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.

Aidan suggested replacement text for the suggestion which enjoyed
wide support:
 >   An application with a choice between connecting to LL address and
 >  non-LL address SHOULD prefer the non-LL address.

 >> - 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.

Erik Guttman
ZEROCONF WG cochair

---

From: Ian Lister <[email-masked]>
Date: Wed, 5 Feb 2003 22:07:17 +1000 (EST)

Sounds great - ship it! :-)

Actually, just one minor note below.

>   LL configuration as well.

I agree that is fine in the absence of explicit configuration to the
contrary on the host, but I don't think the protocol should forbid the
implementation from allowing the user to manually keep using IPv4LL after
a global address has been acquired.

I can't imagine that would be too contentious but if it is then forget I
mentioned it...

Ian

---

From: "John C. Welch" <[email-masked]>
Date: Wed, 05 Feb 2003 07:50:25 -0500

>    NOTE WELL:  This is a major change to the existing draft.

I'm so tired of this argument, that I no longer care, but I think that this
is going to bite us in the heiny big time. And I see "DHCP DeathTraps" as
the fun new prank this year.

john

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

---

From: Alex Karahalios <[email-masked]>
Date: Wed, 5 Feb 2003 09:10:00 -0700

Hi Erik,

I'm not sure how you arrived at a consensus on this point? I think that 
there were some very vocal people in favor of this. Maybe this weighs 
more heavily than those of us who were not as vocal and would rather 
see that IPv4 and other configurations coexist.

My view comes from actually implementing IPv4 and DHCP in a small 
embedded device. It's much easier to leave both configurations around 
rather than "pulling the plug" from IPv4 after a DHCP address is 
obtained. Many times, services on a small embedded device are tied to 
specific IP addresses and having one of those addresses go away defeats 
the purpose of the device.

This "major change" is not a show stopper - it just means more 
development time spent adding code to a memory restricted device to 
handle the case of IPv4 addresses no longer being valid.

I still don't see how having both types of addresses on a device does 
any harm to anything but the device itself. I think this spec. should 
not be dictating to us how many IP addresses we may use at any time - 
just like there is no spec telling us that we cannot use multiple 
static IP addresses.

Thanks for listening,

Alex Karahalios

---

From: Vincent Lubet <[email-masked]>
Date: Wed, 5 Feb 2003 09:18:34 -0800

>    NOTE WELL:  This is a major change to the existing draft.

I do not think there was a clear consensus on "MUST NOT". Many opinions 
expressed on this topic where much more nuanced so I think the text 
should read "SHOULD NOT".

I remember the argument was made that if before acquiring a non LL 
address the host had established communications using IPv4 LL address, 
the host should be able to continue to use IPv4 LL.

The typical example is a host at home that starts a long print job 
using LL and the the home router to the Internet. The home router 
assigns a DHCP address to the host that is still talking to printer 
with IPv4 LL. I don't think the print job should be aborted at that 
point.

Vincent

---

From: Keith Moore <[email-masked]>
Date: Wed, 5 Feb 2003 12:39:30 -0500

> with IPv4 LL. I don't think the print job should be aborted at that 

Agree "MUST NOT continue using" is too strong and too imprecise.

I would argue for "MAY continue using" the LLv4 address on already-open
connections, "SHOULD discontinue" accepting new connections sent to the LLv4
destination address, and "SHOULD discontinue" using the LLv4 address as a
source address for new connections.  However I'd also argue that a reasonable
effort SHOULD be made to acquire an address via DHCP before a host ever
attempts to configure or use an LLv4 address.

The intent is that the host should play well in the network environment in
which it finds itself, not that operations that are already in progress should
be disrupted. But since the best way to do this may vary from one kind of host
to another (especially for special-purpose hosts), it seems appropriate to
allow some implementor discretion in determining the best way to do this.

I would also support "hosts MAY provide a means for users to manually override
use of DHCP" language.

Keith

---

From: Mika Liljeberg <[email-masked]>
Date: 05 Feb 2003 19:53:20 +0200

>    NOTE WELL:  This is a major change to the existing draft.

This sounds like a really bad idea.

Any sessions already using the LL address would be forcibly torn down
when a global address appears. This is an implementation nightmare.

Implementations capable of having multiple addresses per interface
should be allowed to keep their LL address.

Regards,

	MikaL

---

From: joe holt <[email-masked]>
Date: Wed, 5 Feb 2003 10:03:51 -0800

> I would also support "hosts MAY provide a means for users to manually 

I agree with Vincent and Keith that MUST NOT is too strong, and I 
support Keith's suggested changes in wording. Existing LLv4 connections 
should not be torn down or disrupted. A client should try to switch 
over to using a non-LLv4 address when it becomes available.

/joe

--------
Joe Holt
Manager, Utilities Applications
Apple Computer, Inc.

---

From: Mika Liljeberg <[email-masked]>
Date: 05 Feb 2003 20:07:49 +0200

On Wed, 2003-02-05 at 19:39, Keith Moore wrote:
> source address for new connections.

I don't see any reason not to continue using LL source address with LL
destination addresses. The source address selection rules should take
care of this automatically.

>   However I'd also argue that a reasonable

This is too slow for ad-hoc configurations in environments like Buetooth
PAN. The rational way for devices like these would be to configure LL
addresses in parallel with trying DHCP and to support at least two
addresses per interface. Otherwise the address configuration delay
becomes prohibitive to the user.
 
Besides, going for rules different from IPv6 just causes headaches for
hybrid IPv4/IPv6 stack implementors.

	MikaL

---

From: Mika Liljeberg <[email-masked]>
Date: 05 Feb 2003 22:08:04 +0200

On Wed, 2003-02-05 at 20:58, Keith Moore wrote:
> relying on source address selection is a pretty dubious idea anyway.

Not sure what you mean. Surely it is preferable to select a source
address that has a matching scope with the destination address, rather
than recommending that the node select a source address with a different
scope?

The recommendation should be that applications should choose a global
destination address over a link local one, whenever possible. This
places the onus on the mechanism by which a destination address is
acquired (e.g. LL Multicast Name Resolution).

As for source address selection rules, longest prefix match seems to
work well enough for IPv6. Why not for IPv4?

> .. "SHOULD discontinue" accepting new connections sent to the LLv4
destination address

This is even worse. If the peer only knows your LL address, this causes
loss of connectivity.

> > > effort SHOULD be made to acquire an address via DHCP before a host
> > > ever attempts to configure or use an LLv4 address.
> > 
> > This is too slow for ad-hoc configurations in environments like
> > Buetooth PAN. The rational way for devices like these would be to
> > configure LL addresses in parallel with trying DHCP and to support at
> > least two addresses per interface. Otherwise the address configuration
> > delay becomes prohibitive to the user.
> 
> well, the whole purpose of SHOULD is to allow some latitude. 

I appreciate that. I just think that this does not need to be said. If a
node is allowed to have multiple addresses, including a link local one,
the order in which the addresses are acquired is irrelevant.

> if you want us to say that v4LL should only be used for the same
> purposes that v6LL is intended to be used for (e.g. router/neighbor
> discovery), and not for normal applications, that's quite fine with me.

Ideally, the same recommendations should apply. 

Of course, applications are likely to use LL addresses when nothing else
is available. Again, Bluetooth PAN is one example.

	MikaL

---

From: Keith Moore <[email-masked]>
Date: Wed, 5 Feb 2003 15:31:04 -0500

> than recommending that the node select a source address with a
> different scope?

Nope.  It is far preferable to always use the widest scope address that
is available and to avoid using limited-scoped addresses as much as
possible, for both source and destination.

> acquired (e.g. LL Multicast Name Resolution).

The idea that you can control use of scoped addresses by the means by
which hosts acquire addersses is a fallacy.  There are too many ways in
which hosts acquire addresses, and it's not reasonable to expect  hosts
to keep track of network topology.

> work well enough for IPv6. Why not for IPv4?

It's broken for IPv6 also.  At least, the idea that it's useful to
use a limited scope address when a larger scoped one is available is
broken, and address selection can't solve the problems that result.

> This is even worse. If the peer only knows your LL address, this
> causes loss of connectivity.

Notice I didn't say "SHOULD immediately discontinue".  One of the
reasons I phrased it this way was to provide some chance for hosts that
already had LL addresses to discover and begin using the new address.  

But the bottom line is that scoped and limited-duration addresses are
both broken. They create a lot of problems that can't be fixed.  They
are useful for limited cases such as ad hoc newtorks, but their
limitations need to be respected, and they need to be used sparingly. 
Which implies, among other things, that it's far better for a device to
start out using a stable, routable address whenever possible, than to
start out using an LL address and try to fail over to a routable one at
a later time.  As for trying to use both, this doesn't play well with
existing networks and applications.  And why use an LL address when a
routable one will work better?
 
> > > > effort SHOULD be made to acquire an address via DHCP before a
> > > > host ever attempts to configure or use an LLv4 address.
> > > 
> > > configure LL addresses in parallel with trying DHCP and to support
> > > at least two addresses per interface. Otherwise the address
> > > configuration delay becomes prohibitive to the user.
> > 
> I appreciate that. I just think that this does not need to be said. If
> a node is allowed to have multiple addresses, including a link local
> one, the order in which the addresses are acquired is irrelevant.

This gets back to the question of whether it is reasonable for a device
to use a different IP address other than the one assigned to it by DHCP.
I think that by default the device needs to respect what the network
assigns to it.  

If you want to define a separate way that the network can say "it's okay
to use LL also" or for that matter "it's okay to use these N IPv4
addresses" then fine, but that seems out of scope for this WG.  At
least that question should be deferred for the time being so that we can
get this RFC out the door.

Keith

---

From: Mika Liljeberg <[email-masked]>
Date: 05 Feb 2003 23:51:44 +0200

> possible, for both source and destination.

You're just proposing a different source address selection rule. I would
be happy enough with this if you can get the same rule applied for IPv6
as well.

I don't think the benefits outweigh the burden of having different rules
for IPv4 and IPv6.

> to keep track of network topology.

I was suggesting that applications should choose a global scope
destination address whenever one is available. That is a simple enough
rule, and can be implemented as part of a name resolver. In fact, above
you just proposed this very same rule yourself.

Applying this rule to destinationa address selection is enough to cause
new connections to not use LL addresses.

> already had LL addresses to discover and begin using the new address.  

If the node continues to accept connections to the LL address, it might
as well do so indefinitely, since there is no way to come up with a
meaningful deprecation period.

> limitations need to be respected, and they need to be used sparingly.

I agree on principle, scoped addresses are a pain. As an implementor,
however, I disagree with needlessly specifying divergent behaviour
between IPv4 and IPv6. That is more pain.

> a later time.

This recommendation is only relevant for implementations that are
limited to a single address per interface. Let's not make it a
straight-jacket for implementations that aren't.

>   As for trying to use both, this doesn't play well with

Experience with our implementation does not support this view.

> If you want to define a separate way that the network can say "it's okay to use LL also" or for that matter "it's okay to use these N IPv4
> addresses" then fine, but that seems out of scope for this WG.

I agree, mechanisms that allow the network to dictate policy are out of
scope. So is making assumptions about what that policy might be.

	MikaL

---

From: Mika Liljeberg <[email-masked]>
Date: 06 Feb 2003 01:16:52 +0200

Keith,

This is getting out of hand and I'm not interested in a shouting match.
I think I've made my point to the WG and I'll just say this. I'd agree
to language such as:

"IPv4 LL configuration of interfaces has limited applicability beyond
the case where an interface does not obtain configuration in any other
way (such as manual configuration, DHCP, etc.)  A host obtaining such a
configuration MAY continue using the IPv4 LL configuration as well.
However, such a host SHOULD make every effort to deprecate the LL
configuration when initiating new connections."

Leave the other things as implementation details, as they should be.

	MikaL

On Thu, 2003-02-06 at 00:46, Keith Moore wrote:
> > > >  Surely it is preferable to select a source
> > > > address that has a matching scope with the destination address,
> > > > rather than recommending that the node select a source address
> > > > with a different scope?
> > > 
> > > Nope.  It is far preferable to always use the widest scope address
> > > that is available and to avoid using limited-scoped addresses as
> > > much as possible, for both source and destination.
> > 
> > You're just proposing a different source address selection rule. 
> 
> That's only part of it.  The more important part of what I'm proposing
> is that we stop pretending that scoped addresses are satisfactory for
> most purposes.  Fortunately, IPv6 folks seem to be figuring this out
> already.
> 
> > I don't think the benefits outweigh the burden of having different
> > rules for IPv4 and IPv6.
> 
> Well, I don't think the benefits of v4LL outweigh having to support LL
> addresses in both IPv4 and IPv6.  v6LL should be sufficient, especially
> once you acknowledge that v4LL isn't suitable for general purposes
> either.  But I've been assuming that the WG is going to get v4LL anyway,
> so have been trying to minimize the harm done.
> 
> > > > The recommendation should be that applications should choose a
> > > > global destination address over a link local one, whenever
> > > > possible. This places the onus on the mechanism by which a
> > > > destination address is acquired (e.g. LL Multicast Name
> > > > Resolution).
> > > 
> > > The idea that you can control use of scoped addresses by the means
> > > by which hosts acquire addersses is a fallacy.  There are too many
> > > ways in which hosts acquire addresses, and it's not reasonable to
> > > expect  hosts to keep track of network topology.
> > 
> > rule, and can be implemented as part of a name resolver. 
> 
> NO IT CANNOT.  It is completely unreasonable to assume that applications
> only get their addresses via a single API or protocol.
> 
> > In fact, above you just proposed this very same rule yourself.
> 
> Nope.  Address selection and name resolver API are very different.
> 
> > > reasons I phrased it this way was to provide some chance for hosts
> > > that already had LL addresses to discover and begin using the new
> > > address.  
> > 
> > If the node continues to accept connections to the LL address, it
> > might as well do so indefinitely, since there is no way to come up
> > with a meaningful deprecation period.
> 
> No, it doesn't follow.  Given a choice between "terminate immediately"
> and "accept connections indefinitely" the former is preferable.  But a
> more reasonable choice would be somewhere in the middle.  Exactly where
> in the middle probably depends on the characteristics of the
> applications supported by the host.
> 
> Perhaps language like "SHOULD cease to accept new connections at the
> v4LL address as soon as practicable" would be better. 
> 
> > > But the bottom line is that scoped and limited-duration addresses
> > > are both broken. They create a lot of problems that can't be fixed. 
> > > They are useful for limited cases such as ad hoc newtorks, but their
> Then you presumably agree that we shouldn't be bothering with v4LL at
> all?  That would certainly minimize the special casing.
> 
> There will always be some differences between IPv4 and IPv6, and for
> good reason. v6 deliberately changed some things from v4 behavior. On
> the other hand, there's no need to worry about the impact of v6LL on
> v4 apps, but there is a need to worry about the impact of v4LL on v4
> apps.
> 
> > > Which implies, among other things, that it's far better for a device
> > > to start out using a stable, routable address whenever possible,
> > > than to start out using an LL address and try to fail over to a
> > > routable one at a later time.
> > 
> > limited to a single address per interface. 
> 
> No, it makes sense to apply this on a per-interface basis.
> 
> > > existing networks and applications.  And why use an LL address when
> > > a routable one will work better?
> > 
> And experience with our applications does not support your view.
> 
> > > If you want to define a separate way that the network can say "it's
> > > okay to use LL also" or for that matter "it's okay to use these N
> > > IPv4 addresses" then fine, but that seems out of scope for this WG.
> > 
> > I agree, mechanisms that allow the network to dictate policy are out
> > of scope. So is making assumptions about what that policy might be.
> 
> Well then you'd agree that it's not appropriate for this WG to assume
> that it's okay to send LL on a network that assigns a routable v4
> address - because that's making an assumption about that network's
> policy.
> 
> Look, the "don't use LL if you have a DHCP address" is a compromise, and
> we shouldn't pretend that it's anything other than that.  Ideally the
> network would be able to clearly specify what addresses a host could
> use as a matter of policy. Ideally hosts could reliably determine
> whether such policy specifications were actually being made on authority
> of the network operator and ignore those that aren't.  Ideally hosts
> could reliably determine whether they were on a network for which there
> was an explicit policy or whether they were on a network (say an ad hoc
> network) for which there was no such policy.  Ideally all hosts would be
> given stable, globally routable addresses.
> 
> For various reasons, we're not currently able to provide these ideal
> conditions.   What we're trying to do is to pick some sort of balance
> that minimizes the harm until we can improve conditions. Using and
> trusting DHCP (by default, in the absence of manual configuration) as an
> indication that a host should not use LL is better than either requiring
> manual configuration of LL in all cases or having LL automatically
> configured in all cases.   For the cases where it doesn't work, manual
> configuration is a backup.  Eventually, perhaps, we can provide
> mechanisms which are more flexible and/or more secure than this, which
> maintain the required balance of interests with fewer failures and less
> user effort. 
> 
> But I really have to wonder whether it's worth it to invest any more
> effort in v4LL anyway, given that the limitations of v4 are really
> starting to show.
> 
> Keith

---

From: Aidan Williams <[email-masked]>
Date: Thu, 06 Feb 2003 10:56:35 +1100

Firstly, thanks Erik for grasping the nettle once again in an
attempt to get some closure on this.

>    NOTE WELL:  This is a major change to the existing draft.

What is missing in this (as other people have also pointed out)
is the idea that existing v4 LL connections can continue, but that
new LL connections should make use of the non-LL address.

> I do not see that there is any difference between Keith and

Hmm.  I would like the text not to be more restrictive than it
needs to be -- just dropping the "and the IPv4LL address is the
only address associated with that interface" text would work for me.
If an administrator chooses to allow the v4-LL address to
co-exist on an interface, why should we prohibit it?

- aidan

---

From: Keith Moore <[email-masked]>
Date: Wed, 5 Feb 2003 19:05:03 -0500

> I'd agree to language such as:
> 

That's simply not acceptable, as the last several months' worth of discussion
should have made clear.

---

From: Keith Moore <[email-masked]>
Date: Wed, 5 Feb 2003 19:18:56 -0500

> co-exist on an interface, why should we prohibit it?

The point of the "only address associated with the interface" was that if the
use of LL is implicit in some other explicit choice (such as that of the
interface) made by the application, then it seems appropriate to use LL.  
That and I was trying to avoid having the text forbid use of LL in a case
where there was no other way to satisfy the application's request.

But you don't ever want to use an LL source address when a routable source
address will do.

Keith

---

From: Aidan Williams <[email-masked]>
Date: Thu, 06 Feb 2003 11:29:04 +1100

> where there was no other way to satisfy the application's request.

So, can you live with dropping the "and the IPv4LL address is the
only address associated with that interface" ?

- aidan

---

From: "John C. Welch" <[email-masked]>
Date: Wed, 05 Feb 2003 19:29:49 -0500

> That's simply not acceptable, as the last several months' worth of discussion

<sarcasm>

v4LL, having come far too close to a consensus shall now return back into
argument mode

</sarcasm>

john

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

---

From: Keith Moore <[email-masked]>
Date: Wed, 5 Feb 2003 19:41:28 -0500

On Thu, 06 Feb 2003 11:29:04 +1100
Aidan Williams <[email-masked]> wrote:

> Keith Moore wrote:
> > The point of the "only address associated with the interface" was that if
> > the use of LL is implicit in some other explicit choice (such as that of
> > the interface) made by the application, then it seems appropriate to use
> > LL.  That and I was trying to avoid having the text forbid use of LL in a
> > case where there was no other way to satisfy the application's request.
> 

No.  I'm sure there is another way to specify the same thing, probably with
better precision or greater clarity than what I suggested.  But simply
dropping that text fragment would allow use of LL source addresses in
situations where it should not be used, and I don't think it's a good idea for
this document to define behavior in terms of a specific API.

perhaps: "SHOULD NOT use an LL source address unless the application has
unambiguously requested this."

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 5 Feb 2003 19:46:13 -0500

On Wed, 05 Feb 2003 19:29:49 -0500
"John C. Welch" <[email-masked]> wrote:

> > That's simply not acceptable, as the last several months' worth of
> > discussion should have made clear.
> 

If consensus can only be achieved by making the document deliberately
imprecise in order to gloss over the failure to resove a known problem, then
we're better off without it.

However, my reading is that the group does have rough consensus on this.  It's
vague language like "MAY continue using the IPv4 LL configuration" that I'm
objecting to.  I should have made that clearer in my previous message.

Keith

---

From: Aidan Williams <[email-masked]>
Date: Thu, 06 Feb 2003 12:03:29 +1100

> unambiguously requested this."

Remarkable.  I can live with that.
- aidan

---

From: Keith Moore <[email-masked]>
Date: Wed, 5 Feb 2003 20:11:34 -0500

> Remarkable.  I can live with that.

woohoo!   is it (virtual) beer time yet?

Keith

---

From: Robert Elz <[email-masked]>
Date: Thu, 06 Feb 2003 18:33:20 +0700

Date:        Wed, 05 Feb 2003 12:54:16 +0100
    From:        erik guttman <[email-masked]>
    Message-ID:  <[email-masked]>

  | The summary of the consensus follows.

There's been enough discussion of your first couple of
points already, I don't see the need to add more.   But ...

  | REJECTED:
  |    This specification will define or require some additional mechanism
  |    to disable IPv4 LL autoconfiguration.
  | 
  | WG chair assessment:
  |    This suggestion has been brought up in past last calls and again in
  |    this discussion.  There again fails to be anything like working group
  |    consensus to support or introduce this feature.

I'd agree with that assessment, but not with the conclusion.

You could just as easily say that there fails to be anything like WG
consensus to exclude it.

What this eventually comes down to is that the doc author writes whatever
he likes, and unless there's WG consensus to change it, it stays the way
it is written.

That's not the way the IETF works (or it isn't the way it is supposed to
work).   What's supposed to happen, is that the WG is supposed to reach
at least rough consensus that the document is acceptable, which does not
mean reaching a stage where there are no remaining issues upon which
consensus can be reached, so the rest just get left however they happen
to exist.

One way or another, some kind of (rough) consensus needs to be reached
on this issue (note: we're not debating here whether an existing protocol
should be changed, where you can say "no consensus to make a change").

But this part

  |    There are very clear
  |    and unchallenged technical arguments from Ted Lemon indicating that
  |    there are severe security considerations with coercive deactivation
  |    IPv4 LL autoconfiguration.

is simply wrong.   I certainly challenged Ted's arguments (several times).
Ted didn't even reply to my last message on the issue (whether that was due
to exhaustion, or finally realising his mistake, I can't tell).   The
security considerations argument against this is simply bogus.   That of
itself doesn't necessarily mean that there must necessarily be a way to tell
a device to not configure itself on a LAN at all, but using the bogy man of
"security" as if it were an unassailable argument against this is not going
to achieve anything.

kre

---

From: Robert Elz <[email-masked]>
Date: Thu, 06 Feb 2003 18:40:11 +0700

Date:        05 Feb 2003 20:07:49 +0200
    From:        Mika Liljeberg <[email-masked]>
    Message-ID:  <1044468469.1516.40.camel@devil>

  | >   However I'd also argue that a reasonable
  | > effort SHOULD be made to acquire an address via DHCP before a host ever
  | > attempts to configure or use an LLv4 address.
  | 
  | This is too slow for ad-hoc configurations in environments like Buetooth
  | PAN.

I suspect that you're overestimating what is required of "reasonable effort".

I'd be happy if a node sent a DHCPDISCOVER, got no reply in 0.2 seconds,
sent another, again got no reply (perhaps just wait 0.1 seconds this time)
and then, said "OK, I'll do the LL thing" - while continuing to look for
a DHCP answer in parallel.

Even there, those times are probably more than really required.  Most of
the time, nodes will get replies to DHCP requests quite quickly, when
one doesn't appear promptly, the chances are that there won't be one, so
at that point, starting to get a LL address seems reasonable to me.

That is, there's no need to wait until all hope of obtaining a LL address
has been abandoned (for now anyway) - but avoiding starting on the ARP
merry-go-round for LL addresses, when a (quite short) delay would have
avoided that seems like a very good idea to me.

  | Besides, going for rules different from IPv6 just causes headaches for
  | hybrid IPv4/IPv6 stack implementors.

All this stuff is completely different in IPv6, there is simply no
comparison.

kre

---

From: Keith Moore <[email-masked]>
Date: Thu, 6 Feb 2003 10:16:09 -0500

I generally agree with KRE here.  

My suggestion is that we agree to move forward with the current compromise
(by default, implementations use a DHCP address in preference to an LL
address) and that we agree that explicit indication from DHCP to enable
LL, explicit indication from DHCP to disable LL, and protection of clients
from denial-of-service due to spoofed DHCP, are all topics for future
study - perhaps even by another group (since they all have to do with DHCP).

I'll note that DHCP already has a worked-out solution for authentication,
which, though not widely deployed, may at least serve as a starting point
for those with the last concern.

Keith

---

From: Ted Lemon <[email-masked]>
Date: Thu, 6 Feb 2003 13:14:21 -0600

> to exhaustion, or finally realising his mistake, I can't tell).

It was due  to the fact that it didn't seem productive.   You simply 
don't agree with me about this.   What am I supposed to do about that?  
  Erik asked us to stop flaming endlessly about this stuff.   I think it 
was a reasoable request.   So I'd like to honor it.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 6 Feb 2003 13:15:53 -0600

> a DHCP answer in parallel.

Many DHCP servers wait a full second for the ping test to happen, so 
these timeframes aren't really going to help - functionally, this is 
equivalent to not waiting at all.

---

From: Robert Elz <[email-masked]>
Date: Fri, 07 Feb 2003 18:23:29 +0700

Date:        Thu, 6 Feb 2003 13:14:21 -0600
    From:        Ted Lemon <[email-masked]>
    Message-ID:  <[email-masked]>

  | It was due  to the fact that it didn't seem productive.   You simply 
  | don't agree with me about this.   What am I supposed to do about that?

We should probably attempt to work out just what it is that one of us
is not understanding about the other's position (argument, belief) that
has led to this.   This isn't an issue where the arguments are just
based upon religious views (on either side), but one of us seems to be
seeing something that isn't being communicated very well to the other.

  |   Erik asked us to stop flaming endlessly about this stuff.   I think it 
  | was a reasoable request.   So I'd like to honor it.

I don't think that either of us was "flaming" on this particular issue.

In general, I like to work these things out in public, so everyone (and
the archives) have a record of just what happened, and why (and that's
true when when it means that the outcome is that it becomes obvious that
I had no idea what I was talking about).

But if you would like to explain to me what about the last message I sent
was wrong in your opinion, I'd be happy to receive it, even in private mail.

kre

---

From: Robert Elz <[email-masked]>
Date: Fri, 07 Feb 2003 18:35:33 +0700

Date:        Thu, 6 Feb 2003 13:15:53 -0600
    From:        Ted Lemon <[email-masked]>
    Message-ID:  <[email-masked]>

 | Many DHCP servers wait a full second for the ping test to happen,

Yes, I know that.

  | so these timeframes aren't really going to help - functionally, this is 
  | equivalent to not waiting at all.

Not quite.   But if you believe that waiting a very short while to see
if a DHCP response appears is functionally no different to not waiting,
then there can't really be an objection to the delay.

Why it makes a difference, is that (using the short timer figures from
2.3 of the draft) it takes just about a second for the LL ARP probe
cycle to complete.   That is, if it is started at just the same time as
the DHCP query, and there's a DHCP server that does wait a second (plus
overheads) for a ping response (to fail to arrive) then with the extra
0.3 second or so delay, it is still likely that the DHCP answer will be
available before the node has concluded that its LL address is really free
(so the node can simply abandon its LL allocation in progress, and use
the DHCP provided address).

On the other hand, without that extra delay, the LL ARP probe is likely to
finish before this kind of DHCP server will ever reply, so the node will
always end up picking a LL address, using it for some fraction of a second
(just enough time to get started) and then have that overridden by the
DHCP answer.

In either case, either a "fast" (sloppy if you like) DHCP server, in which
case the node would be able to avoid even starting the LL ARP probes, or
with a "slow" (safe if you like) DHCP server, it will at least normally
avoid the LL address allocation completing.

Of course, for any node using the 8-10 second timers for LL allocation, none
of this really makes much difference, with that amount of delay (as useless
as it actually is for claimed purpose), the node may as well wait several
seconds for a DHCP answer before starting, it is only a small (percentage)
increase in the overall delay.

kre

---

From: Mika Liljeberg <[email-masked]>
Date: 07 Feb 2003 19:40:43 +0200

>From the user perspective waiting just a short period is certainly
better than waiting for the DHCP client to give up. However, this still
creates a dependency between the DHCP implementation and the v4LL
implementation, which I would like to avoid. These could be completely
separated in the implementation architecture. If it is ok to run DHCP
and v4LL configuration in parallel in a staggered fashion, it must be ok
to run them in parallel without any timing interdependencies.

Another (minor) point is that certain wireless links have latencies
substantially higher than 0.1 seconds (e.g. 0.5..1 seconds for
Bluetooth). Any such devices would have to wait for somewhat longer in
order to discover a DHCP server.

	MikaL

---

From: Ted Lemon <[email-masked]>
Date: Fri, 7 Feb 2003 11:53:00 -0600

> has led to this.

I really tried, and believe I failed.   I do not really understand how 
the facts you've stated support your position, and I don't see how to 
get you to how the facts I've stated support mine.   I don't think 
there's a disconnect in terms of each other's factual basis for drawing 
our conclusions.   Rather, I think that you and I disagree on the 
hypothetical gravity of two situations that haven't been tested in the 
real world.   Honest engineers can have such disagreements.

> This isn't an issue where the arguments are just

I think you're right that this isn't religious.   That doesn't make it 
tractable, unfortunately.

> I don't think that either of us was "flaming" on this particular issue.

I don't mean flaming in the sense of yelling.   I mean flaming in the 
sense of going 'round and 'round without making progress.   In that 
sense, we were both flaming.

> was wrong in your opinion, I'd be happy to receive it, even in private 

I have explained, over and over again.   I've wasted countless hours of 
my employer's time trying to resolve my differences with you and with a 
couple of other people on this mailing list, to no avail.   I need to 
go back to doing the work they pay me to do.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 7 Feb 2003 12:26:06 -0600

> then there can't really be an objection to the delay.

I see where you're coming from, but your argument could easily go in 
exactly the opposite direction with the same supporting facts.   Sure, 
if we delay 0.3 seconds, we are never going to get a response from the 
DHCP server in that time anyway, so it doesn't delay  IPv4ll 
configuration more than 0.3 seconds.   On the other hand, if we're 
never going to get a response from the DHCP server during the allotted 
timeout anyway, why bother waiting?

If we need to wait until a DHCP server has had a reasonable time to 
respond, our specification needs to be a lot more complicated than it 
is.   For example, let's say we want to delay until a DHCP transaction 
has either succeeded or failed.   So we wait, say, 1.5 seconds to give 
the DHCP server time to send us a DHCPOFFER.   And during that time, 
the DHCPOFFER arrives.   Okay, now our DHCP client is engaged, and 
following its own timing requirements.   Now that we have the 
DHCPOFFER, does the DHCP client tell the IPv4ll state machine to wait?  
  If so, for how long?   Until the transaction has completed?   What if 
it doesn't complete?

What do we write in the draft to account for this situation?   Is it 
even the right thing to do to try to account for this in the draft?   
Honestly, I think it's best not to say, because if we do say, we open 
up a huge can of worms, and this becomes the DHCP+IPv4ll draft, not the 
IPv4ll draft.

If DHCP and IPv4ll interfered with each other strongly, we'd need to 
address this.   But they don't.   If I get an IPv4ll address, and then 
two seconds later I get a DHCP address, the draft already says what to 
do, and what it says to do will work just fine.   So there is no need 
to further address this in the draft, and furthermore I think it would 
be dangerous and harmful to try to do so.

---

From: Robert Elz <[email-masked]>
Date: Sat, 08 Feb 2003 20:27:14 +0700

Date:        Fri, 7 Feb 2003 12:26:06 -0600
    From:        Ted Lemon <[email-masked]>
    Message-ID:  <[email-masked]>

  | On the other hand, if we're 
  | never going to get a response from the DHCP server during the allotted 
  | timeout anyway, why bother waiting?

Not never Ted, just never from your (or some other) servers.   Servers
that don't do the ping test (which includes the way I use your server)
will usually send an offer much quicker than that - but I certainly take
the point that someone else made that all of these timers depend upon
the network technology in use, and I'd suggest probably should be specified
to vary based upon that - otherwise we can't do otherwise than end up with
timer values set to allow the slowest technologies to cope - and the slowest
I'm aware of are 802.x nets with 802.1d enabled on the link.   For those,
even the timer values in section 2.2 aren't nearly long enough.

  | Now that we have the 
  | DHCPOFFER, does the DHCP client tell the IPv4ll state machine to wait? 

I would, yes.

  | If so, for how long?   Until the transaction has completed?   What if 
  | it doesn't complete?

Yes to Q2 there, which answers Q1, and if it fails, then the LL thing can
just start again.

I'm not about to worry much about that case, this is a very rare event,
and attempting to put in special cases to handle rare events isn't worth
the bother.   Once a week, somewhere in the world, a device will wait
an extra 10 seconds or so before giving itself an LL address.   Why worry?

  | What do we write in the draft to account for this situation?   Is it 
  | even the right thing to do to try to account for this in the draft?   
  | Honestly, I think it's best not to say, because if we do say, we open 
  | up a huge can of worms, and this becomes the DHCP+IPv4ll draft, not the 
  | IPv4ll draft.

If this draft did no more that define v4LL addresses, and say how they
can be configured (that is, explain the ARP probes, etc), I'd tend to
agree with you.   But it doesn't - it also tries to tell nodes that
they should all configure LL addresses, and always keep the things (the
latter part in the process of being removed now).   That means that
it is already getting involved with what should be configured, or not
configured, and when.

  | If DHCP and IPv4ll interfered with each other strongly, we'd need to 
  | address this.   But they don't.

I agree, they don't.   Where things get messy is when the node ends up
having an address from both.

The WG already seems agreed that that should not happen, it should be
one or the other (with the open question of "neither" not relevant here).

This particular issue (the timers) relates to how to get from nothing,
to having a single address, in the smoothest way possible (and ideally
as quickly as possible).

kre

---

From: Mika Liljeberg <[email-masked]>
Date: 08 Feb 2003 15:47:37 +0200

> having an address from both.

People keep saying that without offering any real evidence.

Things only get messy when nodes start mixing an LL source address with
a routable destination address, or vice versa. If the scopes of the
source and destionation addresses are required match, things become very
clear indeed.

> one or the other (with the open question of "neither" not relevant here).

I don't. And I've seen comments from others who don't seem to agree
either.

	MikaL

---

From: Robert Elz <[email-masked]>
Date: Sat, 08 Feb 2003 21:37:39 +0700

Date:        08 Feb 2003 15:47:37 +0200
    From:        Mika Liljeberg <[email-masked]>
    Message-ID:  <1044712056.11519.5.camel@devil>

  | If the scopes of the source and destionation addresses are required match,
  | things become very clear indeed.

Yes, but you cannot require that - not in the sense that it is not
a good idea, in the sense that it is impossible.

A link can have nodes on it that have only v4LL addresses (to satisfy
everyone, let's assume that such a node attempted to get an address via
DHCP, failed to get a response, and then assigned itself a LL address,
though how it happened doesn't matter).

A link can also have nodes on it that have never heard of v4LL addresses,
and have only old fashioned "routable" addresses.

If some other node, that has both addresses (link local and routable)
wants to send a multicast or broadcast packet, that both of the others
will (or might) receive, which source address would it use, given your
proposed rule?

If both of the others want to reply to that packet, how is that accomplished
using your rule?

I think (hope) that you'll see that you can't require what you want.

So, we are stuck with mixed scope address packets, and mixed communications.
We could just require that a node not use its LL address if it has a global
one (that's close enough to what IPv6 does - LL addresses, aside from a few
uses that don't exist at all in v4, just aren't used at all if a node has
a global address - the global address is used instead) - but if that's
going to be the outcome, what use is having the LL address in the first
place?   It is just going to sit there doing nothing (this is unlike IPv6
where those other few defined uses demand that the LL address exist).

  | I don't. And I've seen comments from others who don't seem to agree
  | either.

Of course there are some who don't agree.   But see Erik's summary of
the last time this debate was held ...

http://www.merit.edu/mail.archives/zeroconf/2003-02/msg00000.html

This is the first issue in that message.

kre

---

From: Mika Liljeberg <[email-masked]>
Date: 08 Feb 2003 17:20:47 +0200

> a good idea, in the sense that it is impossible.

It is not impossible, it's the conservative approach. Making this
requirement simply restricts what v4LL addresses can be used for, namely
it restricts them for communicating with other v4LL compliant nodes.

The idea that v4LL nodes should be able to communicate with non-v4LL
nodes is simply faulty. The whole can of worms in crawling free in this
WG is due to that misconception.

> and have only old fashioned "routable" addresses.

If a link has routable addresses available, all nodes on that link
should be able to acquire one. Whether some of them will also have v4LL
addresses is irrelevant.

> will (or might) receive, which source address would it use, given your

A non-v4LL node would use a routable one. A v4LL node with a non-v4LL
application would do the same. A v4LL-aware application on a v4LL node
might broadcast using both.

> If both of the others want to reply to that packet, how is that accomplished

A node with only a v4LL address would not reply to broadcasts or
multicasts with a routable source address.

The applicability of v4LL addresses is limited. It should be expected
that not all services on a routed network will be available to nodes
that only have a v4LL address. The other path leads to the endless bog.

> I think (hope) that you'll see that you can't require what you want.

No, I don't. Sorry.

> This is the first issue in that message.

Review the responses. I counted as many as 6 immediate objections to
this point. That's pretty far from a consensus.

	MikaL

---

From: Keith Moore <[email-masked]>
Date: Sat, 8 Feb 2003 11:06:43 -0500

On 08 Feb 2003 15:47:37 +0200

> source and destionation addresses are required match, things become very

False, because not all applications involve only two parties.

Keith

---

From: Mika Liljeberg <[email-masked]>
Date: 08 Feb 2003 18:26:28 +0200

> False, because not all applications involve only two parties.

Give us a concrete example illustrating the problem and let's examine
it.

	MikaL

---

From: Keith Moore <[email-masked]>
Date: Sat, 8 Feb 2003 11:33:53 -0500

> Give us a concrete example illustrating the problem and let's examine

I've already done that on multiple occasions. Maybe I'll put something on a
web page in a few days so that I won't have to try to explain this anew
everytime somebody makes a blanket assertion like this one.

---

From: Mika Liljeberg <[email-masked]>
Date: 08 Feb 2003 18:49:48 +0200

> everytime somebody makes a blanket assertion like this one.  

I'm not asking for a treatise on the subject. Just a concrete case study
of an application that fails with the scoping rules I propose:

- for unicast, source and destination scopes must match
- for multicast & broadcast, a routable source address must be used
unless the application (sender) explicitly requests a v4LL source
address

Note: it could be argued that v4LL source addresses should not be used
at all with multicast/broadcast destinations, as there are potential
failure modes with non-v4LL compliant nodes. Depends on how conservative
one wants to be.

If you've already done such a case study, perhaps you could post a
pointer to the archive?

	MikaL

---

From: Ted Lemon <[email-masked]>
Date: Sat, 8 Feb 2003 14:40:23 -0600

> I don't. And I've seen comments from others who don't seem to agree

Right, I mistakenly interpreted some things that had been said here as 
indicating that a node would not have a v4ll address if it had another 
address, but at least according to Stuart I was mistaken.   And I 
certainly don't participate in the supposed consensus that if a host 
has a non-v4ll address it can't have a v4ll address.

---

From: Keith Moore <[email-masked]>
Date: Sat, 8 Feb 2003 16:58:31 -0500

> has a non-v4ll address it can't have a v4ll address.

A node should definitely not automatically use a v4LL address if it has a
routable address.  There is no good reason for it to do so.  Having it do so
only increases the complexity of the network and applications and with it, the
liklihood of failure.

---

From: Robert Elz <[email-masked]>
Date: Sun, 09 Feb 2003 16:31:55 +0700

Date:        Sat, 8 Feb 2003 14:40:23 -0600
    From:        Ted Lemon <[email-masked]>
    Message-ID:  <[email-masked]>

  | And I 
  | certainly don't participate in the supposed consensus that if a host 
  | has a non-v4ll address it can't have a v4ll address.

It has become clear that we need to choose our words very carefully here.

No-one (that I recall anyway) is saying that any node "cannot" have a
v4ll address.

The issue he is that this is zeroconf - in the absence of any configuration
a node configures itself a v4LL address.

When there is configuration, the node does what the configuration tells it
to do.

That can be (in some cases) just to configure itself a v4LL address.

In other cases it may be to configure itself a routable address, and not
to configure a v4LL address.

In other cases, it may be to configure both.

In still other cases, of course, it could be to configure neither.

Thus far, I'd hope, I have said nothing that anyone will object to.
That is, if there's anyone out there who is proposing to require that
my laptop MUST have some particular kind of address, no matter how I
manually configure it, they're in some dreamland.

What remains is merely to decide what kinds of configuration information
(assuming some exists) should cause a node to adopt one of the strategies
different from LL only.

Fairly clearly, I hope, manual configuration - that is, the owner/operator
of the node explicitly configuring it in some way is the ultimate winner
in all debates, and whatever is configured (even if it is totally stupid,
like configuring 127.1.2.3/17 on an ethernet) is what wins.

Where we have some disagreements, it seems, is with what should be done in
cases where there is some configuration, not done manually by the owner of
the system.   Here the common (and obvious) example is DHCP - but as has
been mentioned before, some nodes use RARP, or MOP (or whatever that is),
and there's also PPP for serial links that can supply addresses as well.

Here, most (though certainly not unanimous) opinion on the list has been
that a node that receives an address via one of those other configuration
mechanisms should use that address, and not configure a LL address (by
default - it can still be instructed to).

The reasoning is pretty simple - having one address makes lots of things
simpler than having two, and having one that is able to reach more nodes
is better than one which reaches less (access controls can still limit
access any way desired of course).   A routable address can communicate
with everything a LL address can communicate with, and more, so having the
LL address in addition to the routable one is extra complexity for no gain.

If you disagree with this, ask yourself if you really intend that a node
that implements LL addressing, is required (absent human config to the
contrary of course) to configure itself a LL address on a PPP link, after
PPP has assigned it an address to use there (as I understand PPP, which
isn't much, I suspect it isn't possible before, as the address, I think,
gets assigned during the link setup process).

kre

---

From: Mika Liljeberg <[email-masked]>
Date: 09 Feb 2003 12:44:12 +0200

On Sun, 2003-02-09 at 11:31, Robert Elz wrote:

[...]
> and there's also PPP for serial links that can supply addresses as well.

I agree with your summation this far.

> with everything a LL address can communicate with,

The reasoning here is perhaps too simple. It holds only if ALL nodes on
the link will have a routable address. I don't think this is necessarily
true.

In general, a routable address can only be used to communicate safely
with other routable addresses.

Note well: the only reliable way to recognize a v4LL compliant
destination is from the fact that it has a v4LL address. In all other
cases, it is unsafe to use a v4LL source address, because the
destination might be non-v4LL compliant and could send its response
packets to a router instead.

>  and more, so having the

What of implementation complexity? From an implementation perspective
having all these special conditions on when v4LL addresses can be
configured only adds to complexity.

I'm not being the "lazy engineer" here. A good engineer works very very
hard to arrive at a simple design. Implementation complexity is usually
a sign of bad design.

> gets assigned during the link setup process).

No, of course not. Zeroconf is only applicable to links that use ARP.
PPP doesn't. With PPP you'd use either routable or private addresses,
negotiated as part of the IPCP handshake.

	MikaL

---

From: Robert Elz <[email-masked]>
Date: Sun, 09 Feb 2003 18:26:15 +0700

Date:        09 Feb 2003 12:44:12 +0200
    From:        Mika Liljeberg <[email-masked]>
    Message-ID:  <1044787452.11519.93.camel@devil>

  | The reasoning here is perhaps too simple. It holds only if ALL nodes on
  | the link will have a routable address.

No, it doesn't.

  | I don't think this is necessarily true.

I agree with that.

  | In general, a routable address can only be used to communicate safely
  | with other routable addresses.

No, a routable address can communicate perfectly well with a LL address.

  | Note well: the only reliable way to recognize a v4LL compliant
  | destination is from the fact that it has a v4LL address.

That isn't a reliable way.   I can easily manually configure an address
that looks like a LL address on any ancient node, and what's more, will
do exactly that if it turns out to be the easy way to get that node
talking to other newer ones on some ad-hoc net.

  | In all other
  | cases, it is unsafe to use a v4LL source address, because the
  | destination might be non-v4LL compliant and could send its response
  | packets to a router instead.

Yes, that might happen.   But so what?   If the router is "doing the
right thing" all this will mean is that the response will get dropped
at the router (though there have been suggestions in this group that to
avoid that, routers be permitted to forward such packets back onto the
link from which they originated - I see no real problem with that).

But even if the router knows nothing about LL addresses either, and
hasn't even been configured to filter them, all it can end up doing
is forwarding the packet aimlessly toward the network core, where it
should die for lack of a route.   This is no different to what would
happen without LL addresses, if one node on a net is misconfigured.

There's no real harm from this - communication doesn't work, but nor
would it using your proposal.  On the other hand, allowing communication
between LL and routable addresses allows communication to succeed in many
cases where your proposal prevents it.

  | What of implementation complexity?

Every time an address is to be used, the node needs to choose one.
What's more, applications that care about addresses also get to
see more than one, and also need to choose which they use.   A DNS
server would typically have to listen on 2 sockets (and yes, the code
to do that is there already but it still means extra overhead).

  | From an implementation perspective
  | having all these special conditions on when v4LL addresses can be
  | configured only adds to complexity.

Unless you're demanding that every node MUST always configure a LL
address, even if I, the owner of the node, want to explicitly
configure it not to, there already needs to be a mechanism to
disable it.

"All these special conditions" (for which there really aren't many
in that "all") amount to no more than setting the switch which really
already has to be there.

  | No, of course not. Zeroconf is only applicable to links that use ARP.

No it isn't.   The current document only defines how to do it on links
that use ARP, but do see section 1.2 ...

   Link-layer network technologies that do not support ARP may be able
   to use other techniques for determining whether a particular IP
   address is currently in use. However, the application of claim-and-
   defend mechanisms to such networks is left to a future document.

PPP could trivially define an option to negotiate LL addresses (it does
already for IPv6 I believe, though as I said, PPP is outside my area
of expertise).   Once LL addresses exist, I see no reason the PPP people
would not go ahead and define the mechanism.   After all, that allows
ad-hoc PPP links to be established between two nodes, with no configuration
required at either end.

kre

---

From: Mika Liljeberg <[email-masked]>
Date: 09 Feb 2003 14:28:02 +0200

> No, a routable address can communicate perfectly well with a LL address.

Only if both nodes are v4LL compliant. It is not safe to talk to a
non-v4LL node using a v4LL address.

I'm expecting networks to have a lot of non-v4LL compliant nodes.

> talking to other newer ones on some ad-hoc net.

Ahh, manual configuration. You can always shoot yourself in the foot,
no?

The draft already says that v4LL addresses should not be configured
manually.

> link from which they originated - I see no real problem with that).

So you say all routers should be v4LL compliant?

Yeah, you can blackhole it manually. Despite best efforts to the
contrary even private addresses still leak out all the time.

Again: I'm expecting a *lot* of non-v4LL comliant nodes out there.

> happen without LL addresses, if one node on a net is misconfigured.

I'd wager you would *not* want to be the poor bastard who is at the
receiving end of that black hole.

> Every time an address is to be used, the node needs to choose one.

We already do that. Not a big deal.

> see more than one, and also need to choose which they use.

Where do these addresses come from? They always come from:

a) manual configuration

You can always shoot yourself in the foot.

b) a name resolution process. 

Normal (stupid) applications usually take the first address they get
from the resolver. It is a simple matter to implement name resolver APIs
on v4LL compliant nodes in such a way that they always return routable
addresses first.

c) a communicating peer as part of the application layer protocol

Ask yourself where the peer got the address. Repeat until you get either
a) or b) as the answer.

>    A DNS

Any v4LL compliant node with a routable address will use that to
communicate with DNS.

So, you need to do this only if you want to support DNS for nodes that
only have a v4LL address.

> in that "all") amount to no more than setting the switch which really

I'm not opposed to manual configuration. I was talking about the
implementation dependencies to other automated mechanisms that have been
proposed.

I can see that network admins might want to disable the use of v4LL
completely on their networks, but I submit that network management
software is beyond the scope of this WG.

> that use ARP, but do see section 1.2 ...

Right, I had a careless turn of phrase there. What I meant is that this
specification is limited to links that use ARP.

To address your earlier argument: I am not saying that "every
v4LL-compliant node MUST have a v4LL address". I am saying:
- A node MUST be allowed to have a v4LL together with a routable address
on the same interface
- A node MUST NOT use the v4LL address when communicating with a
non-v4LL compliant node
- PLEASE don't create unnecessary implementation dependencies between
v4LL and other address configuration mechanisms

I hope I made my position clear on that. :)

	MikaL

---

From: Robert Elz <[email-masked]>
Date: Sun, 09 Feb 2003 20:41:38 +0700

Date:        09 Feb 2003 14:28:02 +0200
    From:        Mika Liljeberg <[email-masked]>
    Message-ID:  <1044793681.21186.107.camel@devil>

  | Only if both nodes are v4LL compliant. It is not safe to talk to a
  | non-v4LL node using a v4LL address.

I believe it is safe enough.

  | I'm expecting networks to have a lot of non-v4LL compliant nodes.

Yes, agreed.

  | Ahh, manual configuration. You can always shoot yourself in the foot,
  | no?

Yes, you can, but you can also make things work that way where they would
have failed other ways.

But where this came up was that you said that noticing LL addresses was
a reliable way to detect that the destination understands what LL means.
I was just pointing out that that is not so - it is not reliable.

  | The draft already says that v4LL addresses should not be configured
  | manually.

And given a choice between failing to communicate, and doing what a
draft or RFC (that the user probably hasn't ever heard of) says, which
do you expect to happen?

  | So you say all routers should be v4LL compliant?

No, that isn't what I said at all.

  | Yeah, you can blackhole it manually. Despite best efforts to the
  | contrary even private addresses still leak out all the time.

Of course.   Part of the issue there naturally is that routers cannot
block 1918 addresses by default, whereas they can block LL's, so at
least new router (software) will be able to assist.   But of course
that will take a long time to get deployed.

  | Again: I'm expecting a *lot* of non-v4LL comliant nodes out there.

yes.

  | I'd wager you would *not* want to be the poor bastard who is at the
  | receiving end of that black hole.

The receiving end of the black hole is a LL address, remember.   Which
poor bastard would that actually be ?

People send packets to bogus addresses all the time - they don't get
answered, for the vast majority of these cases, the node sends a few
packets, spaced by varying amounts, and then gives up.

This one just happens to be an easy one to deal with, as the dest addr
is one that manifestly cannot reach anyone useful, once it has passed
through a router.   So even if the site in question hasn't blackholed it,
their ISP can (and if there's enough of such bogus traffic, almost
certainly will - it avoids traffic on their links).  If there's not
enough of it for them to notice (from all their customers combined),
why would we care?

  | So, you need to do this only if you want to support DNS for nodes that
  | only have a v4LL address.

No, I meant running a DNS server on a node which would normally have
just a routable address, but which you want to demand have a LL address
as well so it can communicate with LL-only nodes.   NB: it is not the
DNS server application that wants to communicate with the LL nodes, as
you say, they're unlikely to be using DNS anyway (though they might, but
that's not important here).   Some other applocation on the node wants
to communicate with LL only nodes.   So, the node has to have 2 addresses
(your theory) - which now the DNS server needs to deal with, for no
reason worth knowing.   This is just an example of the extra complexity.

  | I'm not opposed to manual configuration. I was talking about the
  | implementation dependencies to other automated mechanisms that have been
  | proposed.

The other mechanism proposed is that when a node configures some other
address, it turns off LL by default.   That means, as part of the addr
config mechanism you set the "no LL" switch for the interface.

This really sounds difficult...

  | I can see that network admins might want to disable the use of v4LL
  | completely on their networks, but I submit that network management
  | software is beyond the scope of this WG.

Network management software???   What has that to do with anything?
The issue (an issue) is whether or not a node should configure a LL address,
having it configured, and then disabled with some random other software is
not at all appropriate.   Not configured, means not configured (at all).

  | Right, I had a careless turn of phrase there. What I meant is that this
  | specification is limited to links that use ARP.

no, not even that.   Most of what is there applies to LL addresses in
general.   The only part of it that is specific to ARP networks is that
part that describes how to probe and defend addresses.

  | To address your earlier argument: I am not saying that "every
  | v4LL-compliant node MUST have a v4LL address". I am saying:
  | - A node MUST be allowed to have a v4LL together with a routable address
  | on the same interface

I don't have a problem with that, if a node wants to have both, and
is configured to have both, that's fine.

  | - A node MUST NOT use the v4LL address when communicating with a
  | non-v4LL compliant node

I disagree with that.

  | - PLEASE don't create unnecessary implementation dependencies between
  | v4LL and other address configuration mechanisms

Address configuration mechanisms (of whatever kind) assuming there is
more than one of them (and there clearly is) have all kinds of
dependencies between them.   That's unavoidable - they're all configuring
essentially the same thing, so they have to interact.

kre

---

From: Mika Liljeberg <[email-masked]>
Date: 09 Feb 2003 17:12:59 +0200

> I believe it is safe enough.

Are you saying that we should relax the admonishment that v4LL addresses
should not be configured manually?

> Yes, you can, but you can also make things work that way where they would

Meaning, you can allow nodes that only have a v4LL address to converse
with non-v4LL compliant nodes that have a manually configured v4LL
address.

That is clearly a fringe case.

The failure mode here is very simple to understand. That is not true of
the alternative.

> draft or RFC (that the user probably hasn't ever heard of) says, which

I expect the implementations to do what the RFC says. Why else do we
write these things?

As for users, we can't protect them from stupidity.

What we can do, is make sure v4LL nodes in routed networks will try to
get a routable address and use that whenever they connect to another
routable address. That way your special case above won't even come up.

> that will take a long time to get deployed.

Exactly.

> poor bastard would that actually be ?

Does it matter? If the packets escape the link they must end up
somewhere and use up someone's bandwith, as will the ICMP errors coming
back.

> packets, spaced by varying amounts, and then gives up.

This usually only happens when someone mistypes an address. What you're
proposing is of a different magnitude completely.

Frankly, I think this is a far more serious problem than providing no
connectivity between v4LL nodes that have no routable address and
non-v4LL compliant nodes.

If you disagree, then we have a difference of opinion that cannot be
resolved on technical grounds.

> as well so it can communicate with LL-only nodes.

A DNS server doesn't need an LL address (although it could have one).

v4LL-compliant nodes should acquire a routable address when they are
part of a routed network. If they don't, they have no business talking
to DNS anyway, or trying to connect to any addresses that they would get
from DNS, which are more than likely to be unreachable (behind a
router).

>    NB: it is not the

Actually, the DNS server only needs to deal with routable addresses. You
*don't* want to put LL addresses into DNS.

v4LL addresses will be resolved with something like Rendezvous or
Link-local Multicast Name Resolution, anyway. The DNS server has no part
in that.

> This really sounds difficult...

To do it gracefully requires that the node support two addresses per
interface, even if one of the addresses is in deprecated state.

This is how I would implement it if I had to, DHCP option or not, since
our implementation already supports multiple addresses per interface.

However, I don't subscribe to the "disable v4LL" idea in the first
place.

> Network management software???   What has that to do with anything?

That's how network admins manage the nodes on their networks. It can be
used to twiddle settings like "enable/disable v4LL". Maybe I'm using the
wrong term. Does "remote configuration software" sound right?

> part that describes how to probe and defend addresses.

Now it's my turn to refer you back to section 1.2. First paragraph.

> is configured to have both, that's fine.

Excellent.

>   | non-v4LL compliant node

Hrrm.

> essentially the same thing, so they have to interact.

No they don't. Given a proper API, they will just add and remove
addresses from network interfaces independent of each other.

	MikaL

---

From: Robert Elz <[email-masked]>
Date: Sun, 09 Feb 2003 22:52:08 +0700

Date:        09 Feb 2003 17:12:59 +0200
    From:        Mika Liljeberg <[email-masked]>
    Message-ID:  <1044803577.21383.233.camel@devil>

  | Are you saying that we should relax the admonishment that v4LL addresses
  | should not be configured manually?

Somewhere our contexts have totally diverged.

No.

What I meant was that I believe it is safe enough for a nodes with
LL addresses to communicate with nodes with routable addresses (and vice
versa of course).

Or if you like, I oppose LL19.

  | Meaning, you can allow nodes that only have a v4LL address to converse
  | with non-v4LL compliant nodes that have a manually configured v4LL
  | address.
  | 
  | That is clearly a fringe case.

Yes, but one to keep in mind.

  | The failure mode here is very simple to understand. That is not true of
  | the alternative.

When the alternative fails, it fails - as it would with LL19 imposed
upon everyone, the only variation is in the effect of the failure upon
what packets go where.   For most purposes the difference is irrelevant.

  | I expect the implementations to do what the RFC says. Why else do we
  | write these things?

I would expect that too.   But to achieve that the RFC has to be written
such that it allows people to do what they want to do - otherwise they
simply ignore it.

  | What we can do, is make sure v4LL nodes in routed networks will try to
  | get a routable address and use that whenever they connect to another
  | routable address. That way your special case above won't even come up.

Yes, whenever that happens there will be no problem.

But no-one is pretending that all nodes must be given a routable
address (and there are, or seem to be, some people who want to
have nodes which cannot ever have a routable address).

When nodes with no routable address appear on a net, and they will
for one reason or another, we need to deal with them - including when
they want to communicate with all the nodes without LL addresses
(old and new).

  | Does it matter? If the packets escape the link they must end up
  | somewhere and use up someone's bandwith, as will the ICMP errors coming
  | back.

And if that every gets to be enough of a problem to matter, someone will
block the packets.   So, does it matter?

  | If you disagree, then we have a difference of opinion that cannot be
  | resolved on technical grounds.

I disagree, and so ...

  | A DNS server doesn't need an LL address (although it could have one).

I agree that it doesn't need one.   But, using your model, if the node
upon which the DNS server is running (this being some generic *BSD or
Linux box most likely) happens to be running some other application which
needs to communicate with LL only nodes, what then?

I'd prefer to just leave he system with its routable address (and not
require anything more).

  | v4LL-compliant nodes should acquire a routable address when they are
  | part of a routed network. If they don't, they have no business talking
  | to DNS anyway, or trying to connect to any addresses that they would get
  | from DNS, which are more than likely to be unreachable (behind a
  | router).

You're still missing my point, which had nothing at all to do with
anyone (relevant) attempting to talk to the DNS, or using any results
they may gain that way.

Please do remember that a "DNS server" is not a computer with a network
attachment, it is a piece of software that runs on a computer that
might also be running all kinds of other software.

  | Actually, the DNS server only needs to deal with routable addresses. You
  | *don't* want to put LL addresses into DNS.

Something that we actually agree upon.   Violently I suspect.

  | That's how network admins manage the nodes on their networks. It can be
  | used to twiddle settings like "enable/disable v4LL". Maybe I'm using the
  | wrong term. Does "remote configuration software" sound right?

It doesn't matter what you call it, the problem is that it works only
after the node is configured and running on the (a) network in the
first place.   If LL addresses are to be disabled, that should happen
as part of the node's startup sequence, not sometime later.

Please do not assume that the node necessarily has any stable storage
in which you can stick a configuration setting to be used thereafter.

  | Now it's my turn to refer you back to section 1.2. First paragraph.

Which says ...

	The specifications in this document apply to any IEEE 802 media

Note it does not say "apply only to".   So, you keep on reading and
eventually get to the third paragraph, which clearly extends things to
other media as well - just as it should.

This doc could conceivably be divided into two - one specifying the
general properties of LL, and another specifying how to configure LL
on 802.x (and similar) networks.   But, it is common in these cases
to just put the most common case (which is clearly 802.x) in the base
spec, and then as other technologies require it, write the extra specs.

That's what happened for ARP, as just one example...

  | No they don't. Given a proper API, they will just add and remove
  | addresses from network interfaces independent of each other.

That doesn't work.   The obvious example is that when you manually
configure a node's address, you almost never want it (also) going and
doing DHCP to get a different one (either as a replacement, or in addition).

LL doesn't need to to be much different than that.   You (the user, or
the device manufacturer) pick which address assignment method to use (or
which sequence to try until one succeeds) and then just let them run.

kre

---

From: Mika Liljeberg <[email-masked]>
Date: 09 Feb 2003 19:09:41 +0200

> LL addresses to communicate with nodes with routable addresses (and vice

Such communication is only possible if you configure at least a
169.254/16 on-link route on those nodes manually (admittedly, the route
is enough).

> Or if you like, I oppose LL19.

So I gathered. :)

> Yes, but one to keep in mind.

I don't get that.

Could you give me some examples of these v4LL nodes that participate in
a routed network but are unable to get a routable address?

> what packets go where.   For most purposes the difference is irrelevant.

The alternative is multiple different failure modes, which makes them
more difficult to handle.

It also means the an application, on a node that only has a routable
address, can get a LL address from getpeername() or directly from the
peer as part of the application protocol. This leads to exactly those
application problems that Keith has been complaining about.

> such that it allows people to do what they want to do - otherwise they

I doubt there would be enough incentive to willfully break the RFC in
this case. The obvious solution (even for a user) is to get a routable
address to all nodes on the link.

> have nodes which cannot ever have a routable address).

As part of a routed network?

Let's take an example: a printer that configures a LLv4 address and uses
rendezvous to advertise itself. The printer does not have a routable
address. Four points:

1) The printer has no need to initiate connections to other nodes.
2) Nodes that support rendezvous can contact to the printer directly.
3) Nodes that do not support rendezvous cannot print directly to the
printer even if they have the manually configured 169.254/16 on-link
route, because they have no way of finding the IP address of the
printer.
4) the obvious solution to 3) is to put up a print server that serves
the non-rendezvous nodes.

> block the packets.   So, does it matter?

Someone will block the packets and, no doubt, complain virulently. :)

>   | resolved on technical grounds.

When in doubt, I tend to go for "DO NO HARM". That means that, when
there is potential for harm when v4LL only nodes are introduced into a
routed network, the harm should befall the v4LL nodes and not any
others.

> needs to communicate with LL only nodes, what then?

We already agreed that this is a fringe case. Two possible solutions,
both simple:

1) The v4LL node should acquire a routable address.
2) The host with the DNS server should be v4LL compliant and acquire a
v4LL address. (This has no implications to the DNS server application)

> I'd prefer to just leave he system with its routable address (and not

That doesn't make sense to me.

> might also be running all kinds of other software.

I know that. You argued that the DNS server *program* would have to
listen to both the routable and the v4LL address. I responded to that
argument. I argued that it only has to listen to the routable address,
for the reasons above.

So you're right. I probably missed your real point.

> Something that we actually agree upon.   Violently I suspect.

Excellent! :)

> as part of the node's startup sequence, not sometime later.

Ok, point taken.

> other media as well - just as it should.

If that's what it means, perhaps it should be said more clearly. That is
certainly not how I read it.

> That doesn't work.

It does work. We have an API like that.

>    The obvious example is that when you manually

That makes sense in normal configurations (and the user interface may
guide you to do this), but there is no need to enforce this within the
TCPIP stack or in the protocol specifications. You can legally have two
addresses on the same interface.

> which sequence to try until one succeeds) and then just let them run.

s/method/methods/ and I would agree.

	MikaL

---

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

Date:        09 Feb 2003 19:09:41 +0200
    From:        Mika Liljeberg <[email-masked]>
    Message-ID:  <1044810580.21186.302.camel@devil>

  | Such communication is only possible if you configure at least a
  | 169.254/16 on-link route on those nodes manually (admittedly, the route
  | is enough).

If the node is a legacy node, yes (that, or the router needs to understand
LL addresses, and return packets mistakenly sent to it back to the link
they came from).

Nodes that understand LL addressing, but don't happen to have an LL
address assigned to them shouldn't need this kind of configuration,
that should be implicit.

  | Could you give me some examples of these v4LL nodes that participate in
  | a routed network but are unable to get a routable address?

Huh?   If you take a node to my network (LL aware or not) and attempt
get get a routable address, you'll fail.   DHCP (which works there) is
set to only assign addresses to known systems.   The DHCP server there
won't send a 2563 reply (by default anyway - I'd typically only do that
to specific clients that I know about, not just to anything unknown)
and so you would get to assign yourself a LL address.

So, now your v4LL node would be on a routed network, and unable to get
a routable address.

Aside from the "bus stop" or "airport" case (purely ad-hoc networks)
this is all exactly how v4LL addresses actually work today.   The
nodes that implement them attempt to get a routable address, if that
succeeds they use it.  When it fails, they (attempt to) assign a
LL address, and they use that.   Have you never seen that happen?

  | It also means the an application, on a node that only has a routable
  | address, can get a LL address from getpeername() or directly from the
  | peer as part of the application protocol.

Yes.

  | This leads to exactly those
  | application problems that Keith has been complaining about.

Yes.  I know that.    But I don't believe that "never allow LL and
routable addresses to communicate" fixes that.   Even if it did, it would
be too high a price to pay.

"Prefer routable addresses" (which is something I certainly agree with)
deals with most of the issue (most cases).

The prohibition wouldn't fix the issue, as you still have to deal with
nodes that have both LL and routable addresses (which your proposal would
require to exist) which will then still expose both addresses to
applications.

  | I doubt there would be enough incentive to willfully break the RFC in
  | this case.

This of course is all guesswork on both sides, so I will say no more
but ask you to look at other RFCs that have prohibited things that
users want to do (even when another RFC provides a mechanism).   Consider
the prohibition on characters outside 0..0x7F in e-mail (and that MIME
provides an alternative) and count the users that ignore all of that...

  | The obvious solution (even for a user) is to get a routable
  | address to all nodes on the link.

If you have one node with only a LL address, then perhaps.   But if
you have many nodes with LL addresses on some ad-hoc network, and
one legacy system that doesn't understand LL??

  | 1) The printer has no need to initiate connections to other nodes.

How does it report when it needs its paper tray or toner refilled ?

  | 2) Nodes that support rendezvous can contact to the printer directly.

Sure.

  | 3) Nodes that do not support rendezvous cannot print directly to the
  | printer even if they have the manually configured 169.254/16 on-link
  | route, because they have no way of finding the IP address of the
  | printer.

"Hey Mika, what's the IP address of that printer you're using?"

  | 4) the obvious solution to 3) is to put up a print server that serves
  | the non-rendezvous nodes.

On a managed network, perhaps.   For three friends and one of those
portable network printers in an airport?   Really?

  | When in doubt, I tend to go for "DO NO HARM". That means that, when
  | there is potential for harm when v4LL only nodes are introduced into a
  | routed network, the harm should befall the v4LL nodes and not any
  | others.

Absolute rules rarely work (they just turn into dogma).   What's needed
is to evaluate the potential harm, weigh the costs of ignoring it,
implementing a workaround, or submitting and saying "no".

  | 2) The host with the DNS server should be v4LL compliant and acquire a
  | v4LL address. (This has no implications to the DNS server application)

Where I first used this as an example is precisely because your
parenthetical remark is incorrect.

  | > I'd prefer to just leave he system with its routable address (and not
  | > require anything more).
  | That doesn't make sense to me.

I meant, after (s/he/the/) that if a system has a routable address, it
needs nothing more, if it is LL aware, or configured, it can communicate
with LL addresses - it doesn't need to have its own LL address, and is
simpler not to.

  | I know that. You argued that the DNS server *program* would have to
  | listen to both the routable and the v4LL address. I responded to that
  | argument. I argued that it only has to listen to the routable address,
  | for the reasons above.

Oh, now I see what you were saying, but it really doesn't work that way.
To make that happen (even assuming that it was a desirable outcome) would
require even more complexity than is now required (the server would have
to look at each individual address, and determine whether or not that one
was one that might be used, or probably wouldn't ever be).

  | If that's what it means, perhaps it should be said more clearly. That is
  | certainly not how I read it.

OK, then this should be a new "Editorial" issue (the first such
issue on the list...)    Anytime that different people reading the
text come (reasonably) to different conclusions, implies that the
text is not clear enough.

Once the edtorial issue is cleared up (one way or the other) then
there might be some technical issue as to whether what it says is
correct, but it is pointless debating that when everyone believes
it is correct, because they read it their own way.

Do you want to send in an issue for that one, or should I?

  | That makes sense in normal configurations (and the user interface may
  | guide you to do this), but there is no need to enforce this within the
  | TCPIP stack or in the protocol specifications. You can legally have two
  | addresses on the same interface.

Yes, I know, that's fine.   The question is more whether you actually
want to, given no particularly good reason to do so.

  | > LL doesn't need to to be much different than that.   You (the user, or
  | > the device manufacturer) pick which address assignment method to use (or
  | > which sequence to try until one succeeds) and then just let them run.
  | 
  | s/method/methods/ and I would agree.

Oh, good, because I don't mind that change.

That is, I don't object to a node being able to be configured explicitly
to have multiple addresses (including where one, or more, of them are
link local addresses), if that's what someone wants to do with it.

And, provided that I have a way to explicitly configure it to have only
one address, and that having only one won't prevent me from communicating
with anyone else (that the particular address, or address type, I choose
is able to reach).

All that's left is to decide what the default should be when there is no
explicit configuration, and for that, I prefer the simplicity of just one
address, of the broadest possible scope available.

kre

---

From: Mika Liljeberg <[email-masked]>
Date: 11 Feb 2003 01:00:03 +0200

> So, now your v4LL node would be on a routed network, and unable to get

You would deny me a routable address but you would welcome me to your
servers?

Frankly, I would not expect to be able to access anything on your
network having only my v4LL address.

> require to exist) which will then still expose both addresses to

That could be mitigated by, e.g., having the host resolver return
routable addresses first.

> one legacy system that doesn't understand LL??

Well, there you have me. Admittedly, a nerdy user might be tempted to do
the dirty deed and configure a random LL address on the legacy node. On
the other hand, a nerdy user would not lug around a legacy node. :)

A non-technical user would just be out-of-luck, of course.

> How does it report when it needs its paper tray or toner refilled ?

Ok, so it talks to other rendezvous nodes.

> "Hey Mika, what's the IP address of that printer you're using?"

This would not be a common use case.

> portable network printers in an airport?   Really?

One of them with a legacy node and the knowledge to configure routes?
Again, not a very common use case.

> with LL addresses - it doesn't need to have its own LL address, and is

It's simple enough to have both types of addresses at the same time.

> was one that might be used, or probably wouldn't ever be).

Not really. The admin would just have to put the address into the config
file for bind to bind to (pun intented).

> Do you want to send in an issue for that one, or should I?

Be my guest.

> want to, given no particularly good reason to do so.

It's a simple clean design with no awkward transitions between v4LL and
routable modes or any interdependencies between address configuration
mechanisms. It is also closer to IPv6 semantics, which is a good thing
too.

> link local addresses), if that's what someone wants to do with it.

Good.

> with anyone else (that the particular address, or address type, I choose

I guess we still disagree on a few minor details here. :)

> address, of the broadest possible scope available.

That's fine, although the default configuration is really up to the
manufacturer. Depends on the type of the device.

	MikaL

---

From: Robert Elz <[email-masked]>
Date: Tue, 11 Feb 2003 16:03:22 +0700

Date:        11 Feb 2003 01:00:03 +0200
    From:        Mika Liljeberg <[email-masked]>
    Message-ID:  <1044918002.31088.163.camel@devil>

  | You would deny me a routable address but you would welcome me to your
  | servers?

Of course, or those of them that allow you to connect.  At least that's
an option that I want available (otherwise when I'd have to either give
you a routable address, and simultaneously install filters to stop you
getting off the net, or have a 1918 type net as secondary addresses on
the net and give you addresses on that one, and then arrange to make
sure communications work - which is just the same problem as making
connections to the LL address work.

  | > "Hey Mika, what's the IP address of that printer you're using?"
  | This would not be a common use case.

I disagree.   The prime motivator for LL addresses is for ad-hoc
networks (the doc even says so).   Those are networks that form when
a few people get together and make a net connecting whatever they
happen to have with them.   They're often (even usually) in close
proximity to each other, and easily able to exchange verbal information.

  | One of them with a legacy node and the knowledge to configure routes?
  | Again, not a very common use case.

Well, one of them might be me, I use NetBSD, which currently has no v4LL
support, and to the best of my knowledge, no-one is in any kind of
hurry to bother adding it...   (maybe it will never appear there).

How common it is isn't really relevant, it needs to be able to work for
when it is required.

kre

---

From: Mika Liljeberg <[email-masked]>
Date: 11 Feb 2003 21:45:51 +0200

> How common it is isn't really relevant, it needs to be able to work for

Perfect is the works enemy of good.

	MikaL

---

From: Keith Moore <[email-masked]>
Date: Wed, 12 Feb 2003 16:44:15 -0500

> I'm expecting networks to have a lot of non-v4LL compliant nodes.

fair enough, but the case of a host with only a v4LL address talking
to a host with a routable address should be rare - it should only
occur when the v4LL host has somehow failed to acquire an address from
DHCP.    and even in that case, there is a workaround by configuring the
other host to arp for v4ll addresses.  (of course, there should be no
v4LL-only hosts as these could not interoperate anyway)

and it is impossible to define v4LL behavior in such a way that it will
always interoperate with hosts that don't support it.

> The draft already says that v4LL addresses should not be configured

this should be interpreted as "v4LL addresses should not be assigned
manuallly".  there is no objection to a host permitting a user to
manually tell it to pick a v4LL address at random, and follow the
claim/defend protocol in this specification.  

> Ask yourself where the peer got the address. Repeat until you get
> either a) or b) as the answer.

nope.  you're completely wrong about that.  and even to the extent that
addresses do come from manual configuration or name resolution, (a) to
cope with a mixture of routable and LL addresses often requires a change
to existing applications and (b) there is no fix that allows
applications to work with a mixture of LL and routable addresses in all
cases.  in general the application doing the referral has no idea
whether the address will be usable to the party who eventually wants to
use it.

> - A node MUST be allowed to have a v4LL together with a routable
> address on the same interface

I don't think anyone's objecting to this, but it should not happen
absent manual configuration to enable it, or except as a transition
from LL to routable addresses.

> - A node MUST NOT use the v4LL address when communicating with a

there's no way for the source to know whether the destination is v4LL
compliant.  the safest thing is to always use a routable source address,
if you have one.

> v4LL and other address configuration mechanisms

the dependencies are unfortunate, but necessary.  trying to get rid of
those dependencies causes worse problems.

---

From: Mika Liljeberg <[email-masked]>
Date: 13 Feb 2003 00:55:12 +0200

On Wed, 2003-02-12 at 23:44, Keith Moore wrote:

> nope.  you're completely wrong about that.

The above is simple logic. It's not right or wrong, it just is.

However, you're right that the interesting place is at the node of
origin, where the application interacts with the APIs on that node.
That's what I was trying to get people to focus on.

>   and even to the extent that

I think we agree on most of that. Our disagreements relate to how to
best cope with that.

Applications are stupid. They don't go to great lengths to find out all
the addresses a node has. Typically, they just use an API to get one
address and then they use it. Most commonly, this API is the host
resolver API, although there are other possibilities as well.

Proper design of the APIs can minimize the chance that applications will
get hold of a LL address, even if the node has both LL and routable
addresses. It's not a perfect approach, but it very often works.

Naturally, this WG can't require OS vendors to redesign their APIs or
force application vendors to rewrite their applications. However, this
WG could give advice on those issues. Unfortunately, this WG apparently
has decided to focus on something it *can* affect direcly, choosing to
kludge the TCPIP stack in order to work around the problems. That is
understandable, however, let's be honest about it and not confuse it
with good overall design.

	MikaL

---

From: Keith Moore <[email-masked]>
Date: Wed, 12 Feb 2003 18:03:58 -0500

> The above is simple logic. It's not right or wrong, it just is.

no, it's a false assumption.  applying logic to false assumptions does
not say anything about the validity of the conclusion.

> origin, where the application interacts with the APIs on that node.

it's not even always the same application as the one in question.
and messing with those APIs in order to mislead applications breaks
another set of apps.  nor can you hope to solve the problem by changing
the APIs because the API implementation has no idea about what the needs
of the application are.

Keith

---

From: Mika Liljeberg <[email-masked]>
Date: 13 Feb 2003 01:18:28 +0200

> not say anything about the validity of the conclusion.

You forgot to explain what the false assumption is.

> it's not even always the same application as the one in question.

Say what? I'm afraid my school english gave up on that sentence.

> another set of apps.

I was talking about overall design, not "messing with APIs". Although
you confusing the two just goes to prove my point.

>   nor can you hope to solve the problem by changing

The problem cannot be solved. You said so yourself. It can be mitigated.
Good API design is one way to do that.

	MikaL