Subject: Re: I-D ACTION:draft-hiller-dns-addr-00.txt

From: James Carlson <[email-masked]>
Date: Wed, 5 Jun 2002 11:58:34 -0400

Because I commented on the SIP server address draft, someone pointed
out this draft to me as well.  I somehow overlooked it the first time
around.  Sorry for the extreme time delay.

>  A major portion of the text in this memo was stolen from RFC 1877 
>  [8].

Indeed.  And the proposal is flawed for exactly the same reasons that
RFC 1877 is flawed.  These include:

	- There's no reason to expect that the "server" end of the
          connection can supply or that the "client" end can use these
          addresses.  It works only when the server has special
          configuration, and the client *happens* to also be running a
          local set of applications that care about DNS server
          addresses.  It fails utterly if either peer happens to be a
          mere router or bridge.

	- Using draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt with
          DHCPINFORM gives simple support for this feature on PPP, as
          well as over any other medium that can carry UDP/IPv6.
          Having one mechanism rather than N (where N>1) is better.

	- The negotiation is backwards; the Configure-Request sender
          is somehow obliged to "guess" at the addresses of the DNS
          servers that actually reside on the other end of the link.

More fundamentally, DNS server addresses (and search paths, and boot
image names, and log hosts, and print servers, and home page URLs, and
so on) are application-level details.  PPP's NCPs are a mechanism for
negotiating link layer issues, such as proper numbering, naming, and
identification.  DNS resolver configuration is not a per-link issue.

-- 
James Carlson, Solaris Networking         <[email-masked]>
SUN Microsystems / 1 Network Drive         71.234W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.497N   Fax +1 781 442 1677

---

From: "Glen Zorn" <[email-masked]>
Date: Mon, 10 Jun 2002 04:56:48 -0700

>           addresses.  It fails utterly if either peer happens to be a

Yes, but only if we ignore the existence of AAA.

>           Having one mechanism rather than N (where N>1) is better.

Very true, however DHCP is unlikely to work in an Internet roaming scenario.

>           servers that actually reside on the other end of the link.

There needn't be any guessing involved: DNS clients are generally either
configured with DNS server addresses or not; this option allows for both
possibilities.

> identification.  DNS resolver configuration is not a per-link issue.

This is not necessarily true.  For example, say that a user is dialing into
a POP operated by an ISP who has contracted with the user's employer to
provide connectivity to the corporate "intranet".  For this hypothetical
user, the ISP's DNS servers are pretty much useless (because the user needs
internal corporate addresses), as is DHCP, since the addresses of the
appropriate DNS servers are returned by the corporate AAA server.

---

From: James Carlson <[email-masked]>
Date: Mon, 10 Jun 2002 08:52:33 -0400

> James Carlson [mailto:[email-masked]] writes:
[...]
> Yes, but only if we ignore the existence of AAA.

That's a local implementation matter.  *If* your AAA implementation
dictates DNS server addresses (arguably a very bad choice, for very
many reasons), *then* you have to find a reasonable way to put these
bits on the wire.  This is no different from handling any other non-L2
information that comes from the AAA server -- including lists of IP
filters to put in place.

Note that 802.1x can also use AAA on the server and thus has the same
(non-)problem.  How are DNS server addresses transferred in this case?
Why should we prefer a PPP-only solution to a general problem?

(The reasons that putting DNS server addresses into AAA is bad include
the fact that it's both technically infeasible to force the client to
use a particular DNS server, and probably unwise as well.  At best,
the data here are merely advice to the client -- not required.)

Note also that a reasonable PPP server can if necessary insert an NAI
based on local configuration ... being a DHCP proxy provides a great
deal of flexibility.

> Very true, however DHCP is unlikely to work in an Internet roaming scenario.

Please explain that comment.  There's nothing in the on-the-wire bits
that makes this proposal any better or worse than DHCP with respect to
roaming.

In fact, there's nothing particular in PPP or DHCP that helps or hurts
roaming.

Are you, perhaps, suggesting that a DHCP server doesn't know which
port or authenticated peer is in use?  If that's the case, then, like
this proposal, this is a matter of local policy and implementation.
This same issue exists with any other use of DHCP.  Why should DNS
server addresses be special?  If we need this proposal, why not just
copy *all* DHCP options into IPCP and IPV6CP?

Are you suggesting that the DHCP client doesn't know when to ask for
new data?  It's supposed to do it when the link goes up, and if it
doesn't, then the implementation is broken, not the protocol.

> configured with DNS server addresses or not; this option allows for both

No.  Here's the protocol as it exists in this draft (and RFC 1877):

  Client: "I think there might be DNS servers on your end of the link
  that have IP addresses 10.0.0.1 and 10.0.0.2.  Is that correct?"

  Server: "No, I (somehow) see some DNS servers here, but the right
  addresses are 10.0.0.3 and 10.0.0.4."

  Client: "I think there might be DNS servers on your end of the link
  that have IP addresses 10.0.0.3 and 10.0.0.4.  Is that correct?"

  Server: "Yes, that's right."

