ppp: initial IPV6CP support

7 files changed, 1580 insertions, 3 deletions

diff --git a/accel-pppd/CMakeLists.txt b/accel-pppd/CMakeLists.txt
index 10de4bbf..aaafbd94 100644
--- a/accel-pppd/CMakeLists.txt
+++ b/accel-pppd/CMakeLists.txt
@@ -65,6 +65,7 @@ ADD_EXECUTABLE(accel-pppd
 	ppp/ppp_ipcp.c
 	ppp/ipcp_opt_ipaddr.c
 	ppp/ipcp_opt_dns.c
+	ppp/ipv6cp_opt_intfid.c
 	ppp/ppp_ipv6cp.c
 	ppp/ppp_ccp.c	
 	ppp/ccp_mppe.c
diff --git a/accel-pppd/ppp/ccp_mppe.c b/accel-pppd/ppp/ccp_mppe.c
index 0952aa01..cf83d2d7 100644
--- a/accel-pppd/ppp/ccp_mppe.c
+++ b/accel-pppd/ppp/ccp_mppe.c
@@ -1,6 +1,7 @@
 #include <stdlib.h>
 #include <string.h>
 #include <errno.h>
+#include <arpa/inet.h>
 #include <sys/socket.h>
 #include <sys/ioctl.h>
 #include "linux_ppp.h"
diff --git a/accel-pppd/ppp/ppp.c b/accel-pppd/ppp/ppp.c
index a044d9a6..7ce3b4ba 100644
--- a/accel-pppd/ppp/ppp.c
+++ b/accel-pppd/ppp/ppp.c
@@ -493,6 +493,7 @@ static int get_layer_order(const char *name)
 	if (!strcmp(name,"auth")) return 1;
 	if (!strcmp(name,"ccp")) return 2;
 	if (!strcmp(name,"ipcp")) return 2;
+	if (!strcmp(name,"ipv6cp")) return 2;
 	return -1;
 }
 
diff --git a/accel-pppd/ppp/ppp.h b/accel-pppd/ppp/ppp.h
index 8556b2c2..e8141cc1 100644
--- a/accel-pppd/ppp/ppp.h
+++ b/accel-pppd/ppp/ppp.h
@@ -3,7 +3,6 @@
 
 #include <sys/types.h>
 #include <time.h>
-#include <netinet/in.h>
 #include <pthread.h>
 
 #include "triton.h"
@@ -95,8 +94,8 @@ struct ppp_t
 	time_t start_time;
 	time_t stop_time;
 	char *username;
-	in_addr_t ipaddr;
-	in_addr_t peer_ipaddr;
+	uint32_t ipaddr;
+	uint32_t peer_ipaddr;
 
 	struct ppp_ctrl_t *ctrl;
 
diff --git a/accel-pppd/ppp/ppp_ccp.c b/accel-pppd/ppp/ppp_ccp.c
index d4732fa3..58a4abf6 100644
--- a/accel-pppd/ppp/ppp_ccp.c
+++ b/accel-pppd/ppp/ppp_ccp.c
@@ -1,6 +1,7 @@
 #include <stdlib.h>
 #include <string.h>
 #include <errno.h>
+#include <arpa/inet.h>
 #include <sys/socket.h>
 #include <sys/ioctl.h>
 #include "linux_ppp.h"
