Re: [IPv6] Reasons for slow IPv6 adoption in Enterprises

[Nick Hilliard <[e-mail]>]

Ed,

fwiw, your description below aligns very closely with my experience of 
enterprise apathy about ipv6.

These may be good issues to dissect and try to solve in v6ops.

Nick

Vasilenko Eduard wrote on 21/07/2023 08:35:
>
> Hi Robert,
>
> 1.
>
> I believe that the 1^st reason for a very limited IPv6 adoption in the 
> enterprise is the absence of a budget or business case.
>
> IT typically has 4% of the company budget in many verticals, 
> networking is inside this. They could not replace the infrastructure 
> for a limited number of years whatever business case they would 
> prepare. IT is not the core business for many verticals.
>
> They need a ve-e-e-ry smooth upgrade. That IPv6 does not have.
>
> They need to invest for many-many years (up to 10) and leave with 
> DualStack double expenses.
>
> DC is an exception where the POD is typically replaced as a whole 
> (like Green Field). Some other Green Fields may happen as an exception.
>
> This business reason probably (my guess) has a 50% of weight in the 
> explanation of why we see so bad IPv6 adoption in enterprises.
>
> 2.
>
> Google blocking DHCPv6 is definitely inside the first 5 reasons. I am 
> not sure if is it in position 3 or 4.
>
> Let’s say that it is 10% of the overall weight of IPv6 adoption 
> challenges.
>
> 3.
>
> NAT [absence] is probably equal to DHCPv6 [blocking] in the weight for 
> reasons of IPv6's bad progress in Enterprises.
>
> 4.
>
> Somewhere around is the absence of a business case to spend additional 
> money for transformation.
>
> Hence, no, Google is not the primary reason. But big enough to talk 
> about it.
>
> Because of their rigid position, somebody would win: the market or 
> Google. It would be interesting to see who.
>
> PS: It is my personal opinion.
>
> Eduard
>
> *From:*Bob Hinden [mailto:[e-mail]]
> *Sent:* Thursday, July 20, 2023 5:19 PM
> *To:* Vasilenko Eduard <[e-mail]>
> *Cc:* Bob Hinden <[e-mail]>; Sri Gundavelli (sgundave) 
> <[e-mail]>; 6MAN <[e-mail]>
> *Subject:* Re: [IPv6] New Version Notification for 
> draft-gundavelli-6man-nd-location-00.txt
>
> Eduard,
>
> It’s a false dichotomy to say “Google vs. IPv6”. Or to say that the 
> reason for a slow enterprise migration to IPv6 is due to Android not 
> supporting DHCP.
>
> Bob
>
>
>
>     On Jul 20, 2023, at 12:01 AM, Vasilenko Eduard
>     <vasilenko.eduard=[e-mail]
>     <mailto:vasilenko.eduard=[e-mail]>> wrote:
>
>     Hi Sri, I am not sure.
>
>     Stateless DHCPv6 looks better because it was intended specifically
>     for such sort of situation.
>
>     Doing it on the ND is like reinventing the wheel.
>
>     The more competitive options exist for the same purpose – the less
>     probability of market adoption for all of them.
>
>     But from another point of view, there is the battle of Google
>     against the whole world for DHCP blocking.
>
>     If we would assume that Google would win then Enterprises would
>     need an alternative method to deliver location.
>
>     The question would probably be different:
>
>     Would enterprises eradicate Google software from their networks or
>     enterprises would not move to IPv6 at all?
>
>     IMHO: Businesses would choose Google, not IPv6. (hence, the
>     current miserable % adoption of IPv6 on Enterprises)
>
>     But there is big pressure from some governments for IPv6
>     migration, at least for the Public sector.
>
>     They have to decide: cancel Google or DHCP? Let us see the result
>     of the battle between the protocol and the biggest OTT.
>
>     Eduard
>
>     *From:*Sri Gundavelli (sgundave) [mailto:[e-mail]]
>     *Sent:*Wednesday, July 19, 2023 8:23 PM
>     *To:*Vasilenko Eduard <[e-mail]
>     <mailto:[e-mail]>>; Mark Smith
>     <[e-mail] <mailto:[e-mail]>>
>     *Cc:*6MAN <[e-mail] <mailto:[e-mail]>>
>     *Subject:*Re: [IPv6] New Version Notification for
>     draft-gundavelli-6man-nd-location-00.txt
>
>     Thanks Vasilenko.  I am not debating on what is a better approach,
>     but not to miss the key point here: if the reported data is of the
>     network node, there is no difference in how its delivered. With
>     DHCP or IPv6 RA, same considerations apply. But when reporting
>     client-specific location data, we need to ensure the location data
>     is of that device and it is delivered it to only that device.
>
>     My interest for this option is for allowing the endpoint to use in
>     emergency applications. The endpoint obtains this information from
>     the network, similar to how it obtains DNS configuration in RFC
>     6106, so it can use the same in call signaling.
>
>     I don’t have a use-case for obtaining this information for any
>     other IPv6 neighbor, but as a config option from the network.
>     Location from all my ND neighbors is too much of data.  There is a
>     trust relationship between the device and the network and we
>     extend the same trust for the reported location-data. In that
>     sense, an option in  IPv6 Router Advertisement is what I am
>     looking for. We need to define a new IPv6 Neighbor Discovery
>     option type for the same.
>
>     Sri
>
>     *From:*Vasilenko Eduard <[e-mail]
>     <mailto:[e-mail]>>
>     *Date:*Wednesday, July 19, 2023 at 12:43 AM
>     *To:*Mark Smith <[e-mail]
>     <mailto:[e-mail]>>, Sri Gundavelli
>     <[e-mail] <mailto:[e-mail]>>
>     *Cc:*6MAN <[e-mail] <mailto:[e-mail]>>
>     *Subject:*RE: [IPv6] New Version Notification for
>     draft-gundavelli-6man-nd-location-00.txt
>
>     >existing stateless DHCPv6 is the better solution
>
>     +1
>
>     *From:*Mark Smith [mailto:[e-mail]]
>     *Sent:*Tuesday, July 18, 2023 7:02 PM
>     *To:*Sri Gundavelli (sgundave) <[e-mail]
>     <mailto:[e-mail]>>
>     *Cc:*Vasilenko Eduard <[e-mail]
>     <mailto:[e-mail]>>; 6MAN <[e-mail]
>     <mailto:[e-mail]>>
>     *Subject:*Re: [IPv6] New Version Notification for
>     draft-gundavelli-6man-nd-location-00.txt
>
>     Hi Sri,
>
>     On Wed, 19 July 2023, 00:31 Sri Gundavelli (sgundave),
>     <sgundave=[e-mail]
>     <mailto:[e-mail]>> wrote:
>
>         Hi Vasilenko,
>
>         Thanks! With RFC 6085 Unicast RA, we will have the mechanism
>         to deliver client-specific location, and not just
>         network-attachment point location.
>
>     How are you going to identify clients in this situation?
>
>     RSes don't have any client identifiers in them for this purpose,
>     unlike DHCPv6 which has client DUIDs.
>
>     The answer isn't to add something like a client DUID to RAs,
>     because by the time you've done that you've nearly invented
>     existing 2 packet stateless DHCPv6, so may as well just use that
>     since it already does what you want and implementations already exist.
>
>     Additionally you also get the existing DHCPv6 deployment scaling
>     mechanisms of DHCPv6 relays that relay messages to more
>     centralised DHCPv6 servers.
>
>     You wouldn't have that with RSes with a client identifier, so
>     you'll have to configure every router with a database of all
>     possible clients and their option values, unless you (re)invent
>     "RS relay" mechanisms too.
>
>     There might be value in having options like these in RAs as long
>     as they apply to all hosts on a link.
>
>     However, beyond that, meaning client specific options and values,
>     then existing stateless DHCPv6 is the better solution.
>
>     Unicast RAs only exist to avoid the costs of link multicasts, not
>     to facilitate client specific RA options, because they can't
>     facilitate them.
>
>     Regards,
>
>     Mark.
>
>
>         Regards
>         Sri
>
>
>         On 7/17/23, 11:35 PM, "Vasilenko Eduard"
>         <vasilenko.eduard=[e-mail]
>         <mailto:[e-mail]><mailto:[e-mail]
>         <mailto:[e-mail]>>> wrote:
>
>
>         Hi Sri,
>         Unicast RA is much more welcome for a different reason:
>         downstream multicast does not work properly over Wireless
>         and/or consumes huge radio resources. Many solutions proposed
>         here (like "prefix per subnet" or fully stateful ND router)
>         are trying to eliminate downstream multicast as the biggest ND
>         problem in wireless. One more proposal would not hurt.
>         Eduard
>         -----Original Message-----
>         From: ipv6 [mailto:[e-mail]
>         <mailto:[e-mail]><mailto:[e-mail]
>         <mailto:[e-mail]>>] On Behalf Of Sri Gundavelli
>         (sgundave)
>         Sent: Monday, July 17, 2023 6:16 PM
>         To: Vasilenko Eduard
>         <vasilenko.eduard=[e-mail]
>         <mailto:[e-mail]><mailto:[e-mail]
>         <mailto:[e-mail]>>>;[e-mail]
>         <mailto:[e-mail]><mailto:[e-mail]
>         <mailto:[e-mail]>>
>         Subject: Re: [IPv6] New Version Notification for
>         draft-gundavelli-6man-nd-location-00.txt
>
>
>         Hi Vasilenko,
>
>
>         Thanks for reviewing the draft.
>
>
>         In the context of both RFC 6225 and RFC 4676, the reported
>         location can be of a.) a network node (e.g., DHCP server), b.)
>         a network node closest to the client, or of the c.) client
>         location. The same location semantics, supporting the three
>         different variants, can be sent in IPv6 ND as well.
>
>
>         > Hence, DHCP was the right approach.
>
>
>         This is a good observation and relevant only for #c above
>         (reported location is the client's location). Agree, the
>         unicast nature of DHCP allocation make it easy to deliver a
>         client specific location. But in wireless environments there
>         is extensive use of unicast RA (RFC 6085). When allocating
>         unique IPv6 prefixes, and/or for ensuring the periodic RA
>         messages do not add traffic on the wireless medium, RAs are
>         sent in unicast mode and that allows the network to deliver
>         client specific location. With indoor localization a default
>         feature in Wireless environments, the network can provide more
>         precise geo-spatial coordinates to the client.
>
>
>         Also, thanks for the feedback on the three approaches.
>
>
>         Regards
>         Sri
>
>
>
>
>
>
>
>
>
>
>
>
>         On 7/17/23, 12:34 AM, "Vasilenko Eduard"
>         <vasilenko.eduard=[e-mail]
>         <mailto:[e-mail]><mailto:[e-mail]
>         <mailto:[e-mail]>>
>         <mailto:[e-mail]
>         <mailto:[e-mail]><mailto:[e-mail]
>         <mailto:[e-mail]>>>> wrote:
>
>
>
>
>         Concern:
>         Location is probably an attribute of one host. Hence, DHCP was
>         the right approach.
>         The subnet could be stretched over the continent by different
>         L2 technologies.
>         Of course, it is possible to say that in this case, the
>         network administrator should not use the location option.
>
>
>
>
>         "troan-6man-universal-ra-option" is not an option because it
>         has no consensus.
>
>
>
>
>         PVD is probably not an option - it is just a way to deliver
>         many different subnet parameters to the host, That is not
>         needed for the location. The host could not be in 2 different
>         locations at the same time, couldn't it?
>
>
>
>
>         Ed/
>         -----Original Message-----
>         From: ipv6 [mailto:[e-mail]
>         <mailto:[e-mail]><mailto:[e-mail]
>         <mailto:[e-mail]>> <mailto:[e-mail]
>         <mailto:[e-mail]><mailto:[e-mail]
>         <mailto:[e-mail]>>>] On Behalf Of Sri Gundavelli
>         (sgundave)
>         Sent: Sunday, July 16, 2023 6:47 PM
>         To:[e-mail] <mailto:[e-mail]><mailto:[e-mail]
>         <mailto:[e-mail]>> <mailto:[e-mail]
>         <mailto:[e-mail]><mailto:[e-mail]
>         <mailto:[e-mail]>>>
>         Subject: [IPv6] FW: New Version Notification for
>         draft-gundavelli-6man-nd-location-00.txt
>
>
>
>
>         Hello folks:
>
>
>
>
>         I have posted a draft on supporting location elements in IPv6
>         ND. Please review and any feedback is greatly appreciated.
>
>
>
>
>         Regards
>         Sri
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>         On 7/12/23, 1:02 PM, "[e-mail]
>         <mailto:[e-mail]><mailto:[e-mail]
>         <mailto:[e-mail]>>
>         <mailto:[e-mail]
>         <mailto:[e-mail]><mailto:[e-mail]
>         <mailto:[e-mail]>>>
>         <mailto:[e-mail]
>         <mailto:[e-mail]><mailto:[e-mail]
>         <mailto:[e-mail]>>
>         <mailto:[e-mail]
>         <mailto:[e-mail]><mailto:[e-mail]
>         <mailto:[e-mail]>>>>"
>         <[e-mail]
>         <mailto:[e-mail]><mailto:[e-mail]
>         <mailto:[e-mail]>>
>         <mailto:[e-mail]
>         <mailto:[e-mail]><mailto:[e-mail]
>         <mailto:[e-mail]>>>
>         <mailto:[e-mail]
>         <mailto:[e-mail]><mailto:[e-mail]
>         <mailto:[e-mail]>>
>         <mailto:[e-mail]
>         <mailto:[e-mail]><mailto:[e-mail]
>         <mailto:[e-mail]>>>>> wrote:
>
>
>
>
>
>
>
>
>
>
>
>
>         A new version of I-D, draft-gundavelli-6man-nd-location-00.txt
>         has been successfully submitted by Sri Gundavelli and posted
>         to the IETF repository.
>
>
>
>
>
>
>
>
>         Name: draft-gundavelli-6man-nd-location
>         Revision: 00
>         Title: Civic Location and Geospatial Coordinate Support in
>         IPv6 ND Document date: 2023-07-12
>         Group: Individual Submission
>         Pages: 5
>         URL:https://www.ietf.org/archive/id/draft-gundavelli-6man-nd-location-00.txt<https://www.ietf.org/archive/id/draft-gundavelli-6man-nd-location-00.txt>
>         <https://www.ietf.org/archive/id/draft-gundavelli-6man-nd-location-00.txt>
>         <https://www.ietf.org/archive/id/draft-gundavelli-6man-nd-location-00.txt&gt;>
>         <https://www.ietf.org/archive/id/draft-gundavelli-6man-nd-location-00.txt>
>         <https://www.ietf.org/archive/id/draft-gundavelli-6man-nd-location-00.txt&gt;>
>         <https://www.ietf.org/archive/id/draft-gundavelli-6man-nd-location-00.txt&gt;>
>         <https://www.ietf.org/archive/id/draft-gundavelli-6man-nd-location-00.txt&amp;gt;&gt;>
>         Status:https://datatracker.ietf.org/doc/draft-gundavelli-6man-nd-location/<https://datatracker.ietf.org/doc/draft-gundavelli-6man-nd-location/>
>         <https://datatracker.ietf.org/doc/draft-gundavelli-6man-nd-location/>
>         <https://datatracker.ietf.org/doc/draft-gundavelli-6man-nd-location/&gt;>
>         <https://datatracker.ietf.org/doc/draft-gundavelli-6man-nd-location/>
>         <https://datatracker.ietf.org/doc/draft-gundavelli-6man-nd-location/&gt;>
>         <https://datatracker.ietf.org/doc/draft-gundavelli-6man-nd-location/&gt;>
>         <https://datatracker.ietf.org/doc/draft-gundavelli-6man-nd-location/&amp;gt;&gt;>
>         Htmlized:https://datatracker.ietf.org/doc/html/draft-gundavelli-6man-nd-location<https://datatracker.ietf.org/doc/html/draft-gundavelli-6man-nd-location>
>         <https://datatracker.ietf.org/doc/html/draft-gundavelli-6man-nd-location>
>         <https://datatracker.ietf.org/doc/html/draft-gundavelli-6man-nd-location&gt;>
>         <https://datatracker.ietf.org/doc/html/draft-gundavelli-6man-nd-location>
>         <https://datatracker.ietf.org/doc/html/draft-gundavelli-6man-nd-location&gt;>
>         <https://datatracker.ietf.org/doc/html/draft-gundavelli-6man-nd-location&gt;>
>         <https://datatracker.ietf.org/doc/html/draft-gundavelli-6man-nd-location&amp;gt;&gt;>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>         Abstract:
>         The physical location of a network device plays a crucial role
>         in various applications, particularly in emergency calling,
>         where precise caller location information is essential for
>         prompt and effective emergency response.
>
>
>
>
>
>
>
>
>         RFC 4676 has standardized DHCP options for delivering the
>         Civic Location of the client, while RFC 6225 has defined DHCP
>         options for delivering the Geospatial coordinates of the
>         client. However, these corresponding options are missing in
>         IPv6 Neighbor Discovery protocols.
>
>
>
>
>
>
>
>
>         This proposal aims to address this gap by introducing the
>         necessary options for IPv6 Neighbor Discovery to provide
>         accurate location information.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>         The IETF Secretariat
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>         --------------------------------------------------------------------
>         IETF IPv6 working group mailing list
>         [e-mail] <mailto:[e-mail]><mailto:[e-mail]
>         <mailto:[e-mail]>> <mailto:[e-mail]
>         <mailto:[e-mail]><mailto:[e-mail]
>         <mailto:[e-mail]>>>
>         Administrative
>         Requests:https://www.ietf.org/mailman/listinfo/ipv6<https://www.ietf.org/mailman/listinfo/ipv6>
>         <https://www.ietf.org/mailman/listinfo/ipv6>
>         <https://www.ietf.org/mailman/listinfo/ipv6&gt;>
>         --------------------------------------------------------------------
>
>
>
>
>
>
>         --------------------------------------------------------------------
>         IETF IPv6 working group mailing list
>         [e-mail] <mailto:[e-mail]><mailto:[e-mail]
>         <mailto:[e-mail]>>
>         Administrative
>         Requests:https://www.ietf.org/mailman/listinfo/ipv6<https://www.ietf.org/mailman/listinfo/ipv6>
>         --------------------------------------------------------------------
>
>
>
>         --------------------------------------------------------------------
>         IETF IPv6 working group mailing list
>         [e-mail] <mailto:[e-mail]>
>         Administrative Requests:https://www.ietf.org/mailman/listinfo/ipv6
>         --------------------------------------------------------------------
>
>     --------------------------------------------------------------------
>     IETF IPv6 working group mailing list
>     [e-mail] <mailto:[e-mail]>
>     Administrative Requests:https://www.ietf.org/mailman/listinfo/ipv6
>     --------------------------------------------------------------------
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------