rfc3314.txt

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

      6. After the PDP Context Activation, the GGSN sends a Router
         Advertisement to the UE.

      7. The UE should be configured not to send a Neighbor Solicitation
         message.  However, if one is sent, the GGSN will silently
         discard it.

      8. The GGSN updates the SGSN with the whole IPv6 address.

   Each connected handset or laptop will create a primary PDP context
   for communication on the Internet.  A handset may create many primary
   and/or secondary PDP contexts throughout the life of its connection
   with a GGSN.

   Within 3GPP, the GGSN assigns a single 64-bit identifier to each
   primary PDP context.  The GGSN also advertises a single /64 prefix to
   the handset, and these two items are assembled into a single IPv6
   address.  Later, the GGSN modifies the PDP context entry in the SGSN
   to include the whole IPv6 address, so that the SGSN can know the
   single address of each 3GPP node (e.g., for billing purposes).  This
   address is also used in the GGSN to identify the PDP context
   associated with each packet.  It is assumed that 3GPP nodes will not




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


   generate any addresses, except for the single identifier/prefix
   combination assigned by the GGSN.  DAD is not performed, as the GGSN
   will not assign the same address to multiple nodes.

2  Recommendations to the 3GPP

   In the spirit of productive cooperation, the IPv6 Working Group
   recommends that the 3GPP consider three changes regarding the use of
   IPv6 within GPRS.  Specifically, we recommend that the 3GPP:

      1. Specify that multiple prefixes may be assigned to each primary
         PDP context,

      2. Require that a given prefix must not be assigned to more than
         one primary PDP context, and

      3. Allow 3GPP nodes to use multiple identifiers within those
         prefixes, including randomly generated identifiers.

   Making these changes would provide several advantages for 3GPP
   implementers and users:

      Laptops that connect to 3GPP handsets will work without any
      software changes.  Their implementation of the standard IPv6 over
      PPP, address assignment, and autoconfiguration mechanisms will
      work without any modification.  This will eliminate the need for
      vendors and operators to build and test special 3GPP drivers and
      related software.  As currently specified, the 3GPP standards will
      be incompatible with laptop implementations that generate their
      own identifiers for privacy or other purposes.

      IPv6 software implementations could be used in 3GPP handsets
      without any modifications to the IPv6 protocol mechanisms.  This
      will make it easier to build and test 3GPP handsets.

      Applications in 3GPP handsets will be able to take advantage of
      different types of IPv6 addresses (e.g., static addresses,
      temporary addresses for privacy, site-scoped addresses for site
      only communication, etc.)

      The GPRS system will be better positioned to take advantage of new
      IPv6 features that are built around the current addressing
      architecture.

2.1 Limitations of 3GPP Address Assignment

   The current 3GPP address assignment mechanism has the following
   limitations:



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


      The GGSN only advertises a single /64 prefix, rather than a set of
      prefixes.  This will prevent the participation of 3GPP nodes
      (e.g., handsets or 3GPP-attached laptops) in IPv6 site
      renumbering, or in other mechanisms that expect IPv6 hosts to
      create addresses based on multiple advertised prefixes.

      A 3GPP node is assigned a single identifier and is not allowed to
      generate additional identifiers.  This will prevent the use of
      privacy addresses by 3GPP nodes.  This also makes 3GPP mechanisms
      not fully compliant with the expected behavior of IPv6 nodes,
      which will result in incompatibility with popular laptop IPv6
      stacks.  For example, a laptop that uses privacy addresses for web
      browser connections could not currently establish a web browser
      connection over a 3GPP link.

   These limitations could be avoided by enabling the standard IPv6
   address allocation mechanisms in 3GPP nodes.  The GGSN could
   advertise one or more prefixes for the local link in standard IPv6
   Router Advertisements, and IPv6 addresses could be assembled, as
   needed, by the IPv6 stack on the handset or laptop.  An interface
   identifier could still be assigned by the GGSN, as is currently
   specified in the 3GPP standards.  However, the handset or laptop
   could generate additional identifiers, as needed for privacy or other
   reasons.

2.2 Advertising Multiple Prefixes

   For compliance with current and future IPv6 standards, the IPv6 WG
   recommends that the 3GPP allow multiple prefixes to be advertised for
   each primary PDP context.  This would have several advantages,
   including:

      3GPP nodes could participate in site renumbering and future IPv6
      mechanisms that rely on the use of multiple global prefixes on a
      single link.

      Site-local prefixes could be advertised on 3GPP links, if desired,
      allowing for site-constrained communication that could survive
      changes to global prefix information (e.g., site renumbering).

