RE: [dhcwg] dhcpv6-24: Interface-ID option

"Bernie Volz (EUD)" <Bernie.Volz@am1.ericsson.se> Wed, 15 May 2002 19:41 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19909 for <dhcwg-archive@odin.ietf.org>; Wed, 15 May 2002 15:41:23 -0400 (EDT)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA25608 for dhcwg-archive@odin.ietf.org; Wed, 15 May 2002 15:41:37 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA24503; Wed, 15 May 2002 15:31:46 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA24484 for <dhcwg@ns.ietf.org>; Wed, 15 May 2002 15:31:45 -0400 (EDT)
Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19265 for <dhcwg@ietf.org>; Wed, 15 May 2002 15:31:29 -0400 (EDT)
Received: from mr7.exu.ericsson.se (mr7att.ericy.com [138.85.224.158]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g4FJVDi25519 for <dhcwg@ietf.org>; Wed, 15 May 2002 14:31:13 -0500 (CDT)
Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with SMTP id g4FJVDQ22271 for <dhcwg@ietf.org>; Wed, 15 May 2002 14:31:13 -0500 (CDT)
Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt749 ; Wed May 15 14:31:12 2002 -0500
Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id <KVLD5J9T>; Wed, 15 May 2002 14:31:12 -0500
Message-ID: <66F66129A77AD411B76200508B65AC69B4D427@EAMBUNT705>
From: "Bernie Volz (EUD)" <Bernie.Volz@am1.ericsson.se>
To: "'Bound, Jim'" <Jim.Bound@hp.com>, Ralph Droms <rdroms@cisco.com>, dhcwg@ietf.org
Subject: RE: [dhcwg] dhcpv6-24: Interface-ID option
Date: Wed, 15 May 2002 14:31:07 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1FC47.0FB7DCF0"
Sender: dhcwg-admin@ietf.org
Errors-To: dhcwg-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: <dhcwg.ietf.org>
X-BeenThere: dhcwg@ietf.org

The link-address field in the Relay-Forw header is not the client's address. It is the a global or site address assigned to the relay for the link on which the client's message was received (in some applications, it could even be the "subnet selection" value as in DHCPv4).

- Bernie

-----Original Message-----
From: Bound, Jim [mailto:Jim.Bound@hp.com]
Sent: Wednesday, May 15, 2002 3:28 PM
To: Ralph Droms; dhcwg@ietf.org
Subject: RE: [dhcwg] dhcpv6-24: Interface-ID option


the one place we need to be careful with the interface ID is if the link-address is link-local from the client.  then the server has no clue regardless of the interface id. The server must look at the IP header from the relay to figure everything out.  

we should put the required scoped value of the address on the interface of the relay in the link address.  or else the relay now needs to maintain state to find the client.

I am not sure what the interface id is buying us but it is useful field for the future for sure I can think of many reasons such as a future partitioned IPv6 link.

/jim

> -----Original Message-----
> From: Ralph Droms [mailto:rdroms@cisco.com]
> Sent: Wednesday, May 15, 2002 1:00 PM
> To: dhcwg@ietf.org
> Subject: Re: [dhcwg] dhcpv6-24: Interface-ID option
> 
> 
> At 11:09 AM 5/8/2002 -0400, Thomas Narten wrote:
> > >    If the relay agent cannot use the address in the 
> link-address field
> > >    to identify the interface through which the response 
> to the client
> > >    will be forwarded, the relay agent MUST include an Interface-id
> > >    option (see section 22.19) in the Relay-forward 
> message.  The server
> >
> >I think the interface-id option may be underspecified. If it is
> >included, but there is no valid link-address (which I understand is
> >the reason for defining this particular option), how does the server
> >know which addresses to assign the client? I.e., how does the server
> >know on which link the client is?
> 
> The relay agent always fills in the link-address field even 
> if it also 
> includes an Interface-id option.  Does the text need to be clarified?
> 
> 
> > >    The relay agent puts the client's address in the 
> link-address field
> > >    regardless of whether the relay agent includes an 
> Interface-id option
> > >    in the Relay-forward message.
> >
> >This doesn't seem right to me. I thought that the link-address is
> >supposed to hold the address of the relay agent. Seems wrong to put
> >the client's address in it. The link-address field is what the server
> >uses to figure out which link the client is on (right?). Also, since
> >the client's address is a link-local address, this field doesn't seem
> >to contain useful information for the server in this case.
> 
> This text should be edited to (based on suggested text from Bernie):
> 
>     The relay agent fills in the link-address field as 
> described in the 
> previous
>     paragraph regardless of whether the relay agent includes 
> an Interface-id
>     option in the Relay-forward message.
> 
> 
> > >    Servers MAY use the Interface-ID for parameter 
> assignment policies.
> > >    The Interface-ID SHOULD be considered an opaque value, 
> with policies
> > >    based on exact string match only; that is, the 
> Interface-ID SHOULD
> > >    NOT be internally parsed by the server.
> >
> >Shouldn't the first MAY be a MUST? I.e., the link-address field
> >contains no useful information.
> 
> The link-address field does contain useful information (a 
> site-scoped or 
> global address); the Interface-ID provides additional information.
> 
> >Also, not sure the above is sufficient. Unless the
> >interface-identifier is somehow stable, it's not clear how the server
> >policy could take it into account. There are no words suggesting the
> >interface-identifier needs to be stable.
> 
> OK, we'll add some words about stability.
> 
> 
> > >       interface-id         An opaque value of arbitrary 
> length generated
> > >                            by the relay agent to identify 
> one of the
> > >                            relay agent's interfaces
> >
> >Any reason not to make this 32 bits? the IPv6 API already has 32-bit
> >interface IDs. Is there any reason to make it larger?
> 
> The relay agent may use another value aside from the IPv6 API for the
> interface-id, so we should allow for arbitrary length.
> 
> - Ralph
> 
> 
> 
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www1.ietf.org/mailman/listinfo/dhcwg
> 

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg