Subject: Policy of IPv6 DNS Discovery

From: "Jaehoon Paul Jeong" <[email-masked]>
Date: Sat, 2 Aug 2003 10:32:42 +0900

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 its 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

---

From: Rob Austein <[email-masked]>
Date: Sat, 02 Aug 2003 13:11:28 -0400

> 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 <[email-masked]>.

---

From: Bob Hinden <[email-masked]>
Date: Sat, 02 Aug 2003 12:00:13 -0700

Rob,

>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

---

From: Rob Austein <[email-masked]>
Date: Sat, 02 Aug 2003 16:52:34 -0400

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

> 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 <[email-masked]>.

---

From: "Eric A. Hall" <[email-masked]>
Date: Sat, 02 Aug 2003 16:24:00 -0500

> 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/

---

From: Rob Austein <[email-masked]>
Date: Sat, 02 Aug 2003 18:11:26 -0400

> operate outside of or run in parallel with DHCP.

No, sorry, I forgot about yours, and you're correct that it doesn't
quite fit into any of the pigeon holes in my previous message.

If I understand it correctly, the simple version of what you propose
(just using multicast to find recursive name servers, nothing else)
substitutes one multicast-based discovery protocol for another
multicast-based discovery protocol.  Since it's quite possible to
co-locate a DHCP-lite "server" inside the same "process" (or whatever
fate sharing unit a server host uses) as the recursive name server,
the fate sharing comparision comes out as a wash when one looks at it
closely.  So one's left arguing about relatively trivial engineering
details like packet formats and port numbers.

The SRV based stuff is a different ball of wax: in that one, you're
reinventing SLP instead of reinventing DHCP :).  While one could
certainly have a fun discussion along those lines, the ZEROCONF and
DNSEXT WGs have already spent a lot of time down the LLMNR rabbit
hole, and I'm reluctant to follow them down there.

In any case, either version of what you're talking about still looks
to me like a proposal for new protocol work.  We're still trying to
determine whether -any- new protocol work is needed, so this, like the
RA-based and ND-based proposals, isn't really in scope at the moment.
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: "Eric A. Hall" <[email-masked]>
Date: Sat, 02 Aug 2003 18:38:50 -0500

> details like packet formats and port numbers.

There's also the operational overhead differences. You'll still have to
manage static pre-configured lists of servers, for example, while there
wouldn't be any such lists with the multicast DNS 'CONFIG' model. Since
any server that responded to the request would be a candidate, managing
the list would essentially boil down to adding and deleting servers (or
enabling and disabling recursion on those servers), and the new list of
servers would self-identifies on the next query seamlessly.

Granted, there would be some administration in terms of ensuring that
multicast filters were working properly, but this is less than the
requirements for DHCP.

> reinventing SLP instead of reinventing DHCP :). 

I wasn't advocating any additional work for SRV. I was making the point
that SRV-based configurations only requires a working resolver, and that
the multicast CONFIG approach gets that minimal level of service working
*from inside DNS* as well. So again, for those services which use SRV,
using a DNS-based configuration service makes it simpler since everything
~needed would be in the resolver code, with no external services needed.

> to me like a proposal for new protocol work.

A new DNS opcode and some behavioral rules.

> We're still trying to

---

From: Rob Austein <[email-masked]>
Date: Sat, 02 Aug 2003 20:06:19 -0400

> servers would self-identifies on the next query seamlessly.

Nope.  A minimal DHCPv6-lite server co-located with a recursive name
server would just respond with its own address.  This is no more (and
no less) static configuration than in your model.

> multicast filters were working properly, but this is less than the

Nope.  It's exactly the same as with DHCP, just on a different port
number.  The only real difference is that with DHCP one also has the
alternative of using DHCP relays if site multicast isn't practical.
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: Bill Manning <[email-masked]>
Date: Sat, 2 Aug 2003 17:13:12 -0700 (PDT)

