Subject: RE: reqs for local addressing OR requirements for SL replacement? [Re: Accept hain/templin draft as wg item?]

From: "Michel Py" <[email-masked]>
Date: Mon, 25 Aug 2003 08:17:25 -0700

Pekka,

> Pekka Savola wrote:
> What I'm trying to say is that we need to first figure out
> where we need local-use applications -- and, as an interim
> feature, maybe reword the current draft so that it's
> apparent which current perceived local-use scenarios
> require specific requirements.

This appears to me the opposite of what is generally done within the
IETF. First we write requirements then we look at specific scenarios,
not the opposite.

Besides, at this stage of things it is generally admitted that a broader
view is useful in describing the problem in context.

>> which is one of the reasons that eventually led to RFC1597.
>> What makes you believe that the reasons they did it in the
>> past do not exist anymore?

> And what problems has this caused that are really, really
> problematic?

NAT, in the first place.

> On the other side, I fail to see the need to hijack a
> prefix for your running system.  IPv6 addresses are quite
> obtainable nowadays if you're an equivalent of LIR.

Doubly irrelevant to the discussion: first, you can't ask every network
to become a LIR; second, the need for public addresses and local
addresses is totally different, so even if one enterprise has become a
LIR to obtain public addresses it does not remove the need for private
ones.

> In addition, compared to the situation back in 1994 (and
> earlier), people actually use Routing Registries to check
> advertisements. You really cannot assume that you could
> hijack a prefix and have it work in the Internet.

I have live examples that use NAT for that purpose and some other people
have contributed the same here.

You did not answer the question. The question is not why network
administrators are wrong to use local addresses. Wrong or not, and
whether you like it or not, they have, do and will use them. Putting
your head in the sand or stating that there are no reasons to use local
addressing is not going to change it.

There are extremely large numbers of networks that currently use local
addressing; RFC1918 is not what created this situation: to the contrary
it is a by-product of their widespread use and created well-known
prefixes for them.

What makes you thing that the requirements of all these networks have
changed?

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: Pekka Savola <[email-masked]>
Date: Tue, 26 Aug 2003 14:33:51 +0300 (EEST)

> IETF. First we write requirements then we look at specific scenarios,

My point exactly!  Why are we writing requirements for _local addressing_, 
and not writing requirements to solve the problems which people perceive 
exist in IPv6 after the elimination of site-locals?!!?!?

> > And what problems has this caused that are really, really

Please be a bit more specific on how that came to be.  Do you mean that 
folks who hijacked the address space deployed NAT to be able to continue 
using their hijacked space inside their network but do one-to-one 
conversion at the border?

> to become a LIR; 
> second, the need for public addresses and local

Sure, but there are also other ways to obtain addresses.

So, what you're really saying that folks would hijack prefixes to be used 
internally (instead of trying to use them externally).  I wonder if that 
was the case of prefix hijacking by-and-then.

Sites could very well get another /48 for internal-only connections, and
/48 for public ones, I guess.  Easy to filter at the edges, doesn't need
to be routed, etc.  Shouldn't be a huge problem in getting through RIR
policies.

> What makes you thing that the requirements of all these networks have

Given time, bogus requirements could be shown to be bogus.  Perhaps SoBig 
and friends have enlightened some network managers to the fact that 
private addressing helps you not at all.

I do not see the need to repeat IPv4's mistakes in IPv6.  That's why we 
advocate dual-stack deployment.  If you want to keep the broken designs, 
keep those IPv4-only.

My (and others) goal is to show that the use of local addressing is not 
the right approach in many cases, and show some alternative means to 
achieve the same ends.  If, in the end, the users wish to shoot them in 
the foot, we can't prevent that, but via these procedures I'd hope it's 
the 1% who do the shooting, not 99%.

-- 
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: Fred Templin <[email-masked]>
Date: Tue, 26 Aug 2003 09:27:35 -0700

Pekka,

Pekka Savola wrote:

>exist in IPv6 after the elimination of site-locals?!!?!
>

