Subject: Revised IPv6 charter and DNS discovery

From: Thomas Narten <[email-masked]>
Date: Wed, 05 Mar 2003 10:22:59 -0500

note: AD hat on.

Bob & Margaret have sent me a revised IPv6 charter that I have
forwarded to the IESG/IAB for consideration. It is largely consistent
with the charter that the WG has already seen and supported with one
exception. "DNS discovery" is not included in the charter.

I asked that this item be removed from the charter for several
reasons:

- If I were to take it to the IESG/IAB (who get to review all WG
  charters), I would expect to get strong pushback on including the
  DNS discovery work in the IPv6 WG. Reasons would include:

  - this is not IPv6-specific work, it should be done in a broader
    IETF context, e.g., where the DNS operational expertise resides
    such as in DNSOP.

  - why not just use DHC? I know that many are opposed to including
    DHC as part of the solution, but that view is not universally
    shared, understood, or agreed too. Especially outside of the IPv6
    community.

  - what about the technical concerns that have been raised regarding
    the approach in the current draft? (See Erik Nordmark's
    presentation at the Yokohama meeting, for example.) IMO, there has
    been a lack of rigorous consideration of the issues that have been
    raised.

  Although I have heard the arguments coming from proponents of the
  DNS discovery work, I have not been strongly convinced. Moreover, I
  also have heard the arguments against the approach in the current
  document from others, and find their arguments to have merit as
  well. That puts me in the awkward position of arguing for a position
  within the IESG that the WG supports, but that I have concerns with
  and where I don't have strong answers for addressing those
  concerns. The issues here are not black-and-white.  I see that there
  are multiple sides to the argument, but this group seems to have
  difficulty in having a technical discussion about those issues. It
  seems like the WG is to a large extent tired of this issue and just
  wants to have an RFC.

- the dns discovery effort has dragged on for way too long (more than
  2 years), and due in part part to the history, I have doubts about
  this WG being able to have a productive discussion on the topic
  anymore. Being very aware of ongoing discussions and concerns being
  discussed on, e.g., the problem-statement list, it is time to make
  some decisions and move on. One of those decision may just be that
  the idea of a quick-and-simple DNS discovery has missed its window
  of opportunity, and we just need to move on.
  
- the current approach of interest assumes the use of SL
  addresses. Given the issues swirling around SL and to what degree
  the WG wants to encourage or limit their usage, I find it hard to
  believe that the current ID is a good way to go forward. It would
  seem odd to recommend this approach while simultaneously still
  having discussions about how much to discourage the usage of
  site-local addressing.
  
- it is not clear to me there is really consensus for the current
  document at this point in time, whatever past concensus there might
  have been.  Moreover, it's not clear how much support the selected
  approach has outside of the IPv6 community. This gets back to an
  earlier point about doing the work in consultation with the right
  experts.

Where to go from here? If there is truly interest in continuing this
work, it might make sense to engage the DNSOP WG to see what kind of
interest there is there _for the problem statement_ before even
discussing any particular approach. It might also make sense to host a
BOF on either the narrow topic of DNS discovery or the broader topic
of service discovery. Steve Deering posted a long note a while back on
"serverless discovery" that I think was quite interesting, but much
work needs to be done to flesh that out, assuming there is interest in
doing so. Finally, there is always DHC (the IESG approved DHCPv6 as a
PS at the end of 2002), so the IETF _does_ have a recommended approach
-- it's just one that some people don't like.
  
Thomas 
--------------------------------------------------------------------
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: Pekka Savola <[email-masked]>
Date: Wed, 5 Mar 2003 17:40:11 +0200 (EET)

> exception. "DNS discovery" is not included in the charter.

FWIW, I support this approach.

A BOF would likely be the best approach if we want to explore and find the 
best solution(s).  If we want to push just one/two solutions, dnsop/dnsext 
(where appropriate) or even v6ops  (this is a deployment problem, you 
could argue ;-) -- but there's already a bit much on that plate) would do.

Btw, personally, I have a gut feeling that a neighbor discovery option
would probably be a simple approach, though it isn't without its own 
problems (like monitoring the lifetime of the DNS resolver in the 
advertisements).

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: "James Kempf" <[email-masked]>
Date: Wed, 5 Mar 2003 09:09:37 -0800

Thomas,

I support this change.

Regarding what to do with the DNS server discovery work, I think a BOF would be
an appropriate approach. Steve Deering's serverless discovery is an interesting
approach, and I think it deserves some consideration, but I've heard plausible
reasons why DNS server discovery might be an exception to the general case of
service discovery so one topic of such a BOF would be sorting that out.

            jak

