MCNS Telco Return DHCP Messaging

bbeser@usr.com Tue, 15 April 1997 17:10 UTC

Received: from cnri by ietf.org id aa02593; 15 Apr 97 13:10 EDT
Received: from marge.bucknell.edu by CNRI.Reston.VA.US id aa15194; 15 Apr 97 13:10 EDT
Received: from reef.bucknell.edu by mail.bucknell.edu; (5.65v3.2/1.1.8.2/17Jul96-0109PM) id AA15241; Tue, 15 Apr 1997 11:56:35 -0400
Date: Tue, 15 Apr 1997 11:56:35 -0400
Message-Id: <35399260.3000@usr.com>
Errors-To: droms@bucknell.edu
Reply-To: dhcp-v4@bucknell.edu
Originator: dhcp-v4@bucknell.edu
Sender: dhcp-v4@bucknell.edu
Precedence: bulk
From: bbeser@usr.com
To: Multiple recipients of list <dhcp-v4@bucknell.edu>
Subject: MCNS Telco Return DHCP Messaging
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
X-Comment: Discussion of DHCP for IPv4
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
Mime-Version: 1.0

I would like to get ideas/comments/problems about the scheme that I am 
currently working on:
     
     The MCNS (Multimedia Cable Network System) published the Cable Modem 
     Telephony Return Interface Specification. The specification is 
     different than the two way specification, since the downstream and 
     upstream signals flow through different nets. 
     
     
                              tv cable (downstream)
                CMTS ---------------------------------> CM
                ^                                       |
                |                                       |
                | internet                              |
                |                                       |
                |    ordinary telephone modem (upstream)|
                TRAC<-----------------------------------+
     
     
           CMTS: Cable Modem Termination System
           CM:   Cable Modem
           TRAC: Telephone Return Access Concentrator
     
     
     When the DHCP_discover message is send it passes through the TRAC and 
     reaches the DHCP server. But the return path is different. The trick 
     to make DHCP_offer reach CM via CMTS is:
     
          When CM generates DHCPDISCOVER it fills the 'giaddr' with the 
          address of CMTS. The DHCP proxies (if any) relay the message to 
          DHCP server without changing the 'giaddr'. DHCP server sends the 
          offer to 'giaddr' (CMTS). And CMTS sends the DHCPOFFER to CM.
          
Is there any DHCP server/proxy implementation that the above method will 
not work?

Do you see any problems?

All ideas/comments/problem scenarios are welcome.

Burcak Beser                    US Robotics
bbeser@usr.com                  8100 McCormick Blvd, Skokie, IL, 60076-2999

