Subject: (ngtrans) DSTM Issues

From: Jim Bound <[email-masked]>
Date: Tue, 20 Jul 1999 14:14:33 -0400

Folks,

First my co-authors are on holiday and we did communicate but we need to
review what I am about to state but want your input in the meantime so
we can start working on the issues next week.  I received Oslo input from 
the chairs on DSTM and I am sure at this point not all input from Oslo.
But.....

It has been suggested that what we do with DSTM to move it quickly is
remove the parts where a node out on the IPv4 Internet will try to
access an IPv6 FQDN for a service.  This will greatly reduce the
complexity of understanding the DNS interaction in DTSM to resolve that
action.  This is ok for the next two years IMO because when I first
envision'd this with AIIH it was a feature I added for the future.  I
don't believe any "IPv6 aware app servers in a DMZ" will only have IPv6 
addresses for at least the next three years, and IPv6 will have been on 
the street for close to two years at that time.  Then what we would do is 
have a follow on draft for this specific issue.  But see below my last 
comments on this issue.  

We also will provide an extensive DSTM overview which gives the reader a
good start before delving into DSTM.

We also have document structure issues from combining AIIH and DTI.  We
knew we could not fix that by Oslo and did not try.  Thanks for bearing
with us on that issue.

We will also give serious thought to dropping the need for TEP RRs but
look for our approach to find TEPs as needed.

If your tracking DHCPv6 in that WG you know we are doing finish up work
and making real sure we don't loose the good things from DHCPv4
Technology within DHCPv6.  Charlie and I also have another co-author
Mike Carney from Sun who is a product implementor for DHCPv4 and this
will make DHCPv6 even better.  My hope is the basic architecture does
not change for those of us who have started implementations.  I doubt
that will happen and the additions and changes will be more at the
application function layer than the kernel layer affecting our code done
to coexist with Stateless Addr Conf.  But just in case I have stopped my
DHCPv6 implementation and have suggested to other implementors to do the
same until the next draft which will come out around Oct/Nov timeframe.
The good news is that we can now get the extensions we need for IPv6
Transition most likely on the table for the DHCPv6 updates.  We look for
WG last call and to the IESG if the plan works March 2000.  This should
not affect DSTM as DHCPv6 is needed and will be here for IPv6.

If you have DSTM input please send it to us now and the WG so we can
have as much input as possible to get a new draft out.

On the DNS issues above for incoming v4 requests to the DSTM server.
In the interim I am going to review what it would take to get this done
and available to vendors supporting a DHCPv6/DNS co-located server. What
I am to propose to my company and I don't know if I can pull this off is
if I can give my DHCPv6 code base (given the time frame above) to ISC
and ISC has a V6 DNS implementation underway now, and contract them out
via the BIND vendors to get this working and running as a defacto option
to BIND.  They would need a stateless IPv6 implementation too but I will
look at the capability of building DHCPv6 in a manner that it can work
with any "compliant" stateless addr conf implementation by using wrappers
where interaction is defined and using an ascii text database for the
config parts and most likely a simple file and mmap where appropriate.
This should be fairly portable.  This way if customers need this feature
before 2 years we have a mechanism in the industry to provide it.

Sounds like Laurents presentation was very interactive we look forward to
more input on the mail list.

thanks
/jim

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 20 Jul 1999 16:51:00 -0500

Jim Bound wrote:
...
> envision'd this with AIIH it was a feature I added for the future.  
...

I think this is a good approach.

  Brian