7. Differences from RFC 3697
This document obsoletes RFC 3697 and introduces several important changes to the Flow Label specification. This section summarizes the key differences.
1. Flow Label Distribution Requirement
RFC 3697: Did not specify how source nodes should choose Flow Label values, stating only that the values should be "uniformly distributed."
RFC 6437: Explicitly requires that Flow Label values approximate a discrete uniform distribution and recommends using a pseudo-random function. This change provides clearer guidance for implementers.
2. Stateless vs. Stateful Scenarios
RFC 3697: Did not clearly distinguish between stateless and stateful uses of the Flow Label.
RFC 6437: Clearly separates stateless and stateful scenarios, with the primary focus on stateless operation. This makes it easier for implementers to understand the default behavior.
3. Load Distribution Use Case
RFC 3697: Mentioned load distribution as a possible use case but did not emphasize it.
RFC 6437: Explicitly encourages the use of the Flow Label for load distribution across ECMP and LAG paths. This reflects the primary practical use case that has emerged.
4. Security Considerations
RFC 3697: Stated that the Flow Label "must be delivered unchanged to the destination node(s)" without exceptions.
RFC 6437: Allows the Flow Label to be changed for "compelling operational security reasons" and provides detailed security considerations. This change acknowledges the reality that security requirements may sometimes necessitate modifying or clearing the Flow Label.
5. Source Node Behavior
RFC 3697: Did not provide specific guidance on how source nodes should set the Flow Label.
RFC 6437: Provides clear requirements for source nodes, including the use of pseudo-random functions and the need to set different Flow Labels for different flows.
6. Forwarding Node Behavior
RFC 3697: Stated that forwarding nodes must not change the Flow Label, with no exceptions.
RFC 6437: Maintains this requirement but adds an exception for security reasons, as described in Section 6.1.
7. Hash Function Guidance
RFC 3697: Stated that "the Flow Label bits alone make poor material for a hash key."
RFC 6437: Clarifies that the Flow Label can be used as part of a hash function (not alone) and provides an example hash function in Appendix A.
8. Terminology
RFC 3697: Used the term "immutable" to describe the Flow Label.
RFC 6437: Avoids the term "immutable" because it is misleading (the Flow Label is not cryptographically protected and can be changed).
9. RFC 2205 Correction
RFC 3697: Did not address the interaction with RSVP (RFC 2205).
RFC 6437: Includes an essential correction to RFC 2205 regarding the use of the Flow Label with RSVP.
10. Practical Guidance
RFC 3697: Was primarily a specification document with limited practical guidance.
RFC 6437: Provides more practical guidance for implementers, including specific recommendations for source nodes, forwarding nodes, and security considerations.
Summary of Intent
The changes from RFC 3697 to RFC 6437 are intended to:
- Clarify ambiguities in the original specification
- Encourage practical use of the Flow Label, particularly for load distribution
- Provide implementer guidance on how to generate and use Flow Label values
- Address security concerns in a realistic way
- Reflect operational experience gained since RFC 3697 was published
These changes maintain backward compatibility with RFC 3697 while making the specification more practical and implementable.