Re: [IPv6] New Version Notification for draft-bonica-6man-deprecate-router-alert-01.txt

['Toerless Eckert' <[e-mail]>]

On Wed, Feb 14, 2024 at 08:51:33PM -0000, Adrian Farrel wrote:
> Toerless,
> 
> I might agree with you that the specs should be "updated", but the fact is that implementations use the protocol number (46) rather than the RAO when the packet is not IP-addressed to the next hop.

I fail to parse and/or understand.
Ron claimed that RSVP-TE implementations are IP-addressing the next hop. Are you claiming this is not true ?
If what Ron says is true, then where in your experience is the case that the protocol number is "used"
(where "used" means i guess to extract the packet from the forwarding plane).

> Sadly, this is not the only issue in the RSVP/RSVP-TE that is cloudy or has changed by common usage. Once, long ago, I entirely rewrote 2205 and 3209, whereupon the person paying me at the time decided that the value was too high to share with the rest of the world. I substantially lack the energy to do this again.

Well, i was just suggesting to document the common usage of router alert (or rather its non-use
in situations including or like RSVP-TE), and not rewriting everything. And i would hope that
that router-alert specific update would be fairly limited. And the goal of course would be to
help avoiding the need for draft-bonica-6man-deprecate-router-alert, aka: well document how
it's not required where the IETF in RSVP still specifies it is needed. If that work would
not help with that goal then of course we can take that discuss away from this thread and
decide on it based on whatever other merits it may or may not have.

> RFC 6398 may be a useful read.

It was a good attempt, but is also making excuses for broken code that are incorrect.

   [RFC2113] specifies no (and [RFC2711] specifies a very
   limited) mechanism for identifying different users of IP Router
   Alert.  As a result, many fast switching implementations of IP Router
   Alert punt most/all packets marked with IP Router Alert into the slow path .

   Even though RFC2113 explicitly hints at what can be done in parenthesis:
   Routers that recognize this option shall
   examine packets carrying it more closely (check the IP Protocol
   field, for example) to determine whether or not further processing is
   necessary.

This misunderstanding proliferated by RFC6398 has been at the root of
the implementation problems.

> https://datatracker.ietf.org/doc/draft-rahman-rtg-router-alert-dangerous/ is an interesting precursor

Yes, and better than RFC6398:
   A router SHOULD inspect Router Alert packets before sending them to 
   the "slow path" so that if the protocol to which a packet belongs is 
   not enabled on the router or on the incoming interface (physical or 
   virtual), then the packet is dropped. 

> And https://datatracker.ietf.org/doc/draft-ietf-mpls-lspping-norao/ is in the pipe, although not directly related.

Not going to read this right now, but wrt to all this fuzz about supposed attack vectors from
RAO: I can do the same type of attack vectors with TTL expiry, which is also how traceroute
manages to do hop discovery onpath. And i wonder if the Internet would work if it wasn't
for traceroute. And its kinda silly that the only way on how traceroute ever got to work was
not by using what the IETF explicitly designed for applications like tracreoute (RAO), but
instead workarounds that service provider would have a hard time to disable.

Filter and rate limiters are not evil, they are necessities for any IP networks. Singling out
router-alert for whats equally needed for other protocols just has us build more of those
worse workarounds like traceroute.

> Perhaps the clearest statement of a progression away from RAO in RSVP-TE is in RFC 3473 (GMPLS) where it says (section 10)
>    When a node is sending a Path, PathTear or ResvConf message to a node
>    that it knows to be adjacent at the data plane (i.e., along the path
>    of the LSP), it SHOULD address the message directly to an address
>    associated with the adjacent node's control plane.  In this case the
>    router-alert option SHOULD not be included.
> 
> It is notable, that many RSVP-TE implementations owe a lot to GMPLS these days.

Yes, nice. See above. Maybe there is not much more to write up for non-RAO use in RSVP-TE or
other appropriate deployments of RSVP. But happy to document the cases where RAO is
required.

