Subject: Re: Call for v6ops agenda items

From: <[email-masked]>
Date: Mon, 15 Feb 2010 16:09:58 +0100

Hi,

Would there be interest to hear about stateless IPv6 prefix delegation proposal - i.e. prefix delegation like in 6RD/6to4, but without encapsulation:

http://tools.ietf.org/html/draft-savolainen-stateless-pd-00

This approach would make it easy to delegate (mainly slightly) shorter than /64 prefixes for a large number of devices connected via point-to-point links (e.g. cellulars). The con is extra consumption on IPv6 address space. I think the approach would be useful if many devices would need few additional /64s, but would not compete with flexibility of RFC3633.

Best regards,

Teemu

---

From: Joel Jaeggli <[email-masked]>
Date: Mon, 15 Feb 2010 19:39:00 -0800

I'd be inclined to hear that.

FWIW. I guess it should be stated that I work for nokia again.

joel

[email-masked] wrote:
> Hi,
>  
> Would there be interest to hear about stateless IPv6 prefix delegation
> proposal - i.e. prefix delegation like in 6RD/6to4, but without
> encapsulation:
>  
> _http://tools.ietf.org/html/draft-savolainen-stateless-pd-00_
>  
> This approach would make it easy to delegate (mainly slightly) shorter
> than /64 prefixes for a large number of devices connected via
> point-to-point links (e.g. cellulars). The con is extra consumption on
> IPv6 address space. I think the approach would be useful if many devices
> would need few additional /64s, but would not compete with flexibility
> of RFC3633.
>  
> Best regards,
>  
> Teemu
>  
>  
>  
>

---

From: Cameron Byrne <[email-masked]>
Date: Mon, 15 Feb 2010 20:30:38 -0800

> I'd be inclined to hear that.

It would be more interesting to hear the plans of an operator than a
vendor.  Their view points are often different.  Unfortunately, that
is not how these things always work.  The draft does an outstanding
job of summarizing how things are supposed to work in the
documentation.  I am disappointed that the draft does not adequately
address the IPv6-only use case, which is how things will likely work
in the real world (see VZW handset spec for LTE where IPv6 connection
is always mandatory, including for SMS, granted IPv4 is optional, but
they have 30x the IPv4 space that T-Mobile USA has  ...).  Relegating
IPv6-only to M2M communications when it will certainly be deployed for
general services (IMS, web, email, ...) with NAT64 as needed. -- but
that is my own operator specific technology drum beating -- full
disclosure.

> FWIW. I guess it should be stated that I work for nokia again.

Thanks for the disclosure.  I was certainly thinking that.

---

From: Joel Jaeggli <[email-masked]>
Date: Mon, 15 Feb 2010 21:14:45 -0800

Cameron Byrne wrote:
> vendor.  Their view points are often different.

Not an unreasonable proposition.

>  Unfortunately, that

PD is basically the one thing that's going to keep my mobile router from
having to NAT (which it does today in ipv4). I don't think the utility
can properly be under-scored even if this proposal happens to be the
wrong one.

> Thanks for the disclosure.  I was certainly thinking that.

Hey, it's only been two weeks, back under this flag, not used to it
again myself.

---

From: <[email-masked]>
Date: Tue, 16 Feb 2010 08:30:39 +0100

Hi Joel, Cameron,

I second operator's presentations on this topic:) But too often I feel that operators are not very interested to ensure hosts have enough addresses available for sharing.. You can hear this thought echoing e.g. on proposals saying hosts should have just /128, and no prefix delegation. How on earth you can share that kind of uplink connection without IPv6 NAT?

Cameron, the intent of the draft is to explain IPv6-only case well. If its not already, I can definitely work on that - and feedback helps. The IPv6-only is actually the scenario I want to go to with this, but I have thought it helps people to get grab of the idea faster when explained via 6RD/6to4.	

When lacking locally unique IPv4 addresses (e.g. IPv6-only case, or GI-DS-Lite in works..), the n locally unique bits required for prefix calculation has to be obtained from some source, and that is not so easily done right (especially as the n is rather small value like 32 or less). In the draft I propose following sources as possibilities:

