Subject: proposal for a compromise on DNS discovery

From: Alain Durand <[email-masked]>
Date: Wed, 16 Jul 2003 00:21:14 -0700

I have circulated this among several people yesterday and it may be time
to bring this to the list.

Our community is basically divided in two camps,
the "conservatives", coming from v4 where the operational practice
is to use DHCP for DNS discovery and would like to operate the same way
for v6, and the "liberals", coming from v6 where the autoconfiguration
story is build on Neighbor Discovery and RA/RS, and who would like to
expand on this.

As I explain in an earlier mail, the differences in the mode of 
operation are:
- DHCPv6 can also pass the address of the NTP server
- RA/RS have the unsolicited multicast provision that helps save 
bandwidth
   when a large number of nodes are autoconfiguring at the same time.

The compromise solution I'd like to bring forward is to optionally 
piggy back the
unsolicited multicast mode to DHCPv6-lite.

More specifically, this would work the following way:

At boot time, the client wait a bit (random 0..MAX1 seconds) and listen
to unsolicited DHCPv6 DNS recursive server advertisements sent to the
link-local-all-node multicast address.
If noting comes, it send a DHCPv6 request.
The DHCPv6 server answer to the unicast address of the requester
and, if configured to do so (this would be optional), send the same 
thing to the
link-local-all-node multicast address.
Those multicast responses will be rate limited by the server,
that is, if a second request come within MAX2 seconds,
only the unicast answer will be sent.

I'm sure there would be many details to work out.

	- Alain.

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

---

From: Jaehoon Jeong <[email-masked]>
Date: Wed, 16 Jul 2003 04:36:38 -0700 (PDT)

Thanks for your good proposal.
As I said before, I believe, the RA-based and
DHCP-based DNS discoveries are complementaty each
other. One of them can not be the best. Just like IPv6
address autoconfiguration scenario, the RA-based and
DHCP-based DNS discoveries can be used very well
together. I think most of IPv6 hosts will have DHCPv6
client. Unless DNS information is piggybacked, IPv6
host just conforms to DHCPv6 procedure for DNS
discovery.
The approach of DHCP-lite announcing DNS information
overrides IPv6 RA advertisement. IMHO, it is enough
for one of RA and DHCP to announce IPv6 prefix and DNS
information.

In wireless networks, such as HMIPv6 and NEMO, MAP or
MR announce IPv6 prefix information periodically. If
piggybacking DNS information in RA, there is no need
of additional delay for finding out DNS information.
Your proposal complicates DHCP operation and usage, I
think.
DHCP is not almighty in all environments, and just one
of many solutions.
I am also one of non-english speakers.
Thanks, Alain.

/Jaehoon Paul

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

__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 16 Jul 2003 21:28:45 +0859 ()

Alain;

Before trying to compromise, can you, at least, clarify
your requirement?

> - DHCPv6 can also pass the address of the NTP server

I think NTP configuration is obsoleted.

							Masataka Ohta

---

From: Francis Dupont <[email-masked]>
Date: Wed, 16 Jul 2003 17:00:42 +0200

In your previous mail you wrote:

   Alain;

   
   
=> all the crypto things I know are valid only at limited amount
of time. In fact the military measure of a secret is the duration
one can expect it will remain secret. So as soon as there is
some kind of security involved in the network (and it should be :-),
it is critical to have a good and secure source of the current date.
The protocol which provides this is NTP: it synchronizes all boxes
(i.e., all boxes have the same time) and with a good reference
it can synchronize all boxes to the right time.

Therefore NTP is a part of the initial service discovery stuff (IMHO
this has nothing to do in the dnsop WG as it can't be restricted to
DNS server discovery, but the IPv6 WG already tried to solve the whole
issue and failed...).

Regards

[email-masked]

PS: NTP is very useful for management too, an argument I used many
(~10) years ago when I was at the head of the RIPE DNS TF to
recommend to make all routers (the active equipments at this time)
NTP clients or peers.
PPS: Obviously there is a bootstrap problem with secure NTP.
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 17 Jul 2003 00:57:12 +0859 ()

[email-masked];

> of time.

How many of the crypto things you know can be autoconfigured?

