Subject: Re: [dhcwg] DHCPv6 Server IP address.

From: RamaSubramanian KrishnaMurthi <[email-masked]>
Date: Fri, 20 Jul 2007 19:24:21 -0700 (PDT)

Hi,
Thanks a lot for detailed description.
If the Server sends Unicast Option is it must that server should support Unicast feature. Why I was asking this question is from the Client we could n't find from which DHCPServer the client has got the Ipaddress. If DHCP client has got IP address from a rogue DHCP server then it becomes cumbersome to find from which DHCPServer the client has got the configuration options for both stateless & statefull mode.

Yours ever
-RamaSubbu SK 

----- Original Message ----
From: Bernie Volz (volz) <[email-masked]>
To: RamaSubramanian KrishnaMurthi <[email-masked]>
Cc: [email-masked]
Sent: Saturday, July 21, 2007 2:38:22 AM
Subject: RE: [dhcwg] DHCPv6 Server IP address.

RamaSubbu SK:

DHCPv6 clients normally will multicast their packets to the link-local
multicast address of ff02::1:2. Either the server will be on that link,
or a relay-agent will forward it on (to another relay-agent or the
server).

Thus all packets a client sends are MULTICAST to the ff02::1:2
link-local multicast address (with the IPv6 source address set to the
client's link-local address) and on-link responder (server or
relay-agent) will UNICAST the response packet to the client's link-local
address.

If a server sends a server-unicast option (which has the address of the
DHCPv6 server specified in it) to the client and the client has a
suitable address that it can use to communicate directly with the
server, it can then unicast. Note that if the server's address is a
global unicast address and the client doesn't have a global unicast
address, the client could NOT unicast.

The way a server is identified is by using a Server-ID option. In some
client packets (Solicit, for example) there is no Server-ID option
because the client doesn't know it yet (it is looking for a server to
use). In Request, Renew, Release messages, the client MUST supply the
server-id option from the Advertise it selected. All servers may receive
these requests, but only the one who's server-id matches the value
specified in the option will respond (the others drop the packet).

Note also that the server-id option MUST be used even if packets are
unicast by the client.

This is a bit different than in DHCPv4 where some client messages are
unicast directly between client and server.

- Bernie

-----Original Message-----
From: David W. Hankins [mailto:[email-masked]] 
Sent: Friday, July 20, 2007 2:12 PM
To: RamaSubramanian KrishnaMurthi
Cc: [email-masked]
Subject: Re: [dhcwg] DHCPv6 Server IP address.

On Fri, Jul 20, 2007 at 10:33:30AM -0700, RamaSubramanian KrishnaMurthi
wrote:
> How can I know the DHCPv6 Server IP address on stateless and statefull
> mode?

The Server Unicast Option (RFC 3315 Setion 22.12).

However, the Server may not elect to transmit packets containing this
option, and if it does, it (or possibly some intervening device trying
to be too clever) may send a reply with a UseMulticast status code.

> In DHCPv4, in every DHCP packet server will send its IPaddress in the
> siaddr  field.

That is not correct.  RFC 2131 clarified the 'siaddr' field as the
address of the server to use in the "next step of the client's
bootstrap process", whatever that process may be (but probably
loading an executable image via TFTP).

Or are you looking for a DHCPv6 analogue of the next-server address?
That isn't the Unicast option.

-- 
Ash bugud-gul durbatuluk agh burzum-ishi krimpatul.
Why settle for the lesser evil?     https://secure.isc.org/store/t-shirt/
-- 
David W. Hankins    "If you don't do it right the first time,
Software Engineer             you'll just have to do it again."
Internet Systems Consortium, Inc.        -- Jack T. Hankins

____________________________________________________________________________________
Get the Yahoo! toolbar and be alerted to new email wherever you're surfing.
http://new.toolbar.yahoo.com/toolbar/features/mail/index.php

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: "David W. Hankins" <[email-masked]>
Date: Sun, 22 Jul 2007 11:11:21 +0200

On Fri, Jul 20, 2007 at 07:24:21PM -0700, RamaSubramanian KrishnaMurthi wrote:
> If the Server sends Unicast Option is it must that server should
> support Unicast feature.

My memory is that 3315 says it MUST NOT respond to unicasts unless
it has supplied the unicast option in a message.  Supplying the
Unicast option itself is optional (it's thought to be an operator-
configurable optimization).

I may be remembering that wrong, and I don't remember any other
normative language.

> Why I was asking this question is from the Client we could n't find
> from which DHCPServer the client has got the Ipaddress.

Simply, your only and most reliable indication of 'which server gave
me this address' is the server identifier.  Which is not an address.
And could be spoofed or altered.  Unless you're using authentication,
which you probably aren't.

Since the contents are never used to address or contact the server -
only to identify to which server the client is speaking - this may
very well be a useless blob of random zeroes and ones.

> If DHCP
> client has got IP address from a rogue DHCP server then it becomes
> cumbersome to find from which DHCPServer the client has got the
> configuration options for both stateless & statefull mode.

This is a misconfigured server, or a malcontent?

If it's just a misconfigured server, have a look at the server-id
option, hope that the server is still using the same MAC address
as hopefully is listed there.  If it doesn't use one of the LL types,
you'll have to use the source MAC of the packets you're receiving.

You can hopefully find a way to get to the server from its MAC.