Subject: RE: IPv6 Host Configuration of Recursive DNS Server

From: "Christian Huitema" <[email-masked]>
Date: Sun, 6 Jun 2004 21:28:14 -0700

Two points:

1) In the disadvantage of DHCPv6 section, you ought to mention that
there is a ensure that the DHCP server always returns an up-to-date
value for the address of the preferred recursive DNS server. In large
networks, this is not trivial: the notion of which server is closest
depends on routing configuration and on server status, all of which are
dynamic. In contrast, the anycast approach guarantees that the request
will reach the closest server.

2) In the unmanaged case, you wrongly assume that case C is "like case
A". In fact, it is more like case B: if a gateway provides IPv6
connectivity by managing tunnels, then it is also supposed to provide
access to a recursive DNS server.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Jaehoon Paul Jeong
> Sent: Sunday, June 06, 2004 8:57 PM
> To: [email-masked]
> Cc: V6OPS WG; DHC WG; IPv6 DNS Configuration; IPv6 WG
> Subject: Re: IPv6 Host Configuration of Recursive DNS Server
> 
> Hi all,
> 
> For 1 week, there have been no comments on our IPv6 DNS Configuraion.
>
http://www.adhoc.6ants.net/~paul/publications/ietf-internet-draft/draft-
> ietf-dnsop-ipv6-dns-configuration-00.txt
> 
> Does it mean that there is no problem about this draft and it is ok to
> request WGLC? :-)
> 
> Paul
> 
> ----- Original Message -----
> From: "Jaehoon Paul Jeong" <[email-masked]>
> To: <[email-masked]>
> Cc: "IPv6 DNS Configuration" <[email-masked]>
> Sent: Thursday, June 03, 2004 2:38 PM
> Subject: Re: IPv6 Host Configuration of Recursive DNS Server
> 
> 
> > There is some problem of  column alignment at our draft.
> > You can find a fixed version at the following site:
> >  http://www.adhoc.6ants.net/~paul/publications/ietf-internet-
> draft/draft-ietf-dnsop-ipv6-dns-configuration-00.txt
> >
> > Thanks.
> >
> > Paul
> >
> > ----- Original Message -----
> > From: "Jaehoon Paul Jeong" <[email-masked]>
> > To: <[email-masked]>
> > Cc: "IPv6 DNS Configuration" <[email-masked]>
> > Sent: Thursday, June 03, 2004 10:10 AM
> > Subject: IPv6 Host Configuration of Recursive DNS Server
> >
> >
> > > Hello DNSOP members,
> > >
> > > As you know, a new draft has been published for IPv6 Host
> Configuration of DNS Server Information Approaches:
> > >  http://www.ietf.org/internet-drafts/draft-ietf-dnsop-ipv6-dns-
> configuration-00.txt
> > >
> > > For a long time, DNS Discovery has been discussed at both IPv6 and
> DNSOP working groups.
> > > The long discussion seems to be resolved through this draft.
> > >
> > > In this draft, three approaches are suggested: (a) RA option, (b)
> DHCPv6 option, and
> > > (c) Well-known anycast addresses for Recursive DNS Servers.
> > > We, authors, used "DNS Configuration" instead of "DNS Discovery"
> because recursive DNS server address is
> > > only configured in IPv6 host, not generating DNS server address
like
> in IPv6 address autoconfiguration.
> > >
> > > This draft focuses on describing the attributes of three
approaches
> and suggesting four applicable scenarios:
> > > (a) ISP network, (b) Enterprise network, (c) 3GPP network, (d)
> Unmanaged network.
> > >
> > > Through your review and comments, this will be published as
> Informational RFC according to our milestones.
> > > IMHO, if necessary, the drafts of two other approaches except
DHCPv6
> option will be developed into separate RFCs.
> > >
> > > Thanks.
> > >
> > > Paul,
> > > IPv6 DNS Configuration Design Team.
> > >
> > > ------------------------------------------------------
> > > Jaehoon Paul Jeong (Research Engineer)
> > > TEL. +82-42-860-1664
> > > Mobile +82-16-711-1765
> > > 161 Gajeong-dong Yuseong-gu, Daejeon 305-350, Korea
> > > NGI Standardization Research Team/PEC/ETRI
> > > Homepage: http://www.adhoc.6ants.net/~paul
> > >
> >

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: "Jaehoon Paul Jeong" <[email-masked]>
Date: Mon, 7 Jun 2004 18:03:34 +0900

Thanks for your good comments.

I agree with you at your two points.
Especially, number 2 is the opinion of your co-author, Suresh.
He will speak about your opinion.

Paul

>From: "Christian Huitema" <[email-masked]>
>To: "Jaehoon Paul Jeong" <[email-masked]>; <[email-masked]>
>Sent: Monday, June 07, 2004 1:28 PM
>Subject: RE: IPv6 Host Configuration of Recursive DNS Server
>
>Two points:
>
>> From: [email-masked] [mailto:[email-masked]] On Behalf Of Jaehoon Paul Jeong
>>http://www.adhoc.6ants.net/~paul/publications/ietf-internet-draft/draft-ietf-dnsop-ipv6-dns-configuration-00.txt
>>

---

From: Ted Lemon <[email-masked]>
Date: Mon, 7 Jun 2004 12:24:26 -0700

> will reach the closest server.

This is really more of an advantage of using an anycast address over 
using a unicast address, and has nothing to do with DHCPv6.   If you 
want this functionality, you can use DHCPv6 to configure the anycast 
address, or you can hard-code the anycast address.   The question we're 
trying to address is really how we configure nodes as they come on to 
the network, not with what we configure them.   The reason that anycast 
has a place in this discussion is that it's the only possible value 
that you could just hard-code into the client and thereby bypass 
configuration altogether.

We need to be very careful in discussing this draft not to get confused 
about what the draft does.   It does not say "this is the solution."   
Rather, it is essentially a sales tool which tries to present the 
advantages and disadvantages of each option, so that the buyer (the 
IESG, I guess) can make an informed choice between them.   So please 
let us not digress into deep, detailed discussions about why the other 
guy's choice is wrong - just say what's good about the proposal you 
favor, and if you want to be honest, discuss any disadvantages of which 
you're aware.

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 08 Jun 2004 17:35:18 +0900

Dear all;

The problem is rather generic than DNS configuration. But...

I know ND is wrong. That is, I know it is wrong to have generic
link protocols ignoring link specific properties and has been
pondering on how such protocols suffer.

I just recently noticed that WLAN (802.11*) is not very good at
supporting ND (nor DHCP nor any broadcast/multicast protocol).

Because WLAN use CSMA/CA, it needs ACK for reliable transmission
by confirming that each packet reaches its destination without
collision.

However, with broadcast/multicast packets, there is no ACK for
an obvious reason.

If WLAN is lightly loaded, it is not a serious problem.

However, if WLAN is heavily loaded, ND (and DHCP and any broadcast/
multicast protocol) works poorly. Note that MIPv6 works poorly
too. 

Still, management beacon frames are transmitted frequently
and expected to carry information in a long run.

So, it is possible to piggyback broadcast/multicast part
of address resolution and autoconfiguration (maybe and
routing) in reserved fields of beacon frames.

Though  it is possible to use some data frame frequently
transmitted like beacon frams, it make the already congested
WLAN worse.

Anyway, the fundamental mistake is to try not to have link
specific ways to perform address resolution and autoconfiguration.

DHCP simply needs link specific ways of DHCP discover.

ND needs, IMHO, a lot more.

Note that modifying WLAN protocol to use PIFS is not enough
unless combined with frequent transmission.

						Masataka Ohta

---

From: Mohacsi Janos <[email-masked]>
Date: Tue, 8 Jun 2004 13:28:35 +0200 (CEST)

Hi Masataka,

> pondering on how such protocols suffer.

I think ND is not wrong. There is a clear need for better support to
discover the link parameters, but it is necessary for mostly to the
routing protocols.

> However, with broadcast/multicast packets, there is no ACK for

The IPv4 ARP is not better either, as you found. I think the WLAN should
be improved some way to support multicast in some form.

> routing) in reserved fields of beacon frames.

I think autoconfiguration can be treated differently, than address
resolution. ND as stand for "Neighbour" Discovery is a very good
improvement to ARP and transport specific things...
Of course ND can get into trouble if no reply for ND requests (with
soliticited node multicast address)...

> ND needs, IMHO, a lot more.

What do you think?

> unless combined with frequent transmission.

I agree.

Janos Mohacsi
Network Engineer, Research Associate
NIIF/HUNGARNET, HUNGARY
Key 00F9AF98: 8645 1312 D249 471B DBAE  21A2 9F52 0D1F 00F9 AF98

---

From: Pekka Savola <[email-masked]>
Date: Tue, 8 Jun 2004 16:05:24 +0300 (EEST)

Tailed down mailing lists to just IPv6 WG list..

On Tue, 8 Jun 2004, Masataka Ohta wrote:
> Mohacsi Janos wrote:
> ND is wrong, because it was designed to be applicable to all the
> link types.
> 
> ND deployed multicast only because some ATM guy said NBMA was
> capable of not broadcast but multicast, which is totaly denied
> by the current ND RFC stating that ND may not be applicable to
> NBMA.

I agree that using multicast for ND was probably not one of the wisest
choices in the long run, and we're suffering from it today (e.g., as
many WLAN APs working as bridges don't forward IPv6 neighbor discovery
frames because they are multicast).  There is only marginal value in
ND using multicast (compared to broadcast), as the typical number of
nodes per link is so low that broadcast storms are not a real problem.

However, that doesn't change your original argument about CSMA/CA,
because broadcast suffers from the same issues as well.

> The solution has been never bother to have standard way of
> address resolution.

I have to disagree here.  Just because broadcast/multicast (ND) isn't
optimized for WLAN (or CSMA/CA in general, I guess), that doesn't
nullify the usefulness of ND for all the other media for which this is
not a problem.

The right fix appears to be specifying an IPv6 over WLAN document (or 
the like) which specifies a possible way to optimize the situation for 
WLAN media.

But while IPv6 over WLAN may not be fully optimal, as it requires
link-layer acknowledgements of multicast packets, I think many already
deem it to work to a *sufficient* degree .. and I'm not sure whether
there would be consensus for specifying e.g. the changes you
suggested.  Data (simulations, measurements, etc.) about the
performance, latency, etc. increases might help.
 
-- 
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: George Gross <[email-masked]>
Date: Tue, 8 Jun 2004 10:05:13 -0400 (EDT)

Hi,
	unreliable flooding of control/routing packets is a long standing
problem in the MANET working group [1]. Recently the MANET working group
formed a design team that will tackle this problem among others that arise
when extending OSPF for wireless media.  AFAIK, their design will be
IP-v4/IP-v6 agnostic.

There have been several reliable multicast mechanisms discussed on MANET,
but none have been written up as an Internet Draft yet. If the IP-v6 ND
requirements were well defined, one could pick one of them as the reliable
IP-v6 link-local multicast mechanism.

hth,
	George

[1] refer to the April 8th 2004 MANET working group thread with the
Subject line entitled: " Comments on "Problem Statement for OSPF
Extensions ..." for more background.

---

From: George Gross <[email-masked]>
Date: Wed, 9 Jun 2004 09:17:36 -0400 (EDT)

Hi,

On Wed, 9 Jun 2004, Masataka Ohta wrote:

> George Gross;
> Reliable multicast works over mostly reliable multicast transport.
>
> However, in this case of congested WLAN, multicast/broadcast
> infrastructure is totally unreliable.

For that scenario, I would suggest taking a look at "A Reliable and
Optimised Flooding Mechanism for Adhoc Networks" [1] which describes
Reliable Minimum Spanning Tree (RMST). RMST is a unicast-based alternative
to multicast flooding. there also has been results mentioned on MANET
about how 802.11e can assign higher priority to control packets to achieve
more robust behavior. YMMV.

	George

[1] http://www.cse.unsw.edu.au/~justinl/rmst.pdf

---

From: Mohacsi Janos <[email-masked]>
Date: Wed, 9 Jun 2004 11:08:14 +0200 (CEST)

On Wed, 9 Jun 2004, Masataka Ohta wrote:

> Mohacsi Janos;
>
> > I think it is very useful. The DHCP is very heavy in some environment.
>
> ND is very heavy in some MIPv6 environment.

I agree.

>
> Say it to Bob Hinden and others who wrote things like
>
>    3.1.1 Neighbor Discovery Extension - DNS Server Option
>
> in the DNS autoconfiguration draft.

Then probably has to rename something like : Autoconfigration extension
with Neighbor Discovery -DNS Server Option

>
> >>If we concentrate on Ethernet and address resolution, there is
> >>no reason not to use ARP.
>
> > There is a reason to use ND e.g. on point to point to links you can use
> > ND, while ARP is useless.
>
> ARP is working just fine over point to point Ethernet, though
> point to point links do not need any MAC address, in which
> case both ARP and ND are unnecessary and useless for address
> resolution.
>
> So?

Even if you don't configure any address on your point to point links?
How can you check existence a working node with the link-local address of
the remote side?

Regards,

Janos Mohacsi

---

From: Mohacsi Janos <[email-masked]>
Date: Wed, 9 Jun 2004 09:42:18 +0200 (CEST)

On Wed, 9 Jun 2004, Masataka Ohta wrote:

> Pekka Savola;
>
> > There is only marginal value in
> It has been wrong to try to make ND "useful" for all the useless
> purposes, some of which is already recognized useless or
> harmful (for example, at first, as reasoning not to use ARP, it
> was proposed to send unicast data packet over link multicast,
> which was expected to eliminate the need for a pending queue).
> Now, it is more and more widely recognized that stateless
> autoconfiguration, which was invented as reasoning not to
> use DHCP, is not as useful as expected.

I think it is very useful. The DHCP is very heavy in some environment.
Sorry Masataka, but you are mixing autoconfiguraiton and neighbor
discovery. They are different beasts, they are using the some
infrastructure, that is called ICMPv6.

>
> The sane thing to do is to narrow the scope as much as possible
> and to remove features as much as possible.
>
> For example, MIPv6 suffer, because it, seemingly, recognized ND
> available on all the link types and developped protocol. Then,
> it was found that ND timing values makes MIPv6 not useful for
> quickly moving hosts. It is wrong to have standard timings
> ignoring link specific properties. And, then, there is no
> reason to have standard protocols ignoring link specific
> properties.
>

There is a reason to use ND e.g. on point to point to links you can use
ND, while ARP is useless. ND is very good at discovering neighbor in a
unified way. I think there is no reason kill ND, but make it optimised for
CSMA/CA type network.

Regards,
	Janos Mohacsi

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 08 Jun 2004 21:29:19 +0900

> I think ND is not wrong.

> There is a clear need for better support to

If you are talking about QoS, it is a totally different topic.

> The IPv4 ARP is not better either, as you found.

No, ARP is no better, of course.

Given the point to multipoint nature of infrastructure WLAN,
and given the probability of hidden terminals, ARP is overkill.
Just send all the packets to the base station, IP address of which
should be piggy-backed in beacon.

As for ad-hoc WLAN, it does not work well with multiple link
hops that it is a bad idea at L2. 

> I think the WLAN should

It is inherent to CSMA/CA link that broadcast/multicast is
unreliable.

Our (IETF) approach has been to make IP work over as much link
technology as possible.

> improvement to ARP and transport specific things...

However, there are people who think ND should take care of
everything including DNS configuration.

> What do you think?

Because of its bloated set of features, I think ND hopeless.

							Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 09 Jun 2004 17:44:20 +0900

Mohacsi Janos;

Note that I am no DHCP lover and I know DHCP suffer from WLAN.

> discovery.

So?

Or, are you saying ND over point to point links are useful for
autoconfiguration?

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 09 Jun 2004 16:16:17 +0900

George Gross;

Hi,

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 09 Jun 2004 15:59:40 +0900

Pekka Savola;

> nodes per link is so low that broadcast storms are not a real problem.

I'm afraid you use the term "broadcast storm" incorrectly
(the broadcast storm is huge number of broadcast-style (including
all-*-multicast) packets caused by incorrectly implemented/configured
nodes.

Note also that, on WLAN, even unicast packets are broadcast.

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 10 Jun 2004 01:14:53 +0900

George Gross;

> to multicast flooding.

The basic strategy is to use frequent beacon to advertise
exsistence of entities with optional piggy-backed information
and use unicast to exchange further information.

For infrastructure WLAN with a single base station, the tree should
be a star with the base station at its center, which means the base
station unicasts multicast packets to others. Things get more
complicated if there are multiple base stations connected by
wire, where there are multiple stars. New encapsulation is
necessary to avoid loops.

So, it is not a WLAN link layer but a virtual and inefficient
link layer over WLAN.

However, our goal is to let IP work over various link layers
as efficiently as possible using link specific properties.

> there also has been results mentioned on MANET
> more robust behavior.

Sure. But, not all WLAN cards support it.

							Masataka Ohta

---

From: Jari Arkko <[email-masked]>
Date: Thu, 10 Jun 2004 13:15:25 +0300

Hi Masataka, Greg, and Pekka,

and elsewhere Greg Daley wrote:

> If there are issues in creating new NC entries
> (particularly for mobile nodes) then they should
> be tackled in IRTF MobOpts or fed to the MIP6/MIPSHOP
> WGs.
> 
> All of these groups may require some quantification of
> the problems and the proposed solutions before they
> take on work though (rather than dire 'ND is broken'
> statements).

I tend to agree with Greg and Pekka here. I do agree that
we have performance and other issues with wireless
link layers. Many of these issues are known and
currently being dealt with somewhere, and for the
rest we should carefully define the problems and discuss
how they should be solved. Some issues can be solved
using IPv6 over Foo documents, while others are
best suited for a general solution.

--Jari