--On Monday, February 13, 2012 17:11 +0100 Martin Rex
<mrex(_at_)sap(_dot_)com> 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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf