Theoretical question on PPP

[vangelis angelakos]

Hello,
I am working on a PPP paper and during the last couple of days I've been
reading
RFC 1661, and I have a question on a 'strange' complexity on Magic-Number
description. Specificaly, on page 46, par. 3 the RFC states:

"...If an implementation does receive a Configure-Reject in
response to a Configure-Request, it can only mean that the link is
not looped-back, and that its peer will not be using Magic-
Numbers. In this case, an implementation SHOULD act as if the
negotiation had been successful (as if it had instead received a
Configure-Ack)..."

Does anyone has a better idea on the reason of introducing such
an 'overload' for Conf-Rej? If peer Rejects Magic number option
why SHOULD the implementation act as if the negotiation was
successful (a.k.a will send Echo Requests with it's (rejected) magic
number)?

Thank you,
vangelis

[James Carlson]

Post by vangelis angelakos
"...If an implementation does receive a Configure-Reject in
response to a Configure-Request, it can only mean that the link is
not looped-back, and that its peer will not be using Magic-
Numbers. In this case, an implementation SHOULD act as if the
negotiation had been successful (as if it had instead received a
Configure-Ack)..."
Does anyone has a better idea on the reason of introducing such
an 'overload' for Conf-Rej?

It seems like an obvious bit of logic to me.

Post by vangelis angelakos
If peer Rejects Magic number option
why SHOULD the implementation act as if the negotiation was
successful (a.k.a will send Echo Requests with it's (rejected) magic
number)?

Because it knows necessarily that the line is not looped back.

Using the magic number in the LCP Echo Request messages is harmless
and meaningless to the peer. It's useful just for making sure that a
loopback condition doesn't show up _later_, while the link is
running. It still serves that purpose even if only one side is able
to do the check.

In other words, a system receiving an Echo Request message should not
be trying to match the magic number against anything other than 0 and
its own magic number. As long as the request is either 0 or not the
local magic number, send a reply.

[Vangelis Angelakos]

Mr. Carlson, thank you for taking some of your time replying on this
question.



I will try to give a better focus on the part that troubles me the most.

First of all let's take 2 parts out of the equation:



1. You are right, getting a Conf-Rej on a Conf-Req can positively

identify a no-loopback condition



and 2. Yes, peer on Echo-req should only check 0, local magic-number and
peer-magic number (for miscofigured link according to 1661 page 47 par. 1)



What troubles me is the following:

Why getting into the trouble of overloading Conf-Rej instead of

just using a Conf-Ack (assuming all other options were successfully

agreed, or no other option exists) for the hypothetical Conf-Req in

question?

The answer to that cannot simply be that (in Conf-Rej case) "the

peer will not be using Magic-Numbers" since this can also be done

(with standard procedures) by having peer's Conf-Req NOT to include

a magic-number option.

Since RFC 1661 is a very carefully written document, there must be

a specific reason for this Conf-Rej overload selection, which I fail

to see...

Post by James Carlson

Post by vangelis angelakos
"...If an implementation does receive a Configure-Reject in
response to a Configure-Request, it can only mean that the link is
not looped-back, and that its peer will not be using Magic-
Numbers. In this case, an implementation SHOULD act as if the
negotiation had been successful (as if it had instead received a
Configure-Ack)..."
Does anyone has a better idea on the reason of introducing such
an 'overload' for Conf-Rej?

It seems like an obvious bit of logic to me.

Post by vangelis angelakos
If peer Rejects Magic number option
why SHOULD the implementation act as if the negotiation was
successful (a.k.a will send Echo Requests with it's (rejected) magic
number)?

Because it knows necessarily that the line is not looped back.
Using the magic number in the LCP Echo Request messages is harmless
and meaningless to the peer. It's useful just for making sure that a
loopback condition doesn't show up _later_, while the link is
running. It still serves that purpose even if only one side is able
to do the check.
In other words, a system receiving an Echo Request message should not
be trying to match the magic number against anything other than 0 and
its own magic number. As long as the request is either 0 or not the
local magic number, send a reply.
--
Sun Microsystems / 1 Network Drive 71.232W Vox [phone]
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax [phone]

