[IPv6]Re: Adoption call for draft-bonica-6man-deprecate-router-alert

[Bob Hinden <[e-mail]>]

Brian,

> On Jun 12, 2024, at 1:37 PM, Brian E Carpenter <[e-mail]> wrote:
> 
> On 13-Jun-24 03:18, Bob Hinden wrote:
>> Ron,
>> On Jun 12, 2024, at 8:06 AM, Ron Bonica <[e-mail]> wrote:
>>> 
>>> Bob,
>>> 
>>> Thanks for posing the most interesting architectural question!
>>> 
>>> The HBH Processing draft positions the HBH Options Extension Header as a clean mechanism for signaling through the IPv6 forwarding plane without touching the control plane or exposing it to additional vulnerabilities. The Router Alert option compromises that architectural goal by allowing packets to weave in and out, between the forwarding and control planes.
>>> 
>>> If a new protocol needs to weave in and out between the control and forwarding planes, it can do so by addressing its packets to the node whose control plane it needs to touch. This strategy has been demonstrated by RSVP-TE. Its benefits are:
>>> 
>>> *
>>>    It has been deployed on the global internet (i.e., across domains)
>>> *
>>>    It can be ACL'd by simply examining the destination address and next (non-IPv6) header. There is no need for the ACL mechanism to parse the HBH Options header
>>> 
>>> 
>> It might be helpful if the draft included discussion about how to retrain this property without using Router Alert.  Especially discussing MLD.
> 
> I think MLD is a rather special case, since it is confined to a very local scope and it doesn't involve "alerting" routers at an unknown point potentially on the other side of the world.
> 
> RFC3810:
> "All MLDv2 messages
> described in this document MUST be sent with a link-local IPv6 Source
> Address, an IPv6 Hop Limit of 1, and an IPv6 Router Alert option
> [RFC2711] in a Hop-by-Hop Options header.  (The Router Alert option
> is necessary to cause routers to examine MLDv2 messages sent to IPv6
> multicast addresses in which the routers themselves have no
> interest.)"
> 
> As far as I can tell, if Router Alert didn't exist, MLD would have needed to define it.
> 
> This is worth underlining in the draft because (a) it really is a MUST, and (b) the hop limit of 1 means that it really does only concern the LAN router and has no implications for WAN routers.

All good points to describe, it is a different use case.

Bob



> 
>    Brian
> 
>> Bob (w/ no hats)
>>>                                                                                                           Ron
>>> 
>>> 
>>> Juniper Business Use Only
>>> 
>>> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>>> *From:*Bob Hinden <[e-mail] <mailto:[e-mail]>>
>>> *Sent:*Tuesday, June 11, 2024 11:55 AM
>>> *To:*IPv6 List <[e-mail] <mailto:[e-mail]>>
>>> *Cc:*Bob Hinden <[e-mail] <mailto:[e-mail]>>; 6man Chairs <[e-mail] <mailto:[e-mail]>>;[e-mail] <mailto:[e-mail]><[e-mail] <mailto:[e-mail]>>
>>> *Subject:*Re: Adoption call for draft-bonica-6man-deprecate-router-alert
>>> [External Email. Be cautious of content]
>>> 
>>> 
>>> Hi,
>>> 
>>> With no hats on.
>>> 
>>> My thoughts on deprecating Router Alert is what was written in Section 5.2.1 of the HBH Processing draft (now in RFC Editor queue):
>>> 
>>>       DISCUSSION
>>> 
>>>       The function of a Router Alert Option can result in the processing
>>>       that this specification is proposing to eliminate, that is, to
>>>       instruct a router to process the packet in the control plane.
>>>       This results in the concerns discussed in section 4.  One approach
>>>       would be to deprecate this, because current usage beyond the local
>>>       network appears to be limited, and packets containing Hop-by-Hop
>>>       options are frequently dropped.  Deprecation would allow current
>>>       implementations to continue and its use could be phased out over
>>>       time.
>>> 
>>>       The Router Alert Option could have a potential for use with new
>>>       functions that have to be processed in the control plane.  Keeping
>>>       this as the single exception for processing in the control plane
>>>       with the following restrictions is a reasonable compromise to
>>>       allow future flexibility.  These restrictions are compatible with
>>>       Section 5 of [RFC6398].
>>> 
>>> My question is do we want to disable the possibility of any new functions that need Router Alert in the future.
>>> 
>>> Bob
>>> 
>>> 
>>> 
>>> > On Jun 10, 2024, at 4:23 PM, Jen Linkova <[e-mail] <mailto:[e-mail]>> wrote:
>>> >
>>> > This email starts 6MAN adoption call for the following document:
>>> >
>>> > Title : Deprecation Of The IPv6 Router Alert Option
>>> > Authors : Ron Bonica
>>> > Date : 2024-02-19
>>> >
>>> >https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-bonica-6man-deprecate-router-alert/__;!!NEt6yMaO-gk!CmCegd8V41HWGLJly2mqXbYx0AwGFa6dv4knJdVkLfmlQRCdNqHTUVtGQ5yfA2rqkdAZnI3aY_VTaJ06BDI$ <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-bonica-6man-deprecate-router-alert/__;!!NEt6yMaO-gk!CmCegd8V41HWGLJly2mqXbYx0AwGFa6dv4knJdVkLfmlQRCdNqHTUVtGQ5yfA2rqkdAZnI3aY_VTaJ06BDI$>
>>> >
>>> > Substantive comments, statements of support for adopting this
>>> > document or objections to the adoption should be sent to the mailing
>>> > list.  Editorial suggestions can be sent to the authors.
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [e-mail]
>> Administrative Requests:
>> --------------------------------------------------------------------
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests:
> --------------------------------------------------------------------