rt6: parse TLV

[giulio-sido]

Parse Type Length Values (TLV) in IPv6 Routing Header as specified by RFC 8754 [1].

[1] https://datatracker.ietf.org/doc/html/rfc8754

Signed-off-by: Giulio Sidoretti [email protected]

[giulio-sido]

Thanks for your comments, I have added these minor changes

[ahsalam]

@fxlb any update on this PR ?

@giulio-sido There is a couple of SRH TLVs defined in https://datatracker.ietf.org/doc/html/draft-ietf-spring-sr-service-programming-05#section-7.2.1. They are still waiting for Type assignment by IANA. When they get assigned a type, will you be willing to send one more PR to support them ?

Thanks!

[giulio-sido]

@giulio-sido There is a couple of SRH TLVs defined in https://datatracker.ietf.org/doc/html/draft-ietf-spring-sr-service-programming-05#section-7.2.1. They are still waiting for Type assignment by IANA. When they get assigned a type, will you be willing to send one more PR to support them ?

Sure. In the meantime, all TLVs with types that are not in the RFC 8754 are parsed as generic TLVs.

[ahsalam]

@giulio-sido There is a couple of SRH TLVs defined in https://datatracker.ietf.org/doc/html/draft-ietf-spring-sr-service-programming-05#section-7.2.1. They are still waiting for Type assignment by IANA. When they get assigned a type, will you be willing to send one more PR to support them ?

Sure. In the meantime, all TLVs with types that are not in the RFC 8754 are parsed as generic TLVs.

Great, thanks Giulio!

[ahsalam]

Hi @fxlb, could you please have a look on that PR? we have other new features that we plan to submit but they depend on that PR. thanks!

[giulio-sido]

Hi, I have just rebased yesterday because the main repository had advanced and there was a little conflict to solve. Now the checks have all passed, so the PR should be ready.

[fxlb]

Please have patience, I have no time for a review now. Maybe another maintainer will have time to review the changes.

[fxlb]

First, some questions: You process three IPV6_SRH_TLV_* and the default.

1. Why 2 IPV6_SRH_TLV_* are cases of the switch and IPV6_SRH_TLV_PAD1 is outside the switch with a 'continue'?
2. Have you some pcap files with pad1 and padn TLVs?

[fxlb]

(I have rebased your branch on top the-tcpdump-group:master, please get the updated branch.)

[giulio-sido]

Hi @fxlb, sorry for the late reply. I'll answer your questions.

1. I have chosen to parse the IPV6_SRH_TLV_PAD1 outside the switch statement because in that case there is not a further byte to read containing the TLV length, which is found in all the other TLVs. I thought it would have been cleaner this way, but I'm open to changes in the code if you think I should implement the logic differently.

2. I have added a new pcap file containing an example with the padding TLVs with relative test.

The CI tests are still running as of now, but hopefully everything will work. Let me know if you have any more comments.

Thanks for your time!

[giulio-sido]

Hi @fxlb, I have edited a file because it didn't pass one check. There were a couple trailing spaces.

[fxlb]

I have chosen to parse the IPV6_SRH_TLV_PAD1 outside the switch statement because [...]

OK.

I have added a new pcap file containing an example with the padding TLVs with relative test.

Thanks.

[giulio-sido]

Thaks @fxlb for your feedback. I have updated the code and rebased on the last commit of the master. Let's wait for the CI tests to finish.

[fxlb]

Put "{" at end of line with "if", "for" and "while" to keep style consistent. Done.

[fxlb]

@giulio-sido Thank you for your work and patience.