Subject: Status of Autoconfig Draft

From: Jared August <[email-masked]>
Date: Thu, 5 Oct 2000 16:24:27 -0400

Hello,

I've been asked to research AutoIP (draft-ietf-dhc-ipv4-autoconfig-05), and
was wondering what the status of the draft is. I notice that it has expired
- is there any ongoing work on it? I looked through the archive but didn't
notice anything. Any information would be greatly appreciated.

Thank you,
Jared

---

From: Dale Worley <[email-masked]>
Date: Fri, 6 Oct 2000 16:36:10 -0400

From: Jared August <[email-masked]>

   I've been asked to research AutoIP
   (draft-ietf-dhc-ipv4-autoconfig-05), and was wondering what the
   status of the draft is. I notice that it has expired - is there any
   ongoing work on it? I looked through the archive but didn't notice
   anything. Any information would be greatly appreciated.

AutoIP has never been widely accepted, I think, but people are
starting to use it.  E.g., the Universal Plug and Play protocol uses
it.  I expect usage to increase over time.  So it would probably be
useful to revise the Internet Draft for AutoIP, and hopefully get a
carefully-examined version of it turned into an RFC.

Dale
-- 
Dale R. WORLEY    Project Manager - UPnP        <[email-masked]>
Virata Corp.	  Applications Infrastructure   http://emweb.com

---

From: Erik Guttman <[email-masked]>
Date: Sat, 7 Oct 2000 05:13:11 +0200 (MET DST)

> carefully-examined version of it turned into an RFC.

The ZEROCONF WG has been chartered to work on this issue and produce
a standards track RFC on auto configuration for IPv4.  The following
is a quote from the ZEROCONF WG charter:

   The WG will also produce protocol specifications for Automatic Address 
   Configuration for IPv4 and a Multicast Address Allocation Protocol for
   IPv4 and IPv6. 

   Goals and Milestones:

   Oct 00   
        Submit internet-draft to be considered as an Informational RFC on 
        Requirements for Zero Configuration Networking.
   Dec 00
        
        Submit Automatic Address Configuration for IPv4 to be considered as a 
        Standards Track RFC.

The DHC WG decided in Adelaide (IETF 47) that auto configuration for
IPv4 was NOT within the scope of the WG.  From the IETF 47 minutes:

   Dynamic Configuration of IPv4 Link-local Addresses

   Automatically Choosing an IP Address in an Ad-Hoc IPv4 Network

   Stuart Cheshire, Ralph Droms

   ----------------------------

   The WG suggested that Cheshire submit his draft as an independent
   submission for review by zeroconf and dhc WGs.

So, the work items ahead of us are:

1) Publishing a draft-ietf-zeroconf-ipv4-autoconf-00.txt draft

2) Discontinuing the draft-dhc-ipv4-autoconf-05.txt draft

3) Getting all parties interested in seeing this standard moving
   forward participating in the ZEROCONF WG effort to specify this.

Erik Guttman
ZEROCONF WG Cochair

---

From: "Bernard Aboba" <[email-masked]>
Date: Sat, 7 Oct 2000 22:13:14 -0700

>Discontinuing the draft-dhc-ipv4-autoconf-05.txt draft

While I certainly agree with the idea of going ahead with
standardizing auto-configuration, I also believe that it is
important to document existing practice in an informational
RFC. Today there are tens of millions of hosts which 
behave something along the lines described in 
draft-dhc-ipv4-autoconf-05.txt and so it is valuable to
have this behavior documented somewhere. As a result, I 
do not believe that it makes sense to let
draft-dhc-ipv4-autoconf-05.txt expire completely. Rather,
the draft should focus solely on behavior that is already
implemented.

---

From: Erik Guttman <[email-masked]>
Date: Sun, 8 Oct 2000 14:51:45 +0200 (MET DST)

> the draft should focus solely on behavior that is already

Bernard,

I believe that the zeroconf document must also focus on
documenting the way that hosts are implemented.

We also want to consider issues which were not in the DHC
draft:  Multi-homing and assignment of both link-local and
global scope addresses to a single interface.

The document may define new protocol, but it has to be 
backwardly compatible with the installed base.  At least
IMO.

Perhaps, if we can't come to a quick concensus about 
the combined standard definition and legacy non-standard
description, we should have two parallel drafts (standards
track and informational, respectively) that proceed 
independently.  I think that's a bad idea, as some folks 
will get confused and implement the legacy version where 
we'd really like them to implement the standard one in the 
future.

Erik

---

From: Stuart Cheshire <[email-masked]>
Date: Sun, 08 Oct 2000 13:09:37 -0700

> I've been asked to research AutoIP

In fact that is exactly what I've been working on this week. Erik Guttman
has been reminding me for some time to get a new draft submitted now that it
is an official work item on the Zeroconf charter.

I finished incorporating the last round of suggestions this morning, and
posted the draft with its new official draft-ietf-zeroconf filename today.

For eager people who can't wait for it to appear in the Internet Drafts
directory, you can get it right away at:
<http://web.zeroconf.org/draft-ietf-zeroconf-ipv4-linklocal-00.txt>

I'm hoping that we can get agreement on this and wrap it up rapidly.
Both Mac OS and Microsoft Windows have implemented 169.254/16 link-local
addresses for several years now, and every day we continue to debate the
finer points of this document is taking time away from the far more
important matter of getting IPv6 deployed.

Please send any comments to the zeroconf mailing list or to me directly and
we can hopefully finish this off and put it behind us.

Stuart Cheshire <[email-masked]>

---

From: "Bernard Aboba" <[email-masked]>
Date: Sun, 8 Oct 2000 13:21:06 -0700

>We should have two parallel drafts (standards

The confusion arises from the fact that 
draft-dhc-ipv4-autoconf-05.txt today combines description
of existing practice along with recommendations on future
implementations. I would recommend that all portions
of the draft referring to non-implemented functionality
(such as the DHCP option for control of auto-config 
behavior) be removed, and that the draft state clearly that it
is not a standards track document. The new draft would
focus solely on documenting the functionality shipped
in MacOS and Windows. It is also ok if this draft were
to point out various weaknesses of the legacy approach. 

We could then move forward with a separate standards
track document.