> On Jul 13, 2017, at 1:29 PM, Joe Touch <[email protected]> wrote: > > > > On 7/13/2017 1:23 PM, Dan Wing wrote: >>> On Jul 13, 2017, at 12:59 PM, Joe Touch <[email protected]> wrote: >>> >>> >>> >>> On 7/13/2017 12:39 PM, Dan Wing wrote: >>>>> On Jul 13, 2017, at 6:52 AM, Joe Touch <[email protected]> wrote: >>>>> >>>>> FWIW, why not just add the entropy in the IPv6 flow ID rather than >>>>> expecting it at the transport layer? Intermediate network devices should >>>>> be relying only on the flow ID for that entropy anyway. >>>> I don't know if IPv6 routers do ECMP using flow ID, and I don't know if >>>> physical NICs do RSS CPU load balancing based on IPv6 flow ID. >>> I don't either, but *if* they (either one) does, they really should. >>> >>> RFC 6438 discusses this issue and implies that flow ID isn't used >>> because it's mostly zero, but I wouldn't be surprised if that were to >>> change over time. >>> >>>>> (and yes, that doesn't solve the problem for IPv4, but perhaps that's a >>>>> good reason to encourage use of IPv6) >>>> Yeah, for v4 we're stuck with using source UDP port to provide the ECMP >>>> and receiver benefit. >>>> >>>> >>>> What of NAT64? >>> Sure, that'd help, except we'd have to expect that an IPv4 router would >>> know to jump into the IPv6 flow ID to do ECMP. That seems more of a >>> stretch than the above, IMO. >> Sorry, I wasn't clear. I'm not worried of the NAT64 device itself, but >> rather the IPv4 network beyond the NAT64, should we use IPv6 flow-id as >> proposed. >> >> If there are different ways of expressing ECMP and RSS (receiver side >> scaling) for IPv6 versus IPv4, my worry is what a NAT64 is supposed to do >> with the IPv6 packet (containing a flow-id) it translates to IPv4. If >> traffic from IPv6 is using Flow-ID to provide ECMP and RSS and it hits a >> NAT64, is the NAT64 now needing to do NAPT64 (port translation) in an >> attempt to provide some Flow-ID-like functionality to the source UDP port >> number? > Well, you're translating for a more capable protocol to a less-capable > one. Losing information is part of that game. > > There's no way to do NAT64 translation without losing some of the info > in the IPv6 header, period. > > It MIGHT try to use the flow ID to guide source UDP port generation, but > that assumes there's a UDP header to play with in addition to the IPv4 > header. That's not NAT64 anymore.
Yeah, well, then there is IPv6's UDP checksum versus IPv4's. :-) >> If so, that's new for NAT64, and can't work with stateless translation (IVI >> and related techniques). If not, the IPv4 network suffers (no ECMP) and >> receiver suffers (because no RSS) because the sender was on IPv6 and the >> sender used flow-id. In the other direction, IPv4 to IPv6, it seems easy >> for the NAT64 (stateless or stateful) to copy the UDP source port number >> into the IPv6 flow-id field, or do a cute 20-bit hash of the IPv4 5-tuple, >> or whatever. If we spec'd that, NAT64 in the IPv4->IPv6 direction would >> align with RFC6438 and provide more ergs to IPv6 flow-id. >> >> However, I remain troubled by the IPv6->IPv4 direction with NAT64, should we >> use only Flow-ID on the IPv6 side. > > I don't think we should try to lobotomize an elegant IPv6 solution "just > in case" it hits NAT64. IPv6 flow-id is only elegant if, on a v6 network, it provides us same ECMP and RSS benefits as UDP source port. We haven't concluded we get (or don't get) ECMP and RSS yet. > IMO, that's NAT64's problem to deal with (or not). I could envision a knob that if the encapsulated traffic is traversing a NAT64, then it could use the in-elegant solution (UDP source port number) *and* the IPv6 flow-ID. An SDN controller could (or should) know if the traffic will traverse a NAT64. If the encapsulated traffic remains on v6 (and flow-ID gives us ECMP and gives us RSS), then it could avoid putting flow entropy into the UDP source port. -d _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
