A considered reply to a couple of postings: Under the subject RE: site-local observations from the outside Michel Py wrote: > > Brian, > > >> Michel Py wrote: > >> It's a matter of risk: If I use the > >> Hinden/Haberman draft as private addresses, and if it ends up > >> being perverted as PI, my entire network design goes to the > >> trash. If I hijack a random prefix for private addresses, the > >> risk of collisions although not null is a lot less. > > > Brian E Carpenter wrote: > > I am puzzled by your last two sentences. Can you be more > > precise about why your design would be trashed > > 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.
I still don't understand the difference between using a Hinden/Haberman address or a hijacked address as a routeable prefix. As we know, the algorithm involves giving money to an ISP to announce the prefix. There's no way we can stop that happening. It's going to happen whatever the IETF writes down. I'm not happy about that, but I'm not happy about global warming. If an enterprise decides to switch off the filtering of "local" prefixes in their border router, and pays their ISPs to announce them, that part of the game is over. > > >From another post: > > > If by PI you mean *globally routeable* PI, I am not holding > > my breath, and I believe it would be a serious mistake to > > delay any decisions while waiting for PI. > > If you mean non-globally-routeable PI, Hinden/Haberman is a > > fine solution. > > What you refuse to acknowledge is that there is a high probability that > the Hinden/Haberman draft will be misused as globally routable PI. There's a 100% probability it will be used for inter-enterprise routing (i.e. exceptions such as VPNs to normal routing). 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. > 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. > > Network administrators don't buy that addresses in the Hinden/Haberman > draft will remain non-routable because they will be the first jumping in > the train to make them routable in the first place. Yes. In fact that statement has to be true for any solution satisfying the Hain/Templin "requirements." I think we have to deal with it. > > > 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. Under the subject RE: Geoff Huston's draft and the intended use of the hinden/templin addressspace, Michel Py wrote: > Brian, > > > Brian E Carpenter wrote: > > I kept reading, because if these things are created they *will* > > certainly end up being used as end point identifiers. > > 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. If I'm worried about privacy, I can use RFC 3041 to generate the address. > > 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. Brian > > Michel. -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM NEW ADDRESS <[EMAIL PROTECTED]> PLEASE UPDATE ADDRESS BOOK -------------------------------------------------------------------- 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] --------------------------------------------------------------------
