Subject: Re: [3gv6] Prefix delegation / prefixes shorter than /64 discussion

From: "Hui Deng" <[email-masked]>
Date: Sat, 5 Dec 2009 17:37:55 +0800

Hi, Frank, 

You are saying IA-PD could indicate the prefix length that the requesting
router wishes? And this has already been supported by RFC3633?

How about Teemu, for your stateless, you have similar option to do it?

Thanks

-Hui

> -----Original Message-----
> From: Frank Brockners (fbrockne) [mailto:[email-masked]]
> Sent: Friday, December 04, 2009 3:17 AM
> To: [email-masked]; Vojislav Vucetic (vvucetic);
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked];
[email-masked];
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked];
> [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked];
[email-masked];
> [email-masked]; [email-masked];
> [email-masked]; [email-masked];
> [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; Dhananjay Patki
> (dhpatki)
> Subject: RE: Prefix delegation / prefixes shorter than /64 discussion
> 
> Hi Teemu,
> 
> sorry for the delay. On your question below: The 3rd use-case
> folds two deployment scenarios into a single one:
>   (a) the home router requests multiple
>       /64 prefixes, all of which taken
>       from a shorter /xx prefix.
>   (b) the home router requests prefixes
>       which do not necessary aggregate
>       into one shorter /yy prefix.
> 
> (a) optimizes the use of address space and avoids unnecessary
> fragmentation, i.e. whenever the home router brings up another
> interface, it'll request another /64 for this interface. This avoids
> delegating a shorter prefix to the home router - which is eventually
> not used to the full extend.
> 
> (b) is desired for operators who intend to use different prefixes/
> addresses for different services; e.g. the SP intends to supply
> different
> routing and access control lists for the in-house sensor networks
> (e.g. disallow access from the v6 internet). I agree, that this use case
> 
> is more specific than (a) above; but the idea was to be as generic
> as possible - and avoid restricting any potential use cases.
> 
> From my understanding, RFC 3633 covers both cases, given that we
> can have the requesting router populate the fields in the IA_PD
> to provide hints to the delegating router about what it desires;
> i.e. for (a) one can include prefix-length and for (b) one
> might add even a v6 prefix in the solicit message. This v6 prefix
> could indicate which address pool the prefix should be picked from
> (so it comes down to the implementation of rules on the DHCP server).
> 
> Regards, Frank
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]
> > Subject: RE: Prefix delegation / prefixes shorter than /64 discussion
> >
> > Hi Frank,
> >
> > Could you please elaborate the operational reasons for why different
> > types of networks would need to be differentiated by a prefix (the
> case
> > 2.3)? This is the first time I heard about such requirement. How would
> > that be done in DHCPv6 PD (RFC3633) approach - I mean is there already
> > standard for it?
> >
> > Thanks,
> >
> > 	Teemu
> >
> > >-----Original Message-----
> > >From: ext Frank Brockners (fbrockne) [mailto:[email-masked]]
> > >Sent: 19 November, 2009 04:08
> > >To: Savolainen Teemu (Nokia-D-MSW/Tampere); Vojislav Vucetic
> > >(vvucetic); [email-masked]; [email-masked];
> > >[email-masked]; [email-masked];
> > >[email-masked];
> > >[email-masked]; [email-masked];
> > >[email-masked]; [email-masked];
> > >[email-masked]; [email-masked];
> > >[email-masked]; [email-masked];
> > >[email-masked]; [email-masked];
> > >[email-masked]; [email-masked];
> > >Iisakkila Kaisu (Nokia-D/Helsinki);
> > >[email-masked]; [email-masked];
> > >[email-masked]; [email-masked];
> > >[email-masked]; [email-masked];
> > >[email-masked]; [email-masked];
> > >[email-masked]; [email-masked]; Kekki Sami.J
> > >(Nokia-CIC/Espoo); [email-masked];
> > >[email-masked]; [email-masked];
> > >[email-masked]; [email-masked];
> > >[email-masked]; [email-masked];
> > >[email-masked]; [email-masked];
> > >[email-masked]; [email-masked]; [email-masked];
> > >[email-masked]; [email-masked];
> > >[email-masked]; [email-masked];
> > >[email-masked]; [email-masked];
> > >Dhananjay Patki (dhpatki)
> > >Subject: RE: Prefix delegation / prefixes shorter than /64 discussion
> > >
> > >Hi Teemu,
> > >
> > >thanks for your email. Agreed, it makes sense to add a section
> > >on related technologies - will do this for a revision. Wrt/
> > >you draft - I agree that a "6rd-style" prefix computation on
> > >the UE might be an alternative, apart from the increased
> > >address space consumption, one challenge I see is that it only
> > >applies to a subset of the potential use cases (e.g. the 3rd
> > >use case outlined - where you'd want several different
> > >prefixes which cannot be summarized to a single one - would
> > >not be supported by this schema (unless you'd use multiple
> > >provider prefixes, which might not really be a feasible option).
> > >
> > >Thanks, Frank
> > >
> > >> -----Original Message-----
> > >> From: [email-masked]
> [mailto:[email-masked]]
> > >> Subject: RE: Prefix delegation / prefixes shorter than /64
> > discussion
> > >>
> > >> Hi,
> > >>
> > >> This is important and very useful piece of work. There indeed
> should
> > >be
> > >> means for shorter than /64 prefix delegation in 3GPP networks. The
> > >> document could additionally mention currently available /64 prefix
> > >> sharing technology: Neighbor Discovery Proxies (RFC4389), and some
> > >> words about its limits and issues.
> > >>
> > >> In the following Internet-Draft I have recently described an
> > >> alternative technical solution for the prefix delegation.
> > >Comments are
> > >> welcome:
> http://tools.ietf.org/html/draft-savolainen-stateless-pd-00
> > >>
> > >> With the described solution, UEs could calculate shorter than /64
> > >> delegated prefix by combining bits from the unique /64 prefix
> > >allocated
> > >> to the bearer with service provider's common prefix (learned
> > >e.g. with
> > >> stateless DHCPv6). I think this would be simpler solution
> > >for prefrix
> > >> delegation, but with the expense of higher IPv6 address space
> > >> consumption.
> > >>
> > >> Best regards,
> > >>
> > >> Teemu
> > >> ________________________________________
> > >> From: ext Vojislav Vucetic (vvucetic) [[email-masked]]
> > >> Sent: Friday, November 13, 2009 11:01 PM
> > >> To: [email-masked]; [email-masked];
> > >> [email-masked]; [email-masked];
> > >> [email-masked]; [email-masked];
> > >> [email-masked]; [email-masked];
> > >[email-masked];
> > >> [email-masked]; [email-masked];
> > >> [email-masked]; Hao Bi-QA4417; [email-masked];
> > >> [email-masked]; [email-masked];
> > >> [email-masked]; Iisakkila Kaisu (Nokia-D/Helsinki);
> > >> [email-masked]; [email-masked];
> > >> [email-masked]; [email-masked];
> > >[email-masked];
> > >> [email-masked]; [email-masked];
> > >> [email-masked]; [email-masked]; Salkintzis
> > >Apostolis-
> > >> Y1026C; Kekki Sami.J (Nokia-CIC/Espoo); Sebastian.Speicher@t-
> > >> mobile.net; [email-masked];
> > >[email-masked];
> > >> [email-masked]; [email-masked];
> > >Savolainen Teemu
> > >> (Nokia-D-MSW/Tampere); [email-masked];
> > >> [email-masked]; [email-masked];
> > >> [email-masked]; Xiaoming Zhao; [email-masked];
> > >> [email-masked]; [email-masked]; [email-masked];
> Tao
> > >> Sun; Stefano Faccin; Ali Irfan-FIA225; BENNETT, Andy (Andy); Frank
> > >> Brockners (fbrockne)
> > >> Subject: Prefix delegation / prefixes shorter than /64 discussion
> > >>
> > >> Dear All,
> > >>
> > >>
> > >>
> > >> We already reached some of you with a request to discuss and
> provide
> > >> the comments on the attached document. However, we would
> > >like to reach
> > >> other companies that might be interested in the prefix delegation
> > >> discussion. The document describes some uses cases that outline the
> > >> benefits of prefixes shorter than /64 on the UE. The paper also
> > >> outlines a possible technical solution.
> > >>
> > >> Our objective is to progress this idea in 3GPP based on your
> > >comments
> > >> and suggestions. We would very much appreciate your thoughts on the
> > >> document. Frank Brockners is our lead responsible for this and IPv6
> > >> migration activities.
> > >>
> > >>
> > >>
> > >> Thank you,
> > >>
> > >>
> > >>
> > >> vvv.
> > >>
> > >>
> > >>
> > >> P.S. Both Frank and I will be on the next SA2 meeting and we are
> > >> looking forward to discuss this issues in person or/and over the
> > >email.
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >
> > >