1) Unique /64 prefix obtained via RA - this could work in point-to-point link models using /64 prefix per link, like in 3GPP or WiMAX. I.e. instead of IPv4 address, bits from IPv6 prefix are used as source of uniqueness. The network could communicate how many bits to take from the prefix. 

2) IPv4 address - feasible when uplink access is dual-stack. This is as nice as 6RD/6to4.

3) Interface Identifier - if host knows which bits from Interface Identifier are unique within a gateway scope, that can be used as well. This binds different layers together in not very nice manner, I think. But the gateway can ensure each host on each point-to-poink link has actually different interface identifier (or different 30 least significant bits). E.g. in PPP and 3GPP the network tells UE the IID.

4) DHCPv6 - if a host has been allocated /128 with DHCPv6, it could be arranged that e.g. the lowest bits are unique. But if you have stateful DHCPv6 in use, why not use DHCPv6 PD..

5) Layer 2 identifier - this can be e.g. GTP TEID that is unique within 3GPP GW, and thus might work out in 3GPP environment, but is not so generally applicable.

I would welcome ideas on what is the best approach (especially if there are other alternatives to choose from), if IPv4 address is not available.

Best regards,

Teemu

>-----Original Message-----
>From: ext Joel Jaeggli [mailto:[email-masked]]
>Sent: 16 February, 2010 07:15
>To: Cameron Byrne
>Cc: Savolainen Teemu (Nokia-D/Tampere); [email-masked];
>[email-masked]
>Subject: Re: Call for v6ops agenda items
>
>
>
>Cameron Byrne wrote:

---

From: Mark Smith <[email-masked]>
Date: Tue, 16 Feb 2010 20:14:16 +1030

Hi Teemu,

> I second operator's presentations on this topic:) But too often I feel that operators are not very interested to ensure hosts have enough addresses available for sharing.. You can hear this thought…

What sort of operators? As you're from Nokia, are you taking about
mobile phone network operators?

As for ISPs, I don't think they all believe that. I think they'd be
quite well aware that their customers are sharing their single IPv4
address with multiple devices via NAT, and won't be living in a
fantasy that they're selling a Internet connection/single IPv4 address
for each device residential customers want to attach. If they've also
deployed VoIP services they may have also had to deal with VoIP/NAT
interaction issues, which hopefully would have taught them the benefits
of unique addressing for all edge devices.

If an ISP tries to only give out a single /128, their competitors can
and probably will use that as a marketing weapon - "Other stingy ISPs
give you a single IP address. We'll give you plenty, because we've got
plenty."

---

From: Cameron Byrne <[email-masked]>
Date: Tue, 16 Feb 2010 05:10:36 -0800

> I would welcome ideas on what is the best approach (especially if there are other alternatives to choose from), if IPv4 address is not available.

:)

I was talking about draft-korhonen-v6ops-3gpp-eps-00  :)   Which i
will state again, it is very well written, clear, accurate, and
concise.

But i think you are talking about  draft-korhonen-v6ops-3gpp-eps-00

That said, i think it is very unfortunate that the 3GPP standards
requires a /64 per PDP or EPS bearer.  It is a huge waste of space and
operators like me won't tolerate or deploy systems like this.  /128 is
obviously not good.  /64 is not good either.  The standards should
allow flexibility for the operator to decide this /126 or /112.....
Given that the standards don't allow this flexibility in 3GPP, it
forces me to make it a non-standards exception in the RFP and product
requirements, which costs both me (the operator) and you (the network
and handset vendor) more money in taking out restrictions that made
sense 7+ years ago.

I have been seeing this a lot lately.  Here is a good example:

http://www.gossamer-threads.com/lists/nsp/ipv6/20788

and

http://www.ietf.org/proceedings/76/slides/6man-2.pdf

Today's network operators have learned some IPv6 lesson along the way
and are rejecting out-dated IETF and soon 3GPP guidance.  In the best
case, nothing is hard coded and network deployments can evolve.  In
the worst case, things like /64 per PDP is hard-coded and things are
not so easy...

Best regards,
Cameron

---

From: Gert Doering <[email-masked]>
Date: Tue, 16 Feb 2010 14:25:42 +0100

Hi,

On Tue, Feb 16, 2010 at 05:10:36AM -0800, Cameron Byrne wrote:
> operators like me won't tolerate or deploy systems like this.  

