(Sorry, I messed up the subject of this thread by including "DRAFT")
On 2010-04-23 07:30, Shane Amante wrote:
<snip>
> I completely agree that this is a challenging problem;
> however, I see a few ways of potentially dealing with it:
a)
> Restoral of domain-specific flow-label values, (your
> proposal), at egress from an administratively defined domain
> -- which I find might be impractical to implement; or,
There are ways to do this, but they are complex and
IMHO undesirable.
b)
> Declare that the flow-label is _mutable_ by each
> administrative domain. Therefore, I _MAY_ not trust an
> incoming IPv6 flow-label from another administrative domain.
> However, in thinking about this a bit more, this has problems
> of it's own, namely: a) the dependency of intermediate
> routers to (re)calculate a "good" flow-label based off the 3-
> or 5-tuple in the IPv6 header (possible, but not guaranteed);
> and, b) it could unintentionally overwrite "good"
> flow-labels, particularly those of inter-domain IP-in-IPv6
> tunnels (cf: draft-carpenter-flow-ecmp), where the outer IPv6
> header may have a "good" flow-label based on the inner IP
> header's 5-tuple -- which is bad.
However, consider that the flow label is a forgeable field, not
protected by any checksum (including IPSEC). So you can't trust
it and an attacker could always attack your ECMP or LAG by
giving all packets the same label. It may be that the only safe
way is to recalculate the label at a trusted border. (Good luck
doing that at 100 Gb/s.)
So maybe mutability is in fact the only way to make it safe to
use across domain boundaries?
c) Declare the flow-label
> is _immutable_ and must be set by all hosts and must only
> contain a 3- or 5-tuple hash of the appropriate IPv6 headers.
> Further use cases for the flow-label would be restricted.
> IMHO, this would be by far the easiest from an implementation
> and operational point-of-view, however this is unlikely to
> appeal to proponents of domain-specific special-uses of
> flow-labels, unfortunately.
True, and it's also the current standard, which as far as I
know is not being used.
>
> FWIW, related to the last point, (and as I'm sure you're well
> aware of), I'd also add that we're well beyond the alpha and
> beta stages of IPv6 deployment and well into mad deployment
> phase of IPv6 to mitigate IPv4 address exhaustion.
> Therefore, if a legitimate use of flow-labels has not been
> found in the last 15 years of IPv6 development, it's time to
> move on and use the flow-label for something useful and
> practical in production networks, (i.e.: a hash of the 3- or
> 5-tuple of L3 + L4 headers for LAG + ECMP load-balancing).
Oh yes, we certainly need to enable that, but it doesn't need
any change in the current standards. It's a product issue.
Brian
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
