[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


To: bmanning@ISI.EDU, pekkas@netcore.fi
Cc: dnsop@cafax.se
From: matthew.ford@bt.com
Date: Tue, 15 Jul 2003 08:47:38 +0100
content-class: urn:content-classes:message
Sender: owner-dnsop@cafax.se
Subject: RE: IPv6 DNS Autoconfiguration

In the same way that they find/extract the local DNS policy information
before configuring existing DHCP services I expect.

Mat.

> -----Original Message-----
> From: Bill Manning [mailto:bmanning@ISI.EDU]
> Sent: 15 July 2003 08:49
> To: Pekka Savola
> Cc: Ford,M,Mat,XGH5 FORDM5 R; bmanning@ISI.EDU; dnsop@cafax.se
> Subject: Re: IPv6 DNS Autoconfiguration
> 
> 
> 
>  yes, yes... thats not the question.  the question is, how do the
>  good folks who propose this method fo DNS discovery expect to 
>  find/extract the local DNS policy information to try and ensure
>  garbage is not handed out?
>  
> 
> % On Mon, 14 Jul 2003 matthew.ford@bt.com wrote:
> % > we are all free to fill our /etc/resolv.conf with garbage 
> if we want.
> % 
> % Moreover, we are all free to (try to) feed our 
> clients/customers garbage
> % if we want.
> % 
> % I'm not guaranteeing you'd get popular by doing so, but 
> that's another 
> % issue.
> % 
> % > > -----Original Message-----
> % > > From: Bill Manning [mailto:bmanning@ISI.EDU]
> % > > Sent: 14 July 2003 21:09
> % > > To: Pekka Savola
> % > > Cc: dnsop@cafax.se
> % > > Subject: Re: IPv6 DNS Autoconfiguration
> % > > 
> % > > 
> % > >  mind, I am very concerned w/ the goofy IPR/Note Well 
> restrictions,
> % > >  so posting/participating is -very- infrequent.  but to 
> pose a query
> % > >  to the assembled multitude:
> % > > 
> % > >  BIND, a common DNS implementation has the ability to 
> apply access
> % > >  controls as a local policy matter as to who can and can not use
> % > >  a "recursive resolving nameserver" or what ever it was 
> that Rob said 
> % > >  it was.  If one uses the RA/ND techniques, how does 
> one expect to
> % > >  extract the local DNS policy information before 
> handing out server
> % > >  info via the RA/ND method?
> % > > 
> % > >  this weakness was not touched on during Bob Hindons 
> presentation
> % > >  and I did not stay for the rest of the sessions festivities
> % > > 
> % > > 
> % > > 
> % > > 
> % > > % On Mon, 14 Jul 2003, Masataka Ohta wrote:
> % > > % > > Beforehand, I'd like to summarize my talk for today's
> % > > % > > discussion about DNS Discovery and Autoconfiguration.
> % > > % > 
> % > > % > Autoconfiguration, as expected by IPv6 folds, is 
> just impossible
> % > > % > that it is a pity that DNSOP WG is contaminated.
> % > > % > 
> % > > % > Autoconfiguration is easy on a single link isolated from the
> % > > % > Internet. But, that's all.
> % > > % 
> % > > % FWIW, my opinion on the subject;
> % > > % 
> % > > % DHCPv6-lite has been proposed as a means how to fix 
> this problem.
> % > > % 
> % > > % My issue with DHCPv6-lite is that DHCPv6 spec is some 89 
> % > > pages, and most 
> % > > % options are some 5 (or more) pages more, each.
> % > > % 
> % > > % Even though DHCPv6-lite is only a subset of that, it 
> still requires 
> % > > % reading, understanding etc. a lot of it.  It's much more 
> % > > difficult to get 
> % > > % the "big picture" of DHCPv6-lite this way.
> % > > % 
> % > > % Now, if we had specified DHCPv6 without address 
> assignment (like I
> % > > % suggested, but that's beside the point), and put all of the 
> % > > stateful stuff
> % > > % ("cruft") in a separate "extension" RFC, we'd be talking 
> % > > about an entirely
> % > > % different issue.
> % > > % 
> % > > % I was a very simple to implement, robust mechanism 
> that's easy to 
> % > > % understand.  Reading 20 selected pieces of a large document 
> % > > fills that 
> % > > % requirement, IMHO.
> % > > % 
> % > > % I want a spec which is simple and clear, and less than 
> % > > 15-20 pages long.
> % > > % 
> % > > % -- 
> % > > % Pekka Savola                 "You each name 
> yourselves king, yet the
> % > > % Netcore Oy                    kingdom bleeds."
> % > > % Systems. Networks. Security. -- George R.R. Martin: A 
> Clash of Kings
> % > > % 
> % > > % 
> % > > #-------------------------------------------------------------
> % > > ---------
> % > > % # To unsubscribe, send a message to <dnsop-request@cafax.se>.
> % > > % 
> % > > 
> % > > 
> % > > -- 
> % > > --bill
> % > > 
> % > > Opinions expressed may not even be mine by the time you 
> read them, and
> % > > certainly don't reflect those of any other entity (legal or 
> % > > otherwise).
> % > > 
> % > > #-------------------------------------------------------------
> % > > ---------
> % > > # To unsubscribe, send a message to <dnsop-request@cafax.se>.
> % > > 
> % > 
> #-------------------------------------------------------------
> ---------
> % > # To unsubscribe, send a message to <dnsop-request@cafax.se>.
> % > 
> % 
> % -- 
> % Pekka Savola                 "You each name yourselves king, yet the
> % Netcore Oy                    kingdom bleeds."
> % Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
> % 
> 
> 
> -- 
> --bill
> 
> Opinions expressed may not even be mine by the time you read them, and
> certainly don't reflect those of any other entity (legal or 
> otherwise).
> 
> 
#----------------------------------------------------------------------
# To unsubscribe, send a message to <dnsop-request@cafax.se>.

Home | Date list | Subject list