Why exactly are you worrying?  The smallest address block that you can
get from your RIR is a /32, which gives you 4 billion /64s.

If you have more handsets than that, the RIRs will be happy to give you
a larger chunk of addresses.

Gert Doering
        -- NetMaster
-- 
Total number of prefixes smaller than registry allocations:  144438

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

---

From: <[email-masked]>
Date: Tue, 16 Feb 2010 14:38:00 +0100

Hi Cameron,

>will state again, it is very well written, clear, accurate, and

I have to say I was slightly confused to where you actually replied when I was writing my reply back:) Thanks for feedback on that draft as well.

But this is interesting discussion nevertheless.

>and handset vendor) more money in taking out restrictions that made

I just don't see reason why that restriction would have to be changed in any way. Perhaps things could have been better, but surely changing this concept costs way much more in changes, delays, and in increased complexity than the supposedly wasted IPv6 address space can possibly cost. 

>and are rejecting out-dated IETF and soon 3GPP guidance.  In the best

Hmm.. I don't quite agree on this.

>the worst case, things like /64 per PDP is hard-coded and things are

Its pretty much hard coded alright, and as far as I know there are no serious discussion, or solid arguments, to change it to anything else. The discussion now is about whether UEs should be additionally given shorter than /64 and with which tools.

Best regards,

	Teemu

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 16 Feb 2010 14:39:32 +0100 (CET)

> operators like me won't tolerate or deploy systems like this.  /128 is

Why is this a waste of space? With a /32, you can support 4.29 billion 
/64s. Should be enough for most cellular operators, if they need more, 
they can just ask and they'll be given more IPv6 space.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Cameron Byrne <[email-masked]>
Date: Tue, 16 Feb 2010 05:54:38 -0800

On Tue, Feb 16, 2010 at 5:39 AM, Mikael Abrahamsson <[email-masked]> wrote:
> Why is this a waste of space? With a /32, you can support 4.29 billion /64s.
> Should be enough for most cellular operators, if they need more, they can
> just ask and they'll be given more IPv6 space.
>

Right. I have heard this time and again from the IPv6 zealots.  But,
for me it does not make sense to needlessly waste space.  And, if you
looked at the links i sent, perhaps you would see that there are
indeed issues with these long prefixes that network operators really
have today such as the ping-pong issue.

But, as an ISP / mobile provider i should only need a single /32
right?  That is how the routing system is setup.  But here is some
simple math on how my /32 is not enough if i give /64 per mobile
subscriber

2^24 = 16,777,216 = /64 per GGSN or PGW  ( I anticipate GGSN / PGW of
the future to support 10 Million PDP attached subscriber)

2^6 = 64 geographic PGW locations  (I have nearly 30 locations today,
in the future 64 is reasonable)

If you have think the user numbers are high, perhaps you have not seen
any forecasts on how machine to machine communication will grow on
cellular networks.

So, that is how I used 30 bits on the initial deployment.  Yes, I can
ask for more space.... but why should I?  And, what if everyone asks
for more space?  And everyone gets non-contiguous blocks?  And what if
500k IPv4 routes don't go away in 10 years?

Instead of answering these questions, tell me what is so wrong with
giving a mobile user (cell phone! security camera, electricity meter
...) a /112 or something similar?  Why is it so important that the
3GPP specs REQUIRE a /64, and consequently the vendors don't support
anything else?  Really, GGSN vendors only support /64 ....

Cameron

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 16 Feb 2010 15:00:38 +0100 (CET)

On Tue, 16 Feb 2010, Cameron Byrne wrote:

> ...) a /112 or something similar?  Why is it so important that the 3GPP 
> specs REQUIRE a /64, and consequently the vendors don't support anything 
> else?  Really, GGSN vendors only support /64 ....

I also work for a cellular provider/ISP, but I guess I can combine that 
with being an "ipv6 zealot".

Yes, I do agree that requiring a /64 per bearer/PDP is suboptimal, there 
should be a choice. I still don't think it's a waste of space, but I can 
agree that allowing for a few different subnet sizes would make sense.

---

From: Cameron Byrne <[email-masked]>
Date: Tue, 16 Feb 2010 06:06:29 -0800

