Re: [IPv6] Working Group Last Call for draft-ietf-6man-comp-rtg-hdr

Cioa Antonio,

I just worked with Ron on creating Section 13 (“Experimental Results”) in the -02 version. You’ll notice there that one of the suggestions is that results of the experiment should be collected and reported, and that this should include information about interoperability. Interoperability is clearly an important aspect of deployability.

That said, this document is proposed as an Experimental RFC and that is very different from a Standards Track document. The intention is to encourage implementation and experimentation, not to (immediately) produce a specification. Thus, Section 12 describes the implementation status at the time of publication, and is not a full report of the experiment. (FWIW, my advice is that Section 12 should be removed before publication as an RFC with a new “living document” created on a wiki, in github, or in a new draft, so that it can be updated to collect more information about experimentation.)

Lastly, you say that “open source implementations are reported in the paper”, but I find no such reference in this version of any of the previous versions. Just the text in Section 12 reporting on two private implementations (one on hardware and one in a software router).

Cheers,

Adrian

From: ipv6 <ipv6-bounces@ietf.org> On Behalf Of Antonio Cianfrani
Sent: 17 January 2024 23:00
To: Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>
Cc: 6man <ipv6@ietf.org>; draft-ietf-6man-comp-rtg-hdr@ietf.org
Subject: Re: [IPv6] Working Group Last Call for draft-ietf-6man-comp-rtg-hdr

Dear Authors,

in my opinion there are some open issues that should be clarified:

- it seems that the solution is implemented on a single vendor devices: maybe an interoperability test with other vendors is necessary.

- open source implementations are reported in the paper but no reference is provided (and I couldn’t find it on the web).

Best regards,

Antonio

Il Sab 6 Gen 2024, 22:40 Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org <mailto:40juniper.net@dmarc.ietf.org> > ha scritto:

Fair enough.

                      Ron

Juniper Business Use Only

From: Tom Herbert <tom@herbertland.com <mailto:tom@herbertland.com> > 
Sent: Saturday, January 6, 2024 4:22 PM
To: Ron Bonica <rbonica@juniper.net <mailto:rbonica@juniper.net> >
Cc: Jen Linkova <furry13@gmail.com <mailto:furry13@gmail.com> >; 6man <ipv6@ietf.org <mailto:ipv6@ietf.org> >; draft-ietf-6man-comp-rtg-hdr@ietf.org <mailto:draft-ietf-6man-comp-rtg-hdr@ietf.org> 
Subject: Re: [IPv6] Working Group Last Call for draft-ietf-6man-comp-rtg-hdr

[External Email. Be cautious of content]

On Sat, Jan 6, 2024, 12:57 PM Ron Bonica <rbonica@juniper.net <mailto:rbonica@juniper.net> > wrote:

Tom,

Revealing the ultimate destination address to intermediate nodes has never been an explicitly stated requirement of the IPv6 Routing header. Therefore, it is beyond the scope of the current experiment.

Ron,

It may not be an explicit protocol requirement, but as I pointed out it may be an implicit operational requirement at least in some networks. Even if there's not a solution in this draft, I think it's worth mentioning in the draft the loss of visibility of the final destination and potential ramifications.

Tom

However, that doesn’t close the door to subsequent experiments. Please feel free to post a follow up draft.

                                                                                               Ron

Juniper Business Use Only

From: Tom Herbert <tom@herbertland.com <mailto:tom@herbertland.com> > 
Sent: Saturday, January 6, 2024 11:19 AM
To: Ron Bonica <rbonica@juniper.net <mailto:rbonica@juniper.net> >
Cc: Jen Linkova <furry13@gmail.com <mailto:furry13@gmail.com> >; 6man <ipv6@ietf.org <mailto:ipv6@ietf.org> >; draft-ietf-6man-comp-rtg-hdr@ietf.org <mailto:draft-ietf-6man-comp-rtg-hdr@ietf.org> 
Subject: Re: [IPv6] Working Group Last Call for draft-ietf-6man-comp-rtg-hdr

[External Email. Be cautious of content]

On Fri, Jan 5, 2024, 4:35 PM Ron Bonica <rbonica@juniper.net <mailto:rbonica@juniper.net> > wrote:

Hi Tom,

I believe that we have discussed this topic before, but it may have been off-list. So, I will repeat my argument on list.

When considering your objection, we must consider:

- its scope
- the cost / benefit trade-off

