Subject: draft vienna minutes (sorry about the delay)

From: David Meyer <[email-masked]>
Date: Thu, 25 Sep 2003 09:39:24 -0700

*************************************************************************
*** DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT ***
*************************************************************************

		      MINUTES FROM THE DNSOP WG
		      57th IETF, Vienna, Austria

Date:		Monday, July 14, 2003 15:30-17:30 (Hall NO)
Chairs:		David Meyer <[email-masked]>
		Rob Austein <[email-masked]>
Minutes by:	Lars-Johan Liman <[email-masked]>
Version:	$Id: minutes-vienna,v 1.3 2003/07/15 10:19:47 liman Exp $

#----------------------------------------------------------------------
# DRAFT AGENDA

Agenda Bashing                                                   5 minutes
Meyer/all

Status of outstanding drafts                                    10 minutes
Meyer/Austein

(i).    Farewell to drafts this WG doesn't need to think about anymore
        draft-ietf-dnsop-hardie-shared-root-server-07.txt
        draft-ietf-dnsop-v6-name-space-fragmentation-02.txt
        draft-ihren-dnsop-interim-signed-root-02.txt
        draft-ihren-dnsop-v6-name-space-fragment-01.txt

(ii).   WG drafts which are ready for last call
        draft-ietf-dnsop-ipv6-transport-guidelines-00.txt
        draft-ietf-dnsop-serverid-01.txt (?)

(iii).  Active WG drafts
        draft-ietf-dnsop-bad-dns-res-01.txt
        draft-ietf-dnsop-inaddr-required-04.txt
        draft-ietf-dnsop-interim-signed-root-01.txt
        draft-ietf-dnsop-ipv6-dns-issues-02.txt
        draft-ietf-dnsop-ohta-shared-root-server-02.txt
        draft-ietf-dnsop-respsize-00.txt
        draft-ietf-dnsop-serverid-01.txt [unless handled in (ii). above]

(iv).   Expired WG drafts
        draft-ietf-dnsop-dontpublish-unreachable-03.txt
        draft-ietf-dnsop-keyhand-04.txt
        draft-ietf-dnsop-resolver-rollover-00.txt
        draft-ietf-dnsop-rollover-01.txt

(v).    Active individual drafts
        draft-durand-dnsop-dynreverse-00.txt
        draft-hall-dns-data-03.txt
        draft-jeong-ipv6-ra-dns-autoconf-00.txt
        draft-kato-dnsop-local-zones-00.txt
        draft-morishita-dnsop-misbehavior-against-aaaa-00.txt
        draft-park-ipv6-extensions-dns-pnp-00.txt
        draft-warnicke-network-dns-resolution-02.txt
        draft-yasuhiro-dnsop-increasing-dns-server-00.txt

IPv6 DNS Discovery -- Framing the discussion                    15 minutes
Rob Austein 

  IPv6 DNS Discovery, and why it is important                   10 minutes
  Bob Hinden

  IPv6 Router Advertisement based DNS Autoconfiguration         10 minutes
  draft-jeong-ipv6-ra-dns-autoconf-00.txt
  Jaehoon Jeong

  IPv6 Router Advertisement DNS resolver Option                 10 minutes
  draft-beloeil-ipv6-dns-resolver-option-01.txt
  Luc Beloeil

  Discussion                                                    20 minutes

A Suggested Scheme for DNS Resolution of Networks and Gateways  10 minutes
draft-warnicke-network-dns-resolution-02.txt
Edward Warnicke

Considerations for DNS Resource Records                         10 minutes
draft-hall-dns-data-03.txt
Eric Hall

IPv6 Extensions for DNS Plug and Play                           10 minutes
draft-park-ipv6-extensions-dns-pnp-00.txt
Syam Madanapalli

Outstanding issues in draft-ietf-dnsop-ipv6-dns-issues-02.txt   10 minutes
Alain Durand

#----------------------------------------------------------------------
# MINUTES

** AGENDA BASHING **

