Re: [dhcwg] Changes to remove "client-link-local-address" from the DHCPv6 header

[Ralph Droms <[e-mail]>]

At 10:36 AM 8/30/2001 -0400, Ted Lemon wrote:
>> I think the explicit specification of a relay-address is needed in cases
>> where either the relay has no global address on the proper interface (and
>> thus needs to indicate a prefix-only address, which should work just fine),
>> or where specifying the source address may complicate the packet's route out
>> of the relay (this is speculation).  If a relay must detect one of these
>> conditions, then it complicates the relay, or encourages relay authors to
>> opt for the safer solution and always use the option (in which case it isn't
>> optional in a practical sense).
>
>I think the DHCP server should be using the prefix that the relay
>reports when doing address assignments, not the IP address that the
>relay reports.   Maybe I'm missing something here - are we back to
>overloading these two functions?
>
>                               _MelloN_


Suppose the field name and definition are changed as in the figure below,
and:

* The server chooses an address for the client
  based on the link-prefix (details TBD; could
  use 0s to indicate prefix length or include
  explicit prefix length or ???)
* The server sends the Relay-reply message to 
  the source address in the IP header of the
  Relay-forward message
* The relay forwards the Reply message to the
  client on the link identified by the
  link-prefix

This proposal still overloads the identification of the link
on which the relay forward the Reply to the client with the
selection of an address for the client by the server.  We
could either add a separate field for specifying a prefix
for address selection or define an option (like the DHCPv4
subnet selection option).  I would be inclined to define
an option that might be used by either a client or a
relay (or both?). 

- Ralph

=====
9.1. Relay-forward message

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    msg-type   |                                               |
     +-+-+-+-+-+-+-+-+                                               |
     |                          link-prefix                          |
     |                                                               |
     |                                                               |
     |               |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
     +-+-+-+-+-+-+-+-+                                               |
     |                                                               |
     |                     client-return-address                     |
     |                                                               |
     |               |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
     +-+-+-+-+-+-+-+-+                                               |
     .                                                               .
     .            options (variable number and length)   ....        .
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


      msg-type                    RELAY-FORW

      link-prefix                 A prefix assigned to the link from
                                  which the client message was received.

      client-return-address       The source address from the IP
                                  datagram in which the message from the
                                  client was received by the relay agent

      options                     MUST include a "Client message
                                  option"; see section 18.7.





_______________________________________________
dhcwg mailing list
[e-mail]
http://www1.ietf.org/mailman/listinfo/dhcwg