Subject: Fwd: I-D Action: draft-bonica-6man-deprecate-router-alert-00.txt

From: Brian E Carpenter <[email-masked]>
Date: Wed, 2 Mar 2022 09:07:24 +1300

Since we are still on the -00 draft, the points below have not been
addressed, so adoption seems premature to me. Also, because there are
clearly operational implementations, consulting v6ops seems advisable.

    Brian

-------- Forwarded Message --------
Subject: Re: I-D Action: draft-bonica-6man-deprecate-router-alert-00.txt
Date: Fri, 31 Dec 2021 13:48:33 +1300
From: Brian E Carpenter <[email-masked]>
To: 6man <[email-masked]>

Hi,

I get the motivation for this draft. However, I think it is a bit unclear
about what it actually implies.

Specifically, MLDv2 (RFC3810) is a MUST in Node Requirements (BCP220/RFC8504)
and Router Alert (RFC2711) is a MUST in MLDv2. Also, MLDv2 is a must-have
in the real world.

So

a) I think section 3 "Updates To RFC 2711" needs to make it clear that the
requirement for MLDv2 in BCP220 is not changed. You aren't proposing
to make RFC2711 obsolete, because it is a normative reference for MLDv2.
In fact, the draft doesn't update RFC2711 by even a comma, so the section
title is plain wrong.

b) I am not sure that this should be standards track. It seems to me much
more like an update to Node Requirements, i.e. its natural destination is
as an update of BCP220. By the way, BCP220 already says:
"The Router Alert option will need to be implemented whenever such
protocols that mandate its use are implemented." You probably want to
update that sentence. It could be updated to say:
"The Router Alert option MUST NOT be implemented unless such
protocols that mandate its use are implemented."

As far as I can tell there's nothing else in BCP220 that is affected,
but the practical implication is surely that no existing router that
supports MLDv2 will be touched.

Regards
     Brian Carpenter

On 31-Dec-21 11:50, [email-masked] wrote:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 
>          Title           : Deprecation Of The IPv6 Router Alert Option
>          Author          : Ron Bonica
> 	Filename        : draft-bonica-6man-deprecate-router-alert-00.txt
> 	Pages           : 8
> 	Date            : 2021-12-30
> 
> 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 datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-bonica-6man-deprecate-router-alert/
> 
> There is also an htmlized version available at:
> https://datatracker.ietf.org/doc/html/draft-bonica-6man-deprecate-router-alert-00
> 
> 
> Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts
> 
> 
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 1 Mar 2022 22:25:05 +0100

What is the reason if this is still actively used in production networks ?

Take https://datatracker.ietf.org/doc/html/rfc7506 as practical
example ....

If you still need to support it why to deprecate it or formally ban from
being used ?

Thx,
R.

On Fri, Dec 31, 2021 at 3:12 AM Joel M. Halpern <[email-masked]> wrote:

> As I read Ron's description, he was looking to make sure that no new
> standards attempted to use Router Alert.  Your proposed approach would
> not seem to accomplish that.
>
> Yours,
> Joel
>
> On 12/30/2021 7:48 PM, Brian E Carpenter wrote:
> > Hi,
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > [email-masked]
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Bob Hinden <[email-masked]>
Date: Wed, 2 Mar 2022 09:10:17 -0800

Hi,

[No hats on]

I reread the draft this morning.   I continue to support the idea of what this draft is attempting to do, that is, saying we should not define any new protocols that use router alert.   I think that falls within our usual definition of what it means to “deprecate” a protocol.

I agree with Brian that it the draft should be clearer as what what are the existing protocols being used that rely on router alert and that these can continue to us it.

Also, good to separate out the protocols that are known to use it operationally (MLDv2 and RSVP, I think) and the protocols that are defined to use it, but are not being used operationally (MRD, MPLS PING, NSIS?).   It would be good to get more data to confirm this to understand the impact.

However, I do wonder if this is solving a problem we think we have.  Is anyone thinking of using router alert for anything new?   Or are the guidelines in RFC6398 enough?  Or are we saying that RFC6398 didn’t go far enough?

Bob

> On Mar 1, 2022, at 12:07 PM, Brian E Carpenter <[email-masked]> wrote:
>

---

