Subject: IPV4 Auto-configuration Draft

From: Ryan Troll <[email-masked]>
Date: Wed, 9 Dec 1998 22:52:28 -0500 (EST)

I recently posted a draft describing how an IPv4 host may choose an
address for itself in the absence of a DHCP server.  This document
describes how Microsoft and Apple do this functionality in their newer
operating systems, and is intended to be a guide for anybody else that
will be doing the same sort of thing.  For example, network appliance
vendors (Voice over IP Telephones, Network based Cameras, etc.)  They
may want to select an address in the same way, and in the same range,
as these operating systems, so that they may inter-operate in any and
all network environments.

The draft has been commented on by people inside and outside of this
WG.  The last version has not had received further discussion, and I
would like to see it move forward.  However, I'm not 100% sure what
path this should take.

Proposing this as a BCP would be a great start.  I believe that
anybody wanting to learn about how others have done this, or are
looking for insight on how to do this, would read the BCP and learn
everything they want.  However, this would not guarantee that anybody
else wishing to do the same would follow these instructions.

My main concern about making this a BCP is that future developers that
decide to generate IPv4 addresses to be interoperable with OS's that
are already doing so will skip the DHCP autoconfig option handling
that is not 100% necessary, but a value added addition.  Making this a
proposed standard will make sure that everything is doing this the
same way, and allows site administrators to be sure that new stuff
won't be coming up that will cause problems.

For example:

Company foobar creates a network appliance that is a camera which is
designed to allocate and transmit images via the MBONE.  Plug it in,
schedule a channel via the simple input device, point and shoot.  In
environments such as mine (multicast capable, all machines registered
with central service, DHCP servers only giving out addresses to
registered machines), having this machine auto-configure an IP address
will allow it to function.  However, had the device listened to the
DHCP option proposed earlier and _not_ configured an IP address, it
would not be functioning at this time.

So, what do you think?  BCP or PS?

Thanks,
-Ryan

---

From: Thomas Narten <[email-masked]>
Date: Mon, 14 Dec 1998 09:41:58 -0500 (EST)

Ryan Troll <[email-masked]> writes:

> will allow it to function.

I don't think I quite agree. If DHCP doesn't give a client an address,
the best the client can do is autoconfigure a link-local address. Such
an address is *only* useful for communication with other nodes on the
same link. It wouldn't be useful for sending stuff onto the MBONE for
example. Right?

Thomas

---

From: Ryan Troll <[email-masked]>
Date: Mon, 14 Dec 1998 10:56:06 -0500 (EST)

I wondered about this, and then it dawned on me that the
autoconfigured clients may be able to handle multicast traffic, due to 
the way multicast routing is done.

When it send a packet to a multicast channel, it goes out just like
everything else.  No big deal there.  Normally, a response won't get
back to it, but multicast doesn't respond.

The other half of the picture is traffic destined to the multicast
channel.  When a packet is sent to a channel, multicast routing takes
over, and it gets forwarded to all multicast routers that have
subscribed to it.  The packet will finally hit the multicast router
for the subnet the network appliance is on, at which time it will
determine which ports on it have sent an IGMP subscribe request for
that channel.  If the appliance did so, the router will send the
packet down the pipe to it.  On the local wire.

So, when using multicast traffic, the link-local addresses are able to
send and receive global traffic.  Which is a little annoying.

Please correct me if I'm wrong about how multicast traffic is routed.
I'd be relieved to hear it. :)

-Ryan

---

From: Thomas Narten <[email-masked]>
Date: Mon, 14 Dec 1998 13:08:47 -0500 (EST)

> send and receive global traffic.  Which is a little annoying.

I believe you are correct in your analysis. However, this only applies
to traffic sent *to* multicast addresses. Even many multicast apps use
a bit of unicasting as well (i.e., as part of a control channel), and
that won't work in general if a sender only has a link-local address.

Or, stated another way, TCP won't work. I suspect that most folks
would view that as making the system essentially unusable. :-)

Thomas

---

From: Mike Carney - SNT Internet Engineering <[email-masked]>
Date: Thu, 17 Dec 1998 14:25:35 -0500 (EST)

> would like to see it move forward.  However, I'm not 100% sure what

Hi Ryan,

	BCP. 

Here are a few comments about your drafts:

DHCP Option to Disable Stateless Auto-configuration in IPv4 clients:
====================================================================

