Subject: [dhcwg] message format

From: Aries Fajar <[email-masked]>
Date: Thu, 18 Apr 2002 12:08:14 +0700

Dear all,
I'm new to dhcpv6 and still learning it. I'm confuse about the dhcp
message.
Can u give the full message dhcp request from the client to the server
as an example ?
draft-ietf-dhc-dhcpv6-23.txt is a little bit confusing about message
format.
I read a book about IPV6 that contains dhcpv6 ( very old, 1996 ) and i
understand
many have changed since then...
so, from all my knowledge that i have acquired, this is my thinking
about message request

------------------------------------------------
|     6    |   4   |    flow label : 0         |
------------------------------------------------
|    len:32   |  nxt : 17 | hops : 9           |
------------------------------------------------
|                                              |
|       Source :                               |
|                                              |
|----------------------------------------------
|                                              |
|        Dest : DHCP Server                    |
|                                              |
----------------------------------------------
|      src port : 546      |   dst port : 547  |
----------------------------------------------
|   length : 96              |    checksum     |
----------------------------------------------
|    request                 |   12345         |
----------------------------------------------
|     options                                  |
----------------------------------------------

so, what's in the options field ? after reading the RFC, there is no
client network address
in the udp message. how can the server send the reply message to the
client, if it doesn't
know about the client address ?

I read the old draft ( draft-ietf-dhc-dhcpv6-15.txt ) and i find a 
more clearly message format. Here it is:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  msg-type = 3 |C|R|  reserved |  transaction-ID   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
|       client's link-local address                 |
|              (16 octets)                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             relay-address                         |
|              (16 octets)                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             server-address                        |
|              (16 octets)                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  extensions (variable number and length)   ....   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

where is it now ? is it somewhere at the options field ?

Please help
Thanks

Aries Fajar
Electrical Engineering Department
Trisakti University
Indonesia

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

---

From: Ralph Droms <[email-masked]>
Date: Sat, 20 Apr 2002 07:58:28 -0400

Aries,

The DHCPv6 message header has been simplified to avoid carrying redundant 
information.  The address to which the server should reply to a DHCPv6 
message is always available as the source address in the IPv6 header.  When 
the client and server are on the same link, the source address is an 
address belonging to the client, so the server can reply directly to the 
client.

When the client and server are on different links, the message to the 
server is forwarded by a relay agent.  In this case, the source address in 
the message received by the server is an address belonging to the relay 
agent.  The server sends its reply back to the relay agent, which then 
forwards the reply back to the client.

For example, in draft-ietf-dhc-dhcpv6-23.txt, at the end of section 18.2.2. 
this text specifies how a server sends a Solicit message:

18.2.2. Creation and transmission of Advertise messages

    [...]

    If the Solicit message was received directly by the server, the
    server unicasts the Advertise message directly to the client using
    the address in the source address field from the IP datagram in
    which the Solicit message was received.  The Advertise message MUST
    be unicast through the interface on which the Solicit message was
    received.

    If the Solicit message was received in a Relay-forward message,
    the server constructs a Relay-reply message with the Advertise
    message in the payload of a "server-message" option.  The server
    unicasts the Relay-reply message directly to the relay agent using
    the address in the source address field from the IP datagram in which
    the Relay-forward message was received.

- Ralph Droms

At 12:08 PM 4/18/2002 +0700, Aries Fajar wrote:
>------------------------------------------------a
>|                                              |
>|       Source :                               |
>|                                              |