Subject: [babel] I-D Action: draft-ietf-babel-v4viav6-01.txt

From: [email-masked]
Date: Fri, 09 Apr 2021 11:42:19 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Babel routing protocol WG of the IETF.

        Title           : IPv4 routes with an IPv6 next-hop in the Babel routing protocol
        Author          : Juliusz Chroboczek
	Filename        : draft-ietf-babel-v4viav6-01.txt
	Pages           : 9
	Date            : 2021-04-09

Abstract:
   This document defines an extension to the Babel routing protocol that
   allows annoncing routes to an IPv4 prefix with an IPv6 next-hop,
   which makes it possible for IPv4 traffic to flow through interfaces
   that have not been assigned an IPv4 address.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-babel-v4viav6/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-babel-v4viav6-01
https://datatracker.ietf.org/doc/html/draft-ietf-babel-v4viav6-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-babel-v4viav6-01

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 09 Apr 2021 20:49:28 +0200

> 	Filename        : draft-ietf-babel-v4viav6-01.txt

I've made a full pass over the existing text, fixing typos and rewriting
stuff.  I've almost completely rewritten the Security Considerations
section, which I'd be grateful for people to check.

Section 3 is new, and contains the word "hamper", a fact that makes me
immensely proud.  I consider it as a starting point for discussion.  It
differs from Donald's suggestion in the following ways:

  - it merely states that a router MUST be able to send ICMPv4 messages
    (after explaining why), implementation techniques are worded as mere
    examples;

  - it doesn't include Donald's suggestions to (1) use a randomly drawn
    address or (2) use the Babel dummy address, as I think they deserve
    further discussion.

Finally, I did not change the intended status (Experimental to Standards
Track), as it is not my role to gauge whether there is sufficient
consensus on this subject.

-- Juliusz

---

From: David Schinazi <[email-masked]>
Date: Fri, 9 Apr 2021 15:33:47 -0700

I like the new text. My understanding was not hampered.

I would personally prefer the "MUST be able to originate ICMPv4"
to be a SHOULD, because you could conceivably set up your
network in such a way that you never need to send ICMPv4.
For example, if all your interfaces have the same MTU, you won't
have any reason to send ICMP Packet Too Big.

David

On Fri, Apr 9, 2021 at 11:49 AM Juliusz Chroboczek <[email-masked]> wrote:

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

---

From: Donald Eastlake <[email-masked]>
Date: Fri, 9 Apr 2021 22:12:08 -0400

Hi Juliusz,

> section, which I'd be grateful for people to check.

Thanks for getting the draft updated and posted. I like the additional
material in the Security Considerations section.

> differs from Donald's suggestion in the following ways:

Hamper is certainly a good word for the use you have made of it.

Maybe your first sentence is a little too restrictive. Perhaps "that
is primarily used to carry diagnostic and debugging information."
rather than "that carries diagnostic and debugging information". There
are a lot of ICMP types and subtypes:
https://www.iana.org/assignments/icmp-parameters/icmp-parameters.xhtml

>     (after explaining why), implementation techniques are worded as mere

I don't have any problem with the above but, while path MTU discovery
may be the strongest reason for ICMP, I do not think we should imply
it is the only reason of significance. For example, there is also
traceroute. RFC 1812 (Requirements for IP Version 4 Routers) says
"ICMP Time Exceeded messages are required because the traceroute
diagnostic tool depends on them."

While it is frequently claimed that "ICMPs are dropped by the core
routers of the Internet", I don't think that is generally true. I just
did some traceroutes from my home computer to the Google DNS servers
at at 8.8.8.8 and 8.8.4.4.  Sometimes the packets are sent for a few
hops via routers in the core Internet that simply don't seem to
produce "time expired" (actually hop count exhausted) ICMPs but
occasionally ICMPs are produced and my home computer gets them back
from every router along the path. And I always seem to get ICMPs back
from the far end so those ICMPs are all being forwarded through the
core Internet.

Anyway, I think there should be some sort of reference in passing to
"traceroute and other uses" or the like.

>     address or (2) use the Babel dummy address, as I think they deserve

I can see questions about using a dummy address, since it implies
multiple routers with the same address. But I really don't see any
problem with a dynamically allocated IPv4 address (a la RFC 3927) as
another example of a way to meet the requirement.

