Subject: Re: Time to Publish draft-ietf-zeroconf-ipv4-linklocal (fwd)

From: Erik Guttman <[email-masked]>
Date: Tue, 21 May 2002 06:13:22 -0700 (PDT)

Keith,

Thanks for your clear review.  I have suggestions which I think will
satisfy your concerns and give us a path forward.  I appreciate your
constructive effort to ensure this protocol meets the needs of a
diverse set of end-users.  The challenges we face here is to supply
something simple enough for consumer appliances but safe enough to be
used on devices connected to any network.

------------------------------------------------------------------------------
Issue 1: This protocol will break distributed applications.

Each component of the distributed application also needs to be able to
send its address+port to other components.  This is a common and
reasonable thing to do - FTP has long allowed it for third-party
mediated transfers, SIP does it for call setup, Gnutella does it to
inform third parties about the locations of files, distributed
computing and cluster computing applications (Globus, Legion,
NetSolve, PVM, Condor, etc.) do it to allow components to spawn new
components on other hosts which communicate with other components that
are already part of the application.

Now here's the problem: If a component starts operation when the local
network is in a disconnected state, it will only learn of the
link-local address(es) of its host.  If it advertises those addresses
to other components, and the network subsequently transitions to a
connected state, those addresses are likely to propgate to components
for which they are not usable.  This applies to both "smart"
applications that explicitly select their source addresses, and "dumb"
applications that simply use whatever source address they are bound
to.

ERIK:  We should add an applications considerations section to
       address this.  It is an additional burden on the app.

- that in lists of interface addresses obtained from the OS that
link-local addresses either be hidden, or distinguished from other
addresses in a way that makes "smart" applications unlikely to choose
those local addresses as source addresses.

ERIK:  Such an interface which hides details of address changes would
       be much higher level than a socket interface - a kind of session
       API.  I doubt whether we could really complete such an effort in
       the IETF, though some such has been proposed in IPng.

------------------------------------------------------------------------------
Issue 2: Definition of "on the same link" is still flawed.

A set of hosts is considered to be "on the same link", if:

- when any host A from that set sends a packet to any other host B in
  that set, using unicast, multicast, or broadcast, the entire
  link-layer packet payload arrives unmodified, and

- a broadcast sent over that link by any host from that set of hosts
  can be received by every other host in that set

ERIK:  OK.  We can adopt this definition.

------------------------------------------------------------------------------
Issue 3: The address defense protocol appears to facilitate new kinds of attack

The security considerations section doesn't adequately address this
attack (it claims that ARP is insecure, which is true, but this
protocol facilitates a new kind of attack using ARP), and it doesn't
provide any means of ameliorating this threat.

ERIK:  Keith makes a good point and this should be added to the security
       considerations section.

------------------------------------------------------------------------------
Issue 4: The document (still) makes misleading claims about security

Section 2.8 is still misleading.  In part, it reads:

   communicate only with other local devices, and this allows them to
                                                  -------------------
   produce cost-effective devices by implementing a degree of security
   -------------------------------------------------------------------
   appropriate for that expected environment. 
   -----------------------------------------

The underlined portion can be read either as a (bogus) assumption
by the designers of such devices, or as a statement that use of
link-local addresses really does provide some security.

ERIK:  This text should be replaced with wording that security
       cannot be assumed on the link in all situations by the
       protocol designers.  Operators of course can make use of
       private links but that is distinct from what the protocol
       implementors and app implementors can assume.

       As ARP is insecure, too, we should mention that for security,
       (for authenticating the communicating endpoint) a higher 
       layer protocol is needed - ie. ipsec, tls, s/mime, etc.

------------------------------------------------------------------------------
Issue 5: Use of link-local addresses in DNS (and other higher-layer protocols)

it would be far better to simply say that link-local addresses SHOULD
NOT be used in DNS and/or that mechanisms specifying link-local
addresses in DNS are currently undefined and for further study.

