Re: Re: RFC1977

> >> > just a small question regarding the RFC above.
> >> > If it's possible for the certain equipment not to provide the frame
> >> > where should be the DNS ?
> >> >
> >> > "By default, no primary DNS address is provided."
> >> >
> >> > Is that mean there will not be the DNS field at all in such a
> >> > frame ? or it will be with \NULL or 0.0.0.0 ?

This means that if the option is not included at all, then the peer
isn't expected to get a primary DNS address via this mechanism.  It
may have one through local configuration, BOOTP/DHCP over PPP,
assuming the peer to be a server, or possibly other means.

Note that the option is a little strange (the address supplied in
Configure-Request actually refers to a node on the _other_ side of the
link) and, though it's fairly commonly implemented, it's not a
standard.

The usual usage, when enabled, is that the side requiring a DNS server
address (the "client") includes the Primary DNS Server Address option
in its IPCP Configure-Request message, with the address set to
0.0.0.0.  The peer can then either respond with Configure-Nak to
specify a non-zero address for it to use, or with Configure-Reject to
say that none is available.  The originator then must send _another_
IPCP Configure-Request message with the right option contents (either
setting the address per the Nak or removing the option altogether on
Reject).

Of course, good implementations should sanity-check that Configure-Nak
as well.  A Nak specifying 0.0.0.0 or some illegal address ought not
be used, and should result in treating the message as though
Configure-Reject were received.

-- 
James Carlson, KISS Network                    <[email protected]>
Sun Microsystems / 1 Network Drive         71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677

_______________________________________________
Pppext mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pppext