A much more reasonable protocol would be to have the side that has the
data *send* that data to the other side.  In other words:

  Server: "Guess what?  I have a couple of DNS servers here at
  10.0.0.3 and 10.0.0.4.  I don't know if you care, but here they
  are."

  Client: "Super."

What I think is going on here is a basic misunderstanding of how PPP
negotiation works, based on a faulty observation of how IPCP IP-
Address negotiation is sometimes *used*.  With IP-Address, it's common
for one side to be ignorant of its own IP address.  Thus, it has to
ask the other side (via Configure-Request for 0.0.0.0) to find out
what the other side thinks its address might be.  This, however, isn't
the case for which the option was designed.  By design, the IP-Address
option sends the local system's IP address via Configure-Request to
the peer.  Each system sends its own IP address because it "owns" that
information.  The use of Configure-Nak exists only in the case where
the other peer disagrees.

This DNS proposal is *not* the same case.  Instead, this draft (and
RFC 1877) intentionally have the side that does *not* own the data
(and merely holds a copy of that data) sending the Configure-Request.
That's backwards.

We shouldn't be confused about which side of the link "owns" the data.
The name servers are present on the *server's* side of the link.  The
numbering of those servers exists on that side of the link.  The side
that owns the data should be sending the Configure-Request.

If you don't want to change it because RFC 1877 is already broken,
then that's fine, but that doesn't make it any less backwards.

> appropriate DNS servers are returned by the corporate AAA server.

Actually, if this is the case, then the entire link is useless with
respect to the ISP.  It ought to have addresses that are assigned from
within the corporate entities' private address space.  Since such a
link goes behind a corporate firewall, it also means that much of the
ISP is inaccessible to the client side over that link.  That's by
design.

Ignoring whether this is a good idea (ssh and IPsec are obviously
*much* better solutions that don't expose the corporate entity in
question to a potentially highly foolish entanglement with the ISP's
internal security), this issue is really a red herring.

Since the link is tunneled back to the corporate site, this means that
*all* packets sent by the remote client must be tunneled back.  This
includes the DHCPINFORM messages themselves.  The corporate site's
server(s) that terminate the tunnel can then respond with the
appropriate information.

Since the ISP's server is aware of this chicanery (it must, since the
IP addresses on the link are unrelated to its own IP address space,
and may overlap other corporate customer's addresses or even its own
internal addresses, and since it acts as one end of the tunnel), the
ISP's server can know whether to provide helpful DHCP information
locally or forward along the tunnel.

Like RFC 1877, this draft should *at best* be on Informational track,
despite what the Category header in the draft suggests.  However, I
would strongly prefer that it not be published as an RFC at all.  It's
not necessary and merely perpetuates a previous design error into a
brand new realm.

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 10 Jun 2002 06:02:44 -0700 (PDT)

> Yes, but only if we ignore the existence of AAA.

Routability is an issue. If a AAA server returns an address for a node,
then the NAS (or the VPN server, if compulsory tunneling is involved)
has to advertise a prefix that encompasses that address.

> Very true, however DHCP is unlikely to work in an Internet roaming scenario.

What breaks?

> appropriate DNS servers are returned by the corporate AAA server.

If the user needs internal corporate addresses, then we're talking about
compulsory tunneling. Without tunneling, the NAS can't just assign such an
address, since routability is an issue. If a AAA server returns an
address for a node, then the NAS (or the VPN server, if compulsory
tunneling is involved) has to advertise a prefix that encompasses that address.

If we have a compulsory tunnel, then a DHCPINFORM sent to the NAS will be
sent down the tunnel for handling by the corporate DHCP server. So the
user will get what is required, namely the internal DNS server address.

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 10 Jun 2002 06:06:05 -0700 (PDT)

> (non-)problem.  How are DNS server addresses transferred in this case?

Answer: DHCP is used. If required, the 802.1X authenticator can
function as a DHCP Relay or Server.

> based on local configuration ... being a DHCP proxy provides a great

Careful. DHCP proxies are not defined in the DHC RFCs, only relays.

> port or authenticated peer is in use?

In fact, this is handled via the DHCP Relay Option.

---

From: James Carlson <[email-masked]>
Date: Mon, 10 Jun 2002 10:08:23 -0400

> has to advertise a prefix that encompasses that address.

"Yuck."  How does anyone know what might be reachable by an arbitrary
third party?

> function as a DHCP Relay or Server.

That's exactly my point.  If you can do it for the 802.1x
authenticator, then you can do it for PPP.

> Careful. DHCP proxies are not defined in the DHC RFCs, only relays.

True.  That doesn't stop anyone from implementing such a thing for any
reason.  I don't believe that any such RFC is required, since it would
involve *only* the internal behavior of a system, not the bits that
appear on the wire.  There's no good reason to write RFCs about things
that external systems can't observe.

For the same reason that BOOTP proxies for SLIP were common 10 years
ago, I expect DHCP proxies to be just as reasonable.  The issues are
essentially unchanged today.

> In fact, this is handled via the DHCP Relay Option.

I'm trying to extract the reason why DHCP can't be used, and IPV6CP
must be modified instead.  Since no reason is given, I have to guess
at it.  I suspect that it's just parity with RFC 1877, and that would
not be a good thing.