Re: Call for v6ops agenda items

[Joel Jaeggli <[e-mail]>]

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