---

From: Alain Durand <[email-masked]>
Date: Wed, 05 Mar 2003 10:08:23 -0800

Thomas,

[co-Author of the DNS discovery draft hat on]

I agree with your assessment that this proposal
has missed its window of opportunity.
We could probably do a very interesting post-mortem analysis
why in the context of the problem-statement list, but this is not
the topic for today's discussion.

Now that DHCPv6 is eventually going to be published and implemented,
the pressure for an alternate solution specifically for DNS is much 
lower
and I would agree we should now step back and look
at the more general problem from a fresh start.

There are actually two different topics that could be discussed
in a bof:

	- is DHCP enough for general parameter configuration or is
	  there a significant enough problem space where its not
	  applicable/desirable? For example, for address configuration,
	  we have DHCP and stateless autoconf. Does this dichotomy
	  between server-helped and self-derived configuration applies to
	  other services?

	- What does it mean to use 'well known voluntary ambiguous' addresses
	  for service configuration?
		This is a discussion I had with Steve Deering before he went
		on sabbatical. This is the equivalent of the '911' service:
		wherever you are, you dial 911 and you are connected to the emergency
		service. Can we use this paradigm for services that are
		supposed to be somehow 'universal'?
		For example, you want a NTP server, try '777::1', you want a DNS 
server,
		try '411::1',... Charge to the network to make sure the 'call' 
connects
		to the right place. The devil is, of course, in this last sentence.

	- Alain.

---

From: Bill Manning <[email-masked]>
Date: Wed, 5 Mar 2003 10:17:37 -0800 (PST)

As a co-author of a couple of previous DNS discovery IDs, I would
have to agree that as postulated, the current DNS discovery work
has pretty much been OBE. (overtaken by events)
There have been two distinct BOFs on this idea in the last five years
so I don't think another BOF will be very productive.

% Thomas,
% 
% [co-Author of the DNS discovery draft hat on]
% 
% I agree with your assessment that this proposal
% has missed its window of opportunity.
% We could probably do a very interesting post-mortem analysis
% why in the context of the problem-statement list, but this is not
% the topic for today's discussion.
% 
% Now that DHCPv6 is eventually going to be published and implemented,
% the pressure for an alternate solution specifically for DNS is much 
% lower
% and I would agree we should now step back and look
% at the more general problem from a fresh start.
% 
% There are actually two different topics that could be discussed
% in a bof:
% 
% 	- is DHCP enough for general parameter configuration or is
% 	  there a significant enough problem space where its not
% 	  applicable/desirable? For example, for address configuration,
% 	  we have DHCP and stateless autoconf. Does this dichotomy
% 	  between server-helped and self-derived configuration applies to
% 	  other services?
% 
% 	- What does it mean to use 'well known voluntary ambiguous' addresses
% 	  for service configuration?
% 		This is a discussion I had with Steve Deering before he went
% 		on sabbatical. This is the equivalent of the '911' service:
% 		wherever you are, you dial 911 and you are connected to the emergency
% 		service. Can we use this paradigm for services that are
% 		supposed to be somehow 'universal'?
% 		For example, you want a NTP server, try '777::1', you want a DNS 
% server,
% 		try '411::1',... Charge to the network to make sure the 'call' 
% connects
% 		to the right place. The devil is, of course, in this last sentence.
% 
% 
% 	- Alain.
% 
% --------------------------------------------------------------------
% 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]
% --------------------------------------------------------------------
% 

-- 
--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).

---

From: Alain Durand <[email-masked]>
Date: Wed, 05 Mar 2003 10:29:48 -0800

> so I don't think another BOF will be very productive.

Bill,

Note that I'm not suggesting a bof on DNS discovery mechanism per se,
but a bof on generic service discovery using well known, voluntarily 
ambiguous
addresses.

	- Alain.

---

From: Pekka Savola <[email-masked]>
Date: Thu, 6 Mar 2003 16:46:14 +0200 (EET)

> so I don't think another BOF will be very productive.

I assume those BOFs were for IPv4?

When considering DNS discovery in IPv6 context, we need to consider the 
scope of such discovery -- ie. where it is expected to be used, and 
possible subsequent configuration methods.

As I see it, DNS discovery can either be:

 1) "all that you need"
 2) "the first step"

