Re: avoiding proxies

Luc;

> > > On the Internet, the mechanism to relay requests to servers over
> > > multiple links is called routing.
> > 
> > Exactly, let's let routing do the job it is supposed to be providing
> > already anyway, rather than layering on even more mandatory services.
> > 
> 
> Ok I may understand what do you wanna say. 
> 1- we could use multicast to transport DNS requests. But multicast is
> not easy to deploy within access networks such as xDSL, RTC... (NBMA
> links)

I hope Eric recognizes that ring search with multicast is an
application layer attempt to poorly imitate a routing protocol.

> 2- we could use anycast
> 
> But it is not clear for me how we could use DNSSEC in such scheme. There
> is still and perhaps a bigger issue there if we need to distribute keys.
> (I do not argue that RA-based solution is better there ;+)

Read the draft on security considerations and never say autoconfigured
security.

							Masataka Ohta
#----------------------------------------------------------------------
# To unsubscribe, send a message to <dnsop-request <at> cafax.se>.

RE: avoiding proxies

Hi Masataka,

> -----Message d'origine-----
> De : Masataka Ohta [mailto:mohta <at> necom830.hpcl.titech.ac.jp]
> Envoye : vendredi 1 aout 2003 05:45
> > 2- we could use anycast
> > 
> > But it is not clear for me how we could use DNSSEC in such 
> scheme. There
> > is still and perhaps a bigger issue there if we need to 
> distribute keys.
> > (I do not argue that RA-based solution is better there ;+)
> 
> Read the draft on security considerations and never say autoconfigured
> security.
> 
> 							Masataka Ohta
> 

I've just read quickly you draft.

First point, 
I'm impressed that you dare say that you ask client to use no security.
(I hope I have missed nothing). Indeed we are not using any security
within current operational and commercial network for home residential
customers, and that works, this is a fact. I do know if we should
impose cryptography in all IP datagrams, but I feel that IETF want to
propose the option if needed.

Second point, 

Re: avoiding proxies

Luc;

> > Read the draft on security considerations and never say autoconfigured
> > security.

> I've just read quickly you draft.

Do read the draft, carefully and thoroughly.

> First point, 
> I'm impressed that you dare say that you ask client to use no security.

NO.

> (I hope I have missed nothing).

You have missed all.

> I do know if we should
> impose cryptography in all IP datagrams, but I feel that IETF want to
> propose the option if needed.

Yup.

> Second point, 
> I guess if Firewall will must be aware of anycast way of working,

No.

> because incoming datagrams may not have a source address = to anycast

Policy of IPv6 DNS Discovery

Re: Policy of IPv6 DNS Discovery

Hi Bill,

My mail is as follows;
Maybe, you can see mine, now.

/Jaehoon Paul

-----------------------------------------------------------------------------------------------
Hello all,

Thanks for your insightful suggestions and comments.
For DNS Discovery, we have been discussing much.
IMHO, every technology has its own application domain.
Until now, several propositions for DNS Discovery have been suggested and discussed.
A unique solution can not cover every environment, I think.
DHCPv6, RA, Anycast and Multicast approaches have their own domain.
If each applicability is reasonable, it is valuable to develop it and adopt it.
As one of RA camp, I think, RA-approach is useful in some of wireless networks,
such as HMIPv6, MANET connected to the Internet and NEMO.
You can refer to each application in the following links;

 - HMIPv6: 
   http://www.ietf.org/internet-drafts/draft-jeong-hmipv6-dns-optimization-01.txt
   http://www.adhoc.6ants.net/~paul/publications/international-conference/vtc2003-fall-jaehoon.pdf

 - MANET and NEMO:
   http://www.adhoc.6ants.net/~paul/publications/international-conference/pimrc2003-jaehoon.pdf

RA-based DNS Discovery is efficient when address autoconfiguration should be
performed through RA, because it needs not additional discovery.
For example, if MAP option and DNS option in an RA message are delivered in HMIPv6,
there is no delay to discover DNS information. This scheme leads to the optimization
of DNS name resolution owing to using the local recursive DNS server within the MAP domain.