On Tue, Feb 16, 2010 at 6:00 AM, Mikael Abrahamsson <[email-masked]> wrote:
>> Instead of answering these questions, tell me what is so wrong with giving
>> a mobile user (cell phone! security camera, electricity meter ...) a /112 or
>> something similar?  Why is it so important that the 3GPP specs REQUIRE a
>> /64, and consequently the vendors don't support anything else?  Really, GGSN
>> vendors only support /64 ....
>
> I also work for a cellular provider/ISP, but I guess I can combine that with
> being an "ipv6 zealot".

:)

> agree that allowing for a few different subnet sizes would make sense.

Teemu,

That means there are 2 of us now.  Does that make it relevant
conversation?  Keep in mind, if it is hard coded in ipv6 in 2010 make
a big difference from being hard coded in 2012.  Lets fix it now in
the standards, otherwise an enterprising GGSN manufacturer will add it
as a knob and customers will buy it and use it.

Cameron

---

From: Simon Perreault <[email-masked]>
Date: Tue, 16 Feb 2010 09:08:06 -0500

On 2010-02-16 08:54, Cameron Byrne wrote:
> anything else?

Advantages of /64:

- Stateless autoconfig
- Privacy addresses [RFC4941]
- ...others? (help me here)

/64 is not just /63+1.

Simon
-- 
NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca
STUN/TURN server        --> http://numb.viagenie.ca
vCard 4.0               --> http://www.vcarddav.org

---

From: <[email-masked]>
Date: Tue, 16 Feb 2010 15:15:26 +0100

>From: ext Cameron Byrne [mailto:[email-masked]]
>Sent: 16 February, 2010 15:55
>To: Mikael Abrahamsson
>Cc: Savolainen Teemu (Nokia-D/Tampere); [email-masked];
>[email-masked]; [email-masked]; [email-masked]

Well, timing at least. We should now deploy v6, not discuss on link models. Remember RFC4682 SLAAC that says:
--
5.5.3.  Router Advertisement Processing

   For each Prefix-Information option in the Router Advertisement:

....

      If the sum of the prefix length and interface identifier length
      does not equal 128 bits, the Prefix Information option MUST be
      ignored.  An implementation MAY wish to log a system management
      error in this case.  The length of the interface identifier is
      defined in a separate link-type specific document, which should
      also be consistent with the address architecture [RFC4291] (see
      Section 2).
--

So in addition to dynamic prefix length, you'd need to have some sort of dynamic interface identifier length? More specification work...

One additional reason is unification with Ethernet and other link types. You can have simple IPv6 stack implementation that assumes 64 bit IID and /64 prefix, and therefore can work easily with different kinds of links. I.e. you can separate modem and IP stack implementations more easily.

With /64 prefix you can bridge (or rather ND Proxy) the cellular interface to (W)LAN. If you'd have /112, how to bridge/proxy? 

Best regards,

Teemu

---

From: Mark Smith <[email-masked]>
Date: Wed, 17 Feb 2010 06:59:23 +1030

On Tue, 16 Feb 2010 06:06:29 -0800

> > I also work for a cellular provider/ISP, but I guess I can combine that with

I don't think you should be smiling. Calling people names who disagree
with your opinion will make them less likely to be interesting
in listening to it.

---

From: "Laganier, Julien" <[email-masked]>
Date: Tue, 16 Feb 2010 13:11:35 -0800

Simon Perreault
> > 3GPP specs REQUIRE a /64, and consequently the vendors don't support

Right.

> - Privacy addresses [RFC4941]

Hmm... 

When the link is point-to-point (such as in cellular systems), every host has to be assigned with a unique prefix. Doing so makes the use of randomized interface identifiers [RFC4941] ineffective from a privacy protection point of view because the host can still be uniquely identified by its prefix. 

--julien

---

From: james woodyatt <[email-masked]>
Date: Tue, 16 Feb 2010 13:11:20 -0800

> - ...others? (help me here)

On top of that, if you're just trying to put global addresses on your interior router interfaces without restricting the size of the prefixes you delegate to subscribers, then you should be able to use ULA instead of PI or PA addresses, then aggregate all the PPP links as if they are a single NBMA prefix.

What's the problem?

--
james woodyatt <[email-masked]>
member of technical staff, communications engineering

---

From: Simon Perreault <[email-masked]>
Date: Tue, 16 Feb 2010 16:28:21 -0500

> When the link is point-to-point (such as in cellular systems), every host has to be assigned with a unique prefix. Doing so makes the use of randomized interface identifiers [RFC4941] ineffective f…

Of course. This is true for any network. 3GPP is not special in this 
respect. Quoting from RFC4941:

                                               Although it might appear
    that changing an address regularly in such environments would be
    desirable to lessen privacy concerns, it should be noted that the
    network prefix portion of an address also serves as a constant
    identifier.  All nodes at, say, a home, would have the same network
    prefix, which identifies the topological location of those nodes.
    This has implications for privacy, though not at the same granularity
    as the concern that this document addresses.  Specifically, all nodes
    within a home could be grouped together for the purposes of
    collecting information.  If the network contains a very small number
    of nodes, say, just one, changing just the interface identifier will
    not enhance privacy at all, since the prefix serves as a constant
    identifier.

But others have already mentioned that we cannot assume that there is 
always only one host per 3GPP link.

Simon

---

From: Suresh Krishnan <[email-masked]>
Date: Tue, 16 Feb 2010 16:22:37 -0500

> - ...others? (help me here)

CGAs : for address ownership proof
HBAs : for multihoming

Cheers
Suresh

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 17 Feb 2010 09:32:43 +0100 (CET)

> conversation?  Keep in mind, if it is hard coded in ipv6 in 2010 make

I have changed my mind.

Looking at the scalability figures for current LTE architecture, your 
whole network will melt down before you even get CLOSE to 4 billion 
bearers, and even if you scale it past that, you just get a /30 instead of 
/32 and you can now have 16 billion simultaneous bearers.

Let's stick with /64 for simplicity and for all the other reasons stated 
before. Let's focus on getting DHCPv6-PD etc working over this /64 
instead, much rather put effort into that than trying to get smaller 
netblocks into the standard. It also simplifies filtering etc, the 
standard model today indicates that enduser /64 is a subnet with one or 
more devices within the same administrative entity, let's stick to that.

---

From: "Konrad Rosenbaum" <[email-masked]>
Date: Wed, 17 Feb 2010 13:16:55 +0100 (CET)

Hi,

On Mon, February 15, 2010 16:09, [email-masked] wrote:
> would need few additional /64s, but would not compete with flexibility of
> RFC3633.

I see this from a SOHO perspective (ie. the one who uses the UMTS modem or
DSL router).

As a fan of self-organizing systems, self-organizing routing
infrastructure is akin to the holy grail for me, but unfortunately I don't
think this swallow can fly with a coconut in its beak. (SCNR)

I have a few points of contention:

* there already is a well working protocol for PD: DHCPv6; although I like
the idea of finally getting rid of it

* the unique-bits part is too large to work on more than one level, so it
would be reserved to the ISP-to-User-line, but then again SLAAC is also
reserved to the link level of routing

* semantically it's not the right protocol for this: SLAAC is transmitted
on the same link it configures, PD is transmitted on the upstream link of
those (different links) that are configured

* as a router admin I would never accept PD statelessly - i.e. without
having asked for it; this might be just too much paranoia on my part
though

* stateless also means that the router has to reserve enough space for
EVERY client, because it cannot know whether the client wants to use it;
with a stateful protocol it only needs to reserve space and route the
prefix once the client asks for it

* for most OSes it has to be implemented in a user-space program anyway,
since the kernel cannot know which interfaces to configure, but in
userspace it does not matter whether I implement DHCP rapid commit or
"stateless" PD with a request message - the complexity is the same

I also have a problem with some of the uniqueness-source bits:

P: should be restricted to prefixes announced in the same SLAAC message

I/2: should be unified into just I, since it is guaranteed to exist and is
dependent on layer 2 IDs anyway

4: I have a really big problem with this: it mixes protocols and requires
a lot of dual-stack logic to exist on the host - you can make it a MAY,
but then DHCPv6-PD has to exist as well as a backup

