Re: [dhcwg] DHCP Option for CableLabs Client Configuration

Thomas,

The high level issues you've raised...

1. Suggested text addition to the draft...generally describe how the CCC 
option is used....

"Cablelabs client devices will issue DHCP requests that include options 55 
and 60.  Option 50 will request the CCC option from the DHCP 
server.  Option 60 will specify the specific Cablelabs client type, thus 
directing the DHCP server to populate specific CCC sub-option content in 
its responses.  The details of which CCC sub-options are populated for each 
specific client type are spelled out in the various Cablelabs project 
specifications.  For example, the PacketCable MTA Device Provisioning 
Specification [ref] defines the specific set of CCC sub-options that must 
be populated in DHCP responses to CMs and MTAs in a PacketCable deployment."

The point here is that different Cablelabs client devices will use a 
different set of CCC sub-options.  I don't think we want to get into cross 
pollinating the various specifications.  The CCC option draft describes 
"what" the option is, the specific Cablelabs specs describe "when" and 
"how" its used.

2. General PacketCable provisioning flow (as it relates to the CC 
option).  This is a boiled down version of section 7 of the MTA prov 
spec.  I'm NOT suggesting this gets added to the draft.

PacketCable device provisioning proceeds as follows.

DOCSIS 1.1 provisioning steps:

a. CM issues broadcast discover which includes option 60 of "docsis1.1:..." 
and requests CCC option in option 55.
b. One or more offers arrive at the CM.  The offers MUST include the CCC 
option w/ sub-options 1/2.
c. CM selects one of the offers containing the CCC option and completes the 
DHCP exchange.
d. CM completes the rest of its DOCSIS provisioning process.

The key here is that the access provider's tightly controlled DHCP 
infrastructure sends the CM a specific list of valid, legal, PacketCable 
DHCP/DNS/SNMP server addresses for a specific service 
provider.  PacketCable 1.0 scopes Embedded MTAs only, meaning the CM and 
MTA physically reside in an integrated box.  The CCC sub-option 1/2 info is 
transferred by the CM component to the MTA component (how this occurs is 
implementation specific).

This is the mechanism via which the access provider strictly controls which 
business entities are allowed to offer PacketCable service (or any other 
type of service) over its network. It also permits the access provider to 
direct a specific device to a specific service provider....you can have 
multiple PacketCable service providers on the same access network.

Continuing...

PacketCable 1.0 provisioning steps:

e.MTA issues broadcast discover which includes option 60 of "pktc1.0:..." 
and requests CCC option in option 55.
f. One or more offers arrive at the MTA.  These offers must include the CCC 
option with sub-options 3, 4, 6 (5, 7, 8, 10, 11 are optional) to be 
considered "valid".
g. The MTA selects a valid offer from the set of DHCP servers identified in 
CCC sub-option 1/2.
h. MTA completes the rest of the DHCP exchange
i. MTA completes the rest of the secure provisioning steps

The access providers are assumed to be offering multiple types of services 
(from different business entities) over their data network.  The CCC 
options 1 through 5 are used by the access providers to direct the various 
client types to a restricted set of infrastructure servers that support the 
specific service type from a specific service provider.  It was felt that 
this approach also makes the system a bit more difficult to hack.

4. Port numbers on CCC sub-options 1/2/3/4/5

Don't what more I can add here.  This has been in the architecture since 
day one...additional control for the service providers.  Your comment 
suggesting "if no port number, use DHCP option 6, if port number, use CCC 
sub-option 4/5"... as a developer...I'd rather just deal with the single 
CCC sub-option 4/5 and leave it at that.  The implementation would be 
simpler (for both client and server).

5. Cablelabs specification development process.

Specifcations start out as Works In Progress. Essentially, discussion 
documents.
Following initial agreement by the participants, the WIP goes to a Draft 
status (D0x).  Protoypes are typically developed at this stage.
When everyone is satisfied that the Draft will actually work, the spec goes 
to a Interim stage (I0x).  At this point the spec goes under rigorous 
change control and multiple vendors come out for compliance wave testing at 
the Cablelabs facility (essentially, a rigorous  bake-off).

Its typical that a specification will go through several I0x stages.

Specifically, the PacketCable MTA prov spec is just now coming up on its 
I04 release.  We will be filing change requests on I04 to clean up the 
sections that deal with the CCC option.

Matt Osman from Cablelabs will have to comment if you need more detail here.

Helps ?

Cheers,

