Re: [Int-area] Comments on draft-ietf-intarea-frag-fragile-06

[Tom Herbert <[e-mail]>]

On Tue, Jan 29, 2019 at 3:37 PM Fred Baker <[e-mail]> wrote:
>
>
>
> > On Jan 29, 2019, at 11:45 AM, Tom Herbert <[e-mail]> wrote:
> >
> > Hello,
> >
> > I have suggested text for the draft to address some previous comments
> > made on the list.
> >
> > Last paragraph in section 4.3:
> >
> > "This problem does not occur in stateful firewalls or Network Address
> > Translation (NAT) devices. Such devices maintain state so that they
> > can afford identical treatment to each fragment that belongs to a
> > packet.
>
> Do we have a list of such products? I'm unaware of one. Making a blanket statement such as this troubles me, because it seems to say that this is invariably true, and I don't know that it is or isn't.
>
> > Note, however, that stateful firewalls and NAT devices impose
> > the external requirement that all packets of a flow and fragments of a
> > packets for a flow must traverse the same stateful device; stateless
> > devices do not force this requirement."
>
> Here's an example of why blanket statements need to be qualified. If you take NPTv6 to be a form of NAT, it doesn't force route symmetry.
>
Fred,

Yes, but the statement is in the context of stateful NATs. I agree
that this section is murky, but I believe that's because it referring
to non-standard behaviors. It would be so much easier if we could just
reference the specification that says how stateful intermediate
devices are supposed to work.

> > Section 4.5:
> > "IP fragmentation causes problems for some routers that support Equal
> > Cost Multipath (ECMP). Many routers that support ECMP execute the
> > algorithm described in Section 4.4 in order to perform flow based
> > forwarding;
>
> As far as I know, routers that hash fields in the IP header to select a en ECMP next hop do so because all packets in a flow will hash the same way (modulo the issues with the transport port number), not because they are doing per-flow forwarding. The do so explicitly to avoid having to maintain per-flow state and yet make all fragments of a message follow the same path.

That's true for IPv4,the only way to do stateless ECMP and have
fragments follow the same path as non-fragments is to hash over the IP
addresses only. For IPv6 we can do better. The flow label allows finer
grained per-flow routing, but still only requires inspection of IP
header so keeping fragments in order just works.

Tom

>
> > therefore, the exhibit they same problematic behaviors
> > described in Section 4.4. In IPv6, the flow label may alternatively
> > used as input to the algorithm as opposed to parsing the transport
> > layer of packets to discern port numbers. The flow label should be
> > consistently set for a packets of flow including fragments, such that
> > a device does not need to parse packets beyond the IP header for the
> > purposes of ECMP."
> >
> > Add to section 7.3:
> >
> > "Routers SHOULD use IPv6 flow label for ECMP routing as described in [RFC6438]."
> >
> > _______________________________________________
> > Int-area mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/int-area
>
> --------------------------------------------------------------------------------
> Victorious warriors win first and then go to war,
> Defeated warriors go to war first and then seek to win.
>      Sun Tzu
>