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, 06 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).
- MCNS Telco Return DHCP Messaging bbeser
- Re: MCNS Telco Return DHCP Messaging Mike Carney
- Re: MCNS Telco Return DHCP Messaging Michael W. Patrick