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

[Tom Herbert <[e-mail]>]

On Tue, Sep 24, 2019 at 8:38 PM Joe Touch <[e-mail]> wrote:
>
> 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,

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