Subject: RE: A use for site local addresses?

From: "Michel Py" <[email-masked]>
Date: Wed, 26 Mar 2003 11:24:35 -0800

>> Pekka Savola wrote:
>> People didn't see the need for RFC1918 space in IPv6.

Because of site-locals. With site-locals gone it is an entirely new ballgame. There is a need for private addresses, people will use them no matter if they are site-locals, 6to4 addresses with a v4 RFC1918 address or plain hijack of a global prefix like in the good old days. Then someone will write an RFC to try to contain the hijacks into a well-known range. I have a sense of déjà vu.

> Tony Hain wrote:
> Just like they didn't see the need for private address space
> in IPv4 until there were massive deployments of whatever
> random numbers people found in documents. For those who have
> forgotten, private address space was not set aside to support
> NAT, it exists to provide space for disconnected networks,
> that won't collide with existing allocations when those attach.
> NAT came along later and took advantage of the existence of
> private space.
> There is a need for address space for disconnected networks.
> If the argument is to set aside a different set of address
> space and define it as unroutable, what is the point? We
> already have a defined unroutable space, what value does a
> different one add? Any issues that are raised for FEC0:: will
> hold for whatever new space gets defined.

Agree.

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: Wed, 26 Mar 2003 21:39:37 +0200 (EET)

On Wed, 26 Mar 2003, Michel Py wrote:
> Because of site-locals. With site-locals gone it is an entirely new
> ballgame. There is a need for private addresses, people will use them no
> matter if they are site-locals, 6to4 addresses with a v4 RFC1918 address
> or plain hijack of a global prefix like in the good old days. Then
> someone will write an RFC to try to contain the hijacks into a
> well-known range. I have a sense of déjà vu.

Right .. but this was covered in the meeting.  Those folks present felt
that there really is little need for "RFC1918-like" space even if
site-locals get deprecated.  I think this was quite explicit.

As for the alternatives, you already listed some, plus using site-locals 
regardless of the deprecation.

-- 
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: Michael Thomas <[email-masked]>
Date: Wed, 26 Mar 2003 11:39:33 -0800 (PST)

> Because of site-locals. With site-locals gone it is an entirely new ballgame. There is a need for private addresses, people will use them no matter if they are site-locals, 6to4 addresses with a v…

There is some appeal to 6to4 and 1918... it keeps
the problem within the cesspool of current usage
and doesn't try to rationalize it any further. 
A maze of twisty addresses, all alike...

       Mike

---

From: Tim Chown <[email-masked]>
Date: Wed, 26 Mar 2003 20:02:24 +0000

> A maze of twisty addresses, all alike...

But as Pekka says, won't 6to4 interfaces fail to deliver to 2002:<RFC1918>
if the network is IPv6 only, or doesn't use IPv4 private IPs?

Tim

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 26 Mar 2003 21:29:09 +0100

> if the network is IPv6 only, or doesn't use IPv4 private IPs?

They will fail. Delivery to private addresses does fail. That's
because they're private. The point of mentioning 6to4 is that if you
own one lousy IPv4 address, that gives you a /48. No need to use
RFC 1918 addresses for that.

   Brian

---

From: "EricLKlein" <[email-masked]>
Date: Thu, 27 Mar 2003 09:37:19 +0200

> Because of site-locals. With site-locals gone it is an entirely new
ballgame. There is a need for private addresses,
> people will use them no matter if they are site-locals, 6to4 addresses
with a v4 RFC1918 address or plain hijack
> of a global prefix like in the good old days. Then someone will write an
RFC to try to contain the hijacks into a
> well-known range. I have a sense of déjà vu.

I think this is why this is turing out to be such a heated argument. Some of
us are trying to learn from history in order to repeate it because we too
"have a sense of déjà vu."

Others are looking at how hard it will be to implement it at the application
layer. I can appriciate this concern. I had a discussion yesterday as to
weither in the for seeable future (say 2 - 3 years) I can assume that the
customers of my softweare will have a dual stack router as my first hop. OR
if I could use the dual stack built into the server OS. Our final decision
was that we can not convert our database to pure IPv6 and let the hardware
translate for us, so we will have to do it in the appliaction.