% > 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.
% 
% No, sorry, I forgot about yours, and you're correct that it doesn't
% quite fit into any of the pigeon holes in my previous message.
% 
% If I understand it correctly, the simple version of what you propose
% (just using multicast to find recursive name servers, nothing else)
% substitutes one multicast-based discovery protocol for another
% multicast-based discovery protocol.  Since it's quite possible to
% co-locate a DHCP-lite "server" inside the same "process" (or whatever
% fate sharing unit a server host uses) as the recursive name server,
% the fate sharing comparision comes out as a wash when one looks at it
% closely.  So one's left arguing about relatively trivial engineering
% details like packet formats and port numbers.
% 
% The SRV based stuff is a different ball of wax: in that one, you're
% reinventing SLP instead of reinventing DHCP :).  While one could
% certainly have a fun discussion along those lines, the ZEROCONF and
% DNSEXT WGs have already spent a lot of time down the LLMNR rabbit
% hole, and I'm reluctant to follow them down there.

	See the TBDS work that predates LLMNR (and is referenced by it)
	There are some interesting tweeks that should be done to the 
	protocol (a replacement for QUERY comes to mind...)

	when the early work was done, DHCP did not have all the hooks
	and SLP was too "heavy".   

% In any case, either version of what you're talking about still looks
% to me like a proposal for new protocol work.  We're still trying to
% determine whether -any- new protocol work is needed, so this, like the
% RA-based and ND-based proposals, isn't really in scope at the moment.

	Sorry about bringing up packing plant rejects... :)

% #----------------------------------------------------------------------
% # To unsubscribe, send a message 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: Ralph Droms <[email-masked]>
Date: Sat, 02 Aug 2003 20:29:42 -0400

Eric,

I think there has been a difference of opinion in the past about your 
statement: "Granted, there would be some administration in terms of 
ensuring that multicast filters were working properly, but this is less 
than the requirements for DHCP."  My recollection is that similar 
multicast-based mechanisms have been rejected in the past because they 
require a multicast service, which has not been universally deployed to 
date.  Network admins do have successful experience with DHCP service 
deployment in IPv4 and the service deployment model in IPv6 would be 
essentially the same...

- Ralph

---

From: "Eric A. Hall" <[email-masked]>
Date: Sat, 02 Aug 2003 20:07:37 -0500

> alternative of using DHCP relays if site multicast isn't practical.

I'll go refresh on dhcpv6-lite, but in the meantime if you'll guarantee
that manual maintenance of extra-service configuration data will never be
mandatory (my fear word) then I'll rescind my concerns.

---

From: Rob Austein <[email-masked]>
Date: Sun, 03 Aug 2003 13:20:12 -0400

> mandatory (my fear word) then I'll rescind my concerns.

It's clearly possible to use DHCPv6-lite for DNS discovery in a way
that does not require manual configuration, but read the draft and
decide for yourself.  Whether implementors and operators will chose to
support the no-manual-config co-located DHCPv6-lite server model is a
separate question, which might conceivably be the subject of a short
BCP doc if we reach consensus that this is important.
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: "Jaehoon Paul Jeong" <[email-masked]>
Date: Mon, 4 Aug 2003 10:47:24 +0900

----- Original Message ----- 
From: "Rob Austein" <[email-masked]>
To: <[email-masked]>
Sent: Sunday, August 03, 2003 2:11 AM
Subject: Re: Policy of IPv6 DNS Discovery
> you and I already had when you pestered me about this in private, but

If I bothered you, I am sorry for that.
However, I wanted you, as DNSOP chair, join the discussion more actively.

> requirements and existing protocols.

I have two questions to ask you.
1. Do you mean that RA-based DNS Discovery is out of scope in DNSOP wg?
2. Do you think that DHCPv6-lite is necessary in the environment where DHCPv6 exists?

For the second question, IMHO, in such a case, DHCPv6-lite is unnecessary.
RA-based approach seeks to harmonize with DHCPv6.
Is this non-sense?

/Jaehoon Paul

---

From: Rob Austein <[email-masked]>
Date: Sun, 03 Aug 2003 23:07:48 -0400

> 1. Do you mean that RA-based DNS Discovery is out of scope in DNSOP wg?

I have already answered this question, more than once:

  Discussion of new protocol extensions (such as your draft) will be in
  scope (for some WG, probably not DNSOP) if and only if the
  requirements discussion concludes that there's a gap between real
  requirements and existing protocols.

Serious question, not intended as sarcasm: is there some part of the
previous sentence which you do not understand?

> RA-based approach seeks to harmonize with DHCPv6.

DHCPv6-lite is a subset of DHCPv6; therefore, by definition, if one
has DHCPv6, one also has DHCPv6-lite, and a DHCPv6-lite client doesn't
care whether the server(s) that answer it are DHCPv6 or DHCPv6-lite.
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 4 Aug 2003 13:02:26 +0859 ()

Rob Austin;

> entire discussion in the IPv6 WG,

