Are there any RFCs for address selection for IPv4

On Sun, 25 Apr 2021 18:20:37 +0800

Post by Zhenlei Huang
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?
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 it is important if there's corresponding RFC clarify the source address selection
for IPv4.
Thanks :)

I'm no expert on this, but the router must have a public, routable adress
to the internet, otherwise it can't function as a router. This address
is (usually) provided by the ISP.

It's using its pubic address to route packets to the internet and very
probably NAT to handle packets from and to the LAN.

So, the internal LAN does not have to use routable addresses.

--
Gary Jennejohn

Rodney W. Grimes

2021-04-25 13:40:45 UTC

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.

Post by Zhenlei Huang
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.

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?

Post by Zhenlei Huang
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.

Post by Zhenlei Huang
Thanks :)
_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers

--
Rod Grimes ***@freebsd.org

Zhenlei Huang

2021-04-25 16:07:03 UTC

Hi Rod Grimes,

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
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.

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.

Post by Rodney W. Grimes
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.

Post by Zhenlei Huang
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.

Post by Zhenlei Huang
Thanks :)
_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers

Thanks,
Zhenlei Huang

Poul-Henning Kamp

2021-04-25 17:56:01 UTC

--------

Post by Zhenlei Huang
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.

As I understand it, it only makes sense let the kernel select a LL address under two
conditions:

A) The destination is also LL *or* multicast

B) There is only one "UP" interfaces with an LLA.

Implementing the second criteria runs into us putting a (IPv6)LL
on the loopback interface.

Does anybody know why we put a (ipv6)LL on loopback interfaces ?

--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
***@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

Rodney W. Grimes

2021-04-26 13:50:10 UTC

Post by Poul-Henning Kamp

As I understand it, it only makes sense let the kernel select a LL address under two

I take it you mean for IPv4 only?

Post by Poul-Henning Kamp
A) The destination is also LL *or* multicast

Agree, this is pretty clear from specs.

Post by Poul-Henning Kamp
B) There is only one "UP" interfaces with an LLA.

This I am not clear on. RFC 3927 does bring up some of the
problems, and possible solutions, for a multihomed situation
with LL addresses. Section 3.2

Post by Poul-Henning Kamp
Implementing the second criteria runs into us putting a (IPv6)LL
on the loopback interface.

Huh? We already do that.

Post by Poul-Henning Kamp
Does anybody know why we put a (ipv6)LL on loopback interfaces ?

I believe someplace in the bowls of all the IPv6 specs this
is a requirement. I could not find it quickly though.

Question: Should we allow a route to have a next hop of a LL(ipv4)?
Reason: RFC3927 2.6.2:
The host MUST NOT send a packet with an IPv4 Link-Local destination
address to any router for forwarding.

So, arguably, it is a violation to allow the default route to have
a LL next hop for ipv4. For that matter, it is a violation to allow
ANY ipv4 LL address to be the next hop in the routing table(s).

--
Rod Grimes ***@freebsd.org

Poul-Henning Kamp

2021-04-26 14:24:55 UTC

--------

Post by Poul-Henning Kamp
Does anybody know why we put a (ipv6)LL on loopback interfaces ?

I believe someplace in the bowls of all the IPv6 specs this
is a requirement. I could not find it quickly though.

I'm not seeing Linux doing it for instance ?

Post by Rodney W. Grimes
Question: Should we allow a route to have a next hop of a LL(ipv4)?
The host MUST NOT send a packet with an IPv4 Link-Local destination
address to any router for forwarding.
So, arguably, it is a violation to allow the default route to have
a LL next hop for ipv4. For that matter, it is a violation to allow
ANY ipv4 LL address to be the next hop in the routing table(s).

You are reading that wrong.

It is OK to have a LL as next-hop.

It is not OK to send a packet with dst=LL to any next-hop.

Rodney W. Grimes

2021-04-26 14:01:07 UTC

Post by Zhenlei Huang
Hi Rod Grimes,

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.

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.

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.

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.

Post by Zhenlei Huang
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.

Post by Zhenlei Huang
Thanks :)
_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers

Thanks,
Zhenlei Huang

--
Rod Grimes ***@freebsd.org

Zhenlei Huang

2021-04-26 15:35:38 UTC

Subject: Re: Are there any RFCs for address selection for IPv4
Date: April 26, 2021 at 10:01:07 PM GMT+8

Post by Zhenlei Huang
Hi Rod Grimes,

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 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.

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. 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 .

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.

Post by Zhenlei Huang
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.

Post by Zhenlei Huang
Thanks :)
_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers

Thanks,
Zhenlei Huang

Zhenlei Huang

Rodney W. Grimes

2021-04-26 14:56:33 UTC

Post by Poul-Henning Kamp
--------

Post by Poul-Henning Kamp
Does anybody know why we put a (ipv6)LL on loopback interfaces ?

I believe someplace in the bowls of all the IPv6 specs this
is a requirement. I could not find it quickly though.

I'm not seeing Linux doing it for instance ?

I'll investigate further and see if I can discover why we
do this, if it is or isnt in spec, etc.

Post by Poul-Henning Kamp

You are reading that wrong.

Yep

Post by Poul-Henning Kamp
It is OK to have a LL as next-hop.
It is not OK to send a packet with dst=LL to any next-hop.

No, that is explicity forbidden:
RFC 3927 at 2.7 paragraph 2:

An IPv4 packet whose source and/or destination address is in the
169.254/16 prefix MUST NOT be sent to any router for forwarding, and
any network device receiving such a packet MUST NOT forward it,
regardless of the TTL in the IPv4 header.

If dst=LL you must ARP for the destination is also in the
spec some place, no routing allowed.

Now if you had said dst != LL to any next-hop, that would
be true.

Post by Poul-Henning Kamp
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers

--
Rod Grimes ***@freebsd.org

Poul-Henning Kamp

2021-04-26 15:12:38 UTC

--------

Post by Poul-Henning Kamp
It is OK to have a LL as next-hop.
It is not OK to send a packet with dst=LL to any next-hop.

An IPv4 packet whose source and/or destination address is in the
169.254/16 prefix MUST NOT be sent to any router for forwarding, and
any network device receiving such a packet MUST NOT forward it,
regardless of the TTL in the IPv4 header.

Right the second criteria should be:

It is not OK to send a packet with src=LL or dst=LL to any next-hop.

But it /is/ OK to have a next-hop router on a LL, but it is no use,
unless your host has another interface with a "real" IP on it.

Rodney W. Grimes

2021-04-26 19:50:06 UTC

Subject: Re: Are there any RFCs for address selection for IPv4
Date: April 26, 2021 at 10:01:07 PM GMT+8

Post by Zhenlei Huang
Hi Rod Grimes,

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 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.

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.

Post by Zhenlei Huang
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.

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.

Post by Zhenlei Huang
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.

Post by Zhenlei Huang
Thanks :)

Zhenlei Huang

--
Rod Grimes ***@freebsd.org

Zhenlei Huang

2021-04-29 10:36:44 UTC