Folks,

I worked on this design team.  Many of these issues came up and they are coming up 
again.
The draft you see is the design team and IETF meeting discussion.  It is good to get 
this right.

The driver for this design team and this work was to develop a very quick IETF tracked 
spec that could also be delivered to the market quickly.  The reason was that clients 
required the DNS parts we are all discussing.  But I think some very important 
questions have been raised.But with what I say below does not change the market 
requirement and that should be somewhere in the requirements doc to so all understand 
the assumptions the design team was under to develop a fast and quick solution.  

I do think we need to revmove the wording of "serverless" or "server" as Rob and 
Thomas have pointed out real technology and I believe market issues with such 
terminology.

I do think Ralph provided some new reqs we did not discuss in the design team that 
need to be part of the reqs doc per his exchange with Keith.  And configuration is 
pretty important and how many ways do we get to do it with IPv6 ??????????  

I am also very concerned about the use of anycast for servers?  I believe we can do it 
but right now our address arch spec says no way for anything but routers using anycast 
addresses and the issues Itojun has pointed out in his work on anycast.

I think we do need to revisit the entire purpose of the "O" bit and I think now it 
should be deprecated.  It will also make building a dhcp for IPv6 client much easier.  
The dhcp for Ipv6 work is in very good shape.  More on that below.

One proposed solution I supported with Bob which did not make it was using RAs to send 
the node DNS Server related information so the client could connect to the DNS. 

But now we do have dhcp for IPv6 and implementations underway and the Information 
Request option can be built very lightweight to support DNS and some other pieces very 
well colocated with a Router or DNS Server.  There are other options too I won't go 
into just yet.  Or I could drift into a product discussion and thats not for here I 
hope.

Also HP and Linux have working dhcp for IPv6 code running and others are in process 
for real implementation input.

Lastly I am not clear cellular hosts won't want the dhcp for IPv6 process or 
application (Rob made a good technical and philosophical point about this too and both 
are part of our process) instead of stateless in many situations.

regards,
/jim

> -----Original Message-----
> From: Rob Austein [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, April 28, 2002 3:41 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Proposed IPv6 DNS Discovery Requirements
> 
> 
> At Fri, 26 Apr 2002 15:38:35 -0700, Bob Hinden wrote:
> > 
> > There are issues raised in solutions like this to insure that the 
> > co-located services are adequately tied together.  For 
> example in case of a 
> > "DHCP server in the DNS server" the processes need to be 
> tied together in a 
> > manner that the DHCP process would not provide the address 
> of the DNS 
> > server if the DNS server process was down.  Or that the 
> DHCP server not 
> > provide the addresses for other DNS serves unless it knows 
> that they are up 
> > and available.
> 
> I suspect that upon close examination all solutions will have issues
> along these lines (anycast certainly does).
> 
> In any case, I agree that such issues are part of the analysis.
> 
> > So I think the examples you raised do fit with the 
> definition.  My intent 
> > was that the requirements should allow for a of number different 
> > solutions.  Picking a specific solution requires evaluating 
> the strengths 
> > and weaknesses of the specific solution.
> 
> Ok, thanks.
> --------------------------------------------------------------------
> IETF IPng Working Group Mailing List
> IPng Home Page:                      http://playground.sun.com/ipng
> FTP archive:                      ftp://playground.sun.com/pub/ipng
> Direct all administrative requests to [EMAIL PROTECTED]
> --------------------------------------------------------------------
> 

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------

Reply via email to