Subject: Re: [v6ops] IPv6 MTU Flow-label.... (related to draft-v6ops-pmtud-ecmp-problem-01)

From: Owen DeLong <[email-masked]>
Date: Mon, 1 Dec 2014 13:08:38 -0800

> On Nov 13, 2014, at 4:35 PM, Jeroen Massar <[email-masked]> wrote:
> 
> On 2014-11-14 01:07, Mark ZZZ Smith wrote:
> [..]
> 
>> So I'd argue that protocols shouldn't have to be changed in reaction
>> to lack of proper product design. I wouldn't support using the flow
>> label for this purpose.
> 
> Flow Label cannot work the way that it is defined.
> 
> The reason for having a Flow Label is so that for instance a Load
> Balancer does not have to look further than the first 40 bytes of packet
> (thus just the IPv6 Header).

When you state it as an absolute, the of course:

> 
> But, as every node MUST look at ICMPv6, that is thus automatically false.
> 

Becomes true.

However, this:

> Hence, the Flow Label is useless for the purposes of identifying a flow.

Is not entirely true.

Let’s try restating your absolute in a better way:

The reason for having a Flow Label is so that for instance a Load Balancer does not have to look further than the first 40 bytes of packet (the IPv6 header) in order to make a determination of what to do for packets that are part of the flow, if the flow is cached for fast switching. It does not, however, provide any expedited handling of signaling packets RELATED TO, but NOT PART OF the flow, such as most ICMPv6 messages like PTB.

> Note that an IPv6 'error', thus an ICMPv6 packet, for instance an PTB,
> but also "port unreachable" etc is part of the flow as it indicates an
> error status that relates to that flow.

No, it’s not PART OF the flow… It’s RELATED TO the flow, as you state above.

Think of it like a phone call… The SS7 messages in the PSTN (or the SIP messages in VOIP) are messages about the call and/or the participants in the call that enable the call to occur. However, they are not part of the call. None of the call participants ever hear them. In the case of SS7, they are sent over out-of-band signaling channels, such as the D channels in ISDN. In the case of VOIP, they are sent over SIP while the call itself is delivered via RTP.

> The big problem is that even if the Load Balancer supports parsing the

> ICMPv6 PTB and can associate it with the correct "flow" and thus the
> right backend host, it won't help as there are a lot of other systems
> out there that are on purpose filtering out ICMPv6.

I think fixing the ICMPv6 over-filtering problem is going to be necessary and is likely to occur anyway. I think that isa better solution that providing an in-band signaling hack to fudge PMTU-D instead.

> By including the MTU in the packet though, it won't be filtered (or at
> least set to 1280, which is the minimum which just makes them hurt their
> own performance, but it won't break things).

One could make the argument that by including MTU into the packet, you may introduce the following problems:

	1.	You now have two potentially conflicting sources of MTU information.
	2.	Until this is supported on every router that has interfaces with disparate MTUs, the potential for “interesting” results will persist.
	3.	You virtually guarantee that the incorrect filtering of ICMPv6 will never get solved.
	4.	Routers which modify the header on the fly create interesting problems for AH packets.

There may be other problems, but those are the ones that jump out at me at the moment.

Owen