From: Ron Bonica <[email-masked]>
Date: Thu, 3 Mar 2022 20:40:15 +0000

Bob, Brian, and Robert,

Thanks for the review. I will try to address your comments in the next revision of the document. Specifically, I will add the following text.

Will this provide sufficient clarity?

                                                                                            Ron

====================================
Section X. RFC 6398 Considerations

RFC 6398 provides recommendations against using the Router Alert in the end-to-end open Internet and identifies controlled environments where protocols depending on Router Alert can be used safely.  However, RFC 6398 is silent regarding whether the IETF should specify new protocols that use the Router Alert Option. Therefore, one might infer that the IETF can specify new protocols that use the Router Alert Option, so long as they are deployed in controlled environments only. Network operators must exercise care not to deploy these protocols on the end-to-end open Internet, as doing so would create security vulnerabilities. 

This document recommends against specifying new protocol that use the Router Alert Option, regardless of whether they are deployed on the open Internet or in controlled environments. However, it allows legacy protocols [Section 3] to continue to use Router Alert Option. 

3.  Updates To RFC 2711

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.

Table 1 contains a list of protocols that use the IPv6 Router Alert Option.  There are no known IPv6 implementations of MPLS PING Neither INTSERV nor NSIS are widely deployed.  All NSIS protocol  EXPERIMENTAL.

      +====================+============+==========================+
      | Protocol                            | References      | Application                                    |
      +====================+============+==========================+
      | Multicast Listener           | [RFC3810]       | IPv6 Multicast                              |
      | Discovery Version           |                           |                                                         |
      | 2 (MLDv2)  *                     |                            |                                                        |
      +-------------------- -----------+--------------- ------+----------------------------------- ----+
      +-------------------------+---------------+----------------------------+
      | Multicast Router   | [RFC4286]  | IPv6 Multicast           |
      | Discovery (MRD) * |                     |                                      |
      +-------------------------+---------------+----------------------------+
      +----------------------- -+---------------+----------------------------+
      | MPLS PING **       | [RFC8029]  | MPLS OAM                |
      +------------------------+----------------+----------------------------+
      +------------------------+----------------+---------------------------+
      | Resource               | [RFC3175]  | Integrated Services   |
      | Reservation          | [RFC5946]  | (INTSERV) [RFC1633] (Not |
      | Protocol (RSVP)   | [RFC6016]  | Traffic engineering or |
      |     **                        | [RFC6401]  | MPLS signaling)          |
      +-----------------------+----------------+--------------------------------+
      +-------------    -------+------------+--------------------------+
      | Next Steps In      | [RFC5979]  | NSIS [RFC408 ]    |
      | Signaling (NSIS)  | [RFC5971] |                                |
       |                       **   |                     |                                |
      +---------------------  +----------------+---------- ------------+

         Table 1: Protocols That Use The IPv6 Router Alert Option

* Widey implemented
** No commercially available IPv6 implementations known

=======================================

Juniper Business Use Only

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Bob Hinden
Sent: Wednesday, March 2, 2022 12:10 PM
To: Brian Carpenter <[email-masked]>
Cc: IPv6 List <[email-masked]>; Bob Hinden <[email-masked]>
Subject: Re: I-D Action: draft-bonica-6man-deprecate-router-alert-00.txt

[External Email. Be cautious of content]

Hi,

[No hats on]

Bob

> Subject: Re: I-D Action: 
> draft-bonica-6man-deprecate-router-alert-00.txt
> I get the motivation for this draft. However, I think it is a bit 
> unclear about what it actually implies.
>
> Specifically, MLDv2 (RFC3810) is a MUST in Node Requirements
> (BCP220/RFC8504) and Router Alert (RFC2711) is a MUST in MLDv2. Also,
> MLDv2 is a must-have in the real world.
>
> So
>
> a) I think section 3 "Updates To RFC 2711" needs to make it clear that 
> the requirement for MLDv2 in BCP220 is not changed. You aren't 
> proposing to make RFC2711 obsolete, because it is a normative reference for MLDv2.
> In fact, the draft doesn't update RFC2711 by even a comma, so the 
> section title is plain wrong.
>
> b) I am not sure that this should be standards track. It seems to me 
> much more like an update to Node Requirements, i.e. its natural 
> destination is as an update of BCP220. By the way, BCP220 already says:
> "The Router Alert option MUST NOT be implemented unless such protocols 
> that mandate its use are implemented."
>
>> https://datatracker.ietf.org/doc/draft-bonica-6man-deprecate-router-a
>> lert/ There is also an htmlized version available at:
>> https://datatracker.ietf.org/doc/html/draft-bonica-6man-deprecate-rou
>> ter-alert-00 Internet-Drafts are also available by rsync at 
>> rsync.ietf.org::internet-drafts 
>> Internet-Draft directories: http://www.ietf.org/shadow.html or 
>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 4 Mar 2022 09:48:33 +1300