Section 2.2: 

- You can't require use of the parameter request list. It's a MAY
   in RFC2131. The client needs to identify that it is autoconfig-aware
   in another manner - perhaps by including the auto-config option in
   its requests.

- Using DHCPOFFERs w/ a yiaddr of 0.0.0.0 violates RFC2131. Rather than
  overloading a DHCPOFFER, why not define a new message type?

Section 2.3:

- Last sentence contradicts text in 2.2.

I realize you're attempting to document Microsoft / Apple practice, but I
do believe we should specify the most correct method from a DHCP perspective
for folks in the future who choose to implement this functionality.

Automatically Choosing an IP address in a Ad-Hoc IPv4 Network
=============================================================

- Needs a pass through the spell checker. ;^)

Section 2, second paragraph. The listen interval should be tunable, not
implementation specific. 

Section 3.1, last paragraph. Two machines can get lock-stepped, and never
succeed. Clients should randomize their IP address selection algorithm.

Section 4:

- second paragraph. The wait interval should be tunable, with a specified
default.

- third paragraph. When the client recieves a DHCP reply, and
  drops the link address, won't the user lose data if they're talking to
   another link-local node?

Mike Carney
SNT Internet Engineering
Sun Microsystems, Inc.

---

From: "Ryan Troll" <[email-masked]>
Date: Thu, 17 Dec 1998 14:32:25 -0500 (EST)

Thanks for the comments.

> 	BCP.

This is for the Automatically Choosing an IP Address draft, right? :)

>    in another manner - perhaps by including the auto-config option in

That's what I meant, but you are correct, not what I said.  I'll make sure
this is addressed.

>   overloading a DHCPOFFER, why not define a new message type?

I'll have to defer to the rest of the list on this one.  I picked this
method, as it seemed the easiest thing to implement, and would not have any
interraction problems with existing implementations.  Clients that received
this would have explicitly said they could handle it earlier.

> - Last sentence contradicts text in 2.2.

Yes, and no.  Now that I look at it, I think it should say:

	If the site administrator allows auto-configuration on the originating
subnet, the DHCP server MUST either ignore the DHCPDISCOVER, or respond with
an offer for the address 0x00000000, and with the AutoConfigure option set
to "AutoConfigure".

There are two possible ways to tell the client to autoconfigure.  Ignoring
the DHCPDISCOVER is exactly what servers not supporting this option will do.
However, since the option was set, servers that understand it may choose to
answer and tell the client 'go ahead and autoconfigure'.  This would allow
clients to autoconfigure quickly, as opposed to waiting and determining that
no DHCP servers are going to answer.

> for folks in the future who choose to implement this functionality.

Actually, what I've documented is my proposal to stop what MS and Apple are
doing when site want to.  The second document is mostly documenting what
they are doing, with the addition of my option so that future folks that do
this will allow admins to disable it when necessary.

You are correct, we should specify the most correct method from a DHCP
perspective.  I'm open to suggestions for this.  If there is something
better we could do, or add to these documents, let me know.

Personally, I believe the correct method from a DHCP perspective is to use
DHCP. :)  However, that's not always possible.

> Automatically Choosing an IP address in a Ad-Hoc IPv4 Network

That doesn't work when you've accidentally added mispellings (IE:
automaticly) to your spell-checker dictionary. :)  [ You're not the first to
point this out. ]

>   drops the link address, won't the user lose data if they're talking to

Yes.  The draft says this should only be done if the host doesn't support
multiple IP addresses on the given interface.  Or if the client was told
(via the DHCP option) to not auto-configure an address.

---

From: Mike Carney - SNT Internet Engineering <[email-masked]>
Date: Thu, 17 Dec 1998 14:32:52 -0500 (EST)

> send and receive global traffic.  Which is a little annoying.

I don't think that's the case, at least for IPv4. The router/switch isn't
going to talk to the link-local address client, because it doesn't recognize
the client's source address as being on the local link - (remember,
it's using one of the magic Microsoft / Apple IP address ranges). Thus,
the client can't submit an IGMP request.

Mike Carney
SNT Internet Engineering
Sun Microsystems, Inc.

---

From: "Ryan Troll" <[email-masked]>
Date: Thu, 17 Dec 1998 15:22:38 -0500 (EST)

