Subject: Re: LCP Reconfiguration

From: Vernon Schryver <[email-masked]>
Date: Wed, 29 Apr 1998 07:56:24 -0600 (MDT)

> From: James Carlson <[email-masked]>

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

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

> Note that it terminates the network layer connection.  This does *NOT*
> imply that it should terminate any transport or application layer
> sessions. ...

You obviously do not mean what many less technically knowledgable people
will misunderstand by your first sentence.  "Users" tend to "log in" using
telnet or rlogin.  While the robotic, non-human "user" that is responsible
for the PPP link will have to authenticate itself (i.e. "log on") again,
the human user should not need to, given properly functioning PPP peers.

Yes, that means (as we have often agreed in the mailing list) that smart
cards which involve humans to transmit the secret of the instant to the
PPP peer for PPP authentication are at best inconvenient.

Vernon Schryver    [email-masked]

---

From: Vernon Schryver <[email-masked]>
Date: Wed, 29 Apr 1998 09:33:17 -0600 (MDT)

> From: "Scott Reeve"<[email-masked]>

> >always exactly the same as terminating and restarting the link.)

Note for the record that he did not say "avoid any Configure-Requests."

> Neat idea - I wonder if any implementation does this.  Most do a
> cold warm-start, not a warm warm-start :-)

What is a "cold warm-start" or a "warm warm-start"?
If you mean are there any implementations which remember what they
negotiated previously and prefer those values either after dropping
the phone line and redialing, or after receiving an unexpected LCP
Configure-Request on a line (or VC) that has not hiccuped, then
the answer is yes.

The necessary machinery is fundamental to all PPP negotiations.  Every
Configure-Request stands on its own, independent of previous packets.
The only default value for very parameter is specified in the relevant
RFC.  On the other hand, if you do not remember the results of previous
Configure-Rejects and -Naks, you'll have problems.  Thus, it is both most
correct and easiest to give all Configure-Request the same context.
Remember the last good values you had, whether from Naks, Rejects, or
Acks, and use them for the next Configure-Request, regardless of whether
the phone line (or ATM VC) has bounced.

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

IP has no real state to restart.  IP routes are transient and can
change with or without IPCP or LCP changing.

Also, if you delete your IP route when you receive an unexpected
Configure-Request, then won't you stop queuing traffic for the
link, and so won't your demand dialing code decide the link is
unneeded and drop it?  In other words, you need to keep an IP route
through a PPP link especially when it is not running.

Even if you did make a mistake and kill all IP routes through a PPP link
that is (re)negotiating LCP or IPCP, that would not affect TCP/IP
applications involving reasonable hosts.  An occassional ICMP Unreachable
(not to mention a short term blackhole) "SHOULD NOT" affect any TCP state
machines in the ESTABLISH state.

> >> I just want to make sure that this interpretation is correct, and that
> >> existing implementations actually behave accordingly.
> ...

If your interpretation is what I think it is, then the answer is
yes, they do.  In my view, any implementation that does not is ...
less than admirable.