Thanks, subject to a typo check (e.g. "Widey implemented") this makes it much clearer.

That doesn't necessarily mean I agree, but it makes it clear what we are discussing.

Regards
    Brian

                     Ron
> RFC 6398 provides recommendations against using the Router Alert in the 
end-to-end open Internet and identifies controlled environments where protocols depending on Router Alert can be used safely.  However, RFC 6398 is silent regarding whether the IETF should specify new protocols that use 
the Router Alert Option. Therefore, one might infer that the IETF can specify new protocols that use the Router Alert Option, so long as they are deployed in controlled environments only. Network operators must exercise 
care not to deploy these protocols on the end-to-end open Internet, as doing so would create security vulnerabilities.
>        | Discovery Version           |                           |      
                                                   |
>        | Discovery (MRD) * |                     |                      
                |
>         |                       **   |                     |            
                    |
> I agree with Brian that it the draft should be clearer as what what are 
the existing protocols being used that rely on router alert and that these can continue to us it.
> However, I do wonder if this is solving a problem we think we have.  Is 
anyone thinking of using router alert for anything new?   Or are the guidelines in RFC6398 enough?  Or are we saying that RFC6398 didn’t go far enough?

---

From: Ron Bonica <[email-masked]>
Date: Thu, 3 Mar 2022 21:13:53 +0000

Brian,

Would you be less averse to the draft if:

- the intended status were BCP
- it didn’t update RFC 2711
- the title of Section 3 were changed

Anything else?

                                             Ron

-----Original Message-----
From: Brian E Carpenter <[email-masked]> 
Sent: Thursday, March 3, 2022 3:49 PM
To: Ron Bonica <[email-masked]>; Bob Hinden <[email-masked]>; Robert Raszuk <[email-masked]>
Cc: IPv6 List <[email-masked]>
Subject: Re: I-D Action: draft-bonica-6man-deprecate-router-alert-00.txt

Regards
    Brian

                     Ron
end-to-end open Internet and identifies controlled environments where protocols depending on Router Alert can be used safely.  However, RFC 6398 is silent regarding whether the IETF should specify new protocols that use the Router Alert Option. Therefore, one might infer that the IETF can specify new protocols that use the Router Alert Option, so long as they are deployed in controlled environments only. Network operators must exercise care not to deploy these protocols on the end-to-end open Internet, as doing so would create security vulnerabilities.
                                                   |
                |
                    |
>> a) I think section 3 "Updates To RFC 2711" needs to make it clear 
>> that the requirement for MLDv2 in BCP220 is not changed. You aren't 
>>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-b
>>> onica-6man-deprecate-router-a__;!!NEt6yMaO-gk!VDaNVsvJ53vF78m1pxd4nV
>>> W4Bsv-DghjHWuE9ZowRvsQvztuTgV46imGSeQYlA2P$
>>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/dr
>>> aft-bonica-6man-deprecate-rou__;!!NEt6yMaO-gk!VDaNVsvJ53vF78m1pxd4nV
>>> W4Bsv-DghjHWuE9ZowRvsQvztuTgV46imGSWMF3ZtC$
>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/i-
>>> d-announce__;!!NEt6yMaO-gk!VDaNVsvJ53vF78m1pxd4nVW4Bsv-DghjHWuE9ZowR
>>> vsQvztuTgV46imGSYuf1806$ Internet-Draft directories: 
>>> https://urldefense.com/v3/__http://www.ietf.org/shadow.html__;!!NEt6
>>> yMaO-gk!VDaNVsvJ53vF78m1pxd4nVW4Bsv-DghjHWuE9ZowRvsQvztuTgV46imGSXtt
>>> exQn$  or 
>>> https://urldefense.com/v3/__ftp://ftp.ietf.org/ietf/1shadow-sites.tx
>>> t__;!!NEt6yMaO-gk!VDaNVsvJ53vF78m1pxd4nVW4Bsv-DghjHWuE9ZowRvsQvztuTg
>>> V46imGSWzuoqq_$
>>
>> Administrative Requests: 
>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv
>> 6__;!!NEt6yMaO-gk!VDaNVsvJ53vF78m1pxd4nVW4Bsv-DghjHWuE9ZowRvsQvztuTgV
>> 46imGScKSZ_MK$

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 4 Mar 2022 10:26:38 +1300