[Unruh]

Post by Vangelis Angelakos
Mr. Carlson, thank you for taking some of your time replying on this
question.
I will try to give a better focus on the part that troubles me the most.
1. You are right, getting a Conf-Rej on a Conf-Req can positively
identify a no-loopback condition
and 2. Yes, peer on Echo-req should only check 0, local magic-number and
peer-magic number (for miscofigured link according to 1661 page 47 par. 1)
Why getting into the trouble of overloading Conf-Rej instead of
just using a Conf-Ack (assuming all other options were successfully
agreed, or no other option exists) for the hypothetical Conf-Req in
question?

I do not understand why it is overloading conf-rej. Conf-rej is used when
the peer refuses a certain option. It is refusing magic. There is no other
option to be suggested ( conf-ack) it is simply saying it will not do
magic. That is what conf-rej means. It is not
overloading it. Now, this says what you should do whan you receive that
rejection-- ignore it, and assume that the branch is not looped back.

Post by Vangelis Angelakos
The answer to that cannot simply be that (in Conf-Rej case) "the
peer will not be using Magic-Numbers" since this can also be done
(with standard procedures) by having peer's Conf-Req NOT to include

How does it request NOt to include it? Conf ack is there for suggesting
possibilities to a configuration request with various option. This is not
one of many options, it is "I do not do magic", which is the same as all
other conf-rej messages.

Post by Vangelis Angelakos
a magic-number option.
Since RFC 1661 is a very carefully written document, there must be
a specific reason for this Conf-Rej overload selection, which I fail
to see...

I do not see how this is an overload. It describes what your reaction
should be to the remote's rejection of a configuration.

Post by Vangelis Angelakos

Post by James Carlson

Post by vangelis angelakos
"...If an implementation does receive a Configure-Reject in
response to a Configure-Request, it can only mean that the link is
not looped-back, and that its peer will not be using Magic-
Numbers. In this case, an implementation SHOULD act as if the
negotiation had been successful (as if it had instead received a
Configure-Ack)..."
Does anyone has a better idea on the reason of introducing such
an 'overload' for Conf-Rej?

It seems like an obvious bit of logic to me.

Post by vangelis angelakos
If peer Rejects Magic number option
why SHOULD the implementation act as if the negotiation was
successful (a.k.a will send Echo Requests with it's (rejected) magic
number)?

Because it knows necessarily that the line is not looped back.
Using the magic number in the LCP Echo Request messages is harmless
and meaningless to the peer. It's useful just for making sure that a
loopback condition doesn't show up _later_, while the link is
running. It still serves that purpose even if only one side is able
to do the check.
In other words, a system receiving an Echo Request message should not
be trying to match the magic number against anything other than 0 and
its own magic number. As long as the request is either 0 or not the
local magic number, send a reply.
--
Sun Microsystems / 1 Network Drive 71.232W Vox [phone]
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax [phone]

[Vangelis Angelakos]

Post by Unruh

Post by Vangelis Angelakos
Why getting into the trouble of overloading Conf-Rej instead of
just using a Conf-Ack (assuming all other options were successfully
agreed, or no other option exists) for the hypothetical Conf-Req in
question?

I do not understand why it is overloading conf-rej. Conf-rej is used when
the peer refuses a certain option. It is refusing magic. There is no other
option to be suggested ( conf-ack) it is simply saying it will not do
magic. That is what conf-rej means. It is not
overloading it. Now, this says what you should do whan you receive that
rejection-- ignore it, and assume that the branch is not looped back.

Normaly Conf-Rej does exactly what you are saying BUT RFC 1661,
page 46 states:
"If an implementation does receive a Configure-Reject in response to a
Configure-Request, it can only mean that the link is not looped-back, ***and
that its peer will not be using Magic-Numbers. In this case, an
implementation
SHOULD act as if the negotiation had been successful*** (as if it had
instead
received a Configure-Ack)"

