Re: Call for v6ops agenda items

[Cameron Byrne <[e-mail]>]

On Mon, Feb 15, 2010 at 11:30 PM,  <[e-mail]> wrote:
> 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.
>

:)

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

> Best regards,
>
> Teemu
>
>
>>-----Original Message-----
>>From: ext Joel Jaeggli [mailto:[e-mail]]
>>Sent: 16 February, 2010 07:15
>>To: Cameron Byrne
>>Cc: Savolainen Teemu (Nokia-D/Tampere); [e-mail];
>>[e-mail]
>>Subject: Re: Call for v6ops agenda items
>>
>>
>>
>>Cameron Byrne wrote:
>>> On Mon, Feb 15, 2010 at 7:39 PM, Joel Jaeggli <[e-mail]>
>>wrote:
>>>> 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.
>>
>>Not an unreasonable proposition.
>>
>>>  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.
>>
>>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.
>>
>>>> FWIW. I guess it should be stated that I work for nokia again.
>>>
>>> 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.
>>
>>>> joel
>>>>
>>>> [e-mail] 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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>