Subject: RE: Proposed IPv6 DNS Discovery Requirements

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Tue, 30 Apr 2002 15:56:12 +0200

> >> b) What's the security model by which the router decides 
  > whether to
  > >>    accept routing updates from the DNS server?
  > > 
  > > The same model that is used between routers in the network.
  > 
  > Right, so this approach adds a whole new set of boxes that 
  > can mess up
  > your routing system.  This does not strike me as a good thing.

=> Which boxes does it add? I really don't see any more
boxes here. Note, I'm not advocating this particular
approach (injecting routes from the DNS) but I don't
agree with your claim above, and I think it can work. 

I think something like MLD extensions would be much cleaner.

  > > That's up to your implementation.  The DNS is the only 
  > server using
  > > this address, so you can tie them together.
  > 
  > Sure.  One can do the same kind of thing with the DHCP approach (use
  > SO_REUSEPORT or whatever and tie the DHCP mini server to the DNS
  > server).

=> I believe you :), in fact, since you read the draft
(twice now ;) ) you would have seen that DHCP messages
were also considered for the 'content' part of the
discovery. 

  > The point was just that exactly the same considerations apply to the
  > anycast proposal as apply to other proposals.

=> I think you're mixing the 'content' of the message
used for discovery and the method used for transporting
that message to the right server. Anycast does the latter.
So I don't know why you're comparing anycast with DHCP.
DHCP can also use anycast in theory, I never tried 
it.

Hesham
--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------

---

From: Rob Austein <[email-masked]>
Date: Tue, 30 Apr 2002 13:10:58 -0400

At Tue, 30 Apr 2002 15:56:12 +0200, Hesham Soliman wrote:
> 
> Which boxes does it add? I really don't see any more boxes
> here. Note, I'm not advocating this particular approach (injecting
> routes from the DNS) but I don't agree with your claim above, and I
> think it can work.

This approach would bring the DNS server boxes inside the trust
boundary of the routers.  They're not there now, and if the prospect
of bringing them inside that trust boundary doesn't strike terror in
your heart, you need to spend more time reading bugtraq. :)

> I think something like MLD extensions would be much cleaner.

I agree that something like the MLD extensions would almost certainly
be a cleaner approach than having the DNS servers play routing games
directly.

> I believe you :), in fact, since you read the draft (twice now ;) )
> you would have seen that DHCP messages were also considered for the
> 'content' part of the discovery.

DHCP messages are not discussed in the stateless DNS discovery draft.
Perhaps you're referring to the design team analysis draft?  Don't
worry, I read that too.

> I think you're mixing the 'content' of the message used for
> discovery and the method used for transporting that message to the
> right server. Anycast does the latter.  So I don't know why you're
> comparing anycast with DHCP.  DHCP can also use anycast in theory, I
> never tried it.

Service discovery via anycast has specific problems that I tried to
detail in a previous message.  In brief: using anycast in effect
stores the configuration in the routing system itself and leaves the
client with no recourse if the routing system (for whatever reason)
gives answers that are not useful.  This might be construed as ok if
one assumes that the failure modes are all binary (either everything's
working perfectly or everything's so broken that it doesn't matter),
but I don't think that assumption is realistic, so the fundamental
model of service discovery via anycast seems broken to me.

I agree that the choice of message format is pretty much orthogonal to
the method used for getting the location query to the entity that's
going to answer them.  There's a different set of issues involved in
the choice of message format, which I'd sum up by saying that I think
it'd be better to do configuration using a protocol that was designed
for the purpose than it would be to retrofit configuration hacks onto
a protocol that was designed to do something else.  I don't think it'd
be particularly useful to the WG to dive much further down that
particular rathole right now, so with your permission I'll stop there.
--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------