Subject: (IPng 7273) Ipv6 Migration

From: Chris Harding <[email-masked]>
Date: Fri, 05 Mar 1999 10:20:21 +0000

Hi -

I had a thought about the API that may be "off the wall" but that could
enable existing applications to work with IPv6 with no change whatsoever.
The advantages of this for v6 deployment would be enormous.

It does not affect the IPv6 extensions to sockets, or the recommendation
that new applications should use them in order to make use of IPv6
features. It is simply a change of behavior of the core API in the presense
of IPv6.

This is how it would operate.

1. Application calls gethostbyname() to look up a host address.

2. gethostbyname() invokes DNS and finds an IPv6 address.

3. gethostbyname() allocates an IPv4 address from a pool kept for this
purpose, sets up a mapping between the v4 address and the v6 address
obtained from DNS, and returns the v4 address to the application.

4. Application does its stuff, making sockets calls from time to time.

5. Sockets calls recognise the v4 address as being from the pool, and
communicate via IPv6 to the v6 address to which the v4 address is mapped,
instead of using v4.

6. When an application binds to a v4 address from the pool, subsequent
sockets calls do a similar v4-v6 translation.

This doesn't actually require standardization. An individual vendor who
obtained a block of IPv4 addresses could do it without consulting anyone
else. But there could be advantages in allocating a single block of IPv4
addresses for everyone to use in this way.

The questions are:

   Will this work?

   Should it be required behavior for conforming UNIX implementations?

Regards,

Chris
+++++

-------------------------------------------------------------------------
           Chris Harding
  T H E    Development Manager
 O P E N   Apex Plaza, Forbury Road, Reading RG1 1AX, UK
G R O U P  Mailto:[email-masked]   Ph: +44 118 950 8311 x2262
           WWW: http://www.opengroup.org    Fx: +44 118 950 0110  

OSF/1, Motif, UNIX and the "X" device are registered trademarks in
the US and other countries, and IT DialTone and The Open Group are
trademarks of The Open Group.
-------------------------------------------------------------------------
--------------------------------------------------------------------
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: Jun-ichiro itojun Hagino <[email-masked]>
Date: Fri, 05 Mar 1999 19:56:51 +0900

>The advantages of this for v6 deployment would be enormous.
(snip)
>features. It is simply a change of behavior of the core API in the presense

	I believe someone can implement fake libc to implement your idea.

	Also I would like to note that the approach is similar to
	draft-tsuchiya-ipv4-ipv6-translator-00. (worth a look)

>   Should it be required behavior for conforming UNIX implementations?

	I believe this will work, but I think we do not need to/want to
	mandate this.

itojun

---

From: Jim Bound <[email-masked]>
Date: Fri, 05 Mar 1999 09:13:47 -0500

Hi Chris,

I am responding to all lists.  But we should pick one list.  I suggest 
as its brainstorming about implementation it can be done on deployment list.
Then if something happens we then should run logic check by the
implementors list.  Then if it is still moving forward go to IETF list
or in this case maybe the XNET list.  As a suggestion for future stuff
from anyone.  But if we all use all these lists all the time and for the
folks on every list it creates a mail storm.

Sorry for contributing to this mail storm but the idea has been put out
and I got something to say about it.

>enable existing applications to work with IPv6 with no change whatsoever.

Many of us have thought about this and several of the ngtrans proposals
assume such an API as Itojun already responded for one of them.

I think???  In your thought your assuming the platform has an IPv6 stack
on it though.  That should be stated otherwise it gets very intense and
IPv4 needs magic cookies and such and I don't think that will ever 
work IMO and perform.

>The advantages of this for v6 deployment would be enormous.

It depends on the costs and performance hit.  One thing customers have
made loud and clear to me is "DO NOT AFFECT THE PERFORMANCE OF MY IPV4
STACK with your IPV6 STACK APPROACH".  I don't know about other vendors
but Compaq is working real hard to make IPv6 transparent to IPv4 ONLY
applications.  When one adds extra conditions, 16 bytes to data
structures, extra code path for IPv6, etc... you can negatively impact 
the IPv4 environment by what we call the death of a thousand cuts.  So 
we need to keep a heads up when we discuss such thoughts as your proposing.  
And probably why this cannot be mandated; as Itojun as replied and I agree
with him.

I will point out that transition has some of the same issues and
properties and why standardizing transition tools will be tricky and the
term "implementation defined" will have to be maintained in many of
those specs and if going to standards track the IESG will have to live
with implementation defined statements in ALL transition specs at this
time.

>features. It is simply a change of behavior of the core API in the presense

When you say the core API what do you mean?  I think in this case the
resolver set of libraries.  I don't know if you looked at BIND lately as
one example but in that code base is not what I would call a core API
but a set of access methods and routines to do DNS processing on a
client type platform.  We are trying to get some things standard working
with ISC now via a group of us vendors with bindworkers as a logic check
but I don't think there is a core API below gethostbyname which is
really nothing more than a lib call into BIND.  Also for Microsoft and
other vendors that don't use BIND I assume have the same issue to
support DNS lookups?

