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

Brian E Carpenter <brian.e.carpenter@gmail.com> Thu, 03 March 2022 20:48 UTC

Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51D793A03F5 for <ipv6@ietfa.amsl.com>; Thu, 3 Mar 2022 12:48:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.109
X-Spam-Level:
X-Spam-Status: No, score=-7.109 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ci8HV4cE13TY for <ipv6@ietfa.amsl.com>; Thu, 3 Mar 2022 12:48:39 -0800 (PST)
Received: from mail-pj1-x1036.google.com (mail-pj1-x1036.google.com [IPv6:2607:f8b0:4864:20::1036]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68CD63A033F for <ipv6@ietf.org>; Thu, 3 Mar 2022 12:48:39 -0800 (PST)
Received: by mail-pj1-x1036.google.com with SMTP id g7-20020a17090a708700b001bb78857ccdso8881205pjk.1 for <ipv6@ietf.org>; Thu, 03 Mar 2022 12:48:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=OuRYbTJNpZteybms1dXw7mKP/YsiZwILZnucKu6s9n4=; b=YoOCKm3jPwyVKirL8pMqbTZdsd+r6lFVNm1mUdeyb/lUr25Q7WotO0Ju34rJZXcAOp gm3/3Ux+5ChvqqKpadL8FONFTwOfdQcE+GS9xbe7xtGpdJaXLPf6fHdjZyNa2crf3BF9 SIWs4evkOp5J6a/NG+lwkSCpqRlTJUPT6/gg3QcKUCrG7AGLFEjnFUayXw2Hv8FW5cnO bYKg84ZFtUiEjvzhSJJjKv+Tee95yD5ZDHnnMcoIEO4O8L3olKwW0pw2/Exr+7IadEx9 WANttpL9z78f5HYldj2OfJqMIvXrGrBCx63nZMXb8zwQmFVxk2xbCDv5ERs1mKIMKnl4 uEew==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=OuRYbTJNpZteybms1dXw7mKP/YsiZwILZnucKu6s9n4=; b=TpMQfZbFdmqJ4jnsE8QMCYU6Pb9zgshbSabUV925HnTfCw4JKVBc0u9IJkaeTfcvYZ k2doHF/4DRZX7OzF8eluICv+xBTEXUDAoYDb0aSiIiI2clL/GDuzeBtGoZ8kgORbfzrW uIUgY9JqgOcBs3k/zWK+PHYPOTDFaqTdb6aynZqNhDYbZDkMi8SENCio/4ThR04rE54Z 6DhjXCuuxSKWASrr0y3nR35FpmZ77nTLdW5G5oXl5xF5Mym4eXAAhgCwPQZxbQPHJG6Y uzy6X2xt4vcM3mxSUQdeqBjbrTOMZWfAvQfP2rPspTCnBuNLNK8UI0BREKdFsp930hDo 2atQ==
X-Gm-Message-State: AOAM531pMPhlJljPSOIQ9fCePEktp1sJKt6PsY9mKRqLBl3R7H3nwIdD NTe1zhcJqt7GDdiJ1BikHBzSOy64naymxw==
X-Google-Smtp-Source: ABdhPJyjTtNSC+3BGFPzag/2vdXxwCJ/s3WGLrOoca4ULOvPh0gRjNen0Kc0RsL2/GKT7MXvVX+Ztw==
X-Received: by 2002:a17:90a:2b0d:b0:1b5:8087:4b4e with SMTP id x13-20020a17090a2b0d00b001b580874b4emr7242578pjc.70.1646340518463; Thu, 03 Mar 2022 12:48:38 -0800 (PST)
Received: from ?IPv6:2406:e003:1005:b501:80b2:5c79:2266:e431? ([2406:e003:1005:b501:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id o6-20020a17090ad20600b001b8d01566ccsm9105159pju.8.2022.03.03.12.48.35 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 03 Mar 2022 12:48:37 -0800 (PST)
Subject: Re: I-D Action: draft-bonica-6man-deprecate-router-alert-00.txt
To: Ron Bonica <rbonica@juniper.net>, Bob Hinden <bob.hinden@gmail.com>, Robert Raszuk <robert@raszuk.net>
Cc: IPv6 List <ipv6@ietf.org>
References: <9061a480-8338-43f0-8868-36942ecdd74d@gmail.com> <f819d5aa-8f97-02f7-91b5-bcb11969f0dc@gmail.com> <4F2A17EF-EA2A-422C-861D-911213EC482C@gmail.com> <BL0PR05MB53168C7E2A927A1F36ACD320AE049@BL0PR05MB5316.namprd05.prod.outlook.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <5b771dc7-980c-5142-2a1f-6f599bd0095f@gmail.com>
Date: Fri, 04 Mar 2022 09:48:33 +1300
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0
MIME-Version: 1.0
In-Reply-To: <BL0PR05MB53168C7E2A927A1F36ACD320AE049@BL0PR05MB5316.namprd05.prod.outlook.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/PVhJYUwFeMddSKP913PtBdYyASg>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Mar 2022 20:48:43 -0000

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 <ipv6-bounces@ietf.org> On Behalf Of Bob Hinden
> Sent: Wednesday, March 2, 2022 12:10 PM
> To: Brian Carpenter <brian.e.carpenter@gmail.com>
> Cc: IPv6 List <ipv6@ietf.org>; Bob Hinden <bob.hinden@gmail.com>
> 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 <brian.e.carpenter@gmail.com> 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 <brian.e.carpenter@gmail.com>
>> To: 6man <ipv6@ietf.org>
>>
>> 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, internet-drafts@ietf.org 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-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
>>> _______________________________________________
>>> I-D-Announce mailing list
>>> I-D-Announce@ietf.org
>>> 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
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------