So Conf-Rej equals Conf-Ack in that case (aka 'overloads' typical use of
Conf-Rej /
(if the 'overload' term sounds strange lets ignore it)).

given in a drawing this paragraph suggests:

PeerA(Conf-Req,MagicNumber) ---> PeerB
PeerA <--- (Conf-Rej,Magic Number)PeerB

instead of

PeerA(Conf-Req,MagicNumber) ---> PeerB
PeerA <--- (Conf-Ack,Magic Number)PeerB
PeerA <--- (Conf-Req)PeerB
PeerA(Conf-Ack)---> PeerB

both resulting in PeerA using Magic-numbers, PeerB
not using Magic-numbers...
My question is why itroducing this extra complexity?

vangelis

[Unruh]

Post by Vangelis Angelakos

Post by Unruh

Post by Vangelis Angelakos
Why getting into the trouble of overloading Conf-Rej instead of
just using a Conf-Ack (assuming all other options were successfully
agreed, or no other option exists) for the hypothetical Conf-Req in
question?

I do not understand why it is overloading conf-rej. Conf-rej is used when
the peer refuses a certain option. It is refusing magic. There is no other
option to be suggested ( conf-ack) it is simply saying it will not do
magic. That is what conf-rej means. It is not
overloading it. Now, this says what you should do whan you receive that
rejection-- ignore it, and assume that the branch is not looped back.

Normaly Conf-Rej does exactly what you are saying BUT RFC 1661,
"If an implementation does receive a Configure-Reject in response to a
Configure-Request, it can only mean that the link is not looped-back, ***and
that its peer will not be using Magic-Numbers. In this case, an
implementation
SHOULD act as if the negotiation had been successful*** (as if it had
instead
received a Configure-Ack)"

No. Conf-Rej means EXACTLY what it always means-- the peer refuses or
cannot use that particular feature. This advises you to , a) not use it,
but b) assume that the connection is NOT looped back ( which is the purpose
of magic to discover). Ie, you can assume that the line behaves as you want
it to. The message means exactly what it always means. Your reaction tothe
message is what is being discussed.
Note that your reaction to rejection messages ALWAYS can mean different
things. Sometimes a rejection results in immediate closing down of ppp (eg
you want them to authenticate via pap and they refuse) other times it does
not result in in that ( you request some compression and they refuse-- you
can then decide to tear down the link or you can decide to continue without
compression). There is no overloading of Conf-Rej in this case. It means
what it always means. There may be an overloading of your reaction to
Conf-Rej, but that has always and for each case of Conf-Rej, been
overloaded. It is up to you to decide what to do in the case of rejection
and it is entirely up to you.

Now you could decide that if the peer does a conf-rej of magic that you
will refuse to have anything more to do with them. The RFC points out that
this would be an idiotic reaction, since the only purpose of magic was to
detect loopbacks, and you now know that none has occured. But it is still
up to you as always.

Post by Vangelis Angelakos
So Conf-Rej equals Conf-Ack in that case (aka 'overloads' typical use of
Conf-Rej /
(if the 'overload' term sounds strange lets ignore it)).

No it does not. It means conf-rej. They refuse to use magic.

Post by Vangelis Angelakos
PeerA(Conf-Req,MagicNumber) ---> PeerB
PeerA <--- (Conf-Rej,Magic Number)PeerB
instead of
PeerA(Conf-Req,MagicNumber) ---> PeerB
PeerA <--- (Conf-Ack,Magic Number)PeerB

Sorry that would make no sense at all. That would overload conf-ack.
Including an option in the conf ack means that the peer is WILLING to
negotiate that particular option.

Post by Vangelis Angelakos
PeerA <--- (Conf-Req)PeerB
PeerA(Conf-Ack)---> PeerB
both resulting in PeerA using Magic-numbers, PeerB
not using Magic-numbers...
My question is why itroducing this extra complexity?

The complexity is only in your mind.

Post by Vangelis Angelakos
vangelis

[James Carlson]

Post by Vangelis Angelakos
Mr. Carlson, thank you for taking some of your time replying on this
question.