D: it shouldn't mention DHCP directly, but instead use the word "stateful"
as other RFCs do, but then again - how to know which IP is meant? The
interface can have multiple IPs all configured through different stateful
protocols and an independent process will not know through which protocol
they came. BTW: why would one use stateless PD if there is stateful
address assignment anyway?

If multiple bits are set - is that legal? What should the host do?

I also think the ping test should be a MUST, not a MAY.

   regards,
   Konrad

---

From: Cameron Byrne <[email-masked]>
Date: Wed, 17 Feb 2010 09:34:09 -0800

On Wed, Feb 17, 2010 at 12:32 AM, Mikael Abrahamsson <[email-masked]> wrote:
> Looking at the scalability figures for current LTE architecture, your whole
> network will melt down before you even get CLOSE to 4 billion bearers, and
> even if you scale it past that, you just get a /30 instead of /32 and you
> can now have 16 billion simultaneous bearers.
>

Can you help me understand the scalability limits you are referencing?
 My expectation is that we deploy EPC PGW for LTE devices to start,
but eventually all 2G and 3G will be anchored on the regional PGW to
support iRAT handover.  Thus, the PGWs that we deploy in LTE will
terminate all data sessions from 2G/3G/4G ... LTE/EPC of today is
barely what UMTS release 99 was in terms of maturity... so there is
plenty of room for evolving to meet scalability challenges.

Granted, i am not explicitly anticipating growth like that in the near
future, but lessons from the past tell us exponential growth is a
reality, and we will have to evolve the technology to fit.   The
numbers i gave are a first swag at doing something that is both
practical and "future proof".   Honestly, that will likely be the
address structure i use in my network, 4 billion bearers or not.   I
am also very interested in the idea of cell site local PGW functions,
such that each cell site can do local handoff of IPv6 internet traffic
instead of backhauling to my mobile network aggregation site.  That is
a separate discussion and perhaps a special case, but if each cell
site has a PGW function and is handing out its own set of /64s, it
exacerbates the problem further... yes, there are lots of IPv6
addresses to be had.  And, no i don't think privacy addresses and
SLAAC and the other goodies that come with /64 are very valuable.
That's a value decision, to each thier own ... unless 3GPP says you
have to do /64 and vendors hard-coded it, which they did.

As one of the other folks pointed out, now is the time to deploy ...
but i tend to think folks have been saying that for 10 years now. At
least, i have heard it for 10 years now, and have told people it for
10 years now (this coin has 2 sides).  I loath to have to repeat the
lessons of classful IPv4 addressing, and as I have pointed out with
references early in this thread, /64 is being reject for point to
point links by many major ISP backbone and content network operators.
But, the 3GPP used a MUST for /64 when I believe they should have used
a SHOULD.  Que sera, sera.

Since it seems to need to be explicitly stated:  Thanks for your
opinion, i respect your comments, and please share the LTE bearer
scaling concerns.

Warmest Regards,

Cameron

> before. Let's focus on getting DHCPv6-PD etc working over this /64 instead,
> much rather put effort into that than trying to get smaller netblocks into
> the standard. It also simplifies filtering etc, the standard model today
> indicates that enduser /64 is a subnet with one or more devices within the
> same administrative entity, let's stick to that.
>
> --

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 17 Feb 2010 22:43:37 +0100 (CET)

> Can you help me understand the scalability limits you are referencing?

The MME offerings I've seen today seem to be in the 10M simultaneous 
bearer range. That means you'd need 400 MMEs to reach 4 billion bearers to 
reach the /32 allocation exhaustion.

I'd imagine the S/PGW are in the same scalability range, so I'd say that 
before you run into the /32 problem with IPv6, you'd hit a lot of other 
problems long before that.

Basically, the current LTE framework with GTPv2 tunnels for everything 
will run into scalability problems long before the current /64 per bearer 
framework will.

---

From: Cameron Byrne <[email-masked]>
Date: Wed, 17 Feb 2010 15:18:05 -0800

On Wed, Feb 17, 2010 at 1:43 PM, Mikael Abrahamsson <[email-masked]> wrote:
> The MME offerings I've seen today seem to be in the 10M simultaneous bearer
> range. That means you'd need 400 MMEs to reach 4 billion bearers to reach
> the /32 allocation exhaustion.

