Subject: [dhcwg] [New I-D] DHCPv6 Relay Agent Link Selection(RALS) Option

From: Amy <[email-masked]>
Date: Wed, 13 Sep 2006 09:27:03 +0800

We posted a new I-D as follows.  We would appreciate your comments.

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.

	Title		: DHCPv6 Relay Agent Link Selection(RALS) Option
	Author(s)	: Y. Zhao
	Filename	: draft-zhao-dhc-dhcpv6-relay-link-selection-00.txt
	Pages		: 16
	Date		: 2006-9-12
	
This document defines a new Relay Agent Link Selection(RALS) option
for the Dynamic Host Configuration Protocol for IPv6 (DHCPv6).The new
option is inserted by the DHCPv6 relay agent when forwarding client-
originated DHCPv6 packets to a DHCPv6 server.  Servers recognizing
this new option can include link-selection information as part of
policies about address assignment, prefix delegation, or other DHCP
parameters.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-zhao-dhc-dhcpv6-relay-link-selecti
on-00.txt

Thanks.

Amy Zhao

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

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Thu, 21 Sep 2006 08:44:10 -0400

1. Write a draft and have it work its way through to RFC.
 
2. Wait for a 3315-bis to be started and suggest it as part of that
work.
 
Note that doing 1 would likely be best and should then be incorporated
into a 3315-bis.
 
I might suggest we extend this draft/work to include more than just the
link-address field. RFC 3315 leaves it unspecified as to which relay's
data is used when relay chaining occurs. There are two conflicting
arguments here: 1) the relay closest to the client should have the most
detailed information about the client vs 2) the relay closest to the
server may have policy it wants to enforce. This second statement is
rather a weird for me to state given the discussion on this thread to
avoid putting too much policy into relays ...
 
HOWEVER, IMHO the BEST solution is to leave this to servers to implement
or offer policy choices as application requirements or customer demand
dictates. As there are many things a relay could provide, different
applications may have requirements to take some information from the
first hop and other information from the last. In a RFC 3315-bis, I do
think it would be useful to point this out specifically.
 
- Bernie

________________________________

From: Lawrence Zou [mailto:[email-masked]] 
Sent: Thursday, September 21, 2006 3:24 AM
To: Bernie Volz (volz)
Cc: [email-masked]
Subject: RE: [dhcwg] [New I-D] DHCPv6 Relay Agent Link Selection(RALS)
Option

Then,how to change the RFC3315? 
I think it is not a "language" problem, 
maybe we should change the definition of the "link-address",let the
second (or later) relay-agent's link-address field can include some
information of  the subscriber?

Best regards,

Lawrence 

________________________________

		From: Bernie Volz (volz) [mailto:[email-masked]] 
		Sent: Friday, September 15, 2006 9:15 PM
		To: Amy
		Cc: [email-masked]; Kostur, Andre
		Subject: RE: [dhcwg] [New I-D] DHCPv6 Relay Agent Link
Selection(RALS) Option

		Just because there is one link-address does not mean
that multiple prefixes (either for stateful or PD, or both) can't be
"found" by the server. The link-address field is a key into where the
client is located. How the server uses that information is up to the
server.

		   NAS,act as relay B, can get the information about the
link(s) where the client is,but the link-address of relay-forward-2 can
not be used as a hint to server
		   Relay A just forwards the client-originated message
to NAS,it can not determine where the client is, so the link-address of
relay-forward-1 can not either.
		 
		   In this case, we can use link-selection option in
relay-forward-2 as a hint to server.
		 
		Well, if you wanted the second (or later) relay-agent's
link-address field to be used, why not change the language of RFC 3315
to allow that? Rather than having to implement an entirely new option
(which you're saying the server would have to "search" the relay chain
for anyway).
		 
		Personally, I've always thought that we should have used
the "inner-most" (ie, closest to server) relay-agent's (non-zero)
link-address field FIRST.  That would have allowed an inner relay to
enforce some level of policy and override what an outer relay (ie,
closer to client) had sent in. And, I'd much rather have RFC 3315-bis
state that than have a completely new option.
		 
		- Bernie

________________________________

		From: Amy [mailto:[email-masked]] 
		Sent: Thursday, September 14, 2006 11:38 PM
		To: Bernie Volz (volz)
		Cc: [email-masked]; 'Kostur, Andre'
		Subject: RE: [dhcwg] [New I-D] DHCPv6 Relay Agent Link
