Re: [IPv6] Routing Headers and limited domains (Was Re: Adoption call for draft-bonica-6man-comp-rtg-hdr

[Mark Smith <[e-mail]>]

Hi All,

Further to Ron's email below, here is the other Standards track IETF
RFC that inserts and removes IPv6 EHs in-flight, also contrary to RFC
8200/Internet Standard 80.

RFC 6550, "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks"

As it mentions the term "IPv6" a total of 64 times, it obviously
implies that it is complying with RFC 8200/Standard 80.

This now expired Internet Draft may have been the document that made
me consider and realise the issues that "private" and non-compliant
limited domain modifications could cause. It specifically articulates
the thinking that in a limited domain ("managed domain"), fields can
be redefined, contrary to specifications.

Using the IPv6 Flow Label for Performance Measurement with Alternate
Marking Method in Segment Routing
https://datatracker.ietf.org/doc/html/draft-fioccola-spring-flow-label-alt-mark-01

The main reason this ID stood out to me was that I was involved in the
updating and current definition of the IPv6 Flow Label field that
resulted in RFC 6437 (RFC 6436 explains rationale for the update).

I suggested treating the flow label field similar to the DSCP field,
meaning a local network could change the Flow Label field to suit its
purposes.

However the outcome, which I agree with, is that a "flow" is an
end-to-end property and has semantics that are independent of any
networks the packet is carried across, so once the Flow Label value is
set, it should be left alone, and its structure and interpretation
should be consistent along the whole of the packet's path between the
packet's Source Address and Destination Address.

Regards,
Mark.


On Sat, 4 Nov 2023 at 08:49, Ron Bonica <[e-mail]> wrote:
>
> Mark,
>
>
>
> I believe that the two bullet points you provide in your email, below, contain the bare, unvarnished truth. The authority to act on these truth is with the IETF leadership. So, I have copied the IAB and IESG.
>
>
>
> IMHO, the IAB should issue a statement saying a) that RFC 8799 is not an IETF consensus document, b) restriction to a limited domain is not an excuse for violating an IETF standard, and c) restriction to a limited domain is not a sufficient mitigation of vulnerabilities. A Security Consideration section MUST specify what each node (not each limited domain) must do to protect itself from vulnerabilities.
>
>
>
>                                                                                    Ron
>
>
>
>
>
>
>
>
> Juniper Business Use Only
>
> From: Mark Smith <[e-mail]>
> Sent: Friday, November 3, 2023 12:22 AM
> To: Tony Przygienda <[e-mail]>
> Cc: Tom Herbert <[e-mail]>; 6man <[e-mail]>; [e-mail]; Chris Chaundy <[e-mail]>
> Subject: Re: [IPv6] Routing Headers and limited domains (Was Re: Adoption call for draft-bonica-6man-comp-rtg-hdr
>
>
>
> [External Email. Be cautious of content]
>
>
>
> [snip]
>
>
> When I was reviewing the limited domain ID, now RFC 8799, I realised I had a few concerns about the fundamental concept (which were ultimately addressed in RFC 8799):
>
>
>
> 1. declaring something a "limited domain" becomes a way to justify not following, and to dismiss the importance of not following certain IETF protocol specifications, while also still implying complying with them, by referring to them and referencing them in the RFC.
>
> 2. Vendors using 1. to implement their own proprietary extensions to protocols, yet still claiming to comply with an IETF protocols specification on their product specification sheets, hiding their proprietary extensions, which you may only discover after you've bought and then deployed their apparently compliant implementation.
>
>
>
>