rfc3314.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,292 行 · 第 1/4 页

   addresses per primary PDP Context having different interface
   identifiers, some modifications to the current 3GPP specifications
   would be required.

   The solutions to achieve this were evaluated against the following
   factors:

      -  Scarcity and high cost of wireless spectrum
      -  Complexity of implementation and state maintenance
      -  Stability of the relevant IETF standards
      -  Impact on current 3GPP standards

   Two solutions to allow autoconfiguration of multiple addresses on the
   same primary PDP Context were considered:

      1. Assign one or more entire prefixes (/64s) to a PDP Context upon
         PDP Context activation and allow the autoconfiguration of
         multiple addresses.

         a) The assignment may be performed by having the GGSN advertise
            one or more /64 prefixes to the mobile device.

         b) The assignment may be performed by building "prefix
            delegation" functionality into the PDP Context messages or
            by using layer 3 mechanisms such as [PREFDEL].  In this way,
            the prefix is not assigned to the link between the GGSN and
            the mobile device (as in 1a), but it is assigned to the
            mobile device itself.  Note that [PREFDEL] cannot be
            considered stable and has not, at this stage, been adopted
            by the IPv6 WG as a WG document.

      2. Share the same prefix between multiple PDP Contexts connected
         to the same GGSN (and APN).  Given that mobile devices may
         generate multiple addresses using more than one interface
         identifier, this would require DAD for the newly generated
         addresses over the air interface, and a proxy DAD, function
         which would increase the complexity and the amount of state to



Wasserman                    Informational                     [Page 18]

RFC 3314       Recommendations for IPv6 in 3GPP Standards September 2002


         be kept in the GGSN.  Also, the GGSN would need to determine
         when the temporary addresses are no longer in use, which would
         be difficult.  One possible solution could be using periodic
         unicast neighbor solicitations for the temporary addresses
         [IPV6ND].

   Considering all the factors when evaluating the solutions, the
   recommendation is to use Solution 1a.  This solution requires the
   least modification to the current 3GPP standards and maintains all
   the advantages of the other solutions.

   Effectively, this would mean that each APN in a GGSN would have a
   certain number of /64 prefixes that can be handed out at PDP context
   Activation, through Router Advertisements.  Therefore, instead of
   using the full IPv6 address to identify a primary PDP context, the
   IPv6 WG recommends that the GGSN use the entire prefix (together with
   other 3GPP specific information) and that the SGSN be informed of the
   prefixes that are assigned to a PDP context.  By assigning a given
   prefix to only one primary PDP context, the GGSN and SGSN can
   associate a prefix list with each PDP context, as needed.

   Note that the recommended solution does not imply or assume that the
   mobile device is a router.  The MT is expected to use the /64 for
   itself and may also use this prefix for devices attached to it.
   However, this is not necessary if each device behind the MT is
   connected to a separate primary PDP Context and therefore can use a
   /64, which is not shared with other devices.  The MT is also expected
   to handle DAD locally for devices attached to it (e.g., laptops)
   without forwarding Neighbor Solicitations over the air to the GGSN.

References

   [OLD-TS23060] TS 23.060, "General Packet Radio Service (GPRS);
                 Service description; Stage 2", V4.1.0

   [NEW-TS23060] TS 23.060 version 3.11.0 (release 99), 4.4.0 (release
                 4) and 5.1.0 (release 5).

   [3GPP-URL]    http://www.3gpp.org

   [IETF-URL]    http://www.ietf.org

   [RFC2026]     Bradner, S., "The Internet Standards Process --
                 Revision 3", BCP 9, RFC 2026, October 1996

   [KEYWORD]     Bradner, S., "Key words for use in RFCs to Indicate
                 Requirement Levels", BCP 14, RFC 2119, March 1999.




Wasserman                    Informational                     [Page 19]

