RE: API Discussion RE: v6ops Agenda for Atlanta

["Bound, Jim" <Jim.Bound@hp.com>]

Hi Margaret,

> Hi Jim,
> 
> > > It is true that we did discuss the IPv4 mapped address issues in
> > > Sunnyvale.   [...]
> >
> >Yes I was there.
> 
> I remember.  :-)  I was just reviewing for folks who weren't...

Yes of course.  Just being a pain here :---)

> 
> > > There was some agreement in the meeting that there are 
> issues with 
> > > using  IPv4 mapped addresses on the wire [...
> >
> >I agree and was there.
> 
> Good, so the v6ops WG needs to decide whether we should 
> produce a document and/or make any recommendations in this 
> area.  Thoughts?

My gut feeling is this and for all NOT MY COMPANY I ALWAYS SPEAK AS JIM
HERE and MY COMPANY HAS NO PROBLEM WITH THAT (in fact all over the world
and in some very intense other places).

I thought I heard consensus that v4mapped should not be on the wire at
interim meeting and on the list.  But here is my bias and not an IETF
norm.  Erik has created these in SIIT.  If he is not comfortable with
this as principle designer of the mechanism then I will support Erik.  I
am tired of watered down designs that are built on consensus.  I started
working with Bob Gilligan on the API as one example in 1994.
Implemented it multiple times and someone is still talking about it.

But if we are to change it or any long time spec that has been
implemented.  I think what we should do is build Extensions to those
specs in separate RFCs esp when it has significant implementation.

Me personally.  I did not like vmapped in SIIT years ago (just like SLs)
and felt it would cause applications confusion.  But we worked around it
and all the security issues Itojun has presented in our implementation,
which I can't go into and sorry about that.

So to reach "forward progress" unless Erik is convinced we document the
known security problems with SIIT in RFC and move on.

> 
> > > The API portion was much more controversial, and there 
> was a general 
> > > consensus in the room not to impose any API changes [...]
> >
> >What you say is true and that was the feeling.  My issue is 
> that this 
> >was discussed on ipng and the apifolks design team. So what 
> we heard at 
> >Sunnyvale Interim meeting is consensus already and Itojun and Craig 
> >know that.  So I don't see why we are revisting it again.
> 
> Obviously, there is quite a bit more history here than I am 
> aware of, as I am no on the API design team...  Now, I am 
> better understanding your point.

Yep.  The mail api list is dormant now but we went to IEEE and the
current model of the default being IPv4 Mapped can be shared by an app
is the standard and implemented widely.

As a note there will be an IPv6 Forum paper on porting to IPv6 that we
will put out in the new year (probably January) and that paper shows
very clearly why we chose what we did as the default.  But the paper is
not ready for prime time just yet to release.
 
> 
> >But it feels like
> >v6ops is being duped to bring it up yet again.  The problem 
> is that the 
> >current API defaults are deployed in production and supported in 
> >practice and spirit by all but two implementations is my 
> knowledge. The 
> >API is now not 2553 but an IEEE spec/std. So I sense 
> politics here but 
> >if you want to have this come up again that is your choice 
> as chair.  
> >But we are not going to break customers at this point using 
> IPv6 is my 
> >strong guess.
> 
> One point that I should make very clear:
> 
> The v6ops group is NOT chartered to make any changes to the 
> IPv6 APIs and/or the IPv6 specifications.  We are chartered 
> to identify real operational and/or security issues and make 
> recommendations to the IPv6 WG, as appropriate.  In this 
> case, we need to figure out if there an issue here that 
> should be documented, and then decide if we want to recommend 
> any changes.  From the discussion in Sunnyvale, there seems 
> to be significant resistance to any changes, which is fine.
> 
> Do you think that there is a real technical issue here that 
> operators and implementors need to be aware of?  Or, is this 
> a non-issue?

I think v4mapped on the wire is something we do need to be sure is
figured out and we need to make a statement.

For the API default this has nothing to do with operators and why I
don't like to see it presented here by Itojun and Craig and why I feel
v6ops is being used as a poltical backdoor to bring this up again.  

I have been accused of beating a dead horse on SLs.  OK this API is
older and tons more of a dead issue.

I don't think v6ops has the charter to be experts around APIs and in
fact no where in the IETF.  It just so happens we have lots of
implementors who do build APIs but that is serendipity not a charter.

FYI the only issue we have left is the scope_id for the base api and we
have now stated see future work.  2553-bis-07 should go to Information
RFC and any new parts folks want for the API can be NEW documents.  But
my bias is we need to do APIs in the IEEE where they are truly chartered
and have integral processes to build APIs.

thanks

/jim
[Honor, Commitment, Integrity]