[Int-area] Re: Gorry Fairhurst's No Objection on draft-ietf-intarea-v4-via-v6-08: (with COMMENT)

[Gorry Fairhurst <[e-mail]>]

On 23/07/2026 12:13, Warren Kumari wrote:
>
>
>
>
> On Tue, Jun 30, 2026 at 4:19 PM, Gorry <[e-mail]> wrote:
>
>     See below marked [gf]
>
>         On 30 Jun 2026, at 15:05, Juliusz Chroboczek <[e-mail]
>         <mailto:[e-mail]>> wrote:
>
>         Hello Gorry,
>
>             (1) I expect some of the text ought to be about forwarding
>             rather than routing? - I see Med made many comments,
>
>         Done (following Mohamed's guidance).
>
>             (2) Current text:
>             there is nothing
>             preventing an IPv6 packet from being routed through a next
>             hop with an IPv4 address (in which case the next hop's MAC
>             address will be obtained using ARP), or, conversely, an
>             IPv4 packet from being routed through a next hop with an
>             IPv6 address.
>             - This text seems to detail IPv4, but not the same level
>             of detail for the IPv6 case. This ought also to mention
>             how that uses ND and other methods, to complete the
>             equivalent to arp?
>
>         Done.
>
>             (3) I'd encourage adding a reference for RFC 8899,
>             alongside the existing referene to RFC 4821.
>
>         Done. (I wasn't aware of this spec.)
>
>             (4) The text currently says:
>             "PMTUd may lead to persistent black-holing of IPv4 traffic."
>             - But not if using RFC 8899?
>
>         I think we're in agreement. What we're saying is that while
>         there exist techniques that avoid this issue, since they are
>         not universally deployed, we cannot afford to not send ICMPv4.
>
>         (Aside: I fully agree with you that we should strive to retire
>         RFC 1191. See for example slide 7 of [1]. Aside ends.)
>
>         [1]:
>         https://datatracker.ietf.org/meeting/110/materials/slides-110-babel-babel-source-specific-and-v4-via-v6-02
>         <https://datatracker.ietf.org/meeting/110/materials/slides-110-babel-babel-source-specific-and-v4-via-v6-02>.
>
>
>             (5) Perhaps obvious to some, but to forward IPv6 packets
>             there must be an IPv4 interface MTU of at least 1280 bytes
>             (the minimum for IPv6): Could something be said?
>
>         I think we're in the good case here: if an interface has IPv6
>         enabled, then its MTU must be at least 1280 octets, hence it's
>         fine to install an IPv4 route though it. (If the interface was
>         not provisioned with IPv6, then obviously it won't work to
>         install a v4-via-v6 route through it, since there's no IPv6
>         neighbour discovery protocol.)
>
>             (6) I am curiuous whether thought was given to multicast
>             routing, or whether that was out-of-scope
>
>         I've given a lot of thought to multicast (I blame Tony P.),
>         only to come to the conclusion that it's beyond my
>         intellectual capabilities. So I really have nothing useful to
>         say about multicast.
>
>             I expected something to be said.
>
>         I'm not to keen on speaking about things I don't understand,
>         so if you insist on something being said, I'll need more
>         precise guidance.
>
>     [gf] ~ I would be happy with simply stating (if it is true):
>     — This method does not support multicast forwarding. Or (if more
>     appropriate)
>     — The scope of this specification is unicast forwarding. The
>     specification does not specify support for multicast forwarding.
>
>
> I''ve been noodling on this, and AFAICT, "The scope of this 
> specification is unicast forwarding. The specification does not 
> specify support for multicast forwarding." works.
>
>
>     - or anything similar.
>
>             NiT: There was one use of /don't/ - is it worh making this
>             /do not/?
>
>
> Sure, why not….
> W
>
>
>         Fixed, thanks.
>
>         -- Juliusz
>
>     Thanks for addressing the other comment,
>
>     Gorry
>
>
:-)

Gorry