Subject: (ngtrans) Re: Ipv6 Migration

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Fri, 05 Mar 1999 19:56:51 +0900

>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.
(snip)
>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.

	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)

>The questions are:
>   Will this work?
>   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: Brian E Carpenter <[email-masked]>
Date: Fri, 05 Mar 1999 13:30:39 +0000

(copies cut down to the NGTRANS list)

I've been thinking about this occasionally for some months. The down 
side is that the address is transient, so any existing middleware
or apps that rely on the IPv4 address being fixed will fail.

Also you have to consider whether the pool of addresses is guaranteed
globally unique. If it is, then it's hard to see why the site
has moved to v6 anyway. If it's not, then we have a whole bunch
of NAT-like issues to resolve.

If someone has cycles to develop a full draft on this, that would be
great. If it does work, it would give us a full applications
suite immediately.

   Brian

---

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?

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

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.

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

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.

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

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.

>6. When an application binds to a v4 address from the pool, subsequent
>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.

>This doesn't actually require standardization. An individual vendor who
>obtained a block of IPv4 addresses could do it without consulting anyone
>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
>addresses for everyone to use in this way.

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 09:18:50 -0500

Brian,

See my note to Chris.  Not without pain.  We have some criteria what we
do to users platforms.  If we reduce IPv4 existing performance that is a
non starter.  Other issues in my response I won't state again.

I think this should be worked on the deployment list not here.

/jim

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 05 Mar 1999 15:06:59 +0000

I actually don't care too much which list, as long as it's only
one and we get some serious peer review, since this isn't
a no-brainer.

    Brian

---

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

>one and we get some serious peer review, since this isn't

I'll say its not.

/jim

---

From: Craig Metz <[email-masked]>
Date: Fri, 05 Mar 1999 12:27:44 -0500

In message <[email-masked]>, you w
>   Should it be required behavior for conforming UNIX implementations?

  This sort of approach was examined in NGtrans long ago. Doing it totally the
way you describe won't work for a number of reasons, but doing almost the same
thing as an in-the-kernel NAT has been looked at and I believe the KAME group
has implemented something along those lines. It is doable, it works as well and
as poorly as any other NAT does, and it probably should not be required.

									-Craig

---

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

Hi -

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?

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

---

From: Chris Harding <[email-masked]>
Date: Fri, 05 Mar 1999 14:16:31 +0000

Dear Brian,

The IPv4 addresses never go outside the host. So each host can use the
same pool of IPv4 addresses. Since it only has to cater for a single
host's requirements, the pool need not be enormous. The addresses will
be transient, but it would probably be possible to have a big enough pool
that a minumum of several days would elapse before re-use. The 
implementation could monitor use of each address and count the days
from the last use of the address, rather than from when the address
is allocated. There would no doubt be some middleware or applications
that would fail, but hopefully they would be rare.

Regards,

Chris
+++++