The agenda was adjusted slightly, by adding short time slots to give
room for Daniel Karrenberg to bring up issues with the .LOCAL top
level domain and its impact on the root name servers, and for 
Ralph Droms to make a presentation about DHCP.

** STATUS OF OUTSTANDING DRAFTS **

(i).    Farewell to drafts this WG doesn't need to think about anymore
        draft-ietf-dnsop-hardie-shared-root-server-07.txt
        draft-ietf-dnsop-v6-name-space-fragmentation-02.txt
	draft-ihren-dnsop-interim-signed-root-02.txt
        draft-ihren-dnsop-v6-name-space-fragment-01.txt

The above drafts were pronounced dead and taken off the agenda of the
working group.

(ii).   WG drafts which are ready for last call
        draft-ietf-dnsop-ipv6-transport-guidelines-00.txt
        draft-ietf-dnsop-serverid-01.txt (?)

No new issues were presented. The chairs will take the drafts to WG
last call.

(iii).  Active WG drafts
        draft-ietf-dnsop-bad-dns-res-01.txt
        draft-ietf-dnsop-inaddr-required-04.txt
        draft-ietf-dnsop-interim-signed-root-01.txt
        draft-ietf-dnsop-ipv6-dns-issues-02.txt
        draft-ietf-dnsop-ohta-shared-root-server-02.txt
        draft-ietf-dnsop-respsize-00.txt
        draft-ietf-dnsop-serverid-01.txt [unless handled in (ii). above]

There was no discussion during the session. These drafts are Still
active.

(iv).   Expired WG drafts
        draft-ietf-dnsop-dontpublish-unreachable-03.txt
        draft-ietf-dnsop-keyhand-04.txt
        draft-ietf-dnsop-resolver-rollover-00.txt
        draft-ietf-dnsop-rollover-01.txt

No one spoke in favour of revival of any of these. The chairs'
approach is to let them die.

(v).    Active individual drafts
        draft-durand-dnsop-dynreverse-00.txt
        draft-jeong-ipv6-ra-dns-autoconf-00.txt
        draft-kato-dnsop-local-zones-00.txt
        draft-morishita-dnsop-misbehavior-against-aaaa-00.txt
        draft-park-ipv6-extensions-dns-pnp-00.txt
        draft-yasuhiro-dnsop-increasing-dns-server-00.txt

The above drafts were deemed still active, but will remain individual
drafts for the time being.

>         draft-hall-dns-data-03.txt
>         draft-warnicke-network-dns-resolution-02.txt

The above drafts were decided to be under serious consideration to
become WG documents.

** IPV6 DNS DISCOVERY -- FRAMING THE DISCUSSION **

Rob Austein made a presentation to try to set the framework for the
discussion. The presentation is found in the meeting archives.

Rob tried to clarify and enumerate the underlying generic problems
faced by a DNS consumer node.

See presentation for details.

Ralph Droms commented that the trust model has changed between IPv4
and IPv6: the IPv4 address is obviously owned by DHCP server, but in
an IPv6 auto-configure scenario the "host" part of the address is "owned"
by the host, and the "prefix" part is "owned" by the upstream router.

** IPV6 DNS DISCOVERY, AND WHY IT IS IMPORTANT **

Bob Hinden made a presentation trying to convey the message about why
DNS discovery is important. The presentation is found in the meeting
archives.

Bob went through the different steps in a DNS consumer's life,
identifying a number of steps where DNS discovery is necessary, and
identifying a couple of different methods to achieve it.

See presentation for details.

There was a note from audience that there is an auto-registration draft
also in the DNSEXT WG.

Ted Lemon also commented that the presentation seemed to conveyed the
message that overloading service location on names or addresses is a
positive thing, which he disagreed with. He was seconded by several
others.

** IPV6 ROUTER ADVERTISEMENT DNS RESOLVER OPTION **

Luc Beloeil made a very fast presentation about the IPv6 router
advertisement DNS resolver option. The presentation is found in the
meeting archives.

See presentation for details.

There was a comment from the audience that DHCP service often is found
in the upstream router anyhow, so why not use it?

