headers
Fred Baker | 25 Apr 2006 18:27
Picon
Favicon

Re: RFC1977

OK. I would suggest that this be taken to the list or to the author. I stopped being the chair in 1995, never mind what the RFC says about my being the "current" chair (I never did understand why PPP documents listed me instead of the mailing list).

On Apr 25, 2006, at 8:52 AM, Michal Szewczyk wrote:

Hi,

Sorry my mistake 1877 :)

Best Regards
MIke

Fred Baker wrote:

Are we talking about the same document?

http://www.ietf.org/rfc/rfc1977.txt
1977 PPP BSD Compression Protocol. V. Schryver. August 1996. (Format:
      TXT=50747 bytes) (Status: INFORMATIONAL)

Vernon's document doesn't mention DNS...

On Apr 25, 2006, at 7:58 AM, Michal Szewczyk ((WA/EPO)) wrote:
> Hi Fred,
>
> 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 ?
>
> Best Regards
> Mike
>
> --
> No virus found in this outgoing message.
> Checked by AVG Free Edition.
> Version: 7.1.385 / Virus Database: 268.4.5/321 - Release Date:
> 2006-04-21

--
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.385 / Virus Database: 268.4.5/321 - Release Date: 2006-04-21
 


_______________________________________________
Pppext mailing list
Pppext <at> ietf.org
https://www1.ietf.org/mailman/listinfo/pppext
Permalink | Reply | 1 comment |
headers
James Carlson | 25 Apr 2006 18:42
Picon

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                    <james.d.carlson <at> sun.com>
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
Pppext <at> ietf.org
https://www1.ietf.org/mailman/listinfo/pppext
Permalink | Reply | 0 comments |

Gmane