To:
matthew.ford@bt.com
cc:
bmanning@ISI.EDU, <dnsop@cafax.se>
From:
Pekka Savola <pekkas@netcore.fi>
Date:
Mon, 14 Jul 2003 22:55:41 +0300 (EEST)
In-Reply-To:
<ADEC16A81CFF17489F5A2A9E1D2226DE01E1D3A1@i2km41-ukdy.nat.bt.com>
Sender:
owner-dnsop@cafax.se
Subject:
RE: IPv6 DNS Autoconfiguration
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
#----------------------------------------------------------------------
# To unsubscribe, send a message to <dnsop-request@cafax.se>.