ppp: initial IPV6CP support

1 files changed, 899 insertions, 0 deletions

diff --git a/rfc/rfc5072.txt b/rfc/rfc5072.txt
new file mode 100644
index 00000000..c3846295
--- /dev/null
+++ b/rfc/rfc5072.txt
@@ -0,0 +1,899 @@
+
+
+
+
+
+
+Network Working Group                                     S. Varada, Ed.
+Request for Comments: 5072                                    Transwitch
+Obsoletes: 2472                                               D. Haskins
+Category: Standards Track                                       E. Allen
+                                                          September 2007
+
+
+                         IP Version 6 over PPP
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Abstract
+
+   The Point-to-Point Protocol (PPP) provides a standard method of
+   encapsulating network-layer protocol information over point-to-point
+   links.  PPP also defines an extensible Link Control Protocol, and
+   proposes a family of Network Control Protocols (NCPs) for
+   establishing and configuring different network-layer protocols.
+
+   This document defines the method for sending IPv6 packets over PPP
+   links, the NCP for establishing and configuring the IPv6 over PPP,
+   and the method for forming IPv6 link-local addresses on PPP links.
+
+   It also specifies the conditions for performing Duplicate Address
+   Detection on IPv6 global unicast addresses configured for PPP links
+   either through stateful or stateless address autoconfiguration.
+
+   This document obsoletes RFC 2472.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Varada, et al.              Standards Track                     [Page 1]
+
+RFC 5072                 IP Version 6 over PPP            September 2007
+
+
+Table of Contents
+
+   1. Introduction ....................................................2
+      1.1. Specification of Requirements ..............................3
+   2. Sending IPv6 Datagrams ..........................................3
+   3. A PPP Network Control Protocol for IPv6 .........................3
+   4. IPV6CP Configuration Options ....................................4
+      4.1. Interface Identifier .......................................4
+   5. Stateless Autoconfiguration and Link-Local Addresses ............9
+   6. Security Considerations ........................................11
+   7. IANA Considerations ............................................11
+   8. Acknowledgments ................................................11
+   9. References .....................................................12
+      9.1. Normative References ......................................12
+      9.2. Informative references ....................................12
+   Appendix A:  Global Scope Addresses................................14
+   Appendix B:  Changes from RFC-2472.................................14
+
+1.  Introduction
+
+   PPP has three main components:
+
+   1) A method for encapsulating datagrams over serial links.
+
+   2) A Link Control Protocol (LCP) for establishing, configuring, and
+      testing the data-link connection.
+
+   3) A family of Network Control Protocols (NCPs) for establishing and
+      configuring different network-layer protocols.
+
+   In order to establish communications over a point-to-point link, each
+   end of the PPP link must first send LCP packets to configure and test
+   the data link.  After the link has been established and optional
+   facilities have been negotiated as needed by the LCP, PPP must send
+   NCP packets to choose and configure one or more network-layer
+   protocols.  Once each of the chosen network-layer protocols has been
+   configured, datagrams from each network-layer protocol can be sent
+   over the link.
+
+   In this document, the NCP for establishing and configuring the IPv6
+   over PPP is referred to as the IPv6 Control Protocol (IPV6CP).
+
+   The link will remain configured for communications until explicit LCP
+   or NCP packets close the link down, or until some external event
+   occurs (power failure at the other end, carrier drop, etc.).
+
+   This document obsoletes the earlier specification from RFC 2472 [7].
+   Changes from RFC 2472 are listed in Appendix B.
+
+
+
+Varada, et al.              Standards Track                     [Page 2]
+
+RFC 5072                 IP Version 6 over PPP            September 2007
+
+
+1.1.  Specification of Requirements
+
+   In this document, several words are used to signify the requirements
+   of the specification.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [6].
+
+2.  Sending IPv6 Datagrams
+
+   Before any IPv6 packets may be communicated, PPP MUST reach the
+   network-layer protocol phase, and the IPv6 Control Protocol MUST
+   reach the Opened state.
+
+   Exactly one IPv6 packet is encapsulated in the Information field of
+   PPP Data Link Layer frames where the Protocol field indicates Type
+   hex 0057 (Internet Protocol Version 6).
+
+   The maximum length of an IPv6 packet transmitted over a PPP link is
+   the same as the maximum length of the Information field of a PPP data
+   link layer frame.  PPP links supporting IPv6 MUST allow the
+   information field to be at least as large as the minimum link MTU
+   size required for IPv6 [2].
+
+3.  A PPP Network Control Protocol for IPv6
+
+   The IPv6 Control Protocol (IPV6CP) is responsible for configuring,
+   enabling, and disabling the IPv6 protocol modules on both ends of the
+   point-to-point link.  IPV6CP uses the same packet exchange mechanism
+   as the LCP.  IPV6CP packets may not be exchanged until PPP has
+   reached the network-layer protocol phase.  IPV6CP packets that are
+   received before this phase is reached should be silently discarded.
+
+   The IPv6 Control Protocol is exactly the same as the LCP [1] with the
+   following exceptions:
+
+      Data Link Layer Protocol Field
+
+         Exactly one IPV6CP packet is encapsulated in the Information
+         field of PPP Data Link Layer frames where the Protocol field
+         indicates type hex 8057 (IPv6 Control Protocol).
+
+
+
+
+
+
+
+
+
+Varada, et al.              Standards Track                     [Page 3]
+
+RFC 5072                 IP Version 6 over PPP            September 2007
+
+
+      Code field
+
+         Only Codes 1 through 7 (Configure-Request, Configure-Ack,
+         Configure-Nak, Configure-Reject, Terminate-Request, Terminate-
+         Ack and Code-Reject) are used.  Other Codes should be treated
+         as unrecognized and should result in Code-Rejects.
+
+      Timeouts
+
+         IPV6CP packets may not be exchanged until PPP has reached the
+         network-layer protocol phase.  An implementation should be
+         prepared to wait for Authentication and Link Quality
+         Determination to finish before timing out waiting for a
+         Configure-Ack or other response.  It is suggested that an
+         implementation give up only after user intervention or a
+         configurable amount of time.
+
+      Configuration Option Types
+
+         IPV6CP has a distinct set of Configuration Options.
+
+4.  IPV6CP Configuration Options
+
+   IPV6CP Configuration Options allow negotiation of desirable IPv6
+   parameters.  IPV6CP uses the same Configuration Option format defined
+   for LCP [1] but with a separate set of Options.  If a Configuration
+   Option is not included in a Configure-Request packet, the default
+   value for that Configuration Option is assumed.
+
+   Up-to-date values of the IPV6CP Option Type field are specified in
+   the online database of "Assigned Numbers" maintained at IANA [9].
+   The current value assignment is as follows:
+
+      1 Interface-Identifier
+
+   The only IPV6CP option defined in this document is the interface
+   identifier.  Any other IPV6CP configuration options that can be
+   defined over time are to be defined in separate documents.
+
+4.1.  Interface Identifier
+
+   Description
+
+   This Configuration Option provides a way to negotiate a unique, 64-
+   bit interface identifier to be used for the address autoconfiguration
+   [3] at the local end of the link (see Section 5).  A Configure-
+   Request MUST contain exactly one instance of the interface-identifier
+   option [1].  The interface identifier MUST be unique within the PPP
+
+
+
+Varada, et al.              Standards Track                     [Page 4]
+
+RFC 5072                 IP Version 6 over PPP            September 2007
+
+
+   link; i.e., upon completion of the negotiation, different interface-
+   identifier values are to be selected for the ends of the PPP link.
+   The interface identifier may also be unique over a broader scope.
+
+   Before this Configuration Option is requested, an implementation
+   chooses its tentative interface identifier.  The non-zero value of
+   the tentative interface identifier SHOULD be chosen such that the
+   value is unique to the link and, preferably, consistently
+   reproducible across initializations of the IPV6CP finite state
+   machine (administrative Close and reOpen, reboots, etc.).  The
+   rationale for preferring a consistently reproducible unique interface
+   identifier to a completely random interface identifier is to provide
+   stability to global scope addresses (see Appendix A) that can be
+   formed from the interface identifier.
+
+   Assuming that interface identifier bits are numbered from 0 to 63 in
+   canonical bit order, where the most significant bit is the bit number
+   0, the bit number 6 is the "u" bit (universal/local bit in  IEEE
+   EUI-64 [4] terminology), which indicates whether or not the interface
+   identifier is based on a globally unique IEEE identifier (EUI-48 or
+   EUI-64 [4])(see case 1 below).  It is set to one (1) if a globally
+   unique IEEE identifier is used to derive the interface identifier,
+   and it is set to zero (0) otherwise.
+
+   The following are methods for choosing the tentative interface
+   identifier in the preference order:
+
+   1) If an IEEE global identifier (EUI-48 or EUI-64) is available
+      anywhere on the node, it should be used to construct the tentative
+      interface identifier due to its uniqueness properties.  When
+      extracting an IEEE global identifier from another device on the
+      node, care should be taken that the extracted identifier is
+      presented in canonical ordering [14].
+
+      The only transformation from an EUI-64 identifier is to invert the
+      "u" bit (universal/local bit in IEEE EUI-64 terminology).
+
+      For example, for a globally unique EUI-64 identifier of the form:
+
+   most-significant                                    least-significant
+   bit                                                               bit
+   |0              1|1              3|3              4|4              6|
+   |0              5|6              1|2              7|8              3|
+   +----------------+----------------+----------------+----------------+
+
+   |cccccc0gcccccccc|cccccccceeeeeeee|eeeeeeeeeeeeeeee|eeeeeeeeeeeeeeee|
+   +----------------+----------------+----------------+----------------+
+
+
+
+
+Varada, et al.              Standards Track                     [Page 5]
+
+RFC 5072                 IP Version 6 over PPP            September 2007
+
+
+      where "c" are the bits of the assigned company_id, "0" is the
+      value of the universal/local bit to indicate global scope, "g" is
+      the group/individual bit, and "e" are the bits of the extension
+      identifier, the IPv6 interface identifier would be of the form:
+
+   most-significant                                    least-significant
+   bit                                                               bit
+   |0              1|1              3|3              4|4              6|
+   |0              5|6              1|2              7|8              3|
+   +----------------+----------------+----------------+----------------+
+
+   |cccccc1gcccccccc|cccccccceeeeeeee|eeeeeeeeeeeeeeee|eeeeeeeeeeeeeeee|
+   +----------------+----------------+----------------+----------------+
+
+      The only change is inverting the value of the universal/local bit.
+
+      In the case of a EUI-48 identifier, it is first converted to the
+      EUI-64 format by inserting two bytes, with hexa-decimal values of
+      0xFF and 0xFE, in the middle of the 48-bit MAC (between the
+      company_id and extension identifier portions of the EUI-48 value).
+      For example, for a globally unique 48-bit EUI-48 identifier of the
+      form:
+
+      most-significant                   least-significant
+      bit                                              bit
+      |0              1|1              3|3              4|
+      |0              5|6              1|2              7|
+      +----------------+----------------+----------------+
+      |cccccc0gcccccccc|cccccccceeeeeeee|eeeeeeeeeeeeeeee|
+      +----------------+----------------+----------------+
+
+      where "c" are the bits of the assigned company_id, "0" is the
+      value of the universal/local bit to indicate global scope, "g" is
+      the group/individual bit, and "e" are the bits of the extension
+      identifier, the IPv6 interface identifier would be of the form:
+
+   most-significant                                    least-significant
+   bit                                                               bit
+   |0              1|1              3|3              4|4              6|
+   |0              5|6              1|2              7|8              3|
+   +----------------+----------------+----------------+----------------+
+
+   |cccccc1gcccccccc|cccccccc11111111|11111110eeeeeeee|eeeeeeeeeeeeeeee|
+   +----------------+----------------+----------------+----------------+
+
+   2) If an IEEE global identifier is not available, a different source
+      of uniqueness should be used.  Suggested sources of uniqueness
+      include link-layer addresses, machine serial numbers, et cetera.
+
+
+
+Varada, et al.              Standards Track                     [Page 6]
+
+RFC 5072                 IP Version 6 over PPP            September 2007
+
+
+      In this case, the "u" bit of the interface identifier MUST be set
+      to zero (0).
+
+   3) If a good source of uniqueness cannot be found, it is recommended
+      that a random number be generated.  In this case, the "u" bit of
+      the interface identifier MUST be set to zero (0).
+
+   Good sources [1] of uniqueness or randomness are required for the
+   interface identifier negotiation to succeed.  If neither a unique
+   number nor a random number can be generated, it is recommended that a
+   zero value be used for the interface identifier transmitted in the
+   Configure-Request.  In this case, the PPP peer may provide a valid
+   non-zero interface identifier in its response as described below.
+   Note that if at least one of the PPP peers is able to generate
+   separate non-zero numbers for itself and its peer, the identifier
+   negotiation will succeed.
+
+   When a Configure-Request is received with the Interface-Identifier
+   Configuration Option and the receiving peer implements this option,
+   the received interface identifier is compared with the interface
+   identifier of the last Configure-Request sent to the peer.  Depending
+   on the result of the comparison, an implementation MUST respond in
+   one of the following ways:
+
+   If the two interface identifiers are different but the received
+   interface identifier is zero, a Configure-Nak is sent with a non-zero
+   interface-identifier value suggested for use by the remote peer.
+   Such a suggested interface identifier MUST be different from the
+   interface identifier of the last Configure-Request sent to the peer.
+   It is recommended that the value suggested be consistently
+   reproducible across initializations of the IPV6CP finite state
+   machine (administrative Close and reOpen, reboots, etc).  The "u"
+   (universal/local) bit of the suggested identifier MUST be set to zero
+   (0) regardless of its source unless the globally unique EUI-48/EUI-64
+   derived identifier is provided for the exclusive use by the remote
+   peer.
+
+   If the two interface identifiers are different and the received
+   interface identifier is not zero, the interface identifier MUST be
+   acknowledged, i.e., a Configure-Ack is sent with the requested
+   interface identifier, meaning that the responding peer agrees with
+   the interface identifier requested.
+
+   If the two interface identifiers are equal and are not zero,
+   Configure-Nak MUST be sent specifying a different non-zero
+   interface-identifier value suggested for use by the remote peer.  It
+   is recommended that the value suggested be consistently reproducible
+   across initializations of the IPV6CP finite state machine
+
+
+
+Varada, et al.              Standards Track                     [Page 7]
+
+RFC 5072                 IP Version 6 over PPP            September 2007
+
+
+   (administrative Close and reOpen, reboots, etc).  The "u"
+   (universal/local) bit of the suggested identifier MUST be set to zero
+   (0) regardless of its source unless the globally unique EUI-48/EUI-64
+   derived identifier is provided for the exclusive use by the remote
+   peer.
+
+   If the two interface identifiers are equal to zero, the interface
+   identifier's negotiation MUST be terminated by transmitting the
+   Configure-Reject with the interface-identifier value set to zero.  In
+   this case, a unique interface identifier cannot be negotiated.
+
+   If a Configure-Request is received with the Interface-Identifier
+   Configuration Option and the receiving peer does not implement this
+   option, Configure-Reject 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 [1]).
+
+   A new Configure-Request MUST NOT contain the interface-identifier
+   option if a valid Interface-Identifier Configure-Reject is received.
+
+   Reception of a Configure-Nak with a suggested interface identifier
+   different from that of the last Configure-Nak sent to the peer
+   indicates a unique interface identifier.  In this case, a new
+   Configure-Request MUST be sent with the identifier value suggested in
+   the last Configure-Nak from the peer.  But if the received interface
+   identifier is equal to the one sent in the last Configure-Nak, a new
+   interface identifier MUST be chosen.  In this case, a new Configure-
+   Request SHOULD be sent with the new tentative interface identifier.
+   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 identifiers chosen at either end will quickly
+   diverge, terminating the sequence.
+
+   If negotiation of the interface identifier is required, and the peer
+   did not provide the option in its Configure-Request, the option
+   SHOULD be appended to a Configure-Nak.  The tentative value of the
+   interface identifier given must be acceptable as the remote interface
+   identifier; i.e., it should be different from the identifier value
+   selected for the local end of the PPP link.  The next Configure-
+   Request from the peer may include this option.  If the next
+   Configure-Request does not include this option, the peer MUST NOT
+   send another Configure-Nak with this option included.  It should
+   assume that the peer's implementation does not support this option.
+
+
+
+
+
+Varada, et al.              Standards Track                     [Page 8]
+
+RFC 5072                 IP Version 6 over PPP            September 2007
+
+
+   By default, an implementation SHOULD attempt to negotiate the
+   interface identifier for its end of the PPP connection.
+
+   A summary of the Interface-Identifier Configuration Option format is
+   shown below.  The fields are transmitted from left to right.
+
+   0                   1                   2                   3
+   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Type      |    Length     | Interface-Identifier (MS Bytes)
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                        Interface-Identifier (cont)
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   Interface-Identifier (LS Bytes) |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      Type
+
+         1
+
+      Length
+
+         10
+
+      Interface-Identifier
+
+         The 64-bit interface identifier, which is very likely to be
+         unique on the link, or zero if a good source of uniqueness
+         cannot be found.
+
+      Default
+
+         If no valid interface identifier can be successfully
+         negotiated, no default interface-identifier value should be
+         assumed.  The procedures for recovering from such a case are
+         unspecified.  One approach is to manually configure the
+         interface identifier of the interface.
+
+5.  Stateless Autoconfiguration and Link-Local Addresses
+
+   The interface identifier of IPv6 unicast addresses [5] of a PPP
+   interface SHOULD be negotiated in the IPV6CP phase of the PPP
+   connection setup (see Section 4.1).  If no valid interface identifier
+   has been successfully negotiated, procedures for recovering from such
+   a case are unspecified.  One approach is to manually configure the
+   interface identifier of the interface.
+
+
+
+
+
+Varada, et al.              Standards Track                     [Page 9]
+
+RFC 5072                 IP Version 6 over PPP            September 2007
+
+
+   The negotiated interface identifier is used by the local end of the
+   PPP link to autoconfigure an IPv6 link-local unicast address for the
+   PPP interface.  However, it SHOULD NOT be assumed that the same
+   interface identifier is used in configuring global unicast addresses
+   for the PPP interface using IPv6 stateless address autoconfiguration
+   [3].  The PPP peer MAY generate one or more interface identifiers,
+   for instance, using a method described in [8], to autoconfigure one
+   or more global unicast addresses.
+
+   As long as the interface identifier is negotiated in the IPV6CP phase
+   of the PPP connection setup, it is redundant to perform duplicate
+   address detection (DAD) as a part of the IPv6 Stateless Address
+   Autoconfiguration protocol [3] on the IPv6 link-local address
+   generated by the PPP peer.  It may also be redundant to perform DAD
+   on any global unicast addresses configured (using an interface
+   identifier that is either negotiated during IPV6CP or generated, for
+   instance, as per [8]) for the interface as part of the IPv6 Stateless
+   Address Autoconfiguration protocol [3] provided that the following
+   two conditions are met:
+
+      1) The prefixes advertised through the Router Advertisement
+         messages by the access router terminating the PPP link are
+         exclusive to the PPP link.
+
+      2) The access router terminating the PPP link does not
+         autoconfigure any IPv6 global unicast addresses from the
+         prefixes that it advertises.
+
+   Therefore, it is RECOMMENDED that for PPP links with the IPV6CP
+   interface-identifier option enabled and satisfying the aforementioned
+   two conditions, the default value of the DupAddrDetectTransmits
+   autoconfiguration variable [3] is set to zero by the system
+   management.  3GPP2 networks are an example of a technology that uses
+   PPP to enable a host to obtain an IPv6 global unicast address and
+   satisfies the aforementioned two conditions [10].  3GPP networks are
+   another example ([11] [13]).
+
+   Link-local addresses
+
+   Link-local addresses of PPP interfaces have the following format:
+
+   | 10 bits  |        54 bits         |          64 bits            |
+   +----------+------------------------+-----------------------------+
+   |1111111010|           0            |    Interface-Identifier     |
+   +----------+------------------------+-----------------------------+
+
+
+
+
+
+
+Varada, et al.              Standards Track                    [Page 10]
+
+RFC 5072                 IP Version 6 over PPP            September 2007
+
+
+   The most significant 10 bits of the address is the Link-Local prefix
+   FE80::.  54 zero bits pad out the address between the Link-Local
+   prefix and the interface-identifier fields.
+
+6.  Security Considerations
+
+   Lack of link security, such as authentication, trigger the security
+   concerns raised in [3] when the stateless address autoconfiguration
+   method is employed for the generation of global unicast IPv6
+   addresses out of interface identifiers that are either negotiated
+   through the IPV6CP or generated, for instance, using a method
+   described in [8].  Thus, the mechanisms that are appropriate for
+   ensuring PPP link security are addressed below, together with the
+   reference to a generic threat model.
+
+   The mechanisms that are appropriate for ensuring PPP link Security
+   are: 1) Access Control Lists that apply filters on traffic received
+   over the link for enforcing admission policy, 2) an Authentication
+   protocol that facilitates negotiations between peers [15] to select
+   an authentication method (e.g., MD5 [16]) for validation of the peer,
+   and 3) an Encryption protocol that facilitates negotiations between
+   peers to select encryption algorithms (or crypto-suites) to ensure
+   data confidentiality [17].
+
+   There are certain threats associated with peer interactions on a PPP
+   link even with one or more of the above security measures in place.
+   For instance, using the MD5 authentication method [16] exposes one to
+   replay attack, where an attacker could intercept and replay a
+   station's identity and password hash to get access to a network.  The
+   user of this specification is advised to refer to [15], which
+   presents a generic threat model, for an understanding of the threats
+   posed to the security of a link.  The reference [15] also gives a
+   framework to specify requirements for the selection of an
+   authentication method for a given application.
+
+7.  IANA Considerations
+
+   The IANA has assigned value 1 for the Type field of the IPv6 datagram
+   interface-identifier option specified in this document.  The current
+   assignment is up-to-date at [9].
+
+8.  Acknowledgments
+
+   This document borrows from the Magic-Number LCP option and as such is
+   partially based on previous work done by the PPP working group.
+
+   The editor is grateful for the input provided by members of the IPv6
+   community in the spirit of updating RFC 2472.  Thanks, in particular,
+
+
+
+Varada, et al.              Standards Track                    [Page 11]
+
+RFC 5072                 IP Version 6 over PPP            September 2007
+
+
+   go to Pete Barany and Karim El Malki for their technical
+   contributions.  Also, thanks to Alex Conta for a thorough review,
+   Stephen Kent for helping with security aspects, and Spencer Dawkins
+   and Pekka Savola for the nits.  Finally, the author is grateful to
+   Jari Arkko for his initiation to bring closure to this specification.
+
+9.  References
+
+9.1.  Normative References
+
+   [1]   Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", STD 51,
+         RFC 1661, July 1994.
+
+   [2]   Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
+         Specification", RFC 2460, December 1998.
+
+   [3]   Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address
+         Autoconfiguration", RFC 4862, September 2007.
+
+   [4]   IEEE, "Guidelines For 64-bit Global Identifier (EUI-64)",
+         http://standards.ieee.org/regauth/oui/tutorials/EUI64.html
+
+   [5]   Hinden, R. and S. Deering, "IP Version 6 Addressing
+         Architecture", RFC 4291, February 2006.
+
+   [6]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
+         Levels", BCP 14, RFC 2119, March 1997.
+
+   [7]   Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC 2472,
+         December 1998.
+
+   [8]   Narten T., Draves, R., and S. Krishnan, "Privacy Extensions for
+         Stateless Address Autoconfiguration in IPv6", RFC 4941,
+         September 2007.
+
+9.2.  Informative references
+
+   [9]   IANA, "Assigned Numbers," http://www.iana.org/numbers.html
+
+   [10]  3GPP2 X.S0011-002-C v1.0, "cdma2000 Wireless IP Network
+         Standard: Simple IP and Mobile IP Access Services," September
+         2003.
+
+   [11]  3GPP TS 29.061 V6.4.0, "Interworking between the Public Land
+         Mobile Network (PLMN) Supporting packet based services and
+         Packet Data Networks (PDN) (Release 6)," April 2005.
+
+
+
+
+
+Varada, et al.              Standards Track                    [Page 12]
+
+RFC 5072                 IP Version 6 over PPP            September 2007
+
+
+   [12]  Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C.,
+         and M. Carney, "Dynamic Host Configuration Protocol for IPv6
+         (DHCPv6)", RFC 3315, July 2003.
+
+   [13]  3GPP TS 23.060 v6.8.0, "General Packet Radio Service (GPRS);
+         Service description; Stage 2 (Release 6)," March 2005.
+
+   [14]  Narten, T. and C. Burton, "A Caution On The Canonical Ordering
+         Of Link-Layer Addresses", RFC 2469, December 1998.
+
+   [15]  Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
+         Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC
+         3748, June 2004.
+
+   [16]  Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April
+         1992.
+
+   [17]  Meyer, G., "The PPP Encryption Control Protocol (ECP)", RFC
+         1968, June 1996.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Varada, et al.              Standards Track                    [Page 13]
+
+RFC 5072                 IP Version 6 over PPP            September 2007
+
+
+Appendix A:  Global Scope Addresses
+
+   A node on the PPP link creates global unicast addresses either
+   through stateless or stateful address autoconfiguration mechanisms.
+   In the stateless address autoconfiguration [3], the node relies on
+   sub-net prefixes advertised by the router via the Router
+   Advertisement messages to obtain global unicast addresses from an
+   interface identifier.  In the stateful address autoconfiguration, the
+   host relies on a Stateful Server, like DHCPv6 [12], to obtain global
+   unicast addresses.
+
+Appendix B:  Changes from RFC 2472
+
+   The following changes were made from RFC 2472 "IPv6 over PPP":
+
+   -  Minor updates to Sections 3 and 4
+
+   -  Updated the text in Section 4.1 to include the reference to
+      Appendix A and minor text clarifications.
+
+   -  Removed Section 4.2 on IPv6-Compression-Protocol based on IESG
+      recommendation, and created a new standards-track document to
+      cover negotiation of the IPv6 datagram compression protocol using
+      IPV6CP.
+
+   -  Updated the text in Section 5 to: (a) allow the use of one or more
+      interface identifiers generated by a peer, in addition to the use
+      of interface identifier negotiated between peers of the link, in
+      the creation of global unicast addresses for the local PPP
+      interface, and (b) identify cases against the DAD of created non-
+      link-local addresses.
+
+   -  Added new and updated references.
+
+   -  Added Appendix A
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Varada, et al.              Standards Track                    [Page 14]
+
+RFC 5072                 IP Version 6 over PPP            September 2007
+
+
+Authors' Addresses
+
+   Dimitry Haskin
+   Ed Allen
+
+   Srihari Varada (Editor)
+   TranSwitch Corporation
+   3 Enterprise Dr.
+   Shelton, CT 06484. US.
+
+   Phone: +1 203 929 8810
+   EMail: varada@ieee.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Varada, et al.              Standards Track                    [Page 15]
+
+RFC 5072                 IP Version 6 over PPP            September 2007
+
+
+Full Copyright Statement
+
+   Copyright (C) The IETF Trust (2007).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
+   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
+   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
+   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+
+
+
+
+
+
+
+
+
+
+Varada, et al.              Standards Track                    [Page 16]
+