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>
ha scritto:

> Fair enough.
>
>
>
>                       Ron
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* Tom Herbert <tom@herbertland.com>
> *Sent:* Saturday, January 6, 2024 4:22 PM
> *To:* Ron Bonica <rbonica@juniper.net>
> *Cc:* Jen Linkova <furry13@gmail.com>; 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
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
>
>
> On Sat, Jan 6, 2024, 12:57 PM Ron Bonica <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>
> *Sent:* Saturday, January 6, 2024 11:19 AM
> *To:* Ron Bonica <rbonica@juniper.net>
> *Cc:* Jen Linkova <furry13@gmail.com>; 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
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
>
>
> On Fri, Jan 5, 2024, 4:35 PM Ron Bonica <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>
> Sent: Friday, January 5, 2024 5:56 PM
> To: Jen Linkova <furry13@gmail.com>
> 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
>
> [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> 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 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
> > 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
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>