Subject: RE: [dhcwg] Changes to remove "client-link-local-address" from th e DHCPv6 header

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Thu, 30 Aug 2001 14:10:42 -0500

Yeah, in thinking some more about this, perhaps it is better that the relay
doesn't know about prefix lengths (it doesn't really need to) - though it
likely will anyway (because of Router Advertisements, etc).

It also is one more thing that could get misconfigured in some way between
the relay and server, so perhaps best to just let the server deal with it.

Therefore, I would suggest it can either be the prefix (with 0's in the interface
id) or just an address. Since the server knows the prefix lengths, it can find
the appropriate "network" by doing the checks only against the prefix-length
bits. Essentially, only the prefix bits are significant and the remaining bits
are don't care. But, I have no major issue if we want to force it to be just
the prefix (with 0's in the other bits).

- Bernie

-----Original Message-----
From: Ralph Droms [mailto:[email-masked]]
Sent: Thursday, August 30, 2001 2:05 PM
To: [email-masked]
Subject: RE: [dhcwg] Changes to remove "client-link-local-address" from
the DHCPv6 header 

Bernie opined:

>Just to be clear, there are three pieces of information: 
>
>1. The address used to communicate with the relay. 
>2. The link on which the client's packet was received. 
>3. The prefix to be used for address assignment for the client. 
>
>I think 1 is easy and it should just be the IPv6 source address of the Relay-Forw. 
>
>In many cases 2 and 3 are the same but they need not be. I would suggest we solve 
>this by doing the following: 
>
>For 3, the relay should send a prefix and prefix-length. 

For 3, we can either do a variable length length+prefix field or send
a prefix with 0's in the interface-id or just send an address
from the appropriate link and let the server deduce the
prefix (which is what we do in DHCPv4, right?).  I've written up
the third alternative, which is as easy as any.  I'll rewrite
it as soon as someone expresses a preference for one of the
other alternatives or comes up with a different plan.

- 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                 An address with a prefix that is
                                  assigned to the link from
                                  which the client should be assigned
                                  an address.

      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.  The relay
                                  MUST include a "circuit-ID option" if
                                  it needs to explicitly identify the
                                  link on which the client message should
                                  be forwarded to the client

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

---

From: Josh Littlefield <[email-masked]>
Date: Thu, 30 Aug 2001 16:03:51 -0400

> "Bernie Volz (EUD)" wrote:
> 

I agree.  I think having the relay include the prefix length is almost
over-specifying the subnet to the server.  The server had its configuration
of subnets, and the relay needs only to provide an address within a subnet. 
Then the address either maps to a subnet, or it doesn't.  But it won't run
the risk of mapping to more than one if the relay-communicated prefix length
is smaller than expected).

> the prefix (with 0's in the other bits).

This is what I was trying to get at before.  The relay-address can be a full
address, or a "prefix-only" address (0's in the other bits) and the server
shouldn't care one way or the other as long as it maps to a subnet and isn't
used to address packets.  I see no reason to force the relay-address to be
prefix-only, or to disallow it.

-- 
=====================================================================
Josh Littlefield                                  Cisco Systems, Inc.
[email-masked]                                      250 Apollo Drive
tel: 978-244-8378  fax: same               Chelmsford, MA  01824-3627

---

From: Ted Lemon <[email-masked]>
Date: Thu, 30 Aug 2001 19:11:47 -0400

> Therefore, I would suggest it can either be the prefix (with 0's in
> the interface id) or just an address. Since the server knows the
> prefix lengths, it can find the appropriate "network" by doing the
> checks only against the prefix-length bits. Essentially, only the
> prefix bits are significant and the remaining bits are don't
> care. But, I have no major issue if we want to force it to be just

If we force it to be just the prefix, the relay has to know the length
of the prefix in order to figure out what it is, right?   :')

Anyway, I think your loose interpretation is fine - any address in the
subnet's range should be fine, including the prefix+all zeros address.
The point is that it is semantically *not* the address to which the
reply goes.

			       _MelloN_

---

From: Ralph Droms <[email-masked]>
Date: Fri, 31 Aug 2001 11:38:19 -0400

Here's the final text on this issue (extracted from the revved draft):

9. Relay messages

   Relay agents exchange messages with servers to forward messages
between clients and servers that are not connected to the same link.

      0                   1                   2                   3
     |               |                                               |
     |               |                                               |

      msg-type                RELAY-FORW

      link-prefix             An address with a prefix that is assigned
                              to the link from which the client should
                              be assigned an address.

      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.

9.2. Relay-reply message

      0                   1                   2                   3
     |               |                                               |
     |               |                                               |

      msg-type        RELAY-REPL

      link-prefix     An address with a prefix that is assigned to the
                      link from which the client should be assigned an
                      address.

      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 "Server message option"; see
                      section 18.8.

16. Relay Behavior

   For this discussion, the Relay may be configured to use a list of
server destination addresses, which may include unicast addresses,
the All DHCP Servers multicast address, or other multicast addresses
selected by the network administrator.  If the Relay has not been
explicitly configured, it MUST use the All DHCP Servers multicast
address as the default.

16.1. Relaying of client messages

   When a Relay receives a valid client message, it constructs a
Relay-forward message.  The relay places an address with a prefix
assigned to the link on which the client should be assigned an address
in the link-prefix field.  This address will be used by the server to
determine the link from which the client should be assigned an address
and other configuration information.

   If the relay cannot use the address in the link-prefix field
to identify the interface through which the response to the client
will be forwarded, the relay MUST include a circuit-id option (see
section TBD)in the Relay-forward message.  The server will include the
circuit-id option in its Relay-reply message.

   The relay copies the source address from the IP datagram in which
the message was received from the client into the client-return-address
field in the Relay-forward message.

   The relay constructs a "client-message" option 18.7 that contains the
entire message from the client in the data field of the option.  The
relay places the "relay-message" option along with any "relay-specific"
options in the options field of the Relay-forward message.  The Relay
then sends the Relay-forward message to the list of server destination
addresses that it has been configured with.

16.2. Relaying of server messages

   When the relay receives a Relay-reply message, it extracts the server
message from the "server-message" option.  If the Relay-reply message
includes a circuit-id option, the relay forwards the message from the
server to the client on the link identified by the circuit-id option.
Otherwise, the relay forwards the message on the link identified by the
link-prefix option.  In either case, the relay forwards the message
to the address in the client-return-address field in the Relay-reply
message.