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

[Tom Herbert <[e-mail]>]

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

> Hi, Tom,
>
> I’ll resend my primary concern:
>
> > On Sep 25, 2019, at 8:46 AM, Tom Herbert <[e-mail]> wrote:
> >
> > On Tue, Sep 24, 2019 at 8:38 PM Joe Touch <[e-mail]> 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)?
> >>        (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,
> >
> > The use case for this is the same as that for IPv6 HBH and DestOpts.
>
> 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.
>
> > There is a need in IPv4 to carry optional network layer information
> > 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.
>

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

…
> > 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.
>
> 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
> > because modifying UDP payload in the network leads to silent data
> > corruption when the UDP ports are misinterpreted (RFC7605).
>
> 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.
>
> > #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.
>
> Arguably you’re doing the same with the IP protocol field, but then (as
> noted before), IPsec already did this.
>
> > #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.
> >> Joe
> >>
> >>> On Sep 24, 2019, at 11:58 AM, Tom Herbert <[e-mail]> wrote:
> >>>
> >>> 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: <[e-mail]>
> >>> Date: Tue, Sep 24, 2019 at 11:53 AM
> >>> Subject: New Version Notification for
> draft-herbert-ipv4-hbh-destopt-00.txt
> >>> To: Tom Herbert <[e-mail]>
> >>>
> >>>
> >>>
> >>> 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
> >>>
> >>> _______________________________________________
> >>> Int-area mailing list
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/int-area
> >>
>
>