Handle overlap without borrowing addresses

An unknown overlap is not a safe RFC1918 plan; someone else’s public allocation is never a substitute.

• §3 considers legitimately assigned global addresses, usurped global addresses, RFC1918 private addresses and Shared Address Space. Legitimately assigned global space poses the fewest numbering problems but is scarce. This is rationale, not permission to take an unassigned or someone else’s block.
• Service Providers MUST NOT use usurped globally unique address space to number the interfaces in question (§3). Even without leaked routes, the provider and subscribers may lose connectivity to the legitimate address holder. This prohibition is not merely a recommendation.
• A provider can use RFC1918 on the CGN-CPE link if it knows the CPE/NAT works with the same block on both sides, or knows the chosen provider block is not used on the subscriber side (§3). Either known condition is enough; lack of both is not a safe private-space plan.
• In an unmanaged service, subscribers choose their own routers and internal prefixes. The provider may not know either condition. The RFC says it then cannot safely use RFC1918 and must resort to Shared Address Space. That lower-case wording is retained without inventing a new uppercase requirement.
• For Shared Address Space, devices MUST be capable of translation when identical shared ranges appear on two different interfaces (§4). The permitted non-provider use is limited to suitable translating routing equipment; identical numeric addresses alone do not distinguish two interface contexts.
• Using shared space for other purposes may create future problems connecting to CGN service when non-overlapping spaces are needed (§4). The allocation is not a general invitation to renumber every subscriber LAN into100.64/10.