---

From: <[email-masked]>
Date: Sun, 6 Dec 2009 19:54:33 +0100

Hi, Hui,

I think the stateless approach is better suited for scenarios where large number of subscribers need to be provided with (few) additional prefixes. E.g. if all "IPv6 Internet" APN accessing UEs need to be provided with prefixes for local links, or e.g. for all UEs connected to dedicated "Internet Connection Sharing" APN, if there were one. 

The RFC3633 is the solution with flexibility.

Best regards,

Teemu

________________________________________
From: ext Hui Deng [[email-masked]]
Sent: Saturday, December 05, 2009 11:37 AM
To: 'Frank Brockners (fbrockne)'; Savolainen Teemu (Nokia-D-MSW/Tampere); [email-masked]
Subject: RE: Prefix delegation / prefixes shorter than /64 discussion

Hi, Frank,

Thanks

-Hui

[email-masked];

---

From: "Hui Deng" <[email-masked]>
Date: Tue, 8 Dec 2009 00:16:55 +0800

Hi, Teemu, 

Could you help to clarify your scenario difference with Frank's proposal,
are you targeting same scenario, by assign another prefix to the UE after it
get basic IPv4 prefix through RS/RA?

Are you proposing together with first RS/RA to assign the prefix to the UE?

I have difficulty to read your two examples, could you kind help to
elaborate a little more about details?

Many thanks

-Hui

> Sent: Monday, December 07, 2009 2:55 AM
> To: [email-masked]; [email-masked]; [email-masked]
> I think the stateless approach is better suited for scenarios where large
number
> of subscribers need to be provided with (few) additional prefixes. E.g. if
all
> "IPv6 Internet" APN accessing UEs need to be provided with prefixes for
local
> links, or e.g. for all UEs connected to dedicated "Internet Connection
Sharing"
> APN, if there were one.
[email-masked];
> [email-masked];
> [email-masked];

---

From: <[email-masked]>
Date: Mon, 7 Dec 2009 21:55:10 +0100

Hi, Hui,

The RFC3633 works so that when a node, a requesting router, needs one or more prefixes, it sends a request for a delegating router, which then responds with one or more prefixes. In 3GPP, an UE gets assigned /64 for a PDP context. When the UE needs to share the Internet connection with local area network, it could request for additional /64 from the cellular network. After receiving the additional /64, UE then would start to advertise that to LAN and starts routing. In the end, UE that first had single /64 for its PDP context is now consuming two /64's.

In the stateless approach, UE would be already assigned a delegated prefix at the very moment it was allocated the /64 by the GW. Without UE's request. So even if UE does not do any routing or sharing, it is allocated more than one /64. This saves the dynamic trouble of allocating prefixes on request, but consumes significantly more IPv6 address space.

In the stateless approach UE needs to calculate which prefixes it has been delegated, and it can do it 6RD style by asking first, e.g. with Stateless DHCPv6, what is the ISP prefix (e.g. /48) and append that with configured number of unique bits from the host-unique /64 prefix it got for the PDP context (say 10 bits), and thus by concatenating /48 from ISP prefix and 10 bits from the unique /64 prefix, the UE comes up with /58, which would be its statelessly delegated prefix. Of course the ISP prefix and number of bits information could be delivered in RA as well, but probably Stateless DHCPv6 is better.

I.e. in this stateless proposal, instead of the node's IPv4 address 6RD uses to concatenate with ISP prefix, bits from UE unique /64 prefix would be used.

The stateless approach, as described, would probably not work on shared medium where /64 is used by multiple devices. But in 3GPP the property of host unique /64 enables this approach.

--

In the RFC3633 approach IPv6 address space is minimally wasted, and DHCPv6 signaling is used to allocate exactly the right number of prefixes, at right time, and possible from multitude of different subnets as Frank said.

In the stateless proposal IPv6 address space is "wasted", only stateful DHCPv6 is needed for learning ISP prefix, and UE gets fixed delegated prefix with no room for negotiation, and usually from a single subnet (could be more, but that would mean multitude of ISP prefixes in use).

I.e. in this stateless approach IPv6 address space is consumed to gain savings elsewhere.

--

An example: if an operator would want to enable easy connection sharing with few prefixes for very many UEs, it could allocate /32 prefix for the sharing purpose and tell UEs to use 29 bits from the host-unique /64 in the concatenation process. That would give each UE 64-32-29=3 bits for local use, i.e. /61 would be delegated. So for giving 8 subnets per UE, operator could, by using /32, offer stateless prefix delegation for 536 million UEs (2^29), without having the burden of continuous DHCPv6 signaling messages and recording which UE was allocated what prefix.

If an operator would want to minimize number of IPv6 addresses spent on this feature, operator could define on APN that would be used by "CPEs", and this APN could be providing stateless prefix delegation like:
- ISP allocafted prefix of /40 for this use
- 20 unique bits from /64 => 2^20 = 1 million possible CPEs
- 64-40-20=4 bits, i.e. 16 subnets per CPE (=/60)
=> 1 million CPEs, each delegated /60 prefix, without single stateful DHCPv6 message exchange, without renew messages, or logging of who got what delegated prefix

See more details in: http://tools.ietf.org/html/draft-savolainen-stateless-pd-00

Comments are very welcome.

Best regards,

        Teemu

>From: ext Hui Deng [mailto:[email-masked]]
>Sent: 07 December, 2009 18:17
>To: Savolainen Teemu (Nokia-D-MSW/Tampere); [email-masked];
>[email-masked]
>> To: 'Frank Brockners (fbrockne)'; Savolainen Teemu (Nokia-D-
>MSW/Tampere);
>> [email-masked]
>[email-masked];
>[email-masked];
>[email-masked];

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 7 Dec 2009 15:14:10 -0800 (PST)

Hi Teemu,
  I read your draft, it is interesting.

The architecture you consider is similar to Nemo and currently Nemo-PD draft draft-ietf-mext-nemo-pd-03 in Mext WG proposes a DHCP PD or RFC 3633 based solution. We had a draft which proposed BU/BA signaling by keeping RR at the HA instead of at the MR. 
In Section 2.7 you mention Nemo type of application, I think but I am not sure.

What I would like to say is that we still need (stateful) prefix delegation to get /64 prefixes for so many new smart phones to be connected simulatenously to the networks.

Regards,

Behcet

