Margaret, I agree with John's input. I will have more before the IETF meeting. I think the doc went way overboard specifying how IPv6 is used in a NON IETF standards networking suite. If this is to be a working group item then I want to be very sure the mission is to provide guidance NOT SHOULD MUST type specification. So I am emphatically against any form of MANDATE from the IETF on this and we need to make sure its a suggestion that 3Gxx can incoporate into their specifications process.
I also will send input as engineer who is building 3Gxx systems for customers with IPv6 already. I also think the Loughney et all IETF 3GPP Many draft has the appropriate tone for an IETF draft for 3Gxx. Until this and John's issues are resolved I for one do not support this being a working group item just yet. regards, /jim On Wed, 14 Nov 2001, Hughes John-CJH023 wrote: > 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] > -------------------------------------------------------------------- > -------------------------------------------------------------------- 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] --------------------------------------------------------------------