which is partly why I abandoned IPv6 WG not being a place
for serious protocol discussion long before.

>    restate them here,

I guess there should be a lot of confusions on "stateless" in addition
to poor understandings on "anycast", such as that anycast addresses
should not be a source address, and on "scope" such as that discussed
in my draft that the archives are not helpful.

If my guess is wrong, correct me with a few pointed references.

>    but I will note that sites which chose to do

Right. However, autocnfiguration is not a protocol but an operational
issue.

Site dependent anycast addresses can not remove operational effort
of DNS configuration by site administrators.

Global anycast addresses does remove it.

> made for why further protocol work is needed, I haven't seen it yet.

As we agree that

> entire discussion in the IPv6 WG,

isn't it obvious that removal of features related to "stateless
autoconfiguration", including entire ND, from IPv6 is the required
protocol work?

							Masataka Ohta

---

From: "Jaehoon Paul Jeong" <[email-masked]>
Date: Mon, 4 Aug 2003 14:35:19 +0900

Thanks for your prompt answers.

----- Original Message ----- 
From: "Rob Austein" <[email-masked]>
To: <[email-masked]>
Sent: Monday, August 04, 2003 12:07 PM
Subject: Re: Policy of IPv6 DNS Discovery

> previous sentence which you do not understand?

Now, I CAN unterstand your intention exactly.
Where can we discuss new protocol extensions if neither in IPv6 wg, nor in DNSOP wg?
This is a question for all DNSOP members except for you.

> care whether the server(s) that answer it are DHCPv6 or DHCPv6-lite.

If DHCPv6-lite is a subnet of DHCPv6, there may be no problem that RA-based DNS Discovery
coexists with DHCPv6 like in ND spec.
A significant number of people, including me, really want RA-based DNS Discovery.
I think, they know the usefulness and operation of DHCPv6.
At least my company has implemented DHCPv6 client/server fully.

I think, I did my best to appeal the necessity of RA-based DNS Discovery, 
although I could not express my opinions well enough because of the limitation of Non-English speaker.

If there is proper reason RA-based DNS Discovery SHOULD NOT coexist with DHCPv6,
I will also rescind my concerns about RA-based DNS Discovery.
Thanks.

/Jaehoon Paul

---

From: John Schnizlein <[email-masked]>
Date: Mon, 04 Aug 2003 07:22:13 -0400

>This is a question for all DNSOP members except for you.

The discussion of the question whether a protocol extension is
necessary for IPv6 hosts to locate DNS servers is underway here.
All the chair is requesting is that we understand first if there
is any need, before we discuss the nature of protocol extensions
that might fit that need.

>although I could not express my opinions well enough because of the limitation of Non-English speaker.

Your interest is clear, and those of us who understand only English
appreciate your extra effort in making it clear in a language other
than your first.

>If there is proper reason RA-based DNS Discovery SHOULD NOT coexist 
>with DHCPv6, I will also rescind my concerns about RA-based DNS Discovery.

I think the reason is stated in RFC 1958: Architectural Principles of 
the Internet.:

   3.2 If there are several ways of doing the same thing, choose one.
   If a previous design, in the Internet context or elsewhere, has
   successfully solved the same problem, choose the same solution unless
   there is a good technical reason not to.  Duplication of the same
   protocol functionality should be avoided as far as possible, without
   of course using this argument to reject improvements.

While this does not deny that different solutions might be appropriate
for different operational situations, it does require that the nature of
the different situations, and the suitability of proposed solutions to 
those differences, should be identified. We have not seen the difference.

Since there is a protocol (DCHPv6) which can provide the necessary
information for hosts, and since the "heavy-weight" concerns attributed
to that protocol have been shown invalid (existence proof: DHPCv6-light),
justification for developing a new protocol (or extension of RA) must meet 
the burden identified in Architectural Principle 3.2

John

---

From: Tim Chown <[email-masked]>
Date: Mon, 4 Aug 2003 13:26:02 +0100

> the burden identified in Architectural Principle 3.2

By that argument, we would not have IPv6 stateless autoconf at all?

Tim

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 4 Aug 2003 21:45:29 +0859 ()

John;

> Your interest is clear,

And it is also clear that his case does not need RA-based DNS
discovery, as was pointed by two of us.

In mobile case, mobile hosts need constant DNS service. It is NOT
acceptable that the mobile hosts try to find DNS server at
foreign environment sometime successfully and sometimes not
that DNS service MUST be bundled and share fate with HA service,
which should be configured simultaneously.

> and those of us who understand only English

He should also appreciate my extra effort.

> the burden identified in Architectural Principle 3.2

ND performs functionality already provided by ARP, DHCP and routing
protocols that it should disapper.

For example, DHCP collocated on routers is the mechanism to provide
address prefixes for autoconfiguration of addresses.

						Masataka Ohta

---

From: Ralph Droms <[email-masked]>
Date: Mon, 04 Aug 2003 09:16:13 -0400

Tim,

Do you think Architectural Principle 3.2 is being misinterpreted in
this discussion (regarding DNS configuration), or should AP3.2 be amended,
or should we deprecate IPv6 stateless autoconfiguration?

I ask in all seriousness, because IMHO the IETF as a whole may not be
keeping AP3.2 as firmly in mind as it should...

I'm also a little leery of lurching off into a philosophical black hole on
the dnsop mailing list, so any declaration of "out of scope" will be heeded.
Perhaps discussion of AP3.2 might move to the problem-statement mailing list?

- Ralph

---

From: John Schnizlein <[email-masked]>
Date: Mon, 04 Aug 2003 09:36:17 -0400

>By that argument, we would not have IPv6 stateless autoconf at all?

Not necessarily by that argument, but this is neither the time nor
place to revisit that question. We can assume for now that there were
sufficient reasons to justify stateless auto-config of host addresses.

Notice that the existence proof to which I refer is stateless also.
Just because the DHCPv6 protocol is used, does not make the result
state-full. Remember that the DHCP server can provide site-specific
information in a stateless way even if it is not managing (state-fully)
the addresses of the hosts. As an additional simplifying feature,
providing (stateless) information about the address of DNS servers
uses the same protocol where addresses are (state-fully) managed 
by a DHCP server. Host configuration can either include or exclude 
host address configuration, depending on the site's decision.

John

---

From: Alain Durand <[email-masked]>
Date: Mon, 04 Aug 2003 13:10:41 -0700

>By that argument, we would not have IPv6 stateless autoconf at all?
No, because DHCPv6-lite keeps no state, so it is fitted
to hand out information without keeping track of who it sent them to.
Works just fine for DNS server, NTP,.... discovery, but
is a little cumbersome for address management...

Note: for those of us who really do not like stateless autoconf,
we could still replace it with DHCPv6-lite where the returned address
would be the concatenation of the prefix and the modified EUI64....
This would not require the DHCPv6-lite server to keep any state,
it could be easily implemented in the routers, ,will serve as access 
control,
allow for prefixes other than /64, simplify having multiple prefixes
on the same link and make the management of reverse DNS so much simpler...
Just 1/2 kidding. ;-)

    - Alain.

---

From: Randy Bush <[email-masked]>
Date: Mon, 4 Aug 2003 13:25:37 -0700

> requirements and existing protocols.

<ad hat>

this is indeed what i thought was/is happening

randy

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 5 Aug 2003 10:10:12 +0859 ()

Alain;

> Note: for those of us who really do not like stateless autoconf,

The problem of stateless autoconf is that it is not define at all,
while the resulting protocols have duplicated functionalities to
existing ones.

Though it is so easy to overlook AP3.2, those who carefully observe
it are rewarded a lot for ease of design, operation and deployment.

> it could be easily implemented in the routers,

That's what I have already pointed out.

> will serve as access 

In addition, with DHCP autoconfiguration, it is also possible to use
arbitrary value for the lower 64 bits of addresses at the descretion
of site administrators.

							Masataka Ohta

---

From: Pekka Savola <[email-masked]>
Date: Tue, 5 Aug 2003 10:27:50 +0300 (EEST)

> which should be configured simultaneously.
[...]

There are two cases here:

 1) "mobile hosts which use Mobile IP"

 In this case, what you say may rather close to the mark.  However, note 
that if a mechanism to find DNS service is commonplace, hosts would have 
more success in finding it -- and the point of not getting it would be 
moot.  

 Moreover, the DNS service located at the home network could be the "last 
resort" service, to be used when no other DNS servers are found in foreign 
network(s).  Depending on where your home agents are (e.g. across the 
globe, 300 ms RTT away), being able to optimize to use the closer DNS 
servers would be desirable, I think.

 2) "mobile hosts without Mobile IP"

A case of this is e.g. a laptop which just plugs in networks here and
there (e.g. IETF meetings) and is not concerned on connection survability,
i.e. doesn't really have a home agent or home network (in Mobile IP
terms).  Such hosts typically require nothing else of the foreign networks
they use than DNS resolution.  They already have (in most cases!)
sufficient clock (for DNSSEC, if used), don't want DNS search path to
point to some local operator's domain because they don't care about it,
etc.

Seems like there may be some cases where DHCP-less operation could indeed 
be useful.

However, if implementing DHCP-lite or such was simple and straightforward 
enough, requiring very little effort, that just *MIGHT* be the way to go 
-- because it will have to be implemented *anyway* to cater for the needs 
of the other cases where configuring more than just the DNS server is 
needed.

I haven't really made up my mind whether DHCP-lite fulfills those
criteria.

-- 
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: Masataka Ohta <[email-masked]>
Date: Tue, 5 Aug 2003 17:34:42 +0859 ()

Pekka;

> There are two cases here:

No.

>  2) "mobile hosts without Mobile IP"

Don't try to misdirect the discussion.

> such as HMIPv6, MANET connected to the Internet and NEMO.

That is the assumption here.

Worse, most of your reasonings are wrong and rest of them are too
weak that any standardized way of DNS autoconfiguration is fine
for your requirement.

							Masataka Ohta

---

From: "Eric A. Hall" <[email-masked]>
Date: Wed, 06 Aug 2003 14:07:45 -0500

> details like packet formats and port numbers.

Are you referring to draft-ietf-dhc-dhcpv6-stateless-00.txt or something
else? That draft makes no mention of multicast whatsoever, and the
reference context of link-local is a unicast address.

> determine whether -any- new protocol work is needed, so this, like the

Some amount of work will need to be done no matter what. At the very
least, a set of behavioral rules will need to be codified.

---

From: Rob Austein <[email-masked]>
Date: Wed, 06 Aug 2003 15:24:16 -0400

> reference context of link-local is a unicast address.

draft-ietf-dhc-dhcpv6-stateless-00.txt is primarily a guide to the
relevant portions of the DHCPv6 spec, and includes a bunch of
normative references.  Try RFC 3315 section 1.2.
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: "Eric A. Hall" <[email-masked]>
Date: Wed, 06 Aug 2003 16:11:27 -0500

on 8/6/2003 2:24 PM Rob Austein wrote:

> Try RFC 3315 section 1.2.

Okay, that and various other sections helped.

As I see it there are a few issues that would need to be described, and
which would effectively equate to protocol work. This includes your
proposal that servers should return a single-item list of just themselves
(or not, if you want to do something else), client algorithms for sorting
the responses (eg, weighted according to the search lists, in comparison
to the host's known domain), recovery options (which do not seem to be
described), and possibly IPv4 support which was listed as a desirable
feature (and would be desirable for the networks I work with, too).

---

From: Pekka Savola <[email-masked]>
Date: Thu, 7 Aug 2003 09:23:27 +0300 (EEST)

> That is the assumption here.

I'm not restricting myself to Jaehoon's assumptions about applicability of 
RA-approaches.  I'm just pointing out that when one says "mobile node", it 
can mean at least a couple of different things.
 
> weak that any standardized way of DNS autoconfiguration is fine

Please elaborate.

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 7 Aug 2003 20:44:45 +0859 ()

Pekka Savola;

> I'm not restricting myself to Jaehoon's assumptions

Here, you are restricted by the context with which we are discussing,
if you want to contribute to the discussion.

> I'm just pointing out that when one says "mobile node", it 

Do it elsewhere, not here.

Here, in this thread at least, we already have an established
terminology, defined by Jaehoon Paul Jeong, on mobility.

Note also that the definition is well established in IETF that
you should find somewhere outside of IETF.

> > weak that any standardized way of DNS autoconfiguration is fine

Read recent mails of this WG to find the elaboration.

						Masataka Ohta

---

From: Pekka Savola <[email-masked]>
Date: Sat, 9 Aug 2003 20:42:52 +0300 (EEST)

> if you want to contribute to the discussion.

What prevents me from expanding the scope of that discussion?  That's what 
discussion is about.

Granted, perhaps it would have been clearer if I had changed the subject 
line when originally posting, but most supposedly read the whole emails, 
not just the subject line.

> terminology, defined by Jaehoon Paul Jeong, on mobility.

See above.

> Read recent mails of this WG to find the elaboration.

They do not provide elaboration of this specific context so it is not
apparent which mails you're referring to. Please spell it out.