----- Original Message ----
> From: "[email-masked]" <[email-masked]>
> Sent: Mon, December 7, 2009 2:55:10 PM
> Subject: Re: [3gv6] Prefix delegation / prefixes shorter than /64 discussion
> 
> Hi, Hui,
> 
> The RFC3633 works so that when a node, a requesting router, needs one or more 
> prefixes, it sends a request for a delegating router, which then responds with 
> one or more prefixes. In 3GPP, an UE gets assigned /64 for a PDP context. When 
> the UE needs to share the Internet connection with local area network, it could 
> request for additional /64 from the cellular network. After receiving the 
> additional /64, UE then would start to advertise that to LAN and starts routing. 
> In the end, UE that first had single /64 for its PDP context is now consuming 
> two /64's.
> 
> In the stateless approach, UE would be already assigned a delegated prefix at 
> the very moment it was allocated the /64 by the GW. Without UE's request. So 
> even if UE does not do any routing or sharing, it is allocated more than one 
> /64. This saves the dynamic trouble of allocating prefixes on request, but 
> consumes significantly more IPv6 address space.
> 
> In the stateless approach UE needs to calculate which prefixes it has been 
> delegated, and it can do it 6RD style by asking first, e.g. with Stateless 
> DHCPv6, what is the ISP prefix (e.g. /48) and append that with configured number 
> of unique bits from the host-unique /64 prefix it got for the PDP context (say 
> 10 bits), and thus by concatenating /48 from ISP prefix and 10 bits from the 
> unique /64 prefix, the UE comes up with /58, which would be its statelessly 
> delegated prefix. Of course the ISP prefix and number of bits information could 
> be delivered in RA as well, but probably Stateless DHCPv6 is better.
> 
> I.e. in this stateless proposal, instead of the node's IPv4 address 6RD uses to 
> concatenate with ISP prefix, bits from UE unique /64 prefix would be used.
> 
> The stateless approach, as described, would probably not work on shared medium 
> where /64 is used by multiple devices. But in 3GPP the property of host unique 
> /64 enables this approach.
> 
> --
> 
> In the RFC3633 approach IPv6 address space is minimally wasted, and DHCPv6 
> signaling is used to allocate exactly the right number of prefixes, at right 
> time, and possible from multitude of different subnets as Frank said.
> 
> In the stateless proposal IPv6 address space is "wasted", only stateful DHCPv6 
> is needed for learning ISP prefix, and UE gets fixed delegated prefix with no 
> room for negotiation, and usually from a single subnet (could be more, but that 
> would mean multitude of ISP prefixes in use).
> 
> An example: if an operator would want to enable easy connection sharing with few 
> prefixes for very many UEs, it could allocate /32 prefix for the sharing purpose 
> and tell UEs to use 29 bits from the host-unique /64 in the concatenation 
> process. That would give each UE 64-32-29=3 bits for local use, i.e. /61 would 
> be delegated. So for giving 8 subnets per UE, operator could, by using /32, 
> offer stateless prefix delegation for 536 million UEs (2^29), without having the 
> burden of continuous DHCPv6 signaling messages and recording which UE was 
> allocated what prefix.
> 
> If an operator would want to minimize number of IPv6 addresses spent on this 
> feature, operator could define on APN that would be used by "CPEs", and this APN 
> could be providing stateless prefix delegation like:
> => 1 million CPEs, each delegated /60 prefix, without single stateful DHCPv6 
> message exchange, without renew messages, or logging of who got what delegated 
> prefix
> 
> _______________________________________________
> 3gv6 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/3gv6

---

From: "Hui Deng" <[email-masked]>
Date: Tue, 8 Dec 2009 15:51:49 +0800

Hi Teemu

You are saying that EPC PDP context must assign an IPv6 prefix to the UE, 
RS/RA will be used to get the second one?

Is there any implementation to borrow the bit form unique for IPv6 prefix
and concatenate into a new delegated prefix? Will that borrrowed bit is same
bit be assigned to new delegated prefix? 

If you define APN for this example, that will be special route for those
delegated prefix, that route might not same as original /64 prefix?

It sounds that stateless is more interesting.
Thanks for the discussion

-Hui

> Sent: Tuesday, December 08, 2009 4:55 AM
DHCPv6,
> what is the ISP prefix (e.g. /48) and append that with configured number
of
> unique bits from the host-unique /64 prefix it got for the PDP context
(say
> I.e. in this stateless proposal, instead of the node's IPv4 address 6RD
uses
> to concatenate with ISP prefix, bits from UE unique /64 prefix would be
used.
> I.e. in this stateless approach IPv6 address space is consumed to gain
savings
> elsewhere.
> 
> --
> 
> An example: if an operator would want to enable easy connection sharing
with
> few prefixes for very many UEs, it could allocate /32 prefix for the
sharing
> purpose and tell UEs to use 29 bits from the host-unique /64 in the
concatenation
> offer stateless prefix delegation for 536 million UEs (2^29), without
having
> the burden of continuous DHCPv6 signaling messages and recording which UE
was
> feature, operator could define on APN that would be used by "CPEs", and
this
> APN could be providing stateless prefix delegation like:
> See more details in:

---

From: "Frank Brockners (fbrockne)" <[email-masked]>
Date: Tue, 8 Dec 2009 09:54:44 +0100

Hi Hui,

> From: Hui Deng [mailto:[email-masked]]

...FB: Yes - see RFC 3633, section 10: "A requesting router may set 
   the IPv6 prefix field to zero and a given value in the prefix-length
   field to indicate a preference for the size of the prefix to be
   delegated."

Regards, Frank

[email-masked];
[email-masked];
discussion
[email-masked];

---

From: "Hui Deng" <[email-masked]>
Date: Tue, 8 Dec 2009 16:55:58 +0800

Thanks

> Sent: Tuesday, December 08, 2009 4:55 PM
> To: Hui Deng
> Cc: [email-masked]; [email-masked]

---

From: <[email-masked]>
Date: Tue, 8 Dec 2009 10:37:08 +0100

Hi Hui,

When IPv6 or IPv4v6 type of PDP context/EPS bearer is set up, the PDN GW will assign one /64 for the bearer. UE will configure address(es) from this prefix for the bearer. RS/RA is used by SLAAC in this procedure.

In this stateless approach, from network point of view, for a bearer multiple prefixes are allocated at the time RS/RA communication for the "usual" /64 prefix. It is just that these additional prefixes are not signaled in RS/RA, but instead are implicitly allocated as described in the draft. The UE will need to know some additional information (such as the ISP prefix) to be able to calculate what prefixes it was actually implicitly allocated by the network.

There is no implementation of this draft for the time being.

Example of how it would work:
1) UE activates PDP context
2) Network assigns /64 for the context, as usual: 1111:1111:ABBA:0000::/64
3) Network sinforms UE that ISP prefix is 2222:2222::/32, and that UE should use 16bits from its unique /64
4) UE combines 2222:2222 with ABBA and comes up with delegated prefix 2222:2222:ABBA::/48

>From routing point of view, the routing must be configured to deliver to PDN GW (APN) packets destined to example prefix of 1111:1111::/32 - from where /64's are allocated for PDP contexts, and to 2222:2222::/32 - from where the UE's statelessly configure their delegated prefixes. As the setup here is large number of point-to-point links from UEs to GW, there is no need to have any dynamic route updates sent from PDN GW towards Internet. The PDN GW just needs to have big pool of IPv6 addresses to play with.

Thank you for your interest!

Best regards,

Teemu

>Sent: 08 December, 2009 09:52
>> The RFC3633 works so that when a node, a requesting router, needs one
>or
>more
>> prefixes, it sends a request for a delegating router, which then
>responds
>with
>> one or more prefixes. In 3GPP, an UE gets assigned /64 for a PDP
>context.
>When
>> the UE needs to share the Internet connection with local area network,
>it
>could
>> additional /64, UE then would start to advertise that to LAN and
>starts
>routing.
>> In the stateless approach, UE would be already assigned a delegated
>prefix
>at
>> the very moment it was allocated the /64 by the GW. Without UE's
>request.
>So
>> even if UE does not do any routing or sharing, it is allocated more
>than
>one
>> 10 bits), and thus by concatenating /48 from ISP prefix and 10 bits
>from
>the
>> delegated prefix. Of course the ISP prefix and number of bits
>information
>could
>> The stateless approach, as described, would probably not work on
>shared
>medium
>> where /64 is used by multiple devices. But in 3GPP the property of
>host
>unique
>> In the stateless proposal IPv6 address space is "wasted", only
>stateful
>DHCPv6
>> is needed for learning ISP prefix, and UE gets fixed delegated prefix
>with
>no
>> room for negotiation, and usually from a single subnet (could be more,
>but
>that
>> process. That would give each UE 64-32-29=3 bits for local use, i.e.
>/61
>would
>> If an operator would want to minimize number of IPv6 addresses spent
>on
>this
>> >Are you proposing together with first RS/RA to assign the prefix to
>the
>> >UE?
>> >
>> >> > (e.g. disallow access from the v6 internet). I agree, that this
>use
>> >case
>> >> >
>> >> > > 2.3)? This is the first time I heard about such requirement.
>How
>> >would
>> >> > > >> means for shorter than /64 prefix delegation in 3GPP
>networks.
>> >The
>> >> > > >> sharing technology: Neighbor Discovery Proxies (RFC4389),
>and
>> >some
>> >> > > >> With the described solution, UEs could calculate shorter
>than
>> >/64
>> >> > > >> discussion. The document describes some uses cases that
>outline
>> >the
>> >> > > >> and suggestions. We would very much appreciate your thoughts
>on
>> >the
>> >> > > >> document. Frank Brockners is our lead responsible for this
>and
>> >IPv6
>> >> > > >> migration activities.
>> >> > > >>
>> >> > > >>
>> >> > > >>
>> >> > > >> Thank you,
>> >> > > >>
>> >> > > >>
>> >> > > >>
>> >> > > >> vvv.
>> >> > > >>
>> >> > > >>
>> >> > > >>

---

From: <[email-masked]>
Date: Tue, 8 Dec 2009 12:15:48 +0100

Noticed one error in the example below - the UE should use lowest bits of the /64 of the bearer, i.e. the example should've been:

1111:1111:1111:ABBA::/64 for UE's PDP context, and 2222:2222::/32 as ISP prefix, thus UE taking the unique lowest 16 ABBA bits from the /64 for combination to come up with the 2222:2222:ABBA::/48.

The prefix length and number of unique bits needed are all variable.

Best regards,

Teemu

>From: [email-masked] [mailto:[email-masked]] On Behalf Of
>Savolainen Teemu (Nokia-D-MSW/Tampere)
>Sent: 08 December, 2009 11:37
>When IPv6 or IPv4v6 type of PDP context/EPS bearer is set up, the PDN GW
>will assign one /64 for the bearer. UE will configure address(es) from
>this prefix for the bearer. RS/RA is used by SLAAC in this procedure.
>
>In this stateless approach, from network point of view, for a bearer
>multiple prefixes are allocated at the time RS/RA communication for the
>"usual" /64 prefix. It is just that these additional prefixes are not
>signaled in RS/RA, but instead are implicitly allocated as described in
>the draft. The UE will need to know some additional information (such as
>the ISP prefix) to be able to calculate what prefixes it was actually
>implicitly allocated by the network.
>
>From routing point of view, the routing must be configured to deliver to
>PDN GW (APN) packets destined to example prefix of 1111:1111::/32 - from
>where /64's are allocated for PDP contexts, and to 2222:2222::/32 - from
>where the UE's statelessly configure their delegated prefixes. As the
>setup here is large number of point-to-point links from UEs to GW, there
>is no need to have any dynamic route updates sent from PDN GW towards
>Internet. The PDN GW just needs to have big pool of IPv6 addresses to
>play with.
>
>>> /64. This saves the dynamic trouble of allocating prefixes on
>request,
>>but
>>> signaling is used to allocate exactly the right number of prefixes,
>at
>>right
>>> be delegated. So for giving 8 subnets per UE, operator could, by
>using
>>/32,
>>> the burden of continuous DHCPv6 signaling messages and recording
>which
>>UE
>>was
>>> allocated what prefix.
>>>
>>> >> I think the stateless approach is better suited for scenarios
>where
>>> >large
>>> >number
>>> >> "IPv6 Internet" APN accessing UEs need to be provided with
>prefixes
>>> >for
>>> >local
>Dhananjay
>>> >Patki
>>> >> > > >> Sun; Stefano Faccin; Ali Irfan-FIA225; BENNETT, Andy
>(Andy);
>>> >Frank
>>> >> > > >> Brockners (fbrockne)
>>> >> > > >> P.S. Both Frank and I will be on the next SA2 meeting and
>we
>>> >are
>>> >> > > >> looking forward to discuss this issues in person or/and
>over
>>> >the
>>> >> > > >email.
>>> >> > > >>
>>> >> > > >>
>>> >> > > >>
>>> >> > > >>
>>> >> > > >>
>>> >> > > >>
>>> >> > > >
>>> >> > > >
>>> >>
>>> >
>>> >
>>
>>
>

---

From: <[email-masked]>
Date: Tue, 8 Dec 2009 12:58:07 +0100

Hi Behcet,

Thank you for your interest. The stateless approach could be similarly used for prefix delegation in Nemo, with similar pros and cons as with ordinary cellular access.

I forgot existence of Nemo when I wrote the 2.7, but in further revisions I will add that. Thank you. It is exactly about that.

I wonder if the stateless approach has less security implications than stateful, due to its more statical properties?

I'm not sure I got your last comment correctly, but definitely prefix delegation with a tool or another is needed for cellular networks.

Best regards,

        Teemu

>From: ext Behcet Sarikaya [mailto:[email-masked]]
>Sent: 08 December, 2009 01:14
>To: Savolainen Teemu (Nokia-D-MSW/Tampere); [email-masked]
>The architecture you consider is similar to Nemo and currently Nemo-PD
>draft draft-ietf-mext-nemo-pd-03 in Mext WG proposes a DHCP PD or RFC
>3633 based solution. We had a draft which proposed BU/BA signaling by
>keeping RR at the HA instead of at the MR.
>What I would like to say is that we still need (stateful) prefix
>delegation to get /64 prefixes for so many new smart phones to be
>connected simulatenously to the networks.
>
>Regards,
>
>Behcet
>
>
>
>or more
>responds with
>context. When
>it could
>starts routing.
>prefix at
>request. So
>than one
>from the
>information could
>shared medium
>host unique
>stateful DHCPv6
>with no
>but that
>/61 would
>having the
>on this

---

From: "Fredrik Garneij" <[email-masked]>
Date: Tue, 8 Dec 2009 14:05:27 +0100

Hi All,

Regardless of length or delegation method used I think it would be good
if the UE initial assigned /64 prefix is part of the larger prefix
delegated to the UE. The benefit of aggregation would serve both routing
and 3GPP PCC model (QoS, traffic separation, charging) well if this
approach would be used in most cases.

About wasting address space, is (pre)allocation a /48 or /56 for each UE
considered as waste of address space? Should the UE follow what is being
done in fixed network CPEs or should there be a special "cellular form
factor" prefix length? Is there a RIR or IANA opinion here? I can see
separate CPE APNs but do we need to make this separation. Simplicity vs.
waste.

///fredrik :-)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: den 8 december 2009 12:58
To: [email-masked]; [email-masked]
Subject: Re: [3gv6] Prefix delegation / prefixes shorter than /64
discussion

Hi Behcet,

Thank you for your interest. The stateless approach could be similarly
used for prefix delegation in Nemo, with similar pros and cons as with
ordinary cellular access.

I forgot existence of Nemo when I wrote the 2.7, but in further
revisions I will add that. Thank you. It is exactly about that.

I wonder if the stateless approach has less security implications than
stateful, due to its more statical properties?

I'm not sure I got your last comment correctly, but definitely prefix
delegation with a tool or another is needed for cellular networks.

Best regards,

        Teemu

>> - 64-40-20=4 bits, i.e. 16 subnets per CPE (=/60) => 1 million CPEs, 
>> each delegated /60 prefix, without single stateful
>DHCPv6
>> >Could you help to clarify your scenario difference with Frank's 
>> >proposal, are you targeting same scenario, by assign another prefix 
>> >to the UE after it get basic IPv4 prefix through RS/RA?
>> >
>> >> > different routing and access control lists for the in-house 
>> >> > sensor networks (e.g. disallow access from the v6 internet). I 
>> >> > agree, that this
>use
>> >case
>> >> >

>> >> > i.e. for (a) one can include prefix-length and for (b) one might

>> >> > add even a v6 prefix in the solicit message. This v6 prefix 
>> >> > > >thanks for your email. Agreed, it makes sense to add a 
>> >> > > >section on related technologies - will do this for a 
>> >> > > >revision. Wrt/ you draft - I agree that a "6rd-style" prefix 
>> >> > > >computation on the UE might be an alternative, apart from the

>> >> > > >increased address space consumption, one challenge I see is 
>> >> > > >that it only applies to a subset of the potential use cases 
>> >> > > >(e.g. the 3rd use case outlined - where you'd want several 
>> >> > > >different prefixes which cannot be summarized to a single one

>> >> > > >- would not be supported by this schema (unless you'd use 
>> >> > > >multiple provider prefixes, which might not really be a 
>> >> > > >feasible
>option).
>> >> > > >
>> >> > > >Thanks, Frank
>> >> > > >
>> >> > > >> In the following Internet-Draft I have recently described 
>> >> > > >> an alternative technical solution for the prefix
delegation.

---

From: "Laganier, Julien" <[email-masked]>
Date: Tue, 8 Dec 2009 08:39:19 -0800

Hi Teemu,

Some comments from my side:

[email-masked] wrote:
> 
> Hi Hui,
> 
> When IPv6 or IPv4v6 type of PDP context/EPS bearer is set up, the PDN
> GW will assign one /64 for the bearer. UE will configure address(es)
> from this prefix for the bearer. RS/RA is used by SLAAC in this
> procedure.
> 
> "usual" /64 prefix.

I think it is a bit misleading to call the PDN GW allocating a /64 prefix to an UE a "stateless" approach.

>From an address perspective, the process involving address configuration out of the allocated /64 is indeed stateless, because the UE using stateless address auto-configuration (SLAAC) needs not to create state with the network for each of the individual addresses it is configuring out of the prefix.

However, from a prefix perspective, the PDN GW has to create state for each /64 prefix it is allocating to an UE to make sure it's not allocating the same prefix twice to two different UEs. Thus, the process of allocating a /64 prefix is entirely stateful: Prefix allocation state is created between the network and the UE at PDP context / EPS bearer set up, and deleted when they're tore down. 

> It is just that these additional prefixes are not
> the draft. The UE will need to know some additional information (such
> as the ISP prefix) to be able to calculate what prefixes it was
> actually implicitly allocated by the network.

I do not understand the benefit of allocating a larger block than the /64 advertized in the RS/RA and not signaling it to the UE. Could you elaborate? What do we gain by making the allocation but not signaling?
 
Best,

--julien

---

From: <[email-masked]>
Date: Tue, 8 Dec 2009 18:35:15 +0100

Hi Julien,

>I think it is a bit misleading to call the PDN GW allocating a /64 prefix to an UE a "stateless" approach.

I referred the stateless delegation when I wrote "In this stateless..", sorry for causing confusion by bad english... I did't mean to say allocation of the /64 for bearer is stateless.

>From an address perspective, the process involving address configuration
>out of the allocated /64 is indeed stateless, because the UE using stateless 
>address auto-configuration (SLAAC) needs not to create state with the 
>network for each of the individual addresses it is configuring out of the prefix.
>
>However, from a prefix perspective, the PDN GW has to create state for each 
>/64 prefix it is allocating to an UE to make sure it's not allocating the same 
>prefix twice to two different UEs. Thus, the process of allocating a /64 prefix 
>is entirely stateful: Prefix allocation state is created between the network and
>the UE at PDP context / EPS bearer set up, and deleted when they're tore down.

This is of course correct.

>I do not understand the benefit of allocating a larger block than the /64 advertized
>in the RS/RA and not signaling it to the UE. Could you elaborate? What do we gain
>by making the allocation but not signaling?

The allocation is of course always available for UEs to learn, as described in my draft. Signaling of required information happens when needed, but not needlessly. 

Obviously majority of UEs do not need additional prefixes, and bluntly allocating prefixes for them may seem illogical. But I have been wondering if it is actually cheaper by default to allocate all UEs with more than one /64 if some UEs need more, rather than establish a system for dynamic prefix delegation ala RFC3633 for those UEs that actually need prefixes (except when justified by use-cases such as discussed earlier in this thread)? 

To limit this "logical waste of addresses" one could use stateless delegation of rather long prefixes (like /60), or use this delegation method with specific APNs (such as "APN for LTE CPEs").

Maybe coexistence with RFC3633 could work so that all UEs would statelessly get like /60 or /62, which would be enough to cover simplest - and likely most common - scenarios while minimizing this "waste", and then DHCPv6 PD would be there for those UEs that need special treatment (such as prefixes from different domains)?

Best regards,

Teemu

---

From: "Laganier, Julien" <[email-masked]>
Date: Tue, 8 Dec 2009 15:00:22 -0800

[email-masked] wrote:
> I referred the stateless delegation when I wrote "In this stateless..",
> sorry for causing confusion by bad english... I did't mean to say
> allocation of the /64 for bearer is stateless.

Prefix delegation implies prefix allocation -- Before you can delegate the use of a prefix you have to allocate it for that use. 

OTOH, since we also agree that the prefix allocation is a stateful process where state is created between the UE and the network (as opposed to stateless address auto-configuration), to me prefix delegation must be stateful.

So I don't quite understand what stateless delegation is, neither what benefits it has over plain (stateful) prefix delegation...
 
> The allocation is of course always available for UEs to learn, as
> described in my draft. Signaling of required information happens when
> needed, but not needlessly.

I have read the draft but do not understand the motivation. What's the benefit compared with traditional RFC 3633? With RFC 3633 signaling does happen when needed, but not needlessly.

> Obviously majority of UEs do not need additional prefixes, and bluntly
> allocating prefixes for them may seem illogical. But I have been
> wondering if it is actually cheaper by default to allocate all UEs with
> more than one /64 if some UEs need more, rather than establish a system
> for dynamic prefix delegation ala RFC3633 for those UEs that actually
> need prefixes (except when justified by use-cases such as discussed
> earlier in this thread)?

Cheap in terms of what?

It's already possible with RFC 3633 to allocate all UEs with more than one /64 and delegate that to them as they request it...

--julien

> To limit this "logical waste of addresses" one could use stateless
> delegation of rather long prefixes (like /60), or use this delegation
> method with specific APNs (such as "APN for LTE CPEs").
>
> Maybe coexistence with RFC3633 could work so that all UEs would
> statelessly get like /60 or /62, which would be enough to cover
> simplest - and likely most common - scenarios while minimizing this
> "waste", and then DHCPv6 PD would be there for those UEs that need
> special treatment (such as prefixes from different domains)?
> 
> Best regards,
> 
> Teemu

---

From: "Hui Deng" <[email-masked]>
Date: Wed, 9 Dec 2009 14:37:33 +0800

One more comment, could we assume the lowest 16 bit /64 won't be overlapped?

Thanks

-Hui

> Sent: Tuesday, December 08, 2009 7:16 PM
> Noticed one error in the example below - the UE should use lowest bits of
the
> /64 of the bearer, i.e. the example should've been:
> 
> 1111:1111:1111:ABBA::/64 for UE's PDP context, and 2222:2222::/32 as ISP
> prefix, thus UE taking the unique lowest 16 ABBA bits from the /64 for
> combination to come up with the 2222:2222:ABBA::/48.
> 
> >>> >proposal,
> >section
> >an

---

From: "Hui Deng" <[email-masked]>
Date: Wed, 9 Dec 2009 14:37:33 +0800

Hi Teemu,

I just read ur draft, for my guessing, wasting is not a issue,
There are still one thing I am not clear still: you said about APN
How does it really work with PD? Since your orginal PDP /64 already belong
to 1 APN, how could this become the second one?

Thanks

-Hui

> Sent: Tuesday, December 08, 2009 5:37 PM
will
> assign one /64 for the bearer. UE will configure address(es) from this
prefix
> for the bearer. RS/RA is used by SLAAC in this procedure.
> 
multiple
> prefixes are allocated at the time RS/RA communication for the "usual" /64
> prefix. It is just that these additional prefixes are not signaled in
RS/RA,
> but instead are implicitly allocated as described in the draft. The UE
will
> need to know some additional information (such as the ISP prefix) to be
able
> to calculate what prefixes it was actually implicitly allocated by the
network.
> 3) Network sinforms UE that ISP prefix is 2222:2222::/32, and that UE
should
> use 16bits from its unique /64
PDN
> GW (APN) packets destined to example prefix of 1111:1111::/32 - from where
/64's
> are allocated for PDP contexts, and to 2222:2222::/32 - from where the
UE's
> statelessly configure their delegated prefixes. As the setup here is large
> number of point-to-point links from UEs to GW, there is no need to have
any
> dynamic route updates sent from PDN GW towards Internet. The PDN GW just
needs
> to have big pool of IPv6 addresses to play with.
>

