[dhcwg] dhcpv6-24: Interface-ID option

Thomas Narten <narten@us.ibm.com> Wed, 08 May 2002 15:11 UTC

Received: from optimus.ietf.org (ietf.org [] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11416 for <dhcwg-archive@odin.ietf.org>; Wed, 8 May 2002 11:11:00 -0400 (EDT)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA04599 for dhcwg-archive@odin.ietf.org; Wed, 8 May 2002 11:11:08 -0400 (EDT)
Received: from optimus.ietf.org (localhost []) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04419; Wed, 8 May 2002 11:09:27 -0400 (EDT)
Received: from ietf.org (odin []) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04390 for <dhcwg@optimus.ietf.org>; Wed, 8 May 2002 11:09:25 -0400 (EDT)
Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com []) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11246 for <dhcwg@ietf.org>; Wed, 8 May 2002 11:09:16 -0400 (EDT)
Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.us.ibm.com []) by e21.nc.us.ibm.com (8.12.2/8.12.2) with ESMTP id g48F9P64142268 for <dhcwg@ietf.org>; Wed, 8 May 2002 11:09:25 -0400
Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com []) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g48F9OQ176822 for <dhcwg@ietf.org>; Wed, 8 May 2002 11:09:24 -0400
Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id g48F9mY19283 for <dhcwg@ietf.org>; Wed, 8 May 2002 11:09:48 -0400
Message-Id: <200205081509.g48F9mY19283@rotala.raleigh.ibm.com>
To: dhcwg@ietf.org
Date: Wed, 08 May 2002 11:09:48 -0400
From: Thomas Narten <narten@us.ibm.com>
Subject: [dhcwg] dhcpv6-24: Interface-ID option
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

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

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

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.

>       interface-id         An opaque value of arbitrary length generated
>                            by the relay agent to identify one of the
>                            relay agent's interfaces

Any reaosn not to make this 32 bits? the IPv6 API already has 32-bit
interface IDs. Is there any reason to make it larger?


dhcwg mailing list