>2. gethostbyname() invokes DNS and finds an IPv6 address.

gethostbyname has no present code base behind it (from the discussion
above) to handle getting IPv6 addresses back into the struct hostent
data structure.  This is why we did the base API initially 4-5 years ago
as one sticky for its incarnation.  So your statement above implies a
lot of work that is not stated and I would claim is overlaying
gethostbyname to really become getipnodebyname in the implementation.
That is overhead for IPv4 apps if IPv6 is not being used in that
instance.  But I realize your just presenting a taxonomy at this point.

>obtained from DNS, and returns the v4 address to the application.

Now we are adding lots of new state to gethostbyname and it will cost
and a translation table in the resolver for client DNS for IPv4 that
will cost too.

Also why wouldn't an application just want to use IPv6 that is the whole
point?  And other cases need to be defined.

>4. Application does its stuff, making sockets calls from time to time.

This is just to vague for me to comment on or parse.  I am all for
implementation defined statements but I need to know at least what the
end result is to be.

>communicate via IPv6 to the v6 address to which the v4 address is mapped,

Given that this mapping can work and I am not sure it can without a
significant performance hit.  This has to be done in most
implementations kernel now and the resolver so you have left the
application space and now in kernel space.  So the pool is now in the
kernel too really (its duplicated in the resolver and the kernel) and
before the TCP/IP processing starts the code uses v6 addresses out the
stack and on incoming converts them to v4.  This is exactly what has
been proposed in serveral ngtrans specs and I suggest you read all those
specs.  But this is a performance hit and I don't believe anyway to get
aggreement to standardize it.  We will face this in ngtrans for those
specs I predict once they are scrutinized to that level of detail.

>sockets calls do a similar v4-v6 translation.

Exactly as I said before.  Now we are putting translation in our kernels
and why I don't think this is a good idea in the "normative" case and
why I am not real hot on the ngtrans specs that do this either and very
suspect they can be standardized in a meaningful way.  The IETF did not
tell me how to implement IP, TCP, etc. and I am sure they are not going
to tell me how to implement a transition tool, which is what I think
your suggesting.

>else. 

I agree we don't need a standard to do neat and tricky things to make
our platforms work well in the storm of transition.  But I doubt any of
us vendors will ship a stack that reduces the performance of IPv4 in any
way.  It took a lot of work to get 16bytes to not burn us and it is
suspect to add more to the barrel of engineering we all must do to get
IPv6 out the door and be able to state it is "production" quality.

>But there could be advantages in allocating a single block of IPv4

I disagree.  With the depletion of IPv4 addresses this is not going to
fly with any formal address registrys or with customers.  I faced this
in AIIH trans mechanism and why I provide all addresses to nodes in the
transition scenario dynamically.  

>   Will this work?

Heck Chris many of us on these lists could make anything work as engineers 
and programmers the question I think that should be asked is (and for many
of the transition specs):

    Will this work at a reasonable performance cost and scale for large
    servers and distributed node sets (e.g. clusters, Large MP
    machines) [Routers too but I don't think Routers are concerend
    about the case Chris is presenting].

That I can answer.  NO.  IPv4 performance will be reduced and IPv6
performance will not reach its optimum level.  	

THEN:

    But do you want to do it anyway if the above answer is NO.

It depends and a vendor could add it as a layered product with all the
health warnings on performance, if a customer wanted it.  

I also don't think this needs to be interoperable or portable if it was
done.  Which leads me to believe it may be work for the deployment and
implementors list to parse and not a standards body.

>   Should it be required behavior for conforming UNIX implementations?

Absolutely NOT NOT NOT NOT.  For all the reasons I stated above.

And besides IPv6 cannot be a UNIX only thing for anything we work on
IMO.

/jim

---

From: Jim Bound <[email-masked]>
Date: Fri, 05 Mar 1999 10:49:38 -0500

>I think you overestimate the cost of performace to the IPv4 stack.  It
>seems to me that what Mr. Harding proposed would only affect a small set
>of the socket API calls, and those that are performace critical almost not
>at all.  Basically we're talking about adding a translation layer between
>any functions that return an address to the application, such as
>gethost...(), accept(), and recvmsg(), and functions that require an
>address from the application, such as bind(), connect(), sendmsg().  

>For the vast majority of applications, this is going to mean a few cycles
>(certainly less than 100 microseconds) of extra processing time assuming
>worst case (meaning translation required).  For most applications (those
>that use TCP, like HTTP, FTP, telnet, mail, etc.), this is going to occur
>only at connection setup and breakdown.  The read() and write() calls
>don't need to be translated!  For performance critical (mostly
>server-side) applications, I would recommend linking with seperate IPv4
>and IPv6 interfaces, as is done today.

The performance hit is in two places.  

In the libraries where gethostxxx access the DNS resolver code path.
DNS resolver has to parse all this and that is some code for sure.
And any perf hit in this code path needs serious justification.