> In fact the military measure of a secret is the duration

So, it should be noted that root keys must also be periodically
configured.

> DNS server discovery, but the IPv6 WG already tried to solve the whole

IPv6 WG has been trying to solve so many non-issues and failing.

							Masataka Ohta

---

From: Francis Dupont <[email-masked]>
Date: Wed, 16 Jul 2003 19:56:01 +0200

=> my answer to the proper question "how many of devices which
can be autoconfigured and don't use any crypto thing I know?"
is none for recent (i.e., in this century) devices.

   
=> do it should be noted than nothing may stay valid forever, even
root keys.

Regards

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 17 Jul 2003 19:14:25 +0859 ()

> is none for recent (i.e., in this century) devices.

Yours is an improper question.

Using autoconfiguration on non crypt things is fine.

However, devices using crypto thing is secure only if they do not use
autoconfiguration of the crypto thing.

Answer the question.

> => do it should be noted than nothing may stay valid forever, even

That's how security needs manual configuration.

							Masataka Ohta

---

From: Francis Dupont <[email-masked]>
Date: Thu, 17 Jul 2003 13:22:04 +0200

=> my argument is that autoconfigurated devices use crypto things,
crypto things need a time service, then the question of autoconfiguration
of time service is sound. I didn't speak about autoconfiguration of
crypto things (i.e., this is a different problem: it should be
discussed in another threat and likely in another list).

   
=> no, my argument is they are not secure if they can't access to a
time service.

Regards

---

From: Mohsen Souissi <[email-masked]>
Date: Thu, 17 Jul 2003 10:01:15 +0200

If this tradeoff proposal can help us move quickly to an operational
solution which maybe quickly implemented and shipped in OS's, I fully
support it.

My concern is that while having this endless religious debate (thanks
Tim for the word), people who want to deploy real and credible IPv6
networks still lack this critical feature (recursive name server
discovery).

Mohsen.

On 16 Jul, Alain Durand wrote:
| I have circulated this among several people yesterday and it may be time
| to bring this to the list.
| 
| Our community is basically divided in two camps,
| the "conservatives", coming from v4 where the operational practice
| is to use DHCP for DNS discovery and would like to operate the same way
| for v6, and the "liberals", coming from v6 where the autoconfiguration
| story is build on Neighbor Discovery and RA/RS, and who would like to
| expand on this.
| 
| As I explain in an earlier mail, the differences in the mode of 
| operation are:
| - DHCPv6 can also pass the address of the NTP server
| - RA/RS have the unsolicited multicast provision that helps save 
| bandwidth
|    when a large number of nodes are autoconfiguring at the same time.
| 
| The compromise solution I'd like to bring forward is to optionally 
| piggy back the
| unsolicited multicast mode to DHCPv6-lite.
| 
| More specifically, this would work the following way:
| 
| At boot time, the client wait a bit (random 0..MAX1 seconds) and listen
| to unsolicited DHCPv6 DNS recursive server advertisements sent to the
| link-local-all-node multicast address.
| If noting comes, it send a DHCPv6 request.
| The DHCPv6 server answer to the unicast address of the requester
| and, if configured to do so (this would be optional), send the same 
| thing to the
| link-local-all-node multicast address.
| Those multicast responses will be rate limited by the server,
| that is, if a second request come within MAX2 seconds,
| only the unicast answer will be sent.
| 
| I'm sure there would be many details to work out.
| 
| 	- Alain.
| 
| #----------------------------------------------------------------------
| # To unsubscribe, send a message to <[email-masked]>.
| 

-- 
Mohsen Souissi

***********************************************************************
* 			AFNIC -  http://www.afnic.fr/                 *
***************************************+*******************************
* 		  mailto:[email-masked]                        *
* Tél. : +33 1 39 30 83 40       |  Fax :    +33 1 39 30 83 01        *
*--------------------------------+------------------------------------*
* Immeuble International - 2, rue Stephenson - Montigny le Bretonneux *
* 78181 Saint Quentin en Yvelines Cedex                               *
***********************************************************************
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 18 Jul 2003 02:13:23 +0859 ()

Francis.Dupont;

> of time service is sound.

Wrong. It is insecure.

							Masataka Ohta