Re: MCNS Telco Return DHCP Messaging

"Michael W. Patrick" <mpatrick@dma.isg.mot.com> Tue, 06 May 1997 18:11 UTC

Received: from cnri by ietf.org id aa00821; 6 May 97 14:11 EDT
Received: from marge.bucknell.edu by CNRI.Reston.VA.US id aa15464; 6 May 97 14:11 EDT
Received: from reef.bucknell.edu by mail.bucknell.edu; (5.65v3.2/1.1.8.2/17Jul96-0109PM) id AA23219; Tue, 6 May 1997 13:39:00 -0400
Date: Tue, 6 May 1997 13:39:00 -0400
Message-Id: <199705061634.MAA07716@prospero.dma.isg.mot.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: "Michael W. Patrick" <mpatrick@dma.isg.mot.com>
To: Multiple recipients of list <dhcp-v4@bucknell.edu>
Subject: Re: MCNS Telco Return DHCP Messaging
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
X-Comment: Discussion of DHCP for IPv4

This is in response to Burcak Beser's 4/15 email proposing operation
of DHCP from a dial-return MCNS modem.

We at Motorola have a number of significant issues with the (still
private)  MCNS dial return spec, and we will be responding to these in
the appropriate MCNS forum.  For now, howewever, I'd like to give
you our feedback on the operation of DHCP in a dial-return Cable Modem (CM).

Just to clarify for the dhcp group, the procedure Burcak describes
is designed to allocate an address for the CABLE MODEM (CM)
ITSELF, not for customer premise equipment (CPE) attached to the 
CM.   

I think it's useful to introduce the concept of separate Logical IP
Subnets (LISs) for the CM's (the "CMTS-LIS"), the TRAC-assigned IP
subnet ("TRAC-LIS") , and subscriber's CPE attached to the CM The
CMTS-LIS is often a private "net 10" net, since there is no
requirements for CMs to be globally addressable.  The CMTS will
forward IP packets down the cable for the CMTS-LIS and the CPE LIS
(i.e. to customers and to the modems themselves). The TRAC (a RAS)
will forward IP packets down to the "TRAC-LIS", which is assigned via
the IPCP protocol in PPP.  

Using this terminology, PPP's IPCP session gives the CM its
IP address on the TRAC-LIS, and the reason the CM needs to do
a DHCP is to get an IP address on the CMTS-LIS.  The CM has IP addrs
on both the TRAC-LIS and CMTS-LIS.  

Comments:

1.  Our first comment is that you (and we, and MCNS) need to 
    specify exactly what happens to the DHCP packets from the CPE.
    The MCNS dial spec specifies that the CM acts as a BOOTP Relay 
    agent (sec 2.6.5.1, pg. 15), but provides no further
    specification.  A major problem is that a relay agent needs to
    be configured with the IP addresses to which to forward the packets.

    If it was your intention that the CM act as a DHCP relay agent for
    the CPE DHCP broadcasts as well, then you need to add
    configuration to the CM to give it the list of DHCP servers to 
    which to UNICAST the forwarded DHCP packets.  This could be in the
    configuration file that the CMs download once they get their
    own IP address.

2.  We feel it is a major requirement that the TRAC and CMTS NOT
    be required to be on the same broadcast lan.  Your approach seems to require
    this.  We feel it is a requirement, in fact, that the TRAC
    be a RAS from a commercial dial-up internet  service provider, at
    that ISP's data center.  The CMTS, of course, is at the cable head
    end, which will be geographically remote from the ISP RAS location.

    A corollary of this is the added requirement that the dial architecture
    support an arbitrary Internet routed hop between the TRAC and CMTS.
    
    As specified, you don't permit standard DHCP relay agents to be
    used between the TRAC and the DHCP server. 
    In our opinion, you either need to make the CM perform ALL functions
    of relay agent (fill in giaddr AND unicast to server) or
    NONE of them (broadcast DHCP-discover with giaddr as zero).
    By only partially implementing the relay agent in the CM (filling
    in giaddr but broadcasting rather than unicasting), you are
    specifying non-standard behaviour that can't be met by standard
    relay agents.

    RFC 1542 makes it clear that BOOTP/DHCP relay agents must see
    an incoming giaddr of zero:

            If the relay agent does decide to relay the request, it MUST examine
            the 'giaddr' ("gateway" IP address) field.  If this field is zero,
            the relay agent MUST fill this field with the IP address of the
            interface on which the request was received.  If the interface has
            more than one IP address logically associated with it, the relay
            agent SHOULD choose one IP address associated with that interface and
            use it consistently for all BOOTP messages it relays.  If the
            'giaddr' field contains some non-zero value, the 'giaddr' field MUST
            NOT be modified.  The relay agent MUST NOT, under any circumstances,
            fill the 'giaddr' field with a broadcast address as is suggested in
            [1] (Section 8, sixth paragraph).


    So if the CM fills in giaddr and broadcasts it, any
    standards-compliant relay server will NOT forward it to the 
    desired DHCP server.  

    If we're going to keep CM's as relay agents, the proper fix for the
    CM's own DHCP request, I believe, is to have the CMTS broadcast the
    IP addresses of a list of DHCP servers that will assign the CM's
    IP address.  Note that this may or may not be the same DHCP
    server assigned IP addresses for CPE, so the CPE-LIS DHCP servers
    should be obtained from the modem config file.

