Subject: Re: LCP Reconfiguration

From: "Scott Reeve"<[email-masked]>
Date: Wed, 29 Apr 1998 10:50:40 -0400

[email-masked] on 04/29/98 09:09:58 AM

To:   [email-masked]
cc:   [email-masked] (bcc: Scott Reeve/Shiva Corporation)
Subject:  Re: LCP Reconfiguration

>> Does that mean all network layer connections are terminated completely,
>> LCP options are renegotiated, and authentication is restarted ? That
>> implies also that the user has to logon again, and all network layer
>> protocols have to be restarted. The effect of this is similar to
>> terminating and restarting the link.
>If a user was involved in logging in, then, yes, he must do that
>again.  The link starts over.  (Of course, it's legal and reasonable
>for the implementation to remember what was negotiated last time so
>that it can avoid any Configure-Naks or Configure-Rejects, so it's not
>always exactly the same as terminating and restarting the link.)

Neat idea - I wonder if any implementation does this.  Most do a
cold warm-start, not a warm warm-start :-)
>The control protocols for the network layer interfaces (such as IPCP)
>do have to start over after authentication (if any), but this does not
>mean that the network layer itself (such as IP) is restarted.

If IPCP must be re-negotiated, wouldn't it be more accurate to say that
IP is restarted?  The route must not be active again until IPCP has come
all
the way back up.  Not sure if that argument carries over to other NCPs
also, but it probably does.

>> I just want to make sure that this interpretation is correct, and that
>> existing implementations actually behave accordingly.
>Note that it terminates the network layer connection.  This does *NOT*
>imply that it should terminate any transport or application layer
>sessions.  Some *very* common implementations of PPP, however, do
>improperly kill off everything anyway.
>For what it's worth, I've seen many implementations of PPP which fall
>over and die if LCP Configure-Request is seen after LCP goes to Open
>state.  It's hard to mandate that all implementations work right ...

Trumpet PPP, for one.

---

From: Rene Tio <[email-masked]>
Date: Wed, 29 Apr 1998 10:59:34 -0700 (PDT)

> From [email-masked]  Wed Apr 29 09:28:58 1998
> 
> 

IMHO, PPP over ATM PVCs should really conform to a leased-line
implementation and should not assume a lower-layer down indication to
trigger re-negotiation.  There were some old implementations (such as
Trumpet, as noted below) which didn't renegotiate properly, but I know of at
least one implementation which has since been fixed.  As for the user having
to log in again, I'd suggest that that is a limitation of the login
mechanism and not due to any deficiency in the PPP state machine.

> also, but it probably does.

Good way to prevent black holes, or if IP addresses are dynamically
assigned, mis-routed packets or address conflicts.

Rene

---

From: James Carlson <[email-masked]>
Date: Wed, 29 Apr 1998 14:21:12 -0400

> IP is restarted?

No.

>  The route must not be active again until IPCP has come
> all
> the way back up.

Not true.  RFC 1661 covers what happens inside PPP -- IPCP included.
It does *not* cover what happens in a given implementation's
connection to the network layer -- IP included.  If the network layer
chooses to continue to advertise the routes and to enqueue any
received packets for a short time on the theory that the interface
will soon come back, then this is probably a Good Thing.

I would say that if you immediately kill off the IP interface and the
associated routes, you would not be as wrong as if you had destroyed
all of the attached TCP connections.  The former is possibly a good
implementation choice in some scenarios.  The latter is generally bad.

-- 
James Carlson, Consulting S/W Engineer  <[email-masked]>
IronBridge Networks / 55 Hayden Avenue  71.246W    Vox:  +1 781 402 8032
Lexington MA  02173-7999 / USA          42.423N    Fax:  +1 781 402 8092
"PPP Design and Debugging" ------------- http://id.wing.net/~carlson/ppp