F39-IL: Yes
Rationale
RFC 6741 preserves the socket API for applications using logical names and separates transport identifiers from locators. The public ILNP implementation explicitly handles reception from its own identifier as loopback in ilnp6_rcv. Its address configuration installs host-local routes using the loopback device, while TCP retains the ordinary connect and receive interface. Together these support local and remote IPC through the same participant-name/service-port abstraction.
Assessment method
Architectural inference from RFC socket/name semantics and pinned explicit ILNP local-reception path
Source context
RFC 6741 sections 10.5 and 14; ilnp-public-1 ilnp6_rcv, addrconf_dst_alloc and TCP socket path
Outstanding qualification
Architectural Yes inferred from the RFC application model and explicit source mechanisms, not a newly executed local TCP session or validation of every prototype code path. The service vector must be assigned locally and recognized by the ILNP stack; resolver and ILCC prerequisites remain. No numeric localhost substitution, ordinary IPv6 fallback, migration of a running process, zero-copy or production-readiness claim is used as the witness. The historical prototype is supporting evidence, not a replacement for the selected RFC profile.
Public sources
- https://github.com/ilnp/ilnp-public-1/blob/068701b8ac26164d38a82b3a5008027539722787/net/ipv6/ilnp6.c
- https://www.rfc-editor.org/rfc/rfc6741.html
- https://github.com/ilnp/ilnp-public-1/blob/068701b8ac26164d38a82b3a5008027539722787/net/ipv6/route.c
- https://github.com/ilnp/ilnp-public-1/blob/068701b8ac26164d38a82b3a5008027539722787/net/ipv6/tcp_ipv6.c
- https://github.com/ilnp/ilnp-public-1/blob/068701b8ac26164d38a82b3a5008027539722787/net/ipv6/ip6_input.c
- https://ilnp.github.io/ilnp-public-1/
Editorial evidence references
The following identifiers refer to research records not included in this public package; they are not public links.
- round701.html