That is what the hain/templin draft is about! The title of the draft is:

  "Addressing Requirements for Local Communications within Sites"

The title articulates the problem space which is perceived as requiring
new solutions after the elimination of site-locals; it is not pre-judging
what those solutions should be. If you think any of the requirements or
scenarios in the document are invalid and/or leaning too strongly in favor
of a particular solution alternative, please send specific comments to that
effect. (I saw that you did provide some pointed comments earlier;
thanks for those.)

Fred
[email-masked]

P.S. In case it is getting lost in the noise, the document ID is:

http://www.ietf.org/internet-drafts/draft-hain-templin-ipv6-limitedrange-01.txt

---

From: Pekka Savola <[email-masked]>
Date: Tue, 26 Aug 2003 19:26:39 +0300 (EEST)

>   "Addressing Requirements for Local Communications within Sites"

Is the title supposed to be a pun?  I.e., do you mean "to find solutions 
to requirements for local communications .." or "finding requirements for 
addressing mechanism to solve this problem" ?

> effect. (I saw that you did provide some pointed comments earlier;

As said, I disagree with pretty much all of the document, if it is 
*supposed* to be the requirements how to find solutions for IPv6 sites 
which seem impaired by IPv6 after SL's are dead.

About the only non-solution specific thing about the document seems to be 
the title (depending on whether you take it for a pun or not..)

The document assumes we need local addressing.  That's already
solutionism.  Having a document which explores local addressing 
requirements may be OK -- but at least state it clearly and DON'T pretend 
otherwise! :-)

---

From: Fred Templin <[email-masked]>
Date: Tue, 26 Aug 2003 09:55:47 -0700

>addressing mechanism to solve this problem" ?

The title says simply that there will be a need for  "local communications
within sites" and this need raises "addressing requirements" - nothing more.
I have no idea how you could twist the meaning in the way you have; the
english language isn't *that* ambiguous!

Fred
[email-masked]

---

From: "Tony Hain" <[email-masked]>
Date: Tue, 26 Aug 2003 10:40:06 -0700

Pekka Savola wrote:
> The document assumes we need local addressing.  That's 
> already solutionism.  Having a document which explores local 
> addressing 
> requirements may be OK -- but at least state it clearly and 
> DON'T pretend otherwise! :-)

There is no intent to pretend. Maybe what you are trying to say is that the
document needs to do a better job of documenting the requirement from the
Application space that they be able to identify any non-globally accessible
addresses so they can ignore them. This has been stated many times on the
list, but is probably not well documented in the current draft. 

I suspect this is the core of your argument about why we don't need any
local use addresses. In the abstract, any prefix can be kept out of the
global routing system, and satisfy most of the scenarios in the draft. The
issue comes when one wants to have some nodes with global access, while
others are limited to local access. Mixing a single prefix in this
environment creates a bottleneck & single point of failure in any edge
access control, and assumes that the nodes are static in their attachment to
the local topology. That set of constraints is unacceptable to many network
managers, so their response will be to use nat to absolutely protect the
nodes that need to be. An alternative is to use 2 prefixes in the network,
where one is in the global routing system and the other is not. From a
routing perspective there is no particular requirement that the restricted
one be identifiable from the global one. Again, any prefix that is not in
the global routing system achieves the protection goal. 

This brings us back to the requirements Keith and others have expressed, in
that any address which is not globally accessable have a flag so they can
choose to ignore it when referring literal topology attachments to others.
At the same time, there are other scenarios where the application wants to
know how to avoid global exposure. We can and should use the Bellovin/Zill
approach to indicate which prefix is local, but we should also make the
local flag well-known so that service providers put them on the bogon list.
This helps reinforce the expectation that the prefix stays local, and
removes the possibility of a single error exposing systems that should not
be. 

Tony

---

From: "Chirayu Patel" <[email-masked]>
Date: Wed, 27 Aug 2003 09:28:03 +0530

> english language isn't *that* ambiguous!

:-)

"Addressing" - "Requirements for Local Communications within Sites"

-or-

"Addressing Requirements" - "for Local Communications within Sites"