>
> What makes you think this? Any current DHCP server (not
> supporting this option)
> will of course respond to this DHCPDISCOVER with a valid
> DHCPOFFER. The servers
> will just ignore the unrecognized autoconfig option in the
> DISCOVER. In order
> for this feature to work, DHCP servers support this option would
> need to be
> deployed.

Ah.  This option is for sites that do not want to give the client any
address.  Their servers are not configured to hand out dynamics unless they
know the MAC address.  In these cases (of which my organization is one), the
DHCP server will not hand out any DHCPOFFER to the client.  The client will
send a few DHCPDISCOVERS, never get a response, and then auto-configure an
IP address.

In an environment where dynamics are handed out to any offer, you are
correct -- the server would ignore the option and just make a valid offer.

Earlier in the document, I tried to describe the exact environment that this
option will take effect in.  Given that description (which I've updated
based on other comments, so it's a little clearer), is the existing text
good enough, or do you believe I should be a little clearer on these points?
(And, if so, which points?)

> You misunderstand my point (or more likely, I didn't clearly
> state it). I was
> saying that you're documenting existing Microsoft/Apple practice in the
> autoconfig draft. I was saying that there are problems with their current
> practice which we could clarify in your draft such that other
> people coming
> along and doing implementations can avoid those problems. I think your
> "disable" draft is a fine idea.

Yes, and thank you.  There have been a couple of things that have come up
and been expanded on in the document, which MS and/or Apple have gone on to
consider.  If there are other topics, I'll gladly add them to the document,
or clear things up before publishing it.

As it stands, it no longer states what MS and Apple do now.  I've added the
use of the DHCP autoconfig option, which neither of them do.  My goal is to
have a document that somebody can implement, will allow them to interoperate
with those OS's, and behave well in existing environments.

MS and Apple have said in passing that this looks good as well.  I don't
believe anybody's committed 100% to implementing the DHCP AutoConfig option,
but I will say that nobody said they wouldn't. :)

Thanks,
-Ryan

---

From: Mike Carney - SNT Internet Engineering <[email-masked]>
Date: Thu, 17 Dec 1998 15:21:02 -0500 (EST)

> Thanks for the comments.

Sure.

> This is for the Automatically Choosing an IP Address draft, right? :)

Right. Sorry.  The "Disable" draft should be a STD, IMHO.

> this would have explicitly said they could handle it earlier.

Using a new message type is not going to interfere with existing
implementations. Not overloading DHCPOFFER is a worthwhile goal, IMHO. Look at
all of the trouble we got ourselves into by not differentiating between the
various DHCPREQUEST messages. ;^)

> an offer for the address 0x00000000, and with the AutoConfigure option set

Ok.

> the DHCPDISCOVER is exactly what servers not supporting this option will do.

What makes you think this? Any current DHCP server (not supporting this option)
will of course respond to this DHCPDISCOVER with a valid DHCPOFFER. The servers
will just ignore the unrecognized autoconfig option in the DISCOVER. In order
for this feature to work, DHCP servers support this option would need to be
deployed.

> no DHCP servers are going to answer.

Right.

> this will allow admins to disable it when necessary.

You misunderstand my point (or more likely, I didn't clearly state it). I was
saying that you're documenting existing Microsoft/Apple practice in the
autoconfig draft. I was saying that there are problems with their current
practice which we could clarify in your draft such that other people coming
along and doing implementations can avoid those problems. I think your
"disable" draft is a fine idea.

> (via the DHCP option) to not auto-configure an address.

You might want to add a sentence saying that the user will loose data, or
better yet, give the user the opportunity to save their data over the
autoconfig connection before transitioning to the DHCP address.

Mike Carney
SNT Internet Engineering
Sun Microsystems, Inc.

---

From: Peter Ford <[email-masked]>
Date: Thu, 17 Dec 1998 17:41:29 -0500 (EST)

We should probably get together a document that can be standardized so the
link local behaviour of IPv4 is well understood.  One idea was to start with
a draft (Ryan's draft serves this purpose), and then propose changes to RFC
1918 on private addressing.  That would be the place where we could add
documentation of the multicasing behaviour.  Alternatively, we can add to
Ryan's document.

We should ask for some guidance from our iesg friends ...

cheers, peter

-----Original Message-----
From: Ryan Troll [mailto:[email-masked]]
Sent: Thursday, December 17, 1998 12:24 PM
To: Multiple recipients of list
Subject: RE: IPV4 Auto-configuration Draft

Thanks,
-Ryan