Please do not send me a copy of your postings by email. I do read
this group. Sending copies by email will just make me take longer in
replying.

Post by Vangelis Angelakos
Why getting into the trouble of overloading Conf-Rej instead of
just using a Conf-Ack (assuming all other options were successfully
agreed, or no other option exists) for the hypothetical Conf-Req in
question?

For at least one very good reason: some lame implementations might not
include the Magic Number option, and thus will refuse it.

Magic numbers are extremely helpful in diagnosing problems in the real
world. Thus, anything reasonable that can be done to make them work
is a valid thing to consider.

In this case, the operation is straightforward: if the peer rejects
(and you know you wouldn't have rejected), then you know that the peer
is indeed one of those lame implementations. You can thus proceed to
use the option properly, because you've validated what you originally
set out to prove (namely that the messages are coming from a peer PPP
implementation).

Post by Vangelis Angelakos
The answer to that cannot simply be that (in Conf-Rej case) "the
peer will not be using Magic-Numbers" since this can also be done
(with standard procedures) by having peer's Conf-Req NOT to include
a magic-number option.

PPP's negotiation is bi-directional.

This means that each side proposes a set of options and negotiates it
with its peer. Those proposals are (with a few notable exceptions)
independent.

In other words, no, it's not at all correct to say that a
Configure-Reject from a peer is equivalent to seeing the peer omit the
option in Configure-Request. Configure-Reject from the peer applies
to the options that were sent *to* the peer.

Post by Vangelis Angelakos
Since RFC 1661 is a very carefully written document, there must be
a specific reason for this Conf-Rej overload selection, which I fail
to see...

It's a trivial modification to the logic that makes Magic Number
operation much more robust when faced with poor implementations, and
is thus valuable.

There are a substantial number of complicated operations that a decent
PPP implementation must perform, not all of which are documented in
that (or any) RFC. In comparison to the rest of the field, I think
this one small exception for the Magic Number option is quite
trivial. It's a bit of noise in a much larger signal.

[vangelis angelakos]

Post by James Carlson
Please do not send me a copy of your postings by email. I do read
this group. Sending copies by email will just make me take longer in
replying.

I am sorry about that. It was not my intention to e-mail the post.
It was poor NewsReader configuration. It is resolved now.

Post by James Carlson

Post by Vangelis Angelakos
Why getting into the trouble of overloading Conf-Rej instead of
just using a Conf-Ack (assuming all other options were successfully
agreed, or no other option exists) for the hypothetical Conf-Req in
question?

For at least one very good reason: some lame implementations might not
include the Magic Number option, and thus will refuse it.
Magic numbers are extremely helpful in diagnosing problems in the real
world. Thus, anything reasonable that can be done to make them work
is a valid thing to consider.
In this case, the operation is straightforward: if the peer rejects
(and you know you wouldn't have rejected), then you know that the peer
is indeed one of those lame implementations. You can thus proceed to
use the option properly, because you've validated what you originally
set out to prove (namely that the messages are coming from a peer PPP
implementation).

This is an interesting approach. Got it!

Post by James Carlson

Post by Vangelis Angelakos
The answer to that cannot simply be that (in Conf-Rej case) "the
peer will not be using Magic-Numbers" since this can also be done
(with standard procedures) by having peer's Conf-Req NOT to include
a magic-number option.

PPP's negotiation is bi-directional.
This means that each side proposes a set of options and negotiates it
with its peer. Those proposals are (with a few notable exceptions)
independent.
In other words, no, it's not at all correct to say that a
Configure-Reject from a peer is equivalent to seeing the peer omit the
option in Configure-Request. Configure-Reject from the peer applies
to the options that were sent *to* the peer.

I was refering to the specific case on the paragraph in question (RFC 1661,
page 46, par. 3)and not to the use of Conf-Rej in general. In a more
'graphical way'
I was suggesting:

PeerA(Conf-Req,MagicNumber) ---> PeerB
PeerA <--- (Conf-Rej,Magic Number)PeerB

instead of

PeerA(Conf-Req,MagicNumber) ---> PeerB
PeerA <--- (Conf-Ack,Magic Number)PeerB
PeerA <--- (Conf-Req)PeerB
PeerA(Conf-Ack)---> PeerB

both resulting in PeerA using Magic-numbers, PeerB not using
Magic-numbers...

Regards,
Vangelis

[James Carlson]

Post by vangelis angelakos

Post by James Carlson

Post by Vangelis Angelakos
The answer to that cannot simply be that (in Conf-Rej case) "the
peer will not be using Magic-Numbers" since this can also be done
(with standard procedures) by having peer's Conf-Req NOT to include
a magic-number option.

PPP's negotiation is bi-directional.
This means that each side proposes a set of options and negotiates it
with its peer. Those proposals are (with a few notable exceptions)
independent.
In other words, no, it's not at all correct to say that a
Configure-Reject from a peer is equivalent to seeing the peer omit the
option in Configure-Request. Configure-Reject from the peer applies
to the options that were sent *to* the peer.

I was refering to the specific case on the paragraph in question (RFC 1661,
page 46, par. 3)and not to the use of Conf-Rej in general. In a more
'graphical way'
PeerA(Conf-Req,MagicNumber) ---> PeerB
PeerA <--- (Conf-Rej,Magic Number)PeerB
instead of
PeerA(Conf-Req,MagicNumber) ---> PeerB
PeerA <--- (Conf-Ack,Magic Number)PeerB
PeerA <--- (Conf-Req)PeerB
PeerA(Conf-Ack)---> PeerB
both resulting in PeerA using Magic-numbers, PeerB not using
Magic-numbers...

That first case doesn't make any sense. As I said, PPP negotiation is
bidirectional. It's symmetric. Both sides *must* send
Configure-Request for the options they intend to use and *both* must
receive Configure-Ack.

More generally (and not with specific reference to the Magic Number
option), a system that sends Configure-Request is saying "I am willing
to receive data encoded in the manner specified by these options."
Each side must say what it's willing to receive. The peer that gets
the Configure-Request message must determine what it's willing to
send. If it can't send certain things, then it sends Configure-Reject
or Configure-Nak, depending on whether it has any alternatives. When
the proposal from the peer matches what it can send, then it sends
Configure-Ack.

That applies for most options, such as MRU, PFC, and ACCM. A few
options are "unusual," and the Magic Number option is one of them.

With the Magic Number option, there's no "encoding" (or other special
link usage) going on, and instead the sender of Configure-Request is
effectively saying "here's a random number that should identify my
messages uniquely." If the peer understands the option, and if the
value doesn't match what was chosen locally, then it sends
Configure-Ack.

With normal Magic Number usage, each side independently chooses a
random number, and each sends it in Configure-Request.

There's just no way that first sequence you're showing (with just a
single Configure-Request) could be a valid and complete negotiation
for PPP. It fails in two respects:

- Peer B has not sent a Configure-Request. It must do so. There's
no "Configure-Reject is good enough" feature.

- Peer A has not received a Configure-Ack. Since the last message
received was Configure-Reject (event RCN), it *must* send a new
Configure-Request.

See the state machine in section 4 of RFC 1661. When Peer A sends
Configure-Request, it's in Req-Sent state. When it gets
Configure-Reject (event RCN), it does "irc,scr/6" -- which means,
Initialize-Restart-Count (start the counter over), and
Send-Configure-Request (send a new Configure-Request message), and
then enter state 6 (Req-Sent).

[Vangelis Angelakos]

Post by James Carlson

Post by Vangelis Angelakos
PeerA(Conf-Req,MagicNumber) ---> PeerB
PeerA <--- (Conf-Rej,Magic Number)PeerB
instead of
PeerA(Conf-Req,MagicNumber) ---> PeerB
PeerA <--- (Conf-Ack,Magic Number)PeerB
PeerA <--- (Conf-Req)PeerB
PeerA(Conf-Ack)---> PeerB
both resulting in PeerA using Magic-numbers, PeerB not using
Magic-numbers...

That first case doesn't make any sense. As I said, PPP negotiation is
bidirectional. It's symmetric. Both sides *must* send
Configure-Request for the options they intend to use and *both* must
receive Configure-Ack.

You are right, the first case is only a part of the complete negotiation.
I was trying to focus on the Conf-Rej overload, I think the complete
scenario would look like this:

PeerA(Conf-Req,MagicNumber) ---> PeerB
PeerA <--- (Conf-Rej,Magic Number)PeerB
PeerA(Conf-Req) ---> PeerB
PeerA <--- (Conf-Ack)PeerB
PeerA <--- (Conf-Req)PeerB
PeerA(Conf-Ack)---> PeerB

instead of

PeerA(Conf-Req,MagicNumber) ---> PeerB
PeerA <--- (Conf-Ack,Magic Number)PeerB
PeerA <--- (Conf-Req)PeerB
PeerA(Conf-Ack)---> PeerB

Again case A overloads Conf-Rej, case B does nothing
'strange', and both result the same.

Post by James Carlson
More generally (and not with specific reference to the Magic Number
option), a system that sends Configure-Request is saying "I am willing
to receive data encoded in the manner specified by these options."
Each side must say what it's willing to receive. The peer that gets
the Configure-Request message must determine what it's willing to
send. If it can't send certain things, then it sends Configure-Reject
or Configure-Nak, depending on whether it has any alternatives. When
the proposal from the peer matches what it can send, then it sends
Configure-Ack.
That applies for most options, such as MRU, PFC, and ACCM. A few
options are "unusual," and the Magic Number option is one of them.
With the Magic Number option, there's no "encoding" (or other special
link usage) going on, and instead the sender of Configure-Request is
effectively saying "here's a random number that should identify my
messages uniquely." If the peer understands the option, and if the
value doesn't match what was chosen locally, then it sends
Configure-Ack.
With normal Magic Number usage, each side independently chooses a
random number, and each sends it in Configure-Request.

