Re: [v6ops] [OPSAWG] Heads up - Plea for allocating a /8 to ISPs

Greetings Mark,

On 11Nov2010, at 21.50, Mark Smith wrote:

> On Thu, 11 Nov 2010 15:18:55 +1100
> Christopher LILJENSTOLPE <[email protected]> wrote:
> 
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>> 
>> A nit here, but the ask is for a /10.
>> 
> 
> Being from the same market as you, is the fundamental motive because
> customers own CPE, and therefore you (we) can't "force" them to upgrade
> it to support IPv6?
> 
> It seems to me we have a three option solution to the "customer owns the
> CPE problem" - carrot, stick, or subversive.
> 
> "Carrot" being, we / the Internet provides some sort of "killer app"
> for IPv6, and therefore people ask for it/install it.
> 
> "Stick" being, at some point in time, the costs of dealing with things
> like CGN, to the customer, become higher than the cost of migrating to
> IPv6. Something like a helpdesk call that is answered with "If you
> upgrade to IPv6, the problem will go away" or something similar.
> 
> "Subversive" being, we manage to get them to upgrade to IPv6 without
> realising it (shiny new CPE which they're happy with because it's
> newer / they've satisfied their "new stuff addiction" problem that most
> of us seem to suffer from ;-) ) (which is pretty much the carrot option,
> except that the carrot option is the one where they know what they
> want, and therefore specifically ask for IPv6 (possibly without
> actually understanding what it is they're asking for)).
> 
> While I do think the NAT444 option has value, I also do think it is
> also fundamentally delaying the inevitable "Stick" option. In my
> experience, the sooner you suffer the pain, the less you suffer over
> all. ISPs with customer owned CPE are probably going to wear pain
> regardless, it's all about the degree ...

Even if we started deploying the stick earlier this year, there are too many targets to get the fleet changed before we're out.  It's just too big a problem space.  We will do carrot/stick/subversion, but it will take time.

	Chris

> 
>> 
>> On 11Nov2010, at 14.22, Soininen, Jonne (NSN-FI/Espoo) wrote:
>> 
>>> Hi,
>>> 
>>> I'd like to add a different perspective. We basically have seven /8s left
>>> (plus the five that will be given directly to the RIRs when we come down to
>>> that number). I think the world expects everybody to be as responsible as
>>> possible with those last available /8s.
>>> 
>>> Taking a /8 to RFC1918bis space means that it is away from global address
>>> space use. If we want to do that we have to be really, really sure this is
>>> the right thing to do. IETF would really have to have strong consensus on
>>> it.
>>> 
>>> I seriously doubt we can converge to any consensus before the IANA pool is
>>> empty. 
>>> 
>>> Just a thought.
>>> 
>>> Cheers,
>>> 
>>> Jonne.
>>> 
>>> 
>>> On 11/11/10 5:13 AM, "ext Erik Kline" <[email protected]> wrote:
>>> 
>>>> Hypothesis: Anything meant to extend the usefulness of IPv4 that does
>>> not
>>>> /simultaneously put immense pressure on the thousands of big and
>>> small things
>>>> that block IPv6 deployment/ will not result in IPv6
>>> readiness nor IPv6
>>>> deployment.
>>> 
>>> It may extend the life of IPv4, giving more time for the
>>>> blocking
>>> elements to become more IPv6-ready, but how will this time
>>>> be
>>> different from the status quo for the last 10+ years?  The only thing
>>> that
>>>> could possibly be different is that the free blocks will actually
>>> be gone by
>>>> the end of 2011.  But if that doesn't work, it's impossible
>>> for me to see how
>>>> these sorts of proposals won't result in anything
>>> other than "business as
>>>> usual".
>>> 
>>> Most animals are motivated to either move toward pleasure or away
>>>> from
>>> pain.  Align incentives, or readjust expectations, accordingly.
>>> 
>>> On 11
>>>> November 2010 11:43, Brian E Carpenter
>>> <[email protected]> wrote:
>>>>> 
>>>> I know that some believe that purposely breaking the IPv4 service could be a
>>>> way to promote IPv6.
>>>> 
>>>> I don't believe that, and I don't doubt the good
>>>> intentions of the
>>>> people proposing this - I've seen too much of them in v6
>>>> working groups
>>>> for that. The problem is elsewhere: this would be a very
>>>> strong message
>>>> to ISPs that are *not* actively planning v6 support that here
>>>> is a way
>>>> to evade the issue for many more years. So we end up with a
>>>> bigger
>>>> legacy of customers stuck behind NAT444 and ISPs that have no
>>>> intention
>>>> to move forward.
>>>> 
>>>> I would like to be proved wrong.
>>>> 
>>>> 
>>>> Regards
>>>> Brian
>>>> 
>>>> On 2010-11-11 15:30, Rémi Després wrote:
>>>>> Hi,
>>>> Ron,
>>>>> 
>>>>> 
>>>>> Le 9 nov. 2010 à 13:26, Ronald Bonica a écrit :
>>>>>> I am having
>>>> a strange sense of déjà vu. About two years ago, we saw another proposal to
>>>> allocate a /8 for private use to support another transition mechanism. We
>>>> concluded:
>>>>>> 
>>>>>> - that we didn't have a /8 to spare
>>>>> 
>>>>> - Allocating a /8
>>>> to ISPs, while it is still feasible, would only slightly modify the date at
>>>> which IPv4 prefixes er exhausted, not a big deal.
>>>>> 
>>>>>> - that a /8 wouldn't
>>>> be enough, anyway
>>>>> 
>>>>> - ISPs already operate several parallel instances of
>>>> 10/8 clouds, so that, although a /7 would be more generous than better a /8, a
>>>> new /8 is enough to replace current 10/8's by a prefix private sites don't
>>>> uses internally.
>>>>> 
>>>>> The known reason why ISPs have problems if they assign
>>>> 10/8's is that some NAT44s:
>>>>> . assign 10/8's for internal use
>>>>> . cannot
>>>> work with identical internal and external address spaces
>>>>> 
>>>>> CONCLUSION:
>>>>> 
>>>> Assigning a new /8 to ISPs so that they can replace 10/8:
>>>>> - is easy to
>>>> do
>>>>> - has negligible effect on the transition schedule
>>>>> - does solve a
>>>> real problem
>>>>> It should, in view of this analysis above, be highly
>>>> recommended by IETF
>>>>> 
>>>>> I know that some believe that purposely breaking the
>>>> IPv4 service could be a way to promote IPv6.
>>>>> IMHO, their time would be
>>>> better spent working to eliminate IPv6 limitations than militating against
>>>> IPv4 deserved QoS.
>>>>> 
>>>>> Kind regards,
>>>>> RD
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>>> So, the
>>>> proposal was abandoned. I wonder if we are not in the exact same place
>>>> today.
>>>>>> 
>>>>>> Maybe the equation would be changed if we could make do with a
>>>> /16, but it appears that a /16 wouldn't help.
>>>>>> 
>>>>>> 
>>>>                 Ron
>>>>>>                                         <speaking
>>>> as individual contributor>
>>>>>> 
>>>>>> BTW, the LISP WG is talking about asking
>>>> for a prefix for a very similar reason.
>>>>>> 
>>>>>> 
>>>>>>> -----Original
>>>> Message-----
>>>>>>> From: [email protected] [mailto:[email protected]]
>>>> On Behalf
>>>>>>> Of james woodyatt
>>>>>>> Sent: Monday, November 08, 2010 11:50
>>>> PM
>>>>>>> To: IPv6 Operations; [email protected]; [email protected]
>>>>>>> Subject:
>>>> Re: [v6ops] Heads up
>>>>>>> 
>>>>>>> On Nov 8, 2010, at 20:24 , Erik Kline
>>>> wrote:
>>>>>>>> Didn't Akira Nakagawa/KDDI present something like this a few
>>>> meetings
>>>>>>> ago?  I can't recall clearly...
>>>>>>> 
>>>>>>> It was in Chicago, if
>>>> I recall correctly.  At which point Tony Hain
>>>>>>> joked that we should direct
>>>> IANA to just turn over the entire remaining
>>>>>>> free pool for that
>>>> use.
>>>>>>> 
>>>>>>> Personally, I'd prefer to take Tony's suggestion as a serious
>>>> proposal.
>>>>>>> A single /8 isn't enough, is it?  For NAT444 to be a really
>>>> workable
>>>>>>> architecture, we've got to give over enough addresses that
>>>> service
>>>>>>> providers can handle at least a hundred million subscriber
>>>> addresses in
>>>>>>> the same address realm, right?
>>>>>>> 
>>>>>>> 
>>>>>>> --
>>>>>>> james
>>>> woodyatt <[email protected]>
>>>>>>> member of technical staff, communications
>>>> engineering
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>> _______________________________________________
>>>>>>> v6ops mailing list
>>>>>>> 
>>>> [email protected]
>>>>>>> https://www.ietf.org/mailman/listinfo/v6ops
>>>>>> 
>>>> _______________________________________________
>>>>>> v6ops mailing list
>>>>>> 
>>>> [email protected]
>>>>>> https://www.ietf.org/mailman/listinfo/v6ops
>>>>> 
>>>>> 
>>>>> 
>>>> _______________________________________________
>>>>> v6ops mailing list
>>>>> 
>>>> [email protected]
>>>>> https://www.ietf.org/mailman/listinfo/v6ops
>>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> v6ops mailing list
>>>> 
>>>> [email protected]
>>>> 
>>>> https://www.ietf.org/mailman/listinfo/v6ops
>>>> 
>>> ________________________________
>>>> _______________
>>> v6ops mailing
>>>> list
>>> [email protected]
>>> https://www.ietf.org/mailman/listinfo/v6ops
>>> 
>>> 
>>> -- 
>>> Jonne Soininen
>>> Nokia Siemens Networks
>>> 
>>> Tel: +358 40 527 46 34
>>> E-mail: [email protected]
>>> 
>>> 
>>> _______________________________________________
>>> OPSAWG mailing list
>>> [email protected]
>>> https://www.ietf.org/mailman/listinfo/opsawg
>>> 
>> 
>> - ---
>> 李柯睿
>> Check my PGP key here:
>> https://www.asgaard.org/~cdl/cdl.asc
>> 
>> -----BEGIN PGP SIGNATURE-----
>> 
>> iQEcBAEBAgAGBQJM23AEAAoJEGmx2Mt/+Iw/KiEH/36K/YzJSdrWCPqMwmR1PACx
>> QP1vqpW1fIADwQ+WHrC9ua1X6RAf9LI6+cjrVcYnfZsZXw/zJibWC6TgNZt0exA3
>> iHxhXqEzjy6rd/y6ATkLDDbu75YXU8SfHm08SozFaEw6aIw3tmHTymxnRQiN3x/7
>> v6FKwst5Mc7/S+mwCIcQLwBgtw/+ZntrhUaZOMsCmyyv6UdziFiub7YBdplODzNK
>> EDdUCXaLOwqY2RAAw0DvHtTY/f9s9UeX1GBhBb8THBQmH7hKJIZ8IK99aAV10tHU
>> axD270Yr2YPIPnfMbqM88zhEs/DT77WGZGmo7zQ/6A9150S83M27i251hLeNyZs=
>> =6t41
>> -----END PGP SIGNATURE-----
>> _______________________________________________
>> v6ops mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/v6ops
> 

---
李柯睿
Check my PGP key here:
https://www.asgaard.org/~cdl/cdl.asc

_______________________________________________
OPS-AREA mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ops-area