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