Subject: RE: PI, routeable PI,

From: "Michel Py" <[email-masked]>
Date: Tue, 12 Aug 2003 12:09:20 -0700

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-masked]
--------------------------------------------------------------------

---

From: Mark Smith <[email-masked]>
Date: Wed, 13 Aug 2003 15:31:39 +0930

On Tue, 12 Aug 2003 12:09:20 -0700

> example. Then the line between it and global PI ceases to exist.

I think a concern about a furture use of host-to-host IPSec and the consequences to local use addresses is quite valid.

There are a number of reasons :

1) IPsec in IPv6 is *free*. Why bother getting a private WAN link when the QoS over the organisation's Internet link, when combined with IPsec, is good enough ?

2) Scaling to large numbers of IPsec tunnels encounters the same problem that scaling over IP over ATM encountered - the overlay network problem. 

3) The solution to the overlay network problem in IPsec is to use transport mode. Transport mode doesn't work with private addressing though.

4) I'm not in touch with recent IPsec / DNSSEC developments, but the only thing I'm aware of that is missing for easy end-to-end transport mode deployment is widely available opportunistic SA establishment.

I wrote a _long_ email describing this I while ago. I appreciate it may have been too long for people to read - I blame it on the fact that I learnt to type properly a number of years ago. I'm trying to learn to be more consise.

If you are interested to read further, here is an archive copy :

http://marc.theaimsgroup.com/?l=ipng&m=103847657209894&w=2

When you add HIP (from what I understand of it) into the mix, you end up spliting the locator and identifier, which I think also makes the  multihoming problem easier to fix.

Regards,
Mark.