Regarding scope, you comment applies to many routing header compression scheme's not only the CRH. So, we should search for a solution that addresses all routing header compression schemes, not just the CRH.

Hi Ron,

Agreed.

Regarding the cost / benefit trade-off, some operators may be concerned about the issue that you raise. They would be willing to sacrifice a few bytes of overhead for the additional functionality that you propose. Other operators, not so much.

Yes, this trade-off could be one of the questions answered in the experiment.

So, it seems that we should look for a solution that a) is applicable to many routing header compression scheme's and b) is optional. Clause a) precludes a solution that is embedded in the CRH.

What do you think of a HBH Option that displays the ultimate destination. This can apply to any routing header compression scheme. It is also optional. If you like the idea, I would support a draft.

No, I suspect a new HBH option for this would be overkill.

Since this is experiment, how about defining two routing header types for CRH where last SID is compressed, and one where it's not. The additional processing and implementation complexity for the handling two variants shouldn't be very significant, and both could be deployed side-by-side. It would allow us to get feedback from real use cases, particularly on rather a FIB containing all possible final destinations is scalable.

Tom

                                                                        Ron

Juniper Business Use Only
-----Original Message-----
From: Tom Herbert <tom@herbertland.com <mailto:tom@herbertland.com> >
Sent: Friday, January 5, 2024 5:56 PM
To: Jen Linkova <furry13@gmail.com <mailto:furry13@gmail.com> >
Cc: 6man <ipv6@ietf.org <mailto:ipv6@ietf.org> >; draft-ietf-6man-comp-rtg-hdr@ietf.org <mailto:draft-ietf-6man-comp-rtg-hdr@ietf.org> 
Subject: Re: [IPv6] Working Group Last Call for draft-ietf-6man-comp-rtg-hdr

[External Email. Be cautious of content]

Hi,

I have a concern with this proposal. As I understand it, the addresses of all intermediate destinations and the final destination can only be correctly deduced with access to the external state (the CRH-FIB). In particular, the final destination address can no longer be deduced by simple inspection of the packet contents. I think it may have ramifications on debugging and security. I suspect this also would be a concern for SR CRH.

This will make much hardware to track and diagnose flows in the network. Also, if the destination is obfuscated the TCP and UDP checksum cannot be validated in the network (strictly not needed, however it is done when debugging corrupted checksums. Even if the diagnostic tools do have access to the FIB, it has to be the correct FIB in time. So to do post mortem analysis on a flow could only be done if the correct state is accessed for when the packet was accessed.

Security may be a problem due to the potential of misdelivery. Correct delivery depends on FIB state being correct and synchronized between nodes. Presumably, misdelivery would be detected by transport layer checksum with pseudo header, however not all protocols have a checksum, and RFC6936 allows UDPv6 to be sent with a zero checksum in the case of tunnels.

To avoid ambiguity and misinterpretation, I suggest that the final address in the SIDs should be sent uncompressed as a plain address or compressed using some stateless method. I think this also could reduce the size of the FIB table since final destinations are likely to be hosts and there may be an order of magnitude more hosts than routers in the network.

Tom

On Thu, Jan 4, 2024 at 1:09 PM Jen Linkova <furry13@gmail.com <mailto:furry13@gmail.com> > wrote:
>
> This message starts a new two week 6MAN Working Group Last Call on
> advancing "The IPv6 Compact Routing Header (CRH)" document
> (https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ie <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ie> 
> tf-6man-comp-rtg-hdr/__;!!NEt6yMaO-gk!CWvVGIuSGSWauTRliWk7FJg8VvZNfVPLMcMeOdaUrfqmrfb7flEI0bndmOe3UuwngN0gXiuPTOerJkI$ ) as an Experimental document.
>
> Substantive comments and statements of support for publishing this
> document should be directed to the ipv6@ietf.org <mailto:ipv6@ietf.org>  mailing list.
> Editorial suggestions can be sent to the authors.  This last call will
> end on Jan 21 2024, 23:59:59 UTC.
>
> --
> Cheers, Jen Linkova on behalf of 6MAN chairs
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org <mailto:ipv6@ietf.org> 
> Administrative Requests:
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6 <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ipv6> 
> __;!!NEt6yMaO-gk!CWvVGIuSGSWauTRliWk7FJg8VvZNfVPLMcMeOdaUrfqmrfb7flEI0
> bndmOe3UuwngN0gXiuPTMIkwPI$
> --------------------------------------------------------------------

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org <mailto:ipv6@ietf.org> 
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------