RE: [dhcwg] DHCP Option for CableLabs Client Configuration

[Erik Nordmark <[e-mail]>]

> If MTAs communicate at the IP layer only with other systems (MTAs, call
> management servers, media gateways, etc.) within the same domain, then it
> makes sense to consider using RFC 1918 private addresses for MTA rather than
> public addresses. Using private addresses for MTAs is significant in the
> case of AT&T Broadband, since this cable operator already has 1,200,000
> telephony subscribers (over broadband cable) today. Note that CableLabs, in
> fact, would like cable operators to assign public addresses to MTAs for
> interdomain communications... but I'm not sure that ARIN would approve of
> that choice given our current generation of products, our (lack of)
> interdomain qos expertise, and the large consumption of public addresses
> that such a decision would entail.

This is tangential to the issues at hand. But I don't think ARIN 
summarily rejects requests for IPv4 addresses just because
the requester can't specify how to interdomain qos; if so they would have
to deny most requests for IPv4 addresses.
So I think it would actually make sense for the operators to request IPv4
addresses. Of course, part of them problem might be that the operators
think RFC 1918 addresses are actually better than the real thing ("more secure"
and other misconceptions).

> I suppose you might consider what I have described as a "walled garden" for
> MTAs. My first reaction is that the end-goal for the PacketCable
> architecture is a voice-over-Internet service, not merely a walled garden
> service. My second reaction is this -- why does the IETF care about whether
> a particular service deployment is a walled garden or not? Do the IETF
> standards only support certain business models, and not others? Do the IETF
> standards FORBID walled gardens? I thought the IETF was a technical
> standards organization, not a business policy standards body.

I think what I said was about doing something which only has useful 
applicability for a walled garden. As far as I can tell there are no
technical reasons for running DNS on a different port (except for testing which
I've commented on several times already), hence this seem to me as a 
technically bad idea. I can understand if folks might want it to make it
easier to build walled gardens, but I think the IETF should not try to
standardize things which are only applicable to walled gardens.
Is that more clear?

> It would seem rational that, should it makes sense to assign RFC 1918
> private IP addresses to MTAs, and since MTAs require DNS fully qualified
> host names as VoIP endpoints in PacketCable (and in SGCP/MGCP, and in SIP),
> then RFC 1918 seems to endorse the operation of a parallel DNS
> infrastructure for the MTAs and VoIP components. And one way to run a
> parallel DNS infrastructure is to use different DNS port numbers for the
> VoIP service. This is particularly true for smaller operators, with more
> limited capital budgets and smaller VoIP subscriber bases.

I suspect many large organizations (but not all) that sit behind a firewall
run a two-faced DNS; the DNS database visible from the inside is different
than the DNS database visible from the outside.
The point is that it is possible to do this without any extra protocols.
 
Given that this is possible I don't see why the IETF needs to provide an
additional mechanism to accomplish the same thing. That implies
uneeded complexity but also additional risks for non-interoperability
(when one system uses one scheme and another system uses another scheme).

> P.S. It wasn't originally my idea to put DNS port number configuration into
> the CableLabs Client Configuration option, by the way. For a substantial
> period of time, I thought it was a "hack". I have only been recently
> convinced that there were significant operational advantages to this
> configuration parameter.

I'd be interested in finding out the significant advantages.

  Erik



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