Subject: [Int-area] Fwd: New Version Notification for draft-herbert-ipv4-hbh-destopt-00.txt

From: Tom Herbert <[email-masked]>
Date: Tue, 24 Sep 2019 11:58:39 -0700

Hello,

I posted a new draft on allowing Hop-by-Hop and Destination options in
IPv4. Relative to the previous draft on IPv4 extension headers
(draft-herbert-ipv4-eh-01) this draft is narrow in intent to just
define use of HBH and DestOpt in IPv4 based on feedback during
IEFT104.

Thanks,
Tom

---------- Forwarded message ---------
From: <[email-masked]>
Date: Tue, Sep 24, 2019 at 11:53 AM
Subject: New Version Notification for draft-herbert-ipv4-hbh-destopt-00.txt
To: Tom Herbert <[email-masked]>

A new version of I-D, draft-herbert-ipv4-hbh-destopt-00.txt
has been successfully submitted by Tom Herbert and posted to the
IETF repository.

Name:           draft-herbert-ipv4-hbh-destopt
Revision:       00
Title:          IPv4 Hop-by-Hop Options and Destination Options
Extension Headers
Document date:  2019-09-24
Group:          Individual Submission
Pages:          18
URL:
https://www.ietf.org/internet-drafts/draft-herbert-ipv4-hbh-destopt-00.txt
Status:         https://datatracker.ietf.org/doc/draft-herbert-ipv4-hbh-destopt/
Htmlized:       https://tools.ietf.org/html/draft-herbert-ipv4-hbh-destopt-00
Htmlized:
https://datatracker.ietf.org/doc/html/draft-herbert-ipv4-hbh-destopt

Abstract:
   This specification enables the use of Hop-by-Hop Options and
   Destination Options extension headers which are defined for IPv6 to
   be used with IPv4. The goal is to provide a uniform and feasible
   method of extensibility that is common between IPv4 and IPv6.

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.

The IETF Secretariat

---

From: Joe Touch <[email-masked]>
Date: Tue, 24 Sep 2019 20:38:29 -0700

Not that I think this is a good idea, but if it proceeds:

- it’s worth noting in this doc that although IPv4 has its own option space, the extension header method is ALREADY how IPsec is defined as an IPv4 option, i.e., IPv4 protocol *always meant* next header anyway

- HBH options MUST be copied into each fragment when fragmented

	note that this means that an extended discussion of how to fragment and its implications is needed;
	the standard alg won’t work. it also means you’ll strictly exceed the IPv4 official definitions of MTU and
	minimum frag size.

	however, this complicates the claim that HBH options in the first frag are handled only if they’re
	complete; if they’re not complete, you have no protocol left

	i.e., either HBH are copied into EACH FRAGMENT (as they are at the source in IPv6), or 
	fragmentation CANNOT occur; you can’t simply act as if the HBH happens only for the first
	fragment or are ignored at IP hops other than the destination

(FWIW, it’s the second point that leads me to question the utility here)

- that said, why is this supposed to help? can you give us examples of successful IPv6 *options* deployed this way at line rate in hardware (notably not for experiments or diagnostic debugging)?
	(NB: I don’t consider tunnel encapsulation/decap or IPsec useful examples; those can already be
	supported that way and don’t really need this “option” mechanism; frag isn’t useful either)

Joe

> On Sep 24, 2019, at 11:58 AM, Tom Herbert <[email-masked]> wrote:
> 
> Hello,
> 
> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area

---

From: Tom Herbert <[email-masked]>
Date: Wed, 25 Sep 2019 08:46:28 -0700

>         supported that way and don’t really need this “option” mechanism; frag isn’t useful either)
Joe,

The use case for this is the same as that for IPv6 HBH and DestOpts.
There is a need in IPv4 to carry optional network layer information
that might be inspected and possibly modified (HBH options at least).

IOAM is a very good example of this where intermediate nodes in a path
record management information in flight packets, and the recorded
information is useful to other nodes in the path. Defining IOAM
protocols is current work in ippm.

For IPv6, a Hop-by-Hop option for IOAM can be defined
(draft-ioametal-ippm-6man-ioam-ipv6-options-01). This is clean and
consistent with HBH options as described in RFC8200.

Defining an IOAM protocol for IPv4 is the problem. There are at least
five proposals:

