Subject: RE: Draft IPv6 Minutes from Atlanta IETF

From: "Michel Py" <[email-masked]>
Date: Sun, 30 Mar 2003 12:51:09 -0800

> Markku Savela wrote:
> - The addresses are unreachable outside of their
>   original context.
> Some may think the above is actually a benefit:
> all those organizations using the IPv4 private
> address spaces will want equivalent IPv6 space.

Agree with Markku's post 100%. I have said I would support deprecation
but certainly not before solutions to replaced what deprecation takes
away are developed. There certainly are some issues with the scoped
architecture and there also is the issue of private addresses with an
architectural limitation to make them unroutable, please see one of my
posts on the IETF list recently.

"Just hijack a prefix that nobody else uses" is not an option and
deprecation, should it happen, needs to provide a replacement for what
it takes away _before_ it eventually happens.

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: "Michel Py" <[email-masked]>
Date: Mon, 31 Mar 2003 09:03:01 -0800

Brian,

> Brian E Carpenter wrote:
> Access control lists in routers were in use for
> this years before RFC 1597. Preventing unwanted
> access has never been a valid argument for private
> addresses and never will be.

I have to disagree with this. There are some legitimate cases of using
private addresses for security purposes in "defense in depth" scenarios
that Richard Draves and I described earlier. This creates demand for
them.

However, the issue has nothing to do with technical reasons and
everything to do with this organization designing protocols without
paying attention to customer needs and getting us into the same circle
one more time.

Private addresses != NAT.
Perception == reality.
Private addresses == security.
Network administrators want security.
Network administrators want private addresses.

Ignoring this fact will lead us in network administrators hijacking
prefixes again; then some vendor will produce a de-facto hack for them,
likely the hack will fall under the umbrella of one of these mighty
corporations that according to popular belief produce junk, then
everyone will be complaining about big mighty corporations producing
proprietary junk, but we will produce an RFC to rubber stamp the
de-facto junk and the loop will be closed.

Please, not one more time. There is a need for private addresses, if we
don't provide a solution the market will and we're not going to be happy
with it.

As Margaret pointed out,
> Margaret Wasserman wrote:
> Unfortunately, there is another reason why enterprises
> use NAT that has not been addressed in IPv6: provider
> independence.

Although one of the big driving forces behind NAT is the lack of PI
addresses, there is an aggravating factor which is the ambiguity of
private addresses, which eventually leads to internal NAT when sites
merge. It is allowed to hope that this factor alone would not trigger
NAT happening if the PI issue was solved, but why take a chance? We need
private addresses, and preferably unique ones.

In order to achieve this we need some kind of architectural limitation
to replace the fact that ambiguity guaranteed non-routability of private
addresses. Keep in mind that we don't need non-routability of private
addresses for security reasons, we need it to ensure there is no routing
table explosion.

Site-locals provide this architectural limitation. What do we have to
replace it? Nothing. People hijacking prefixes will re-introduce most of
the problems that site-locals have, putting them under the rug does not
solve them. I understand that there are problems with site-locals, but
deprecating them should not introduce new issues. Let's be careful not
to have a cure that is worse than the disease.

Michel.