But knowing this is better if we can avoid having to slap together fixes
later for what people will probably do again (i.e. the hijacking of
addresses as de facto private).

---

From: "Jeroen Massar" <[email-masked]>
Date: Thu, 27 Mar 2003 12:38:12 +0100

EricLKlein wrote:

Who did you qoute here again?

> ballgame. There is a need for private addresses,

<SNIP>

> Others are looking at how hard it will be to implement it at 
> the application layer. I can appriciate this concern. I had a
> discussion yesterday as to weither in the for seeable future
> (say 2 - 3 years) I can  assume that the customers of my
> softweare will have a dual stack router as my first hop. OR
> if I could use the dual stack built into the server OS. Our 
> final decision was that we can not convert our database to
> pure IPv6 and let the hardware translate for us, so we will
> have to do it in the appliaction.

If you want to code IPv4 & IPv6 aware programs then check
http://www.kame.net/newsletter/19980604/ which contains
Jun-ichiro itojun Itoh's Implementing AF-independent application.
That document is almost 5 years old now and has been used
by many application porters.

Another good document is written by Eva M. Castro and can
be found at http://jungla.dit.upm.es/~ecastro/IPv6-web/ipv6.html
and it isn't called "Porting applications to IPv6 HowTo" for
nothing. Includes TCP, UDP and multicast examples.

I wonder why you even thought about 'converting your database'
to 'pure IPv6' while IPv4 will be here to stay for quite some
time. IPv4 came quite fast and it will stick around for some
time too. Ofcourse the app will have to have knowledge of both
IPv4 and IPv6, but if you are a smart coder you use the functions
as described in the above two documents which both talk about
making your application AF independent, aka there will be no
knowledge about IPv4/IPv6 and theoretically even IPX.

Still an application should then not be aware of something like
'sitelocal', to get back to the subject becaue in AF independent
world there is no such thing. An app just send data from A to B.
And shouldn't be caring about address prefixes.

Greets,
 Jeroen

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 27 Mar 2003 18:37:31 +0100

EricLKlein wrote:
...
> Our final decision

Of course. Full dual stack support is the only rational starting point;
all the other coexistence mechanisms are second best.

   Brian

---

From: "EricLKlein" <[email-masked]>
Date: Fri, 28 Mar 2003 14:12:40 +0300

> all the other coexistence mechanisms are second best.
But how close to a database (fro example) can the application vendor require
a dual stack.

I can not see the OSS/NMS/BSS vendor requiring that their customer must run
Cisco router IOS 12.1 or higher. Therefore the application needs to have
some minimal dual intelligence built in.

Or this is how I see it, and thus the people speaking out against the local
addresses are right it means more work for them rather than the customers
running it. And this is as it should be.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 28 Mar 2003 16:24:26 +0100

> some minimal dual intelligence built in.

That's why the basic dual stack mechanism includes tunnels - the server would
need to establish a tunnel out to the nearest available IPv6 router. The application
still sees the dual stack socket API.

   Brian

---

From: "Jim Fleming" <[email-masked]>
Date: Fri, 28 Mar 2003 09:40:08 -0600

----- Original Message ----- 
From: "Brian E Carpenter" <[email-masked]>
> still sees the dual stack socket API.

Tunnels are a non-starter because people are not going to move from a 160-bit header
to a 320-bit basic header, followed by numerous other bloated headers and then add more
headers just to tunnel across the legacy IPv4 32-bit Internet. The laws of physics can not be
changed. You can only push bits so fast thru a particular medium.

With the liberated American marketplace, free from the I* society regime, the focus is on SERVICES.
Services are now being developed and deployed that assume minimal bandwidth requirements and
efficient routing. IPv16 only allows native mode, there is no tunnel mode. Not only that, the data rides
inside of the IPv6 basic header in the unused bloated address bits. The 320-bit header is the packet,
the only packet, for many services.

Jim Fleming
http://www.IPv8.info

---

From: "Jim Fleming" <[email-masked]>
Date: Fri, 28 Mar 2003 09:46:05 -0600

http://www.theinquirer.net/?article=8595
"the various states bills all require the banning the use of any technology
that conceals "the existence or place of origin or destination of any communication."
=====