Re: [pim] pim-ipv4-prefix-over-ipv6-nh WGLC

[Stig Venaas <[e-mail]>]

Hi Toerless

Appreciate getting good feedback. The WG is way too quiet. Please see inline.

On Wed, Aug 15, 2018 at 8:25 PM, Toerless Eckert <[e-mail]> wrote:
>
> Had not read the document for Montreal, sorry.
> Did not find discsussions on ML.

Yes, it's been too quiet.

> It would be good if one of the co-authors would do a
> spell/grammer fixup on the document before passing it to IETF/IESG
> review. Forces those reviewers to focus more on paylod feedback ;-))
> (btw: i am bad on my own documents on this as well).

I'll get this done for sure.

> Is the example topology in figure 1 an eBGP peering ? If so, please
> say so in text, otherwise maybe explain a bit more.

Will do.

> What would be a reason to use a setup as in the example topology,
> for unicast only, e.g.: in the absence of multicast ? I can think
> of two reasons only: one is that you want to avoid IPv4 address
> space use, aka: make your IPv4 forwarders unnumbered on the interface
> for simplifiction. The other one is that three is some form of
> benefit of just having a single address familiy BGP connection.

Yes, it is to minimize control plane and maybe management overhead. For
whichever reason people have decided to deploy RFC 5549 for unicast, they
wish to use the reachability information for multicast. They prefer not to
change their unicast deployment to support multicast.

> I am asking, because as soon as you bring in IP multicast, the solution
> proposes that you now must have an IPv4 address to support PIM on the
> interface. And if one goal of the setup was to be unnumbered on IPv4,
> then that goal would be violated. And once you do have IPv4 addressing,
> its unclear to me what the benefit is to only haven an IPv6 peering
> with mixed address families vs. simple separate IPv4 vs. IPv6 peerings
> that match the forwrding plane.
>
> Or the other way around: If you want to get rid of IPv4 signaling, why
> then do we not better define how to send PIM joins for IPv4
> groups/channels via PIM IPv6 ? If i remember it correctly, all
> the address elements in PIM messages do explicitly indicate the AF
> as well.

Sure, and this is maybe something we should do. I think networks that
use 5549 would be quite happy if this was possible. This draft is just a
minor improvement to at least allow them to simplify unicast.

> Another concern is that it may be somewhat risky to introduce this option
> such a long time after the option was specified but not used. As in:
> this might be a great attack vector to crash a neighboring, badly
> implemented PIM neighbor acting extremely surprised seeing such an
> unexpected AF. For "friedly" evolution of signaling, it might be
> better to use a new code point instead.

Note that this option is widely implemented for IPv6, so it is being used.
I doubt IPv4 implementations support it though, unless there is an AF
independent implementation that includes this in their AFI code. If they
ignore the option, then they won't be affected by this. If they did
implement it for IPv4 but don't check the AF (not that 7761 does not
require the AF to match the AF of the pim packet), then in the worst case
they end up with a list of wrong/invalid IPv4 addresses. I think this is
unlikely though, and it should not cause a crash. That one hello option
has unexpected content, should not cause a crash. If it does, then that
is a severe security issue and a broken implementation.

Finally, the use of this option is in line with 7761. It is just an
informational
document saying that it can be useful to use a different AF for the address
list option from the AF of the pim packet. Since this is already shipping, it
would be good to have it documented. And hopefully if other vendors have
customers asking for a solution for RFC 5549 deployment, they will then
consider solving it in the same way.

Thanks,
Stig

> Cheers
>     Toerless
>
> On Tue, Aug 14, 2018 at 01:23:36AM +0000, Michael McBride wrote:
>> Hello folks,
>>
>> Today begins a two week wglc for informational draft: https://tools.ietf.org/html/draft-ietf-pim-ipv4-prefix-over-ipv6-nh-02. Please give it a read (it's 4 pages) and provide feedback on it's readiness to be sent to the IESG for publication. In Montreal we had 3 in favor, none against. What say you?
>>
>> Thanks,
>> mike
>
>> _______________________________________________
>> pim mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/pim
>
>
> --
> ---
> [e-mail]
>
> _______________________________________________
> pim mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pim