Subject: RE: Things I want to see in DHCPv6

From: Bernie Volz <[email-masked]>
Date: Wed, 30 Aug 2000 17:22:02 -0400

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

Yes, I can see arguments in that direction. While fundamentally the idea is
good (being able to uniquely identify a system), for almost all systems it
doesn't really matter what address they get (in theory). For those few
systems where addresses might be important, perhaps static or other
configuration techniques are more appropriate anyway (I think that's the
case in the IPv4 world).

This is likely more of an issue in the IPv4 world (it is something people
have come to expect) and my feeling that we do DHCPng is making me cling to
it?

I think some research could be in order ... how many sites really do use
client identifiers (other than those that might be generated by systems from
a mac address)? I can't really think of any offhand. PLEASE DO NOT SEND YOUR
RESPONSES TO THIS QUESTION - NOW IS NOT THE TIME FOR THIS RESEARCH.

- Bernie Volz
  IPWorks, Inc.

-----Original Message-----
From: Jim Bound [mailto:[email-masked]]
Sent: Wednesday, August 30, 2000 5:02 PM
To: Bernie Volz
Cc: [email-masked]'; [email-masked]; [email-masked]
Subject: Re: Things I want to see in DHCPv6

Hi Bernie,

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

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

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

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.

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

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,

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:45:51 -0400

Hi Bernie,

>>if they so choose to.  Its mostly a joke IMO.

WHOOPS.  I was referencing the issue that joe-random-bad-guy will see my
EUID go by on my book order to amazon.com and do evil things to my
PC at home when I use IPv6.  Politically the IETF has had to address
this issue and Thomas has done a good job with the surgery to put this
into IPv6 "privacy drafts", and we will have to make sure the code is
there to do it.  What I was saying is when the system comes up the user
will get to respond:  Do you care about this Privacy Junk and if you do
I will be whacking your addresses every xxx minutes, but if you believe
in personal responsibility and think this is not necessary we won't do
this to you :----)

>configuration techniques are more appropriate anyway (I think that's the

I agree and if dhcpv4 identifier works lets use it we were just trying
to use what used to be pretty sure to be unique and also could be used
to send to client on a local link.  I don't care really we always have
the IP header.  I suggest we want to keep taking advantage of the
architectural fact that IPv6 nodes do have IPv6 addresses for the link
after they boot as part of the base protocol set.

>have come to expect) and my feeling that we do DHCPng is making me cling to

I think we need it for dhcpv6 too.  Not commenting on dhcpng till the
meeting.

thanks
/jim