Subject: RE: WG Review: IPv6 Operations (v6ops)

From: "Bound, Jim" <[email-masked]>
Date: Tue, 10 Sep 2002 00:09:10 -0400

Hi Pekka (again),

> -----Original Message-----
> From: Pekka Savola [mailto:[email-masked]]
> Sent: Monday, September 09, 2002 4:44 PM
> To: Francis Dupont
> Cc: Bound, Jim; Jun-ichiro itojun Hagino; Brian E Carpenter; Fred L.
> Templin; [email-masked]
> Subject: Re: WG Review: IPv6 Operations (v6ops) 
> 
> 
> On Mon, 9 Sep 2002, Francis Dupont wrote:
> >  In your previous mail you wrote:
> > 
> >    > Basic Tunnels
> >    > 6to4
> >    
> >    Sure.
> >    
> > => I am not convinced by 6to4. For instance by the 
> 6to4-relay concept.
> 
> 6to4 relays cause some rather interesting problems, 
> especially relating to 
> quality of service (too few of them at the moment, leading to huge 
> delays connecting to 6to4 nodes from some areas).

I am not going to bash 6to4.  It has its place and there are places it should not be used.  I believe 6to4 will do what it technically states it will do and worked very hard on that draft as working group reviewer and worker.  And have deployed that too with customers.  But for many of my customers it is a non-starter.  It is not proper for me to even discuss that it is not the point.  6to4 went through a technical process not a philosophical process.  This is NOT the Internet Philosophical Task Force.  Though I think some would love it to be and really believe they control the Internet.  Not Not Not the market and the almighty buck, dollar, euro, whatever controls the Internet. Not us here.  We simply build the specs and a suggested architecture.  But egoes seem to get the best of processes at time.

> 
> >    > DSTM
> >    
> >    I'm not yet convinced of this.  Especially I have huge 
> doubts about 
> >    temporary address management scalability and robustness.
> >    
> > => this address management is exactly the current DHCPv4 
> address management
> > (I agree this is not a real answer :-).
> 
> No it *definitely* isn't, or I've misunderstood the intent.  
> What has been
> proposed is something like 'when application requests and 
> address, get it
> from somewhere, after application exists, return it'.  That's very far
> from DHCPv4.  Add the ports option to the stew and you have a mess..
> 
> Running DHCPv4 over DSTM (with reasonable address lifetimes 
> etc.) would
> sound much better than currently proposed.

Read the DSTM Assumptions in the Spec.  This just frustrates me to no end.  The DSTM assumption is as follows.  "THE USER DOES NOT WANT ANYMORE IPv4 PROLIFERATION and forcing IPv6 deployment native".  They do not want to begin their new IPv6 networks or update their networks with DHCPv4.  

And to answer Rob's question.  Yes I know many customers who do understand the DSTM assumptions.

But one DSTM deployment is using DHCPv4 this way but only because DHCPv6 was not done.  The prime systems integrator just delivered a dhcpv6 solution to resolve that.  Again this is a trial network but it will be the production network of tommorrow.

Have you read the latest DSTM spec (like you asked me about Teredo)?

regards,
/jim

> 
> -- 
> Pekka Savola                 "Tell me of difficulties surmounted,
> Netcore Oy                   not those you stumble over and fall"
> Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords
> 
>

---

From: Pekka Savola <[email-masked]>
Date: Tue, 10 Sep 2002 11:18:07 +0300 (EEST)

On Tue, 10 Sep 2002, Bound, Jim wrote:
> > No it *definitely* isn't, or I've misunderstood the intent.  What has
> > been proposed is something like 'when application requests and
> > address, get it from somewhere, after application exists, return it'.  
> > That's very far from DHCPv4.  Add the ports option to the stew and you
> > have a mess..
> > 
> > Running DHCPv4 over DSTM (with reasonable address lifetimes etc.)
> > would sound much better than currently proposed.
> 
> Read the DSTM Assumptions in the Spec.  This just frustrates me to no
> end.  The DSTM assumption is as follows.  "THE USER DOES NOT WANT
> ANYMORE IPv4 PROLIFERATION and forcing IPv6 deployment native".  They do
> not want to begin their new IPv6 networks or update their networks with
> DHCPv4.

Perhaps I failed to convey my intent or you misunderstood it.  

What I meant was v6-only network + DSTM _without_ temporary address 
management.  IPv4 addresses would be handled over IPv6 tunnels by DHCPv4 
server, not the temporary address management system.   The only difference 
would be using existing protocol DHCPv4 for the task;  temporary address 
management would indeed also be possible, and perhaps even useful in the 
cases that addresses are used by a very small number of applications for 
short periods of time only.  But otherwise, it seems like a complication 
right now.
 
> But one DSTM deployment is using DHCPv4 this way but only because DHCPv6
> was not done.  The prime systems integrator just delivered a dhcpv6
> solution to resolve that.  Again this is a trial network but it will be
> the production network of tommorrow.
> 

Indeed, I have read the latest spec (but only cursorily, the only major
thing that has changed is the applicability statement).  I also commented
on -07 (and DSTM-* technologies) on the ngtrans list (17 Mar 2002).  Have
you read my comments (I have received zero direct feedback)?