On Tue, Nov 23, 2010 at 6:34 PM, George, Wes E [NTK] <wesley.e.geo...@sprint.com> wrote:
> [WES] The concept of IPv6 = forklift upgrade and therefore won't happen is > FUD, pure and simple. Yes, there will be equipment replacements required, and > yes some kit will *never* support IPv6. But ultimately, there is a period in > time after which most equipment purchased will support IPv6. In my own > network, I had to wait 2 years for a lot of our existing EOL hardware to be > replaced for other reasons (because it was out of memory or didn't support > IPv4 features we needed). Organically, as the new hardware was deployed, I > had support for IPv6, and didn't have to spend a bunch of money forklift > upgrading my network to get it. So it's about timing - waiting for the > technology refresh that is going to happen independently of IPv6. (n.b. I do > realize that this is splitting hairs, but it makes a difference because it's > taking advantage of an investment we had to make anyway instead of forcing a > new one for something that doesn't generate much in the way of incremental > revenue) [PF] What you are saying is true, most of the infrastructure is in place and ready for IPv6 - but for enterprises there is a lot of applications that needs to be ported and that is an expensive operation. > As I said in my message to Noel, IPv6 is a foregone conclusion. IPv4 doesn't > scale to all of the things for which we need to have IP addresses today, let > alone in the future, except with NAT. NAT by nature, especially multiple > layers as in NAT444 makes IPv4 a second-class citizen. This is not to say > that IPv4 is going to go away anytime soon, but what you're talking about is > a long-tail problem. Right now, we have to make any IPv6-only things out > there talk to the IPv4-only internet because that's the majority, so we > either do NAT64 or run them dual-stack. In another year or two, enough things > will be dual-stack that IPv6 only connectivity won't be a major issue, > especially within certain communities of interest. And similar to when we > started sticking gateways in front of SNA implementations to make them speak > TCP/IP, we'll stick gateways in front of a rapidly shrinking pile of old kit > with obsolete IPv4-only network stacks so that they can reach the rest of the > IPv6 world. [PF] I agree with you, the legacy IPv4 will not scale - either NAT444. Once an end users gets behind CGN there are several options - it might work depending on which services are used - if it is a nightmare then the end users switches to IPv6, depending which services are available over IPv6 or switches to an ISP that offers better IPv4 connectivity - make use of a IPv4/IPv6 application layer gateway, something similar as a B2BUA in the SIP world About SNA, I still see applications using SNA encapsulated inside TCP/IP, simply because it is too expensive to port the application to the "new world". > [WES] No, we're not going to stop supporting IPv4 before it makes sense to do > so. However, CGN and its variants are stopgap measures until IPv6 support is > there, not a means to indefinitely prolong IPv4. They don't scale, they > don't work with every application, and the less of them that we have to use, > the better. As I've been telling people who cling to legacy IPv4-only > installed base as a reason to focus on CGN or other IPv4 extension methods as > anything but a temporary, necessary evil - how long is it really acceptable > to assume that obsolete equipment should be able to connect to the network as > it evolves? In the US, we have a lot of obsolete mobile phones (including > some non-replaceable embedded OnStar modules in cars) that have no network to > talk to because there is no longer an analog GSM network, we have a bunch of > analog TVs that can't get signal with rabbit ears anymore, etc. I don't > understand why we continually try to shield end users from the unfortunate > concept that their kit does eventually become obsolete and need to be > upgraded to continue providing the same service. Even worse, we try to force > network providers to invest in solutions to perpetuate this, thereby shifting > the cost. [PF] Have a look on the financial situation in the old economies (the U.S. and Europe) > >> thus there will be no killer application for IPv6, > [WES] Disagree. Fully functional end-to-end Internet is IPv6's killer > application. While it's true that your average home broadband user, and even > many enterprises really don't care whether their service is delivered over > IPv4, IPv6, or Avian Carrier, they do want it to work. And based on what I'm > seeing from ISPs who have been testing things like NAT444, the increasingly > subpar service that IPv4 will provide as we run out of addresses will serve > as an incentive to move to IPv6, even if it means that they have to buy a new > widget to do it. > [PF] Yes, but what I had in mind is an extended IPv4 where 32 bits are reserved for the core and 32 bits are reserved for the edges - happens to be the same size as IPv6, i.e. 64 bits (prefix space). The old devices can still use IPv4 for internal communications with legacy applications, once a device needs to communicate outside the edge network it needs to use the 64 bit address space, which is backwards compatible with the legacy IPv4 address space. No NAT, no tunneling nor locator rewriting with the help of an identifier is mandatory though those technologies can be used if desired. Patrick _______________________________________________ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg
