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