In the kernel processing the socket layer for the apps and socket set
calls you speak of above.  Likewise on the justification. 

What do you mean by  "would recommend linking with seperate IPv4
>and IPv6 interfaces, as is done today" above?  I could take that to
mean several things can you expound just on that statement?

It is a cost I will not speculate on the xxxseconds variable because I
did that when I thought 16bytes would not do much to protocol control
block look ups and a bigger IP header would not affect things and I was
wrong.

Lets just agree now it is a performance hit.  We can then go from there.

>Where performance IS going to hit the application is if it is
>connectionless, as in a UDP-based application.  This would affect things
>like NTP and some high-performance cluster software (MPI, PVM, etc.). 
>Having to do a translation on every send or receive would certainly be
>meaningful for large numbers of packets.  Another potential problem set is
>embedded applications, who really can't afford the extra 2 Kbyte or so for
>a table.  In either of these cases, rewrite the code or live without IPv6
>- Mr. Harding has proposed what I think is a neat-o keen alternative,
>which eases integration, not complicates it!

The connection case will require translation for the lookup once it is
found.

>One problem that I see with this methodology is that it requires either
>every application to be re-linked with a library that supports the
>mapping, or that the operating system support it and perform the
>translation before it hits the applications.  Not an impassable hurdle,
>but there it is, and it will almost certainly mean that it will happen on
>Unix systems before other platforms, simply because Unix folks are used to
>compiling their programs before installing them.

Another could point we all need to think about for these implementation
defined thingees anywhere in IPv6.  

If we add anything that breaks std interfaces on platforms that takes
longer to get in a product.  Users are not happy about having to
recompile things all the time including most of my UNIX customers.  So I
am not sure I agree with your premise about UNIX.

/jim

---

From: Shane Kerr <[email-masked]>
Date: Fri, 5 Mar 1999 11:36:18 -0500 (EST)

> And any perf hit in this code path needs serious justification.

Again, this is really not that much code.  For any IPv4 addresses found, a
simple truncation to 32-bits is all you need to do.  This is going to be
only a few addresses per lookup in any case (maximum of 35 addresses on
Solaris 2.6, the machine I'm using now).  Compare this to the overhead of
sending IP packets through the network device and the overhead dwindles to
the point where I think you're going to have a hard time even measuring
it!

> mean several things can you expound just on that statement?

Well, if I want to connect to an IPv6 address, I need to create a socket
with the PF_INET6 flag, and pack sockaddr_in6 structures to define
addresses.  If I want an application that connects to both IPv4 and IPv6
platforms, there's going to be seperate code paths, with one using
PF_INET and sockaddr_in rather than the IPv6 definitions.  Really,
building in a translation layer is merely hiding the details of the
operation inside of an API.

There IS going to be more translation overhead, but not too much.

> Lets just agree now it is a performance hit.  We can then go from there.

I apologize.  I was thinking of modern (i.e. 80486-class or faster)
processors running well-written C code.  This is a mistake, considering
how slow older or embedded CPU's are.  Or Java, for that matter.  :)

> The connection case will require translation for the lookup once it is

No, because when I connect, the API can return a file descriptor.  The
application doesn't have to know that it is "really" an IPv6 connection.
All it has to have is a number to pass to the kernel for read() and
write() calls.  

I don't know if [gs]etsockopt() and ioctl() calls work the same on IPv4
and IPv6 sockets, so these calls may have to be translated as well.  These
should be relatively rare, however.

> am not sure I agree with your premise about UNIX.

Ack!  I'm not happy about NOT being able to recompile things.  :)

I mean, I guess I'm not really sure where your performance concerns lie. 
If I found empirically (by writing and and performing timings) that code
that did what Mr. Harding proposed slowed gethostbyname() calls on a 100
Mbit LAN (using a fast network will increase the relative performance loss
of translation) by 1%, connect() calls by 0.1%, and read() and write()
calls by 0%, slowing a real-world heavy network-usage client application
by 0.001% would that be too much? 

If you say that "any performace loss is too much, all of our CPU cycles
are priceless", then I guess you're right.  But I think that a lot of
consumers don't really understand the real effects of performace loss.
When I've been forced by customers to explain the full algorithms involved
in (say) phone call setup, they can't believe that it's fast enough.

Computers are really fast.

--
Shane Kerr <[email-masked]>
Software Engineer
American Registry for Internet Numbers

---

From: Jim Bound <[email-masked]>
Date: Fri, 05 Mar 1999 12:28:05 -0500

Most of the discussion is happeing on the deployment list now.
I will respond to Shanes last message there and cc Shane so he can 
participate.

I did not cc deployment list for this msg.

thanks
/jim

---

From: Shane Kerr <[email-masked]>
Date: Fri, 5 Mar 1999 10:22:08 -0500 (EST)

> as its brainstorming about implementation it can be done on deployment list.

I've reduced the set to deployment and IETF (since I'm only on the IETF
list).