--- 1/draft-ietf-ipngwg-pppext-ipv6cp-02.txt	2006-12-03 11:54:48.000000000 +0100
+++ 2/draft-ietf-ipngwg-pppext-ipv6cp-03.txt	2006-12-03 11:54:48.000000000 +0100
@@ -1,15 +1,15 @@
 
 Internet Engineering Task Force
 INTERNET-DRAFT                                           Dimitry Haskin
-Expires October 1996                                           Ed Allen
-<draft-ietf-ipngwg-pppext-ipv6cp-02.txt>             Bay Networks, Inc.
+Expires November 1996                                          Ed Allen
+<draft-ietf-ipngwg-pppext-ipv6cp-03.txt>             Bay Networks, Inc.
 
                      IP Version 6 over PPP
 
 Status of this Memo
 
      This document is an Internet-Draft.  Internet-Drafts are working
      documents of the Internet Engineering Task Force (IETF), its
      areas, and its working groups.  Note that other groups may also
      distribute working documents as Internet-Drafts.
 
@@ -250,20 +250,23 @@
       this option, Configure-Rej is sent.
 
       A new Configure-Request SHOULD NOT be sent to the peer until normal
       processing would cause it to be sent (that is, until a Configure-
       Nak is received or the Restart timer runs out).
 
       A new Configure-Request MUST NOT contain the Interface-Token option
       if a valid Interface-Token Configure-Reject is received.
 
       Reception of a Configure-Nak with a suggested Interface-Token
+      different from that of the last Configure-Nak sent to the peer
+      indicates a unique Interface-Token.  In this case a new Configure-
+      Request MUST be sent with the token value suggested in the last
       Configure-Nak from the peer.   But if the received Interface-Token
       is equal to the one sent in the last Configure-Nak, a new
       Interface-Token MUST be chosen.  In this case, a new Configure-
       Request SHOULD be sent with the new tentative Interface-Token.
       This sequence (transmit Configure-Request, receive Configure-
       Request, transmit Configure-Nak, receive Configure-Nak)  might
       occur a few times, but it is extremely unlikely to occur
       repeatedly.  More likely, the Interface-Tokens chosen at either end
       will quickly diverge, terminating the sequence.
 
@@ -294,27 +297,29 @@
 
    Type
 
       1
 
    Length
 
       6
    Interface-Token
 
-      The 32-bit Interface-Token which is very likely  to  be unique
-      to one end of the link or zero if a good sources of uniqueness
-      can not be found.
+      The 32-bit Interface-Token which is very likely to  be unique on
+      the link or zero if a good source of uniqueness can not be found.
 
-   Default
+   Default Token Value
 
-      No Interface-Token is selected.
+      If no valid interface token can be successfully negotiated,
+      no default Interface-Token value should be assumed. The procedures
+      for recovering from such a case are unspecified. One approach is
+      to manually configure the interface token of the interface.
 
 4.2.  IPv6-Compression-Protocol
 
    Description
 
       This Configuration Option provides a way to negotiate the use of
       a specific IPv6 packet compression protocol.  The IPv6-Compression-
       Protocol Configuration Option is used to indicate the ability to
       receive compressed packets.  Each end of the link must separately
       request this option if bi-directional compression is desired.  By