Would it be a problem using the first paragraph as an opening paragraph to
my paper (I will mention the owner of cource, but I will have to translate
in
Greek)?


Once again, thank you for your time,
vangelis

[James Carlson]

Post by Vangelis Angelakos
You are right, the first case is only a part of the complete negotiation.
I was trying to focus on the Conf-Rej overload, I think the complete
PeerA(Conf-Req,MagicNumber) ---> PeerB
PeerA <--- (Conf-Rej,Magic Number)PeerB
PeerA(Conf-Req) ---> PeerB
PeerA <--- (Conf-Ack)PeerB
PeerA <--- (Conf-Req)PeerB
PeerA(Conf-Ack)---> PeerB

Yes; that's the normal way it looks.

Post by Vangelis Angelakos
instead of
PeerA(Conf-Req,MagicNumber) ---> PeerB
PeerA <--- (Conf-Ack,Magic Number)PeerB
PeerA <--- (Conf-Req)PeerB
PeerA(Conf-Ack)---> PeerB

No, that should not happen.

In this case, you're presuming that Peer B somehow understands Magic
Number well enough that it can send Configure-Ack, but when it goes to
send its own Configure-Request, it forgets all about the Magic Number
option.

That doesn't correspond to an expected scenario.

I suppose it's possible, but it would require Peer B to be "strange"
-- it would need to have _partial_ understanding of the option. I
don't know how that could happen.

