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 OAA19089 for ; Wed, 8 May 2002 14:06:26 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA18991 for dhcwg-archive@odin.ietf.org; Wed, 8 May 2002 14:06:34 -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 OAA18846; Wed, 8 May 2002 14:03:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA18819 for ; Wed, 8 May 2002 14:03:19 -0400 (EDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18999 for ; Wed, 8 May 2002 14:03:06 -0400 (EDT) Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g48I3El20607 for ; Wed, 8 May 2002 13:03:14 -0500 (CDT) Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id g48I3Ds08867 for ; Wed, 8 May 2002 13:03:13 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Wed May 08 13:03:13 2002 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 8 May 2002 13:03:13 -0500 Message-ID: <66F66129A77AD411B76200508B65AC69B4D3C3@EAMBUNT705> From: "Bernie Volz (EUD)" To: "'Thomas Narten'" , dhcwg@ietf.org Subject: RE: [dhcwg] dhcpv6-24: Interface-ID option Date: Wed, 8 May 2002 13:03:09 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1F6BA.9CD9BD70" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1F6BA.9CD9BD70 Content-Type: text/plain; charset="iso-8859-1" Thomas: The link-address field is always used by the server to determine what link the client is on. The interface-id is for use by the relay to help it return the response from the server to the client. The reasons for having this include: - It could be that the link-address field isn't specific enough. Perhaps there are a bunch of circuits all with one prefix (the link-address) but the response must be sent to the client over the correct circuit. Hence, the circuit information can be stored by the relay in the interface-id option. - Even if the link-address is sufficient, the interface-id could be used as an optimization by the relay. So: >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? No, there must always be a valid link-address. It just isn't specific enough. > 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. Agreed. This is wrong and needs to be fixed. It should say: The relay agent puts a global or site-scoped address with a prefix assigned to the link on which the client should be assigned an address in the link-address field regardless of whether the relay agent includes an Interface-id option in the Relay-forward message. (This is essentially the text in 20.1). >Shouldn't the first MAY be a MUST? I.e., the link-address field >contains no useful information. No. The server only needs to the link-address to do address assignment in general. There could be instances where a specific relay/server arrangement exists and the server might want to consider the Interface-ID value (for classing, access control, etc). >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? I think it best to keep it variable-length since relays may use this for optimization reasons. For example, in 3G specs we were thinking of allowing the PDP-Context number on the GGSN to be carried in this field (this speeds the return of the reply to the client). While this might fit into 32-bits, why force it? - Bernie -----Original Message----- From: Thomas Narten [mailto:narten@us.ibm.com] Sent: Wednesday, May 08, 2002 11:10 AM To: dhcwg@ietf.org Subject: [dhcwg] dhcpv6-24: Interface-ID option > 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? Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C1F6BA.9CD9BD70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] dhcpv6-24: Interface-ID option

Thomas:

The link-address field is always used by the server = to determine what link the client is on.

The interface-id is for use by the relay to help it = return the response from the server to the client.

The reasons for having this include:
- It could be that the link-address field isn't = specific enough. Perhaps there are a bunch of circuits all with one = prefix (the link-address) but the response must be sent to the client = over the correct circuit. Hence, the circuit information can be stored = by the relay in the interface-id option.

- Even if the link-address is sufficient, the = interface-id could be used as an optimization by the relay.

So:

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

No, there must always be a valid link-address. It = just isn't specific enough.

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

Agreed. This is wrong and needs to be fixed. It = should say:

   The relay agent puts a global or = site-scoped address with a prefix
   assigned to the link on which the = client should be assigned an
   address in the link-address field = regardless of whether the relay
   agent includes an Interface-id option = in the Relay-forward message.

(This is essentially the text in 20.1).

>Shouldn't the first MAY be a MUST? I.e., the = link-address field
>contains no useful information.

No. The server only needs to the link-address to do = address assignment in general. There could be instances where a = specific relay/server arrangement exists and the server might want to = consider the Interface-ID value (for classing, access control, = etc).

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

I think it best to keep it variable-length since = relays may use this for optimization reasons. For example, in 3G specs = we were thinking of allowing the PDP-Context number on the GGSN to be = carried in this field (this speeds the return of the reply to the = client). While this might fit into 32-bits, why force it?

- Bernie

-----Original Message-----
From: Thomas Narten [mailto:narten@us.ibm.com]
Sent: Wednesday, May 08, 2002 11:10 AM
To: dhcwg@ietf.org
Subject: [dhcwg] dhcpv6-24: Interface-ID = option


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

Thomas

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

------_=_NextPart_001_01C1F6BA.9CD9BD70-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg