On Tue, Sep 24, 2019 at 8:38 PM Joe Touch <[email protected]> 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 <[email protected]> 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: <[email protected]> > > 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 protected]> > > > > > > > > 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 > > [email protected] > > https://www.ietf.org/mailman/listinfo/int-area > _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