Post by Vangelis Angelakos
Again case A overloads Conf-Rej, case B does nothing
'strange', and both result the same.

B looks very odd to me.

A looks normal, but with one caveat: the two directions are
independent. So, this is also possible:

PeerA <--- (Conf-Req)PeerB
PeerA(Conf-Req,MagicNumber) ---> PeerB
PeerA(Conf-Ack)---> PeerB
PeerA <--- (Conf-Rej,Magic Number)PeerB
PeerA(Conf-Req) ---> PeerB
PeerA <--- (Conf-Ack)PeerB

... among other possible reorderings. Except for some special state
transitions (basically, when _leaving_ the Opened state), each side
sends Configure-Request messages independently of the other. This
means that you shouldn't always expect to see a nice linear ordering
with one side negotiating its options to completion followed by the
other side.

Post by Vangelis Angelakos

Post by James Carlson
With normal Magic Number usage, each side independently chooses a
random number, and each sends it in Configure-Request.

Would it be a problem using the first paragraph as an opening paragraph to
my paper (I will mention the owner of cource, but I will have to translate
in
Greek)?

Not at all. My publisher might get upset if you used text directly
from my book (without either proper permissions or some standard usage
exemption), but the text I post here is free. ;-}

Note, though, that there are exceptions to that general rule regarding
the way options are negotiated. For instance, the authors of RFC 1877
(not a standard, but a common feature) managed to get their options
backwards, so the system that sends those options is not the one that
actually has the addresses in question.