** IPV6 EXTENSIONS FOR DNS PLUG AND PLAY **

Syam Madanapalli made a presentation regarding IPv6 Extensions for DNS
Plug and Play. His proposal, called 6DNAC has three steps:

- domain name generation
- duplicate domain name detection
- domain name registration

that were animated in the presentation.

** CONFIGURING DEVICES FOR DNS **

Ralph Droms make a presentation about configuring devices for DNS .

The presentation is found in the
meeting archives.

See presentation for details.

** DISCUSSION **

Alain Durand: Please clarify: What happens if you have DHCPv6 and RA
  at the same time on same segment? Does this work?

Ralph Droms: No, I haven't tried. Have to think bout it.

Alain: Will it create a problem?

Ralph: If network administrators do the the right thing - no. If not,
  it might. It may cause unpredictable behaviour.

Pekka Savola: What are the processes to move forward from here? We
  should first think carefully about in which direction we want to go,
  and then set up design team.

Bob Hinden: I want to defend my presentation: the name resolution
  method using names like ftp... and www... was not intended to be
  the perfect solution to service location problem.

Dave Meyer: I still haven't heard why DHCP is NOT the solution to
  this.

Olafur Gudmundson: Ditto. Use DHCP! It's small and it's easy. Get over
  it!

Matt Ford(?): Please no design team. We need this now, and a design
  team will take too long.

<Unknown>: The method depends on type of network infrastructure. There
could be ways to do this using PPP options.

Rob Austein: I hear different signals from the PPP group.

<First name> Thomas: Non-DHCP stuff can be used for ad-hoc networks.

<Unknown>: In what way are the proposed options different from DynDNS?

Rob: They create names out of blue to have some thing to register.

Alain: The unsolicited RA message is one-to-many. One message reaches
  all clients on the segment. The DHCP proposals lead to bilateral
  exchanges that involve at least two-packets per client.

Rob: The security is still an issue. End client needs to verify
  signatures, so it needs NTP.

Randy Bush, AD hat on: Please hum: DHCP vs. auto-discovery.

Dave: not conclusive.

Rob: DHCP attractive: client just sends, and just receives.

Ted Lemon: Someone mentioned reliability issues in DHCP, but that
  doesn't apply to stateless DHCP in IPv6, since that is a different
  animal. Don't compare the two.

Ralph Droms: DHCP "light" is not different from DHCP, it is a subset
  thereof.

Dave: We have two classes of proposals: DHCP vs. discovery.

Ted: You have to have a DHCP client anyhow on the client side. Why not
  use it for DNS discovery.

Ralph: I don't think the O bit=0 means *DON'T* do DHCP.

Dave: We will take the discussion to the list.

** A SUGGESTED SCHEME FOR DNS RESOLUTION OF NETWORKS AND GATEWAYS **

The author was not present. This agenda item was skipped.

** CONSIDERATIONS FOR DNS RESOURCE RECORDS **

The author was not present. This agenda item was skipped.

** Problems with the .LOCAL TLD **

Daniel Karrenberg

The root server operators have been observing large quantities of
queries for names in the .LOCAL and .LOCALHOST top level domains. At
certain points in time and topology up to 1/3 of the query load. If
anything else thatn root name servers were hit by this type of data
stream, it would be called a DOS attack. :-) What can we do about
this? For now: just answer. In the future we might want not to answer,
but that is a decision that cannot be taken by the root name server
operators. An alternative is to delegate them to query sinks (... and
eventually to get the clients fixed).

Akira Kato has written a draft that addresses these issues. Daniel
asked the chairs 1) what the status of the draft is, and 2) how to
proceed.

Rob: Kato's draft was presented in San Francisco (56th IETF), but at
  the time it was so new new that not no one had had an informed
  opinion. Nothing has happened since. Also: it might create a dangerous
  precedence.

  Please hum: WG item (intending a BCP) or not? Result: WG item!

** OUTSTANDING ISSUES IN draft-ietf-dnsop-ipv6-dns-issues-02.txt **

