Hi Margaret, I have read your draft and have a few questions/comments which you may wish to address before forwarding the document to 3GPP.
In the draft, three recommendations are made: > 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. The draft then points out that implementing these recommendations will bring the following benefits: > Laptops that connect to 3GPP handsets will work without any > software changes. Their implementation of 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. It would be helpful if you could show where these incompatibilities lie ? Are these incompatibilities related to PPPv6 or application implementations ? I believe the 3GPP implementation has been designed to work with standard implementations of PPPv6 (between the MT and TE i.e. between a handset and laptop), so if there are problems it would be good to see them stated explicitly. > 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. Is this really an issue. The IPv6 stack will have to be integrated into the UE in any case and therefore some degree of engineering effort will be required. Will implementation of IPv6 in a 3G UE be much more difficult than in say other small devices (PDAs) as a result of 3GPP design decisions. > 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.) It would be helpful if you could expand on what is meant here. Static addresses are already supported, privacy (in the form of generating temporary addresses) is not such an issue in the 3GPP environment as each time a context is activated a new "temporary" address is assigned. Site-scoped addresses are not prevented in 3GPP, the prefix assigned at context activation may be limited to site scope. > The GPRS system will be better positioned to take advantage of > new IPv6 features that are built around the current addressing > architecture. Again this needs to be expanded upon. While it is important to ensure the specs do not prevent future enhancement, the benefits need to be weighed against any increased complexity. The draft also lists two problems with the current 3GPP specs: > 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. I do not see how site renumbering is an issue. When site renumbering takes place (i.e. the operator switches to a new ISP hence causing all address prefixes to change), the change must take place over a period of time where both the old and new addresses are supported. In 3GPP, all new PDP contexts will be assigned new addresses. If PDP contexts need to be deactivated by the network in order to force an address to be renewed, then that is also supported. > 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. Again I do not think the privacy issue is important in a 3GPP environment as I stated above (by their nature addresses are temporary). In RFC3041 "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", it states the following: "The way PPP is used today, however, PPP servers typically unilaterally inform the client what address they are to use (i.e., the client doesn't generate one on its own). This practice, if continued in IPv6, would avoid the concerns that are the focus of this document." This exactly describes the way in which addresses are allocated in the 3GPP specs. So for me, this confirms that Privacy (as described in RFC3041) is not an issue for 3GPP systems. The incompatibility issues need to be clarified - it needs to be explained where there will be problems connecting a UE to IPv6 laptop stacks. One final point, do you really think it is wise to assign /64 to a UE. I am not familiar with how liberally (cheaply) IPv6 addresses will be handed out by the addressing authorities but this seems excessive. Many 3GPP devices may be simple (e.g. telemetry type) devices which will have no use for /64 addresses ? Unless a UE is acting as a router, then /64 seems not to be necessary - in 3GPP the UE is a host not a router. If a UE needs multiple addresses, then it just activates a new PDP context for each address required - this is a good solution, as for each new address required you also specify the QoS capabilities required. Hope these comments are helpful. I think an assessment of how 3GPP implements IPv6 is useful and needed and closer cooperation between the IETF and 3GPP should be encouraged. Best regards, John -----Original Message----- From: Margaret Wasserman [mailto:[EMAIL PROTECTED]] Sent: Tuesday, November 13, 2001 2:40 PM To: [EMAIL PROTECTED] Subject: draft-wasserman-3gpp-advice-00.txt I would like to request that the working group consider draft-wasserman-3gpp-advice-00.txt as a working group work item. This draft was written by the IPv6-3GPP design team and offers advice on the use of IPv6 within 3GPP standards. Please let me know if there are any objections to making this document an IPng work item. Thanks, Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
