Subject: RE: Things I want to see in DHCPv6

From: Bernie Volz <[email-masked]>
Date: Wed, 30 Aug 2000 16:26:52 -0400

Jim:

Regarding the RFC 2131 message types ... I assumed Ralph was not saying he
wanted to use the RFC 2131 packet formats, just the message type names (ie,
use the DHCPDISCOVER, DHCPOFFER, DHCPREQUEST, DHCPACK, ...) instead of the
DHCPv6 terminology (SOLICIT, ADVERTISE, REQUEST, REPLY, ...). We're all
familiar with the RFC2131 message names. And, agreed that we don't want to
have to look way down into a message (such as with DHCPv4 / BOOTP) to
determine the message type - the "op" or "msg-type" field should likely be
the first byte to follow the UDP header.

Thanks for the review of the address generation in IPv6. It is pretty much
as I remember it (good that I don't have to re-read volumes of IPv6
documents since I haven't looked at them in a while). The issue for me is
still the same ... the EUID is likely to change over time (because the
interface is replaced, because of privacy concerns, because of Duplicate
Address Detection, ...) and thus is not a "permanent" unique identifier for
a system. So, if I want a certain box to always get a certain address (at
least as long as the prefix is available) I'm in trouble. Perhaps a good
question is why I would care what the IPv6 address assigned to a system is
and I'm not sure that's easy to answer.

BTW: Has anyone thought about whether DHCPv6 (or DHCPng) can or should be
able to give out multicast or the IPv6 "cluster" addresses (or whatever
they're called now if they still exist)? I would suspect that this would be
a whole lot easier with DHCPv6 since the client could simply supply the
appropriate prefix to obtain that address type? I'm not suggesting this as a
requirement on my list (unless of course everything thinks it has value). I
suspect these would be excellent extensions to consider down the road as
additional "allocatable resources" and as long as the framework can
accommodate it, probably best to ignore for now.

- Bernie Volz
  IPWorks, Inc.

-----Original Message-----
From: Jim Bound [mailto:[email-masked]]
Sent: Wednesday, August 30, 2000 3:45 PM
To: DHCPv6 discussion list
Cc: [email-masked]
Subject: Re: Things I want to see in DHCPv6

Hi Bernie,

Response to Clarification question ONLY:

Clarification
>I essentially agree with Ralph on his list. Here are some
>additions/comments.
Ralph stated he wanted the 2131 message types but later you say you
don't want the boot OP param and multicast is a good thing?  Can you
clarify more as I know Ralph better and I think I know what he is saying
but not clear which way your going here and if you completely agree with
Ralph or want to amend that agreement?  Just for message "syntax" not
semantics as I realize that stuff will have to be at the meeting. thanks

Clarification:
>I also have one item that I feel needs clarification on Ralph's list:
>>   * One interface, with a single unique identifier, can be assigned
>>     multiple addresses

>In IPv6, does this mean one address per prefix on the "interface" (with
>multiple prefixes being supported) or does it mean that the client can also
>obtain MULTIPLE addresses for the same prefix. I would hope both. It is not
>clear exactly how this would easily be achieved - how to tell the
difference
>between a duplicate request (without caching transaction ids) and a request
>for a second (or third...) address. If done in a single request, having
>multiple IP Address Extensions could be used. But if done in multiple
>requests, it is not as easy. I guess it might first be worthwhile to
>consider why we need this - sounds like a useful feature, but would it be
>used and for what reasons?

In IPv6 stateless the node first configures its EUID and for now
implementations are doing the Aggregatable format for IPv6 which implies
a 64bit EUID.  This 64bit EUID is also used to create the nodes 
link-local address by adding an architectural defined constant FE80 to
that and bingo one has a link-local address.  If you watch many of the IPv6
nodes boot up at bake-offs when the OS is being loaded on the screen in the
case of UNIX you see "configuring link-loal address" so by the time the
login prompt appears the node has a link-local address and it is unique
on the link via duplicate address detection and the node can converse on the
link with any other node using its link local address.

So lets assume for clarity that the EUID for mynode interface #1 
is "34" when I attached the link-local prefix to it the link-local 
128bit address is FE80::34 this would be the present client link-local 
address in the existing dhcpv6 messages.

Then a router appears on the link and starts sending out Router
Advertisements as ICMPv6 messages (no more ARP stuff) with a list of
prefixes and sets the bit telling the nodes you can use these prefixes
to configure your addresses.  Lets say the router sent out the following
prefixes:

  3ffe::/64
  2ffe::/64

So at mynode for interface #1 with EUID of 34 I can now configure
addresses as follows:

  3ffe::34
  2ffe::34

And I don't have to run duplicate address detection again as I did for
the link-local and as the EUID did not change.

If I had interface #2 with EUID 53 on the SAME LINK I could configure
two addresses for that interface as:

  3ffe::53
  2ffe::53

What IPv6 gurantees is that link-local addresses will not be duplicated
on a link (IPv4 subnet).

DHCPv6 has used the client link-local address as the dhcpv4 client
identifier and we actually did a have a lot discussion on this years ago
but that was before the Ipv6 Privacy paranoids got involved and
anonymous address have been added to the mix.  This presents a new issue
as you succinctly pointed out and it did for all of our IPv6
implementations too.  I will stop there per Ralphs suggestion to not
discuss input yet.  But at the meeting I can expound on how we have
dealt with that for neighbor discovery and IP over foo issues.

One of the unstated goals of dhcpv6 was to be able to emulate the same
capabilities from a dhcpv6 server to a dhcpv6 client as the router did
with prefixes.  In addition to also using the existing dhcpv4 model
where you give the client a complete 128bit address.  The idea was to
let the user to pick their pain.  But the client in either model can
communicate on the link always with multicast or unicast using its
link-local address as its source address in the IPv6 header.  Hence, it
can get to onlink servers or to onlink relays or generically to agents
on the link.

Hope this was helpful,
/jim

---

From: Jim Bound <[email-masked]>
Date: Wed, 30 Aug 2000 17:02:25 -0400

Hi Bernie,

>the first byte to follow the UDP header.

OH OK.  I was going down the wrong path glad I asked.

>and I'm not sure that's easy to answer.

It certainly is not an easy answer but I don't think it will take lots
of hours either.  But definitely an issue.

Just btw us I will tell you I will make damn sure that in any IPv6
implementation I work on users will be able to ignore this entire fiasco
if they so choose to.  Its mostly a joke IMO.

>accommodate it, probably best to ignore for now.

Anycast addresses I think your referring too.  Still illegal to assign
them to anything but routers.  This is poping up on another design team
I am on in IPv6 space right now.  I agree we need to make sure we do
nothing to prevent giving them out for sure but also nothing really
differentiates anycast from unicast except when its routed and that you
cannot use it as IP source address.

regards,
/jim
- Bernie Volz
  IPWorks, Inc.

-----Original Message-----
From: Jim Bound [mailto:[email-masked]]
Sent: Wednesday, August 30, 2000 3:45 PM
To: DHCPv6 discussion list
Cc: [email-masked]
Subject: Re: Things I want to see in DHCPv6

Hi Bernie,

Clarification

difference

  3ffe::/64
  2ffe::/64

  3ffe::34
  2ffe::34

  3ffe::53
  2ffe::53

Hope this was helpful,
/jim

---

From: Bill Sommerfeld <[email-masked]>
Date: Wed, 30 Aug 2000 17:16:59 -0400

regarding the state machine:

flowcharts are one way to depict state-transitions; however, it's very
easy to forget about certain kinds of events which may occur.

In a past job, when I was working over a DHCPv4 client which had a
badly broken state machine I found it extremely helpful to enumerate:

	- states
	- events
		- packet reception. 
		- timer expiration.
		- ...

I then filled my whiteboard with a big states vs events table (each
"state" is a row; each event is a column), with actions ("send
packet", "set timer", "switch to state Y", ...) in the intersections.
it makes it very easy to figure out where there are holes in the state
transition where the protocol can get "stuck" if you forget about a
retransmission timer..

					- Bill

---

From: Jim Bound <[email-masked]>
Date: Wed, 30 Aug 2000 17:34:46 -0400

bill 100% agree with you.  in fact I was going to do that and it was
suggested to me to do the flowchart first and do the highlevel thing.
I am timed out now to try to get it done by tomorrow.

what we can do for the wg when we get to where folks are comfortable
with what we are going to do is add this to any charts.  or if there is
still confusion after the meeting I will do it immediately.

also not only is what you suggest more useful and complete but way
better to look at than ascii artwork IMO.

the flow chart is only a reference point for sure.

/jim

---

From: Ted Lemon <[email-masked]>
Date: Wed, 30 Aug 2000 14:35:13 -0700

I think it would be a really good idea *not* to put a state diagram in
the protocol spec.   The problem is that then people will just read
the state diagram, and not the text, and that means we have to make
sure the state diagram completely and correctly expresses everything
in the text, which is a hard goal to meet.   I really like the idea in
the failover protocol specification that each state just has a section
explaining what events result in a transition from that state, and
what the resulting state is in each case.

			       _MelloN_

---

From: "Bernard Aboba" <[email-masked]>
Date: Thu, 31 Aug 2000 09:02:49 -0700

>they're called now if they still exist)? 

I would suggest not trying to solve MADCAPv6 issues with DHCPv6. The
MALLOC WG initially tried to reuse DHCP formats for MADCAP and then 
decided to go their own way. Adding more constraints on the problem 
is likely to make it harder to solve and we've got enough on our plate 
already.