MME are generally deployed on ATCA blades, so they are within scope of
Moore's Law on CPU.  MME interaction seem to really scale with
transactions for registration, paging, and handover ... So the call
model is relevant, and M2M as a major growth area is low MME
signaling.   I am not sure MME will be a major road block to realistic
scaling (4 billion not being realistic today).  If I have nearly 100
aggregation locations today, and I have a pool of 2+ MME in each
aggregation location to keep latency low and availability high,
200-300 MME  does not seam unreasonable.  Keep in mind i am talking
10+ years of planning, growth, ... So, not today.... I am just
theorizing about the limits of the system.  I don't disagree with you.

> problems long before that.

That's why i am thinking S/PGW will be distributed to the cell site
location in the long term.  There is little value or sense in taking
LTE or LTE++  type traffic for a city the size of New York into one
location like we do today with 3G.  As a wireless only operator (not
the incumbent wireline carrier), it behooves us to exit Internet bound
traffic quickly.  That means at the cell site or some intermediate
aggregation location of   < 10 cell sites.

>
> Basically, the current LTE framework with GTPv2 tunnels for everything will
> run into scalability problems long before the current /64 per bearer
> framework will.

Agreed.  We cannot tunnel all traffic forever.  There  will have to be
mobility trade-offs made to scale the system.  EPC is not really that
different from the legacy packet core in that way.

---

From: <[email-masked]>
Date: Thu, 25 Feb 2010 13:55:39 +0100

Hi,

Thank you very much for comments. I'm preparing an update. Comments inline:

> * there already is a well working protocol for PD: DHCPv6; although I
> like the idea of finally getting rid of it

Right. IMHO as is proven by 6RD, there's interest to have prefix delegation also without DHCPv6 if easily doable.

> reserved to the link level of routing

I don't agree, the draft intents to say unique-bits can be of about any length. For example:
- if length of unique bits is 1, there can be two routers below the gateway, which both would get delegated prefix of: [SPD-prefix][0/1][subnet ID]. Now if the SPD prefix is say 40 bits, and V6UNIQUE is 1 bit, the router would get /41, right? Then this router could further choose to delegate say /56 by configuring downlink routers by provisioning them with: [SPD-prefix+1][V6UNIQUE of 14 bits of length][subnet ID]. Right?

In fact, this unique bits could be minimum of 1 bit and maximum is many bits (I have to think about that), right?

> those (different links) that are configured

With SLAAC you refer to the case where bits are taken from the /64 prefix configured with SLAAC? Right, but what is the significant difference to 6RD that uses uplinks IPv4 address?

> having asked for it; this might be just too much paranoia on my part

I'm not sure I see the difference, in both cases network has to be trusted... Also, you can trust to the context: e.g. having a dedicated 3GPP APN for this purpose. 

> prefix once the client asks for it

Right, but this depends on the context as well. If you limit stateless delegation only to parts of the network where you know all nodes *are* routers, then the waste is mitigated. Only if the routers' needs vary a lot (some require /48 while most would settle for /60), but all are allocate /48, there would be waste. In 3GPP e.g. this could be mitigated with an APN dedicated for router use - all UEs using this APN would be once (potentially) needing prefixes. 

This is the essential tradeoff in the stateless approach - there's no free lunch.. But which one is more expensive, IPv6 address space, or fully dynamic system?

> "stateless" PD with a request message - the complexity is the same

True. On the requesting router side the savings are indeed less - the main benefits would be on the network side.

> P: should be restricted to prefixes announced in the same SLAAC message

Same as what? The service provider prefix would not be delivered in SLAAC. Anyhow, there's issue if there are multiple /64s in RA (while in 3GPP there currently are always one). Updating draft..

> dependent on layer 2 IDs anyway

Done, but added "T": tunnel identifier. What I'm thinking here is that e.g. the GTP TEID of 3GPP access could be unique part. Each bearer has this locally unique 32bit identifier. I think this requires further clarification.

> but then DHCPv6-PD has to exist as well as a backup

What do you think about 6RD?

> address assignment anyway?

Right.. This was here for sake of "completeness".. but I'll throw it away.

> If multiple bits are set - is that legal? What should the host do?

Updated to say it is not legal.

> I also think the ping test should be a MUST, not a MAY.

Updated.

Thank you,

Teemu