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

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Fri, 15 Sep 2006 09:14:54 -0400

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]] 
		> 
		> 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 

		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? 

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

---

From: Amy <[email-masked]>
Date: Wed, 20 Sep 2006 16:51:41 +0800

Hello,Bernie!
    Thanks!
    If I catch your mean correctly. You and I have come to a concent that
the link-address field in current rfc3315 isn't sufficient? 
    Now, the problem is you think there is no requirements to define a new
option, just change the RFC3315 is sufficient.
 
    I think the link-address is just a hint to the server about the LINK
where the client resides on. The information that the link-address can
supply is per-link. But the information that the link-selection option can
supply is not only per-link, but also per-client.
 
    For example:

    Client A ------------ relay A --------- NAS / relay B --------------DHCP
Server
                    |  
                    |
                    |
    Client B -------|
 
    Client A and Client B reside on the same IP link. I assume there is
three subnet prefixes(prefix A, prefix B and prefix C) on this IP link.
 
    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.
 
B.R.
 
Amy Zhao

  _____  

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

  _____  

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.

   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

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

> We posted a new I-D as follows.  We would appreciate your comments. 
> 
>       Title           : DHCPv6 Relay Agent Link Selection(RALS) Option 
>       Author(s)       : Y. Zhao 
>       Filename        : 

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: "David W. Hankins" <[email-masked]>
Date: Wed, 20 Sep 2006 08:14:13 -0700

> 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.

-- 
ISC Training!  October 16-20, 2006, in the San Francisco Bay Area,
covering topics from DNS to DDNS & DHCP.  Email [email-masked].
-- 
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
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Bud Millwood <[email-masked]>
Date: Thu, 21 Sep 2006 10:02:42 +0200

On Wednesday 20 September 2006 17:14, David W. Hankins 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.
>

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: Ted Lemon <[email-masked]>
Date: Thu, 21 Sep 2006 01:16:44 -0700

Bud Millwood wrote:
> It's not a bad thing for a client/relay to provide a server with as 

Yup.

---

From: Amy Zhao <[email-masked]>
Date: Thu, 21 Sep 2006 17:07:13 +0800

Hello!

Thanks.

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
> 
> > >     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.
> >
> > problem, the determination of which subnet to allocate to 
> the client 
> > has been made on the server side.
> >
> > 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?
> >
> 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.