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

From: [email-masked]
Date: Tue, 13 Apr 2021 08:02: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-02.txt
	Pages           : 9
	Date            : 2021-04-13

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-02
https://datatracker.ietf.org/doc/html/draft-ietf-babel-v4viav6-02

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

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: Tue, 13 Apr 2021 17:06:11 +0200

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

Inserted more text about ways of chosing IPv4 addresses, as described in
my previous message.  I'm not too happy with the new text, which I feel is
somewhat overloaded, so if someone good at writing wants to try their hand
at it, I'd be grateful.

Expanded acknowledgments.  Please let me know if you feel you've been
unfairly omitted.

Intended status is now Standards Track.  I do have some misgivings, but
let's be bold.

-- Juliusz

---

From: David Schinazi <[email-masked]>
Date: Tue, 13 Apr 2021 11:52:18 -0700

I like the new text. Ship it!

David

On Tue, Apr 13, 2021 at 8:06 AM Juliusz Chroboczek <[email-masked]> wrote:

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

---

From: Donald Eastlake <[email-masked]>
Date: Tue, 13 Apr 2021 17:43:06 -0400

Hi,

On Tue, Apr 13, 2021 at 11:06 AM Juliusz Chroboczek <[email-masked]> wrote:
> Inserted more text about ways of choosing IPv4 addresses, as described in

I agree it seems somewhat overloaded. I'm also a little bothered by
referring to a chosen RFC 1918 address as a "dummy address". RFC 1918
addresses are not intended to be duplicated which might happen if a
router just grabbed one, whereas addresses that are officially "dummy
addresses" can be intended for possible duplicate use...

You ask for suggested wording, so how about:

   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"), for example a private [RFC1918] address,
   then that IPv4 address may be "borrowed" to serve as the source of
   originated ICMPv4 packets.  If no such IPv4 address is available, a
   router SHOULD use the Babel dummy IPv4 address TBD2 as the source
   of outgoing ICMPv4 packets.  Note however that using the same
   address on multiple routers may hamper debugging and fault
   isolation, e.g., when using the "traceroute" utility.

There would also have to be an addition to the IANA Considerations
something like:

   IANA is requested to assign an IPv4 Special-Purpose Address
   (192.0.0.11/32 suggested) and record this assignment in the IANA IPv4
   Special-Purpose Address Registry as follows:

     Address Block:         TDB2 /32
     Name:                  Babel dummy address
     RFC:                   [this document]
     Source:                True
     Destination:           False
     Forwarable:            False
     Globally Reachable:    False
     Reserved-by-Protocol:  False

> Intended status is now Standards Track.  I do have some misgivings, but

OK

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