Re: Call for v6ops agenda items

[Mark Smith <[e-mail]>]

Hi Teemu,

On Tue, 16 Feb 2010 08:30:39 +0100
<[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?
> 

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."


> 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:[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
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>