There are also exceptions to the rule regarding the independence of
the peers as well, as with the IPX Network Number.

[Vangelis Angelakos]

It is not that working for Sun microsystems is not enough but.. I just saw
that
you had a <respect mode> book published on PPP </respect mode>!!!!
What can I say :)

I think I 've got the point of the paragraph in question. I was just reading
the spec
while the spec was trying to guide through real life problems. Although the
negotiation
without Conf-Rej seem better in terms of a clean-cut-nicely put case. I
makes no much
sense for a peer to understand Magic_Numbers and not using them...

Thank you for your help. I will stay tunned on the newgroup...
vangelis

[James Carlson]

Post by Vangelis Angelakos
It is not that working for Sun microsystems is not enough but.. I just saw
that
you had a <respect mode> book published on PPP </respect mode>!!!!
What can I say :)

;-}

Post by Vangelis Angelakos
I think I 've got the point of the paragraph in question. I was just reading
the spec
while the spec was trying to guide through real life problems. Although the
negotiation
without Conf-Rej seem better in terms of a clean-cut-nicely put
case.

I'm not so sure I'm sold on the clean-cut nature of avoiding
Configure-Reject, but ...

Post by Vangelis Angelakos
I
makes no much
sense for a peer to understand Magic_Numbers and not using them...

Yes; that's it exactly.

Post by Vangelis Angelakos
Thank you for your help. I will stay tunned on the newgroup...

Parakalo.

[Ignatios Souvatzis]

Post by James Carlson
I suppose it's possible, but it would require Peer B to be "strange"
-- it would need to have _partial_ understanding of the option. I
don't know how that could happen.

Not related to PPP, but:

I've seen a partial implementation of sending ICMP redirect
messages in an now ancient Linux kernel. Not bothering at all
would have allowed communications, implementing correctly in one
of two possible ways would have allowed communications, but the
fourth possible option, and the only forbidden one, was chosen,
and that's the one that creates a black hole. I peeked over Stefan
Beckers shoulder when he tried to diagnose this reading the source
(together with M. van Elst and a few others), and we finally
understood enough to implement the first option (not bothering
at all) and he recompiled the kernel and booted it, and internal
communications in what might be vaguely similar to a LAN party
started to work. I think he submitted his patch to Mr Torvalds,
or maybe an appropriate mailing list, with a somewhat ... astonished
... comment.

Err, anyways - there's always somebody who starts implementing, gets
distracted, and forgets that the version in his file copy should not
be published... peer review should catch this.

-is

[Unruh]

Post by vangelis angelakos

Post by James Carlson
Please do not send me a copy of your postings by email. I do read
this group. Sending copies by email will just make me take longer in
replying.

I am sorry about that. It was not my intention to e-mail the post.
It was poor NewsReader configuration. It is resolved now.

Post by James Carlson

Post by Vangelis Angelakos
Why getting into the trouble of overloading Conf-Rej instead of
just using a Conf-Ack (assuming all other options were successfully
agreed, or no other option exists) for the hypothetical Conf-Req in
question?

