Subject: RE: Circuit ID and Remote ID options

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Wed, 18 Jul 2001 09:48:39 -0500

I think this should be a separate specification. Easier to review/edit and
makes the DHCPv6 specification look less daunting. It also isn't a REQUIRED
part of the protocol.

Please note that giaddr is used in the text and should be changed to DHCPv6
terminology.

I'm also wondering whether it would be easier to just assign a DHCP Relay
Agent Information Option number (16-bit) and use the suboptions per RFC
3046. Though, as the giaddr reference points out, it may require some minor
text to explain how to adapt this RFC to IPv6. 

- Bernie

-----Original Message-----
From: Ralph Droms [mailto:[email-masked]]
Sent: Wednesday, July 18, 2001 9:54 AM
To: DHCPv6 discussion list
Subject: Circuit ID and Remote ID options

Ted has drafted text for the Circuit ID and Remote ID options, which are to 
be used between relay agents and servers.  Two questions: is the text OK 
and do we want to include the text in the base protocol spec?

I'm inclined not to include these two options in the base spec.  Instead, I 
suggest that they, along with other options we know we'll need real soon 
but are not referenced elsewhere in the base spec, be moved to separate 
drafts for consideration in parallel with the base spec I-D.

- Ralph

18.13 Circuit ID Option

    This option MAY be placed in Relay-forward messages by DHCP relay
    agents which terminate switched or permanent circuits.  It encodes
    an agent-local identifier of the circuit on which a DHCP
    client-to-server packet was received.  It is intended for use by
    relay agents in relaying DHCP responses back to the proper circuit.
    Possible values encoded in this field include:

        - Router interface number
        - Switching Hub port number
        - Remote Access Server port number
        - Frame Relay DLCI
        - ATM virtual circuit number
        - Cable Data virtual circuit number

    Servers MAY use the Circuit ID when making address allocation
    decisions and in applying other parameter assignment policies.  The
    Circuit ID SHOULD be considered an opaque value, with policies
    based on exact string match only; that is, the Circuit ID SHOULD
    NOT be internally parsed by the server.   Servers MUST return the
    Circuit ID option in the Relay-reply message that is generated in
    response to a Relay-forward message if this option appears in the
    Relay-forward message.

    Since the Circuit ID is local only to a particular relay agent, a
    circuit ID should be qualified with the giaddr value that
    identifies the relay agent.

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |      OPTION_CIRCUIT_ID        |         option_length         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    .                                                               .
    .                          circuit ID                           .
    .                                                               .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    This corresponds to the DHCPv4 Circuit ID subpoption as described
    in [24].

18.14 Remote ID Option

    This option MAY be sent in Relay-forward messages by DHCP relay
    agents which terminate switched or permanent circuits and have
    mechanisms to identify the remote host end of the circuit.  The
    Remote ID field may be used to encode, for instance:

        -- a "caller ID" telephone number for dial-up connection
        -- a "user name" prompted for by a Remote Access Server
        -- a remote caller ATM address
        -- a "modem ID" of a cable data modem
        -- the remote IP address of a point-to-point link
        -- a remote X.25 address for X.25 connections

    The remote ID MUST be globally unique.

    DHCP servers MAY use this option to select parameters specific to
    particular users, hosts, or subscriber modems.  The option SHOULD
    be considered an opaque value, with policies based on exact string
    match only; that is, the option SHOULD NOT be internally parsed by
    the server.  Servers MUST return the Circuit ID option in the
    Relay-reply message that is generated in response to a
    Relay-forward message if this option appears in the Relay-forward
    message.

    The relay agent MAY use this field to select the circuit on which
    to forward a DHCP reply message.

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |       OPTION_REMOTE_ID        |         option_length         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    .                                                               .
    .                           remote ID                           .
    .                                                               .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    This corresponds to the DHCPv4 Remote ID subpoption as described in
    [24].

---

From: Ted Lemon <[email-masked]>
Date: Wed, 18 Jul 2001 13:49:39 -0700

> makes the DHCPv6 specification look less daunting. It also isn't a REQUIRED

I was under the impression that we were trying to specify options that
we know are needed in the main draft.  If that is not the case, then
it's fine with me if we put them in a seperate draft.

> Please note that giaddr is used in the text and should be changed to DHCPv6

Oops!

> text to explain how to adapt this RFC to IPv6. 

This wouldn't make a whole lot of sense, frankly - the relay mechanism
in DHCPv6 is completely different.  There is no need for a suboption
encapsulation - the relay agent is already encapsulating the client's
packet, so the whole kludge we had to do for DHCPv4 is unnecessary.
RFC3046 mostly describes the kludge, which we don't want people to
even think about in DHCPv6.

			       _MelloN_

---

From: Jim Bound <[email-masked]>
Date: Thu, 19 Jul 2001 00:32:31 -0400 (EDT)

Just to note I like the circuit and route id stuff.  I think it will be
used immediately by implementors.  I don't see harm here?  Unless its
controversial and will hold us up or we need gobs of text and such. But I
am not hearing folks against it?

/jim

---

From: Ted Lemon <[email-masked]>
Date: Wed, 18 Jul 2001 22:29:32 -0700

> am not hearing folks against it?

Works for me, obviously.   :')   I also think it will get immediate
use, so putting it in the base draft, with the fixes that Bernie
suggested is a win.

			       _MelloN_