Re: [dhcwg] DHCP Option for CableLabs Client Configuration

[Thomas Narten <[e-mail]>]

Paul,

> 1. On the advice of several DHCP and Cablelabs experts, we specifically did 
> not duplicate Cablelabs specification content in this draft.  We decided to 
> define CCC sub-option syntax and content in the draft, with specific 
> Cablelabs specifications elaborating on exactly how and when the CCC 
> sub-options are used.  The idea is to avoid significant duplication of text 
> and the inevitable synchronization problems that would result between 
> multiple documents.

I agree that duplication of text is not a good idea. But this document
could include enough background information and details so that one
could implement/review it without having to look at the other
document. I.e, *this* document should make it clear what the DHCP
operations are. The other document can indicate how the values in the
option are to  be used.

Looking at the other  document, I see now that:

1) The DHC server is supposed to include the CCC option in its
   Advertise. The MTA uses that information in selecting a
   server. This is normal DHCP, and the document  could easily make
   this part clear.

1a) the client identifies itself with a "user class" option, this
    allows the DHC server to know to include the CCC option. Correct?
    In any case, the document could easily make it clear what the
    normal steps are here.

2) Once the MTA has chosen a server, it seems to me like normal DHCP
   would apply. At this point, some of the specific options don't make
   sense (or maybe this is a wording thing).

>       |    4    |  MTA    | TSP's Primary Domain Name Server Address   |  
>       +---------+---------+--------------------------------------------+  
>       |    5    |  MTA    | TSP's Secondary Domain Name Server Address |  

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?

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?


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.

5)

>   8.1. TSP's DHCP Server Address Sub-Options

There are number of formats, some of which include a port number. It
appears the MTA takes the DHC server address and sends followup DHC
messages to *that* particular server (possibly at a redirected port).

This seems like a change to basic DHC behavior on the client. Seems to
me that this is inappropriate and unnecessary (at least in some
cases). Also, I find it unfortunate that someone outside of the IETF
seems to be specifying behavior that changes basic DHCP behavior.

First, to redirect the client to a specific DHC server, it would seem
better to just have the MTA client pick the server based on the DHC
advertisement. This can already be done in DHC today. (i.e, the client
just uses the server that sent an advertisement that the MTA liked.)
No special option is needed.

*If* the DHC WG thinks that modifying the basic DHC client processing
rules in order to redirect the client to other servers (and ports) via
a specific option is a good idea, it would be better for the WG to
define a general way of doing this.

Seems to me that Cablelabs is extending/modifying basic DHC processing
rules inappropriately, something that the IETF/DHC WG should retain
control over.

I'd like to better understand the requirements here.

> >3) There are some kerberos-specfic sub-options here. I wonder if they
> >    make sense from the kerberos perspective (and will try to find
> >    someone who can answer). Reason I say this is I'm aware of an older
> >    kerberos ID that put Realm information into a  DNS RR, and the
> >    realm field was NOT the same as an FQDN (as this ID says it will
> >    be)

> A PacketCable MTA's realm name and domain name are not the same.  A 
> PacketCable deployment will typically be a large, multi vendor 
> situation.  The authentication realms and domain name space are kept 
> separate.

This is not what I read the document to say:

>    8.4. TSP's Kerberos Realm Name Sub-Option  
>         
>    The PacketCable architecture requires an MTA to authenticate itself 
>    to the TSP's network via the Kerberos protocol.  A Kerberos Realm 
>    name is required at the MTA to permit a DNS lookup for the address of 
>    the TSP's Kerberos Key Distribution Center (KDC) entity.  
>             
>    The Kerberos Realm name is an FQDN.  The sub-option is encoded as 
>    follows: 

I read the above as the Realm name is a FQDN. Please clarify.    

> >4) Options 4 & 5 don't make sense to me immediately. Why would the MTA
> >    need special DNS servers (as opposed to just using the ones through
> >    it's ISP?)

> The PacketCable specs draw a hard line between data access provider and 
> telephony service provider.  The access provider is responsible for 
> provisioning the CM, the telephony service provider provisions the 
> MTA.  These two business entities are assumed to have their own DHCP and 
> DNS infrastructure.

OK. But I think there may be cleaner ways of doing this (using
existing DHC mechanisms) than the proposed options.

> >And, why can't the normal DNS server option be used
> >    here? If the MTA's DHC requests get routed to the TSP-specific DHC
> >    server, it can know to return an appropriate DNS server. Why is a
> >    special suboption needed?

> CCC sub-options 4/5 allow an optional port number where the standard DNS 
> options do not.

How important is this? Is this critical?

Thomas


_______________________________________________
dhcwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/dhcwg