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

Speaking just as a Babel working group member:

I view the source IP address of an ICMP as helping to identify, to the
extent it can without undue effort, the router that generated the ICMP. And
I agree that we should minimally constrain the Babel router consistent with
that.

   1. Obviously, if you are generating an ICMP to send out an interface and
   that interface has an IPv4 address, that's the address you use.
   2. If the interface does not have an IPv4, then the router MAY use the
   IPv4 address of any other interface or an IPv4 address that it has been
   configured to use for this purpose.
   3. If no IPv4 address is available as listed in 1. and 2., then it is
   RECOMMENDED that the Babel router dynamically generated a "Link Local" IPv4
   address [RFC3927] and use that as the ICMP source IP address.
   4. if none of the above are available or convenient, a Babel router MUST
   use the Babel dummy IPv4 address TBD (value 192.0.0.11 suggested).

If people think this is too complex, step 3 could be dropped but it
provides a significant improvement in identifying the ICMP source Babel
router. There are plenty of "MAY"s and a RECOMMENDED in there so someone
who just doesn't feel like implementing all this can skip most parts. I
think we should get a Babel specific dummy address for the last resort step
because it should be easy and it provides a tiny bit more identification
than, for example, using the generic dunn IPv4 address.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e3e3@gmail.com

On Thu, Apr 8, 2021 at 11:54 AM David Schinazi <dschinazi.ietf@gmail.com>
wrote:

> On the topic of the ICMP IPv4 source address, I agree with Juliusz.
> The specific value of that field is not required for interop, so in the
> spirit of Babel specs we shouldn't over-constrain implementations.
> Saying that routers need to be able to send ICMPv4 seems like the
> right choice here. I would suggest adding some implementation
> advice saying that using the same address (e.g. the dummy address
> <https://datatracker.ietf.org/doc/html/rfc7600#section-4.8>)
> on all routers is simplest but using different addresses can simplify
> debugging.
>
> On the topic of standards/experimental, I think that this specification
> matches the maturity required of a proposed standard as defined in
> RFC 2026 Section 4.1.1
> <https://datatracker.ietf.org/doc/html/rfc2026#section-4.1.1>. When RFC
> 1883 <https://datatracker.ietf.org/doc/html/rfc1883> was published in
> 1995,
> I don't think that IPv6 had a lot of implementation and deployment
> experience. But I don't feel too strongly here, as the consumers of
> RFCs generally don't look at the track/category when deciding what
> or how to implement.
>
> David
>
> On Thu, Apr 8, 2021 at 7:22 AM Toke Høiland-Jørgensen <toke=
> 40toke.dk@dmarc.ietf.org> wrote:
>
>> Juliusz Chroboczek <jch@irif.fr> writes:
>>
>> >> There is one other question in my mind. Does this draft really need to
>> >> be Experimental? I would be inclined to target it to Proposed Standard.
>> >
>> > I'm a little uneasy on this subject.  My personal feeling is that we
>> > haven't done our homework on this extension (admittedly my fault), and
>> > that we don't have enough implementation and deployment experience to
>> > propose it as a standard right now.
>> >
>> > I'd be delighted if people could disagree.
>>
>> Isn't that just a matter of time? I.e., we could adopt it as PS, with
>> the expectation that by the time it gets published we will have built
>> that experience? Or does there even need to be a final decision about
>> the status at adoption time?
>>
>> -Toke
>>
>> _______________________________________________
>> babel mailing list
>> babel@ietf.org
>> https://www.ietf.org/mailman/listinfo/babel
>>
>