Alain Durand talked briefly about outstanding issues in
draft-ietf-dnsop-ipv6-dns-issues-02.txt. It's almost ready for last
call. Remaining issues: what do about reverse domain space, especially
prepopulation? Another revision with focus on reverse prepopulation is
planned.

** DS UPDATE IN PARENT **

Mohsen Souissi 

DNSSEC is getting more and more operational. Test beds in different
places. What about update DS in parent? We need operational
requirements before working.

Randy, AD hat on: This is one of the main focuses of the group! If not
  interested there will be consequences ... ;-) Degenerate case:
  root key management.

It was found to be a suitable WG item. :-)

The meeting was closed.
#----------------------------------------------------------------------
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: Tim Chown <[email-masked]>
Date: Thu, 25 Sep 2003 18:17:35 +0100

So this is a reasnoably fair reflection of the lack of concensus on RA vs
DHCP for DNS resolver discovery in Vienna.   Some comments are missing
though, like Alain's "large network resetting" issue, and of course the
"Why have DHCP?" responses to "Why not use DHCP?" :)

How is the impasse to be resolved?   Pekka suggested a design team, which
was not taken forward as it would be a potentially slow process, yet I'm
not sure anything has changed since July anyway?

There were some fringe proposals after Vienna, e.g. for multicast responses
to DHCP requests.   Perhaps the lack of a detailed RA-based proposal will
cause DHCP to be used "by default".   

There is still work either way in how the DHCPv6 (Lite) settings are 
propogated to the router, or how DHCPv6 forwarding accurs where DHCPv6
requests are sourced on a subnet with no server.

Thoughts?

Tim

---

From: John Schnizlein <[email-masked]>
Date: Thu, 25 Sep 2003 13:53:18 -0400

At 01:17 PM 9/25/2003, Tim Chown wrote:
Re: draft vienna minutes (sorry about the delay)
>DHCP for DNS resolver discovery in Vienna.   

My impression is different: The rough consensus is to just use DHCPv6 
as the protocol - either the "light" stateless subset in the router,
or the statefull server. There seems to be a small but vocal set of
people who want to invent something new rather than use the v6 variant
of the dynamic host configuration protocol that is known to work.

John

---

From: Miek Gieben <[email-masked]>
Date: Thu, 25 Sep 2003 23:58:42 +0200

[On 25 Sep, @19:53, John wrote in "How IPv6 host gets DNS address ..."]
> of the dynamic host configuration protocol that is known to work.

This was also my impression,

grtz  Miek

---

From: Pekka Savola <[email-masked]>
Date: Fri, 26 Sep 2003 07:34:54 +0300 (EEST)

> of the dynamic host configuration protocol that is known to work.

Well, as it is, it is up to the chairs (by RFC2418) to decide what the
consensus is.  

Currently, at least, I don't agree with this characterization of rough 
consensus.

-- 
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: Soohong Daniel Park <[email-masked]>
Date: Fri, 26 Sep 2003 14:45:42 +0900

> of the dynamic host configuration protocol that is known to work.

Just impression not consensus...

Daniel

---

From: Ralph Droms <[email-masked]>
Date: Fri, 26 Sep 2003 06:41:25 -0400

Tim, what do you mean by "work either way"?  There's no additional
configuration work required for DHCPv6 - any protocol, whether it's RAs or
DHCPv6 or ???, that passes the addresses of DNS servers to hosts must be
configured with those addresses.  If the DHCPv6 server is in a router, it
can be configured along with all of the other router configuration
parameters, which is how we configure the DHCPv6 server in IOS.

There's no protocol development work required for DHCPv6 forwarding.
RFC3315 defines how DHCPv6 messages are forwarded by DHCPv6 relay agents.

- Ralph

At 06:17 PM 9/25/2003 +0100, Tim Chown wrote:
>[...]

---

From: Ralph Droms <[email-masked]>
Date: Fri, 26 Sep 2003 06:54:33 -0400

