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

[Donald Eastlake <[e-mail]>]

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.

On Tue, Apr 13, 2021 at 9:11 AM Juliusz Chroboczek <[e-mail]> wrote:
>
> > 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.
>
> 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).

 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.

> 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.

Another reason to go with a Babel dummy address.

> 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.

Sounds reasonable.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   [phone] (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 [e-mail]

> Ok?  If not, yell!
>
> -- Juliusz