1) Use IPv4 options to carry the data (e.g. IPv4+options->TCP)
2) Allocate a new IP protocol number to carry IOAM data (IPv4->IOAM->TCP)
3) Embed IOAM data in the optional data of a UDP encapsulation like
Geneve or GUE (IPv4->UDP->GUE->TCP)
(draft-brockners-ippm-ioam-geneve-03)
4) Use GRE and create a new EtherType that contain IOAM data structure
(IPv4->GRE->IOAM->TCP) (draft-weis-ippm-ioam-gre-00)
5) Enable Hop-by-Hop options in IPv4 and use the IOAM HBH option being
defined (IPV4->HBH->TCP) (this draft)

#1 is the standard way to extend IPv4 for this sort of thing, however
IPv4 are generally considered a non-starter. It's well known that
routers don't deal with them well and the space is limited to forty
bytes. #2 would define a new type of extension header. #3 isn't robust
because modifying UDP payload in the network leads to silent data
corruption when the UDP ports are misinterpreted (RFC7605).

#4 is interesting. There is a certain appeal in that it's much easier
to get an EtherType allocation rather than an IP protocol number.
OTOH, this seems like an abuse of GRE to turn it into IP extensibility
mechanism which it was never intended to be.

#5 is the proposed method of this draft.

Assuming that IPv4 options are not an option, all the remaining share
some properties. Each is creating or using an extension header in some
format (i.e. a header inserted between the IPv4 header and transport
layer). They are all subject to IPv4 fragmentation where fragments
will not contain the IOAM data-- the first fragment may contain IOAM
data and it would need to be specified whether intermediate nodes can
process the data.

Tom

Th#2-#5 are variations on the same theme, namely to carry IOAM data in
some sort of extension header. The differences amongst these are the
format the extension header would take.

---

From: Joe Touch <[email-masked]>
Date: Thu, 26 Sep 2019 07:30:07 -0700

Hi, Tom,

I’ll resend my primary concern:

> On Sep 25, 2019, at 8:46 AM, Tom Herbert <[email-masked]> wrote:
> 
>> ...

My concern is that the HBH options are not used largely for the same reasons that IP options are not used:
a) they are not cost-effective to implement in the fast path
b) slow-path processing is not considered useful.

> that might be inspected and possibly modified (HBH options at least).

That’s called a packet. If routers actually didn’t look further inside without explicit permission of a HBH header, I’d agree. But they routinely dig far into packets for their own purposes, often at the expense of E2E integrity or semantics.

> IOAM is a very good example

It’s a pending example; if you can show no widely deployed and used IPv6 HBH header, then this all becomes speculation.
…
> bytes.

Is space an issue for IOAM?
And if routers don’t do IP options, why do you think they would handle IOAM?

> #2 would define a new type of extension header.

This seems easily sufficient - the argument that it’s hard to get an IP protocol number is correct - it should be. But isn’t that what you’re doing with this draft? Wouldn’t needing an IP protocol number still be needed even if your draft passed?

I.e., why do we need to do double the assignment and work - esp. given this is for an emerging proposal.

> #3 isn't robust

Agreed - a port filter would then disable this approach. But why isn’t that a *desirable* property? IMO, this protocol represents a potential security risk that should be easy for users or networks to disable and filter.

> mechanism which it was never intended to be.

Arguably you’re doing the same with the IP protocol field, but then (as noted before), IPsec already did this.

---

From: Tom Herbert <[email-masked]>
Date: Thu, 26 Sep 2019 07:54:07 -0700

On Thu, Sep 26, 2019, 7:30 AM Joe Touch <[email-masked]> wrote:

> >> - that said, why is this supposed to help? can you give us examples of
> successful IPv6 *options* deployed this way at line rate in hardware
> (notably not for experiments or diagnostic debugging)?
> That’s called a packet. If routers actually didn’t look further inside
> without explicit permission of a HBH header, I’d agree. But they routinely
> dig far into packets for their own purposes, often at the expense of E2E
> integrity or semantics.
>
> It’s a pending example; if you can show no widely deployed and used IPv6
> HBH header, then this all becomes speculation.
>

Joe,

Your arguments seems to be more against use of Hop-by-Hop options in
general.

Last time I checked, Hop-by-Hop options have not been deprecated by IETF.
Neither do I see why it's incumbent on us to show they're widely deployed
as a prerequisite to developing them. Additionally, what is the evidence
that they're not widely deployed-- for instance do we _know_ for a fact
that they're not deployed in some large private network? (IOAM is targeted
to closed networks). For that matter if we only are allowed to work with
protocols that are widely deployed, then how could we ever work on new
protocols? E.g. why should we develop new UDP options when they currently
they have no deployment.

Tom

