ietf
[Top] [All Lists]

Re: The point is to change it: Was: IPv4 depletion makes CNN

2010-06-09 15:38:22
On 6/7/10 12:49 PM, John C Klensin wrote:

> My belief is that we have a serious IPv6 marketing and
> transition problem until and unless we can get a level of
> functionality for IPv6 (and, really, for IPv4/IPv6 mixtures of
> the sorts that Ned's notes imply) at a level of investment
> roughly equivalent to the costs we are now paying for IPv4
> alone.   I want to stress that "level of investment" and terms
> like "expensive" are measured in requirements for knowledge,
> maintenance, configuration fussing, etc., not just hardware.
> They also include some important issues about support costs on
> the vendor/ISP side: if an ISP sells a "business IPv6 service"
> with certain properties and customers get into trouble, that ISP
> is itself in trouble if the support requests require third-level
> or engineering/design staff involvement to understand or
> resolve.  When the hardware costs we are talking about are in
> the same range as one month's connectivity bills (and all the
> numbers you and Ned mentioned are, at least for me), they just
> wash out and disappear compared to aggravation, fussing, and
> other sysadmin costs.

IMHO, it would be a mistake to expect low end routers targeting home and
small office environments to eventually include features for handling
multiple IPv4 addresses

Except that there is no "eventually" here. This class of device already supports multiple IPv4 addresses and 1:1 NAT, for the simple reason that a lot
of such setups depend on having such support. This has been true for many
years.

The problem with this class of device isn't the lack of support for multiple
IPv4 addresses, it's the lack of support for IPv6.

in conjunction with an IPv4 to IPv6 transition
strategy, largely for the reasons you give.   When multiple providers
are involved,

Again with the multiple providers strawman. Nobody is talking about multiple
providers and failover and so on here. This truly is a different level of
service.

some choices are available for multiple IPv4 addresses
where devices terminating a provider's network are connected through a
vlan switch with trunking.  Or terminated with a selection of mid-range
routers ~$400/$50 new/used price range, such as cisco 871 or 2600.
Instead of expecting a company's support to deal with with involved
configurations, solutions are increasingly met by co-location services,
or VPS where the providers offer network/power redundancy,  dual stack
rout-ability, and support expertise.

All of which fals FAR outside the range of service this discussion is about.

An automatic 6to4 tunnel for an isolated IPv6 network,  routes on a
per-packet basis to a border router in another IPv6 network over IPv4
infrastructure.  Tunnel destinations are determined by the IPv4 address
of the border router extracted from the IPv6 address starting with the
prefix 2002::/16 having the format
2002:/border-router-IPv4-address/::/48, which likely makes this a
function of the ISP.  When IPv6 is available, each device becomes
accessible with unique IP addresses.  A conservative approach for scarce
IPv4 addresses is to associate dedicated servers/services with specific
ports of a single global address, a feature supported by nearly all
commodity routers.  Whenever accessing IPv6 networks over the Internet
becomes imperative, ISPs will suggest boilerplate solutions.  However,
it seems unlikely these will include anachronistic use of IPv4 addresses.

And so, having no other argument to make, we resort to pejoratives?
Calling small business use of a small number of IPv4 addresses "anachronistic"
doesn't change the fact that this is a widespread practice fully supported by
an ample number of reasonable quality router products. And you're not going to
get IPv6 deployed in such cases without a drop-in replacement that adds IPv6
support to what's already there.

                                Ned
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>