Subject: Re: [3gv6] Stateless Prefix Delegation I-D updated (draft-savolainen-stateless-pd)

From: <[email-masked]>
Date: Tue, 2 Mar 2010 16:56:04 +0100

Hi Conrad,

> I assume you mean specifically section 5 of this draft - the supposed
> problem with DHCPv6 not allowing to assign prefixes backward. This has
> good reasons: DHCP is a forward assignment - assigning part of the
> delegated prefix back to the originating link usually leads to problems
> with routing.

Rather the delegating router would delegate a prefix minus one /64. I.e. the one /64 would not be really assigned back to the originating link, but rather never assigned to requesting router at the first place...

> The solution is to assign a separate portion of the provider prefix to
> direct link prefixes and delegate something different from this. It
> requires a bit more thinking on the network operators part, but causes
> much less pain for the support hotline... ;-)
> 
> Eg. if the provider uses 2001:db8::/32 and has about 10mio customers
> (24bit customer ID) one solution would be to reserve 2001:db8:0::/40
> for
> link assignment and 2001:db8:100::/40 through 2001:db8:ff00::/40 for
> PD.
> As a customer I could for example get 2001:db8:11:2233::/64 via SLAAC
> for
> the uplink and 2001:db8:1122:3300::/56 via DHCPv6 PD for delegation
> downstream.

Isn't this close to what I describe in stateless draft, i.e. having a /32 bit ISP prefix, and then using 24 lowest bits of the /64 prefix given to UE (with SLAAC) in calculating the delegated /56 prefix? In DHCPv6-"light" this calculation would be done by DR, in Stateless this would be done by RR.

Best regards,

Teemu

---

From: "Konrad Rosenbaum" <[email-masked]>
Date: Tue, 2 Mar 2010 14:20:39 +0100 (CET)

Hi,

On Sat, February 27, 2010 23:29, [email-masked] wrote:
> Have you seen also
> http://tools.ietf.org/html/draft-krishnan-intarea-pd-epc-00 ? With DHCPv6
> PD there's the issue of not being able to use one /64 on the WAN from the
> delegated space. On the other hand, not having a global /64 prefix on the
> WAN at all (unnumbred model) probably would be too big change for the
> 3GPP. Any thoughts about this issue?

Eg. if the provider uses 2001:db8::/32 and has about 10mio customers
(24bit customer ID) one solution would be to reserve 2001:db8:0::/40 for
link assignment and 2001:db8:100::/40 through 2001:db8:ff00::/40 for PD.
As a customer I could for example get 2001:db8:11:2233::/64 via SLAAC for
the uplink and 2001:db8:1122:3300::/56 via DHCPv6 PD for delegation
downstream.

    Konrad

---

From: "Konrad Rosenbaum" <[email-masked]>
Date: Tue, 2 Mar 2010 18:56:19 +0100 (CET)

Hi,

On Tue, March 2, 2010 16:56, [email-masked] wrote:
> Rather the delegating router would delegate a prefix minus one /64. I.e.
> the one /64 would not be really assigned back to the originating link, but
> rather never assigned to requesting router at the first place...

In theory what you propose should work, but...

Let's assume we assign 2001:db8:1:200::/56 to the device.

It would give the uplink 2001:db8:1:200::/64 and say 2001:db8:1:201::/64
to its WLAN port. For the device itself everything is fine - its routing
table contains two orthogonal /64 routes.

However the Access Concentrator has to deal with a paradoxical situation:
several overlapping routes. If we assume the AC has host-ID ::1 and the
CPE device or mobile phone has ::2:

2001:db8:1:200::1/128 loops back to the AC(*)
2001:db8:1:200::/64 has the link as direct target without gateway
2001:db8:1:200::/56 goes to gateway fe80::2 via the same link

(*)some IPv6 stacks may omit this one

It may work or it may not work. The alternative is a lot more entries in
the routing table.

What I described below has the upside that the third route does not
overlap with the others. It has of course the downside that it uses up
slightly more address space.

> Isn't this close to what I describe in stateless draft, i.e. having a /32
> bit ISP prefix, and then using 24 lowest bits of the /64 prefix given to
> UE (with SLAAC) in calculating the delegated /56 prefix? In DHCPv6-"light"
> this calculation would be done by DR, in Stateless this would be done by
> RR.

Correct.

   Konrad

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 2 Mar 2010 19:45:17 +0100 (CET)

On Tue, 2 Mar 2010, Konrad Rosenbaum wrote:

> However the Access Concentrator has to deal with a paradoxical 
> situation: several overlapping routes. If we assume the AC has host-ID 
> ::1 and the CPE device or mobile phone has ::2:

Hm, I don't really endorse this model (I prefer the WAN interface 
unnumbered model), but I don't understand why this overlapping routes 
situation is paradoxical?

Longest prefix routing is the norm on the Internet and should handle this 
just fine?

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: <[email-masked]>
Date: Wed, 3 Mar 2010 22:22:39 +0100

Hi,

> It would give the uplink 2001:db8:1:200::/64 and say

Actually the network (AC) would advertise to the device's uplink that prefix, not the device.

> situation:

Mikael commented the longest matching prefix point, so why it wouldn't work? (From point-to-point link (PPP) point of view, the AC just needs to send all packets matching to /56 to the peer except the address it has possibly configured to its end).
 
> It may work or it may not work. The alternative is a lot more entries
> in the routing table.

Hmm.. but that problem is perhaps a problem only for the AC, right? I mean for all provisioning, policy and charging (PCC) etc entities it is just single /56 that needs to be considered per subscription, not a /56 and a /64?

> slightly more address space.

.. and that PCC needs to consider both /56 and /64 for a single subscription, whileas in the alternative PCC has to consider only single /56.

Best regards,

Teemu

---

From: Antonio Querubin <[email-masked]>
Date: Thu, 4 Mar 2010 00:30:56 -1000 (HST)

On Wed, 3 Mar 2010, [email-masked] wrote:

> Hmm.. but that problem is perhaps a problem only for the AC, right? I 
> mean for all provisioning, policy and charging (PCC) etc entities it is 
> just single /56 that needs to be considered per subscription, not a /56 
> and a /64?
>
> .. and that PCC needs to consider both /56 and /64 for a single 
> subscription, whileas in the alternative PCC has to consider only single 
> /56.

The problem with carving out a /64 out of the assigned /56 to provision 
each end-user is that the end-user must now make an exception for that /64 
as being outside of their network with regard to policy even though it's 
in their assigned address range.  Ie. this can unnecessarilly complicate 
things for the end-user in building ACLs for example.

Personally I'd prefer giving the end-user maximum flexibility in how they 
actually use their assigned /56 (or /48) rather than deny them the 
use of one /64.

Antonio Querubin
808-545-5282 x3003
e-mail/xmpp:  [email-masked]