Looking carefully at the new Section 3, the end of the third paragraph
("has not been assigned an IPv4 address") and the text near the
beginning of the 4th paragraph ("that has been assigned an IPv4
address") sound a little contradictory. I suggest they be made more
precise. So the 3rd paragraph could end with "... originate ICMPv4
packets even when the interface on which they will be transmitted has
not been assigned an IPv4 address." and the text in the 4th paragraph
could be "... if a router has another interface that has been assigned
an IPv4 address ...".

A bit later, I would prefer if "for example an address taken from a
private address range [RFC1918] that is known to not be used in the
local routing domain" were changed to something like "for example
dynamically created address as described in [RFC3927] or an address
taken from a private address range [RFC1918] that is known to not be
used in the local routing domain".

> consensus on this subject.

While there haven't been a lot of comments on this, I think that so
far they lean towards Proposed Standard.

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

---

From: Donald Eastlake <[email-masked]>
Date: Fri, 9 Apr 2021 23:09:51 -0400

Hi David,

> have any reason to send ICMP Packet Too Big.

I think "MUST be able" is the right thing. Of course there is no
problem with disabling ICMPs or any particular type(s) of ICMPs if you
like. But really, by default, traceroute should work. If some Babel
router is tossing packets, you should be able to get back some
indication of that with a code giving the reason. Etc.

Thanks,
Donald

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sat, 10 Apr 2021 13:53:18 +0200

Thanks for your review, Donald.

> rather than "that carries diagnostic and debugging information".

Right.

> it is the only reason of significance. 

[...]

> "traceroute and other uses" or the like.

You're right, I'll think about how to formulate it.  The point I'm trying
to make is that while it might be okay for this extension to break
diagnostic tools (presumably, it is preferable to partially break
traceroute due to this extension rather than breaking it completely by
using v4-in-v6 tunnelling), it is not okay to break higher-layer protocols
that rely on ICMP.  (I'm also trying to hint at the fact that I consider
it a dubious design for higher-layer protocols to rely on ICMP, but that's
not the main point here.)

> another example of a way to meet the requirement.

I need some time to think it over.  On the one hand, 3927 is pretty clear
that link-local addresses are for communication on the local link.  On the
other hand, using 169.254/16 as the source address is no different from
using fe80::/64 as the source address, which is what happens when an
unnumbered IPv6 router needs to send an ICMPv6 packet.

Quoting Section 2.7:

   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.

Granted, this requirement does not apply to ICMPv4, but it still makes me
nervous.  What if a router decides to summarily drop all packets with
a source address in 169.254/16?

> precise.

Agreed.

> far they lean towards Proposed Standard.

I'm fine with it either way, but I'll want one of the chairs to send me
a clear order that I can refer to.

-- Juliusz

---

From: Donald Eastlake <[email-masked]>
Date: Sat, 10 Apr 2021 21:35:39 -0400

Hi Juliusz,

We seem to generally be in agreement. See below.

> not the main point here.)

While traceroute is most useful if all the routers along the path have
unique IPv4 addresses, it still provides useful information if that is
not true.

> a source address in 169.254/16?

That is a point against using [RFC3927] addresses. But I think the
idea of providing a variety of alternatives for implementers is good.
So maybe if we don't give [RFC3927] addresses as an alternative, a
Babel dummy address should be assigned and available as another
alternative. When such an address is assigned from the 192.0.0.0/24
block, you get to explicitly specify whether it can be used as a
source address or not, etc. See
https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml.

> a clear order that I can refer to.

OK. I'll wait a couple of days and thenell you my judgement...

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

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sun, 11 Apr 2021 14:25:54 +0200

> We seem to generally be in agreement.

Yes, it's about finding the right formulation.

---

From: Donald Eastlake <[email-masked]>
Date: Mon, 12 Apr 2021 23:23:05 -0400

Hi Juliusz,

> Yes, it's about finding the right formulation.

Well, I think your writing is better than mine.

I've reviewed the emails and, based thereon, I direct you, as you
requested, to change the draft to target "Proposed Standard".

Thanks,
Donald

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 13 Apr 2021 15:11:32 +0200

> another example of a way to meet the requirement.

Ok, let's see if I read the group right.

1. David suggests that I mention 192.168.0.8, the dummy address assigned
   for 4rd (RFC 7600).

2. Donald wants me to suggest dynamic allocation from the RFC 3927 range.

Concerning 1, the current draft explicitly uses the term "dummy address",
which is a nod in David's direction.  On the other hand, I'm a little
reluctant to mention RFC 7600 explicitly, since I'd rather we avoid being
associated with packet translation techniques.  Yuck.

Concerning 2, I'm going to add a mention of dynamically drawn addresses,
but I'm going to avoid mentioning 3927 explicitly, since I'm not sure that
using 3927 addresses outside of the local link is legit.  Additionally,
doing otherwise might imply that the conflict detection and defense
mechanisms in that document are applicable (or desirable) in our context.

Ok?  If not, yell!

-- Juliusz

---

From: David Schinazi <[email-masked]>
Date: Tue, 13 Apr 2021 10:53:59 -0700

I'm OK with RFC 3927 and 7600 not being mentioned.

David

---

From: Donald Eastlake <[email-masked]>
Date: Tue, 13 Apr 2021 15:42:26 -0400

Just speaking as a wg member:

Hi  Juliusz,

