Subject: [3gv6] about Prefix delegation in 3GPP EPC networks

From: [email-masked]
Date: Tue, 30 Mar 2010 15:14:57 +0800

Dear Suresh,

Nice meeting you at IETF 77.

First of all, I agree with you that it is good for a UE to use a shorter prefix to meet the situation, rather than using multiple /64 prefixes.

Some additional comments about your draft:
1. Where to store the prefix length that you reserved for each UE?
2. How to validate the request from UE to avoid address abusing?
3. The proposed method in your draft seems address wasting, because you reserve /x (x < 64) prefix for each UE. It is better to store the minimum length that a UE can apply, and assign the proper lengh to UE based on the available adrress pool, the minimum length the UE can apply, and the length the UE actually requests.
4. Are there any other alternatives besides DHCPv6-PD? I listed some potential solutions in a 3GPP document. What is your opinion to them?

Best Regards,
Zhenqiang Li
13911635816
Department of Network Technology
China Mobile Research Institute
2010-03-26

---

From: "Frank Brockners (fbrockne)" <[email-masked]>
Date: Tue, 30 Mar 2010 09:33:00 +0200

Hi Zhenqiang Li,

please see some thoughts inline.. (Suresh will probably add more)

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> [email-masked]
> Subject: [3gv6] about Prefix delegation in 3GPP EPC networks
> 
> Dear Suresh,
> 
> First of all, I agree with you that it is good for a UE to use a
> shorter prefix to meet the situation, rather than using multiple /64
> prefixes.

...FB: there's been several discussions at this past IETF on this
particular topic - and the approach which seems to have wide support is
that for Release 10, one would support a model where one PDN connection
would continue to be represented by a *single* prefix. This prefix could
be shorter that /64. This means that we can still hand out multiple
prefixes to the UE, but it would always be possible to aggregate all of
them into a single prefix. We'd continue using SLAAC for assigning the
/64 for the UE (or better PDN-Connection-link) and would hand out the
remainder of the "shorter prefix" using DHCP PD. This will keep changes
to the current architecture to a minimum (incl. PCC will need to deal
with only a single prefix in its rules). More complex alternatives would
be explored in future releases (i.e. Release 11 and onwards).

I'm working on updating the contributions S2-101176, S2-101177,
S2-101178 that were submitted "for information" to the last 3GPP SA2
meeting to reflect these changes (which are only small deltas to the
current versions, so hope to have them available for discussion in the
next few days) (You can find the submitted version at
http://www.3gpp.org/ftp/tsg_sa/WG2_Arch/TSGS2_78_San_Francisco/Docs/)

> 2. How to validate the request from UE to avoid address abusing?

...FB: The expected approach is that shorter prefixes would be handled
as a capability of the APN. This way you also won't have any issues with
"abuse" - each UE (for a particular APN supporting shorter prefixes)
could use DHCPv6 PD to request portions of the prefix. 

> 3. The proposed method in your draft seems address wasting, because
you
> reserve /x (x < 64) prefix for each UE. It is better to store the
> minimum length that a UE can apply, and assign the proper lengh to UE
> based on the available adrress pool, the minimum length the UE can
> apply, and the length the UE actually requests.

...FB: If we do things on a per APN basis (as mentioned above), one
would expect that only those UEs who need shorter prefixes would use the
particular APN, so the amount of "wasted" addresses would be relatively
small. That said, the approach would just be for Release 10 (we just
have two more meetings to get this off the ground) - more optimal
approaches could be studied in future releases.

Regards, Frank

> 4. Are there any other alternatives besides DHCPv6-PD? I listed some
> potential solutions in a 3GPP document. What is your opinion to them?
> 
> Best Regards,
> Zhenqiang Li
> 13911635816
> _______________________________________________
> 3gv6 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/3gv6