2.3 Assigning a Prefix to Only One Primary PDP Context

   The IPv6 WG recommends that the 3GPP treat a primary PDP context,
   along with its secondary PDP contexts, as a single IPv6 link, and
   that the GGSN view each primary PDP context as a single subnet.
   Accordingly, a given global (or site-local) prefix should not be
   assigned to more than one PDP context.




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


   Because multiple IPv6 hosts may attach through a 3GPP handset, the
   IPv6 WG recommends that one or more /64 prefixes should be assigned
   to each primary PDP context.  This will allow sufficient address
   space for a 3GPP-attached node to allocate privacy addresses and/or
   route to a multi-link subnet [MULTLINK], and will discourage the use
   of NAT within 3GPP-attached devices.

2.3.1   Is a /64 per PDP Context Too Much?

   If an operator assigns a /64 per PDP context, can we be assured that
   there is enough address space for millions of mobile devices?  This
   question can be answered in the positive using the Host Density (HD)
   Ratio for address assignment efficiency [HD].  This is a measure of
   the number of addresses that can practically and easily be assigned
   to hosts, taking into consideration the inefficiencies in usage
   resulting from the various address assignment processes.  The HD
   ratio was empirically derived from actual telephone number and data
   network address assignment cases.

   We can calculate the number of easily assignable /64's making the
   following assumptions:

      An HD ratio of 0.8 (representing the efficiency that can be
      achieved with no particular difficulty).

      Only addresses with the 3-bit prefix 001 (the Aggregatable Global
      Unicast Addresses defined by RFC 2373) are used, resulting in 61
      bits of assignable address space.

   Using these assumptions, a total of 490 trillion (490x10^12) /64
   prefixes can be assigned.  This translates into around 80,000 PDP
   Contexts per person on the earth today.  Even assuming that a
   majority of these IPv6 /64 prefixes will be used by non-3GPP
   networks, there is still clearly a sufficient number of /64 prefixes.

   Given this, it can be safely concluded that the IPv6 address space
   will not be exhausted if /64 prefixes are allocated to primary PDP
   contexts.

   For more information regarding policies for IPv6 address assignment,
   refer to the IAB/IESG recommendations regarding address assignment
   [IABAA], and the APNIC, ARIN and RIPE address allocation policy
   [AAPOL].








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


2.3.2   Prefix Information in the SGSN

   Currently, the 3GPP standards allow only one prefix and one
   identifier for each PDP context.  So, the GGSN can send a single IPv6
   address to the SGSN, to be used for billing purposes, etc.

   Instead of using the full IPv6 address to identify a PDP context, the
   IPv6 WG recommends that the SGSN be informed of each prefix that is
   currently assigned to a PDP context.  By assigning a prefix to only
   one primary PDP context, the SGSN can associate a prefix list with
   each PDP context.

2.4 Multiple Identifiers per PDP Context

   The IPv6 WG also recommends that the 3GPP standards be modified to
   allow multiple identifiers, including randomly generated identifiers,
   to be used within each assigned prefix.  This would allow 3GPP nodes
   to generate and use privacy addresses, and would be compatible with
   future IPv6 standards that may depend on the ability of IPv6 nodes to
   generate new interface identifiers for communication.

   This is a vital change, necessary to allow standards-compliant IPv6
   nodes to connect to the Internet through 3GPP handsets, without
   modification.  It is expected that most IPv6 nodes, including the
   most popular laptop stacks, will generate privacy addresses.  The
   current 3GPP specifications will not be compatible with those
   implementations.

3  Additional IPv6 Work Items

   During our work on this document, we have discovered several areas
   that could benefit from further informational or standards-track work
   within the IPv6 Working Group.

   The IPv6 WG should work to define a point-to-point architecture and
   specify how the standard IPv6 address assignment mechanisms are
   applicable to IPv6 over point-to-point links.  We should also review
   and clarify the IPv6 over PPP specification [PPP] to match the
   current IPv6 addressing architecture [ADDRARCH].

   The IPv6 WG should consider publishing an "IPv6 over PDP Contexts"
   (or similar) document.  This document would be useful for developers
   writing drivers for IPv6 stacks to work over 3GPP PDP Contexts.

   The IPv6 working group should undertake an effort to define the
   minimal requirements for all IPv6 nodes.





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


4  Security Considerations

   This document contains recommendations on the use of the IPv6
   protocol in 3GPP standards.  It does not specify a protocol, and it
   introduces no new security considerations.














































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


Appendix A:  Analysis of Findings

   This section includes some analysis that may be useful to
   understanding why the IPv6 working group is making the above
   recommendations.  It also includes some other options that were
   explored, and the reasons why those options were less suitable than
   the recommendations outlined above.

A.1 Address Assignment Solutions

   In order to allow for the configuration and use of multiple IPv6