I believe an important part of "engineering" is assessing the balance
of factors in favor of or against various choices. Simplicity is a
good thing so it would be nice if IPv4-less Babel routers did one
simple thing for a source address. On the other hand, minimizing
restrictions on implementers and being able to adapt to different
conditions is good. In this case, I think the balance is towards the
second point and alternatives should be provided.

> 1. David suggests that I mention 192.168.0.8, the dummy address assigned

 A "dummy" address is a reasonable alternative. I think the source IP
address in an ICMP serves two functions. One is to make the packet
"legal" so it wouldn't be thrown away as malformed or malicious. The
other is to provide information that helps to identify the source for
management/debugging/whatever purposes. A "dummy" address is not going
to provide much information but if an implementer is going to follow
that path, it might as well be a Babel specific dummy address. The
existing "dummy" IPv4 address seems to have to do with IPv4 ICMP
messages created by converting ICMPv6 messages [RFC7600]. Possibly
there could be a network in which both could be generated as a source
address and with a separate Babel dummy address, you at least have one
bit of specificity.

> 2. Donald wants me to suggest dynamic allocation from the RFC 3927 range.

Well, I did want that option but your quotes from RFC 3927 convinced
me that the risk of packets with such a "link local" source address
being discarded by routers was too high so I no longer support that.

> associated with packet translation techniques.  Yuck.

Another reason to go with a Babel dummy address.

> mechanisms in that document are applicable (or desirable) in our context.

Sounds reasonable.

Thanks,
Donald

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 14 Apr 2021 00:49:51 +0200

> a separate Babel dummy address

I've been thinking about this all evening, and I think I now see what
makes me uncomfortable.  (Dinner helped.)

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.

Not sure how to proceed:

 1. reuse the 4rd dummy address, as David suggested, repurposing it
    to be a generic dummy address?
 2. write a new RFC defining a cross-protocol dummy address?
 3. define a cross-protocol dummy address in this draft?
 4. remain vague, as in the current text?
 5. some other solution I'm missing?

I'm not volunteering for (2), although I could perhaps be a co-author.
(3) seems like exceeding the scope of this document.  (1) and (4) would be
fine with me.

-- Juliusz

---

From: David Schinazi <[email-masked]>
Date: Tue, 13 Apr 2021 19:00:46 -0700

Oh that's a good point, I totally agree.
(1) or (4) both seem like the best outcome here.
I think I'm now leaning towards (4).

David

---

From: Donald Eastlake <[email-masked]>
Date: Tue, 13 Apr 2021 22:58:31 -0400

Hi Juliusz,

> across all routing protocols.

OK.

>     to be a generic dummy address?

  To the extent that it  changes the use of and existing assignment,
it seems a little mucky.

>  2. write a new RFC defining a cross-protocol dummy address?

  It would be a pretty short RFC but it feels like it would cause some delay.

>  3. define a cross-protocol dummy address in this draft?

  That would actually be a fairly typical thing to do. Basically just
replace appropriate occurrences of "Babel" with "IPv4-via-IPv6" so
it's the "IPv4-via-IPv6 dummy address" and just mention in passing at
some point that it "may" be used with other routing protocols that
support IPv4 via IPv6.

>  4. remain vague, as in the current text?

  Seems unsatisfying to me.

> (3) seems like exceeding the scope of this document.  (1) and (4) would be

I don't think (3) exceeds our scope. We need a facility. So we specify
it in our draft. And, just in passing, we are liberal and say others
can use it. There is no need to make a big point of it being
"cross-protocol" and no need to name any other routing protocol(s).

Thanks,
Donald

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 14 Apr 2021 14:31:45 +0200

> "cross-protocol" and no need to name any other routing protocol(s).

Donald, could you please check RFC 7600, because I'm wondering if that's
not what they have done already.  Here are the relevant quotations:

Section 4.8:

   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.

IANA Considerations:

   o  Reserved IPv4 address 192.0.0.8/32 to be used as the "IPv4 dummy
      address" (Section 4.8).

So I'm pretty tempted to say "MAY use 192.0.0.8 if no more suitable IPv4
address is available", as David originally suggested, and see what the
IESG says.

-- Juliusz

---

From: Donald Eastlake <[email-masked]>
Date: Wed, 14 Apr 2021 12:10:32 -0400

Hi Juliusz,

> address is available", as David originally suggested, and see what the

I spent a little while looking at RFC 7600. Their use is very close to
ours and they have deliberately chosen a maximally generic name for
192.0.0.8. So I don't have any problem with going with that address in
the draft. This is also a faster way to get to a really stable
address.

The interesting question is whether or not to reference RFC 7600. I
would be tempted not to since, to implement Babel IPv4 via IPv6, there
isn't anything in RFC 7600 you have to know about -- in fact someone
could be confused or at least end up wasting time looking at the 4rd
stuff in RFC 7600. Just use 192.0.0.8/32 are refer to it as "the IPv4
dummy address".

Thanks,
Donald