In MANET connected to the Internet, the binding of global IPv6 address is needed
to communicate with an Internet node. RA-based approach is suggested as follows;
  http://people.nokia.net/~charliep/txt/aodvid/globalv6.txt

In this case, the address of recursive DNS server is needed for resolving the global DNS 
name. DNS option is also indispensible to this approach.

If we do not adopt RA-based DNS Discovery, there will be limitation in some domains.

Basically, in most of the current  IPv6 LANs, ND-based stateless address autoconfiguration
is used for address autoconfiguration rather than stateful DHCP approach.
In IPv6 stateless autoconfiguration, DNS discovery is a big lack in the basic IPv6 networking service. 
If DNS discovery is provided via RA message, I believe, most of IPv6 LANs will do without DHCPv6.
As you know, in most of IPv4 LANs, through DHCP, we get only IP address and DNS information,
although being able to get other important parameters.
Therefore, if ND provides IPv6 hosts with DNS information as well as IPv6 prefix,
the hosts will nearly have no inconvenience in basic IPv6 networking.
In the environment where there is need to autoconfigure more other parameters, 
such as NTP server and Web-proxy, DHCPv6 can be used well.

IMHO, the development of RA-based DNS Discovery belongs to IPv6 wg, not DNSOP wg,
because it is the extension of IPv6 protocol, not DNS protocol.
However, in my memory, Thomas Narten, Internet Area Director, said that IPv6 DNS Discovery
should be handled in DNSOP wg.
If so, I think, the extension of IPv6 protocol for DNS Discovery can be discussed in DNSOP wg.

In conclusion, I am sure, IPv6 protocol itself needs ND-based DNS autoconfiguration.
Let the autoconfiguration of other parameters except DNS information processed by DHCPv6. 

It seems be time for related ADs and Chairs to negotiate and decide the policy for DNS discovery.
After that, we engineers will be able to develop more practical solution mechanisms according to the direction.

Thanks.

/Jaehoon Paul

------------------------------------------------------------------------------------------------

----- Original Message ----- 
From: "Bill Manning" <bmanning <at> ISI.EDU>
To: "Jaehoon Paul Jeong" <paul <at> etri.re.kr>
Cc: "Bill Manning" <bmanning <at> ISI.EDU>
Sent: Saturday, August 02, 2003 1:05 PM
Subject: Re: Policy of IPv6 DNS Discovery

> 
> [Charset Windows-1252 unsupported, skipping...]
> 
> I think you were trying to say something, but it renders
> as a non-supported character set.  Sorry about that.
> 
> 
> --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 <at> cafax.se>.

Re: Policy of IPv6 DNS Discovery

% Hi Bill,
% 
% My mail is as follows;
% Maybe, you can see mine, now.
% 
% /Jaehoon Paul
% 
% -----------------------------------------------------------------------------------------------
% Hello all,
% 
% Thanks for your insightful suggestions and comments.
% For DNS Discovery, we have been discussing much.
% IMHO, every technology has its own application domain.

	In the case of Internet, I beg to differ.

% Until now, several propositions for DNS Discovery have been suggested and discussed.
% A unique solution can not cover every environment, I think.
% DHCPv6, RA, Anycast and Multicast approaches have their own domain.

	DNS, as a unique solution, covers all the environments
	you have currently specified, so perhaps more thought it 
	needed.  In any case...
	If you take this approach, you must also indicate which
	method takes priority when "domains" overlap.
	This also means you must define all possible domains.
	DHCPv4, DHCPv6, RA, Anycast, Multicast, LLMNR, TBDS,...
	how many are there?

% In conclusion, I am sure, IPv6 protocol itself needs ND-based DNS autoconfiguration.
% Let the autoconfiguration of other parameters except DNS information processed by DHCPv6. 

	It remains unclear to me how ND-based DNS autoconfiguration
	will be able decern the DNS admins policy profile and use
	ND-based DNS autoconfiguration accordingly.

