Re: [OPSAWG] Heads up - Plea for allocating a /8 to ISPs
Cameron Byrne <[email protected]>
| Newsgroups | gmane.ietf.v6ops,gmane.ietf.ops |
|---|---|
| Message-ID | <[email protected]> |
On Wed, Nov 10, 2010 at 8:14 PM, Christopher LILJENSTOLPE <[email protected]> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > - -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Erik, > > On 11Nov2010, at 14.13, Erik Kline 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. >> > Interesting hypothesis, but seems to me to be a bit of A=B, C=D A=D? Everyone who is asking for this is running as fast as they can to get v6 deployed. Sometimes reality is messier than a hypothesis > >> 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". > > Glad you used BAU = IPv6 is our BAU engineering and product model. However, some operators have infrastructure that is a bit longer in the tooth than others.... There are rules of physics, economics, and support systems. > Large network operators all around the world have already hit this. They use duplicate addressing, vrf's, NAT444, or other messy things like bogons. This is old news. Folks have been complaining about RFC1918 being too small for a long time. Folks tried to open up class E, no luck. With every day that goes buy, expanding RFC1918 yields less and less utility as more and more network operators work around it. Sorry you are hitting this wall now, but this is really just old news (as you may have heard) Cameron ps. glad you are doing ipv6. >> >> Most animals are motivated to either move toward pleasure or away from >> pain. Align incentives, or readjust expectations, accordingly. > > So, what animal did you have in mind for us, a sloth? > >> >> 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 >>> >> _______________________________________________ >> 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----- > > iQEcBAEBAgAGBQJM225RAAoJEGmx2Mt/+Iw/DpEIAInK9tQsTxLMjOEM68R36pyw > nYlv8n7rbY/Q/TIyDxjzBr0Z3tHYRnzA2ATVVNRIWNm+K31ROsq8LUUY6gQvKrJv > lZRBCnKhKi+2XmcfaWf5kfZVwE9wjtEh6E02FSE/lc7usJ+sl2wsGvglEur/IP3b > 76piaDVm38gDeY59myCpCFdqMFyzeRIBUo1SVHl2kIuUaI7zTQt5ygS+7d6GW5TG > EQodM8BJMttNTCxhDb79YtGer5t6td2+uZ1inqjNumXoqiIK/ghvDwrPwJMTg8U3 > rsChKYXMxDALH1Ar32LeRrZQbqL6t2G+YxD+tf+6abKIOfjast5/V4UetAZ6gPU= > =hEtQ > - -----END PGP SIGNATURE----- > -----BEGIN PGP SIGNATURE----- > > iQEcBAEBAgAGBQJM23BGAAoJEGmx2Mt/+Iw/y98IAJbq3DtZW58CNBuQMtqyVdFr > rWnb3peQnwXe8jedlllZWqeJ3KDF0nx2uBYXVQX7QakxvHO/xlWejN+Le7XYwb4H > k8NlK0XwPMC4sZxQDq8Jh5X63iPMrFEl+GC0h9DNmvQ5jF8IuWnaCgDQE7BSAnSJ > M+gQHWbZzD/yCxl0+MhE3jvCL1xFN4YpzPPGXUFtr9h/eZ/8rANegRgLHXNpA4Ur > icAhza9yA7RCdLnWZHQpktmrGmyIOoHwkOUQo5G/T8ChV6RvwsYDndZzrm3F8Xzf > fa6Sa5CLnCH2UvOEmC+SkgP02pXl00X7J7kUlGoYEp4moEemZJxY889t/6LFQt0= > =Alp6 > -----END PGP SIGNATURE----- > _______________________________________________ > v6ops mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/v6ops > _______________________________________________ v6ops mailing list [email protected] https://www.ietf.org/mailman/listinfo/v6ops