1. IPv6 Near-Unique Site Local Addresses draft-francis-ipngwg-unique-site-local-00.txt

2. Problem Statement in Draft Site-locals not globally unique Sites cannot be “merged” without first renumbering –Renumbering eventually necessary, but over time Site-local address is potentially ambiguous outside immediate context of network layer –In email or a file

3. Solution in Draft Assign “near-unique” random value in 38- bit 0’s field of site-local address | 10 | | bits | 38 bits | 16 bits | 64 bits | +----------+-------------+-----------+---------------+ |1111111011| 0 | subnet ID | interface ID | +----------+-------------+-----------+---------------+ | 10 | | bits | 38 bits | 16 bits | 64 bits | +----------+-------------+-----------+---------------+ |1111111011| non-zero | subnet ID | interface ID | +----------+-------------+-----------+---------------+

4. Solution in Draft Don’t use a registry –Even registry can’t enforce uniqueness –Because of site splits Instead each site choose a random number –Literally toss coins –Or, ISP can assign random number from good random number generator

5. Low probability of collision For any given site, very low probability that it will ever connect to another site with same prefix –Some math errors in the draft, off by maybe factor of 2 –Conclusion still applies

6. Draft Error Near-unique site-locals don’t really help with merging sites If two merged site halves maintain separate global prefixes –Advertise prefix to each half If two merged site halves obtain same global prefixes –Must renumber anyway (near-unique or not)

7. 2 sites ISP1 ISP2 Site 1 Site 2 Prefix P1 Prefix P2 P1.1 L.1 P2.1 L.1 P2.2 L.2 P1.2 L.2 ISP3

8. “Merge” with separate global prefixes Advertise global prefixes directly ISP1 ISP2 Site 1 Site 2 Prefix P1 Prefix P2 P1.1 L.1 P2.1 L.1 P2.2 L.2 P1.2 L.2 ISP3 P2 P1

9. One half gets new prefix Other half doesn’t have to renumber ISP1 ISP2 Site 1 Site 2 Prefix P1 Prefix P3 P1.1 L.1 P3.1 L.1 P3.2 L.2 P1.2 L.2 ISP3 P3 P1

10. But only partial merge Can’t use each other’s ISPs ISP1 ISP2 Site 1 Site 2 Prefix P1 Prefix P3 P1.1 L.1 P3.1 L.1 P3.2 L.2 P1.2 L.2 ISP3 P3 P1

11. Near-unique site-locals doesn’t help Still can’t use each other’s ISPs ISP1 ISP2 Site 1 Site 2 Prefix P1 Prefix P3 P1.1 L1.1 P3.1 L3.1 P3.2 L3.2 P1.2 L1.2 ISP3 L3 L1

12. What about a full merge? Can’t add new prefix without changing SLA ISP1 ISP2 Prefix P1 Prefix P3 P1.1 P3.1 L1.1 P3.1 P1.1 L3.1 P3.2 P1.2 L3.2 P1.2 P3.2 L1.2 ISP3 collisions!

13. Can’t change global SLA’s without changing site-local SLA’s ISP1 ISP2 Prefix P1 Prefix P3 P1.1 P3.1 L1.1 P3.3 P1.3 L3.1 P3.4 P1.4 L3.2 P1.2 P3.2 L1.2 ISP3 different SLA’s

14. Full merge requires renumbering regardless Can’t use router renumbering to do it ISP1 ISP2 Prefix P1 Prefix P3 P1.1 P3.1 L1.1 P3.3 P1.3 L3.3 P3.4 P1.4 L3.4 P1.2 P3.2 L1.2 ISP3

15. One possible option: Don’t apply router renumbering to site locals ISP1 ISP2 Prefix P1 Prefix P3 P1.1 P3.1 L1.1 P3.3 P1.3 L3.1 P3.4 P1.4 L3.2 P1.2 P3.2 L1.2 ISP3

16. Remaining Benefits Remaining benefit appears to be removing out-of-context address ambiguity Possible benefits with site-multi-homed host? –Draft doesn’t talk about this –I don’t fully understand the issues

17. Discussion? Benefit not as strong as draft states Still there is some benefit Picking random number is easy, doesn’t require change to implementations –Seems no good reason to disallow a site from doing it Picking a random number is kind of weird