Subject: API Discussion RE: v6ops Agenda for Atlanta

From: "Bound, Jim" <[email-masked]>
Date: Fri, 15 Nov 2002 10:39:02 -0500

Why is ipv4mapped still being discussed in this sense.  Itojun was told
clearly that we are NOT going to change the API defaults with current
deployed products.  This has been discusseed to death and a standard in
IEEE.

Any other working group member who was NOT the chair would be told to go
away.

/jim
[Honor, Commitment, Integrity]

> -----Original Message-----
> From: Margaret Wasserman [mailto:[email-masked]] 
> Sent: Friday, November 15, 2002 5:40 AM
> To: [email-masked]
> Subject: v6ops Agenda for Atlanta
> 
> 
> 
> Here is the draft agenda for our v6ops meeting in Atlanta. 
> Please let me know if there are any questions or comments, or 
> if I seem to have omitted anything.
> 
> Margaret
> 
> 
> 
> IPv6 Operations WG (v6ops)
> Wednesday, November 20, 2002, 0900-1130 
> =======================================
> 
> CHAIRS:  Jun-ichiro "Itojun" Hagino <[email-masked]>
>           Margaret Wasserman <[email-masked]>
> 
> AGENDA:
> 
> Introduction and Agenda Bashing -- Margaret (5 min)
> 
> Report from Interim Meeting -- Margaret (5 min)
> 
> Deployment Scenario/Analysis Status & Open Issues:
> 
> 	Unmanaged Networks Team -- Christian Huitema (20 min)
> 	
> http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-unmansc
> ope-02.txt
> 	
> http://www.ietf.org/internet-drafts/draft-huitema-ngtrans-unma
neval-01.txt

	ISP Team -- Cleve Mickles (20 min)
	
http://www.ietf.org/internet-drafts/draft-mickles-v6ops-isp-cases-02.txt

	Enterprise Team -- Yanick Pouffary (20 min)
	
http://www.ietf.org/internet-drafts/draft-pouffary-v6ops-ent-v6net-01.tx
t

	Cellular Networks Team -- Jonne Soininen (20 min)
	
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-3gpp-cases-00.txt
	
http://www.ietf.org/internet-drafts/draft-wiljakka-3gpp-ipv6-transition-
02.txt

Current Work Items (Status & Open Issues):

	Transition Mechanisms -- Erik Nordmark (10 min)
	
http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-mech-v2-01.txt
	
Proposals for New Work Items:

	Application Aspects of IPv6 Transition (5min) - Myung-Ki Shin
	
http://www.ipv6.or.kr/Internet-Draft/draft-shin-v6ops-application-transi
tion-00.txt

	6to4 Security -- Pekka Savola (5 min)
	
http://www.ietf.org/internet-drafts/draft-savola-v6ops-6to4-security-00.
txt

	Firewalling Considerations for IPv6 -- Pekka Savola (5 min)
	
http://www.ietf.org/internet-drafts/draft-savola-v6ops-firewalling-00.tx
t

	IPv4 Mapped Addresses Considered Harmful -- Craig Metz (10 min)
	
http://www.ietf.org/internet-drafts/draft-cmetz-v6ops-v4mapped-api-harmf
ul-00.txt 

http://www.ietf.org/internet-drafts/draft-itojun-v6ops-v4mapped-harmful-
01.txt

---

From: Margaret Wasserman <[email-masked]>
Date: Fri, 15 Nov 2002 11:33:17 -0500

Hi Jim,

It is true that we did discuss the IPv4 mapped address issues in 
Sunnyvale.   At that time,
Itojun presented one draft that concerned two different parts of the 
issue:  what should and
shouldn't be sent on the wire, and what should and shouldn't be passed by 
the API,
particularly in a dual stack.

There was some agreement in the meeting that there are issues with using 
IPv4 mapped
addresses on the wire that need to be documented, although it was not clear 
what action we
should recommend to correct  these issues -- updating  the IPv6 addressing 
architecture,
modifying SIIT, etc.

The API portion was much more controversial, and there was a general 
consensus in the room
not to impose any API changes on existing implementations.  Of course, the 
whole WG was not
necessarily represented at the meeting.

Based on the input they received in Sunnyvale, Craig and Itojun have split 
the document into
two parts -- the on-wire part and the API part, and they have updated both 
parts.  This will
allow us to consider the two parts separately.

There was enough interest and discussion in Sunnyvale, at least regarding 
the on-wire issues
that it seemed worthwhile to discuss this again in Atlanta to see if this 
is something that the
v6ops WG should document.

Margaret

---

From: "Hesham Soliman (EAB)" <[email-masked]>
Date: Fri, 15 Nov 2002 18:37:40 +0100

> should recommend to correct  these issues -- updating  the 

=> I would not say we agreed on this, I for one don't 
think the scenarios presented by Itojun as valid. I
believe others made the same comment.

Hesham

---

From: "Bound, Jim" <[email-masked]>
Date: Fri, 15 Nov 2002 12:51:20 -0500

Hi Margaret,

> particularly in a dual stack.

Yes I was there.

> should recommend to correct  these issues -- updating  the 

I agree and was there.

> necessarily represented at the meeting.

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

> allow us to consider the two parts separately.

That is good.

> v6ops WG should document.

If this is the discussion I fully agree.

Thanks for listening to my point and responding,
/jim

---

From: Margaret Wasserman <[email-masked]>
Date: Fri, 15 Nov 2002 15:39:44 -0500

Hi Jim,

> > Sunnyvale.   [...]

I remember.  :-)  I was just reviewing for folks who weren't...

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

> > consensus in the room not to impose any API changes [...]
>
>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.

>But it feels like

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?

> > There was enough interest and discussion in Sunnyvale, at
> > least regarding the on-wire issues that it seemed worthwhile to discuss
> > this again in Atlanta to [...[
>

Well, we'll see.   I know that Craig and Itojun are following this thread,
and I'm sure that they will try to focus their attentions on the areas that
might need some attention from v6ops.

>Thanks for listening to my point and responding,

Thanks for letting me know what you were thinking, so that I could
respond.

Margaret

---

From: "Bound, Jim" <[email-masked]>
Date: Sun, 17 Nov 2002 09:55:44 -0500

Hi Margaret,

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

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