% /Jaehoon Paul
% 
% ----- Original Message ----- 
% From: "Bill Manning" <bmanning <at> ISI.EDU>
% To: "Jaehoon Paul Jeong" <paul <at> etri.re.kr>
% Cc: "Bill Manning" <bmanning <at> ISI.EDU>
% Sent: Saturday, August 02, 2003 1:05 PM
% Subject: Re: Policy of IPv6 DNS Discovery
% 
% 
% > 
% > [Charset Windows-1252 unsupported, skipping...]
% > 
% > I think you were trying to say something, but it renders
% > as a non-supported character set.  Sorry about that.
% > 
% > --bill

--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 <at> cafax.se>.

Re: Policy of IPv6 DNS Discovery

At Sat, 2 Aug 2003 10:32:42 +0900, Jaehoon Jeong wrote:
> 
> A unique solution can not cover every environment, I think.

Sorry, but that turns out not to be the case.  It's fairly obvious to
anyone who has taken the trouble to understand how DHCP works that
DHCPv6-lite would work in pretty much every environment we've been
discussing.  Apparently some people just don't like DHCP.

> It seems be time for related ADs and Chairs to negotiate and decide
> the policy for DNS discovery.  After that, we engineers will be able
> to develop more practical solution mechanisms according to the
> direction.

I'm not sure why you insist on a public repetition of an exchange that
you and I already had when you pestered me about this in private, but
whatever.

The reason why this topic was moved from the IPv6 WG to the DNSOP WG
was to force a real discussion of requirements before proposing
solutions.  In particular, we're required to answer the question which
the IPv6 WG declined to ask: given DHCPv6 (including DHCPv6-lite),
what real need is there for further work in this space?  This
discussion is finally taking place on the DNSOP mailing list, albiet
in fits and starts.  Discussion of new protocol extensions (such as
your draft) will be in scope (for some WG, probably not DNSOP) if and
only if this discussion concludes that there's a gap between real
requirements and existing protocols.
#----------------------------------------------------------------------
# To unsubscribe, send a message to <dnsop-request <at> cafax.se>.

Re: Policy of IPv6 DNS Discovery

Rob,

>The reason why this topic was moved from the IPv6 WG to the DNSOP WG
>was to force a real discussion of requirements before proposing
>solutions.  In particular, we're required to answer the question which
>the IPv6 WG declined to ask: given DHCPv6 (including DHCPv6-lite),
>what real need is there for further work in this space?  This

I think the IPv6 w.g. did answer this question several times.  It concluded 
that it did want a solution in addition to DCHPv6.  For example from the 
minutes of the Salt Lake City IETF in December 2001:

    Deering took poll of room: How many people think w.g. should continue
    work on stateless DNS discovery? Consensus to continue work.

and again in the minutes of the Yokohama Japan Thursday, July 2002:

    Wasserman took poll for choices listed. Results were:

    1) Continue w/ existing proposal, Proposed Standard or Experimental:

    Consensus to standardize short term solution
    Consensus to continue work on current proposal.

    2) Accept DHCP in addition to current work

    Consensus to continue working on DHCPv6

    3) Requirements: Important to further develop requirements?

    Small consensus to not work on requirements

    4) Consider new short term solution:

    N/A

Also, a specific solution draft was accepted as a working group item.

This work was later removed from the IPv6 w.g. charter by the IESG and 
moved to this working group.

I would also note that at the Vienna meeting, a "hum" was taken in the 
DNSOP group and there was not a consensus that there should only be a 
DHCPv6 solution to this problem.

I conclude from this that there is a significant number of people who think 
that a solution is needed in addition to DHCPv6.

Regards,
Bob

#----------------------------------------------------------------------
# To unsubscribe, send a message to <dnsop-request <at> cafax.se>.

Re: Policy of IPv6 DNS Discovery

At Sat, 02 Aug 2003 12:00:13 -0700, Bob Hinden wrote:
> 
> I think the IPv6 w.g. did answer this question several times.  It concluded 
> that it did want a solution in addition to DCHPv6.  For example from the 
> minutes of the Salt Lake City IETF in December 2001:
> 
>     Deering took poll of room: How many people think w.g. should continue
>     work on stateless DNS discovery? Consensus to continue work.

