mirror of
https://gitlab.com/d3tn/ud3tn.git
synced 2026-08-16 13:01:06 +02:00
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> |
||
|---|---|---|
| .. | ||
| decoder | ||
| dockerfiles | ||
| dtn7_interoperability | ||
| functional | ||
| integration | ||
| ion_interoperability | ||
| unit | ||
| run_hdtn_test.sh | ||
| ud3tn_stress_test.sh | ||