Brian,
>> Michel Py wrote: >> Because then the addresses used on the private network would be >> routable PI, which is exactly what network designers don't want >> when they design a private network with private addresses. > Brian Carpenter wrote: > I still don't understand the difference between using a > Hinden/Haberman address or a hijacked address as a routeable > prefix. Fundamentally, not much and I do agree that the Hinden/Haberman draft is preferable in any "localized" situation, but I see you still are not getting my point, likely due to my poor wording, I apologize being so heavy. Allow me to try in other words: Short try at it: For local use only, it is less risky to hijack a random prefix than to use Hinden/Haberman, not because Hinden/Haberman is inherently risky, but because the risk that it will be used for another purpose than local use is high. Long try at it: - The enterprise has two unfulfilled needs: globally routable PI and private addresses. - Whatever we can say about it, the network administrator gets to pick what becomes of the Hinden/Haberman draft, globally routable PI _or_ private address. The prefix can't serve both purposes at the same time for reasons explained 20 times on this list already. - Since the only thing that can solve the PI need short term is Hinden/Haberman, that's what it becomes, leaving the network administrator with no other choice but to hijack for private address use. This is doubly crappy, but perverting Hinden/Haberman is a whole lot better than no PI at all, and the ugliness of hijacking as long as it is contained within the private network does not exist because nobody can see it :-) I'm not saying hijacking is good, what I'm saying is that it's not ugly enough. Look at it this way: hijacking a random IPv6 prefix is a lot safer (WRT collision risk) than using RFC1918. So yes, the network administrator would rather use Hinden/Haberman as private addresses instead of hijacking, but this is overruled by the PI need. In short: the Hinden/Haberman draft does not solve the private address need because what it creates is globally routable PI, whether we like it or not. > There's a 100% probability it will be used for inter-enterprise > routing (i.e. exceptions such as VPNs to normal routing). Routing it over the Internet (without a VPN) for inter-entrerprise communication would also be perfectly legitimate, host-to-host IPSEC for example. Then the line between it and global PI ceases to exist. > There's probably a 100% probability that some enterprises will > pay ISPs to announce /48s into the DFZ (as mentioned above). > But I don't think that is a characteristic of the > Hinden/Haberman draft. It will happen whatever we define. The > trick is to make it an exception rather than the rule. What do we have WRT this except a MUST or MUST NOT in a draft? >> As so, it can't be used for private addresses. I'm not the >> only one that says this. > No, you're not, but it doesn't follow. It can be used for > private addresses by default. But there is no enforcement > mechanism. If you prefer; that's because we took out the two known enforcements mechanisms: ambiguity and scope. We all agree that ambiguity is bad and I would not have too many problems letting scope go if we had a replacement enforcement mechanism, but the bottom line is that we don't have one. >>> and why random hijacking is less risky than a >>> pseudo-random generator? >> It's not; it has everything to do with the purpose of the prefix, >> not with the way the address was picked. The risk of collision >> for an address that does not get out of the site is a lot less >> (specifically, a merge) than for an address that reaches the >> outside. > That's certainly true, but I think the risk is negligible anyway. Let's say it's acceptable, I agree. >>> Brian E Carpenter wrote: >>> I kept reading, because if these things are created they *will* >>> certainly end up being used as end point identifiers. >> Michel Py wrote: >> Can you develop why? In the absolute I can find lots of reasons >> but I don't see why the identifier/locator solution would prefer >> using these vs. having its own prefix. > If I have an IP address for my machine that is > FC00:<IBM's random number>:1:1:<my 64 bit id> > why wouldn't I use that as a transport address in a multihomed > session? I can't see a downside. There are two, a big one and a small one. The big one: that space is not aggregatable. Save for id/loc solutions that use DNS as the locator-to-identifier mapping mechanism, there is a long-term scalability need for aggregation, the id/loc mechanism being the extra redirection layer that makes it possible to happen. The small one: it does not register with defense-in-depth that prefers two distinct prefixes. >> I agree that they would be used for NAT though, because >> NAT does not need anything to be invented. > Indeed not. Whatever we do, NAT6 is lurking. I think that we have been collectively reckless about this. There might not be a lot that we can do, but maybe it would be worth having a paragraph in each draft about "does this rush us in the arms of NATv6 or not". Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