And there's at least part of the problem.  "Stateless DNS discovery"
is not the same thing as "a solution in addition to DHCPv6" unless
"stateless" is just a euphemism for "anything but DHCP".  DHCPv6-lite
is also "stateless" for every definition of "stateless" that applies
to, eg, the RA-based proposals.  This confusion persisted through the
entire discussion in the IPv6 WG, and at least some of the arguments
in favor of RA-based or ND-based solutions on this list still appear
to originate in this confusion.

> and again in the minutes of the Yokohama Japan Thursday, July 2002:

Same problem.

> I would also note that at the Vienna meeting, a "hum" was taken in the 
> DNSOP group and there was not a consensus that there should only be a 
> DHCPv6 solution to this problem.

Correct.  Please see the message to which I was responding, which
called for an immediate decision in favor of a non-DHCP-based
solution.  I do not think that the discussion is over yet, which is
why I do not think an immediate decision is appropriate.

> I conclude from this that there is a significant number of people
> who think that a solution is needed in addition to DHCPv6.

And a significant number of people are still waiting to hear reasons
more substantial than "I don't like DHCP" (or, even worse, "I don't
understand DHCP but I know that I don't like it").

If there are serious -technical- reasons for why DHCP-lite is a bad
solution, fine, put 'em on the table.

Real issues I've heard so far:

1) Pekka points out that the DHCPv6 spec is a pretty big chunk of text
   for an implementor to have to read just to do a little discovery
   frob.  The DHC WG is already aware of this problem and is already
   working on a doc to help: see draft-ietf-dhc-dhcpv6-stateless-00.
   So I think this issue is under control.

2) Alain points out that having every node in a building poll at once
   when the building's power comes on can ruin one's afternoon.   I'm
   not as concerned about this as Alain is, but Alain has already come
   up with a proposal for an optional extension that will address his
   concern.  So I think that this issue is also under control.

3) Ohta-san has resurfaced the well-known-anycast hack.  Issues with
   this are already on record in the IPv6 WG list archives, so I won't
   restate them here, but I will note that sites which chose to do
   this with unicast addresses out of their own address space (as
   opposed to well-known unicast or anycast addresses) are already
   free to do so, and, indeed, I've been told that many ISPs already
   do this for v4 -- pretty much by definition, nobody but the ops
   staff at those ISPs would know.  At a high level, though, the key
   point here is that this is not new technology, and sites which
   chose to use it can do so already without further protocol work.

Other than the above, what I've heard has been the same tired refrain
of "stateful address assignment is optional in IPv6, therefore we need
a DNS discovery solution which doesn't use DHCP", which just tells me
that the people singing this song still don't understand how the DHCP
Information-Request mechanism works.  See (1), above.

In summary, while it's possible that there's a credible case to be
made for why further protocol work is needed, I haven't seen it yet.
#----------------------------------------------------------------------
# To unsubscribe, send a message to <dnsop-request <at> cafax.se>.

Re: Policy of IPv6 DNS Discovery

on 8/2/2003 3:52 PM Rob Austein wrote:

> Real issues I've heard so far:
> 
> 1) Pekka points out that the DHCPv6 spec is a pretty big chunk of text

> 2) Alain points out that having every node in a building poll at once

> 3) Ohta-san has resurfaced the well-known-anycast hack.  Issues with

> Other than the above, what I've heard has been the same tired refrain
> of "stateful address assignment is optional in IPv6, therefore we need

I don't know if you're bundling my complaint in the latter camp or not,
but if so that's an incorrect interpretation. My complaint is that the
mandatory requirement introduces unnecessary complexity to the default
scenario by interfering with the application-layer DNS service, imposes
non-intuitive management cycles onto the service ("oh yeah, my resolver
gets its config from this extraneous service that I forgot about because
I'm not using it for anything else"), and is wholly unnecessary when the
service is capable of handling it internally.

Separately, use of in-band dynamic discovery via multicast also allows
SRV-based discovery mechanisms to bootstrap further. Those systems also
operate outside of or run in parallel with DHCP.

FWIW, I run DHCP here and I would almost certainly use it for this too,
although my network is much better managed than most of the networks out
there today.

--

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

#----------------------------------------------------------------------
# To unsubscribe, send a message to <dnsop-request <at> cafax.se>.