Note: Below, I attached the relevant portion of the specification.
     
     ---
     
     Perform DHCP Query
     
     When the CM has established an IP link to the TRAC via the PPP 
     session, it MUST transmit a DHCPDISCOVER message to the TRAC as 
     described in the following sections.
     
     DHCP Process
     
     The DHCP process is outlined in Figure 1. This figure assumes a DHCP 
     proxy between the TRAC and the DHCP server, although this proxy is not 
     required. 
     
     Note: The CM MUST use information from the TSI message in the DHCP 
     process. This message comes at a periodic rate at the control of the 
     CMTS.
     
        CM              TRAC       DHCP Proxy      DHCP Server        CMTS
        _______         ______     __________      ___________        ____
     CM gets CMTS address                       
     for 'gi' from TSI                  |               |               |
        |       discover         discover               |               |
        |-------------->        (broadcast)             |               |
        |               ---------------->        discover           Offer
        |               |               ---------------->(unicast to CMTS)
        |               |               |               ---------------->
        |               Offer (unicast to 'yiaddr' at 'chaddr')         |
        <---------------------------------------------------------------
        <-----------    .               |               |               |
        <----------- (Other Offers)     |               |               |
        |               |               |               |               |
     CM chooses offer   |               |               |               |
        Request (w/ 'server id')        |               |               |
        |-------------->          Request               |               |
        |               |       (broadcast)             |               |
        |               ---------------->         request               |
        |               |               ---------------->              ACK
        |               |               |               | (unicast to CMTS)
        |               |               |               ---------------->
        |               ACK (unicast to 'yiaddr' at 'chaddr')           |
        <----------------------------------------------------------------
        |               |               |               |    CMTS updates 
        |                                                 forwarding tables 
                                                                 
     Data Returned:
        IP Address
        Subnet Mask
        TFTP Server Address
        TFTP Filename
        Lease Time
     
                        Figure 1. DHCP Process
     
     
     The steps in the process are:
     1. The CM generates a DHCPDISCOVER message in which 'giaddr' is filled 
     with the address of CMTS (the address is gained from tv cable in TSI 
     message) fields and sends the message up the PPP link to the TRAC.
     
     2. The TRAC broadcasts the DHCPDISCOVER message on its local network.
     
     3. The DHCP proxy recognizes the discovery message, and forwards it 
     to a configured interface. Since the 'giaddr' field is already 
     non-zero, the proxy leaves the field intact.
     
     4. The DHCP server receives the discovery message, and generates a 
     DHCPOFFER message. It sends the offer to the address specified in 
     the 'giaddr' field, which is the downstream channel IP address.
     
     5. The CMTS receives the DHCPOFFER message. It examines the 'yiaddr' 
     and 'chaddr' fields, and sends the offer message down the cable plant 
     to these IP and MAC addresses, respectively. If the BROADCAST bit in 
     the 'flags' field is set to one, the CMTS MUST send the downstream 
     packet to the broadcast IP address (255.255.255.255), instead of 
     the address specified in 'yiaddr'. The CM MUST use the MAC address 
     specified in 'chaddr' even if the BROADCAST bit is set. The CMTS 
     MUST NOT update its ARP or routing tables based upon this 'yiaddr' 
     'chaddr' pair.
     
     6. The CM receives one or more offer messages. It chooses an offer, 
     and generates a DHCPREQUEST message. The request message MUST have 
     all fields set as specified in section 3.4.4.2 for the discovery 
     message, except that it MUST also set the 'server identifier' 
     option to the value returned in the accepted offer message. The 
     'secs' field MUST be set to the same value as in the original 
     discovery message. The request message MUST be sent up the PPP link, 
     destined to the broadcast IP address (255.255.255.255).
     
     7. The TRAC broadcasts the request message on its local network.
     
     8. The DHCP proxy recognizes the DHCPREQUEST message, and forwards 
     it to a configured interface. Since the 'giaddr' field is already 
     non-zero, the proxy leaves the field intact.
     
     9. The DHCP server receives the request message, and generates a 
     DHCPACK message. It sends the offer to the address specified in 
     the 'giaddr' field, which is the downstream channel IP address.
     
     10. The CMTS receives the DHCPACK message. It examines the 'yiaddr' 
     and 'chaddr' fields, and updates its routing and ARP tables to 
     reflect the address pairing. It then sends the offer message down 
     the cable plant to these IP and MAC addresses, respectively. If the 
     BROADCAST bit in the 'flags' field is set to one, the CMTS MUST 
     send the downstream packet to the broadcast IP address 
     (255.255.255.255), instead of the address specified in 'yiaddr'. 
     The CM MUST use the MAC address specified in 'chaddr' even if the 
     BROADCAST bit is set.
     
     11. The CM receives the DHCPACK message. 
     
     12. In the event that the CM is not compatible with the configuration 
     received in the DHCPACK message, the CM MAY generate a DHCPDECLINE 
     message, per [RFC-1541], and transmit it up the PPP link.
     
     13. On seeing a DHCPDECLINE message the CMTS MUST examine the 'yiaddr' 
     and 'chaddr' fields, and update its routing and ARP tables to flush 
     any invalid pairing.
     
     Upon completion of these steps, the CMTS has a valid IP/MAC address 
     pair in its forwarding tables, and the CM has all parameters 
     necessary to proceed to the next phase of initialization, the 
     TFTP of the configuration file.
     
     If an IP address is returned that is different from the IP address 
     requested by the CM in the DHCP OFFER, the CM MUST accept the DHCP 
     returned address as the CM host IP address. The CM MUST continue to 
     use the address negotiated by IPCP for any packets which should 
     use the PPP link for a return path. The CM MUST use its DHCP 
     returned address for all communication on the broadband media. 
     
     DHCP Discovery and Request Message
     
     The DHCP Discover and Request IP packets:
       MUST be IP UDP packets.
       MUST be addressed to the IP broadcast address (255.255.255.255).
       MUST be formatted per Figure 1 in [RFC-1541]
     
     The CM MUST construct the DHCP message as follows:
       The 'op' field MUST be set to BOOTREQUEST.
       The 'htype' field MUST be set to 1 (10Mb/s Ethernet)
       The 'hlen' field MUST be set to 6.
       The 'hops' field MUST be set to zero.
       The BROADCAST bit in the 'flags' field SHOULD be set to 0.
       If the CM has previously been assigned an IP address, it SHOULD 
     put this address in the 'ciaddr' field. If the CM has previously 
     assigned an IP address by DHCP, and also has been assigned an IP 
     address via IPCP, the CM SHOULD place the previous DHCP assigned 
     address in the 'ciaddr' field.
       The CM MUST place the Downstream Channel IP address, obtained from 
     the TSI  message on the cable downstream, in the 'giaddr' field.
       The 'chaddr' field MUST contain the 48- bit CM LAN MAC address.
     
     DHCP Offer and Acknowledge Message
     The following information is returned in the DHCP offer, and MUST 
     be used by the CM:
       The TFTP server address is returned in the 'siaddr' field.
       The configuration filename is returned in the 'file' field.
       The CM IP address is returned in the 'yiaddr'.
       The DHCP server identifier is returned in the 'server identifier' 
     option of the DHCPOFFER message. 
     The server identifier may not be present in the DHCPACK message.
     
     The DCHP OFFER MAY be authenticated if the DHCP authenticate parameter 
     in the TCD message is set to TRUE(1).