diff --git a/rfc/rfc3162.txt b/rfc/rfc3162.txt
new file mode 100644
index 00000000..a62642f3
--- /dev/null
+++ b/rfc/rfc3162.txt
@@ -0,0 +1,675 @@
+
+
+
+
+
+
+Network Working Group                                           B. Aboba
+Request for Comments: 3162                                     Microsoft
+Category: Standards Track                                        G. Zorn
+                                                           Cisco Systems
+                                                               D. Mitton
+                                                   Circular Logic UnLtd.
+                                                             August 2001
+
+
+                            RADIUS and IPv6
+
+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.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2001).  All Rights Reserved.
+
+Abstract
+
+   This document specifies the operation of RADIUS (Remote
+   Authentication Dial In User Service) when run over IPv6 as well as
+   the RADIUS attributes used to support IPv6 network access.
+
+1.  Introduction
+
+   This document specifies the operation of RADIUS [4]-[8] over IPv6
+   [13] as well as the RADIUS attributes used to support IPv6 network
+   access.
+
+   Note that a NAS sending a RADIUS Access-Request may not know a-priori
+   whether the host will be using IPv4, IPv6, or both.  For example,
+   within PPP, IPv6CP [11] occurs after LCP, so that address assignment
+   will not occur until after RADIUS authentication and authorization
+   has completed.
+
+   Therefore it is presumed that the IPv6 attributes described in this
+   document MAY be sent along with IPv4-related attributes within the
+   same RADIUS message and that the NAS will decide which attributes to
+   use.  The NAS SHOULD only allocate addresses and prefixes that the
+   client can actually use, however.  For example, there is no need for
+
+
+
+
+
+Aboba, et al.               Standards Track                     [Page 1]
+
+RFC 3162                    RADIUS and IPv6                  August 2001
+
+
+   the NAS to reserve use of an IPv4 address for a host that only
+   supports IPv6; similarly, a host only using IPv4 or 6to4 [12] does
+   not require allocation of an IPv6 prefix.
+
+   The NAS can provide IPv6 access natively, or alternatively, via other
+   methods such as IPv6 within IPv4 tunnels [15] or 6over4 [14].  The
+   choice of method for providing IPv6 access has no effect on RADIUS
+   usage per se, although if it is desired that an IPv6 within IPv4
+   tunnel be opened to a particular location, then tunnel attributes
+   should be utilized, as described in [6], [7].
+
+1.1.  Requirements language
+
+   In this document, the key words "MAY", "MUST, "MUST NOT", "optional",
+   "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as
+   described in [1].
+
+2.  Attributes
+
+2.1.  NAS-IPv6-Address
+
+   Description
+
+      This Attribute indicates the identifying IPv6 Address of the NAS
+      which is requesting authentication of the user, and SHOULD be
+      unique to the NAS within the scope of the RADIUS server.  NAS-
+      IPv6-Address is only used in Access-Request packets.  NAS-IPv6-
+      Address and/or NAS-IP-Address MAY be present in an Access-Request
+      packet; however, if neither attribute is present then NAS-
+      Identifier MUST be present.
+
+   A summary of the NAS-IPv6-Address Attribute 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     |             Address
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                                Address
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                                Address
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                                Address
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+               Address             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+Aboba, et al.               Standards Track                     [Page 2]
+
+RFC 3162                    RADIUS and IPv6                  August 2001
+
+
+   Type
+
+      95 for NAS-IPv6-Address
+
+   Length
+
+      18
+
+   Address
+
+      The Address field is 16 octets.
+
+3.2.  Framed-Interface-Id
+
+   Description
+
+      This Attribute indicates the IPv6 interface identifier to be
+      configured for the user.  It MAY be used in Access-Accept packets.
+      If the Interface-Identifier IPv6CP option [11] has been
+      successfully negotiated, this Attribute MUST be included in an
+      Access-Request packet as a hint by the NAS to the server that it
+      would prefer that value.  It is recommended, but not required,
+      that the server honor the hint.
+
+   A summary of the Framed-Interface-Id Attribute 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-Id
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                                Interface-Id
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+          Interface-Id             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Type
+
+      96 for Framed-Interface-Id
+
+   Length
+
+      10
+
+   Interface-Id
+
+      The Interface-Id field is 8 octets.
+
+
+
+Aboba, et al.               Standards Track                     [Page 3]
+
+RFC 3162                    RADIUS and IPv6                  August 2001
+
+
+2.3.  Framed-IPv6-Prefix
+
+   Description
+
+      This Attribute indicates an IPv6 prefix (and corresponding route)
+      to be configured for the user.  It MAY be used in Access-Accept
+      packets, and can appear multiple times.  It MAY be used in an
+      Access-Request packet as a hint by the NAS to the server that it
+      would prefer these prefix(es), but the server is not required to
+      honor the hint.  Since it is assumed that the NAS will plumb a
+      route corresponding to the prefix, it is not necessary for the
+      server to also send a Framed-IPv6-Route attribute for the same
+      prefix.
+
+   A summary of the Framed-IPv6-Prefix Attribute 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     |  Reserved     | Prefix-Length |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                                Prefix
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                                Prefix
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                                Prefix
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                                Prefix                             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Type
+
+      97 for Framed-IPv6-Prefix
+
+   Length
+
+      At least 4 and no larger than 20.
+
+   Reserved
+
+      This field, which is reserved and MUST be present, is always set
+      to zero.
+
+   Prefix-Length
+
+      The length of the prefix, in bits.  At least 0 and no larger than
+      128.
+
+
+
+Aboba, et al.               Standards Track                     [Page 4]
+
+RFC 3162                    RADIUS and IPv6                  August 2001
+
+
+   Prefix
+
+      The Prefix field is up to 16 octets in length.  Bits outside of
+      the Prefix-Length, if included, must be zero.
+
+2.4.  Login-IPv6-Host
+
+   Description
+
+      This Attribute indicates the system with which to connect the
+      user, when the Login-Service Attribute is included.  It MAY be
+      used in Access-Accept packets.  It MAY be used in an Access-
+      Request packet as a hint to the server that the NAS would prefer
+      to use that host, but the server is not required to honor the
+      hint.
+
+   A summary of the Login-IPv6-Host Attribute 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     |             Address
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                                Address
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                                Address
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                                Address
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+            Address                |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Type
+
+      98 for Login-IPv6-Host
+
+   Length
+
+      18
+
+
+
+
+
+
+
+
+
+
+
+Aboba, et al.               Standards Track                     [Page 5]
+
+RFC 3162                    RADIUS and IPv6                  August 2001
+
+
+   Address
+
+      The Address field is 16 octets in length.  The value
+      0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF indicates that the NAS SHOULD
+      allow the user to select an address or name to be connected to.
+      The value 0 indicates that the NAS SHOULD select a host to connect
+      the user to.  Other values indicate the address the NAS SHOULD
+      connect the user to.
+
+2.5.  Framed-IPv6-Route
+
+   Description
+
+      This Attribute provides routing information to be configured for
+      the user on the NAS.  It is used in the Access-Accept packet and
+      can appear multiple times.
+
+   A summary of the Framed-IPv6-Route Attribute format is shown below.
+   The fields are transmitted from left to right.
+
+    0                   1                   2
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+   |     Type      |    Length     |  Text ...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+
+   Type
+
+      99 for Framed-IPv6-Route
+
+   Length
+
+      >=3
+
+   Text
+
+      The Text field is one or more octets, and its contents are
+      implementation dependent.  The field is not NUL (hex 00)
+      terminated.  It is intended to be human readable and MUST NOT
+      affect operation of the protocol.
+
+      For IPv6 routes, it SHOULD contain a destination prefix optionally
+      followed by a slash and a decimal length specifier stating how
+      many high order bits of the prefix to use.  That is followed by a
+      space, a gateway address, a space, and one or more metrics
+      (encoded in decimal) separated by spaces.  Prefixes and addresses
+      are formatted as described in [16].  For example,
+      "2000:0:0:106::/64 2000::106:a00:20ff:fe99:a998 1".
+
+
+
+Aboba, et al.               Standards Track                     [Page 6]
+
+RFC 3162                    RADIUS and IPv6                  August 2001
+
+
+      Whenever the gateway address is the IPv6 unspecified address the
+      IP address of the user SHOULD be used as the gateway address.  The
+      unspecified address can be expressed in any of the acceptable
+      formats described in [16].  For example, "2000:0:0:106::/64 :: 1".
+
+2.6.  Framed-IPv6-Pool
+
+   Description
+
+      This Attribute contains the name of an assigned pool that SHOULD
+      be used to assign an IPv6 prefix for the user.  If a NAS does not
+      support multiple prefix pools, the NAS MUST ignore this Attribute.
+
+   A summary of the Framed-IPv6-Pool Attribute format is shown below.
+   The fields are transmitted from left to right.
+
+    0                   1                   2
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Type      |    Length     |     String...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Type
+
+      100 for Framed-IPv6-Pool
+
+   Length
+
+      >= 3
+
+   String
+
+      The string field contains the name of an assigned IPv6 prefix pool
+      configured on the NAS.  The field is not NUL (hex 00) terminated.
+
+3.  Table of Attributes
+
+   The following table provides a guide to which attributes may be found
+   in which kinds of packets, and in what quantity.
+
+   Request Accept Reject Challenge Accounting  #  Attribute
+                                   Request
+   0-1     0      0      0         0-1        95  NAS-IPv6-Address
+   0-1     0-1    0      0         0-1        96  Framed-Interface-Id
+   0+      0+     0      0         0+         97  Framed-IPv6-Prefix
+   0+      0+     0      0         0+         98  Login-IPv6-Host
+   0       0+     0      0         0+         99  Framed-IPv6-Route
+   0       0-1    0      0         0-1       100  Framed-IPv6-Pool
+
+
+
+Aboba, et al.               Standards Track                     [Page 7]
+
+RFC 3162                    RADIUS and IPv6                  August 2001
+
+
+4.  References
+
+   [1]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
+         Levels", BCP 14, RFC 2119, March, 1997.
+
+   [2]   Yergeau, F., "UTF-8, a transformation format of Unicode and ISO
+         10646", RFC 2044, October 1996.
+
+   [3]   Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy
+         Implementation in Roaming", RFC 2607, June 1999.
+
+   [4]   Rigney, C., Rubens, A., Simpson, W. and S. Willens,  "Remote
+         Authentication Dial In User Service (RADIUS)", RFC 2865, June
+         2000.
+
+   [5]   Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
+
+   [6]   Zorn, G., Mitton, D. and B. Aboba, "RADIUS Accounting
+         Modifications for Tunnel Protocol Support", RFC 2867, June
+         2000.
+
+   [7]   Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M.
+         and I. Goyret, "RADIUS Attributes for Tunnel Protocol Support",
+         RFC 2868, June 2000.
+
+   [8]   Rigney, C., Willats, W. and P. Calhoun, "RADIUS Extensions",
+         RFC 2869, June 2000.
+
+   [9]   Kent S. and R. Atkinson, "Security Architecture for the
+         Internet Protocol", RFC 2401, November 1998.
+
+   [10]  Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA
+         Considerations Section in RFCs", BCP 26, RFC 2434, October
+         1998.
+
+   [11]  Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC 2472,
+         December 1998.
+
+   [12]  Carpenter, B. and K. Moore, "Connection of IPv6 Domains via
+         IPv4 Clouds", RFC 3056, February 2001.
+
+   [13]  Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
+         Specification", RFC 2460, December 1998.
+
+   [14]  Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4
+         Domains without Explicit Tunnels", RFC 2529, March 1999.
+
+
+
+
+
+Aboba, et al.               Standards Track                     [Page 8]
+
+RFC 3162                    RADIUS and IPv6                  August 2001
+
+
+   [15]  Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6
+         Hosts and Routers", RFC 2893, August 2000.
+
+   [16]  Hinden, R. and S. Deering, "IP Version 6 Addressing
+         Architecture", RFC 2373, July 1998.
+
+5.  Security Considerations
+
+   This document describes the use of RADIUS for the purposes of
+   authentication, authorization and accounting in IPv6-enabled
+   networks.  In such networks, the RADIUS protocol may run either over
+   IPv4 or over IPv6.  Known security vulnerabilities of the RADIUS
+   protocol are described in [3], [4] and [8].
+
+   Since IPSEC [9] is mandatory to implement for IPv6, it is expected
+   that running RADIUS implementations supporting IPv6 will typically
+   run over IPSEC.  Where RADIUS is run over IPSEC and where
+   certificates are used for authentication, it may be desirable to
+   avoid management of RADIUS shared secrets, so as to leverage the
+   improved scalability of public key infrastructure.
+
+   Within RADIUS, a shared secret is used for hiding of attributes such
+   as User-Password [4] and Tunnel-Password [7].  In addition, the
+   shared secret is used in computation of the Response Authenticator
+   [4], as well as the Message-Authenticator attribute [8].  Therefore,
+   in RADIUS a shared secret is used to provide confidentiality as well
+   as integrity protection and authentication.  As a result, only use of
+   IPSEC ESP with a non-null transform can provide security services
+   sufficient to substitute for RADIUS application-layer security.
+   Therefore, where IPSEC AH or ESP null is used, it will typically
+   still be necessary to configure a RADIUS shared secret.
+
+   However, where RADIUS is run over IPSEC ESP with a non-null
+   transform, the secret shared between the NAS and the RADIUS server
+   MAY NOT be configured.  In this case, a shared secret of zero length
+   MUST be assumed.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Aboba, et al.               Standards Track                     [Page 9]
+
+RFC 3162                    RADIUS and IPv6                  August 2001
+
+
+6.  IANA Considerations
+
+   This document requires the assignment of six new RADIUS attribute
+   numbers for the following attributes:
+
+      NAS-IPv6-Address
+      Framed-Interface-Id
+      Framed-IPv6-Prefix
+      Login-IPv6-Host
+      Framed-IPv6-Route
+      Framed-IPv6-Pool
+
+   See section 3 for the registered list of numbers.
+
+7.  Acknowledgments
+
+   The authors would like to acknowledge Jun-ichiro itojun Hagino of IIJ
+   Research Laboratory, Darran Potter of Cisco and Carl Rigney of Lucent
+   for contributions to this document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Aboba, et al.               Standards Track                    [Page 10]
+
+RFC 3162                    RADIUS and IPv6                  August 2001
+
+
+8.  Authors' Addresses
+
+   Bernard Aboba
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA 98052
+
+   Phone: +1 425 936 6605
+   Fax:   +1 425 936 7329
+   EMail: bernarda@microsoft.com
+
+
+   Glen Zorn
+   Cisco Systems, Inc.
+   500 108th Avenue N.E., Suite 500
+   Bellevue, WA 98004
+
+   Phone: +1 425 471 4861
+   EMail: gwz@cisco.com
+
+
+   Dave Mitton
+   Circular Logic UnLtd.
+   733 Turnpike Street #154
+   North Andover, MA 01845
+
+   Phone: 978 683-1814
+   Email: david@mitton.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Aboba, et al.               Standards Track                    [Page 11]
+
+RFC 3162                    RADIUS and IPv6                  August 2001
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2001).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS 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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Aboba, et al.               Standards Track                    [Page 12]
+
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]
+