Subject: RE: draft-wasserman-3gpp-advice-00.txt

From: Hughes John-CJH023 <[email-masked]>
Date: Fri, 16 Nov 2001 13:29:28 -0500

Hesham,

Thanks for the response. I will address just one of the points you made as it seems to be the most important in relation to this draft:

=> Actually it seems to me that the solution in the draft 
is a lot simpler than the one in the current 3GPP specs, but 
I might have missed something that concerned you ?

I agree. The solution in the draft is simpler however at the expense of what I view as being a wasteful implementation. The draft proposes /64 being allocated to each mobile device at a minimum and problably multiple /64s. This would be perfectly acceptable if each mobile device was a mobile router supporting mobile subnets - but in 3GPP that is not the case, a mobile device is a host and in many cases the hosts may have very basic functionalities.

The working group should provide guidance on whether such a solution is something they are comfortable with being recommended to 3GPP.

Best Regards,
John   

-----Original Message-----
From: Hesham Soliman (ERA) [mailto:[email-masked]]
Sent: Thursday, November 15, 2001 2:36 AM
To: 'Hughes John-CJH023'; 'Margaret Wasserman'; [email-masked]
Subject: RE: draft-wasserman-3gpp-advice-00.txt 

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 ? 

=> Some of the incompatibilities are:
- An IPv6 host can have multiple addresses of various 
  scopes assigned to a single interface. The current 
  3GPP addressing solutions do not allow this. 

- An IPv6 host can generate many interface ids 
  based on one or more prefixes received in the RA. 
  The current 3GPP addressing solutions do not allow
  this either.

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. 

=> Another (perhaps not a critical issue to 3GPP right now)
is what happens if the link between the TE and MT is not
PPP. The solution proposed by the draft allows for this 
to work.

>	   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.  

=> Sure there are integration issues but the less changes, 
   the better. Also one important issue here is that
   following the way things are defined in IETF will allow
   3GPP to be compatible with future proposals on IPv6
   (within IETF). For instance, when IPv6 addressing was
   first considered in 3GPP, privacy issues may not have come
   up in IETF, but when they did, the proposed solution was made
   to work with the existing IETF standards. Evidently it (RFC 3041)
   doesn't work with the existing 3GPP standard. So it's good 
   to follow the same model as IETF to allow for smooth integration
   of future features. 
   Of course this is provided that the IETF model meets the 3GPP
   requirements. In this case I believe it does.

>	   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.)

Site-scoped addresses are not prevented in 3GPP, the prefix assigned at context activation may be limited to site scope.

=> Yes but you can't assign both Site-local and Global. 
I suspect most 3GPP handsets will require global addresses
too. Unless people will only talk to other subscribers of the 
same operator :)
Another important issue here is renumbering. To be able to 
have a smooth renumbering mechanism you need to allow for
advertising 2 prefixes at least.

>	   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.

=> Actually it seems to me that the solution in the draft 
is a lot simpler than the one in the current 3GPP specs, but 
I might have missed something that concerned you ?

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.

=> Interesting point. But since site renumbering will affect several
parts of the network (DNS, DHCP (if exists), filters, policies...etc)
there is certainly room for error there. So I think it's wise 
to allow both prefixes for some time. Switching things on and off
does not seem to be very flexible. 
Consider the case where something goes wrong. I think the down
time for the network will be significant here. 

Cheers, 
Hesham

--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------