Subject: [babel] About ICMP and unnumbered routers

From: Juliusz Chroboczek <[email-masked]>
Date: Sun, 02 Aug 2020 21:07:59 +0200

Dear all,

This mail is about the consequences of draft-bastian-babel-v4ov6-00 on
ICMPv4 generation.

At last week's meeting, Margaret kindly pointed out that we didn't do our
homework, and that we didn't consider how ICMPv4 is sent out when the
sending router has no IPv4 addresses.  I've looked at a few RFCs, and here
are my tentative conclusions.

RFC 1812 Section 2.2.7 says:

   In this scheme, a router that
   has unnumbered point to point lines also has a special IP address,
   called a router-id in this memo.  The router-id is one of the
   router's IP addresses (a router is required to have at least one IP
   address).  This router-id is used as if it is the IP address of all
   unnumbered interfaces.

So it looks like it was decided back in 1995 that all IPv4 routers need at
least one IPv4 address.  Much as I tried, I couldn't find anything that
would relax this requirement.  As expected, when an ICMPv4 packet is sent
over an unnumbered interface, the distinguished "router-id" address is
used as the source address:

   the IP source address in an ICMP message originated by the router MUST
   be one of the IP addresses associated with the physical interface over
   which the ICMP message is transmitted.  If the interface has no IP
   addresses associated with it, the router's router-id (see Section
   [5.2.5]) is used instead.

(This appears to be a typo -- there's nothing relevant in Section 5.2.5.)

Interestingly, there appears to be nothing in RFC 1812 that specifies that
the router-id is globally unique; thus, what we could do would be to put
the same IPv4 address on all routers.  This would make traceroute a little
confusing (RFC 5837 might help), but it would solve both the problem with
ICMPv4 blackholes and compliance with RFC 1812.

In the light of the above, and in the immortal words of Lenin, what shall we do?

1. Pick a private IPv4 (say 10.42.42.42) and put it on the loopback
   interface of all unnumbered routers.

2. Request a dedicated IPv4 address (the "all-routers anycast address") to
   be used as the loopback address of unnumbered routers.

3. Update RFC 1812 to allow unnumbered routers and 0.0.0.0 as the source
   address of ICMPv4 packets.

I'm interested in the comments of wise people.

-- Juliusz

---

From: David Schinazi <[email-masked]>
Date: Sun, 2 Aug 2020 17:52:28 -0700

I don't know if I qualify as a "wise person", but I have comments :-)

I may have found a solution from 4rd. They reserved an
"IPv4 dummy address" specifically for the purpose of
filling in the source address of ICMPv4 packets:

https://tools.ietf.org/html/rfc7600#section-4.8
(Text copied below for convenience)

I think this might suit our needs?

Cheers,
David

4.8.  Tunnel-Generated ICMPv6 Error Messages

   If a Tunnel packet is discarded on its way across a 4rd domain
   because of an unreachable destination, an ICMPv6 error message is
   returned to the IPv6 source.  For the IPv4 source of the discarded
   packet to be informed of packet loss, the ICMPv6 message has to be
   converted into an ICMPv4 message.

   R-22: If a CE or BR receives an ICMPv6 error message [RFC4443], it
         MUST synthesize an ICMPv4 error packet [RFC792].  This packet
         MUST contain the first 8 octets of the discarded packet's IP
         payload.  The reserved IPv4 dummy address (192.0.0.8/32; see
         Section 6) MUST be used as its source address.

         As described in [RFC6145], ICMPv6 Type = 1 and Code = 0
         (Destination Unreachable, No route to destination) MUST be
         translated into ICMPv4 Type = 3 and Code = 0 (Destination
         Unreachable, Net unreachable), and ICMPv6 Type = 3 and Code = 0
         (Time Exceeded, Hop limit exceeded in transit) MUST be
         translated into ICMPv4 Type = 11 and Code = 0 (Time Exceeded,
         time to live exceeded in transit).

On Sun, Aug 2, 2020 at 12:08 PM Juliusz Chroboczek <[email-masked]> wrote:

> _______________________________________________
> babel mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/babel
>

---

From: Donald Eastlake <[email-masked]>
Date: Sun, 2 Aug 2020 21:18:19 -0400

Hi Juliusz/David,

Thanks for the research. See below.

>    interface of all unnumbered routers.

I would recommend against this due to possible collisions.

>    be used as the loopback address of unnumbered routers.

I think this is the best way forward. Probably the "IPv4 dummy
address" David Schinazi found would do fine. (If there is any problem
with that, getting a new special use IPv4 address for this purpose
would be pretty easy. The assignment requirement is "IETF Review"
which means any document that goes through IETF Last call will do as
the basis for a new assignment.
https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml)

