On 04/16/2017 05:15 PM, Matthias Schiffer wrote: > On 04/14/2017 07:38 PM, Stephen Hemminger wrote: >> On Fri, 14 Apr 2017 18:44:46 +0200 >> Matthias Schiffer <mschif...@universe-factory.net> wrote: >> >>> As link-local addresses are only valid for a single interface, we can allow >>> to use the same VNI for multiple independent VXLANs, as long as the used >>> interfaces are distinct. This way, VXLANs can always be used as a drop-in >>> replacement for VLANs with greater ID space. >>> >>> This also extends VNI lookup to respect the ifindex when link-local IPv6 >>> addresses are used, so using the same VNI on multiple interfaces can >>> actually work. >>> >>> Signed-off-by: Matthias Schiffer <mschif...@universe-factory.net> >> >> Why does this have to be IPv6 specific? > > I'm not familar with IPv4 link-local addresses and how route lookup works > for them. vxlan_get_route() sets flowi4_oif to the outgoing interface; does > __ip_route_output_key_hash() do the right thing for link-local addresses > when such addresses are used on multiple interfaces? I see some special > casing for multicast destinations, but none for link-local ones. >
Getting back to this (sorry for the delay, I got caught up in other projects), I'm seeing the following pros and cons regarding the support of VXLAN over IPv4 link-local addresses: + There should be no technical reason not to support it; as everything is in the kernel, the usual problems with IPv4 LL (userspace APIs not supporting passing a scope ID as part of the IP address) don't apply here + The code needed to support IPv4 LL should be easy to add - IPv4 LL semantics aren't as well-defined as for IPv6. While IPv4 LL addresses are usually in the 169.254.x.y range, the Linux kernel allows setting the address scope independently of the range for IPv4. In contrast to this, we need to judge the validity of the configuration based on syntactic properties of the IP addresses (at least if we don't want to add a lot of more compexity to the validation, and probably other parts of the code.) Generally, code that checks for the 169.254.x.y range is uncommon in the kernel (I think I only found a single instance, somewhere in the SCTP implementation.) - IPv4 LL addresses are mostly used for zeroconf; I don't really see a usecase for zeroconf addresses + VXLANs - Personally, I have no interest in IPv4 I probably forgot a few more arguments... All in all, I'd like the VXLAN maintainers to decide if we do want IPv4 LL support or not, and if the verdict is to support it, I'll implement it in the next revision of my patchset. Matthias
signature.asc
Description: OpenPGP digital signature
