ud3tn/test
Felix Walter bae84adcdd bundle_processor, RX: Properly handle LocalNode ipn EIDs
This was implemented using Claude Code. Prompts:

- > According to RFC 9758, there is the concept of LocalNode ipn URIs, which should be handled properly. This means ipn EIDs with allocator `0` and node number `0xFFFFFFFFF` should resolve to the local node when dispatching bundles in `bundle_processor`. Note from the RFC: "Because a LocalNode ipn EID only has meaning on the local bundle node, any such EID MUST be considered non-routable. This means that any bundle using a LocalNode ipn EID as a bundle source or bundle destination MUST NOT be allowed to leave the local node. Equally, all externally received bundles featuring LocalNode EIDs as a bundle source or bundle destination MUST be discarded as invalid." I propose to:
	- Add this special handling for the bundle destination in `endpoint_is_local` and `get_agent_id` in `bundle_processor.c`, e.g., by prefix-matching the string representation. As we do EID normalization in the parser, we only need to match the 2-element representation. This change will moreover ensure that such bundles do not leave the local node.
	- Reject incoming bundles with such EIDs in the source or destination field early-on: add a check after the `bundle_is_valid` check in `components/cla/cla_contact_rx_task.c` (we cannot extend `bundle_is_valid` as it may also be used for checking the validity of locally-injected bundles).
- (Note: We cannot reject it in the parsers as we are using them for our persistent storage.)
- > Check the EID normalization in `components/ud3tn/eid.c`, lines 317--368, again. We perform this for every bundle upon reception and local creation. It seems you were missing some context. Also, ipn:0.4294967295 is NOT a valid EID, as in the 2-element representation the first number is the node number and the second the service number, and ipn:0.0 is the NULL endpoint and any other service number there is invalid.
- > Do not forget to include the EID normalization in `components/ud3tn/eid.c`, lines 317--368, in your context.
- > The correct format is ipn:4294967295.*, as the node number 0xFFFFFFFFF determines it is a LocalNode URI and we represent it in decimal. As we do normalization, we do not need to care about the allocator id (which is 0 but is dropped due to normalization). You do not need to touch validation or normalization. Just implement proper prefix matching for "ipn:4294967295." in the mentioned places in `bundle_processor.c` and properly determine the local agent id there (which is equal to the service number when dealing with an ipn EID). Additionally, implement the rejection in `cla_contact_rx_task.c` as mentioned by prefix-matching the source and destination EID of the incoming bundle.

Signed-off-by: Felix Walter <felix.walter@d3tn.com>
2025-11-12 09:52:03 +01:00
..
decoder bundle: Implement dedicated bundle validation before further processing 2025-06-05 11:05:47 +02:00
dockerfiles CI: Bump interop testing images to include Jansson dependency 2025-06-05 17:03:39 +02:00
dtn7_interoperability cmdline: Rename eid to node-id 2024-09-13 15:18:03 +02:00
functional python-ud3tn-utils: Introduce JSON configuration format 2025-06-05 17:03:39 +02:00
integration test/integration: Add ipn update to bundle send-receive test 2025-11-12 09:49:23 +01:00
ion_interoperability test: Clean up timeouts applied in ION-BIBE interop test 2025-06-06 09:14:57 +02:00
unit bundle_processor, RX: Properly handle LocalNode ipn EIDs 2025-11-12 09:52:03 +01:00
run_hdtn_test.sh test: Delay sending bundles in interoperability tests 2025-06-06 09:14:57 +02:00
ud3tn_stress_test.sh Re-integrate v0.13.0 routing code as "integrated default BDM" 2024-07-15 00:46:14 +02:00