ERIK:  The use of link-local addresses in the DNS is not currently
       specified by any document except some in discussion in the 
       DNSEXT working group.  What you are proposing is an additional
       for ZEROCONF name resolution protocols.

       I agree that we should call attention
       to the difficulty of keeping link-local address to name mapping
       in the DNS consistent with the actual state of the network.
       Given addr autoconf, address assignments will change dynamicly.
       If autoconf addresses in A, AAAA, etc. RRs can be obtained from
       the DNS, secure dynamic update would be required, right?  

------------------------------------------------------------------------------
Issue 6: Hosts that have multiple interfaces

It's hard to see how to fix this.  IP is designed with the assumption
that a host or service can be identified with sufficient precision
(for the purpose of establishing a connection to that host) simply by
specifying the host's or service's address and the port number of the
service.  And defending the addresses between separate links seems
undesirable.

ERIK:  Options 
       - Use on only 1 link at a time. 
       - Defend all addresses (that one has in one's cache?) on all 
         connected links.
       - Propose an interface indexed socket interface that is also
         exposed by service discovery.  That way, every time an address
         is selected, it will be explicitely destined for an unambiguous
         interface.
          discovery:  find a service, get its address and interface id.
          bind:       bind to an address and interface id.  One would
                      have to bind to each interface, or ANY.
          recvfrom:   would indicate the source addr and incoming inter-
                      face.
          sendto:     would indicate the dest addr and outgoing interface.
          connect:    would take dest addr and outgoing interface.
          gethostbyname() would indicate the interface for each addr in
                      the hostent.
         This work has already been done for the IPv6 API.  In fact, we
         could leverage this - by specifying that the behavior
         of these interfaces for IPv6 mapped IPv4 addresses in the LL 
         range is ---.
   
------------------------------------------------------------------------------
Recommendations:

- Provide a means for networks to disable use of link-local addresses
  for any host that is

  - capable of using routable addresses, and
  - not explicitly configured to use link-local addresses.  

ERIK:  I disagree with Keith here.  v4 LL autoconfiguration has been
       present in networks for four years.  The DHCP option to 'turn
       off' autoconfiguration has never been implemented and no vendor
       I know of has the intention of doing so.  As long as the other
       problems above (notably the multihomed autoconfiguration problem)
       is addressed, this extreme restriction *against current practice
       of the most popular client platforms* cannot be defended.

- Explicitly and clearly state in positive terms that all IP-capable
  devices, including those using only link-local addresses, MUST
  implement security adequate to protect the device's resources 
  those resources to which the device has access, and the network.

ERIK:  Yes - and specify that these must be done at a higher layer
       than the IP configuration interface, which is all we are
       defining in this document.

- Also, I wonder if this protocol be considered only applicable for
  use in ad hoc networks - in particular that it SHOULD NOT be
  considered a substitute for DHCP even for limited-function devices - 

ERIK:  This protocol is already being used in non-ad hoc networks.
       You are suggesting an applicablity statement which ignores
       the primary use of the protocol - namely unadministered
       local networking which works irrespective of which DHCP
       server comes up, and even if several do, without coordination.
       (!)
      
- Beyond the suggestions I made above, I'm not sure how to keep 
  link-local addresses from breaking distributed applications.  
  But I think the potential can be minimized by only using
  link-local addresses on ad hoc networks or on hosts that are
  explicitly configured to use them, and with some of the other
  suggestions I made.  

ERIK:  I agree an application considerations section should be added.
       There are issues which need to be presented.  None are insoluble.
       The local address may change.  Applications will need to detect
       this event and rebind or reconnect their sockets, etc.  The
       remote address may change.  Applications will need to perform
       service discovery in this case, to determine their peers new
       location.  Multihomed hosts need to present the interface in
       the networking API if more than one interface exposes link local
       addresses (probably).  All of these issues need to be discussed
       but none of them are showstoppers.

Best regards,

Erik

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 21 May 2002 08:13:44 -0700 (PDT)

>        address this.  It is an additional burden on the app.

I agree. There *are* issues here -- but they can at least be articulated.

>   - not explicitly configured to use link-local addresses.  

Note that the currently shipping IPv4 LL implementations don't work this
way -- LL capability is always available. After some initial concern from
customers (who were at first alarmed by the use of the 169.254/16 prefix),
there does not seem to be much demand for disabling use of IPv4 LL. So
while I do have some concerns about application behavior with LL
addresses, I don't think that providing a mechanism to disable it is
necessary. 

>   those resources to which the device has access, and the network.

Sure, but keep in mind that this is an unfunded mandate. 

>        server comes up, and even if several do, without coordination.

Yes, this isn't just about adhoc. If it were, then we wouldn't have needed
to do this work in the first place.

---

From: Keith Moore <[email-masked]>
Date: Tue, 21 May 2002 14:42:25 -0400

[am cc'ing the ADs on my reply]

> Date: Tue, 21 May 2002 06:13:22 -0700 (PDT)
> From: Erik Guttman <[email-masked]>
> To: [email-masked]
> Cc: Erik Guttman <[email-masked]>, [email-masked],
>         [email-masked], [email-masked]
> Subject: Re: Time to Publish draft-ietf-zeroconf-ipv4-linklocal  (fwd)
> 
> 
> Keith,
> 

And thanks for your thoughtful response.  Unfortunately there's
still a significant gap here.  I don't think the current protocol
yet meets the challenge you cite - in its current form it's neither 
sufficiently versatile for consumer appliances nor safe enough to
be used full-time on arbitrary devices.  And I still don't think 
those challenges can be met with mere wording changes to the current
document, or even with API changes - protocol changes are necessary.

I would like to make clear that I do share that goal - I just don't
think the current draft meets that goal.

Additional text would help. In general application developers need to be
made aware of the consequences of scoped addresses for their applications
(and IMHO we should really discourage their use except in corner cases
because there's no easy way for applications to fix the problems they cause)
This is a larger architectural issue than just this draft - one that
needs to be sorted out in the community, probably with IAB assistance.  
But it would help if this document at least mentioned these issues. 

However I do not think it's reasonable for linklocal to break existing 
applications if there's no way for the network to disable it.   What is 
being proposed is to update every Internet host to support this, amounting 
to a fundamental change in the architecture of the v4 Internet.  As such 
it needs to avoid breaking things as much as possible.

>        the IETF, though some such has been proposed in IPng.

I wasn't proposing an interface that hides details of address changes -
actually I consider such proposals completely infeasible.  By "smart"
applications I was merely referring to apps that choose which local 
address to bind to a socket.  These apps will break if they choose a
link local address where a routable address is needed, or if the link
local address is changed.

>        protocol designers.  

It would be better to say "cannot be assumed at all".
or merely "cannot be assumed".  Let's be as clear about this as possible.

>        Operators of course can make use of

How so?  I don't see this as proposing any additional work - I see it
as removing the impression that the current draft gives that DNS is somehow 
suitable for advertising link local addresses.  It's just not a good fit.

Yes, additional work is needed to make link local devices accessible by 
name, but we knew that anyway.

>        the DNS, secure dynamic update would be required, right?  

What would be the point?  If the device can be configured to do secure 
dynamic update, surely it could more easily be configured with a static 
IP address.

Leveraging the v6 interface work doesn't solve the problem. 

First, because essentially every single app in existence expects that
an IP address (without an interface identifier) is sufficiently precise
to be able to identify a destination host.  (the only exceptions that
come to mind are diagnostic apps like ping, traceroute, tcpdump).
Requiring apps to explicitly choose which network interface to use in 
order to reach a device that only has a link local address basically 
means that such devices can only reliably be reached from special-purpose 
apps - or that by 

Second, you are talking about changes to the v4 interface that will break 
apps.  v6 has always supported link local addresses, so apps written for 
v6 have to deal with that interface.  The same isn't true for v4 apps.

Third, some of the API changes you are proposing would have far reaching
effects, which are far beyond the ability of this group to consider.

IMHO this problem illustrates a fundamental limit to the applicability of 
link local addresses.  They are useful in ad hoc networks, or for initial 
configuration.  But they are not a good general-purpose IP address 
configuration mechanism, not even for simple devices, because those 
addresses are only accessible from the local link, and this makes 
unwarranted assumptions about how the customer has configured his network 
and hosts - or alternately, this imposes undesirable constraints on how 
the customer must configure his network and hosts in order to use such 
devices.  And even assuming the network is configured acceptably, devices 
that require link-local addresses may require special-purpose apps.

Perhaps I simply misunderstand the current draft, because it seems to
say that DHCP can effectively be used to "turn off" autoconfiguration:

From section A.1 (MacOS 8.x and 9.x)

   "Once a new lease is obtained, [from DHCP] Mac OS will not 
    allocate further connections using the autoconfigured IP address.

From section A.2 (Windows 98/98SE)

   "Once a new lease is obtained, [from DHCP] Windows 98/98SE will not 
   allocate further connections using the autoconfigured IP address."

And I read A.3 as saying that Windows 2000 and ME have the same behavior
except that the latter two have media sense.

In effect, this seems to provide a way for network administrators to
"turn off" use of link local addresses merely by supporting DHCP
(or by configuring their hosts with static addresses).  It's reasonable
to assume, then, that for the vast majority of operational networks,
link-local addresses are NOT currently in use, and therefore the
experience from existing implementations is NOT a useful indicator of 
the safety of using link-local addresses as proposed in this document. 

So I stand by my recommendation - we need a way for networks to disable 
this.  And we also need to clearly state that link local addresses are 
not a general-purpose address configuration mechanism.  Devices that 
implement only link-local addressing may not be usable in existing
networks.

> ERIK:  This protocol is already being used in non-ad hoc networks.

how so?  according to the document, with existing implementations,
if a DHCP server responds, the link local addresses stop working.
presumably link local addresses aren't used either if there is
a statically configured address.  how many non-ad hoc networks 
don't use either DHCP, or static configuration, and don't have any
Win98/ME/2000 or MacOS8/9 hosts?

I wrote a script to ping every possible link-local address in my 
local subnet, which consists of several hundred machines running 
various operating systems, including several that are claimed to 
support link-local addresses.  So far it's 25% through the address
space, and not a single machine has answered.

So I am unconvinced that the protocol is already being used in the
way you say it is.

>        server comes up, and even if several do, without coordination.

I'm suggesting an applicability statement that recognizes the inherent
limitations of the protocol.  Yes, it may turn out that the protocol 
isn't as universally applicable as was hoped, or that it may require
slightly more work and/or burden on hosts in order to make it generally
applicable. But if that's reality, we need to recognize it.

link-local addresses might sometimes be useful for maintenance/diagnostic
purposes in cases where there are unauthorized or incorrectly
configured DHCP servers.  I don't claim that they're not useful, I 
only claim that they're not useful as general-purpose IP addresses
(even for devices that you only want to be locally-accessible),
and that the current draft doesn't specify enough to keep them from 
causing harm to applications or from introducing another means of
denial-of-service attack. 
       
>        but none of them are showstoppers.

none of them are general solutions either.  at best they make link-local
addresses special-purpose tools that are only useful in specific, 
fairly limited circumstances.  there's nothing wrong with that, but
the current draft implies that link local addresses are useful for
simple devices that want net access.  IMHO that's overselling them.

Keith

---

From: Keith Moore <[email-masked]>
Date: Tue, 21 May 2002 21:58:07 -0400

> way -- LL capability is always available. 

then please explain why, if on a win2k box I try to ping a 169.254/16
address, the box doesn't arp for that IP address on the link, but
instead immediately sends a packet with the link-layer destination 
address set to the link-layer address of the default router?

and also why not one single host in my network (including win2k
and winxp hosts) responds to a ping for any address in 169.254/16?
 
> After some initial concern from
> there does not seem to be much demand for disabling use of IPv4 LL. 

maybe those customers aren't running distributed apps, or maybe 
the LL isn't enabled for some other reason (just as on my network)

> Sure, but keep in mind that this is an unfunded mandate. 

also keep in mind that secure hosts are cheaper than security holes.

Keith

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 21 May 2002 20:15:48 -0700 (PDT)

> address set to the link-layer address of the default router?

I didn't say that the interface always has a linklocal address. If you
read the Appendix of the draft, it describes how Windows and Mac OS 9.1
systems function. The point is that the behavior described in that
Appendix can't be turned off. 

> the LL isn't enabled for some other reason (just as on my network)

The LL address is indeed not enabled unless the DHCP server doesn't
respond, as described in the Appendix. 

> also keep in mind that secure hosts are cheaper than security holes.

Not actionable, unless it is described exactly *how* those hosts should be
secured on a small home network.

---

From: Keith Moore <[email-masked]>
Date: Wed, 22 May 2002 00:29:05 -0400

> Appendix can't be turned off.

as I read the Appendix, link local addressing *can* be turned off 
for existing implementations - merely by arranging for DHCP requests 
to be answered.  which means that in most of today's nontrivially 
sized networks link local addressing is turned off "by default".  

what am I missing?
 
> secured on a small home network.

there's no such thing as a one-size-fits-all security solution, because
different hosts have different kinds of resources to protect, different
threat models, different models for who can use them.  that doesn't 
mean that such hosts can't be secured with a reasonable amount of effort 
and expense, it just means that it's infeasible to describe exactly how 
it should be done for all cases.

Keith

---

From: Erik Guttman <[email-masked]>
Date: Wed, 22 May 2002 08:22:21 -0700 (PDT)

> sized networks link local addressing is turned off "by default".  

Though Windows and Mac OS (older versions) turned off link-local
configuration when DHCP service became available, there is no
requirement that they do so in the document.  Later versions of
Mac OS 9 and Mac OS X *do not* turn off link-local address
configuration in this case.

Erik

---

From: Erik Guttman <[email-masked]>
Date: Wed, 22 May 2002 09:06:46 -0700 (PDT)

Keith,

To follow up on non-security issues on this thread:
  ACTION suggests a remedy we can agree on.
  ISSUE suggest an action to take to come to agreement.

On Tue, 21 May 2002, Keith Moore wrote:
> > reasonable thing to do 
[snip]
> > for which they are not usable.  

If the component app starts onperation on a local network, how will
it register to a host on a non-local network?    

> it needs to avoid breaking things as much as possible.

Address reconfiguration events can occur when
 - a dhcp lease expires and is not renewed
 - a dhcp reconfigure option is received (assuming its supported)
 - ipv6 link-local autoconfiguration is used and there is a collision
 - ipv6 RA indicates a different prefix
 - ...

This problem is not unique to v4 LL autoconfiguration.  

> local address is changed.

So apps will have to be "really smart" and note the difference between
different address scopes, preferring the global range.  Its not pretty
but we already have magic addresses - like in the multicast range,
loopback, etc.

ACTION:  Admonish programmers not to cache link-local address values
         in their programs as their local address.  Rather, check  
         the *current* address.  Further, be prepared for address
         change errors from relevant (i/o, socket, etc) calls.

> name, but we knew that anyway.

From draft-ietf-zeroconf-ipv4-linklocal-05.txt:
2.9 Higher-Layer Protocol Considerations

   For example, DNS Resource Records containing link-local addresses 
   SHOULD NOT be sent to hosts ouside the link to which those link-
   local addresses apply. 

ACTION:  Change the example to either omit the DNS example or provide
         a different one.  Add text to indicate that storing link-local
         addresses in the DNS is not well understood or well advised.
 
> >          exposed by service discovery.  

Your points are well taken.  There are two workable strategies then.

1. Establish that v4LL works for one configured interface.  Clarify that
   if used for more than one it will break existing applications.  Or

2. Establish that if a multihomed host uses v4LL on more than one
   interface it MUST defend all addresses it detects on any v4 auto-
   configured interface on all its v4 autoconfigured interface.  Or

2 could limit the scalability of the v4LL protocol and expose other
links to ARP attacks.  So maybe we need to specifically limit the
applicability of the protocol to a single interface.

We should add that if, in the future, additional network APIs 
are developed to expose (or transparently manage) interface ids,
disambiguating addresses, it would be possible to support 
multiple link-local address autoconfigured interfaces on a host.

ISSUE:  Add an applicability statement - only single interfaces
        can be autoconfigured unless the host supports an interface
        indexed API, and expose the addresses for additional
        interfaces' addresses only through this new API.

> say that DHCP can effectively be used to "turn off" autoconfiguration:

Some existing implementations do turn off v4LL autoconfiguration, but
this is not required.

ISSUE: Clarify that this transition is not a requirement. (see below).

> implement only link-local addressing may not be usable in existing

It is clear you disagree with the authors and me on this point.

ISSUE:  We need ZEROCONF WG mailing list feedback on this point.  

Erik

---

From: Keith Moore <[email-masked]>
Date: Wed, 22 May 2002 12:08:17 -0400

> configuration in this case.

well, there's a couple of machines on our network running MacOS X, 
and they didn't respond to link local addresses either.

I can only conclude that this is a *very* late change, and that
therefore we don't have adequate experience to show that existing
practice doesn't break anything.

Keith

---

From: RJ Atkinson <[email-masked]>
Date: Wed, 22 May 2002 13:09:31 -0400

Keith,

	I disagree with a lot of what you are saying above and previously.
I'd also suggest that there is not rough consensus behind your positions
-- and that the IETF operates on rough consensus rather than unanimity.

	Please stop trying to unilaterally derail this.

Ran

---

From: John Schnizlein <[email-masked]>
Date: Wed, 22 May 2002 13:36:13 -0400

Yeah, Keith. Please get back in line with the rest of us who
have realized that this train has left the station. :-)

Once we all go quiet they can get on with the Host Requirements
for ZeroConfig, neither a superset nor a subset of Internet Host
Requirements, but suited to IP networks that are not interconnected.

Although I do not understand the motivation, beyond bringing features
from AppleTalk and Novell IPX/SPX into an IP world, stating concerns
about ZeroConfig is really unpopular.

Actually, I admire the way you have provided several detailed technical 
arguments that the current specification is not what it should be. I 
accept your claim that your intention is not sabotage, but clarification.

John

---

From: Keith Moore <[email-masked]>
Date: Wed, 22 May 2002 15:06:59 -0400

> it register to a host on a non-local network?    

The component app starts operation when the network is disconnected
for some reason.  when the network's external link comes back up,
the app fails to operate as it is intended.  LL addressing creates
a new failure mode that apps aren't prepared to deal with - having
bound to an LL address, the app isn't able to communicate with its
nonlocal peers even when it has network connectivity to them.

>  - a dhcp lease expires and is not renewed

This is not inherent in DHCP - if you run a DHCP server that doesn't
renew leases indefinitely (read: as long as possible) then you assume 
the risk that applications will break.  

The failure of DHCP to renew an active address lease should be considered
a failure of the network (or perhaps, a failure of the DHCP design,
though it's hard to see how it could have been avoided)  Or to put it 
another way: DHCP provided temporary leases on an IP address in order to 
garbage-collect addresses from crash-prone PCs.  The resulting ability 
of the DHCP protocol to deny a lease renewal is an (at the time) 
unintended/unexamined consequence of DHCP's design. It is NOT a general 
license for the network to change addresses at a whim, nor is it a 
justification for LL addresses to increase this kind of failure.

If a DHCP server fails to renew an active lease from a host that has
promptly defended that lease, this should be viewed as a network failure.

>  - a dhcp reconfigure option is received (assuming its supported)

see above.

>  - ipv6 RA indicates a different prefix 

First of all, IPv6 is irrelevant to applications written for IPv4.  

Second, though v6 LL addresses are clearly useful for corner cases
like ND/RD, and perhaps for specialized apps like network management, 
that doesn't mean that they're suitable as a normal means of access 
for hosts or applications.  linklocal-05 is making greater claims
of applicability for v4 LL addresses than I've seen made for v6 LL
addresses.

Third,  nobody has demonstrated a way to make applications in general
survive renumbering - and more generally, nobody has demonstrated 
technology that would allow renumbering of a network of significant
size to be anything less than a carefully-planned and managed event.
RA's ability to change prefixes needs to be viewed as an experimental 
and highly dubious feature of IPv6.  Just because it's a feature of 
IPv6 doesn't mean it's a good idea.  (some other features of IPv6 are 
already falling into disfavor - e.g. A6 records, bit fields in DNS, 
mapped IPv4 addresses.) 

> This problem is not unique to v4 LL autoconfiguration.  

Perhaps not, but there's a difference between imposing a burden
on v6 apps that are written to expect a v6 environment, and
imposing a burden on v4 apps that weren't written to expect
linklocal addresses.

> but we already have magic addresses - like in the multicast range,

Yes but this is a *new* set of magic addresses that existing apps don't
know how to deal with.  It's an incompatible change which would be
imposed on all hosts (and all apps that run on those hosts) without 
providing any way to disable it.

>          change errors from relevant (i/o, socket, etc) calls.

Even for newly written or updated apps, it takes *much* more than that 
to fix the problem.   Scoped addresses are a major headache for apps.
In general, expecting apps to know which addresses to use in which cases 
is really poor architecture -  apps are not in a position to know these
things.  

>    SHOULD NOT be sent to hosts ouside the link to which those link-

The problem with this statement is that it implies that it's reasonable
to use DNS at all - which is a big stretch.

>          addresses in the DNS is not well understood or well advised.

I recommend omitting the DNS example entirely.
The latter sentence sounds good.

>         interfaces' addresses only through this new API.

Rather than imposing restrictions on hosts,  I think it's better to 
simply document this as a fundamental limitation of LL addressing - you 
can't reliably expect LL addresses to be accessible from multihomed hosts
if more than one interface on that host is configured to support LL
addresses.   (unless the host acts as an L2 bridge - which is too ugly
to suggest)

But this just further illustates the need to be able to disable LL 
addressing (at least from a per-interface basis) - because there certainly 
will be multi-interface hosts set up for the sole purpose of mediating 
between devices that only support LL addressing and the rest of the net.

> ISSUE: Clarify that this transition is not a requirement. (see below).

Being able to disable LL needs to be a requirement, because of application 
compatability issues and because of problems with multihomed hosts.

> ISSUE:  We need ZEROCONF WG mailing list feedback on this point.  

I suspect the root problem is trying too hard to make LL addresses 
into a general-purpose mechanism for address configuration of simple 
hosts.  They're just not suitable for that - even presuming that the 
only other hosts that need to access the host in question are on the 
same link is a big stretch - and it threatens to impose the highly
undesirable requirement that all devices on some kinds of networks 
(say, home networks) be effectively on the same link in order to 
interoperate at all.

If you get past insisting that LL addresses be a general-purpose 
mechanism, and/or provide a simple way to for simple devices to 
obtain addresses that aren't necessarily LL (the only real issue 
here is claim/defend/discover protocol implementation overhead 
because LL doesn't provide security anyway) then you no longer have
a need to insist that all GP hosts must have LL addressing turned on
at all times.

*then* you can solve the problem of configuring ad hoc networks
and configuring simple devices in a way that doesn't prevent such 
devices from being used on some kinds of networks, and which also
minimizes breakage for existing apps and networks.

But the current proposal doesn't quite get there.

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 22 May 2002 15:25:55 -0400

> -- and that the IETF operates on rough consensus rather than unanimity.

I don't know if I can get rough consensus from this group or not.
But I do expect the group to meet the requirements of RFC 2026
for PS status - one of which says that "A Proposed Standard should 
have no known technical omissions with respect to the requirements 
placed upon it."  This isn't the case yet, not by a long shot.
Either the protocol needs some beefing up, or it needs to make
fewer claims of applicability, or both.  I've tried to make
constructive suggestions as to the minimum changes necessary to
solve these problems.

>         Please stop trying to unilaterally derail this.

I'm not trying to derail this; I'm trying to make it better and
to minimize the harm that it seems likely to cause in its current form.

Keith

---

From: "Philip Nye" <[email-masked]>
Date: Thu, 23 May 2002 11:51:23 +0100

Hello,

On Keith's concern about LL addresses breaking existing apps and at the risk
of repetition. Can somebody summarise for me the thinking behind the change
that recommends retaining LL addresses alongside a static or DHCP allocated
address, rather than the earlier behaviour of using LL addresses only when
nothing else is present?

Philip Nye

---

From: Erik Guttman <[email-masked]>
Date: Thu, 23 May 2002 04:22:51 -0700 (PDT)

On Thu, 23 May 2002, Philip Nye wrote:
> Can somebody summarise for me the thinking behind the change

Please see section 1.5 of 
http://www.ietf.org/internet-drafts/draft-ietf-zeroconf-ipv4-linklocal-05.txt

Erik