Hi, all,
Brian reacted privately to the proposed use of flow labels in 4rd.
Since his comments below are IMHO of general interest, here they are with my
own reaction (and with his permission)
2012-06-21 14:18, Brian E Carpenter:
> Rémi,
>
> As I understand it, this flow label value would exist only for
> the portion of the path that is in fact a v4-in-v6 tunnel,
> localised to the ISP infrastructure. That seems OK.
>
> The checksum value will be constant for a given traffic flow. It
> will be somewhat random because that is the nature of a
> checksum. Thus, it seems to me that it will be useful if the ISP
> has any ECMP or LAG in place (RFC 6438).
...
> you could choose to put a 4 bit pseudorandom number in
> the remaining 4 bits, generated by a further stateless hash of
> the IPv4 5-tuple. That would improve the distribution of the
> flow label values, and would be very close to RFC 6437 and 6438,
> if not fully conformant.
Interesting IMHO, with two comments:
- It would be applicable only to a list of L4 protocols known to have ports at
the beginning of IP payloads.
- It could be added as a MAY, to avoid imposing its complexity to all
implementations.
...
> (You can copy this to softwire if useful.)
More opinions from the WG?
Regards,
RD
> On 2012-06-19 08:36, Rémi Després wrote:
>> Hi, Brian,
>>
>> In the still progressing 4rd design, flow labels happen to be
>> a convenient tool to maintain, after 4rd domain traversal,
>> IPv4-like protection of addresses and protocol. For this,
>> each tunnel packet has an address-and-protocol checksum set
>> in its FL.
>>
>> This is understood to be compatible with RFC6437 because:
>>
>> a) RFC6437 says "A node that forwards a flow whose flow label
>> value in arriving packets is zero MAY change the flow label
>> value. In that case, it is RECOMMENDED that the forwarding
>> node sets the flow label field for a flow to a uniformly
>> distributed value as just described for source nodes. ... In
>> such cases, a flow can be defined by fewer IPv6 header
>> fields, typically using only the 2-tuple {dest addr, source
>> addr}."
>>
>> b) In CEs and BRs, arriving packets are IPv4, i.e. equivalent
>> to packets without FLs.
>>
>> c) In RFC2119, "RECOMMENDED" means that "there may exist
>> valid reasons in particular circumstances to ignore a
>> particular item, but the full implications must be understood
>> and carefully weighed before choosing a different course".
>>
>> d) Implications, which are are well understood, are also well
>> weighted (5-tuple flows aren't distinguished, which isn't
>> recommended, but this is to maintain IPv4 addresses-and-port
>> protection without extra header between IPv6 header and IP
>> payload).
>>
>>
>> Is this for you a correct interpretation?
>>
>> Thanks, RD
>>
>
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