---

From: <[email-masked]>
Date: Wed, 9 Dec 2009 10:47:40 +0100

Hi Fredrik,

You mean /56 would be reserved for an UE, from where GW would pick one /64 to be advertised in RA for the UE. Then UE, after learning the /56, would understand that one /64 of that space is already in use at UEs uplink interface?

I don't believe /56 per UE is a big deal, especially if it provides less complexity. I'm not aware of RIR/IANA opinions on this.

Best regards,

Teemu

>ext Fredrik Garneij
>Sent: 08 December, 2009 15:05
>To: [email-masked]

---

From: <[email-masked]>
Date: Wed, 9 Dec 2009 11:12:15 +0100

>Prefix delegation implies prefix allocation -- Before you can delegate
>the use of a prefix you have to allocate it for that use.
>
>OTOH, since we also agree that the prefix allocation is a stateful
>process where state is created between the UE and the network (as
>opposed to stateless address auto-configuration), to me prefix
>delegation must be stateful.

When UE is allocated /64, a state is created in the network. Now with RFC3633 PD, when additional prefixes are delegated, also additional states have to be created.

With the stateless approach, there is no need for _additional_ state besides the /64 already allocated for the UE...

But maybe that depends on what do we mean by state.

On the GW, there has to be routing information for routing the /64, and the calculated (say) /56 to the UE. But the route entry for this /56 can be created at the moment /64 is allocated to the UE, and removed when the /64 is removed. 

If there is source address validation taking place, that function of course needs to also become aware what source prefixes are allowed on UE. 

The firewall on downlink, well, it probably does not allow unsolicited downlink traffic? But if it does, then state there needs update?

In DHCPv6 PD, the DHCPv6 server needs to be aware what prefixes have been allocated to whom. In the stateless approach, there is no need for that.

Policy control, charging, will know who using using the addresses if they know who has /64, as they also can calculate what is the delegated prefixes for that UE - there is no need for additional signaling.

Where else is state that needs to be considered?

>So I don't quite understand what stateless delegation is, neither what
>benefits it has over plain (stateful) prefix delegation...
>
>I have read the draft but do not understand the motivation. What's the
>benefit compared with traditional RFC 3633? With RFC 3633 signaling does
>happen when needed, but not needlessly.

By learning the /64 prefix, the UE can know what prefixes it has been delegated.

Less signaling. Probably savings on UE implementation, as Stateless DHCPv6 is enough and full DHCPv6 is not required. 

