1

I have a ubuntu machine with two interfaces (eth0 and eth1). Eth0 interface has a dhcp address and eth1 has apipa (169.254.x.x) address. eth1 is not connected and eth0 is connected to a local network. From my desktop, which is also connected to the same network, i can ping 169.254.x.x address and can do scp, etc.

How this is possible? No routing is enabled.

2
  • 1
    On which host is the 169.254.x.x address? Are you sure eth0 doesn't have two addresses? Including ip addr and ip route get 169.254.x.x (for whatever x.x. you used) in the question may help... – dirkt Jun 4 '20 at 21:05
  • So Kumar any feedback on my answer? – A.B Jun 8 '20 at 8:21
0

Just for clarification: APIPA is Microsoft's original naming and has been standardized as Dynamic Configuration of IPv4 Link-Local Addresses (IPv4LL).

Here is what probably happens:

  • the Desktop has itself a route to the IPv4LL LAN, probably in addition to a more "classical" route it got by the same DHCP Ubuntu uses, say a private LAN 192.168.1.0/24.

  • Ubuntu has itself an IPv4LL address on eth1, let's say 169.254.5.6

  • When Desktop is looking for 169.254.5.6 since its on-link (directly reachable), it sends an ARP requests for 169.254.5.6 as broadcast,

  • Ubuntu receives the broadcast. As a Linux host, it's following the Weak Host Model: the IP addresses added to its interfaces belong to the host rather than to their interface. It's true both for IPv4 and for ARP, as documented in the arp_filter setting:

    arp_filter - BOOLEAN

    [...]

    0 - (default) The kernel can respond to arp requests with addresses from other interfaces. This may seem wrong but it usually makes sense, because it increases the chance of successful communication. IP addresses are owned by the complete host on Linux, not by particular interfaces. Only for more complex setups like load- balancing, does this behaviour cause problems.

    so it answers the ARP request for 169.254.5.6 assigned to eth1, but on eth0 where it was asked, using eth0's Ethernet MAC address.

  • Desktop now having resolved the layer 2 Ethernet address, updates its ARP table and sends an IPv4 ICMP echo request packet to Ubuntu's 169.254.5.6 with destination MAC address Ubuntu's eth0 MAC address,

  • Ubuntu, following the Weak Host Model replies with an IPv4 ICMP echo reply to the request. Since OP tells it's working, that further means that:

    • either Desktop source address is an IPv4LL too and Ubuntu also has a 169.254.0.0/16 route on eth0 with lower metric (or used first anyway if equals), so the reply comes on the right side,

    • or more probably the Desktop is not using an IPv4LL source to query the IPv4LL address 169.254.5.6 so it's in the same IP network (set by DHCP) as Ubuntu's IP address on eth0 and Ubuntu answers on the right side too (because its routing table has an entry like 192.168.1.0/24 on eth0). This case (not using IPv4LL source) is recommended by the RFC:

    Where both an IPv4 Link-Local and a routable address are available on the same interface, the routable address should be preferred as the
    source address for new communications
    , but packets sent from or to
    the IPv4 Link-Local address are still delivered as expected.

    Assuming I didn't miss something in my explanation, which case is it?

Of course this behaviour isn't entirely correct. Because each broadcast domain should have its own private IPv4LL LAN for itself, and not leak addresses to an other one.

What this means in practice, is that if a Linux host with default configuration participates in multiple such IPv4LL networks (one per interface), it might (uncertain, see later) not allow any other system to use any of its own IPv4LL addresses, or switch needlessly its own IPv4LL address even if they are not on the same side because there are collision detections. But in practice, still because of the Weak Host Model, by default multiple routes to 169.254.0.0/16 will enter the land of the Multi-Homed (mis)configuration. Usually one route only works correctly: the first among equals as displayed with ip route show 169.254.0.0/16. Others will have working ARP, but probably not working IP routing. This requires configuring the host properly for multi-homing (in which case it would anyway probably stop answering ARPs sent to the "wrong" interface above and not trigger this problem), and integration with IPv4LL wouldn't help. Most of this doesn't happen with IPv6, because any use of a link-local address must include the interface.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.