EricLKlein wrote:

Who did you qoute here again?

> > >> 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,

<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


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

Reply via email to