Subject: RE: Thoughts on the draft-hinden last call

From: "Christian Huitema" <[email-masked]>
Date: Mon, 3 Nov 2003 17:12:58 -0800

> OK, this is going to go around endlessly, so please re-read my
original
> message where I said that there are some who simply do not agree that
> local
> addressing is needed -- I know that is your position and I respect it.
I
> also said that I firmly disagree and suggest that we have plenty of
> scenarios that suggest otherwise.  Lets not waste further bits on this
> argument.

Hans,

You have clearly stated your point. You, and several others, believe
that local addressing is not needed. However, I don't believe that the
working group should heed your opposition. Something is needed if a
significant part of the community believes they need it; unanimity is
definitely not required, and even majority is not required. 

In the case in point, there is a significant constituency who believes
that they need a replacement for site local addresses, and that
"draft-hinden" is a reasonable way to obtain this replacement. You are
indeed free to not use such addresses and never deploy them within the
networks that you manage, but that does not change the needs of others.

-- Christian Huitema

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Hans Kruse <[email-masked]>
Date: Mon, 03 Nov 2003 20:43:49 -0500

Whoa, sorry if this got that far out of context!    I very expressly 
believe that a local scheme in general, and the one in draft-hinden in 
particular, is needed for a number of scenarios!

> definitely not required, and even majority is not required.

Hans Kruse, Associate Professor
J. Warren McClure School of Communication Systems Management
Adjunct Associate Professor of Electrical Engineering and Computer Science
Ohio University, Athens, OH, 45701
740-593-4891 voice, 740-593-4889 fax

---

From: Alain Durand <[email-masked]>
Date: Mon, 03 Nov 2003 22:45:07 -0800

> networks that you manage, but that does not change the needs of others.

In principle, I would almost agree with this statement, with one caveat:
"... as long as it does not break anything in the global Internet for
people that do not use this proposal"

As I explain in a previous message, this last property is not verified
by the hinden/haberman draft, as when those addresses leak,
they would create untraceable problems, very similar to the one
caused by RFC1918 leaks today.

	- Alain.

---

From: Tim Chown <[email-masked]>
Date: Tue, 4 Nov 2003 08:37:29 +0000

> networks that you manage, but that does not change the needs of others.

Agree 100%.

IPv6 at least has the advantage that we have address space to offer anyone
wanting local addressing a means to gain a unique (or as good as a unique)
prefix to use, which is a big advantage on the (dis)ambiguity front.

Leakage will still be an issue, but I don't believe that can be fixed by
an RFC.

Tim

---

From: Tim Chown <[email-masked]>
Date: Tue, 4 Nov 2003 08:48:10 +0000

> caused by RFC1918 leaks today.

But could we ever stop leakage?

And would it not be more dangerous if hijacked or randomly picked prefixes
leaked instead of well-known (probabilistically unique) prefixes?

Tim

---

From: Alain Durand <[email-masked]>
Date: Tue, 04 Nov 2003 09:45:31 -0800

> leaked instead of well-known (probabilistically unique) prefixes?

You're assuming that the alternative to hinden/haberman is hijacking 
random prefixes.
I don't. I see allocation of real PI (by real I mean registered) a more 
serious alternative.
The more I think about it, the more I come to the conclusion that the 
issue
with the hinden/haberman draft is that those prefixes cannot be trace 
back,
making them as good (or as bad) as ambiguous.

I just saw a press release from a company building high speed network 
chips
that claim they can process up to a million route at 40 Gb/s...
so I'm honestly thinking that handing out PI to people who can justify 
the need
is not as scary as it sounds, at least it would enable us to wait until 
we get something
from Multi6.

	- Alain.

---

From: Tim Chown <[email-masked]>
Date: Tue, 4 Nov 2003 18:00:49 +0000

> is not as scary as it sounds, at least it would enable us to wait until 

Sure if you can provide a solution for PI addressing then you will solve
many issues in one... the question for you is then how these people
"justify their need" - will anyone who would be able to get a unique
hinden/haberman draft prefix be eligible for your PI prefix?

How do we control or throttle the allocations and not regret it later?
With current IPv6 adoption we don't have a problem though... (!)

Tim

---

From: Alain Durand <[email-masked]>
Date: Tue, 04 Nov 2003 10:55:22 -0800

> With current IPv6 adoption we don't have a problem though... (!)

Exactly the point... The fear of a gold rush has been driving many 
similar
discussions over the last few years. The reality is very different.

	- Alain.

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 09 Nov 2003 22:19:44 +0100

> caused by RFC1918 leaks today.

Q: Who is to blame and likely to be a victim?

A: any ISP without ingress filtering.

To misquote Pekka, why exactly should we care if ISP X's operations 
break because it fails to implement ingress filtering?

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 09 Nov 2003 22:24:11 +0100

Alain,

Please define "real PI (by real I mean registered)". Not having seen the
draft that defines it, I can't evaluate your argument.

  Brian

---

From: Alain Durand <[email-masked]>
Date: Sun, 09 Nov 2003 14:02:29 -0800

> A: any ISP without ingress filtering.

Did you never heard about the AS112 project as an example of how much
trouble RFC1918 can cause?
http://www.as112.net/
With that regard, as hinden/haberman addresses are not resolvable in 
the reverse tree DNS,
they will cause exactly the same issue as RF1918.

	- Alain.

---

From: Leif Johansson <[email-masked]>
Date: Sun, 09 Nov 2003 23:03:58 +0100

