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

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

It isn't clear what should be done (by a relay and by servers) when the
link-address is all 0's.

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.

Persumably if this does occur (link-address is 0), the server must rely
on other mechanisms to determine the client's link or, worst case, drop
(or reject) the client's requests.

- Bernie

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

About all of the "link-address" discussion, I see a potential
use-case where all of the relays in a chain between the client
and server would have no global or site-scoped addresses at all
and as such would have to place a link-local address in the
peer-address field when relaying the client/server exchanges.
(When the client and relay reside on the same device, the relay
may even have to place the the loopback address (::1) in the
peer-address field.)

In such cases, the relay would include an Interface-ID option
to identify the interface on which the message to be relayed
was received. I don't see anything in (RFC3315, Section 20)
that precludes this, but the language could possibly be made
more clear and/or explicit in an RFC3315(bis) effort. For
example, the final sentence in (RFC3315, Section 20.1.1)
doesn't make sense when there is no global/site-scoped
address available to place in "link-address".

As input to the RALS draft, I agree with the other expressed
concerns about policy in the relay agents; "link-address" is
just one piece of information used by the server to select
addresses/prefixes for assignment to an IA per (RFC3315,
Section 11).

Fred
[email-masked]    

________________________________

From: Bernie Volz (volz) [mailto:[email-masked]] 
Sent: Wednesday, September 20, 2006 5:38 AM
To: Amy
Cc: [email-masked]
Subject: RE: [dhcwg] [New I-D] DHCPv6 Relay Agent Link Selection(RALS)
Option

To do that, I would suggest you use other options from the relay
(remote-id, subscriber-id, interface-id, ...) and or client.
 
Or, if a client is only to get an address on a single prefix, don't
configure all three prefixes to be on the same link. Note that the
link-address field could be Prefix A, Prefix B, or Prefix C.
 
We can certainly always dream up cases where new options might solve a
potential problem, but we first need to assure that this is a real
problem and that there aren't other ways to accomplish the same goals.
 
Your draft does not give sufficient reason and motivation for a new
option.
 
In the introduction, you state:
 
   When MN powers on or connects to a NETLMM domain, the MAG includes
   the identifier of the Local Mobility Anchor(LMA) that is in charge of
   serving that MN in the DHCPv6 Relay-forward message, so that the
   DHCPv6 server can select the IP address accordingly(e.g. from the IP
   subnet of the LMA).

So, where it this information placed? In in the link-address field?
remote-id option? subscriber-id option? interface-id option?
Vendor-specific Information option? Why can't this information be used
(or extended to include the information to be used) to select the proper
prefixes for a client?
 
- Bernie
 
________________________________

From: Amy [mailto:[email-masked]] 
Sent: Wednesday, September 20, 2006 4:52 AM
To: Bernie Volz (volz)
Cc: [email-masked]
Subject: RE: [dhcwg] [New I-D] DHCPv6 Relay Agent Link Selection(RALS)
Option

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

________________________________

	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: "Templin, Fred L" <[email-masked]>
Date: Thu, 28 Sep 2006 11:44:31 -0700

> 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