Hi David, You wrote:
> [This is going a bit far afield from routing research topics, so it'll > be my last message on this thread] OK, I will try to wind up too - though I think it is pertinent, given that the question of IPv6 adoption is absolutely central to any discussion about the future of the Internet, and due to my understanding of the rough RRG consensus involving the assumption that IPv6 adoption will occur soon enough and thoroughly enough to make the IPv4 scaling problem not worthy of our primary focus. >>> Since IPv6 currently uses the same routing technology as IPv4, the >>> _Internet_ has a routing scalability problem. >> >> These are two separate Internets. > > Yes they are two separate Internets, but they are sharing the same > underlying resources (routers, bandwidth, engineers, etc). I agree. >> I think the benefit of fixing IPv4 routing is primarily that a >> billion or more people can continue for the foreseeable future using >> the Internet the way they do today. > ... >> There is no prospect of moving everyone to IPv6 as far as I can see >> - it is too disruptive. > > Again, I'd argue a billion or more people simply don't care if they're > using IPv4 or IPv6. What they care about is getting to the services and > content they want/need. Yes, and IPv6 alone does not do this for them. There is no prospect in the foreseeable future for every significant application to be rewritten or all the world's websites, game servers etc. made to operate over IPv6 too. That leaves everyone dependent on IPv4. "Dual Stack Lite" seems to be the most developed Western plan to give people IPv6 and reduce their demands on the IPv4 address space. However it is at the early planning stages and if and when it is developed and deployed it will not suit some significant subset of users and so will be hard to market. "Dual Stack Lite" doesn't really do much to encourage IPv6 applications, services etc. but at least it would boost the currently small number of people who have native IPv6 connectivity. > As I mentioned in my previous note, I suspect > the best case scenario we're looking at right now is for ISPs migrate > their own infrastructure over to IPv6 (tunneling IPv4 from customer to > edge through that IPv6 infrastructure), thereby allowing them to reuse > any IPv4 addresses they've used for internal infrastructure for customer > assignments. Yes - it would be interesting to know how flexibly and efficiently large and small ISPs assign their IPv4 addresses to active customers, such as home, SOHO etc. mass-market end-users. > This has the side benefit of allowing the ISP to provide > IPv6 connectivity to their customers at no (significant) additional > cost. The economic incentives for an ISP to migrate their > infrastructure to IPv6 would come from avoiding the cost of obtaining > more IPv4 address space. However, I can't see it would be a cost-saving approach. The ISP would need to spend a lot of money buying, installing, managing, maintaining and powering the shelves full of COTS boxes or racks of blade servers or whatever which implement the special "carrier grade NAT" IPv6-aware NAT arrangements by which multiple customers share a single IPv4 address. > "Dual stack lite" is a variation of this, > adding in the ability to do "carrier grade NAT" within the ISP > infrastructure. While some percentage of the existing customer base > won't like the implications of carrier-managed NAT, there will likely be > (extra cost) options that will keep those customers mollified. I agree. > Of course, one of the problems with this scenario is that the IPv6 being > deployed is straight "Deering IPv6", which means there will be more > "vast installed base" that will need to be dealt with if/when a scalable > IPv6 architecture is developed. Oh well. Yes, but it is not a big fuss to change every customer's /64 address just once sometime in the future - if that is necessary to make these IPv6 prefixes part of the new scalable routing and addressing system. I don't assume that this would be necessary. The IPv6 prefixes Comcast already have are presumably large slabs of space, and it will be fine to keep them and continue to give each HFC cable modem customer a /64 of it or whatever, on a PA basis. My view of portable, multihomable, end-user space in a future scalable routing and addressing system is that it doesn't come from your ISP. You get it by renting space from some stable outfit which probably has nothing to do with your current ISP. Then, you can use that space through one or many ISPs, as you choose, anywhere in the world, indefinitely. So Comcast could keep its current prefixes for its cable modem customers, and if any of them wanted to multihome, they would tunnel from their current prefix to the nearest ETR, or Comcast could organise some special routing link from that ETR, and allow the customer to emit packets with source addresses matching their own micronet / EID prefix. I think a more likely scenario would be that the customer runs a bi-directional tunnel from their cable modem /64 address to an ETR somewhere - but this is not just an ETR, it is also a router which can forward packets from the micronet address space to the rest of the Net. This now looks almost identical to the TTR (Translating Tunnel Router) model, but without the frequent mobility. http://www.firstpr.com.au/ip/ivip/#mobile For instance I have a single fixed IPv4 DSL address, but it wouldn't matter if it was dynamically assigned. I could get a dynamically assigned cable modem service, IPv4 at present. Both services could have static or dynamically assigned IPv6 addresses in the future, and perhaps no IPv4 addresses. I would rent micronet space (IPv4 and/or IPv6) from some company and my DSL and HFC ISPs would hopefully have TTR-style ETRs (of the correct IPv4/6 flavor) in their networks. I would tunnel to those two TTRs and be happily mulithomed. If there were no TTRs in these networks, I would tunnel to one or two TTRs from a TTR company (maybe two TTRs, each from a different TTR company), in the same city. For big, static, end-user networks it would be different. They would make specialised arrangements with fibre links to two or more ISPs and link directly into each ISP's ETRs. Each ISP would know to accept outgoing packets from the end-user network's micronet address space, which wouldn't directly involve the ETR. However for home and SOHO users who want to multihome, I think the TTR model would be the only feasible approach, since it would be too much fuss for the customer and the ISP to make special technical arrangements about routing packets back and forth along a particular DSL or cable modem service, where those packets are to and from some address space the ISP has no relationship with. >> I stand by all my arguments against the notion that ISPs will start >> disconnecting their networks from certain portions of the Net, due >> to marginal expense problems with running DFZ routers, due to desire >> to urge people to use IPv6 or for any other purpose. > > I'm not suggesting ISPs will filter for any other reason than > self-preservation. ISPs will filter out longer prefixes when they see > their infrastructure at risk. I am suggesting it will be cheaper to buy new routers than to try to replace the customers they would lose by not connecting them as fully to the Net as competing ISPs. > Having routers fall over, try to get back > up, and fall over again is not a lot of fun for anyone involved. Given > unconstrained routing system growth as implied by current policies and > technology and no deployable alternative, I'm not sure what other > options there are. I think the first option is bigger routers. Then, in the longer term, a greater impetus for a scalable routing and addressing system for both IPv4 (urgently) and IPv6 (ready for some time in the future when IPv6 is widely used). - Robin -- to unsubscribe send a message to [EMAIL PROTECTED] with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg
