Subject: RE: Circuit ID and Remote ID options

From: "Thirumalesh Bhat" <[email-masked]>
Date: Wed, 18 Jul 2001 19:25:43 -0700

Yes - I think we should have a separate draft for options. We have a
list of options that we need for DHCPv6. A preliminary list is as
follows:

15 Domain Name       NOT Present in DHCPv6 Draft

43 Vendor Specific   NOT Present in DHCPv6 Draft

60 Class Identifier  NOT Present in DHCPv6 Draft

77 User-Class        NOT Present in DHCPv6 Draft

81 Client FQDN       NOT Present in DHCPv6 Draft

CSR Classless routes - option TBD

thx

-----Original Message-----
From: Bernie Volz (EUD) [mailto:[email-masked]] 
Sent: Wednesday, July 18, 2001 7:49 AM
To: DHCPv6 discussion list
Subject: RE: Circuit ID and Remote ID options

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: Jim Bound <[email-masked]>
Date: Thu, 19 Jul 2001 01:07:43 -0400 (EDT)

this is good list.  the ones we have now must be there too.

/jim