Subject: RE: [dhcwg] DHCP Option for CableLabs Client Configuration

From: "Woundy, Richard" <[email-masked]>
Date: Tue, 6 Aug 2002 13:59:15 -0600

Erik,

We have some areas of agreement and disagreement. In summary, I think we
should see if a "two-faced DNS" solution is practical for the particular
problem at hand.

Many comments below on your comments.

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

Today, cable operators (and many other service providers) offer Internet
access services to subscribers with public IPv4 addresses allocated from
ARIN. It is a best effort service that does not require interdomain qos.
That's not the issue here.

I think many people would disagree that voice over IP service is effective
over a best effort network service. Particularly note that we are leveraging
the same regional backbones where we are offering best effort Internet
service. Voice over IP traffic may compete for resources for MP3 downloads,
kazaa traffic, etc. Of course, some folks would suggest that we service
providers should over-provision the bandwidth of our regional backbone
links, so that best effort service can be made to work for VoIP -- which is
certainly feasible, given sufficient capital and operational expenses. It's
just that the financial expenses might crush any hopes of making voice over
IP into a viable business. That's part of the reason why the IETF has folks
working on RSVP, DiffServ, COPS, etc.

My point is more about whether ARIN would agree that the typical PacketCable
MTA needs a public IPv4 address. It's hard to justify the need for a public
IPv4 address

Note that I am *not* suggesting that MTAs operate behind some sort of
corporate firewall. In fact, they will co-exist with cable modems and
computers (for subscriber Internet access) on the same cable networks.

Note that we assign private IPv4 addresses to cable modems today --
primarily at the request of ARIN. Even though the modems enable full-blown,
non-walled-garden access to the Internet to computers behind them, the
modems themselves are mostly manageable bridges that do not require Internet
access (there are a few clever exceptions).

>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 agree with you that RFC 1918 addresses are not "more secure". But since I
*am* a cable operator, and obviously part of "the problem", or part of some
hidden conspiracy... Nevermind, this isn't a productive or technical line of
discussion; we should take this offline. ;^)

>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?

I guess that is more clear.

Are you suggesting that if folks in the cable world still believe that there
is a requirement to communicate DNS port numbers to MTAs, then they should
define an additional Internet draft that is published as Experimental or
Informational?

Note that the PacketCable specifications themselves, and the long-term
intent of the CableLabs Config option, is to enable VoIP services beyond
"walled garden" services. We are just talking about part of the DHCP option
information in that draft, no?

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

One difference is that in the firewall example, it is readily apparent which
DNS traffic is "internal" versus "external". All "external" traffic comes in
from the firewall, or in from an "external" interface. All "internal"
traffic comes from a well-defined set of "internet" IPv4 subnets.

In the cable networks, the cable modems, computers with Internet access, and
MTAs all co-exist on the same cable/DOCSIS subnets.

It *is* possible to assign different IPv4 addresses to these different types
of devices, which may be something that a two-faced DNS service could
leverage. I need to think about whether this approach will scale.
 
>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).

I understand the need and desire to reduce unneeded complexity.

I don't quite understand the issue of non-interoperability. If an RFC
explains the expected DNS behavior of the MTA, and there are multiple
implementations that support that expected DNS behavior in DNS servers,
then... what's the issue again?

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

The biggest advantage is that a cable operator could run multiple DNS
servers on the same hardware, with separate administrative tools, run by
possibly independent operations folks. There would be no issues about the
impacts of one DNS service configuration change on the other DNS service.
Both DNS services could be verified independently, without the need of
performing DNS queries "from the right location for the right test".

A two-faced DNS service might be a better alternative; perhaps more complex,
but perhaps more in line with how other folks solve similar DNS problems.
Let's explore that technical approach further. At least it allows us to
avoid the discussion about whether I am part of some grand cable
conspiracy... Sigh. ;^)

-- Rich

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

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 7 Aug 2002 11:04:05 +0200 (CEST)

> define an additional Internet draft that is published as Experimental or

Depends on the ellusive details.

It would be better if they could clearly communicate the requirement so that
the IETF can look at it and try to understand what type of reqirement it
is and whether or not it is a requirement specific to the cablelabs type
of environment. 

If the requirement is that for testing purposes or experimentation 
in the cablelabs environments it is useful to be able to use different port
numbers for DNS, then a separate info or experimental document would make
sense. But I can't yet tell whether this is the case.

> information in that draft, no?

Yes. Thomas had some issues with the other suboptions, but my concerns
is about the DNS.

> then... what's the issue again?

There is in theory potential interoperability issues both for DHCP and DNS.
DHCP: will things operate correctly if the MTA receives a good ol' DNS
name server option instead of this suboption? If not you either get all
the DHCP servers on the planet to implement the cablelabs option or you could
end up with interoperability problems.
DNS: will things operate correctly if the MTA is using the standard DNS port?
If not you either get all the DNS resolvers on the planet to be configurable
to run on an alternate port, you could end up with interoperability problems.

Of course, by careful selection of parts (DHCP servers, DNS resolvers) for
a cablelabs environment one can avoid these problems. But part of the benefits
of the Internet interoperability story is that it doesn't require special
versions of protocols and software; things off the shelf just tend to
interoperate. This off-the-shelf aspect and the price of equipment that
results is often a key perceived benefit of using the internet protocols.
So let's think a bit before embarking on paths that break this.

> performing DNS queries "from the right location for the right test".

Thank you!!! It's something concrete like this that I've been looking for
all along.

Have people been thinking about this when there are only two DNS servers
on the box (one for the best-effort IP network and one for the VoIP network),
or have people also been thinking about outsourcing cases where a
single DNS box might provide DNS service for multiple VoIP networks run by
different operators? I think understanding whether it can be more than 2
in a box might be important.

  Erik

---

From: Ted Lemon <[email-masked]>
Date: Thu, 8 Aug 2002 11:47:07 -0500

> end up with interoperability problems.

It is always a risk that a DHCP server administrator will configure the 
DHCP server incorrectly.   This is an example of an incorrect configuration.
    There is nothing that you can do in the protocol to prevent an incorrect 
configuration.   For example, if I configure my DNS server to do TSIG 
updates, but I put the wrong TSIG key data on the client, the update 
inexplicably doesn't work.   As the administrator, I just have to figure 
that out and fix it.   The protocol can't help me - it has no way to report 
that the signature didn't verify, because an invalid signature means the 
packet should be tossed.   Is this a bug in the protocol?   (I don't think 
so!)