> - the intended status were BCP

Would it then update RFC6398 (BCP168) in some way? And I still want to see
the relationship with Node Requirements (BCP220) clarifed. In any case, I 
don't
think we need yet another BCP number.

> - it didn’t update RFC 2711

Well, objectively it *doesn't* update the text of 2711 in any way, except 
possibly
as an applicability statement as described by RFC2026.

> - the title of Section 3 were changed

For example, to "Applicability of RFC2711"?

> Anything else?

Review by v6ops?

    Brian

>> Thanks for the review. I will try to address your comments in the next 
revision of the document. Specifically, I will add the following text.
> end-to-end open Internet and identifies controlled environments where protocols depending on Router Alert can be used safely.  However, RFC 6398 
is silent regarding whether the IETF should specify new protocols that use the Router Alert Option. Therefore, one might infer that the IETF can specify new protocols that use the Router Alert Option, so long as they are deployed in controlled environments only. Network operators must exercise care not to deploy these protocols on the end-to-end open Internet, as 
doing so would create security vulnerabilities.
>> 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.
>>         | 2 (MLDv2)  *                     |                           
 |                                                        |
>> Also, good to separate out the protocols that are known to use it operationally (MLDv2 and RSVP, I think) and the protocols that are defined to 
use it, but are not being used operationally (MRD, MPLS PING, NSIS?).   It would be good to get more data to confirm this to understand the impact.

---

From: Vasilenko Eduard <[email-masked]>
Date: Fri, 4 Mar 2022 13:57:06 +0000

Hi all,
I believe that it is a good idea to deprecate router alert a little.
My logic is like this:
Router alert is very expensive for the router control plane,
Hence, many people are trying to protect the router by filtering,
But filtering is typically available only for HbH or DO as a whole,
Hence, they kill HbH and DO in principle.
IMHO: router alert is not so valuable to pay by HbH and DO for it.

Yet, Brian is asking good questions for how to properly harmonize this half-deprecation with the rest of the documents.
It is probably possible to solve when the document would become WG draft.

It is needed in principle. It is just a question how to formalize it properly.

Eduard

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 4 Mar 2022 15:30:48 +0100

All,

I have a bit of a different opinion on this.

For example Figure 1 from the draft shows a very archaic view of reality.

Reality is that lot's of control plane functionality is already distributed
to the line cards. Some platforms also compute FIB on each line card
instead of getting dump from RP/RE like illustrated.

The trend to even further distributed packet and processing including
punting and exceptions handling is growing. Suffice to say that modern DPUs
and IPUs all process control plane and data plane in the NICs.

With that let's see how this is relevant to IPv6 ... We do see that not
everything already encoded in the v6 header can be processed in hardware.
There is trend of stuffing headers with more programmable functions which
quite likely would need to be processed outside of hardware data plane
perhaps in equally fast co-located NPUs.

So if this is something we need to face we may as well keep Router Alert as
it could turn quite useful as a standard way to punt feature hungry packets
to local (*still distributed*) high speed processing on the NIC or line
cards. If not this trigger some other trigger will be used to
accomplish exactly the same.

With that I am quite pessimistic of the proposal.

Thx,
Robert

On Fri, Mar 4, 2022 at 2:57 PM Vasilenko Eduard <vasilenko.eduard=
[email-masked]> wrote:

> Yet, Brian is asking good questions for how to properly harmonize this
> half-deprecation with the rest of the documents.