On 05/03/2019 19:37, Brian E Carpenter wrote:
On 06-Mar-19 04:55, Tom Herbert wrote:
On Tue, Mar 5, 2019 at 2:30 AM Stewart Bryant <[email protected]> wrote:
On 05/03/2019 01:37, Brian E Carpenter wrote:
Hi,
This is an interesting draft, but I must say I have serious doubts about
the IETF working on any significant update to IPv4 at the IP header level,
or of any such updates ever making it into the operational network.
This is something that worries me, in that the IETF seems to be
deserting the IPv4 market sector before it is clear that the market is
fully committed to an IPv6 only world.
Stewart,
I agree. It's clear that IPv4 isn't going away any time soon (e.g.
https://www.internetgovernance.org/2019/01/04/is-there-hope-for-ipv6/).
Bringing beneficial features into IPv4 from Ipv6, like the
aforemention extension headers, could promote uniformity between the
versions and might help to facilitate transition to IPv6.
Well, I worded my comment quite carefully. IPv4 will fade out over many
years, and any attempt to actively kill it would backfire. But that
doesn't mean that the intensively conservative enterprise network
operators will rush to enable new features. Rather the opposite, in
fact. That's why I give the UDP encapsulation approach a much better
chance of success, whether the carrier is IPv6 or IPv4.
Brian
I certainly think that the UDP approach is a good one that will see
greater exploration with time. The thing about UDP is that all the
routers look at it anyway to do ECMP.
As to enterprises, for them it is all cost benefit, which is why they
may "never" go IPv6 in many cases, but might be interested in enhanced IPv4.
As you may gather I think our "pilgrimage" to IPv6 means that we have
taken our eye off the ball in terms of the needs of the users of
Internet technology, which may remain IPv4 in some cases, and may move
immediately to something beyond IPv6 in other cases.
- Stewart
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