…
> This seems easily sufficient - the argument that it’s hard to get an IP
> protocol number is correct - it should be. But isn’t that what you’re doing
> with this draft? Wouldn’t needing an IP protocol number still be needed
> even if your draft passed?
>
> Agreed - a port filter would then disable this approach. But why isn’t
> that a *desirable* property? IMO, this protocol represents a potential
> security risk that should be easy for users or networks to disable and
> filter.
>
> >>> Status:
> https://datatracker.ietf.org/doc/draft-herbert-ipv4-hbh-destopt/
> >>> Htmlized:
> https://tools.ietf.org/html/draft-herbert-ipv4-hbh-destopt-00
> >>> Htmlized:

---

From: Joe Touch <[email-masked]>
Date: Thu, 26 Sep 2019 08:17:15 -0700

Hi, Tom,

> On Sep 26, 2019, at 7:54 AM, Tom Herbert <[email-masked]> wrote:
> 
> Joe,
> 
> Your arguments seems to be more against use of Hop-by-Hop options in general.

My concern is that you are trying to copy what appears to be a failed approach. I have no position on whether it *should* fail, but more rather that it *has*.

I.e., I’m following your logic:
	- IPv4 options are not deployed and so are not useful

I agree completely. But isn’t the same true for IPv6 HBH?

If not, can you provide *an example of a widely deployed HBH option in current use*?

> Last time I checked, Hop-by-Hop options have not been deprecated by IETF. Neither do I see why it's incumbent on us to show they're widely deployed as a prerequisite to developing them. Additionally, what is the evidence that they're not widely deployed-- for instance do we _know_ for a fact that they're not deployed in some large private network? (IOAM is targeted to closed networks). For that matter if we only are allowed to work with protocols that are widely deployed, then how could we ever work on new protocols? E.g. why should we develop new UDP options when they currently they have no deployment.

Agreed, but your logic leads to the conclusion that you should be using IPv4 options (unless you show that space is a problem) first.

If that is a problem, then an IP protocol is sufficient, as it was for IPsec.

I see no need for an IPv4 framework to address a problem that doesn’t need that *framework*.

Joe

---

From: "Black, David" <[email-masked]>
Date: Fri, 27 Sep 2019 14:11:40 +0000

There may be a relatively contained early-adopter opportunity to try something in this area of IPv4 options – Deterministic Networking (DetNet – detnet WG) is using 6-tuple match (2 x IP address, L4 protocol [e.g., TCP, UDP], 2 x port, DSCP) to pick off traffic flows that go through the DetNet data plane in routers instead of the default data plane.  DetNet appears to nee IOAM in order to ensure that OAM traffic goes through the DetNet data plane – if the DetNet data plane is down, having an OAM  continuity check report that the default data plane is functional turns out to be worse than useless, as it has the potential to mislead the operator about where and what the problem is.

Thanks, --David

From: Int-area <[email-masked]> On Behalf Of Joe Touch
Sent: Thursday, September 26, 2019 11:17 AM
To: Tom Herbert
Cc: int-area
Subject: Re: [Int-area] New Version Notification for draft-herbert-ipv4-hbh-destopt-00.txt

[EXTERNAL EMAIL]
Hi, Tom,

On Sep 26, 2019, at 7:54 AM, Tom Herbert <[email-masked]<mailto:[email-masked]>> wrote:

Joe,

Joe

---

From: Joe Touch <[email-masked]>
Date: Sat, 28 Sep 2019 08:05:43 -0700

Hi, David,

Although I appreciate new interest in trying this experiment, that’s not what I was asking.

My understanding of the logic is as follows:
	- IPv4 in-header options aren’t supported
	- so let’s make a version of IPv4 options inspired by IPv6 HBH options

That logic only works if IPv6 HBH options were a success. I’m asking for anyone to point to a success case.

If there are no widely deployed IPv6 HBH options at this point (given they’ve been available for two decades), this is not a useful approach to mimic in IPv4.

Joe

> On Sep 27, 2019, at 7:11 AM, Black, David <[email-masked]> wrote:
> 
> From: Int-area <[email-masked] <mailto:[email-masked]>> On Behalf Of Joe Touch
> On Sep 26, 2019, at 7:54 AM, Tom Herbert <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Joe,
>

---

From: Bob Hinden <[email-masked]>
Date: Sun, 29 Sep 2019 10:29:12 -0700

Joe,

> On Sep 28, 2019, at 8:05 AM, Joe Touch <[email-masked]> wrote:
> 
> Hi, David,
> 

To add, my preference would be see effort go into making a few IPv6 HBH options work on the Internet, vs. trying to update all IPv4 implementations to support a similar mechanism for IPv4.

Bob