Selection(RALS) Option

		Hi,Bernie:
		  
		   Thanks!
		 
		   On the first hop relay, according to Section 20.1.1.
of rfc3315 , the link-address placed by first hop relay will be used by
the    server to determine the link where the client is.
		   But in IPv6, multiple subnet prefixes can be assigned
to IP link, the link-address only can determine one subnet prefix. And
Link-selection option can determine one or more seperated subnet
prefixes.

		    On the non-first hop relay, according to Section
20.1.2. of rfc3315, the link-address is either 0 (if If the source
address from the IP datagram header of the received message is a global
or site-local address) or a global or site-local address assigned to the
interface on which the message was received.
		   
		                       relay-forward-1
relay-forward-2
		   client----relay A--------------------NAS/relay
B-----------------------server
		 
		   NAS,act as relay B, can get the information about the
link(s) where the client is,but the link-address of relay-forward-2 can
not be used as a hint to server
		   Relay A just forwards the client-originated message
to NAS,it can not determine where the client is, so the link-address of
relay-forward-1 can not either.
		 
		   In this case, we can use link-selection option in
relay-forward-2 as a hint to server.
		 
		B.R.
		 
		Amy Zhao

________________________________

			From: Bernie Volz (volz) [mailto:[email-masked]]

			Sent: Thursday, September 14, 2006 8:59 PM
			To: Amy; Kostur, Andre
			Cc: [email-masked]
			Subject: RE: [dhcwg] [New I-D] DHCPv6 Relay
Agent Link Selection(RALS) Opt ion

			I agree with Andre. I can't see the need for
this option.
			 
			The link-address field in the relay-forw message
is addressing information for the server to use in determine where the
client is (for address assignment/prefix-delegation purposes). There is
***NO*** requirement that this address be an address that the
relay-agent has configured.
			 
			The address of relay agent is in either the
peer-address field (if this isn't the first hop relay) or in the SOURCE
address of the relay-forw packet. Thus, unlike in DHCPv4 where the
giaddr field is overloaded to mean two things, that is NOT the case for
DHCPv6.
			 
			Unless you can come up with a reason why the
link-address field isn't sufficient, I can't see supporting this work.
			 
			- Bernie

________________________________

			From: Amy [mailto:[email-masked]] 
			Sent: Wednesday, September 13, 2006 3:56 AM
			To: 'Kostur, Andre'
			Cc: [email-masked]
			Subject: RE: [dhcwg] [New I-D] DHCPv6 Relay
Agent Link Selection(RALS) Opt ion

			Hello,Kostur
			    Thank you!
			    
			    Yes, it is a counterpart of DHCPv4
link-selection sub-option, so we used a similiar option name. And we
missed it in the draft, sorry.
			   
			    I obtain the requirement from NetLMM Base
protocol, the draft is still in progress.
	
+--------------------------------+
			                  |           LMM Domain
|
			                  |
|
			                  |    +----+           +----+
|
			                  |    |LMA |           | LMA|
|
			                  |    +----+           +----+
|
			                  |       \               /
|
			                  |    **********************
|
			                  |   *                      *
|
			                  |  *      IP network        *
|
			                  |   *                      *
|
			                  |    **********************
|
			                  |      /        |         \
|
			                  |  +----+    +----+     +----+
|
	
+--|MAG1|----|MAG2|-----|MAG3|---+
			                     +----+    +----+     +----+
			                        |                    |
			                        |                    |
			                      +---+ Movement        +--+
			                      |MN | ---->           |CN|
			                      +---+                 +--+
			 
			  When a mobile mode connects to the NetLMM
infrastructure, it first needs to configure an address,i.e.NetLMM
Address. This address is the invariant IP address on the MN inside the
NetLMM domain. And the IPv6 link prefix of the NetLMM address comes from
LMA, not MAG. 
			 
			   From my understand, link-address field holds
the address of the relay agent. And so, we think that only using
link-address can not satisfy the above requirement.

________________________________

			From: Kostur, Andre
[mailto:[email-masked]] 
			Sent: Wednesday, September 13, 2006 12:23 PM
			To: Amy; [email-masked]
			Subject: RE: [dhcwg] [New I-D] DHCPv6 Relay
Agent Link Selection(RALS) Opt ion

				> -----Original Message----- 
				> From: Amy
[mailto:[email-masked]] 
				> A New Internet-Draft is available from
the on-line 
				> Internet-Drafts directories. 
				> 
				> 
				>       Title           : DHCPv6 Relay
Agent Link Selection(RALS) Option 
				>       Author(s)       : Y. Zhao 
				>       Filename        : 
				>
draft-zhao-dhc-dhcpv6-relay-link-selection-00.txt 
				>       Date            : 2006-9-12 

				I don't understand the requirement for
this draft.  From what I understand, this is to allow the Relay Agent to
select the link/prefix from which to make an allocation.  This is
basically a v6 version of the Link Selection Suboption for dhcpv4.
However, from my reading of RFC 3315, this functionality is already
supported in the link-address field of the Relay-forward message:

				      link-address   A global or
site-local address that will be used by 
				                     the server to
identify the link on which the client 
				                     is located. 

				What behaviours does this draft cover
that the link-address field doesn't address?

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Mon, 25 Sep 2006 08:39:30 -0400

Link-address also applies to Prefix Delegation. How else could the
server know where the client is located? Relay-agents don't care whether
the device doing DHCP is using stateful or PD; they use the same
forwarding logic.

- Bernie 

-----Original Message-----
From: Amy Zhao [mailto:[email-masked]] 
Sent: Monday, September 25, 2006 4:11 AM
To: Bernie Volz (volz); 'Bud Millwood'; 'David W. Hankins'; 'Ted Lemon'
Cc: [email-masked]
Subject: RE: [dhcwg] [New I-D] DHCPv6 Relay Agent Link Selection(RALS)
Option

Hello, Bernie,Bud,David and Ted!
       Thank you!
       I will consider your comments carefully. Maybe you're right. 
       
       Another question:
       Is there any text describing the link-address about
prefix-delegation,or it is same as the link-address about ip-address
assignment?

B.R.
Amy 

E-mail: [email-masked]

> Sent: Thursday, September 21, 2006 8:23 PM
> To: Amy Zhao; Bud Millwood; David W. Hankins
> Cc: [email-masked]
> Amy:
> Bud, David, and Ted all share the same concern I have, though 
> they expressed it better.
> 
> You are trying to have the relay make decisions that are 
> better left to the server. We usually assume that the DHCP 
> server is the place where complexity lives and many servers 
> (as David pointed out for the ISC server and we have similar 
> facilities in the Cisco Network Registrar
> server) already provide mechanisms to do this -- either for specific
> (preconfigured) clients or based on information (from client 
> or relay) in the packet.
> 
> If you put this information in the relay, you've got to 
> configure it and also any other relays that those clients may 
> use. Generally there are many relays for each DHCP server.
> 
> If you put this information in the DHCP server, you've got 
> fewer "devices" to configure and update as changes are made.
> 
> And, DHCP servers usually run on general purpose hosts and 
> have APIs or other capabilities that are often lacking on 
> relay agents which are typically on routers.
> 
> The bottom line is that as the relay must be configured with 
> some set of rules (ie, POLICY) to apply to clients (so that 
> it can set your link-selection option accordingly), we feel 
> it better to move that logic into the DHCP server.
> 
> If you don't have rules (policy) but instead the relay is 
> extracting this information from the network in some manner 
> that is unavailable to the DHCP server, then I suggest we 
> look at an option for the relay to communicate this 
> information to the server so that the server can apply 
> appropriate policy. That is a much more powerful system as 
> perhaps others want to do more than just determine the 
> prefixes to assign.
> 
> You might look at what DOCSIS provides for DHCPv4 and DHCPv6 
> as a model
> -- capabilities and other data are communicated to the DHCP 
> server so that it can apply appropriate policy.
> 
> - Bernie 
> 
> From: Amy Zhao [mailto:[email-masked]]
> Sent: Thursday, September 21, 2006 5:07 AM
> To: 'Bud Millwood'; 'David W. Hankins'
> Cc: [email-masked]
> Hello!
> Sorry, maybe I used an inappropriate example. I am not trying to make
> relay
> agent dictate policy, I just want to express 
> that the information the link-address provides is per-link, and the
> information that lin-selection option provides can be not only 
> per-link,but also per-client.
> 
> B.R.
> Amy 
> 
> E-mail: [email-masked]
> 
> 
>  
> 
> > From: Bud Millwood [mailto:[email-masked]] 
> > Sent: Thursday, September 21, 2006 4:03 PM
> > To: [email-masked]
> > Subject: Re: [dhcwg] [New I-D] DHCPv6 Relay Agent Link 
> > Selection(RALS) Option
> > 
> > On Wednesday 20 September 2006 17:14, David W. Hankins wrote:
> > > On Wed, Sep 20, 2006 at 04:51:41PM +0800, Amy wrote:
> > > >     But for some access policy, client A can not be 
> assigned the 
> > > > address in prefix A, client B can not be assigned the 
> address in 
> > > > prefix B. And in this case, onlu using link-address is 
> > not sufficient.
> > >
> > > Traditionally, when DHCPv4 installations have been 
> > presented with this 
> > > problem, the determination of which subnet to allocate to 
> > the client 
> > > has been made on the server side.
> > >
> > > That is, the server identifies the client (by identifier or 
> > contents 
> > > of some options the client (or relay!) supplies or similar) and 
> > > allocates an address the client 'is permitted'.  In ISC 
> > DHCP we call 
> > > these 'permit/deny' statements, and it is generally done by 
> > > 'class'ifying the clients into distinct groups first.
> > >
> > >
> > > There aren't any DHCPv6 traditions quite yet, but is there 
> > some reason 
> > > you think this old DHCPv4 model is not going to serve us 
> in DHCPv6?
> > >
> > > It's my opinion that it would be easier to configure the 
> > (small number
> > > of) DHCP Servers to do what is desired in this situation, 
> > and harder 
> > > to configure the (larger number of) relays to produce the 
> > right subnet 
> > > for each client.
> > 
> > I'd like to weigh in here and say that I generally agree with 
> > your conclusions David. It's not a bad thing for a 
> > client/relay to provide a server with as much contextual 
> > information as possible, but there should be a distinction 
> > between providing contextual information and trying to 
> > dictate policy. And I don't think relays should be dictating policy.
> > 
> > - Bud
> > 
> > Bud Millwood
> > Weird Solutions, Inc.
> > http://www.weird-solutions.com
> > tel: +46 8 758 3700
> > fax: +46 8 758 3687
> > mailto:[email-masked]
> >

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Thu, 28 Sep 2006 14:54:01 -0400

Fred:

Just to be sure - I was talking only about the link-address field. That
is where a link-local address is useless.

The peer-address field contains the IPv6 source address of the received
client's message or RELAY-FORW from the previous relay. That can be
anything (link-local, etc) -- it is whatever the sender used, period.

- Bernie

-----Original Message-----
From: Templin, Fred L [mailto:[email-masked]] 
Sent: Thursday, September 28, 2006 2:45 PM
To: Bernie Volz (volz); Amy
Cc: [email-masked]
Subject: RE: [dhcwg] [New I-D] DHCPv6 Relay Agent Link Selection(RALS)
Option

> In other forums there has been some discussions as to whether to place
a
> link-local address into this field, but IMHO I think that is a bad
idea
> as it conveys no information (at least not to the server or other
> relays) and may not even be useful to the relay itself (such as if
there
> are multiple point-to-point links) -- the relay can use the
Interface-ID
> to specify what it needs.

I think it needs *both* the link-local (or loopback) address
and the Interface-ID option. But, the address would be gotten
from the "peer-address" field and not the "link-address" field;
right? I don't want to wander too far off-topic, but the RAAN
draft might possibly say something about the server including
Interface-ID options when necessary too.

Thanks - Fred
[email-masked]

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Thu, 28 Sep 2006 14:55:40 -0400

>I don't want to wander too far off-topic, but the RAAN

Huh? RFC 3315 already requires that the Interface-ID option from a
RELAY-FORW to be echoed back to the relay in a RELAY-REPLY. I don't see
why the RAAN draft has to say anything about that option.

- Bernie

-----Original Message-----
From: Templin, Fred L [mailto:[email-masked]] 
Sent: Thursday, September 28, 2006 2:45 PM
To: Bernie Volz (volz); Amy
Cc: [email-masked]
Subject: RE: [dhcwg] [New I-D] DHCPv6 Relay Agent Link Selection(RALS)
Option

a
idea
there
Interface-ID

Thanks - Fred