For at least one very good reason: some lame implementations might not
include the Magic Number option, and thus will refuse it.
Magic numbers are extremely helpful in diagnosing problems in the real
world. Thus, anything reasonable that can be done to make them work
is a valid thing to consider.
In this case, the operation is straightforward: if the peer rejects
(and you know you wouldn't have rejected), then you know that the peer
is indeed one of those lame implementations. You can thus proceed to
use the option properly, because you've validated what you originally
set out to prove (namely that the messages are coming from a peer PPP
implementation).

This is an interesting approach. Got it!

Post by James Carlson

Post by Vangelis Angelakos
The answer to that cannot simply be that (in Conf-Rej case) "the
peer will not be using Magic-Numbers" since this can also be done
(with standard procedures) by having peer's Conf-Req NOT to include
a magic-number option.

PPP's negotiation is bi-directional.
This means that each side proposes a set of options and negotiates it
with its peer. Those proposals are (with a few notable exceptions)
independent.
In other words, no, it's not at all correct to say that a
Configure-Reject from a peer is equivalent to seeing the peer omit the
option in Configure-Request. Configure-Reject from the peer applies
to the options that were sent *to* the peer.

I was refering to the specific case on the paragraph in question (RFC 1661,
page 46, par. 3)and not to the use of Conf-Rej in general. In a more
'graphical way'
PeerA(Conf-Req,MagicNumber) ---> PeerB
PeerA <--- (Conf-Rej,Magic Number)PeerB

You are trying to control how B reacts. YOu cannot. That is completely up
to them, not you. All that is up to you is to determine how to act in the
face of responses from B.
Why B would refuse magic is completely beyond me. As James says, it almost
certainly means that the peer is broken, and that the writer of the ppp
implimentation then use is incompetent. But you have to figure out what to
do in the face of that. Do you tell the peer to go to hell and close the
connection ( which you have every right to do) or do you simply continue.

Post by vangelis angelakos
instead of
PeerA(Conf-Req,MagicNumber) ---> PeerB
PeerA <--- (Conf-Ack,Magic Number)PeerB
PeerA <--- (Conf-Req)PeerB
PeerA(Conf-Ack)---> PeerB

Of course. But soem peers are broken. They do stupid things. What do you do
when they do stupid things. You can destroy the connection because the
writer was stupid, or continue because you have the information that magic
was there to give to you.

Post by vangelis angelakos
both resulting in PeerA using Magic-numbers, PeerB not using
Magic-numbers...

Of course, But the world is not perfect, nor are writers of ppp
implimentations. Some of those implimentations arose because some poor guy
just out of university was told to cobble up a ppp implimentation in two
days, or he is fired. He has no idea about ppp, and even though he reads
Carlson's book does not absorb it sufficiently to understand it. What do
you do when you try to connect with his implimentation? Scream and quit or
continue? Screaming and quiting would display the same level of
incompetence on your part in this case, and the rfc is pointing that out.

Post by vangelis angelakos
Regards,
Vangelis

[Vangelis Angelakos]

Post by Unruh

Post by Vangelis Angelakos
PeerA(Conf-Req,MagicNumber) ---> PeerB
PeerA <--- (Conf-Ack,Magic Number)PeerB
PeerA <--- (Conf-Req)PeerB
PeerA(Conf-Ack)---> PeerB

Of course. But soem peers are broken. They do stupid things. What do you do
when they do stupid things. You can destroy the connection because the
writer was stupid, or continue because you have the information that magic
was there to give to you.

Post by Vangelis Angelakos
both resulting in PeerA using Magic-numbers, PeerB not using
Magic-numbers...

Of course, But the world is not perfect, nor are writers of ppp
implimentations. Some of those implimentations arose because some poor guy
just out of university was told to cobble up a ppp implimentation in two
days, or he is fired. He has no idea about ppp, and even though he reads
Carlson's book does not absorb it sufficiently to understand it. What do
you do when you try to connect with his implimentation? Scream and quit or
continue? Screaming and quiting would display the same level of
incompetence on your part in this case, and the rfc is pointing that out.

I think I've got the point. Thank you!

P.S. you've been very tough on your characterizations :)