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

[Brian E Carpenter <[e-mail]>]

On 04-Mar-22 10:13, Ron Bonica wrote:
> Brian,
> 
> Would you be less averse to the draft if:
> 
> - 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

> 
>                                               Ron
> 
> 
> 
> Juniper Business Use Only
> 
> -----Original Message-----
> From: Brian E Carpenter <[e-mail]>
> Sent: Thursday, March 3, 2022 3:49 PM
> To: Ron Bonica <[e-mail]>; Bob Hinden <[e-mail]>; Robert Raszuk <[e-mail]>
> Cc: IPv6 List <[e-mail]>
> Subject: Re: I-D Action: draft-bonica-6man-deprecate-router-alert-00.txt
> 
> [External Email. Be cautious of content]
> 
> 
> 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
> 
> On 04-Mar-22 09:40, Ron Bonica wrote:
>> 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 <[e-mail]> On Behalf Of Bob Hinden
>> Sent: Wednesday, March 2, 2022 12:10 PM
>> To: Brian Carpenter <[e-mail]>
>> Cc: IPv6 List <[e-mail]>; Bob Hinden <[e-mail]>
>> Subject: Re: I-D Action:
>> draft-bonica-6man-deprecate-router-alert-00.txt
>>
>> [External Email. Be cautious of content]
>>
>>
>> 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 <[e-mail]> wrote:
>>>
>>> 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 <[e-mail]>
>>> To: 6man <[e-mail]>
>>>
>>> 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, [e-mail] 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://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-b
>>>> onica-6man-deprecate-router-a__;!!NEt6yMaO-gk!VDaNVsvJ53vF78m1pxd4nV
>>>> W4Bsv-DghjHWuE9ZowRvsQvztuTgV46imGSeQYlA2P$
>>>> lert/ There is also an htmlized version available at:
>>>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/dr
>>>> aft-bonica-6man-deprecate-rou__;!!NEt6yMaO-gk!VDaNVsvJ53vF78m1pxd4nV
>>>> W4Bsv-DghjHWuE9ZowRvsQvztuTgV46imGSWMF3ZtC$
>>>> ter-alert-00 Internet-Drafts are also available by rsync at
>>>> rsync.ietf.org::internet-drafts
>>>> _______________________________________________
>>>> I-D-Announce mailing list
>>>> [e-mail]
>>>> 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_$
>>>
>>> --------------------------------------------------------------------
>>> IETF IPv6 working group mailing list
>>> [e-mail]
>>> Administrative Requests:
>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv
>>> 6__;!!NEt6yMaO-gk!VDaNVsvJ53vF78m1pxd4nVW4Bsv-DghjHWuE9ZowRvsQvztuTgV
>>> 46imGScKSZ_MK$
>>> --------------------------------------------------------------------