Date: Mon, 26 Apr 2021 12:50:06 -0700 (PDT) From: "Rodney W. Grimes" <freebsd-rwg@gndrsh.dnsmgr.net> To: Zhenlei Huang <zlei.huang@gmail.com> Cc: "Rodney W. Grimes" <freebsd-rwg@gndrsh.dnsmgr.net>, freebsd-hackers@freebsd.org Subject: Re: Fwd: Are there any RFCs for address selection for IPv4 Message-ID: <202104261950.13QJo623099257@gndrsh.dnsmgr.net> In-Reply-To: <937C7998-7689-4D27-88B4-96C53F0E6F97@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > Begin forwarded message: > > > > From: "Rodney W. Grimes" <freebsd-rwg@gndrsh.dnsmgr.net> > > Subject: Re: Are there any RFCs for address selection for IPv4 > > Date: April 26, 2021 at 10:01:07 PM GMT+8 > > To: Zhenlei Huang <zlei.huang@gmail.com> > > Cc: "Rodney W. Grimes" <freebsd-rwg@gndrsh.dnsmgr.net>, freebsd-hackers@freebsd.org > > > >> Hi Rod Grimes, > >> > >> > >>> On Apr 25, 2021, at 9:40 PM, Rodney W. Grimes <freebsd-rwg@gndrsh.dnsmgr.net> wrote: > >>> > >>>> Hello hackers, > >>>> > >>>> For IPv6 there's RFC 6724 to clarify the default address selection procedure, > >>>> both for source address selection and destination address selection. Are there > >>>> any RFCs like RFC 6724 that are for IPv4? > >>> > >>> The important difference I think here is that in IPv6 it is very normal to > >>> have both a link local and a routable IP address on an interface. RFC 3927 > >>> speaks to this for IPv4 with: > >>> IPv4 Link-Local addresses are not suitable for communication with > >>> devices not directly connected to the same physical (or logical) > >>> link, and are only used where stable, routable addresses are not > >>> available (such as on ad hoc or isolated networks). This document > >>> does not recommend that IPv4 Link-Local addresses and routable > >>> addresses be configured simultaneously on the same interface. > >>> > >>> Though technically you have not put a global uniq unicast address on the > >>> outbound interface the fact your trying to route one via that interface > >>> to a loopback interface puts you into the situation your attempting > >>> to route global IP over a link local address. > >>>> > >>>> I'm exploring RFC 3927, consider this situation, a host configured with link-local > >>>> address on NIC and global unicast alias address on loopback interface, and default route to > >>>> the link-local address of router (some ISPs do this). The current implementation kernel > >>>> will use the link-local address as the source address when initializing a connection to > >>>> remote host via the default route. It seems wrong, as link-local address are not > >>>> routable as per RFC 3927. > >>> > >>> So your wanting the kernel to pick a source address on another interface > >>> for a packet going out a different interface, that is what seems wrong. > >> > >> I'm not sure if this is proper for IPv4, but in the IPv6 network stack, FreeBSD's > >> current implementation select global unicast address over link-local address, in case > >> the outgoing interface does not have any global unicast addresses. > >> I'm wondering whether it makes sense also for IPv4. > > > > This is due to the fact that IPv6 is specified to have this type of > > behavior. In v6 we have the idea of scope, that does not exist in > > the v4 world, or at least at this time it does not. RFC3927 3.2 does > > discuss the idea of scope and v4. > > I have got noticed the limitation of the current implementation of IPv4 scope. > Basically it confuses to have two or more interfaces all configured with LL addresses. Yes, as the expectation in IPv4 is that a subnet is generally only reachable on one interface and from one address and that all host on a subnet are rechable from any interface on that subnet, which does not work with the ipv4 LL logic as it is today. > > > >>> > >>> Though I think this could be solved by applying a technique used in > >>> routers, and that is the concept of a host specific globally routeable > >>> IP address that should be used for all non-local packets. This is useful > >>> in complex multipath networks as the router is always accessable via > >>> that IP address no mater which interfaces are routing packets correctly > >>> as long as the routing protocols are maintaining a path to it. > >>> > >>> But before going down that road, why are you putting your desired globally > >>> routeable IP address on lo0 and not on the upstream interface which would > >>> eliminate this problem? Is it because you have a complex multipath network, > >>> or is it from an attempt to save some global IP's that would be needed > >>> to run these on the link? Or? > >>> > >> > >> Reading RFC 3927 2.7, it states link-local addresses are not routable. The router shall > >> discard those packets from or to link-local addresses. Then it make no sense for a host > >> to select link-local address as source address when it initialize a connection, except for > >> an edge case that the destination is also link-local address. > > > > In my reply to Poul Henning I wrote that allowing a ipv4 LL address > > as a next hop may be a violation of RFC, and is the root cause of > > this address selection process. > > For route I think it is valid to have a LL as next-hop. In the routing world the next-hop would > be 'translated' to layer 2 address, regardless the mean, ARP or NDP. Poul correcting me, and I agree, my statment was rushed and wrong. > I'm recently working on > a feature to make FreeBSD's IPv4 route have IPv6 address as next-hop based on > Alexander V. Chernikov 's work, and it works so far so good except the default source > address selection. The related RFC is RFC 5549 . Ok. I think it might help to split this problem space over that which exists for a "host" and that which exists for a "multi-homed host", and that which exists for a "router". The host I would say just put the globally routable IP on the upstream interface and your done. For the multi-homed host there needs to be a way to specify that some v4 IP is that hosts globally reachable IP and should be used as the source when the current logic only finds a LL v4 address. This same logic should work for a router, but may not be desireable for some reason. > > > > > It wont fix your issue, as once you remove that route your host > > wont be able to send anything but link local packets. I am still > > unclear why your putting your IP address on lo0 and attempting/expecting > > that address to route over a link that is only configured with LL > > addresses. > > By putting routable IP address to lo0 is just an example. For routers there may be > routable IP addresses on other interface. I'm not able to completely explain the > motivation for such kind of config, but > if it is valid to have a LL as next-hop, then it is OK for a router / host to have one > interface with only LL address and also have other routable IP addresses on other > interfaces. But there is no guarantee that you can use those routeable IP addresses on the other interfaces as source addresses on a LL interface only. I now understand your problem space better, and I think the simplest solution is to have a way to say "this IP address" is my globally reachable IP address (it needs to be an address on SOME interface.) And this globally reachable IP address should be used for a NON local packet source address when the current logic would of ended at the LL selection. You often have such IP addresses when you configure full mesh multi-hop iBGP that are injected into OSPF or other interior protocol and thus are reachable via interface addresses. This address is often configured on a loopback device, and exported into the interior protocol. > >>>> So it is important if there's corresponding RFC clarify the source address selection > >>>> for IPv4. > >>> > >>> I do not believe you well find anything that speaks to this issue for IPv4, as > >>> your not really in the situation of RFC6724 which has to do with multiple IP > >>> addresses on the same interface. > >>> > >>>> Thanks :) > >>> Rod Grimes rgrimes@freebsd.org > >> Zhenlei Huang > > Rod Grimes rgrimes@freebsd.org <mailto:rgrimes@freebsd.org> > Zhenlei Huang -- Rod Grimes rgrimes@freebsd.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?202104261950.13QJo623099257>