[EMAIL PROTECTED] ("Stephen Sprunk") writes: > > isc is multihomed, so it's difficult to imagine what isp we could have > > taken address space from then, or now. > > According to multi6, you will get PA space from each of your ISPs and > overlay a prefix from each on every subnet. I'll save y'all another rant > on the workability of that model...
please don't. don't save me from that rant. let's all hear it. really. > Some fear that you would more likely just generate a ULA, use that > internally, and NAT at the borders. Or maybe you'd stick with IPv4 > RFC1918 space internally and NAT to IPv6 PA space at your borders. the internet endpoint type trend is toward SOHO and dsl/cable, and the provider trend is toward gigantic multinational. companies who build their own networks tend to find that the cheapest interoffice backhaul is IP-in-IP VPN's. thus is the old model of a 1000-person company buying a T1 transit connection moving toward the margins. as i continue to research my own premises, i find that the style of internetworking practiced at isc, which precludes PA space due to multihoming and due to possible renumbering penalties, is becoming quite rare as a percentage of the total number of network owners and the total number of endpoints thus interconnected. it's sad but it's true and it gives cause to ponder the future of enabling technologies like internet exchange points. this may yet lead to a mechanism for qualifying multihomed network builders to get PI space, since they'll be rare enough to have a low impact on the global routing table. on the other hand, transit-provider lock-in is not officially recognized as having any bearing on any RIR policy in any region; if that continues to be the case, the rare kind of network i'm most familiar with will continue to use ipv4 or will only use ipv6 via something like ULA's. what this may mean is that approving ULA's will make the situation better, since network owners will otherwise just pirate unused space at random. with ULA's we'll at least have a chance to trace leaks and try to make BCP38 happen in more places. -- Paul Vixie