>    address of ICMPv4 packets.

Updating RFC 1812 seems like a more difficult path and possibly there
are routers or middle boxes that discard packets with a 0.0.0.0 source
as bogus. I don't know if the text is still valid but RFC 1122 says of
0.0.0.0 source:

                 This host on this network.  MUST NOT be sent, except as
                 a source address as part of an initialization procedure
                 by which the host learns its own IP address.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 [email-masked]

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Mon, 3 Aug 2020 15:47:26 +0000

Has an RFC 5735 169.254.0.0/16 IPv4 link local address been considered? Do the ICMP packets need to cross routed boundaries? [Sorry, I haven't been paying careful attention to the issue, so I haven't taken the time to understand it.]
Barbara

> -----Original Message-----
> From: Donald Eastlake
> 
> Hi Juliusz/David,
> 
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.iana.org_assignments_iana-2Dipv4-2Dspecial-2Dregistry_iana-
> 2Dipv4-2Dspecial-2Dregistry.xhtml&d=DwICAg&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=LoGzhC-8sc8SY8Tq4vrfog&m=3AJm3dEuSiQGZ-
> ZV79-GC1BPS_4jpUF5cvaTIlD5ZgI&s=b0I9NcTMzHIVkI9EZQ5GEcPBe-dg-
> xPXFNH5MtgyCH8&e= )
> 
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_babel&d=DwICAg&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=LoGzhC-8sc8SY8Tq4vrfog&m=3AJm3dEuSiQGZ-
> ZV79-
> GC1BPS_4jpUF5cvaTIlD5ZgI&s=5Nh_1kZZZtr2sloYG14thQ3TVcrnB_0udm7dQ
> LdKRfg&e=

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Mon, 3 Aug 2020 15:48:54 +0000

I should have said RFC 3927 169.254.0.0/16 IPv4 link local address.
https://tools.ietf.org/html/rfc3927
Barbara

> From: STARK, BARBARA H
> Has an RFC 5735 169.254.0.0/16 IPv4 link local address been considered? Do
> the ICMP packets need to cross routed boundaries? [Sorry, I haven't been
> paying careful attention to the issue, so I haven't taken the time to
> understand it.]
> Barbara
> 
> > > In the light of the above, and in the immortal words of Lenin, what shall
> we
> > do?
> >
> o9_HUMeMTSQicvjIg&r=LoGzhC-8sc8SY8Tq4vrfog&m=tiGmpKDzY_-
> H72AiAJGyH7KnqmLvnnUW_qRpVWtlUh0&s=GkxQbxLD8cUTqaegZPMJkByiF
> wjB9SDwCM7S3sBuIgQ&e=

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 03 Aug 2020 18:26:14 +0200

> Has an RFC 5735 169.254.0.0/16 IPv4 link local address been considered?
> Do the ICMP packets need to cross routed boundaries?

Yes.  If there's an MTU mismatch and a packet has the DF bit set, then the
router needs to send back a Packet Too Big message to the originator, else
a blackhole will occur (except if RFC 4821 is implemented, but even if it
is, PTB packets make convergence faster).

Note howver, that I'm not sure whether routers block packets with
169.254/16 in the *source* address (as opposed to the destination).

-- Juliusz