Subject: Re: (ngtrans) "Bump-in-the API" idea

From: Jim Bound <[email-masked]>
Date: Thu, 08 Jul 1999 23:17:06 -0400

I don't believe any BIS idea can be standardized.  Informational yes.
We could not get all the vendors to agree on the exact interfaces for a
standard.

I also am not clear there is a business case in the market for such a
mechanism unless it is truly bug free and robust.

I agree the loadable module idea is a neat idea though if one had to do
BIS.  

Might this discusision be better suited to the implementors list?

/jim

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 09 Jul 1999 08:24:32 -0500

Agreed, it clearly can't be standards track work.

Also note that its architectural issues are isomorphic with those
for the RSIP proposal (in the NAT WG) and to some extent with
the NAT issues. So it isn't a panacea.

  Brian

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter (IAB Chair)
Program Director, Internet Standards & Technology, IBM Internet Div
On assignment for IBM at http://www.iCAIR.org 
Non-IBM email: [email-masked]

---

From: Jim Bound <[email-masked]>
Date: Fri, 09 Jul 1999 12:55:22 -0400

>I don't know...NATs aren't bug free or robust, and they seem to be doing
>a good business.  Bump-in-the-foo seems more-or-less about as buggy
>or robust as a NAT.

Touche ... Good point.

But I don't think we can standardize them anymore than we could NAT but
if they are to become pervasive some info and analysis in the IETF on
them is prudent like we are doing for NAT.

I do think we may be jumping the gun though that we need these though.
I can't think of to many net utilities that will not have been ported to
do Ipv4 or IPv6 by most vendors by Jan 2000 based on the implementation
rate I see.

But private customer in-house apps and then ISV apps are a different
story.  

So one characterization that would be useful to be discussed (and was
part of what I was working on before I got ill) is what is the
application landscape reqs for transition for IPv6/IPv4 nodes.

/jim

---

From: Keith Moore <[email-masked]>
Date: Fri, 09 Jul 1999 02:56:29 -0400

---

From: Peter Tattam <[email-masked]>
Date: Sat, 10 Jul 1999 15:12:19 +1000 (EST)

> do Ipv4 or IPv6 by most vendors by Jan 2000 based on the implementation

I think this is overly optimistic for the PC scene.  While winsock 1.1 API is
wide use and has been for at least 5 years, the Winsock 2 spec has been out for
a couple of years and take up of the new API has not been good. Despite this
most SW vendors have not upgraded their apps to it.  I predict that most
binaries for the internet won't be upgrade in the near future as a result. 
This huge installed base of software must be supported for Ipv6 to have any
credibility.  This is the crux of my arguments for Bump-in-the foo
implementations.

--
Peter R. Tattam                            [email-masked]
Managing Director,    Trumpet Software International Pty Ltd
Hobart, Australia,  Ph. +61-3-6245-0220,  Fax +61-3-62450210

---

From: Jim Bound <[email-masked]>
Date: Sun, 11 Jul 1999 21:51:09 -0400

>credibility.  This is the crux of my arguments for Bump-in-the foo

The apps I was talking about were the std OTB net apps like ftp,
telnet, sendmail, bind/dns, nfs, yp, http, et al.

Also the std OTB net utilities like traceroute, ping, netstat, tcpdump,
ifconfig, et al.

Also the std daemons inetd, ppd, et al.

After the above we are talking about custom business applications that
use the network or custom network applications

The list above mostly has been ported and running and tested on the
6bone and at the UNH Interoperability Tests and Connectathon.

Please list for us what you call the "huge base of software" with a few
examples that will need to be ported to IPv6?   

Also I envision users first adopting IPv6 and using it just with the
above std net apps, utilities, and daemons.  As that begins at the
customer site they will begin to work with their software suppliers and
ISVs to move apps to IPv6 for there business.

I agree with you the PC environment will have more apps to move to the
IPv6 network paradigm but I believe those will be the last to deploy
IPv6 except the std net parts I mention above.

/jim

---

From: Peter Tattam <[email-masked]>
Date: Mon, 12 Jul 1999 13:17:52 +1000 (EST)

> examples that will need to be ported to IPv6?   

Go to www.tucows.com  to get one possible sample list of third party software
for the internet.  The bulk of these would not require modification if BIS
techniques are used.  Generally they are written to coexist with firewalls and
NATs, so the BIS techniques should also work in most cases.

> IPv6 except the std net parts I mention above.

The pc world is totally different to the unix world in this regard.  Generally
the supplied tools are fairly basic and so there is a large market for third
party apps.  I wouldn't like to hazard a guess regarding relative percentages,
but just to say "significantly more" than for the unix market.

The pc world is the fastest moving so I wouldn't say that too loudly.  Any ISP
who seriously wants to embrace IPv6 technology would want to make sure their
installed user base was able to successfully utilize IPv6.  I think I could
come up with realistic examples.  A classic one would be a Cable ISP that can't
get sufficient IPv4 allocation to provide manageable internet access.  Their
customers would be typical pc users.  If their service did not support BIS for
transition, the service would be sunk before it started.

> /jim

Peter

---

From: Jim Bound <[email-masked]>
Date: Mon, 12 Jul 1999 00:01:05 -0400

>NATs, so the BIS techniques should also work in most cases.

I went there and what I saw were more net std apps as I stated in my
previous mail.  I did not see anything that the business community needs
to do business was my point.  Clearly there are a whole class of apps
that are useful to PC users as the above web page discloses.  I knew
that and agree that BIS could be useful for those PC apps.

So I agree for the PC centric app BIS could be useful down the road,
when they cannot get any IPv4 address and NAT is an option they would
rather not use.

>transition, the service would be sunk before it started.

I don't agree with you and we can just leave it at that.  If the OTB
network apps support IPv6 (note on the web page you provide a lot of the
apps were exactly this) then the Cable ISP will have a start.  I will
give you one better; if the PC's stacks are not shipping an IPv6 stack they
are definitely sunk.  The PCs need a production quality IPv6 stack on
the market even before BIS is helpful.

IPv6 will also be deployed on Intranets and with 6to4 those Intranets
will be able to communicate for business operations.  So manufacturing
plant A in Rochester NY can communicate with their manufacturing plant B
in Cleveland OH , likewise Banking can be done this way too.  

Each of us have our IPv6 target market biases in the IETF I am sure.

I have stated that BIS can be useful, but cannot be standardized by the
IETF.

I am not sure further discourse is needed at my end?

/jim