Firstly, when we were developing RFC 3697, we were told very forcefully by the WG to remove use cases from the draft and simply to define generic "boundary" semantics. I think exactly the same should apply to this draft, so all the references to 6LSA should be removed. Then we'll be able to see more clearly what is actually proposed and whether it will satisfy other use cases.
Secondly, I think section 3 completely misrepresents RFC 3697. For that reason I will only comment here on section 3.
- The static allocation of Flow Labels defining fixed, end-to-end flows in large networks is unwieldy at best. If the specification had allowed for dynamic allocation of Flow Labels as flows were set up and torn down
But it does. The allocation of flows is as dynamic (or as static) as the sending host wants to make it.
(or progressed over multiple hops), the network administrators and/or users would have had the latitude to use one or more labels (in the same flows) - as and when necessary and for different purposes.
A flow, in 3697, is nothing more nor less than the set of packets that a sending host chooses to label with the same flow label. I could define every 3rd packet of a TCP session as a flow if I wanted to. Implementors have complete latitude.
The static characteristic of the Flow Label allocation end-to-end and its 3-tuple association with source and destination addresses (which are also static end-to-end) renders the view that the Flow Label is there to extend the address space into the Flow Label field.
It isn't static. (Neither will addresses be, once shim6 is defined and deployed). It is end to end (see below for why). It certainly isn't an address space extension - it is quite compatible with 3697 to use the same flow label with different address pairs; it is quite compatible with 3697 for the nodes to agree on some extra rules about flow label assignment. All 3697 says is that the 3-tuple MUST be unique.
Conversely, one could use the source and destination addresses in conjunction with the Traffic Class field to provide the same services without using the Flow Label at all.
Not at all. The flow label semantics are e2e and the Traffic Class semantics are domain specific. They are in no sense equivalent.
There is no need for a separate static 20-bit field, that has to be used end-to-end, on top of the 256 bits of address space to identify a flow.
An address pair doesn't identify a flow, especially when the rest of the header is hidden by encryption.
- Specific flow state establishment methods and the related service models are out of scope in the current label specification [1].
Yes, that was very specific guidance from the WG.
Devoid of a methodology for establishing a flow or for provisioning services using established flows meant the Flow Label specification is incomplete
The WG wanted boundary semantics. They didn't want that confused with use cases.
and possibly inadequate toward providing implementation and deployment direction for efficient use of the label.
Boundary semantics, by definition, can't be "inadequate" in the strict English sense of the word. If it means "wrong" that's a different matter, but has to be justified.
- As the Flow Label field carries a static, fixed label generated by a source host, for a flow to receive requested treatment in the network, a signaling protocol such as the Label Distribution Protocol (LDP) (used in MPLS) or Resource Reservation Protocol (RSVP) must be used to distribute the label binding (packet classification) information (for this source-based packet classification) to all other nodes in the network.
That is not required. The text assumes a use case that requires other nodes to have dynamic prior knowledge of the labels in use. There are uses cases (soft-state load sharing for example) that certainly don't.
The current Flow Label specification [1] does not provide any mechanism for propagating label binding information into the network which makes the current Flow Label specification difficult to implement.
As noted, that was specifically missed out to follow the WG's guidance, and is not needed in all use cases.
- To ensure that flows can be identified uniquely in the network, the 3-tuple of Flow Label, Source and Destination addresses is used to define a flow. Given the large address field used by the IPv6 protocol, the memory requirements for maintaining a flow state that includes two 128-bit addresses and a 20-bit Flow Label (for a total of 276 bits) can be significant when tens of thousands of flows are in operation in a network node. Moreover, the operations used for flow look-ups may also be processing intensive involving multiple memory fetches per flow in 32-bit or 64-bit machines. This is not desirable for small or portable devices with limited memory and processing power.
This is correct to some extent, but since the Internet is largely stateless, there isn't really any other option at the level of the boundary semantics. As noted above, a specific use case can very well add its own signaling mechanism to arrange for whatever stronger uniqueness semantics it needs. And of course the lookup problem is susceptible to hash optimization.
- In IPv6 packets that must traverse errorùprone or unreliable links, errors may inadvertently change the Flow Label bits. As the static Flow Label is to be used end-to-end, the errors may result in flows that can not be matched to any flow (packet) treatment profile. The current specification of Flow Label does not address how errored packets need to be handled or if they can be processed at all in the error-prone links.
Yes, perhaps it should state that they should be handled as default. In fact 3697 section 2 says
"If an IPv6 node is not providing flow-specific treatment, it MUST ignore the field when receiving or forwarding a packet"
which could be read to include the case of an unknown flow label. But we would expect level 2 error detection to discard such a packet anyway.
Furthermore, errored packets in TCP streams will fail checksums at the destination host resulting in unnecessary retransmissions
They aren't in the least unnecessary. They are very necessary.
and possible congestion.
Congestion?? TCP retransmission tends to have the opposite effect, because it resets the window.
(On the other hand, flexible Flow Label as proposed in this document only has local significance and as such has limited vulnerability.)
This is bogus. An errored packet is discarded at level 2 anyway.
- The fixed label MUST be delivered unchanged to the destination nodes; this even applies to the zero Flow Label which is used for labeling packets that are not part of any flow (for nodes that do not support Flow Label based flows). It is not clear how this requirement contributes any useful functionality.
This was thoroughly debated in the WG, but the short answer is that it allows the two ends to agree on (for example) a flow-based load sharing mechanism; and it allows for flow state, if supported, to be implemented consistently. As far as I recall, the IETF decided against a label-switching usage of the flow label in 1994 when the CATNIP proposal was dropped, and decided against it again when 3697 was debated - and both times the feeling was for an e2e flow label.
This constitutes an ideal mechanism for man-in-the-middle attacks. What is needed to derail an end-to-end statically defined flow is to simply insert all zeroes in
I wish the text didn't keep repeating the false assertion that 3697 flows are statically defined. As noted above, they are as dynamic as the sending host wants them to be.
the Flow Label field thus making the flow a 'non-flow'. The flow
meant for QoS delivery becomes meaningless
QOS may not be the only use case, although it may be common.
and could potentially be harmful to a mission.
Indeed. There are other fields (addresses and traffic class for example) that a MITM can change with amusing results. If that is a threat, the operator needs to protect Level 2.
- Scalability is another issue with the static, fixed Flow Label
They are not static or fixed.
assignment. Static assignments are not considered by their very nature scalable. For instance, the projected depletion of the fixed address space in IPv4 has resulted in the adoption of IPv6 (for its huge address space). Flexibility in the assignment of values to a bit field as and when needed is considered in general a good idea. This is true for the Flow Label as well.
Indeed. That's why we have 20 bits and the broad 3-tuple uniqueness requirement. We won't run out unless a sending host needs more than ( 2**20 -1 ) flows to the same destination within two minutes. I don't think there's a scaling problem.
To summarize, the current IPv6 Flow Label is little used; its current
Yes, because we took 10 years to define its boundary semantics, so nobody knew what to implement before they shipped product.
specification is confusing.
I see nothing confusing.
Absent an associated mechanism for label binding distribution, the specification provides little in way of functionalities for the IPv6 protocol.
That was entirely intentional.
Its application in providing flow based QoS has not been defined,
And we are waiting for use cases to be defined *within* the semantics of RFC 3697. Flow based QOS could be one of those use cases.
its implementation by network devices may prove to be expensive and may introduce issues concerning proper use of the available resources.
Or may not.
Its use in the error-prone media is questionable. It is vulnerable to the man-in-the-middle attacks.
See above comment on the need to protect Level 2 in any case.
Finally, the current specification is too restrictive to allow its wide-spread use;
It isn't restrictive; it's actually very permissive except for the e2e immutability.
the static allocation of the Flow Label raises
It isn't static.
questions regarding its scalability.
It is scaleable.
It is safe to assume that emerging applications will find it difficult to take advantage of the current Flow Label specification.
This is true, until we get some use cases specified within the boundary set by RFC 3697. When I last heard from the 6LSA authors, that is what I understood they were going to do.
Brian
-------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
