Theoretical question on PPP - PPP

This is a discussion on Theoretical question on PPP - PPP ; 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 ...

+ Reply to Thread
Results 1 to 15 of 15

Thread: Theoretical question on PPP

  1. Theoretical question on PPP

    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




  2. Re: Theoretical question on PPP

    "vangelis angelakos" writes:
    > "...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.

    > 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.

    --
    James Carlson, Solaris Networking
    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

  3. Re: Theoretical question on PPP

    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...





    "James Carlson" wrote in message
    news:xoavlkis7gk6.fsf@sun.com...
    > "vangelis angelakos" writes:
    >> "...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.
    >
    >> 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.
    >
    > --
    > James Carlson, Solaris Networking
    > 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




  4. Re: Theoretical question on PPP

    "Vangelis Angelakos" writes:

    >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?


    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.


    > 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.



    >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.







    >"James Carlson" wrote in message
    >news:xoavlkis7gk6.fsf@sun.com...
    >> "vangelis angelakos" writes:
    >>> "...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.
    >>
    >>> 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.
    >>
    >> --
    >> James Carlson, Solaris Networking
    >> 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




  5. Re: Theoretical question on PPP

    "Unruh" wrote in message
    news:erhv68$k4d$1@aioe.org...


    >>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?


    > 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



  6. Re: Theoretical question on PPP

    "Vangelis Angelakos" writes:
    > 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.

    > 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?


    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).

    > 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.

    > 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.

    --
    James Carlson, Solaris Networking
    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

  7. Re: Theoretical question on PPP

    > 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.


    >> 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?

    >
    > 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!

    >> 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



  8. Re: Theoretical question on PPP

    "vangelis angelakos" writes:
    > >> 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...


    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).

    --
    James Carlson, Solaris Networking
    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

  9. Re: Theoretical question on PPP

    >> 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...

    >
    > 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.



    > 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



  10. Re: Theoretical question on PPP

    "Vangelis Angelakos" writes:
    > 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


    Yes; that's the normal way it looks.

    > 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.

    > 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.

    > > 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.

    --
    James Carlson, Solaris Networking
    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

  11. Re: Theoretical question on PPP

    "Vangelis Angelakos" writes:

    >"Unruh" wrote in message
    >news:erhv68$k4d$1@aioe.org...



    >>>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?


    >> 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)"


    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.



    >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.


    >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


    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.


    >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.


    >vangelis




  12. Re: Theoretical question on PPP

    "vangelis angelakos" writes:

    >> 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.



    >>> 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?

    >>
    >> 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!


    >>> 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


    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.


    >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.



    >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.



    >Regards,
    >Vangelis




  13. Re: Theoretical question on PPP

    >>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.
    >
    >
    >
    >>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



  14. Re: Theoretical question on PPP

    It is not that working for Sun microsystems is not enough but.. I just saw
    that
    you had a book published on PPP !!!!
    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



  15. Re: Theoretical question on PPP

    "Vangelis Angelakos" writes:
    > It is not that working for Sun microsystems is not enough but.. I just saw
    > that
    > you had a book published on PPP !!!!
    > 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'm not so sure I'm sold on the clean-cut nature of avoiding
    Configure-Reject, but ...

    > I
    > makes no much
    > sense for a peer to understand Magic_Numbers and not using them...


    Yes; that's it exactly.

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


    Parakalo.

    --
    James Carlson, Solaris Networking
    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

+ Reply to Thread