Subject: Re: [Int-area] I-D Action: draft-herbert-ipv4-udpencap-eh-00.txt

From: Brian E Carpenter <[email-masked]>
Date: Tue, 5 Mar 2019 14:37:09 +1300

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.

On the other hand, I think the idea of a UDP encapsulation of extension
headers is very interesting. I'm not sure I understand all the implications
yet, and I'm not sure why the format can't be defined simply by a normative
reference to RFC8200. The idea of having a duplicate format definition
is a bit scary.

Regards
   Brian Carpenter

On 28-Feb-19 09:19, [email-masked] wrote:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 
>         Title           : IPv4 Extension Headers and UDP Encapsulated Extension Headers
>         Author          : Tom Herbert
> 	Filename        : draft-herbert-ipv4-udpencap-eh-00.txt
> 	Pages           : 27
> 	Date            : 2019-02-27
> 
> Abstract:
>    This specification defines extension headers for IPv4 and a method to
>    encapsulate extension headers in UDP to facilitate transmission over
>    the Internet. The goal is to provide a uniform and feasible method of
>    extensibility that is shared between IPv4 and IPv6.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-herbert-ipv4-udpencap-eh/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-herbert-ipv4-udpencap-eh-00
> https://datatracker.ietf.org/doc/html/draft-herbert-ipv4-udpencap-eh-00
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 5 Mar 2019 10:30:20 +0000

> 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.

Certainly a lot of enterprise networks and SP cores are still IPv4 only 
with no apparent intention to shift in the near future.

Markets and standards, like nature, abhor a vacuum, and if we do not 
continue to serve the IPv4 needs some other (quasi) SDO will appear in 
support of users with requirements and vendors that never leave money on 
the table.

- Stewart

---

From: Tom Herbert <[email-masked]>
Date: Tue, 5 Mar 2019 07:55:42 -0800

> 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.

Tom

> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area

---

From: Tom Herbert <[email-masked]>
Date: Tue, 5 Mar 2019 08:42:05 -0800

Hi Brian,

> Hi,
Hi Brian,

Thanks for the comments!

> or of any such updates ever making it into the operational network.

I understand the concern. It's probably true that extension headers in
IPv4 wouldn't be very usable in today's Internet. Undoubtedly, many
middleboxes would block them. But that's not because middleboxes are
concerned about a threat of extension headers in IPv4, it's more
because some middleboxes drop packets with any protocols they don't
understand (pretty much leaving only TCP and UDP as being usable
protocols on the Internet). There are some potential mitigations to be
pointed out:

- IPv4 already supports at least two extension headers, namely ESP and
AH. They might not be called extension headers, but they have the same
format and function as IPv6 cognates.
- There's no concept of HBH options in IPv4 as needing to be processed
by every node in the path, so the relaxed processing requirement of
RFC8200 can be set from the start without legacy issues.
- This doesn't actually change IP header, it is just enabling new
values in the protocol field. In a host implementation this is very
straightforward and in some ways it's a simplification to to be more
like IPv6.
- UDP encapsulation of extension headers could serve to make extension
headers transparent to middleboxes.
- It is conceivable to only allow extension headers in UDP
encapsulation thereby eliminating the problem of making a core update
to IPv4. IPv4 extension headers would be defined as part of an
encapsulation protocol.
- IPv4 extension headers could be another use case for limited domains.

> reference to RFC8200. The idea of having a duplicate format definition

Some implications are described in the document. When encapsulating
transport packets within UDP the IP header for the encapsulated
transport header needs to be deterministic, how to deal with NAT and
encapsulated transport checksum needs a solution. Intermediate nodes
parsing HBH embedded options is tricky since that requires them to
inspect UDP payloads and potential modify the payload. For that, a
magic number is used to minimize the possibility of misinterpretation
of UDP payload type. If you think of other implications please bring
them up.

I'm not sure what the comment on duplicate format definition refers
to. Perhaps this is about the the description of extension headers for
IPv4 in the draft?

Thanks,
Tom

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 6 Mar 2019 08:37:33 +1300

> 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

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 6 Mar 2019 08:41:59 +1300

> to. Perhaps this is about the the description of extension headers for

Yes. I'd rather see them defined as IPv6 extension headers patched for
IPv4, with no duplication of other parts of the definitions. Otherwise
there'll be a risk of them drifting apart.

   Brian

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 6 Mar 2019 16:36:18 +0000

> chance of success, whether the carrier is IPv6 or IPv4.

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

---

From: Fernando Gont <[email-masked]>
Date: Fri, 8 Mar 2019 06:44:51 -0300

HIi, Tom,

> <[email-masked]> wrote:
[...
> RFC8200 can be set from the start without legacy issues.

Aren't all IPv4 HBH optons, essentially?

> straightforward and in some ways it's a simplification to to be more

Haven't checked the I-D yet. Quick question: do you expect NATs parse
past this EHs to be able to do NAPT as they do nowadays?

Thanks!

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Tom Herbert <[email-masked]>
Date: Fri, 8 Mar 2019 08:12:05 -0800

> Aren't all IPv4 HBH optons, essentially?

Maybe they could be considered that in that they can be processed in
the network. However, they don't have the bits in the type field that
indicate modifiable options or what to do with an unknown option.

> past this EHs to be able to do NAPT as they do nowadays?
No, I wouldn't expect that. To get IPv4 extension headers through a
NAT,stateful firewall, etc. encapsulation in UDP can be done. Native
IPv4 extension headers would probably be most useful in a limited
domain.

Tom