Hi Fernando, Thanks for the fast reaction. More below.
Le 9 sept. 2010 à 20:31, Fernando Gont a écrit : > Hi, Remi, > >> Draft-gont-6man-flowlabel-security is based on the assumption that FL >> values are set as currently specified in RFC 3697, i.e. with a >> *stateful* algorithm that needs to keep track of flow establishments >> and terminations, and with FL immutability. > > Note: the only additional "state" in the algorithm is the counter. > > As for keeping track of flows, as I've just noted to Steven, this is a > refinement. But you could probably live assuming that all flows > terminate in a period equal to the duration of the flow label space > (i.e., when the flowlabel space wraps and you'd reuse a flowlabel value, > the flow that was previously using that FL value has already terminated) > > While I've assumed that RFC3697 holds when wrote draft-gont, FL > immutability is not a requirement for the algorithm to work. Note that my proposal doesn't exclude stateful algorithms (no objection to yours in particular). It just authorizes stateless algorithms provided they are adequate for the load-balancing purpose. > >> The best combination I personally get, considering past discussions >> on a potential RFC-3697 revision, is so far as follows: >> >> R1. Packet sources SHOULD set FLs to non-zero values that generally >> differ from a flow to another (e.g. with currently specified stateful >> algorithms, or with n-tuple hashes). >> >> R2. Packet sources MUST set FLs to zero otherwise. >> >> R3. Intermediate nodes MAY replace null FL values by non-zero FL >> values, PROVIDED these non-zero values generally differ from a flow >> to another. >> >> R4. Intermediate nodes MAY replace non-zero FL values by non-zero FL >> values, PROVIDED these non-zero values generally differ from a flow >> to another. >> >> R5. Intermediate nodes MAY replace non-zero FL values by null values >> ONLY IF found necessary for some identified policy-dependent security >> reason (e.g. in some managed firewalls). > > I'd make R3 through R5 a "SHOULD NOT.... but if you do, do it this way". > -- but could certainly with your "MAY", as stated. About R3: If part of a network has the ability to identify 5-tuples and to compute FLs, replacing null FLs by non-zero FLs seems to me a completely acceptable choice. About R4: If part of a network has the ability to identify 5-tuples and to compute good FLs, and has no confidence in upstream provided FLs, I see no objection to its replacing old FLs by supposedly better ones for its own load balancing (and, by the same token, for that of downstream networks that use upstream FLs). About R5: I agree that SHOULD NOT would be better, with no objection to adding "unless found strictly necessary..." >> R6. Nodes that tunnel flow aggregates SHOULD replicate non-zero FLs >> encapsulated packets in encapsulating packets. >> >> R7. Nodes that tunnel flow aggregates SHOULD set FLs of encapsulating >> packets that contain null FLs to a value that characterize the tunnel >> itself, and MUST set it to 0 otherwise. > > Will give these last two another thought. Look forward to it. > > Thanks! > -- > Fernando Gont > e-mail: ferna...@gont.com.ar || fg...@acm.org > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 > > > > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