In the first model, you need no other information.  When you've completed 
DNS discovery, that's it.  This is a very valid scenario in e.g. mobile 
environments, when visiting networks (for example, at IETF's, I run dhcpv4 
*only* to get the DNS address :-( ).

In the second model, you generally want to obtain also other information.  
This typically applies to non-visiting networks, like an enterprise LAN.
The question becomes which tool is used (or fits best) in getting that 
information.  If you need/want to use DHCPv6 (stateful or stateless) for 
that, no use having a separate mechanism for DNS and the rest.

The critical thing in the 2nd model is whether DNS resolvers enable some 
config mechanisms: they certainly enable being able to surf to the home 
page of your own (or enterprise) from where you can obtain some values, 
scripts which give you the configuration you want etc.  But perhaps more 
importantly, you could place configuration details in the DNS, in some 
format.

So, basically if one believes roaming users or DNS-based configuration 
would be nice, some easy DNS resolver configuration mechanism would be 
"very nice".

---

From: Pekka Savola <[email-masked]>
Date: Thu, 6 Mar 2003 17:17:26 +0200 (EET)

On Thu, 6 Mar 2003, Bill Manning wrote:
> % On Wed, 5 Mar 2003, Bill Manning wrote:
> % > As a co-author of a couple of previous DNS discovery IDs, I would
> % > have to agree that as postulated, the current DNS discovery work
> % > has pretty much been OBE. (overtaken by events)
> % > There have been two distinct BOFs on this idea in the last five years
> % > so I don't think another BOF will be very productive.
> % 
> % I assume those BOFs were for IPv4?
> 
> 	No, they were for DNS discovery. Protocol agnostic.

That avoids the question (which I hoped was clear, but perhaps not).

If you have to run DHCPv4 in any case to get an IPv4 address to be able to
use the net, I'm certain nothing could come of such a BOF.
 
> 
> % As I see it, DNS discovery can either be:
> % 
> %  1) "all that you need"
> %  2) "the first step"
> 
> 	Both points were covered each time. And each time, the result
> 	was that DNS discovery should be limited to point #1.

Good.

> 	Point #2 is covered under the DHCP work and should not
> 	be replicated.  

Ok, but one argument is that DHCP is too address-assignment -specific.

---

From: Bill Manning <[email-masked]>
Date: Thu, 6 Mar 2003 07:11:36 -0800 (PST)

--bill

---

From: Tim Chown <[email-masked]>
Date: Sat, 8 Mar 2003 16:40:11 +0000

> would be nice, some easy DNS resolver configuration mechanism would be 

What happened to the RA-piggyback mechanism?

Tim

---

From: Pekka Savola <[email-masked]>
Date: Sat, 8 Mar 2003 18:45:15 +0200 (EET)

> What happened to the RA-piggyback mechanism?

No comments from the w.g. except by me and the author.

RA-piggybacking has a few different nuances, and I'm not sure if I think
the one proposed is necessarily the best one, but it's the one group of
solutions I'd probably follow up if I wanted to achieve something.

---

From: Tim Chown <[email-masked]>
Date: Sat, 8 Mar 2003 17:08:12 +0000

> solutions I'd probably follow up if I wanted to achieve something.

I'd like to see it kept on the table.  I appreciate it has security issues,
but then all the tabled methods do too?

Tim

---

From: Pekka Savola <[email-masked]>
Date: Tue, 11 Mar 2003 16:39:22 +0200 (EET)

> but then all the tabled methods do too?

Actually, the security properties of RA-piggybacking solutions are roughly 
on the same level as with DHCP and friends, not to mention general 
connectivity.

The only attack model with RA-piggybacking that might make sense is to 
inject a spoofed RA containing your rogue DNS servers instead of hijacking 
all the connectivity.  This might be more difficult to notice than all net 
access being man-in-the-middle -attacked on the link by a node.

But then again, the above case hasn't been mentioned in any analysis I
recall (just made it up), so it's difficult to say.  I certainly don't
feel there are a lot of issues with security in RA-based DNS discovery.

---

From: Brian Haberman <[email-masked]>
Date: Tue, 11 Mar 2003 09:51:46 -0500

> feel there are a lot of issues with security in RA-based DNS discovery.

I believe section 6.2.7 of RFC 2461 will help catch this kind of attack.
If the routers on the link validate the parameters being sent by other
routers in their RA's, the spoofed RA should be detected.

Brian

---

From: Tim Chown <[email-masked]>
Date: Tue, 11 Mar 2003 14:43:19 +0000

> feel there are a lot of issues with security in RA-based DNS discovery.

OK, so do you think it;s worth getting it tabled (late) in dnsext in San 
Francisco (given they have no public agenda yet?)

Tim

---

From: Pekka Savola <[email-masked]>
Date: Wed, 12 Mar 2003 09:00:31 +0200 (EET)

> Francisco (given they have no public agenda yet?)

Sure, why not?