>> need prefixes (except when justified by use-cases such as discussed

Less implementation on UE, less signaling, less states to be kept.

>It's already possible with RFC 3633 to allocate all UEs with more than
>one /64 and delegate that to them as they request it...

Yes. What I'm proposing is more optimization than new feature as such.

Best regards,

Teemu

---

From: <[email-masked]>
Date: Wed, 9 Dec 2009 16:35:22 +0100

That's my assumption.

Of course it is possible to configure network to give prefixse with overlapping lower bits, but either those networks would not use the stateless delegation as described, or then higher bits would be used instead.

6RD builds delegated prefix by using (locally) unique IPv4 address. My intent here is to describe how the bits from IPv4 address can be replaced from (locally) unique bits from elsewhere, in order to gain similar delegation feature to IPv6-only networks. So the source does not necessarily have to be IPv6 prefix, any other locally unique source would do as well...

What is additionally interesting is that if the UE has dual-stack bearer, then IPv4 address could be used as source just like in 6RD. I.e. prefix could be automatically delegated 6RD style but instead of encapsulating IPv6 in IPv4, IPv6 packets would be sent out directly. This is not described in the draft, but was just thinking at the time of writing.

Best regards,

Teemu

>Sent: 09 December, 2009 08:38
>GW
>as
>> >should use 16bits from its unique /64
>> >>You are saying that EPC PDP context must assign an IPv6 prefix to
>the
>> >>UE,
>> >>and concatenate into a new delegated prefix? Will that borrrowed bit
>is
>> >>same
>> >>> request for additional /64 from the cellular network. After
>receiving
>> >>the
>> >>> In the end, UE that first had single /64 for its PDP context is
>now
>> >>consuming
>> >>> two /64's.
>> >>>
>> >>> In the stateless approach UE needs to calculate which prefixes it
>has
>> >>been
>> >>> I.e. in this stateless proposal, instead of the node's IPv4
>address
>> >>6RD
>> >>uses
>> >>> to concatenate with ISP prefix, bits from UE unique /64 prefix
>would
>> >>be
>> >>used.
>> >>>
>> >>> In the RFC3633 approach IPv6 address space is minimally wasted,
>and
>> >>DHCPv6
>> >>> feature, operator could define on APN that would be used by
>"CPEs",
>> >>and
>> >>this
>> >>> => 1 million CPEs, each delegated /60 prefix, without single
>stateful
>> >>DHCPv6
>> >>> message exchange, without renew messages, or logging of who got
>what
>> >>delegated
>> >>> prefix
>> >>>
>> >>> See more details in:
>> >>> >are you targeting same scenario, by assign another prefix to the
>UE
>> >>> >after it
>> >>> >> of subscribers need to be provided with (few) additional
>prefixes.
>> >>> >E.g. if
>> >>> >all
>> >>> >> How about Teemu, for your stateless, you have similar option to
>do
>> >>it?
>> >>> >>
>> >>> >> Thanks
>> >>> >>
>> >>> >> -Hui
>> >>> >>
>> >>> >> > > types of networks would need to be differentiated by a
>prefix
>> >>(the
>> >>> >> > case
>> >>> >> > > that be done in DHCPv6 PD (RFC3633) approach - I mean is
>there
>> >>> >already
>> >>> >> > > standard for it?
>> >>> >> > >
>> >>> >> > > Thanks,
>> >>> >> > >
>> >>> >> > >     Teemu
>> >>> >> > >
>> >>> >> > > >> document could additionally mention currently available
>/64
>> >>> >prefix
>> >>> >> > > >> benefits of prefixes shorter than /64 on the UE. The
>paper
>> >>also

---

From: <[email-masked]>
Date: Wed, 9 Dec 2009 16:40:08 +0100

Hi Hui,

Thank you for reading. What I ment in the email is that in some APNs stateless delegation would not necessarily be made available (if, for some reason, operator wants to have separate APNs for routers than hosts).

In those APNs where stateless delegation would be available, also the original /64 from the PDN would come from the same APN as the delegated prefixes.

Best regards,

Teemu

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 10 Dec 2009 07:38:40 -0800 (PST)

Hi Teemu,
  Thank you for your kind response.

In case of Nemo, I was wondering what would be the ISP Prefix?

Another comment I have is about MiFi type of CPEs where uplink is cellular interface but the downlink is WiFi which is a shared link. In such a case I think that /64 prefix assigned to the uplink can be shared by the hosts connected to WiFi.

Regards,

Behcet

----- Original Message ----
> Sent: Tue, December 8, 2009 5:58:07 AM
> Subject: RE: [3gv6] Prefix delegation / prefixes shorter than /64 discussion
> 
> Hi Behcet,
> 
> Thank you for your interest. The stateless approach could be similarly used for 
> prefix delegation in Nemo, with similar pros and cons as with ordinary cellular 
> access.
> 
> I forgot existence of Nemo when I wrote the 2.7, but in further revisions I will 
> add that. Thank you. It is exactly about that.
> 
> I'm not sure I got your last comment correctly, but definitely prefix delegation 
> with a tool or another is needed for cellular networks.
> 
> Best regards,
> 
>         Teemu
> 
> >> From: "[email-masked]"

---

From: <[email-masked]>
Date: Thu, 10 Dec 2009 16:50:57 +0100

Hi,

Thank you for this exchanges and this propsition regarding stateless approach.
In the future, various "terminals" are likely to be conencted to cellular networks, including some CPE, handsets, sensosrs, and I think that we may need some possible dynamic configuration policy to allocate various prefixes lenths to these terminals. If not, we may have to allocate some default prefixes, to be determined, and it may be not optimal to allocate some /64 for example to sensors or too limited to allocate /64 to CPEs. So, we may have to identify connected devices "type" to allocate statelessly or statefully prefixes or addresses to these terminals.
Best Regards
David

> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] De
> la part de Behcet Sarikaya
> Envoyé : jeudi 10 décembre 2009 16:39
> À : [email-masked]; [email-masked]
> Objet : Re: [3gv6] Prefix delegation / prefixes shorter than
> /64 discussion
>
> Hi Teemu,
> Another comment I have is about MiFi type of CPEs where
> uplink is cellular interface but the downlink is WiFi which
> is a shared link. In such a case I think that /64 prefix
> assigned to the uplink can be shared by the hosts connected to WiFi.
>
> Regards,
>
> Behcet
>
>
> > >The architecture you consider is similar to Nemo and currently
> > >Nemo-PD draft draft-ietf-mext-nemo-pd-03 in Mext WG
> proposes a DHCP
> > >PD or RFC
> > >In Section 2.7 you mention Nemo type of application, I
> think but I am
> > >not sure.
> > >
> > >> The RFC3633 works so that when a node, a requesting
> router, needs
> > >> one
> > >or more
> > >> In the end, UE that first had single /64 for its PDP
> context is now
> > >consuming
> > >> two /64's.
> > >>
> > >> I.e. in this stateless proposal, instead of the node's
> IPv4 address
> > >6RD uses to
> > >> concatenate with ISP prefix, bits from UE unique /64
> prefix would
> > >> be
> > >used.
> > >>
> > >> In the RFC3633 approach IPv6 address space is minimally
> wasted, and
> > >DHCPv6
> > >> I.e. in this stateless approach IPv6 address space is
> consumed to
> > >> gain
> > >savings
> > >> elsewhere.
> > >>
> > >> --
> > >>
> > >> burden of continuous DHCPv6 signaling messages and
> recording which
> > >> UE
> > >was
> > >> allocated what prefix.
> > >>
> > >> feature, operator could define on APN that would be used
> by "CPEs",
> > >and this APN
> > >> - 64-40-20=4 bits, i.e. 16 subnets per CPE (=/60) => 1 million
> > >> CPEs, each delegated /60 prefix, without single stateful
> > >DHCPv6
> > >> >proposal, are you targeting same scenario, by assign another
> > >> >prefix to the UE after it get basic IPv4 prefix through RS/RA?
> > >> >
> > >> >Are you proposing together with first RS/RA to assign
> the prefix
> > >> >to
> > >the
> > >> >UE?
> > >> >
> > >> >I have difficulty to read your two examples, could you
> kind help
> > >> >to elaborate a little more about details?
> > >> >
> > >> >Many thanks
> > >> >
> > >> >-Hui
> > >> >
> > >> >> of subscribers need to be provided with (few)
> additional prefixes.
> > >> >E.g. if
> > >> >all
> > >> >> > interface, it'll request another /64 for this
> interface. This
> > >avoids
> > >> >> > addresses for different services; e.g. the SP intends to
> > >> >> > supply different routing and access control lists for the
> > >> >> > in-house sensor networks (e.g. disallow access from the v6
> > >> >> > internet). I agree, that this
> > >use
> > >> >case
> > >> >> >
> > >> >> > From my understanding, RFC 3633 covers both cases,
> given that
> > >> >> > we can have the requesting router populate the
> fields in the
> > >> >> > IA_PD to provide hints to the delegating router
> about what it
> > >> >> > desires; i.e. for (a) one can include prefix-length and for
> > >> >> > (b) one might add even a v6 prefix in the solicit message.
> > >> >> > This v6 prefix could indicate which address pool the prefix
> > >> >> > should be picked
> > >from
> > >> >> > > >To: Savolainen Teemu (Nokia-D-MSW/Tampere); Vojislav
> > >> >> > > >Vucetic (vvucetic); [email-masked];
> > >> >> > > >[email-masked]; [email-masked];
> > >> >> > > >revision. Wrt/ you draft - I agree that a "6rd-style"
> > >> >> > > >prefix computation on the UE might be an
> alternative, apart
> > >> >> > > >from the increased address space consumption,
> one challenge
> > >> >> > > >I see is that it only applies to a subset of the
> potential
> > >> >> > > >use cases (e.g. the 3rd use case outlined - where you'd
> > >> >> > > >want several different prefixes which cannot be
> summarized
> > >> >> > > >to a single one - would not be supported by this schema
> > >> >> > > >(unless you'd use multiple provider prefixes,
> which might
> > >> >> > > >not really be a feasible
> > >option).
> > >> >> > > >
> > >> >> > > >Thanks, Frank
> > >> >> > > >
> > >> >> > > >> an alternative technical solution for the
> prefix delegation.
> > >> >> > > >Comments are
> > >> >> > > >> welcome:
> [email-masked];
> > >> >> > > >> [email-masked];
> > >> >> > > >[email-masked];
> > >> >> > > >> We already reached some of you with a request
> to discuss
> > >> >> > > >> and
> > >> >> > provide
> > >> >> > > >> Our objective is to progress this idea in 3GPP
> based on
> > >> >> > > >> your
> > >> >> > > >comments

*********************************
This message and any attachments (the "message") are confidential and intended solely for the addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
France Telecom Group shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
********************************

---

From: <[email-masked]>
Date: Thu, 10 Dec 2009 20:19:08 +0100

Hi Bechet,

I'm not sure what you exactly mean by the ISP Prefix question? It could be like /40 selected from ISP's IPv6 address space?

In such MiFi scenario, with different type of up/downlinks, I think the CPE can indeed implement ND Proxy as per RFC4389 (Experimental). Or do you have some other solution in mind? ND proxy is of course not as good as "true" prefix delegation, though: in 6man/v6ops WGs there's recently been some discussions about issues with ND proxy, and it would also make it impossible for PC'es attaching to WLAN to further share the prefix with their possible downlink interfaces... But anyway, the ND Proxy is still way better than NAT66:-)

Best regards,

Teemu
________________________________________
From: ext Behcet Sarikaya [[email-masked]]
Sent: Thursday, December 10, 2009 5:38 PM
To: Savolainen Teemu (Nokia-D-MSW/Tampere); [email-masked]
Subject: Re: [3gv6] Prefix delegation / prefixes shorter than /64 discussion

Hi Teemu,

Regards,

Behcet

---

From: <[email-masked]>
Date: Thu, 10 Dec 2009 22:00:17 +0100

Hi David,

In the case you described, maybe the identification could be based on subscription of the client, rather than identifying the type of the device used?

E.g. if the subscription is say for "smartphone user", give an /64 prefix that comes with stateless PD for additional prefixes, but if subscription is for "CPE", then use DHCPv6 PD?

Best regards,

Teemu
________________________________________
From: ext [email-masked] [[email-masked]]
Sent: Thursday, December 10, 2009 5:50 PM
To: Behcet Sarikaya; Savolainen Teemu (Nokia-D-MSW/Tampere); [email-masked]
Subject: RE: [3gv6] Prefix delegation / prefixes shorter than /64 discussion

Hi,

> [email-masked];

---

From: "Laganier, Julien" <[email-masked]>
Date: Thu, 10 Dec 2009 13:19:12 -0800

Hello Teemu,

So this is what I understand from your proposal: 

It is specifying a "trick" (I don't mean to be pejorative, I just can't find a better word) that both the UE and the network abides with, where the network allocates a shorter-than-64 (say 56 for the rest of the discussion) prefix to the UE at PDN connection set-up, and advertizes in a RA a specific /64 out of it (say the lower /64 prefix out of the /56). 

Since the UE knows the trick, when it receives the RA with the /64 it knows that in reality it got the whole /56, and does not need to do DHCPv6 PD signaling to get it.

All in all:
- you're saving DHCPv6 PD signaling.
- UE and Network need to be modified to implement the specified behavior
- similar state has to be kept, i.e., the /56 was allocated to this UE

My 2 cents: I don't think it's worth. 

Also, so far 3GPP has relied on the use of standard IETF mechanisms for IPv6 configuration. I fail to see a compelling reason or a shortcoming of the existing IETF IPv6 configuration mechanisms (e.g., DHCPv6 PD) that would motivate the IETF to charter new work in that space. 

If that doesn't happen, adopting your proposal in 3GPP would mean that 3GPP is deviating from standard IETF mechanisms for IPv6 configuration. 

--julien

[email-masked] wrote:
> When UE is allocated /64, a state is created in the network. Now with
> RFC3633 PD, when additional prefixes are delegated, also additional
> states have to be created.
> 
> With the stateless approach, there is no need for _additional_ state
> besides the /64 already allocated for the UE...
> 
> On the GW, there has to be routing information for routing the /64, and
> the calculated (say) /56 to the UE. But the route entry for this /56
> can be created at the moment /64 is allocated to the UE, and removed
> when the /64 is removed.
> 
> If there is source address validation taking place, that function of
> course needs to also become aware what source prefixes are allowed on
> UE.
> 
> The firewall on downlink, well, it probably does not allow unsolicited
> downlink traffic? But if it does, then state there needs update?
> 
> In DHCPv6 PD, the DHCPv6 server needs to be aware what prefixes have
> been allocated to whom. In the stateless approach, there is no need for
> that.
> 
> Policy control, charging, will know who using using the addresses if
> they know who has /64, as they also can calculate what is the delegated
> prefixes for that UE - there is no need for additional signaling.
> 
> Less signaling. Probably savings on UE implementation, as Stateless
> DHCPv6 is enough and full DHCPv6 is not required.
>

---

From: <[email-masked]>
Date: Fri, 11 Dec 2009 08:24:41 +0100

Hi Julien,

Thank you for your opinion. I would like hear other views especially from the operator side.

Your understanding is essentially correct. 

If a host has public IPv4 address, it can use 6to4 to come up with set of "delegated" IPv6 prefixes, as described in RFC3056. If a host has private IPv4 address and operator is using 6RD, the host can come up with set of delegated prefixes. In these cases encapsulation is used. Why it would not be useful to have similar property in IPv6 only access? Why the prefix delegation is required to be done via explicit signaling with DHCPv6 server, as the host does not need DHCPv6 for its address configuration?

On the details I could still add that that the /64 does not have to come from the /56. 

Which is bigger host side implementation: DHCPv6 PD or stateless PD? In addition to host modifications that overally are required anyway (I don't think DHCPv6 PD is widely implemented in todays cellular hosts), the affected 3GPP network elements have to be changed anyway as well, as DHCPv6 PD is not supported by current 3GPP specs yet.

All in all, I want to say that I also think IETF defined prefix delegation solution should be used. That's why the stateless approach is contributed as an Internet-Draft:)

Best regards,

Teemu
________________________________________
From: ext Laganier, Julien [[email-masked]]
Sent: Thursday, December 10, 2009 11:19 PM
To: Savolainen Teemu (Nokia-D-MSW/Tampere); [email-masked]; [email-masked]; [email-masked]
Subject: RE: Prefix delegation / prefixes shorter than /64 discussion

Hello Teemu,

All in all:

--julien

---

From: "Fredrik Garneij" <[email-masked]>
Date: Fri, 11 Dec 2009 12:01:28 +0100

Hi Teemu,

For simplicity of routing and 3GPP specified mechanisms like PCC I think
there will be less complexity if the UE /64 would be a part (maybe the
"first" /64 as a suggestion?) of the shorter, lets say /56 prefix that
could be delegated to the /UE regardless of when it is delegated or by
type of mechanism used for delegation. Any thoughts?

///fredrik :-)  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: den 9 december 2009 10:48
To: Fredrik Garneij; [email-masked]
Subject: RE: [3gv6] Prefix delegation / prefixes shorter than /64
discussion

Hi Fredrik,

You mean /56 would be reserved for an UE, from where GW would pick one
/64 to be advertised in RA for the UE. Then UE, after learning the /56,
would understand that one /64 of that space is already in use at UEs
uplink interface?

I don't believe /56 per UE is a big deal, especially if it provides less
complexity. I'm not aware of RIR/IANA opinions on this.

Best regards,

Teemu

>delegated to the UE. The benefit of aggregation would serve both 
>routing and 3GPP PCC model (QoS, traffic separation, charging) well if 
>this approach would be used in most cases.
>
>About wasting address space, is (pre)allocation a /48 or /56 for each 
>UE considered as waste of address space? Should the UE follow what is 
>being done in fixed network CPEs or should there be a special "cellular

>form factor" prefix length? Is there a RIR or IANA opinion here? I can 
>see separate CPE APNs but do we need to make this separation.
Simplicity vs.

>>> burden of continuous DHCPv6 signaling messages and recording which 
>>> UE
>>was
>>> allocated what prefix.
>>>

prefixes.

>>> >> > might

---

From: <[email-masked]>
Date: Mon, 14 Dec 2009 10:48:46 +0100

Hi Fredrik,

Sounds sensible for me. Frank, what do you think?

Is that described somewhere, or should there perhaps be separate I-D to describe that scenario/optimization?

Best regards,

Teemu

>From: ext Fredrik Garneij [mailto:[email-masked]]
>Sent: 11 December, 2009 13:01

---

From: "Fredrik Garneij" <[email-masked]>
Date: Fri, 18 Dec 2009 16:00:13 +0100

Hi Teemu,

I am willing to work on such an I-D.

///fredrik :-)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: den 14 december 2009 10:49
To: Fredrik Garneij; [email-masked]; [email-masked]
Subject: RE: [3gv6] Prefix delegation / prefixes shorter than /64
discussion

Hi Fredrik,

Is that described somewhere, or should there perhaps be separate I-D to
describe that scenario/optimization?

Best regards,

Teemu

>For simplicity of routing and 3GPP specified mechanisms like PCC I 
>think there will be less complexity if the UE /64 would be a part 
>(maybe the "first" /64 as a suggestion?) of the shorter, lets say /56 
>prefix that could be delegated to the /UE regardless of when it is 
>delegated or by type of mechanism used for delegation. Any thoughts?
>
>///fredrik :-)
>

>I don't believe /56 per UE is a big deal, especially if it provides 
>less complexity. I'm not aware of RIR/IANA opinions on this.
>
>Best regards,
>
>Teemu
>

>>>Nemo-PD

>>>In Section 2.7 you mention Nemo type of application, I think but I am

>>>> concatenate with ISP prefix, bits from UE unique /64 prefix would 
>>>> be
>>>used.
>>>>

>>>> CPEs,

>>>> >> > supply

>>>> >> > > >Vucetic