Subject: [babel] AD review of draft-ietf-babel-v4viav6

From: Martin Vigoureux <[email-masked]>
Date: Thu, 4 Nov 2021 18:53:12 +0100

Juliusz, WG,

hello.

Thank you for your work. I have reviewed that document and have only few 
questions.

-m

    A Babel node that needs to announce an IPv4 route over an interface
    that has no assigned IPv4 address MAY make a v4-via-v6 announcement.
If the Babel node needs to do so, what other option does it have? If 
none, then MAY may not be the right keyword.

    If the outgoing interface has been assigned an IPv4 address, then, in
    the interest of maximising compatibility with existing routers, the
    sender SHOULD prefer an ordinary IPv4 announcement; even in that
    case, however, it MAY send a v4-via-v6 announcement.
I don't understand that part. Why do you allow a node with a v4 
interface to use a v4-via-v6 announcement of a v4 route?

    There are various ways to meet this requirement, and choosing between
    them is left to the implementation.  For example, if a router has an
    interface that has been assigned an IPv4 address, or if an IPv4
    address has been assigned to the router itself (to the "loopback
    interface"), then that IPv4 address may be "borrowed" to serve as the
    source of originated ICMPv4 packets.  If no IPv4 address is
    available, a router may choose a source address from a prefix known
    to be unused, for example from a suitably chosen private address
    range [RFC1918].  If no more suitable address is available, then a
    router MAY use the IPv4 dummy address 192.0.0.8 as the source address
    of the IMCPv4 packets that it sends.  Note however that using the
    same address on multiple routers may hamper debugging and fault
    isolation, e.g., when using the "traceroute" utility.
I'm not an ICMP expert, and I may not have understood what you are 
aiming for here. While the first proposal (using loopback) seems ok to 
me, the other don't. I think that it is not good practice to be using 
1918 addresses beyond private networks, and overall, I fail to 
understand how a response to the ICMP packet could reach back the 
originator if it has used 1918/dummy as SA. rfc1812 in fact seems to 
forbid that (section 4.3.2.4), though I didn't check if this requirement 
had been updated by other RFCs.
Anyway, could you elaborate on the above?

Nits
s/RFC5549/RFC8950/
s/IMCPv4/ICMPv4/

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Thu, 04 Nov 2021 20:00:52 +0100

> interface to use a v4-via-v6 announcement of a v4 route?

One reason to do this could be to lower implementation complexity in an
environment where you don't have a mature networking stack to deploy.
If you route everything via v6 you don't have to implement ARP at all :)

> Anyway, could you elaborate on the above?

The idea is that we want there to be *some* ICMP errors going out, even
if there is no v4 addresses configured anywhere. And using a private
address or the dummy 192.0.0.8 (which comes from RFC7600, BTW), makes
this possible. Many networks will happily route such packets; and, for
instance, having traceroute return multiple hops with the dummy address
is better than not having any replies at all.

We recently fixed Linux to use this dummy address, BTW: 

https://git.kernel.org/torvalds/c/321827477360

Prior to that change it would just cheerfully send out ICMP messages
with a source address of 0.0.0.0, which obviously doesn't work at all.

-Toke

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 04 Nov 2021 20:18:36 +0100

Thank for your review, Martin.

> If the Babel node needs to do so, what other option does it have? If none,
> then MAY may not be the right keyword.

I think "needs" is the wrong word here.  What I meant to say is that
a node that would like to advertise a V4 route may choose to make
a v4-via-v6 announcement, but of course whether it actually does is
a matter of local policy (subject to configuration).

I'll try to find a better formulation.  (Any suggestions?)

> I don't understand that part. Why do you allow a node with a v4 interface
> to use a v4-via-v6 announcement of a v4 route?

The v4-via-v6 next-hop is usually a link-local address, which is likely to
be more stable than a v4 address.  If it is known that all the routers in
the domain support the extension, then it may be better for the network to
make a v4-via-v6 announcement.

At any rate, there's no good reason to forbid this behaviour.

> I'm not an ICMP expert, and I may not have understood what you are aiming
> for here. While the first proposal (using loopback) seems ok to me, the
> other don't. I think that it is not good practice to be using 1918
> addresses beyond private networks,

This was discussed at the Babel meeting of 4 March 2021, and the
discussion continued on this very list throughout the month of March.  It
would have been appreciated if you had participated in the discussion back
then, and I find it somewhat discouraging that I need to summarise the
discussion before even reaching the IESG.

I refer you to my slides of 4 March 2021, and the discussion on this list
starting on 14 March 2021 titled "Dummy Source Address".

The case of a router that has a loopback address is pretty obvious, the
loopback address should be used as the source address of the ICMP packet.
That case, however, is not very interesting -- if the router has
a loopback address, then it might as well use it as the next hop.

The problem we're trying to solve here is that of a router that has no
IPv4 address at all.  While you might argue that RFC 1812 does not allow
this case, such routers are being deployed, and the alternatives to this
proposal require either tunnelling (MAP-E) or address-translation (MAP-T,
NAT464, etc.), either of which breaks a number of desirable properties of
the Internet.

The proper solution would be to avoid sending router-to-host ICMP packets,
as described in my slides of 4 March 2021.  This is not a new observation:
the whole point of ECN, for example, is to replace the unreliable
router-to-host "Source Quench" signalling with reliable end-to-end
signalling.  Unfortunately, PMTUd is deployed in the wild, and we need to
do something about it.

Hence, we need to send ICMP packets, and we need something to put in the
source address.  The most robust solution is to use a distinguished
address allocated to the local network.  Failing that, you may either use
an RFC 1918 address, or the dummy address.  Nobody finds these solutions
attractive, but remember that the alternative is NAT464 or other packet
translation technologies.

> and overall, I fail to understand how a response to the ICMP packet
> could reach back the originator if it has used 1918/dummy as SA.

The dummy address is being used as the *source* address, and hence doesn't
prevent routing of the packet.  Some over-zealous packet filters might
look at the source address, in which case you'll end up with an ICMP
blackhole -- but that's already something you need to deal with.

-- Juliusz

---

From: Martin Vigoureux <[email-masked]>
Date: Thu, 4 Nov 2021 20:31:46 +0100

Hi Toke,

thank you for your rapid feedback.
Please see in-line.

regards
-m

> If you route everything via v6 you don't have to implement ARP at all :)
humm, but that's not via v6 in this case because the interface is v4, or 
I'm missing something?

> is better than not having any replies at all.
Are you saying non private networks have routes for 192.0.0.8 or even 
rfc1918 addresses?
I indeed saw that 7600 was proposing the use of that dummy address as 
SA, but 1/ it's Experimental while this draft is in the Standard Track, 
2/ it didn't appear to me that it was for the same use.
It might be fine to send a Destination Unreachable with 192.0.0.8 as SA 
because it's a one way message, but it is not clear to me how 
ping/traceroute works when this address is used as SA in echo request, 
because a reply needs to get back to the sender.
Again, I may be misinterpreting your use case, but I'm wary about a 
draft saying that an implementation can choose whatever source address 
it wants for ICMP messages when rfc1812 clearly doesn't say so.

Not sure if it is relevant, but have you looked into rfc5837?

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 04 Nov 2021 20:38:36 +0100

> Not sure if it is relevant, but have you looked into rfc5837?

Yes, I was aware of this document.  Unfortunately, it only helps with
identifying the interface in the case where the router has an IPv4 address
(the "easy case" in my previous mail).  It's also not applicable to ICMP
MTU Exceeded (see Section 4).

-- Juliusz

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Thu, 04 Nov 2021 20:53:32 +0100

> I'll try to find a better formulation.  (Any suggestions?)

Does it need to include the MAY/SHOULD/MUST language? Otherwise, how
about simply:

"A Babel node can use a v4-via-v6 announcement to announce an IPv4 route
over an interface that has no assigned IPv4 address." ?

-Toke

---

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 05 Nov 2021 14:20:58 +0100

> over an interface that has no assigned IPv4 address." ?

Right, thanks.

-- Juliusz

---

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 05 Nov 2021 14:33:19 +0100

I'm unfortunately unable to upload a new draft at this time.  The changes
are in the git repository.

> then MAY may not be the right keyword.

Replaced following Toke's suggestion:

  A Babel node can use a v4-via-v6 announcement to announce an IPv4 route
  over an interface that has no assigned IPv4 address.

> to use a v4-via-v6 announcement of a v4 route?

Not changed, for reasons explained in my previous mail.

> I think that it is not good practice to be using 1918 addresses beyond
> private networks, and overall, I fail to understand how a response to
> the ICMP packet could reach back the originator if it has used
> 1918/dummy as SA.

I've reworded this section to omit mention of 1918.  Donald, since you're
the body who initially suggested we use 1918, could you please check if
the new formulation is okay with you?

> s/RFC5549/RFC8950/

The extension was inspired by 5549, and I want to give full credit to the
original authors.  Please see paragraph (11) of

  https://datatracker.ietf.org/doc/draft-ietf-babel-v4viav6/shepherdwriteup/

> s/IMCPv4/ICMPv4/

Done, thanks.

-- Juliusz

---

From: Martin Vigoureux <[email-masked]>
Date: Fri, 5 Nov 2021 19:25:41 +0100

Juliusz,

thank you. Please see in-line.

regards,
martin

> I'll try to find a better formulation.  (Any suggestions?)
I like Toke's proposal from which I would in fact remove "can".

> At any rate, there's no good reason to forbid this behaviour.
I'm not asking for that. I'd however suggest that you incorporate the 
explanation you have given above, in the draft.

> discussion before even reaching the IESG.
I understand. It's not always easy for an AD to monitor all the 
discussions of all the WG he/she oversees, but you are right in the 
sense that I should have done my homework better by going back into the 
archives and meetings before sending my e-mail. Point taken.

> translation technologies.
It looks to me that the problem you're trying to solve is an ICMP 
problem, not a Babel one, although it appears in the context of Babel. 
If that is the case, then you shouldn't try to solve it as one section 
in a Babel document or at least you shouldn't say that an implementation 
can choose whatever source IP it wants.

> blackhole -- but that's already something you need to deal with.
I understood that, but I still have concerns
- rfc 7600 is Experimental while this document is Standard Track so you 
are taking a level up the procedures defined in 7600 (the use of the 
Dummy Address for ICMP). A way around that may be to register your own 
special purpose IPv4 address, or be clearer that it's an Experimental 
mechanism (though I'm less sure about that).
- it's still not clear to me how ping or traceroute work with that 
scheme. These require a message to be sent back to the source. If a 
Babel source node used Dummy as SA, how can a message reach it in return?

---

From: Donald Eastlake <[email-masked]>
Date: Sat, 6 Nov 2021 00:22:46 -0400

Hi,

See below.

> >> If the Babel node needs to do so, what other option does it have? If
none,
> >> I don't understand that part. Why do you allow a node with a v4
interface
> >> I'm not an ICMP expert, and I may not have understood what you are
aiming
> can choose whatever source IP it wants.

I don't think the draft says that a Babel router without any assigned IPv4
address can use whatever source IPv4 address it wants. It suggests the
following:

   1. Using an IPv4 address that has been assigned to the router or some
   other interface of the router.
   2. Using "a source address from a prefix known to be unused".  For
   example, if we are talking about a network not having IPv4 connectivity to
   the Internet or only IPv4 connected to the Internet via NAT, the network
   manager may know of an unused local prefix, quite possibly an RFC 1918
   prefix.
   3. Using the IPv4 dummy address as source address.

The idea on point 2 is that a receiver of the ICMP would get more
information about which router had issued ICMP if there is at least a good
chance that they use different source IPv4 addresses. Admittedly, if the
routers are going to be individually configured with some IPv4 address
known to be unused in an isolated or NAT bounded network, this is not
really different from case 1. So 2 only makes separate sense if you have a
scheme to just configure the prefix on your routers and then let them
autogenerate an IPv4 address with that prefix...

For point 3 see below.

> mechanism (though I'm less sure about that).

I do not think the status of RFC 7600 has a controlling effect in this
case. The protocol in Experimental RFC 7600 needed a dummy IPv4 address so,
I assume, it was the motivation for the allocation of 192.0.0.8. But there
is nothing about that allocation that is temporary or tied to the protocol
in RFC 7600. These questions are answered by the column entries for
192.0.0.8 in the IANA Registry at
https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml
As indicated by the "Termination Date" column, this is a permanent
allocation of an IPv4 address. As indicated by the "Reserved-by-Protocol"
column, this IPv4 address is not reserved for the RFC 7600 protocol. And
perhaps most important, when 192.0.0.8 was assigned, it was given pretty
much the most general name it could be given: "IPv4 dummy address".
     It might have been nice to assign a separate IPv4 unicast address as
the "Babel v4-via-v6 IPv4 dummy address" but isn't it obvious that would
be a strict subset of the 192.0.0.8 "IPv4 dummy address"? Given the above
factors and that there is deployed code using 192.0.0.8 for this purpose, I
favor sticking with 192.0.0.8 in this draft.

However, something like the following should be added to the draft's IANA
Consideration:
     "IANA is requested to add [this document] as an additional reference
for 192.0.0.8 in the IANA IPv4 Special-Purpose Address Registry."

> Babel source node used Dummy as SA, how can a message reach it in return?

OK, a node with no routable IPv4 address cannot successfully originate IPv4
pings or run IPv4 traceroute. But I'm not sure why such a node would want
to do that.
      A node with an IPv4 address can send IPv4 traffic and (modulo network
blockage) get back ICMPs. Furthermore, it can also send pings and do
traceroute to other reachable nodes with IPv4 addresses. It will not be
able to ping nodes that don't have an IPv4 address. And it will get back
somewhat uninformative traceroute responses from nodes along the path it is
tracerouting if those nodes don't have iPv4 addresses. But it seems to me
that ping and traceroute will still be of significant use.

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

---

From: Martin Vigoureux <[email-masked]>
Date: Sat, 6 Nov 2021 23:04:38 +0100

Hi Donald,

please see in-line.

regards,
-m

Le 2021-11-06 à 5:22, Donald Eastlake a écrit :
> Hi,
> 
> See below.
> 
> On Fri, Nov 5, 2021 at 2:26 PM Martin Vigoureux 
> <[email-masked] <mailto:[email-masked]>> wrote:
>  > Juliusz,
>  >
> I don't think the draft says that a Babel router without any assigned 
> IPv4 address can use whatever source IPv4 address it wants. It suggests 
> the following:
> 
>     example, if we are talking about a network not having IPv4
>     connectivity to the Internet or only IPv4 connected to the Internet
>     via NAT, the network manager may know of an unused local prefix,
>     quite possibly an RFC 1918 prefix.
> information about which router had issued ICMP if there is at least a 
> good chance that they use different source IPv4 addresses. Admittedly, 
> if the routers are going to be individually configured with some IPv4 
> address known to be unused in an isolated or NAT bounded network, this 
> is not really different from case 1. So 2 only makes separate sense if 
> you have a scheme to just configure the prefix on your routers and then 
> let them autogenerate an IPv4 address with that prefix...

The draft clearly says:
    There are various ways to meet this requirement, and choosing between
    them is left to the implementation.  For example,
This clearly says that the implementation can choose amongst various 
ways. What follows are only examples of some ways.

> case. The protocol in Experimental RFC 7600 needed a dummy IPv4 address 
> so, I assume, it was the motivation for the allocation of 192.0.0.8. But 
> there is nothing about that allocation that is temporary or tied to the 
> protocol in RFC 7600. These questions are answered by the column entries 
> for 192.0.0.8 in the IANA Registry at
My comment is not related to 7600 and Dummy being tied or not, or Dummy 
being temporary, or not.
7600 defined a procedure for using something else than loopback or 
interface@ as SA. By construction, this is an Experimental procedure. 
This draft, as currently written, is making that procedure a Standard 
Track one.

> allocation of an IPv4 address. As indicated by the 
> "Reserved-by-Protocol" column, this IPv4 address is not reserved for the 
> RFC 7600 protocol. And perhaps most important, when 192.0.0.8 was 
> assigned, it was given pretty much the most general name it could be 
> given: "IPv4 dummy address".
>       It might have been nice to assign a separate IPv4 unicast address 
> as the "Babel v4-via-v6 IPv4 dummy address" but isn't it obvious that 
> would be a strict subset of the 192.0.0.8 "IPv4 dummy address"? Given 
> the above factors and that there is deployed code using 192.0.0.8 for 
> this purpose, I favor sticking with 192.0.0.8 in this draft.
> 
> However, something like the following should be added to the draft's 
> IANA Consideration:
>       "IANA is requested to add [this document] as an additional 
> reference for 192.0.0.8 in the IANA IPv4 Special-Purpose Address Registry."
> 
> OK, a node with no routable IPv4 address cannot successfully originate 
> IPv4 pings or run IPv4 traceroute. But I'm not sure why such a node 
> would want to do that.
Maybe that should be clarified, because that section generally talks 
about ICMP so one could expect that all functionalities of ICMP are 
expected to work, while they in fact don't.

>        A node with an IPv4 address can send IPv4 traffic and (modulo 
> network blockage) get back ICMPs. Furthermore, it can also send pings 
> and do traceroute to other reachable nodes with IPv4 addresses. It will 
> not be able to ping nodes that don't have an IPv4 address. And it will 
> get back somewhat uninformative traceroute responses from nodes along 
> the path it is tracerouting if those nodes don't have iPv4 addresses. 
> But it seems to me that ping and traceroute will still be of significant 
> use.As it currently stands the draft doesn't detail much the limitations of 
using ICMPv4 for ping/trace when the sender and/or the replier don't 
have a v4 address. If the choice of the solution is left to the 
implementer then he/she should have at hand the elements enabling 
him/her to make the right choice depending of his/her context and objective.
As said, the issue is an icmp problem, not a babel one, so I'm not sure 
you want to go down that path.

> [email-masked] <mailto:[email-masked]>
> 
>  > > -- Juliusz
>

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 08 Nov 2021 00:32:36 +0100

> It looks to me that the problem you're trying to solve is an ICMP problem,
> not a Babel one, although it appears in the context of Babel.

That's right.

> can choose whatever source IP it wants.

What do you suggest, then?

> are taking a level up the procedures defined in 7600 (the use of the Dummy
> Address for ICMP). A way around that may be to register your own special
> purpose IPv4 address,

That cannot work, as explained in my message of 14 April 2021:

    By the time the IPv4 module has decided it needs to send an ICMPv4 packet,
    it does not necessarily know whether the issue it's reporting is due to
    Babel or to some routing protocol.  In fact, there might not even be
    a well defined responsible protocol -- if a router running both Babel and
    BGP finds out that it has no route to a given destination, is the ICMPv4
    packet associated with Babel or BGP?

    Thus, any implementable procedure for sending ICMPv4 must be independent
    of any given routing protocol -- so it's not reasonable to have a Babel
    dummy address, distinct from a hypothetical BGP dummy address or an OSPF
    dummy address.  If we define a dummy address, that address must be common
    across all routing protocols.

> or be clearer that it's an Experimental mechanism

This draft was initially submitted as Experimental, but the WG group
insisted that I put it on the Standards Track, which I duly did in -02.
I still think it would be better to keep it Experimental, but I am merely
an empty vessel that carries the opinions of the WG.

> scheme. These require a message to be sent back to the source. If a Babel
> source node used Dummy as SA, how can a message reach it in return?

As you rightly note, it cannot.  This is no different from an IPv6 router
that has only been assigned link-local or site-local addresses, it is able
to forward IPv6 packets but cannot originate either IPv6 or ICMPv6.

Martin, ICMP is a best-effort protocol: even in IPv4, the fact that
a packet from A to B is crossing a router R does not imply that R can
reach A.  Source Quench got this wrong, and was therefore replaced by ECN,
which piggybacks on end-to-end packets.  PMTUd got it wrong again, and
that's why it's so unreliable; but that's a design flaw in PMTUd, not an
issue that can possibly be fixed in ICMP.

-- Juliusz

---

From: Martin Vigoureux <[email-masked]>
Date: Tue, 9 Nov 2021 12:47:39 +0100

Juliusz,

thank you for your feedback. I have asked around and the Standard Track 
/ Experimental conflict I was perceiving may not be that bad/critical, 
though a bit of word-smithing may be needed to clarify the situation.
The objective of the below (which doesn't change much) is to keep the 
standard track status of this draft, to avoid this section turning into 
an ICMP specification, and to correctly reference what's being used to 
lift any ambiguity.

Let me know.

regards,
-m

OLD:
There are various ways to meet this requirement, and choosing between 
them is left to the implementation.  For example, if a router has an 
interface that has been assigned an IPv4 address, or if an IPv4 address 
has been assigned to the router itself (to the "loopback interface"), 
then that IPv4 address may be "borrowed" to serve as the source of 
originated ICMPv4 packets.  If no IPv4 address is available, a router 
may use some address from a prefix assigned to the local network that is 
known to not be used by any node in that network.  If no more suitable 
address is available, then a router MAY use the IPv4 dummy address 
192.0.0.8 as the source address of the ICMPv4 packets that it sends.
Note however that using the same address on multiple routers may hamper 
debugging and fault isolation, e.g., when using the "traceroute" utility.

NEW:
In such a situation, a router can use the IPv4 address which has been 
assigned to the router itself (i.e., the loopback interface), as the 
source address of the ICMPv4 packets that it sends. However, in the case 
where no such address exists, a Babel router, needing to send ICMPv4 
packets, could use the experimental mechanism described in <xref 
target="RFC7600"/> which uses the IPv4 dummy address (192.0.0.8) <ref to 
iana registry> as the source address of ICMPv4 packets. Note however 
that some ICMPv4 functionalities such a ping or trace-route are likely 
not to work or not to work as expected when using such mechanism.

and add two informative references:
rfc7600
https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 11 Nov 2021 14:49:40 +0100

> However, in the case where no such address exists, a Babel router,
> needing to send ICMPv4 packets, could use the experimental mechanism
> described in <xref target="RFC7600"/> which uses the IPv4 dummy address
> (192.0.0.8) <ref to iana registry> as the source address of ICMPv4
> packets.

Excellent idea.  I'll give the WG a few days to react, then implement your
suggestion.

Thanks,

-- Juliusz

---

From: David Schinazi <[email-masked]>
Date: Thu, 11 Nov 2021 10:30:44 -0800

This suggestion sounds good to me.

David

On Thu, Nov 11, 2021 at 5:49 AM Juliusz Chroboczek <[email-masked]> wrote:

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

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Fri, 12 Nov 2021 11:40:10 +0100

> This suggestion sounds good to me.

+1

-Toke