3.  That said, we at Motorola disagree that the proper dial return
    CM architecture should call for a dhcp relay agent in the CM.

    We believe that a dial return CM should establish a MAC-level
    tunnel from the CM to the CMTS.  The dial-return CM can then act
    exactly like the cable-return CM as a bridging, rather than IP
    forwarding model:
        - MAC formats remain the same.  The cable-only MAC messages
          e.g. for ranging and upsteam bandwidth control are simply
          omitted.
        - ARP functionality remains the same.  As you know, the 
          problem with the dial return spec is that the PPP link 
          forwards IP only, and doesn't forwared ARP.  The dial return
          spec completely differs from the hfc-return spec in that
          it requires ARP proxy at both the CM and CMTS.  This is
          problematic for CMTS system that have a mixture of dial
          and HFC return modems, a major requirement.    
        - This permits CPE-originated multicasts to be handled in the
          same manner has HFC. 
        - This  avoids any anti-spoofing filters in the TRAC or the
          TRACs internet connection.  That's because the PPP
          upstream always has the PPP-LIS as the source IP of the
          "outer" IP packet; the CPE's source address (on the CPE-LIS)
          is the "inner" IP packet that is forwarded to the internet
          from the CMTS.
        - By tunnelling to the CMTS, you permit it to implement
          policies on the forwarding of IP broadcasts/multicasts,
          e.g. virtual LANs, virtual LISs, virtual private networks,
          etc.  All these things can be done with a cable-return
          CMTS, but CANT be done with the proposed dial-return
          architectures, since the CMTS never sees upstream data.        
        - The CM's DHCP exchange, then, would be tunnelled to the 
          CMTS.  The CM should act as a regular client, broadcasting
          its DISCOVER and REQUEST packets.

    The major disadvantage of tunneling all CPE packets from CM to
    CMTS, of course, is the higher latency and performance loss.

    We propose as an option that the modem implement an IP filter
    that allows as an optimization that UNICAST IP packets 
    be able to be forwarded in the PPP layer from CM to TRAC.
    All MAC broadcasts (like ARP!) and IP multi/broadcasts (like
    multicast, RIP, IGMP, ICMP broadcasts, etc) be forwarded through
    the tunnel.    The cable operator can then be given the option
    to tradeoff the two upstream approaches (tunnelled through CMTS vs. direct
    through TRAC).

    The appropriate tunneling protocol is an item for discussion,
    but data-only L2TP comes to mind as a reasonable choice.

    With a layer 2 CM-to-CMTS tunnel, then, a standard DHCP relay
    agent at the CMTS (either co-located with it, or implemented
    in a separate router of a router/CMTS combo) will do DHCP
    relay for the CPE's DHCP.  The CM would then act just like 
    a CPE host, originating a DHCP broadcast with zero giaddr.
    
    We strongly believe that the same IP forwarding model
    (bridging in the CM) should be used for both dial-return CMs
    and hfc-return CMs.    We shouldn't have a bridging model
    for hfc-return CMs, and an IP-forwarding model (with ARP spoofing)
    for dial-return CMs.  For example, doesn't the CM have to 
    decrement the hop count (since two dial CMs could be on the same
    customer LAN).

4.  As a related issue, can the RAS vendors please respond on the
    email as to how they treat IP broadcasts, and how they
    recognize and treat subnet-specific IP broadcasts?
    4.1: Are these broadcasts sent back down other dial-in ports?
        (I'd hope not).
    4.2: Are these IP broadcasts ALWAYS copied onto the RAS's LAN?
        (VERY important question. Vendors?)
    4.3: Under what circumstances does the RAS decrement the hop count?

Regards,
-mike
------------------------------------------------------------------------
Michael W. Patrick  Motorola ISG/NSD               20 Cabot Rd, MS M4-30
mpatrick@dma.isg.mot.com  (508) 261-5707              Mansfield MA 02048



Beser's 4/15 email, for reference:

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