Re: [babel] About ICMP and unnumbered routers

["STARK, BARBARA H" <[e-mail]>]

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

> -----Original Message-----
> 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
> 
> > -----Original Message-----
> > From: Donald Eastlake
> >
> > Hi Juliusz/David,
> >
> > Thanks for the research. See below.
> >
> > On Sun, Aug 2, 2020 at 3:08 PM Juliusz Chroboczek <[e-mail]> wrote:
> > > 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.
> >
> > I would recommend against this due to possible collisions.
> >
> > > 2. Request a dedicated IPv4 address (the "all-routers anycast address") to
> > >    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://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= )
> >
> > > 3. Update RFC 1812 to allow unnumbered routers and 0.0.0.0 as the
> source
> > >    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   [phone] (cell)
> >  2386 Panoramic Circle, Apopka, FL 32703 USA
> >  [e-mail]
> >
> > > I'm interested in the comments of wise people.
> > >
> > > -- Juliusz
> >
> > _______________________________________________
> > babel mailing list
> > [e-mail]
> > 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=
> 
> _______________________________________________
> babel mailing list
> [e-mail]
> 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=tiGmpKDzY_-
> H72AiAJGyH7KnqmLvnnUW_qRpVWtlUh0&s=GkxQbxLD8cUTqaegZPMJkByiF
> wjB9SDwCM7S3sBuIgQ&e=