Subject: RE: LCP Reconfiguration

From: Theimer Thomas <[email-masked]>
Date: Wed, 29 Apr 1998 16:43:54 +0200

John,

thanks for your comments. I agree that the client software can store the
secret and simply re-authenticate. However, there are cases where NCP
(and LCP) state may be lost on one side of the link without the other
side knowing. I am refering to a situation where the PPP link is
actually an ATM PVC, e.g. running over an ADSL line. Now suppose that
the NAS reboots for some reason and looses all active sessions. The NAS
will try to open all PPP links again, but the clients may not know that
the NAS went down, because the ATM PVC does not provide any indication
of that event.

The safest thing to do is probably to explicitly terminate all PPP links
(send a terminate request) before sending any LCP configure requests.
This would bring all clients into a well-defined state, even if they are
still in the open state. I was just trying to avoid that by sticking to
the normal startup sequence for opening a PPP link, and see if that
solves the problem.

If NCP tries to maintain state, this would raise the same question for
NCP: what happens if a NCP in the open state gets a configure-request
message ? Will it also return to the establish-phase, and restart NCP
negotiation ? I have not seen a clear definition of state transitions
for IPCP, so I can only guess what might happen in this case.

Thomas Theimer

> -----Original Message-----
> From:	John Shriver [SMTP:[email-masked]]
> Sent:	Wednesday, April 29, 1998 3:32 PM
> To:	Theimer Thomas
> Subject:	Re: LCP Reconfiguration
> 
> That's exactly the right interpretation.
> 
> But the USER doesn't have to re-authenticate.  The software does.  It
> can store the "secret" for the length of the session.
> 
> Similarly, the NCP's don't have to throw away all their state.  It
> would be stupid for IPCP to negotiate new IP addresses.  They should
> hang on to all the resources until the link goes down.
> 
> You probably want to try and get a copy of Carlson's book on PPP.

---

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

> (send a terminate request) before sending any LCP configure

No.  LCP Configure-Request is necessary and sufficient for this case.
Sending a Terminate-Request would be wrong, and may well shove the
peer into state 5 and cause a long delay in bringing the link back.

> the normal startup sequence for opening a PPP link, and see if that

No, LCP Configure-Request itself brings everyone into a well-defined
state.

> negotiation ?

Yes.  It returns to state 6 or 8, depending on whether or not it likes
the Configure-Request.

> I have not seen a clear definition of state transitions

They're the same as the transitions for LCP in RFC 1661.

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