Tom,
OK. Let's see if the following text works any better for you.
Ron
========================
7.1. For Protocol Developers
Protocol developers SHOULD NOT develop new protocols that rely
on IP fragmentation. However, they MAY develop new protocols that
rely on IP fragmentation when no viable alternative exists.
Legacy protocols that depend upon IPv6 fragmentation SHOULD be updated
to break that dependency. However, in some cases, there may be no viable
alternative to IPv6 fragmentation (e.g., IPSec tunnel mode, IP-in-IP
encapsulation).
In these cases, the protocol MAY continue to rely on IPv6 fragmentation.
A protocol can break its dependency upon IP fragmentation by
using a sufficiently small MTU (e.g. the protocol minimum link MTU),
disabling IP fragmentation, and ensuring that the transport protocol in
use adapts its segment size to the MTU. Another approach is to deploy
a sufficiently reliable PMTU discovery mechanism (e.g., PLMPTUD).
7.3. For Middle Box Developers
Middle box developers SHOULD implement devices that process IP fragments in a
predictable manner.
For example, a stateless load balancer might exhibit one of the following
behaviors:
- Balance load based on L3 information only
- Balance load based upon both L3 and L4 information, but discard all IP
fragments
- For non-fragmented packets, balance load upon both L3 and L4 information. For
fragmented packets, balance load based upon L3 information only. Therefore,
packets belonging to a single flow can be assigned to two different interfaces.
(See Section 4.4 for details).
- Balance load based upon both L3 and L4 information, but maintain enough
state so that all packets and packet fragments belonging to a flow are assigned
to the same interface.
Undesirable outcomes can be attributed to each of the above mentioned
behaviors. Therefore, middle box vendors MUST document the behaviors that their
devices exhibit.
> -----Original Message-----
> From: Tom Herbert <t...@herbertland.com>
> Sent: Monday, November 12, 2018 4:25 PM
> To: Ron Bonica <rbon...@juniper.net>
> Cc: Joe Touch <to...@strayalpha.com>; Ole Troan
> <otr...@employees.org>; int-area <int-area@ietf.org>
> Subject: Re: [Int-area] Stateless devices and IP fragmentation
>
> On Mon, Nov 12, 2018 at 1:08 PM, Ron Bonica <rbon...@juniper.net> wrote:
> > Joe, Tom,
> >
> > Does the following text work for you?
> >
> > Ron
> >
> > =======================================================
> >
> >
> > 7.1. For Protocol Developers
> >
> > Protocol developers SHOULD NOT develop new protocols that rely
> > on IP fragmentation. However, they MAY develop new protocols that
> > rely on IP fragmentation when no viable alternative exists.
> >
> > Legacy protocols that depend upon IPv6 fragmentation SHOULD be
> updated
> > to break that dependency. However, in some cases, there may be no
> viable
> > alternative to IPv6 fragmentation (e.g., IPSec tunnel mode, IP-in-IP
> encapsulation).
> > In these cases, the protocol MAY continue to rely on IPv6 fragmentation.
> >
> > A protocol can break its dependency upon IP fragmentation by
> > using a sufficiently small MTU (e.g. the protocol minimum link MTU),
> > disabling IP fragmentation, and ensuring that the transport protocol in
> > use adapts its segment size to the MTU. Another approach is to deploy
> > a sufficiently reliable PMTU discovery mechanism (e.g., PLMPTUD).
> >
> > 7.3. For Middle Box Developers
> >
> > Middle box developers SHOULD implement devices that do not fail or
> cause
> > failures when processing fragmented IP packets.
> >
> > For example, in order to support IP fragmentation, a load balancer
> > might execute the following procedure:
> >
> > o Receive a fragmented packet
> >
> > o Identify a next-hop using information drawn from the first
> > fragment (i.e., the fragment containing offset 0)
> >
> > o Forward the first fragment and all subsequent fragments through
> > the above-mentioned next-hop
>
> Ron,
>
> I think that algorithm describes virtual reassmbly. Based on the first packet
> a
> virtual state for the fragment train is created and used to route the
> non-first
> fragments. Problems with this are: 1) the device is no longer stateless 2) it
> assumes the first fragement is received first 3) it requires that all
> fragments are
> forwarded through the same intermediate node.
>
> If the goal is to implement a stateless device, then all packets including
> fragments need to be processed independently. For a stateless firewall, just
> inspecting and potentially dropping the first fragment should yield the
> correct
> behavior. For an L4 load balancer, it is a hard problem to get consistent
> stateless forwarding between fragments and non-fragments. I believe that is
> best solved by routing based on flow label instead of ports. The flow label is
> available in all packets and doesn't require DPI, it should be the suggested
> solution for IPv6 at least.
>
> Tom
>
> >
> > In some cases, given price and performance constraints, it may be
> impossible to design a middle box that processes IP fragments correctly. In
> these cases, the vendor MUST document the issue and propose work-arounds.
> >
> >> -----Original Message-----
> >> From: Joe Touch <to...@strayalpha.com>
> >> Sent: Monday, November 12, 2018 2:02 PM
> >> To: Ron Bonica <rbon...@juniper.net>
> >> Cc: Ole Troan <otr...@employees.org>; Tom Herbert
> >> <t...@herbertland.com>; int-area <int-area@ietf.org>
> >> Subject: Re: [Int-area] Stateless devices and IP fragmentation
> >>
> >> Ron
> >>
> >> As I noted, SHOULDs always need to explain why they are not MUSTs and
> >> under what conditions they should be excepted... see below...
> >>
> >> Joe
> >>
> >> > On Nov 12, 2018, at 10:35 AM, Ron Bonica <rbon...@juniper.net>
> wrote:
> >> >
> >> > Folks,
> >> >
> >> > It warms my heart to see old friends share a spirited debate ;-)
> >> >
> >> > But what does this mean for draft-ietf-intarea-frag-fragile? The
> >> > draft
> >> observes that some stateless middle boxes behave poorly in the
> >> presence of IP fragments. In order to avoid this situation, the draft
> >> makes the following
> >> recommendations:
> >> >
> >> > 1) Application developers SHOULD NOT develop new applications that
> >> > rely
> >> on IP fragmentation.
> >>
> >> I’d call this protocol developers, not just application developers
> >> (to cover tunnel and security designs too), I.e., anything that goes as
> payload in IP...
> >>
> >> They CAN rely on IP *source* fragmentation when needing to support
> >> direct IP-in-IP tunnels, as for existing protocols such as IPsec
> >> tunnel mode and IP-in- IP encapsulation.
> >>
> >> > 2) Application-layer protocols that depend upon IPv6 fragmentation
> >> SHOULD be updated to break that dependency.
> >>
> >> Same issue...
> >>
> >> > 3) Middle box developers SHOULD implement devices that support IP
> >> fragmentation.
> >>
> >> Here’s the problem - under what cases is an exception warranted?
> >>
> >> AFAICT, Middlebox developers SHOULD support processing of IP
> >> fragments with the same services they support atomic data grams.
> >>
> >> > These boxes SHOULD not fail or cause failures when processing
> >> > fragmented
> >> IP packets.
> >>
> >> Middleboxes SHOULD forward IP fragments without processing if
> >> processing cannot be supported. The MAY drop fragments only when
> >> there are significant indications of an overload condition.
> >>
> >> How’s that? That’s still staying in SHOULD/MAY land as much as possible.
> >>
> >> Joe
> >>
> >> >
> >> > Note the generous application of the word "SHOULD". These are
> >> recommendations, not iron-fisted dictates. If developers heed these
> >> recommendations, they will avoid some amount of pain. However, it is
> >> understood that these recommendations will not be heeded by all.
> >> Hence the word "SHOULD".
> >> >
> >> >
> >> > Ron
> >> >> -----Original Message-----
> >> >> From: Ole Troan <otr...@employees.org>
> >> >> Sent: Monday, November 12, 2018 5:23 AM
> >> >> To: Joe Touch <to...@strayalpha.com>
> >> >> Cc: Tom Herbert <t...@herbertland.com>; Ron Bonica
> >> >> <rbon...@juniper.net>; int-area <int-area@ietf.org>
> >> >> Subject: Re: [Int-area] Stateless devices and IP fragmentation
> >> >>
> >> >>
> >> >>
> >> >>> On 12 Nov 2018, at 11:11, Joe Touch <to...@strayalpha.com>
> wrote:
> >> >>>
> >> >>>
> >> >>>
> >> >>> On Nov 12, 2018, at 1:36 AM, Ole Troan <otr...@employees.org>
> >> wrote:
> >> >>>
> >> >>>>> And none of these update RFC1812.
> >> >>>>>
> >> >>>>> These things can be rolled out in any numbers you like - they
> >> >>>>> are creating
> >> >> the problem that only they can clean up. Killing capability in the
> >> >> rest of the Internet to make these mechanisms work isn’t a viable
> >> >> solution and never has been.
> >> >>>>
> >> >>>> And if that makes the IPv4 Internet die quicker, I’ll take that as a
> feature.
> >> >>>
> >> >>> Sure, as long as your goal is to kill IPv6 too.
> >> >>>
> >> >>> Joe
> >> >>
> >> >> And that’s probably as good an end to this thread as any…
> >> >>
> >> >> Ole
> >
_______________________________________________
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area
