Re: Last Call: draft-weil-shared-transition-space-request-03.txt(IANA Reserved IPv4 Prefix for Shared Transition Space) toInformational RFC
On Sep 23, 2011, at 20:54, Cameron Byrne cb.li...@gmail.com wrote: So if there is going to be breakage, and folks are willing to fix it over time because the good outweighs the bad (I personally do not believe this), then why not dedicate 240/4 for this purpose? 240/4 would be very useful if designated unicast. We should do that, in my opinion. But it's not immediately deployable. It can't be fixed over time in the sense that a prefix reserved from GUA might be; that is, it can't be deployed today and fixed over time. Rather, 240/4 is only useful after the fix is deployed. For what it's worth, to my knowledge none of the co-authors of draft-weil or draft-bdgks have ever expressed any love for the architectural impact of CGN. We all agree that IPv6 is the best choice from a forward-looking perspective. But we also know that the short-term needs of some service providers are driving them to deploy CGN as NAT444. This reservation may help make it less broken. But one concerned over IPv6 deployment may take solace in the fact that, even in the best case, CGN will be worse than native IPv6 in multiple dimensions. Just because I'm putting on a bandage today, doesn't mean that I consider it a good long-term solution. Cheers, -Benson ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-03.txt(IANA Reserved IPv4 Prefix for Shared Transition Space) toInformational RFC
On Sep 24, 2011 8:36 AM, Benson Schliesser (bschlies) bschl...@cisco.com wrote: On Sep 23, 2011, at 20:54, Cameron Byrne cb.li...@gmail.com wrote: So if there is going to be breakage, and folks are willing to fix it over time because the good outweighs the bad (I personally do not believe this), then why not dedicate 240/4 for this purpose? 240/4 would be very useful if designated unicast. We should do that, in my opinion. But it's not immediately deployable. It can't be fixed over time in the sense that a prefix reserved from GUA might be; that is, it can't be deployed today and fixed over time. Rather, 240/4 is only useful after the fix is deployed. For what it's worth, to my knowledge none of the co-authors of draft-weil or draft-bdgks have ever expressed any love for the architectural impact of CGN. We all agree that IPv6 is the best choice from a forward-looking perspective. But we also know that the short-term needs of some service providers are driving them to deploy CGN as NAT444. This reservation may help make it less broken. But one concerned over IPv6 deployment may take solace in the fact that, even in the best case, CGN will be worse than native IPv6 in multiple dimensions. Just because I'm putting on a bandage today, doesn't mean that I consider it a good long-term solution. Cheers, -Benson Let's avoid having yet another thread where there is no consensus but the parties continue to restate their claims over and over. I don't see anything new in what you wrote. Things happen fast when revenue is on the line. Now, if you are in the business of selling ipv4 address space on the secondary market, as folks have linked to you before on the nanog list, you must like the idea of pushing out ipv6 deployment in favor of the broken nat444 ipv4 ecosystem platitudes about ipv6 aside. Here you claim to be friends with ipv4 black-marketeers http://diswww.mit.edu/charon/nanog/139751 The ietf must stick to the guidance that ipv6 replaces ipv4, not that shady black markets and middle boxes replace ipv4. Now, my motivation -- I have taken the ietf guidance and have laid the ground work for deploying ipv6 to mass consumers in the near term. The ietf has been unequivocal that ipv6 is the path forward for years. As an ipv6 network, I am subject to Metcalfe's law... meaning, if I am the only one doing v6 I am in bad shape, but if everyone else has been listening to the ietf in good faith, then ipv6 will be deployed soon (as ipv4 depletes) and Metcalfe's law is a fortuitous cycle of compound benefits for me, ipv6 networks, and ipv6 users. And, conversely, efforts to prolong ipv4 are a direct inhibitor to my short term and medium term benefits in deploying ipv6. The IETF prolonging IPv4 with this effort is changing the rules of the game and overturning well known and long standing precedent, including not joining 240/4 with public or private pools. Governing bodies should not overturn long standing precedent and change the rules of the game at critical times where change is required. Cb ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-03.txt(IANA Reserved IPv4 Prefix for Shared Transition Space) toInformational RFC
On 9/24/11 11:24 AM, Cameron Byrne cb.li...@gmail.com wrote: Let's avoid having yet another thread where there is no consensus but the parties continue to restate their claims over and over. Fair enough. We're discussing the reservation of a prefix; the context is a foregone conclusion. Now, if you are in the business of selling ipv4 address space on the secondary market, as folks have linked to you before on the nanog list, you must like the idea of pushing out ipv6 deployment in favor of the broken nat444 ipv4 ecosystem platitudes about ipv6 aside. Here you claim to be friends with ipv4 black-marketeers http://diswww.mit.edu/charon/nanog/139751 Yes, I'm friends with many people. Some of them vote for the opposite political party as me, some of them work for my competitors, etc. I may agree with some friends, disagree with others, and even hold competing ideas in my mind at the same time. Yet I remain my own person. -Benson ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-03.txt(IANA Reserved IPv4 Prefix for Shared Transition Space) toInformational RFC
Jari, I found your review comments to be very thoughtful and helpful. I understand the concerns you are raising, and I agree that your proposed way forward is reasonable. I did have one question: So here's what I would like to propose. The document goes forward but we make a much clearer statement with regards to the implications both for applications out there, as well as for subsequent IETF work: - what types of impacts may be felt by the rest of the network (not the ISP that is deploying NAT444) - what kinds of application practices may be affected - what IETF specifications may need revision due to this (e.g., do we need to revise ICE etc) Who was the we you were thinking of, making this statement? (I think I'm asking, would this statement be part of this draft, or something else?) Thanks, Spencer ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-03.txt(IANA Reserved IPv4 Prefix for Shared Transition Space) toInformational RFC
Thanks for that question, it is a good one. I would like these additions to be made to a new version of draft-weil. I'm willing to contribute, if necessary. Jari ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