I would agree with "reasonably fair" - in a little more detail, I
heard a louder hum for DHCPv6 but not rough consensus.  I think the
minutes might provide a little more detail about my presentation (for those
who don't go look up the presentation); perhaps "configuring devices for DNS
using DHCPv6"?  Finally, for those who weren't present, I think the minutes
should note that DHCPv6 has been accepted as a Proposed Standard and is
published as RFC 3315 (I believe this was the case as of the Vienna
meeting), so we're comparing the use of a published standard against the
development and future publication of a new protocol.

According to the minutes, the first step was to be a continuation of the
discussion on the mailing list.  Perhaps the chairs could frame and kick off
that discussion before we go to a design team?

- Ralph

---

From: Bob Hinden <[email-masked]>
Date: Fri, 26 Sep 2003 10:29:40 -0700

Pekka,

>Currently, at least, I don't agree with this characterization of rough

Likewise.

Bob

---

From: Bob Hinden <[email-masked]>
Date: Fri, 26 Sep 2003 11:00:47 -0700

Hi Ralph,

>development and future publication of a new protocol.

If I remember correctly you said that the RFC was in authors 48hours review 
at the time and wasn't quite published by the meeting.  :-)  It certainly 
is published now!

I am in agreement except for the point about the development of a new 
protocol.  One of the current alternate proposals is for a new option for 
Router Advertisements so no new protocol would need to be developed in that 
case.  The well known address approach doesn't require any protocol.  I 
agree that both of these require specifications to be completed, approved, 
and published.

I have been wondering if it would make sense to define a new RA option 
designed to carry DHCPv6 options.  That would make it possible to take 
advantage of DHCPv6 options that would make sense to use in RAs.  I think 
this would be useful for information that would be common to all hosts on 
the link.

The biggest technical difference I see between the DHCPv6 (and DHCPv6 lite) 
and RA approaches is that DHCPv6 is a two packet exchange for each host vs. 
the RA approach where a RA message can be multicast to all hosts on the link.

>that discussion before we go to a design team?

Good point.

Bob

---

From: Ralph Droms <[email-masked]>
Date: Fri, 26 Sep 2003 16:04:12 -0400

Bob - you have a better memory than I do.  Looks like the official
publication date for RFC 3315 was about 7/30...

- Ralph

At 11:00 AM 9/26/2003 -0700, Bob Hinden wrote:
>Hi Ralph,
>
>>[...]
>
>If I remember correctly you said that the RFC was in authors 48hours 
>review at the time and wasn't quite published by the meeting.  :-)  It 
>certainly is published now!

---

From: Soohong Daniel Park <[email-masked]>
Date: Sat, 27 Sep 2003 11:20:54 +0900

> the RA approach where a RA message can be multicast to all 

In addition, mobile node (especially WLAN) prefer RA option to DHCP 
from ISP experiences because of below reasons
1) Delay of DHCP request/reply Relay
2) Risk of centralized DHCP server (fault, failure and etc.)

Daniel

---

From: John Schnizlein <[email-masked]>
Date: Mon, 29 Sep 2003 15:13:40 -0400

Neither of these is a technical reason to prefer RA to DHCPv6.
Specific technical responses to the points raised:

At 10:20 PM 9/26/2003, Soohong Daniel Park wrote:
RE: draft vienna minutes (sorry about the delay)
>> The biggest technical difference I see between the DHCPv6 
>> (and DHCPv6 lite) and RA approaches is that DHCPv6 is a two 
>> packet exchange for each host vs. the RA approach where a RA 
>> message can be multicast to all hosts on the link.

This apparent efficiency - one packet per link rather than 2 per host -
would come at the cost of the hosts waiting until the next scheduled
multicast RA. Where would the two-packet exchange be more detrimental
than a random delay until DNS is available?

>2) Risk of centralized DHCP server (fault, failure and etc.)

In the circumstance in which RA would suffice, there is no need for
a "centralized DHCP server" or the relay agent to get traffic to it.
The same router that provides RA could answer a DHCPv6 information
request with the options relevant to DNS.

John