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

From: "Frank Brockners (fbrockne)" <[email-masked]>
Date: Tue, 1 Oct 2019 08:45:16 +0000

Expanding from Bob's preference: IMHO it would make sense to explore what we can solve with extension headers (HbyH and DO) - rather than argue the past or judge from the past. Hardware is changing - and what used to be the case, does not necessarily hold true in present or the future. 
Back in the hackathon at IETF 100 we even showcased a hardware implementation of what is ultimately an extension header use-case, see e.g. https://www.globenewswire.com/news-release/2017/11/10/1195153/0/en/Barefoot-Networks-Collaborates-with-Cisco-to-Demonstrate-In-situ-Operations-Administration-and-Management-IOAM-Showcasing-the-Power-of-Programmable-Forwarding-Plane-Technology.html 

Providing a holistic implementation in hardware for recent efforts that leverage EH (like PDM, IOAM, etc.) would become easier if we had a protocol independent approach to EH. This would mean that e.g. for IOAM we could use almost the same implementation for v4 as we'd do for v6 - protocol specific efforts would be limited, and as a nice side effect we'd avoid more complex encapsulations for IOAM in IPv4 which we'd need to use otherwise (e.g. one proposal is to use GRE - which doesn't make things easier).

Frank

> -----Original Message-----
> From: Frank Brockners (fbrockne) <[email-masked]>
> Sent: Dienstag, 1. Oktober 2019 10:22
> To: Frank Brockners (fbrockne) <[email-masked]>
> Subject: Re: [Int-area] New Version Notification for draft-herbert-ipv4-hbh-
> destopt-00.txt
> 
> Joe,
> 
> > On Sep 28, 2019, at 8:05 AM, Joe Touch <mailto:[email-masked]&gt;
> wrote:
> >
> > 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.
> 
> 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
> 
> 
> >
> > Joe
> >
> >> On Sep 27, 2019, at 7:11 AM, Black, David <mailto:[email-masked]&gt;
> wrote:
> >>
> >> 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 <mailto:[email-masked]&gt; 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
> <mailto:[email-masked]&gt; 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
> >
> > _______________________________________________
> > Int-area mailing list
> > mailto:[email-masked]
> > https://www.ietf.org/mailman/listinfo/int-area

---

From: Joe Touch <[email-masked]>
Date: Tue, 1 Oct 2019 07:45:14 -0700

> On Oct 1, 2019, at 1:45 AM, Frank Brockners (fbrockne) <[email-masked]> wrote:
> 

Sure, but...

> Providing a holistic implementation in hardware for recent efforts that leverage EH (like PDM, IOAM, etc.) would become easier if we had a protocol independent approach to EH. This would mean that e.g. for IOAM we could use almost the same implementation for v4 as we'd do for v6

I think you’re missing Bob’s point, which I’ll expand on:

a) you can already proceed for IPv6; show us it has been deployed

b) as you note, IPv4 != IPv6. “almost the same” has a lot of variants...

> - protocol specific efforts would be limited, and as a nice side effect we'd avoid more complex encapsulations for IOAM in IPv4 which we'd need to use otherwise (e.g. one proposal is to use GRE - which doesn't make things easier).

I can see how GRE might be more complex, but not why a HBH code point is needed (e.g., vs. just an IPv4 protocol code point and using the IPsec approach).

Joe

---

From: Tom Herbert <[email-masked]>
Date: Tue, 1 Oct 2019 08:14:29 -0700

Joe,

Taking "the IPsec approach" would be creating a new extension header
and code point that is unique to IPv4-- I don't see how that's any
better than just using an existing EH defined for IPv6. IP protocol 0
is already reserved in the IPv4 protocol number space, it's just a
matter of specifying how it can be used with IPv4.

Tom

> [email-masked]

---

From: Fred Baker <[email-masked]>
Date: Tue, 1 Oct 2019 11:38:12 -0400

On Oct 1, 2019, at 11:14 AM, Tom Herbert <[email-masked]> wrote:
> better than just using an existing EH defined for IPv6. 

I'm not sure I agree with that.

When we added IPsec to IPv4, a system that didn't implement IPsec could not step past the IPsec header when parsing. It had no idea the length of the ipSEC header. If we add an extension header to IPv6 (for example, when we added the security header to IPv6), we could continue to parse the IPv6 header even if we didn't implement a given header beyond parsing. So they are not the same thing.

---

From: Tom Herbert <[email-masked]>
Date: Tue, 1 Oct 2019 08:57:50 -0700

> When we added IPsec to IPv4, a system that didn't implement IPsec could not step past the IPsec header when parsing. It had no idea the length of the ipSEC header. If we add an extension header to…

Fred,

Yes, I was assuming Joe meant to create a new extension header for
IPv4. The EH, rather it's a new one or reuse of HBH or DO, would have
the properties of other plain text EHs with next header field and
explicit length and so could be parsed over.

Tom

---

From: Ole Troan <[email-masked]>
Date: Tue, 1 Oct 2019 21:30:53 +0200

> When we added IPsec to IPv4, a system that didn't implement IPsec could not step past the IPsec header when parsing. It had no idea the length of the ipSEC header. If we add an extension header to…

In the general case you cannot parse over an unknown extension header in IPv6 either.
AH and ESP have already been backported from IPv6 to IPv4. I see no principal difference in doing the same with the remaining two (or three) containers options either.

Cheers,
Ole