DNS and NBNS IP address negotiation
James Carlson
> assignment. But according to RFC1877, there should be no default offer for
> these options. If I understand this correctly, at least the RAS should not
> offer DNS and NBNS addresses within its initial IPCP ConfReq, right ?
No. If a server implements this sorry excuse for an option, then it
should offer the information that it has in *every* Configure-Request
that it sends.
Quite frankly, running BOOTP over PPP is more standards-compliant,
more flexible, and downright easier than running RFC 1877.
> But
> what does the host side do ? Does ist question these options right in its
> first ConfReq (to be NAK'ed) or does it first negotiate the ususal IP
> addresses and thereafter goes for DNS/NBNS configfuration through a second
> IPCP negotiation step ?
No, you can't do IPCP in two steps. There's only one IPCP negotiation
phase. If the peer sends another IPCP Configure-Request after having
negotiated IP addresses, then IPCP starts over from scratch. See RFC
1661.
If the "host" has DNS/NBNS options it wants to the "server" (note that
there's no such thing as a "host" or "server" here, since PPP is
explicitly peer-to-peer), then it should go ahead and put them in its
first IPCP Configure-Request. Any implementation that doesn't want to
see these options will simply return them in IPCP Configure-Reject.
--
James Carlson, Consulting S/W Engineer <car...@ironbridgenetworks.com>
IronBridge Networks / 55 Hayden Avenue 71.246W Vox: +1 781 372 8132
Lexington MA 02421-7996 / USA 42.423N Fax: +1 781 372 8090
"PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp
Steve Matthews
As James indicates the WINS and DNS options are sent in the IPCP conf
request from the client.
Any DUN fields left for assignment will be presented as '0.0.0.0' IP
address's.
It is then up to the peer to provide if it can.
best regs
Steve
Peter Steiner
>thinking about RFC1877 and how a message flow would look like, I am now
>not entirely sure about one detail and, as expected, Win95 ppplog.txt
>doesn't help to clarify this much (no clue whether Linux pppd supports
>these options, but don't think so).
Maybe this helps (it's the log of a patched pppd2.3.5)?
Feb 27 13:05:48 kaili pppd[209]: rcvd [PAP AuthAck id=0x1 ""]
Feb 27 13:05:48 kaili pppd[209]: sent [IPCP ConfReq id=0x1 <addr 0.0.0.0>
<compress VJ 0f 01> <ms-dns 0.0.0.0> <ms-dns 0.0.0.0>]
Feb 27 13:05:48 kaili pppd[209]: sent [CCP ConfReq id=0x1 <deflate 15>
<deflate(old#) 15> <bsd v1 15>]
Feb 27 13:05:48 kaili pppd[209]: rcvd [IPCP ConfReq id=0x1 <compress VJ 0f 01>
<addr 193.158.143.21>]
Feb 27 13:05:48 kaili pppd[209]: sent [IPCP ConfAck id=0x1 <compress VJ 0f 01>
<addr 193.158.143.21>]
Feb 27 13:05:48 kaili pppd[209]: rcvd [IPCP ConfNak id=0x1 <addr 62.156.31.10>
<ms-dns 193.158.132.195> <ms-dns 194.25.2.129>]
Feb 27 13:05:48 kaili pppd[209]: sent [IPCP ConfReq id=0x2 <addr 62.156.31.10>
<compress VJ 0f 01> <ms-dns 193.158.132.195> <ms-dns 194.25.2.129>]
Feb 27 13:05:48 kaili pppd[209]: rcvd [LCP ProtRej id=0x3 80 fd 01 01 00 0f 1a
04 78 00 18 04 78 00 15 03 2f]
Feb 27 13:05:48 kaili pppd[209]: rcvd [IPCP ConfAck id=0x2 <addr 62.156.31.10>
<compress VJ 0f 01> <ms-dns 193.158.132.195> <ms-dns 194.25.2.129>]
Ciao,
Peter
--
_ x ___
/ \_/_\_ /,--' p.st...@t-online.de (Peter Steiner)
\/>'~~~~//
\_____/ signature V0.2 alpha
James Carlson
> As to the negotiation mechanism, I think that's perfectly clear now
> (although in contrary to James but conform w/ RFC1877, the RAS doesn't
> send these options until a peer requests them via 0.0.0.0 assignment).
If it does do that, then that's just the NT RAS implementation. It
has nothing at all to do with how PPP options are negotiated per the
standard. There is only one negotiation going on here. It's not
possible (as I think was suggested in the initial email) to negotiate
IP addresses "first" and then DNS/NBNS addresses "later" -- the IPCP
Configure-Request that attempts to negotiate "later" is necessarily
*also* (re)negotiating the IP addresses.
There are other boxes that implement these options -- access servers
-- that do not wait for the client to request the option. That
'waiting' is not required by any PPP standard.
> What I still cannot really understand is why James named these "a sorry
> excuse for an option". Well, BOOTP (DHCP) should be the better choice
> (that's neither from M$ nor just INFORMATIONAL) but if one needs to behave
> almost exactly as a Win9x "client" does, then RFC1877 might be the better
> choice, I think.
No. There are several rules broken here:
- If there's a protocol that does what you need and is already
standardized to do it, then use that protocol FIRST before
inventing something new.
- If you do write a new protocol, it should be minimal enough
such that it can be used in new environments without
redesign.
- Negotiating application layer variables (like name server
addresses) in the link layer (PPP) is a worthless exercise.
- If you really still think that you need a protocol to do
this, you should post FIRST to the appropriate working group
before releasing a product that does something stupid that
will require many other people to do work to conform to your
mistake. Doing otherwise is at best antisocial.
I don't care whether or not this particular RFC came from Microsoft.
That's not the issue. The issue is that RFC 1877 accomplishes
something that already has a history of working using existing
protocols (many older PPP and SLIP implementations used BOOTP), and
does it in a manner that is so badly designed that it is useless in
many network topologies.
Consider, for instance, a small office that has a LAN, a small router,
and a WAN link going to the Internet. Should that router implement
RFC 1877? Probably not, since small routers usually neither know nor
care about name resolution. It would have nothing useful to do with
the results. How do the nodes on the LAN get their parameters? They
certainly can't use RFC 1877, since they're not running PPP. They'd
have to use the already-standard BOOTP. Most routers would proxy this
over the link if configured to do so, and the ISP would have to answer
it.
Consider a Unix workstation where the RFC 1877 parameters would have
to be written to /etc/resolv.conf in order to be usable by
applications. Are you sure you want that? What if you have multiple
links to different sites, some within one domain and some within
another?
In general RFC 1877 makes sense only if you have a single machine
using a single link to attach to a network using PPP, and that single
machine has a poorly-designed monolithic operating system with only
modest distinctions between application and data-link layers. If any
of those assumptions are false, then it's not the best way to do
things.
> Moreover, at least my three ISPs do not support DHCP but
> provide DNS information via IPCP. So that's why I asked for it. Anyone ?
That's the marketing answer to it. People are asking for it mostly
because they're being forced to -- MS has decided that they want to
write "standards" without bothering to do sanity checks with the rest
of the world first, and now we're paying for it.
Btw -- you don't need or want DHCP here; BOOTP is just fine. It's
supported by most (if not all) dial-up servers.
Bernd Harries
I found your article very interresting, but I must admit I
just received a binary of modified pppd 2.3.5 for Linux which
can extract ms-dns and pass it to ip-up as well as print it
within debug.
James Carlson wrote:
..
> Btw -- you don't need or want DHCP here; BOOTP is just fine. It's
> supported by most (if not all) dial-up servers.
Now, if I don't want to use the modified pppd and don't know a new
ISP's nameserver IP, what could bootp help me?
Situation:
I just logged in and have my own and the remote IP.
/etc/resolv.conf is from my old provider (I have a whole set of
/etc/resolv.conf_*) and the old nameserver is now behind many
hops or maybe, the new provider has a firewall and I could only
see his proxy, nameserver, and (ISDN) router, but I don't know
the nameserver yet. And the proxy etc. is just known by name.
How could bootp help me?
What would I need to use it on Linux?
Which machine would be the starting point to refer to?
Which information could bootp give me?
An instant command to issue would be cool. Like
'bootp list nameservers by hops'
You see, I will just try it and maybe force some ISPs to use it,
if it really is generical and fool proof enough.
We can only overcome M$ by spreading our own better simpler and
more reliable standards.
--
Bernd Harries
b...@gmx.de http://www.freeyellow.com/members/bharries
be...@linux-m68k.org Tel. +49 421 809 7351 priv. | MSB First!
har...@stn-atlas.de +49 421 457 3966 offi. | Linux-m68k
bhar...@vossnet.de | Medusa T40
James Carlson
> Now, if I don't want to use the modified pppd and don't know a new
> ISP's nameserver IP, what could bootp help me?
It does essentially the same thing -- you send a BOOTP query over the
link right after bringing up IPCP, and the peer (if it supports this)
will respond with a BOOTP reply containing your DNS server addresses,
domain (which RFC 1877 doesn't give you), SMTP server, and a host of
other things.
Gee, that lack of a domain name in RFC 1877 hurts when you're trying
to fill out your /etc/resolv.conf, doesn't it?
> Situation:
> I just logged in and have my own and the remote IP.
> /etc/resolv.conf is from my old provider (I have a whole set of
> /etc/resolv.conf_*) and the old nameserver is now behind many
> hops or maybe, the new provider has a firewall and I could only
> see his proxy, nameserver, and (ISDN) router, but I don't know
> the nameserver yet. And the proxy etc. is just known by name.
>
> How could bootp help me?
It can find out exactly the same information, plus a bit more.
> What would I need to use it on Linux?
An implementation of bootp. It's a very simple UDP-based application
that you can invoke from ppp-up. It does NOT need to be compiled into
PPP itself.
> Which machine would be the starting point to refer to?
You'd refer to the machine that answered the call -- $5 in the ip-up
script.
> Which information could bootp give me?
Lots. See RFC 2132.
> An instant command to issue would be cool. Like
> 'bootp list nameservers by hops'
One quick web search later -- check out:
http://www.damtp.cam.ac.uk/linux/bootpc/
I think that does most of what you want.
> You see, I will just try it and maybe force some ISPs to use it,
> if it really is generical and fool proof enough.
>
> We can only overcome M$ by spreading our own better simpler and
> more reliable standards.
I've been in the business a while now, and I'm not so sanguine about
the prospects of better standards winning out over lesser standards.
But I guess we can always hope.
James Carlson
> Cisco's AS5100, etc) does not include options #129-132 within its first
> ConfReq but the "client" does. Then the RAS Nak's or Rej's the respective
> options. Well, this might be in contrary to how all remaining IPCP options
> are negotiated but that's how it is done in today's Wintel world which you
> cannot simply ignore regardless how poor their system approach might be.
Oh, *that's* what you're asking about. I misinterpreted the original
posting.
Yes, RFC 1877, in addition to being useless, is completely backwards
with respect to all other PPP negotiations. The side that wants to
have DNS/NBNS addresses (the "client" in Windoze-speak) assigned to it
must send an IPCP Configure-Request message with an essentially
arbitrary (usually value 0) set of addresses for these options. The
side that has the addresses (the "server" in their argot) will then
Configure-Nak with the right addresses. The first side then sends yet
another Configure-Request with the newly-learned addresses, and
finally gets a Configure-Ack in return.
This is completely backwards, and results in a slightly slow start-up
time. If they'd bothered to send it through the working group before
implementing and deploying this mistake, somebody might have noticed.
> Reading this I remember something like "no PCs were harmed during the
> process of making this book" or similar... Be told that my *private*
> opinion *is* very close to yours. ;-)
Hardly private any more!
> Well, that's clear so far. Where, btw, would you draw the border line
> between BOOTP and DHCP ?
RFC 2131 contains the DHCP-specific portions, and RFC 951 describes
the original BOOTP. BOOTP is simple and clean -- you send a single
UDP message to port 67 (with an arbitrary or broadcast address, if
known), and you get back a single UDP reply to port 68 on your system.
DHCP is relatively complex. It involves a server discovery phase, an
address allocation phase, and a lease maintenance phase. Unlike
BOOTP, it requires shared state between the client and the server.
> As far as I understand, a "standard" Wintel PC
> could only issue DHCP requests which are basically BOOTP messages (maybe
> they exceed the 63 bytes, and a few other things). Would you expect a RAS
> with BOOTP support to answer the Win DHCP requests ?
I assume you mean a "NAS," not a "RAS." "NAS" is the usual industry
term for a dial-up communications server, such as a cisco, Nortel, or
Lucent box. "RAS" is usually used to mean MS's proprietary dial-up
support stuff.
Since the PC is doing DHCP, I'd expect that it's DHCPDISCOVER message
would fall on deaf ears with a straight BOOTP server. A BOOTP relay
or a DHCP server should be able to handle it, though.
From what I've *heard* on the DHCP lists, the NT DHCP server is broken
and does not properly support backward-compatibility with BOOTP per
RFC 1542. It does DHCP only.
I don't personally know whether or not it works right since I don't
bother with any MS products.
Peter Steiner
>Yes, RFC 1877, in addition to being useless, is completely backwards
>with respect to all other PPP negotiations. The side that wants to
>have DNS/NBNS addresses (the "client" in Windoze-speak) assigned to it
>must send an IPCP Configure-Request message with an essentially
>arbitrary (usually value 0) set of addresses for these options. The
>side that has the addresses (the "server" in their argot) will then
>Configure-Nak with the right addresses. The first side then sends yet
>another Configure-Request with the newly-learned addresses, and
>finally gets a Configure-Ack in return.
This exactly looks like IP-address negotiation.
sent [IPCP ConfReq id=0x1 <addr 0.0.0.0> <compress VJ 0f 01>
<ms-dns 0.0.0.0> <ms-dns 0.0.0.0>]
sent [CCP ConfReq id=0x1 <deflate 15> <deflate(old#) 15> <bsd v1 15>]
rcvd [IPCP ConfReq id=0x1 <compress VJ 0f 01> <addr 193.158.132.233>]
sent [IPCP ConfAck id=0x1 <compress VJ 0f 01> <addr 193.158.132.233>]
rcvd [IPCP ConfNak id=0x1 <addr 193.159.117.106>
<ms-dns 193.158.132.195> <ms-dns 194.25.2.129>]
sent [IPCP ConfReq id=0x2 <addr 193.159.117.106> <compress VJ 0f 01>
<ms-dns 193.158.132.195> <ms-dns 194.25.2.129>]
rcvd [LCP ProtRej id=0x3 80 fd 01 01 00 0f 1a 04 78 00 18 04 78 00 15 03 2f]
rcvd [IPCP ConfAck id=0x2 <addr 193.159.117.106> <compress VJ 0f 01>
<ms-dns 193.158.132.195> <ms-dns 194.25.2.129>]
1. pppd sends an IPCP configure-request with a value of 0.
2. The other side then NAKs with the right address
3. The first side sends another configure request with the newly
learned address
4. The peer ACKs the address.
My dynamic-DNS patch was done mostly by 'copy&paste'-ing the
IP-negotiation. Of course, this is the wrong place for a DNS
configuration. However, many ISPs support it. The best is to simply
pass the DNS-numbers to a local nameserver as forwarders and to not
include the ISP into the searchlist.
James Carlson
> This exactly looks like IP-address negotiation.
Frome that viewpoint, I suppose so. I still consider it to be
backwards compared with the way all the other options are defined. By
giving a value in an IPCP IP-Address option, you're saying, in effect,
"my IP address is this." What are you saying with the MS-DNS option?
Clearly, the "client" side doesn't have a local DNS server, or it
otherwise wouldn't be asking for one. The "server" side (if it
supports MS-DNS) *does* have a local DNS server, and yet it's not
sending it over as expected in the request message.
Somehow, the "client" is expected to divine the existence of a DNS
server on the "server's" side of the wire, guess that it knows about
it and uses RFC 1877, and will want to reveal that address if only
given a chance to Configure-Nak a bogus address that it sends.
If the same rules were applied to the IP-Address option, you'd have
sent your peer's address inside your own Configure-Request -- as if to
say "my idea of your address is thus." That seems like a very odd way
of viewing the semantics of PPP options to me ...
> My dynamic-DNS patch was done mostly by 'copy&paste'-ing the
> IP-negotiation.
I agree that it happens to appear to be the same, at least
superficially. When the standards are written in the usual manner --
with open review and comment -- they usually are more consistent and
coherent than that.
> Of course, this is the wrong place for a DNS
> configuration. However, many ISPs support it. The best is to simply
> pass the DNS-numbers to a local nameserver as forwarders and to not
> include the ISP into the searchlist.
Another option (one that has a respected history among implementors
but was curiously ignored by MS) is to simply treat the remote address
(the IP address you learn from your peer's IP-Address option in his
Configure-Request) as both your default router and your DNS server.
That happens to work correctly on most decent dial-up servers.
Now why did the do the former but write yet another unnecessary
protocol to do the latter ... ?
--
James Carlson, Software Architect <car...@ibnets.com>
Peter Steiner
>> This exactly looks like IP-address negotiation.
>
>Frome that viewpoint, I suppose so. I still consider it to be
>backwards compared with the way all the other options are defined.
When you define the DNS addresses with "ms-dns" *and* add the option
"dyn-dns" of my patch then the pppd will tell the other side the DNS
address without being askd for it. Quite funny. That's because I treat
the DNS addresses the same as the IP addresses (you know, copy&paste...).
I'm not saying that ms-dns is great, but some people do have problems
with their provider always changeing the DNS addresses. And I really
hate that "That's no problem for winXX, why isn't it working in Linux?"