RFC 3314       Recommendations for IPv6 in 3GPP Standards September 2002


   [TR21905]     3GPP TR 21.905, "Vocabulary for 3GPP Specifications",
                 V5.0.0

   [IPV6]        Deering, S. and R. Hinden, "Internet Protocol, Version
                 6 (IPv6) Specification", RFC 2460, December 1998.

   [NAT-PT]      Tsirtsis, G. and P. Shrisuresh, "Network Address
                 Translation - Protocol Translation (NAT-PT)", RFC 2766,
                 February 2000.

   [PPP]         Simpson, W., "The Point-to-Point Protocol (PPP)", STD
                 51, RFC 1661, July 1994.

   [SIIT]        Nordmark, N., "Stateless IP/ICMP Translation
                 Algorithm", RFC 2765, February 2000.

   [ADDRARCH]    Hinden, R. and S. Deering, "IP Version 6 Addressing
                 Architecture", RFC 2373, July 1998.

   [IPV6ND]      Narten, T., Nordmark, E. and W. Simpson, "Neighbor
                 Discovery for IP Version 6 (IPv6)", RFC 2461, December
                 1998.

   [AUTOCONF]    Thomson, S. and T. Narten, "IPv6 Stateless Address
                 Autoconfiguration", RFC 2462, December 1998

   [PRIVADDR]    Narten, T. and R. Draves, "Privacy Extensions for
                 Stateless Address Autoconfiguration in IPv6", RFC 3041,
                 January 2001.

   [IPV6ETH]     Crawford, M., "Transmission of IPv6 Packets over
                 Ethernet Networks", RFC 2464, December 1998.

   [PPPv6]       Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC
                 2472, December 1998.

   [MULTLINK]    C. Huitema, D. Thaler, "Multi-link Subnet Support in
                 IPv6", Work in Progress.

   [SITEREN]     C. Huitema, "IPv6 Site Renumbering", Work in Progress.

   [HD]          Durand, A. and C. Huitema, "The Host-Density Ratio for
                 Address Assignment Efficiency: An update on the H
                 ratio", RFC 3194, November 2001.

   [IABAA]       IAB, IESG, "IAB/IESG Recommendations on IPv6 Address
                 Allocations to Sites", RFC 3177, September 2001.




Wasserman                    Informational                     [Page 20]

RFC 3314       Recommendations for IPv6 in 3GPP Standards September 2002


   [AAPOL]       APNIC, ARIN, RIPE-NCC, "IPv6 Address Allocation and
                 Assignment Global Policy", Work in Progress.

   [SCOPARCH]    S. Deering, et. al., "IPv6 Scoped Address
                 Architecture", Work in Progress.

   [CELLREQ]     J. Arkko, et. al., "Minimum IPv6 Functionality for a
                 Cellular Host", Work in Progress.

   [PREFDEL]     J. Martin, B. Haberman, "Automatic Prefix Delegation
                 Protocol for Internet Protocol Version 6 (IPv6)", Work
                 in Progress.







































Wasserman                    Informational                     [Page 21]

RFC 3314       Recommendations for IPv6 in 3GPP Standards September 2002


Authors and Acknowledgements

   This document was written by the IPv6 3GPP design team:

   Steve Deering, Cisco Systems
   EMail: [e-mail]

   Karim El-Malki, Ericsson Radio Systems
   EMail: [e-mail]

   Paul Francis, Tahoe Networks
   EMail: [e-mail]

   Bob Hinden, Nokia
   EMail: [e-mail]

   Christian Huitema, Microsoft
   EMail: [e-mail]

   Niall Richard Murphy, Hutchison 3G
   EMail: [e-mail]

   Markku Savela, Technical Research Centre of Finland
   Email: [e-mail]

   Jonne Soininen, Nokia
   EMail: [e-mail]

   Margaret Wasserman, Wind River
   EMail: [e-mail]

   Information was incorporated from a presentation co-authored by:

         Juan-Antonio Ibanez, Ericsson Eurolab

Editor's Address

   Comments or questions regarding this document should be sent to:

   Margaret Wasserman
   Wind River
   10 Tara Blvd., Suite 330
   Nashua, NH  03062  USA

   Phone:  [phone]
   EMail:  [e-mail]





Wasserman                    Informational                     [Page 22]

RFC 3314       Recommendations for IPv6 in 3GPP Standards September 2002


Full Copyright Statement

   Copyright (C) The Internet Society (2002).  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.



















Wasserman                    Informational                     [Page 23]