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

[Juliusz Chroboczek <[e-mail]>]

Thanks for your review, Donald.

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

Right.

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

[...]

> Anyway, I think there should be some sort of reference in passing to
> "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.)

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

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?

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

Agreed.

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

> While there haven't been a lot of comments on this, I think that so
> 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