Thomas, Christian,
I'm responding to both of you in a single message, since you both expressed
concern with choice 2, (locally-defined use of flow-labels), particularly in
the face of IPSec.
Let's first look at the situation as it stands today. Today, if hosts or IPSec
GW's sent IPSec ESP packets, then routers will not be able to find any
Transport layer information anyway to be used as input-keys for LAG or ECMP
hash operations. Thus, they would revert to IP source and destination address
/only/ as input-keys to LAG or ECMP hash operations. While that's slightly
better than better than nothing, there's definitely a higher risk of congesting
a particular component-link inside a LAG or ECMP path, (as opposed to
clear-text packets where Transport layer information is available and is used
as input-keys for LAG + ECMP calculations). In summary, if Transport layer
information is unavailable to intermediate routers to extract and create a
flow-label from (i.e.: locally defined use case), the load-balancing behavior
is _no worse_ than it would be on today's network.[1]
Second, IPSec constitutes a very, very small fraction of the overall Internet
traffic today and I personally don't see that changing in the near future. So,
IMHO, IPSec is more accurately a "corner case".
I would also note that even if IPSec hosts wanted to encode a non-zero
flow-label, (from the inner packet's 5-tuple), administrators of those hosts
MAY NOT want to, because it would be less information in the outer packet
header that, to some extent, would prevent traffic analysis at intermediate
nodes.
Let me try to put things back into a proper perspective wrt the need for a
locally-defined flow-label:
1) We _need_ a meaningful flow-label so that Core routers, with several dozen
100G interfaces, /DO NOT/ have to traverse IPv6 Extension Headers (some of
which could be unknown!) to hope to find Transport-layer information (protocol,
src port, destination port) in order to extract all those input-keys to use
them for LAG and ECMP hash calculations. I would note that all of my routers
today are using a 5-tuple in IPv4 for input-keys for LAG & ECMP, which are
pretty straightforward for Core routers to extract given they have known
offsets in the IP header.
2) On the edge of the network, i.e.: PE's, they need to be capable of looking
at Transport-layer information in order to perform classification of incoming
packets for a variety of reasons:
a) Classify traffic based on IP src, dst address and/or _protocol, src
port or dst port_ in order to drop packets for a DoS attack, for example;
b) Classify traffic based on similar 5-tuple information in order to
rate-limit it -or- apply a specific IP Traffic Class value in the header.
3) The flow-label isn't "protected" in the IPv6 header by a checksum or
anything else (to my knowledge). IOW, a man-in-the-middle attack or
misconfiguration in a 3rd-party host or network could scribble a bad value in
flow-labels that leads Core routers (if they were using flow-labels as
input-keys) to potentially re-order packets or congest component-links in a LAG
or ECMP path. So, as an operator, I'm not sure I want to "blindly" trust
flow-labels even if hosts _were_ setting them to a pseudo-random value.
Furthermore, as an operator, I have no control over how good a hash over, say,
the 5-tuple every host will use to create a "good" flow-label that will
maximize the probability of distributing a flow over very wide component-links
contained in LAG or ECMP paths in my network.
In summary, I'm not sure the incentives of the host vendor's in creating "good"
flow-labels are properly aligned with those of the SP's ... thus, as an
operator, it seems prudent to take more control over my destiny by being able
to set the flow-labels at ingress to my domain boundaries.
-shane
> On May 7, 2010, at 07:49 MDT, Christian Huitema wrote:
>
> I agree with Joel, in great part because of the IPSEC issue that Thomas
> mentions. Final payload and ports can be easily obfuscated behind chains of
> headers, or encrypted in IPSEC. Specifying that the flow label SHOULD be set
> to hash of specified values would lead to greater inter-operability.
On May 7, 2010, at 06:55 MDT, Thomas Narten wrote:
> I haven't decided yet whether I can support choice 2.
>
> However, should choice 2 be used, what is the recommendation when
> IPsec is in use? The recommendation assumes access to port numbers and
> the like, which are hidden when IPsec is in use.
>
> This is particularly important when a packet exits one FL Domain and
> enters a new one, and the recommendation is "throw out the FL and
> figure out a new value to use".
>
> Thomas
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