Brian E Carpenter wrote:
| Alain,
|
| Please define "real PI (by real I mean registered)". Not having seen the
| draft that defines it, I can't evaluate your argument.
|

I seem to remember Kurtis making a proposal but I'm not sure if it
was written up anywhere (or were you making a point :-) )

---

From: Alain Durand <[email-masked]>
Date: Sun, 09 Nov 2003 14:16:10 -0800

> draft that defines it, I can't evaluate your argument.

The problem with the Hinden/harbeman draft is that it allocates a part 
of
the public IPv6 address space for private, unregistered usage.
The consequence is that when (and not if) those addresses
will leak in the public Internet, they will be untraceable and won't 
resolve at all
in the reverse tree DNS.

My suggestion is to let the authority in charge of administering
the public IP address space to allocate directly address space
from a specific bloc to whoever wants it, with no expectation that
it will be routable and leave it up to the customers and their ISP
to see if this gets routed or not (with a recommendation that by 
default it is not).

That way, those addresses would be traceable the day they will leak.
Of course, this requires a little extra management,
and perhaps a (small) recurring fee to maintain the database
instead of a one time 10 euro, but this should not stop anybody serious.

If you, or the wg, thinks this avenue is worth exploring, I can write
a 2 page draft. I honestly believe that this entire issue can be
solved outside of the IETF by the RIRs without introducing anything
new/damaging in the IPv6 architecture.

	- Alain.

---

From: Pekka Savola <[email-masked]>
Date: Mon, 10 Nov 2003 00:30:32 +0200 (EET)

On Sun, 9 Nov 2003, Brian E Carpenter wrote:
[...]
> break because it fails to implement ingress filtering?

Uhh, but isn't the pain felt by everyone, especially if the leakage is
more subtle than source/destination address?  E.g., leakage in the
payload...

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 09 Nov 2003 23:33:42 +0100

Alain,

I think it is well worth writing such a draft. It might move this debate
forward. However, I'll point out one advantage of Hinden/Haberman
that it cannot match - the locally-assigned version of Hinden/Haberman
is instantly available when IANA assigns a prefix, without a one to two
year delay to put registry policy and mechanisms in place.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 09 Nov 2003 23:42:05 +0100

Pekka,

Leakage in the payload (i.e. a referral) is problem we will have anyway,
e.g. if the referred address is inside a firewall. I think that problem
is unavoidable. It's true that with a fully registered PI, diagnosis is
easier.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 09 Nov 2003 23:45:10 +0100

> they will cause exactly the same issue as RF1918.

If they are referred outside their context, sure. But that problem can arise
for any form of privately used addresses, however they are assigned - if nobody
puts them in the public reverse tree, they will cause problems.

   Brian

---

From: Tim Chown <[email-masked]>
Date: Sun, 9 Nov 2003 22:46:38 +0000

> to see if this gets routed or not (with a recommendation that by 

OK, let's compare that against the aims stated in Hinden-Haberman
in section 1.0:

      - Globally unique prefix.
      - Well known prefix to allow for easy filtering at site
        boundaries.
      - Allows sites to be combined or privately interconnected without
        creating any address conflicts or require renumbering of
        interfaces using these prefixes.
      - Internet Service Provider independent and can be used for
        communications inside of a site without having any permanent or
        intermittent Internet connectivity.
      - If accidentally leaked outside of a site via routing or DNS,
        there is no conflict with any other addresses.
      - In practice, applications may treat these address like global
        scoped addresses.

Although I'm a little lagged :) I don't see that your proposal has
different properties, "only" that you allocate from some specific
block.   If that block is fc00::/8 as per Hinden-Haberman, aren't we
in the same position?   So the real issue is the locally-assigned addresses 
(given that leakage is inevitable)?

I think the "probably unique locally assigned" prefix crept in maybe
after the above goals were written, given that the locally assigned
prefixes may not be unique, and would not be registered/traceable?
The one addition you have to the above goals seems to be traceability.

[You also suggest a recurring fee, which this draft does not.  I would
 prefer the draft to just say words to the effect to deter land rush on
 the address space, and not specifics of how.]

Would it help or hurt to split this into two drafts, one proposal that
is unique by registration/escrow (and that thus has traceability) and 
one that is probabilistically unique? 

Tim

---

From: Leif Johansson <[email-masked]>
Date: Mon, 10 Nov 2003 00:01:12 +0100

Brian E Carpenter wrote:
| Pekka,
|
| Leakage in the payload (i.e. a referral) is problem we will have anyway,
| e.g. if the referred address is inside a firewall. I think that problem

There are important differences between the two types of leakage though.

---

From: Bob Hinden <[email-masked]>
Date: Sun, 09 Nov 2003 15:13:10 -0800

Alain,

>new/damaging in the IPv6 architecture.

ULA do not introduce a change to the IPv6 architecture.  They are only 
another way of allocating global unicast addresses.  Implementations will 
treat them like other types of global unicast addresses.  Like other types 
of IPv6 global unicast addresses they may be routable or not.

Bob

---

From: Alain Durand <[email-masked]>
Date: Sun, 09 Nov 2003 15:26:22 -0800

On Nov 9, 2003, at 3:13 PM, Bob Hinden wrote:

> another way of allocating global unicast addresses.  Implementations 
> will treat them like other types of global unicast addresses.  Like 
> other types of IPv6 global unicast addresses they may be routable or 
> not.

I disagree. They are different because they have different properties 
by design.
So if an application is returned both type, it will have to make a 
choice...
This, for me, is a change in the architecture.

	- Alain.