Re: [v6ops] Enterprises won't deploy IPv6 for IPv6's sake (as they didn't IPv4, IPX, XNS, or DECNet)

Hi,

On 9 Jan 2014, at 16:55, "Templin, Fred L" <Fred.L.Templin@boeing.com> wrote:

> Hi Mark,
> 
> In our enterprise we are seeing an emerging network-layer "killer app"
> for IPv6; namely, the deployment of mobile multi-access end user devices
> that need to maintain a stable IP address or subnet. These devices are
> commonly tablets or handsets of various manufacturers that have wireless
> access technologies that get (re)assigned different access addresses as
> they move around, and so tunneling is needed to maintain stable end-user
> addresses.
> 
> As the number of mobile devices grows, the end user addresses assigned
> to mobiles would soon exhaust and fragment the RFC1918 space - hence the
> need for IPv6. But, we only see a need to deploy IPv6 on the mobiles
> themselves and we do not necessarily see a need to upgrade the entire
> enterprise routing structure to IPv6.

The campus wireless solutions I've seen from vendors to date that support IPv6 do some "interesting" things to support devices roaming between IPv6 wireless subnets.  They certainly don't seem to use MIPv6, rather it seems common to use either unicast RAs and/or L2 tunnelling between controllers. e.g. see http://www.cisco.com/en/US/products/ps10315/products_tech_note09186a0080bae506.shtml#mobility.

Tim

> Think of the tablet/handset as a miniature "mobile router" - a device
> that should be able to connect up its own applications plus any number
> of additional end user devices (Internet connection sharing). The mobile
> router gets an IPv6 prefix (/64 or shorter), and a routing system inside
> the enterprise network tracks the mobiles as they move around. What I am
> describing is AERO:
> 
> http://tools.ietf.org/html/draft-templin-aerolink
> 
> Thanks - Fred
> fred.l.templin@boeing.com
> 
>> -----Original Message-----
>> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Mark ZZZ Smith
>> Sent: Thursday, January 09, 2014 2:07 AM
>> To: Randy Bush; Ted Lemon
>> Cc: v6ops@ietf.org
>> Subject: [v6ops] Enterprises won't deploy IPv6 for IPv6's sake (as they didn't IPv4, IPX, XNS, or
>> DECNet)
>> ----- Original Message -----
>>> From: Randy Bush <randy@psg.com>
>>> To: Ted Lemon <ted.lemon@nominum.com>
>>> Cc: "v6ops@ietf.org" <v6ops@ietf.org>
>>> Sent: Thursday, 9 January 2014 8:57 AM
>>> Subject: Re: [v6ops] New Version Notification for    draft-yourtchenko-ra-dhcpv6-comparison-00.txt
>> (fwd)
>>> 
>>>>>   if we want them to deploy ipv6, as opposed to more rfc1918 space, then
>>>>>   we need to remove all speed bumps.  not discuss them.  not tell them
>>>>>   that RA is the true religion.  frelling remove the speed bump.
>>>> 
>>>>   Can you name a specific speed bump?  I've been listening to this
>>>>   conversation for eight years too, and have yet to hear one named.  You
>>>>   seem to be saying that RA is the speed bump, but that's not specific.
>>>>   What is it about RA that "they" need changed?
>>> 
>>> the missing dhcp function, exit router
>>> 
>> 
>> 
>> I don't think this is really true at all. What motivates an enterprise to deploy a new technology is
>> primarily what it does for the enterprise, not specific features of it.
>> 
>> In the early 1990s, enterprises didn't deploy IPX for IPX's sake. They didn't say, "We want IPX." They
>> said, "We want to be able to share files and printers, because it is cheaper than floppy disks and
>> sneakernet, and buying everybody individual printers." If they chose Novell Netware to share files and
>> printers, they then deployed IPX because Novell Netware required it. Those who chose Banyan Vines for
>> file and print sharing deployed the Banyan Vines protocol instead.
>> 
>> In the middle to late 1990s, enterprises didn't deploy IPv4 for IPv4's sake.  They didn't say, "We
>> want IPv4." They said, "We want to be able to email other organisations and be able to access the WWW,
>> because we can email customers and suppliers more quickly than using slower fax and snail mail, and
>> access information useful to our business on the Internet." They then needed IPv4 to do that, so they
>> deployed IPv4 (and wondered why it all had to be so hard with address classes, subnet masks and
>> default gateways, compared to deploying and operating turn-key IPX.)
>> 
>> For most enterprises, other than those that make their money from information technology (like the
>> ones that most people on this mailing list work for), technology is a "necessary evil" to support
>> their actual business of making some other type of widget. It is a cost that takes away from the
>> larger profit they could make on their widgets. If they can reduce those costs, or even eliminate
>> them, they will, because that increases their widget profit.
>> 
>> So a new technology has to either save the enterprise money or make the enterprise money for it to be
>> justified.
>> 
>> The "killer app" for IPv6 for an enterprise is one that exclusively operates over IPv6 (instead of
>> over their already deployed IPv4) _and_ makes or saves them money. Some enterprises may never
>> encounter an IPv6-only application that does this, so they may never have an incentive to deploy it on
>> their network. They may wish to have access to the IPv6 Internet eventually, but all that might mean
>> is IPv6 enabling the external interface of their corporate policy enforcing web proxy, reached over
>> RFC1918 IPv4.
>> 
>> Change IPv6 as much as people want, but if it isn't possible to identify how it, or the applications
>> that exclusively run over it will save or make them money, enterprises will ignore it. More change and
>> more options to it will only increase it's deployment costs, further increasing the barrier it has to
>> jump before it saves or makes an enterprise money.
>> 
>> 
>> Regards,
>> Mark.
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops