G05-LI: No
Rationale
No for the selected inner-IPv4 LISP composition. RFC 9300 defines an IPv4 EID as a 32-bit host identifier: at most 2^32 distinct EIDs in a connected address space, below ten billion devices. Multiple RLOCs change reachability to an EID rather than enlarge its namespace. Instance IDs permit overlapping isolated spaces, but section 8 requires source and destination EIDs to belong to the same Instance ID. Merely multiplying isolated instances therefore does not supply the connected common scenario; no inter-instance translating service is selected.
Assessment method
Selected-profile namespace and source-based resource bounds; no runtime experiment
Source context
RFC 9300 sections 3 (EID), 5 (address-family combinations) and 8 (Instance IDs)
Outstanding qualification
The bound is on the selected inner IPv4 profile, not on LISP generally. RFC 9300 explicitly supports IPv6 EIDs, including IPv6-in-IPv4; choosing that global composition would remove this particular bound and require a fresh mapping/routing plausibility assessment. No requirement for one RLOC per endpoint is assumed. Mapping-cache distribution cannot repair insufficient EID namespace by itself. No profile, implementation or security verdict is changed.
Public sources
Editorial evidence references
The following identifiers refer to research records not included in this public package; they are not public links.
- round400-common-scenario.json
- round438-sources.json
- round438-bounds.json