Cheers
    Toerless

> Cheers,
> Adrian
> 
> -----Original Message-----
> From: ipv6 <[e-mail]> On Behalf Of Toerless Eckert
> Sent: 14 February 2024 19:22
> To: Ron Bonica <[e-mail]>
> Cc: [e-mail]
> Subject: Re: [IPv6] New Version Notification for draft-bonica-6man-deprecate-router-alert-01.txt
> 
> On Wed, Feb 14, 2024 at 04:23:00PM +0000, Ron Bonica wrote:
> > Toerless,
> > 
> > The base RSVP specification allows use of either the router alert or direct addressing.
> 
> Re-reading rfc2205 i can not find this to be true. "3.11.4 RSVP/Routing Interface" specifically
> does not not demand or describe that RSVP must be able to determine the next-hop upstream
> neighbor in the "Route Query" section. Only the next-hop interface.
> 
> > Early in the history of RSVP-TE, vendors agreed to use direct addressing and avoid the router alert. No RFC documents this agreement. It is just inherited wisdom.
> 
> You (MPLS community) should really make yourself honest and figure out where to
> best document this. I would propose we craft a small paragraph outlining this
> change from the RFC2205 spec and propose it as an rfc3209 Errata with target
> "waiting for document update". Aka: could move into any future RFC where
> it would make sense to attach "updates rfc3209" to it, or else it just stays
> an Errata. One could think of an equivalent errata for rfc2205 pointing to
> the rfc3209 errata as an example for the premise that router alert SHUOLD
> be replaced for applications that MUST be deployed with full and strict hop-by-hop support
> of RSVP.
> 
> We could write a short RFC that does this update to RFC3209/RFC2205, but
> given how it would have to discuss extending/modifying rfc2205/3.11.4, i fear
> we'd end up in TSVWG where nobody wants to remember RSVP ;-))
> 
> 
> But back to the purpose of this discuss: I think the RSVP-TE case is irrelevant
> as an argument to deprecate router-alert, because if we assume that RSVP-TE
> MUST always be hop-by-hop, then router-alert is misplaced there anyhow. It really
> only makes sense to use it, when you reasonably can not solve the problem with
> explicit addressing. But that does not imply that router-alert is misplaced for
> any other uses of RSVP.
> 
> The use of router-alert is to help solve the otherwise fairly
> difficult and most applications arguably impossible task to solve auto-discovery
> of the next node on a path supporting a particular feature (when it's not mandatory the next-hop).
> The discovery of a hop that's not the next-hop is the most obvious case, but
> when i was architecting that stuff, i also ran into problems even when there
> was hop-by-hop RSVP support. Namely in IP networks, the next-hop selection
> can be extremely difficult:
> 
> - There is no standard AFAIK in general for determining the ECMP next-hop
>   (tell me if that's not true in MPLS). Every router does its own
>   ECMP algo, and many even have configurable options.
> 
> - There may be even more complex routing than ECMP, such as policy routing.
> 
> Different vendors have done AFAIK different degrees of RSVP contrl plane being
> able to deal with different subsets of being able for RSVP to correctly determine
> the right next-hop in the presence of these various features. And given how
> RSVP-TE by itself is a way to take out all the complexities of advanced
> traffic steering from the routing underlay it is an ideal candidate for
> a simple routing underlauy where this is no problem for the next-hop
> (not sure about the ECMP part though..).
> 
> > Your reference to DETNET confuses me. I am by no means a DETNET expert, but I don't think that DETNET uses the Router Alert Option today. Does it?
> 
> For DetNet with MPLS forwarding plane we should be fine to use RSVP-TE as-is wrt. non-use of router-alert.
> 
> For DetNet with IP forwarding plane  or others there are a couple more issues to resolve, maybe lets take it offline.
> 
> > Let me try to restate your question in a more abstract way. You can tell me if I have understood the question correctly.
> > 
> > Node A sends packets to Node Z. These packets traverse Nodes B, C, D, etc. Nodes A and Z participate in a protocol. Some, but not all of the nodes along the path also participate in the protocol. You want the packet to reach the control plane on nodes that participate in the protocol. But you don't want the packet to disturb the control plane on nodes that do not participate in the protocol.
> >
> > Node A doesn't know which nodes the packet will traverse. Nor does Node A know which nodes on the path participate in the protocol.
> > 
> > How do we get the packet to the control plane on the nodes where it should visit the control plane? How do we avoid making the packet disturb the control plane on other nodes?
> > 
> > Am I understanding the question correctly?
> 
> Yes exactly. And router-alert is the answer how to do it. Especially given that
> the packet match required to determine whether to punt such a packet is the combination
> of both the extension header, but also the protocol field in that extension header.
> So a node can punt only the packets for the protocols that it does have running.
> Such as RSVP, but not PGM (which is a bit theoretical for IPv6 because there is no IPv6
> RFC for PGM, just for IPv4, but it would logically work the same).
> 
> Cheers
>     Toerless
> 
> >                                                           Ron
> > 
> > 
> > 
> > 
> > Juniper Business Use Only
> > 
> > ________________________________
> > From: Toerless Eckert <[e-mail]>
> > Sent: Monday, February 12, 2024 10:15 PM
> > To: Ron Bonica <[e-mail]>
> > Cc: Ole Troan <[e-mail]>; [e-mail] <[e-mail]>
> > Subject: Re: [IPv6] New Version Notification for draft-bonica-6man-deprecate-router-alert-01.txt
> > 
> > [External Email. Be cautious of content]
> > 
> > 
> > On Thu, Feb 01, 2024 at 09:26:41PM +0000, Ron Bonica wrote:
> > > Hi Toerless,
> > >
> > > In the next version of the draft, I will make a specific statement about MLD future versions.
> > >
> > > Sadly, RFC 2205 predates RSVP-TE, the only widely deployed RSVP implementation. I don't know which RFC talks about moving away from the Router Alert Option. But I do know that all of the major vendors made this move more than ten years ago.
> > 
> > Please find that reference, if it exists. I still can not see how this will work in incremental / partial
> > deployments where the upstream router is not necessarily an RSVP, but that next RSVP
> > router is maybe two hops away.
> > 
> > > Due to the nature of MPLS, RSVP-TE must be deployed on every node along the LSP. There is no partial deployment.
> > 
> > [ I would be careful with this notion when considering DetNet where we seem to be including all type of
> >   MPLS over IP/UDP type of solutions. And we have not gotten to the most desirable control plane. But i am
> >   a bit freaked out by these mix&match options anyhow, just saying ;-)) ]
> > 
> > So, if for all we have to care for operationally right now, MPLS has never integrated the mechanisms
> > for loose/incremental deployment with RSVP-TE, then your statement may be
> > correct for RSVP-TE, but it is not correct AFAIK for RSVP for IP.
> > 
> > And i am fully supportive of "Don't use Router Alert unless you can not come up with a better
> > solution", and for strict deployments of course that is easy. But that is completely different from fully deprecating it.
> > 
> > (for example, i wish we would have integrated router-alert into PIM in the 1990th to enable
> >  incremental deployment in enterprises. But we also thought that full/strict deployment was possible.
> >  Alas then we had to go to a lot less "full-upgrade-willing" set of communities than what you
> >  likely experienced with MPLS (aka: enterprises and the like).
> > 
> > Cheers
> >    Toerless
> > 
> > >
> > > Maybe we can use another protocol as an example.
> > >
> > >                                                                           Ron
> > >
> > >
> > >
> > > Juniper Business Use Only
> > >
> > > ________________________________
> > > From: Toerless Eckert <[e-mail]>
> > > Sent: Thursday, February 1, 2024 12:28 PM
> > > To: Ron Bonica <[e-mail]>
> > > Cc: Ole Troan <[e-mail]>; [e-mail] <[e-mail]>
> > > Subject: Re: [IPv6] New Version Notification for draft-bonica-6man-deprecate-router-alert-01.txt
> > >
> > > [External Email. Be cautious of content]
> > >
> > >
> > > On Thu, Feb 01, 2024 at 05:04:35PM +0000, Ron Bonica wrote:
> > > > Typical problem with those statements would be protocols that evolve but need to keep
> > > > backward compatibility. Asssume for example, MLDv3 would not want to break backward
> > > > compatibility and hence continues to use router-alert. Would it still be allowed under the
> > > > rule of your proposed RFC ?
> > > >
> > > > [RB] Absolutely. MLD is an existing protocol. MLDv3 would be a new version of an existing protocol.
> > >
> > > Would be good to maybe add a statement about that to the draft. Not that many existing
> > > protocols that rely on router alert AFAIK, so maybe even enumerate them.
> > >
> > > > > Yes, new protocols have an alternative to the Router Alert Option. RSVP offers a relevant case study (albeit and IPv4-based case study).
> > > > >
> > > > > Early implementations of RSVP used the IPv4 Router Alert Option. Most vendors abandoned that strategy because many operators block all packets containing the IPv4 Router Alert. (How little things have changed!) They migrated to a strategy where the RSVP packet is addressed to the router, and a Router Alert is not required.
> > > >
> > > > I am not aware of a working solution for this approach in incremental or non-full deployments.
> > > >
> > > > Aka: The reason for router-alert to be included in RSVP is that the packet is sent along the
> > > > path and picked up by the first router supporting RSVP. And ignored by intermediate routers.
> > > >
> > > > The workaround only works if every hop along the path supports and enables RSVP - because there
> > > > is no method to detect a router a few hops away reliably, especially in interdomain or more
> > > > complex routing intradomain deployments (traffic engineering etc).
> > > >
> > > > [RB] We have an existence proof of RSVP working without the Router Alert. The industry has also demonstrated that seamless migration is possible.
> > >
> > > Can you point me to the RFC where that mechanism is described ?
> > > RFC2205 does not have it.
> > >
> > > > [RB] I think that you have an interesting question, but I don't understand it. Could you describe a hypothetical new protocol that has this problem?
> > >
> > > Just incremental or partial deployment of such a protocol. E.g. you don't deploy it on
> > > all hops, but just those that have (to stick to the RSVP example) relevant resource reservation
> > > needs.
> > >
> > > Cheers
> > >     Toerless
> > > >
> > > > Cheers
> > > >     Toerless
> > > >
> > > > >
> > > > >
> > > > > Juniper Business Use Only
> > > > >
> > > > > ________________________________
> > > > > From: Ole Troan <otroan=[e-mail]>
> > > > > Sent: Wednesday, January 31, 2024 8:07 AM
> > > > > To: Ron Bonica <[e-mail]>
> > > > > Cc: [e-mail] <[e-mail]>
> > > > > Subject: Re: [IPv6] New Version Notification for draft-bonica-6man-deprecate-router-alert-01.txt
> > > > >
> > > > > [External Email. Be cautious of content]
> > > > >
> > > > >
> > > > > > I let this draft expire two years ago when I became too ill to pursue it. Now, I am happy to report, that I am feeling well enough to annoy you with it again 😉
> > > > > >
> > > > > > Let the food fight begin!
> > > > >
> > > > > I don’t think we should deprecate something unless we have a good alternative to solve the problem.
> > > > > Given that MLDv2 is a fundamental part of the IPv6 protocol suite.
> > > > > Have you thought about how MLD should work without the Router Alert option?
> > > > >
> > > > > O.
> > > > >
> > > > > >
> > > > > > Juniper Business Use Only
> > > > > > From: [e-mail] <[e-mail]>
> > > > > > Sent: Wednesday, January 31, 2024 7:51 AM
> > > > > > To: Ron Bonica <[e-mail]>
> > > > > > Subject: New Version Notification for draft-bonica-6man-deprecate-router-alert-01.txt
> > > > > >  [External Email. Be cautious of content]
> > > > > >
> > > > > >
> > > > > > A new version of Internet-Draft
> > > > > > draft-bonica-6man-deprecate-router-alert-01.txt has been successfully
> > > > > > submitted by Ron Bonica and posted to the
> > > > > > IETF repository.
> > > > > >
> > > > > > Name:     draft-bonica-6man-deprecate-router-alert
> > > > > > Revision: 01
> > > > > > Title:    Deprecation Of The IPv6 Router Alert Option
> > > > > > Date:     2024-01-31
> > > > > > Group:    Individual Submission
> > > > > > Pages:    8
> > > > > > URL:      https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-bonica-6man-deprecate-router-alert-01.txt__;!!NEt6yMaO-gk!Cwq66zb-C2k1NU93EXgMcuesx6u1_281vcN-JGNC3fdtm26405LpuNHWP079H8qnucFNqG98EJdr-0jRAHA7loJHZk2IdEY$
> > > > > > Status:   https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-bonica-6man-deprecate-router-alert/__;!!NEt6yMaO-gk!Cwq66zb-C2k1NU93EXgMcuesx6u1_281vcN-JGNC3fdtm26405LpuNHWP079H8qnucFNqG98EJdr-0jRAHA7loJHPvfO9fA$
> > > > > > HTMLized: https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-bonica-6man-deprecate-router-alert__;!!NEt6yMaO-gk!Cwq66zb-C2k1NU93EXgMcuesx6u1_281vcN-JGNC3fdtm26405LpuNHWP079H8qnucFNqG98EJdr-0jRAHA7loJHQZlElYI$
> > > > > > Diff:     https://urldefense.com/v3/__https://author-tools.ietf.org/iddiff?url2=draft-bonica-6man-deprecate-router-alert-01__;!!NEt6yMaO-gk!Cwq66zb-C2k1NU93EXgMcuesx6u1_281vcN-JGNC3fdtm26405LpuNHWP079H8qnucFNqG98EJdr-0jRAHA7loJHrefpBfo$
> > > > > >
> > > > > > Abstract:
> > > > > >
> > > > > >    This document deprecates the IPv6 Router Alert Option.  Protocols
> > > > > >    that use the Router Alert Option may continue to do so.  However,
> > > > > >    protocols standardized in the future must not use the Router Alert
> > > > > >    Option.
> > > > > >
> > > > > >
> > > > > >
> > > > > > The IETF Secretariat
> > > > > >
> > > > > >
> > > > > > --------------------------------------------------------------------
> > > > > > IETF IPv6 working group mailing list
> > > > > > [e-mail]
> > > > > > Administrative Requests: https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!Cwq66zb-C2k1NU93EXgMcuesx6u1_281vcN-JGNC3fdtm26405LpuNHWP079H8qnucFNqG98EJdr-0jRAHA7loJHUVRj0nM$
> > > > > > --------------------------------------------------------------------
> > > > >
> > > > >
> > > > >
> > > >
> > > > > --------------------------------------------------------------------
> > > > > IETF IPv6 working group mailing list
> > > > > [e-mail]
> > > > > Administrative Requests: https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!G2XQM1YGEbM8WxHJ8I4xgWlv9iLcy_cCL6zm1s4fjIRZ_2mmmawobJT8c8wezhw_VeDlh0YCepIr$
> > > > > --------------------------------------------------------------------
> > > >
> > > >
> > > > --
> > > > ---
> > > > [e-mail]
> > >
> > > --
> > > ---
> > > [e-mail]
> > 
> > --
> > ---
> > [e-mail]
> 
> -- 
> ---
> [e-mail]
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

-- 
---
[e-mail]