--On Monday, February 13, 2012 17:11 +0100 Martin Rex <mrex@xxxxxxx> wrote: > John C Klensin wrote: >> >> Arturo Servin wrote: >>> >>> Chris Grundemann wrote: >>>> >>>> Are you volunteering to buy everyone on earth a new CPE? If >>>> not, who do you suggest will? >>> >>> I suggest the ISPs, they are charging for the service, >>> right? ... >>>> if they were, we could just sign >>>> everyone up for IPv6 capable CPE and skip the whole >>>> debate... ;) >> >> So, Chris, if you expect this allocation will avoid the costs >> of signing everyone up for IPv6-capable CPE, what is your >> transition plan? Or are you advocating an IPv4-forever model? > > > If CPE is meant to refer to the border router, then this > appears like a very short-sighted look at the real issue. > > There are huge amounts of equipment in use that simply does > not support IPv6, other than border routers, like home > multimedia and entertainment stuff (Nintendo WII, Nintendo DS, > Internet-enabled set-top-boxes & TV & Radio, webcams, home > NAS, etc.), which do not support IPv6, > so I don't see how IPv6 could be seen as a solution at all (it > isn't). > > So everyone who is suggesting IPv6 here, is actually > suggesting NAT 4664 over NAT 444. Martin, I think we have been over this territory before. It certainly isn't part of the current Last Call (I've changed the subject line after it got truncated). But, briefly and in the faint hope that an explanation from a slightly different perspective might help, from where I sit it looks like there are three families of IPv6 migration strategies: (1) IPv6 packets on core network, replace or upgrade end network border router to run IPv6, provide IPv6 on end network, expect all devices on end network to be IPv6-capable (either natively or dual-stack). I agree with you that this is completely unrealistic but it is also a complete strawman -- I know of no one who understands the issues who is advocating it at this point. (2) IPv6 packets on core network, replace or upgrade end network border router to be able to do protocol conversion address translation as needed so that IPv4-only devices on the LAN receive and send IPv4 packets. That border device presents public IPv6 addresses to the Internet, not (only) IPv4 addresses (public or private) There seem to be dozens of variations on this theme, with, e.g., varying ideas about what to do about IPv6-native or dual-stack devices on the LAN and whether to temporarily provide public IPv4 addresses to the Internet as well, but the two important things that all of the alternatives have in common are that a customer with IPv6-capable devices can reasonably expect to run IPv6 on them (and run them in the traditional end to end mode with other IPv6 LANs and devices) and that the translations are, at least in principle, under customer control. Note that, especially for ISPs that provide the customer boundary devices as part of their services, one of the variations is to install IPv6-only border equipment and tell customers that, if they want to continue to run IPv4-only devices, they need to obtain and install conversion boxes behind the boundary devices (possibly subsidized but basically at their own expense). I would find that approach odious, but it is no more odious than the choice faced by households with older televisions in countries (or smaller areas) that are going all-digital. Indeed, as far as I can tell, it is _exactly_ the same issue. (3) IPv6 packets possibly on ISP core networks or at peering/ exchange points, but, other than large customers who can make their own arrangements, end network border routers all speak IPv4 (more or less exclusively) and present IPv4 addresses to the network. Whatever conversions are needed occur somewhere in the middle of the network. It seems to me that there are several variations on this theme too but, if the motivation for it includes "don't change any of the equipment on the user site to be IPv6-capable" then devices on the LAN that are IPv6-capable can't take advantage of it and devices on the LAN that are IPv6-only can't operate (note the symmetry between that situation and the argument you are making). Now a problem that some of us are having with CGNs (a member of the third category but perhaps not the only one, or even only one architecture), is that it doesn't seem to inherently involve an IPv6 transition at all. Maybe there are hybrid strategies that make them an integral part of an IPv6 transition, but I'm not sure I see them. If end system LANs are going to be able to receive IPv6 packets and/or use them internally then someone is going to need to incur the cost of purchasing, installing, and supporting IPv6-capable border equipment. If avoiding the costs of that equipment change (regardless of what else the equipment could do) is a goal of a CGN-based strategy, then there is no IPv6 transition strategy, only an IPv4 preservation one (and, to me, one that reinvents many of the strengths and weaknesses of the traditional PSTN Central Office Switch). That doesn't mean the IETF should or should not allocate this shared space block. If an ISP has decided its best strategy lies in CGNs (whether they have an IPv6 transition strategy or the CGNs are code for an IPv4-only network that tied together walled gardens (walled weed-patches?)), then I assume that, absent pressures the IETF can't apply, they will do that. If they don't think they can use private address space for that purpose, then either they will get this shared allocation, they will get private space from the RIRs for running a CGN-based architecture, or they will squat (well, maybe all three). I can't imagine an ISP who had decided on a CGN strategy deciding to not go forward with it because the IETF (or even the IETF and the RIRs) are resistant to that plan. But that is really a discussion about CDNs, not about the wisdom (or not) of making this allocation. john _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf