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

---

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: Masataka Ohta <[email-masked]>
Date: Tue, 08 Jun 2004 21:29:19 +0900

> I think ND is not wrong.

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.

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

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

> 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