At 03:19 PM 7/30/2002 -0400, Thomas Narten wrote:
> > We could add a paragraph or two describing, in general terms, that the 
> DHCP
> > client requests the CCC option and provide option 60 to identify its 
> client
> > type to the server...the server then determines the CCC sub-option content
> > that would be included in responses.
>
>This would be helpful.
>
> > But we would defer to the specific Cablelabs specifications to
> > define the exact sub-option content in the responses. How does that
> > sound ?
>
>Could you give an example? Are you talking about removing all the text
>from the current ID? I'm not sure I'm in favor of that either.
>
> > >Is there ever a reason for the MTA to use a "normal" DNS server
> > >vs. the "TSP DNS"? I would assume not. Thus, the above option appears
> > >redundent with the normal DHC option for identifying DNS servers. Can
> > >someone clarify here if this is/is not the case?
>
> > Again, sub-options 4 and 5 permit port numbers.  Normal DNS options
> >  do not...
>
>Some comments.
>
>First, let's consider the case where the port number version is not
>used, i.e., DNS servers are accessed at the normal port numbers. In
>this case, how does this option differ from option 6 (the standard
>Domain Option)? My sense (from what I understand) is they are the
>same. In that case, I would say use that option and don't even define
>a sub-option that allows specification of the DNS server without a
>port number. No need to define a redundant option.
>
>Second, there has apparently not been an issue in general with the
>Domain Option not specifying an alternate port number, presumably
>because its not required in general. Why is it required in your spec?
>Just saying "it's a requirement" isn't very illuminating.
>
> > >3) It's not immediately clear whether/how the CM uses these
> > >    options. They seem specific to the MTA.  Does the CM use these
> > >    options?
>
> > Per the PacketCable specs, MTA uses sub-option 4/5.  See the provisioning
> > flows in the MTA prov spec (referenced in the draft).
>
>I just looked at the MTA provising draft. It is not at all clear to me
>that the CM needs any of these sub-options. Can you please point me to
>the sections in the document that explain how the CM uses them and
>what specific sub-options it uses?
>
> > >4)
> > >
> > > >      |    9    |         | Reserved for future CableLabs use          |
> > >
> > >I find it odd that this document says "reserved", when the cablelabs
> > >document pretty clearly defines this option and what it means. Please
> > >clarify.
>
> > The PacketCable MTA prov spec is incorrect.  It will be updated soon.
> > Sub-option 9's usage was dropped just prior to the draft's posting.  The
> > draft is correct and authoritative regarding sub-option
> > definitions/syntax.  Any duplication of the draft's text in the 
> PacketCable
> > specs will soon be removed.
>
>OK. But I will note that the classification of the document is
>"ISSUED" (per the cover page), which corresponds to
>
>      "A stable document, which has undergone rigorous member and vendor
>      review and is suitable for product testing and development, cross-vendor
>      interoperability, and for certification testing."
>
>Can you clarify what the next steps for the document are and when it
>will get updated?
>
> > Sub-options 1 and 2 are the mechanism via which the access provider
> > strictly controls which business entities are permitted to offer
> > telephony service over its network.  This is described in the
> > PacketCable MTA prov spec.
>
>Right. In other words, the MTA needs to use a special DNS server and
>get special client-specific configuration. What I don't quite
>understand is why that requires Cablelabs-specific options. This seems
>(mostly) doable with standard DHCP. In that case, I'd prefer that
>approach be used to just defining a bunch of specific (redundant)
>options.
>
>Specifically, if the client includes in its Discover with an "I'm a
>MTA" option, and the DHC servers return an "I'm a MTA DHC server"
>(which the client then selects), this is all fine and consistent with
>DHC. From that point on, the MTA DHC server can send it normal
>options, and those will be interpreted as the ones that the MTA should
>use. You don't need a special option that says "MTA must use this DNS
>server rather than the regular server".
>
>I'd like to understand what is wrong with the above reasoning.
>
> > Do sub-options 1 and 2 really constitute "modifying the basic DHC
> > client" and "changing basic DHCP behavior"?
>
>IMO, Yes. They modify the way the DHC client behaves. Note that DHC
>clients today can select the server based on what it advertises. But
>the option you've defined changes that in the following way:
>
>   - it doesn't say "chose this server that sent you the offer", it
>     seems to say "choose the server whose address is encoded in the
>     sub-option". That's a very different semantic
>
>   - or, it says, from now on, use a different port number when sending
>     DHCP requests (again, a *very* different semantic).
>
> > Cablelabs and the several dozen companies that have vetted this
> > draft have absolutely no interest in anything but standard
> > protocols.  There are several prototype DHCP servers and multiple
> > clients running this draft.  This is the first mention that
> > Cablelabs has distorted the basic DHCP protocol.
>
>That is why it is important to get DHCP options reviewed within the
>IETF, where the DHCP experts are.
>
> > We look to the DHCP gurus for further guidance here...but PacketCable
> > requires an "iron fist" mechanism that allows the access provider to
> > control who is allowed to offer telephony service over its network.
>
>I believe that normal DHCP does this already. I don't understand how
>the proposed extensions are needed (at least in the case of the DHC
>and DNS options).
>
> > > > CCC sub-options 4/5 allow an optional port number where the 
> standard DNS
> > > > options do not.
> > >
> > >How important is this? Is this critical?
>
> > Its a requirement of the PacketCable architecture.
>
>Why? How important a requirement? Its clearly not needed in all
>cases, since some forms of the option do not include a port number.
>
>Thomas

--

Paul Duffy
Cisco Systems, Inc.
paduffy@cisco.com

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg