Subject: Re: Forward: Re: Last Call: 'IPv6 Router Advertisement Option for DNS Configuration' to Experimental RFC (draft-jeong-dnsop-ipv6-dns-discovery)

From: Bob Hinden <[email-masked]>
Date: Mon, 3 Jul 2006 13:18:06 -0700

Tatuya,

On Jun 29, 2006, at 9:52 PM, ext JINMEI Tatuya / 神明達哉 wrote:

> Resending to the list with the source address that appears to be
> expected (the original message seems to have been filtered)...
>
> This time I'm also copying the ipv6 list.  In fact, ipv6@ietf would be
> more suitable place for discussions on this proposal, since it's an
> extension to ND.

I agree and removed the cc: to DNSOP in this reply.

>
> I have several comments on this draft:
>
> - A meta level comment
>
>   I'm afraid I'm re-raising an old discussion (in which case I hope
>   someone will point it out), but I'm concerned that this document may
>   open up a possibility of making (autoconfiguration via) Router
>   Advertisement a convenient and uncontrollable kitchen sink.  In my
>   understanding, the applicability of RA in the original design was
>   limited to a minimum number of layer-3 configuration information
>   parameters, such as subnet prefixes and default router addresses.
>   If my understanding is correct and the design principle still
>   applies, the proposed option is (IMO) against the principle because
>   the configuration information provided by this document (i.e.,
>   recursive DNS server addresses) is (again IMO) at a far higher layer
>   than the intended one.  And the standardization of this option will
>   then be used as an excuse for succeeding violation like "XXX server
>   address ND option" for arbitrary "XXX" protocols.
>
>   So,
>   + I'd first like to confirm whether my understanding about the
>     'design principle' is correct.  If it's wrong, then I'm fine and
>     this concern will be resolved.

I don't remember any ND design principals like this, nor can I find  
any in RFC2461 or it's update <draft-ietf-ipv6-2461bis-07.txt>.   
Further Section 9 "EXTENSIBILITY - OPTION PROCESSING" does not have  
any text limiting new options to the types you suggest.  I hope this  
resolves your concern.

Bob

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

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Wed, 12 Jul 2006 17:47:34 +0900

>>>>> On Mon, 3 Jul 2006 13:18:06 -0700, 
>>>>> Bob Hinden <[email-masked]> said:

> any text limiting new options to the types you suggest.  I hope this  

Hmm...I cannot find background information about the "design
principle" on the net, either.  It may be just an misunderstanding of
mine, in which case, yes, the above concern is resolved (I might then
propose a DHCPv6 server address RA option:-).

But then I have a related question: why is this document supposed to
be an Experimental RFC, rather than a Proposed Standard?  I originally
thought it was because the spec is going to be standardized against
the 'design principle' as a special exception.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

---

From: Bob Hinden <[email-masked]>
Date: Wed, 12 Jul 2006 13:59:35 -0400

Tatuya,

> propose a DHCPv6 server address RA option:-).

Feel free :-)

> the 'design principle' as a special exception.

At this point, I don't remember exactly why the authors submitted for  
experimental as the topic has a long complicated history.  For  
example see: RFC4339 "IPv6 Host Configuration of DNS Server  
Information Approaches".

Bob

---

From: Soohong Daniel Park <[email-masked]>
Date: Thu, 13 Jul 2006 09:53:56 -0400

> example see: RFC4339 "IPv6 Host Configuration of DNS Server  

In last year back, Margaret had agreed to sponsor this document
in the IESG for Experimental. That is all in my memory. I don't
have any history in there. In fact, I prefer PS to Experimental of course.

Regards,

Daniel (Soohong Daniel Park)
Mobile Convergence Laboratory, SAMSUNG Electronics.

---

From: "Stephen Sprunk" <[email-masked]>
Date: Sun, 16 Jul 2006 13:19:30 -0500

Thus spake "Bob Hinden" <[email-masked]>
>>>> And the standardization of this option will then be used as an
>>>> excuse for succeeding violation like "XXX server address ND
>>>> option" for arbitrary "XXX" protocols.
[snip]
>> propose a DHCPv6 server address RA option:-).

I think this raises an interesting point; there are many DHCP options that 
would make sense to include in an RA -- basically all of the 
non-client-specific ones.  I, like Tatuya, had thought there was some 
long-standing antipathy to doing that, but if not, why stop at just DNS 
servers?

There's two general solutions to this which would remove the need for DHCPv6 
in most cases where it's needed today:

1. Create an new RA option that can contain arbitrary DHCPv6 options, or
2. Import a specific list of DHCP options and assign them new RA option 
numbers.

If we present a solution just for DNS, are we going to have to work on a 
dozen or more of these drafts, one each for DNS, NBNS, NTP, TFTP, etc? 
Let's either solve all of the problems or none of them. I have a strong 
preference for the former, as autoconfig doesn't make much operational sense 
if I still have to deploy DHCPv6 to get my hosts to boot.

S

-- 
Stephen Sprunk        "Stupid people surround themselves with smart
CCIE #3723           people.  Smart people surround themselves with
K5SSS         smart people who disagree with them."  --Aaron Sorkin

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 16 Jul 2006 20:28:33 +0200

On 16-jul-2006, at 20:19, Stephen Sprunk wrote:

> I think this raises an interesting point; there are many DHCP  
> options that would make sense to include in an RA -- basically all  
> of the non-client-specific ones.

Well, then:

> 1. Create an new RA option that can contain arbitrary DHCPv6 options

> There's two general solutions to this which would remove the need  
> for DHCPv6 in most cases where it's needed today

DHCPv6 isn't needed today, and the RDNS option makes sure it's not  
needed in the future where there is no IPv4 RDNS server configured,  
either.

> If we present a solution just for DNS, are we going to have to work  
> on a dozen or more of these drafts, one each for DNS, NBNS, NTP,  
> TFTP, etc?

The difference between DNS and these others is that EVERY general  
purpose host connected to the internet needs to have DNS servers  
configured, while this isn't true for the other protocols, and/or the  
server for these other protocols is much less dependent on the  
connectivity of the host at any given moment in time.

---

From: Ralph Droms <[email-masked]>
Date: Sun, 16 Jul 2006 19:03:36 -0400

This topic has been discussed a couple of times; the most recent discussion
is captured in RFC 4339.

- Ralph

---

From: "Stephen Sprunk" <[email-masked]>
Date: Mon, 24 Jul 2006 12:04:41 -0500

Thus spake "Iljitsch van Beijnum" <[email-masked]>
> needed in the future where there is no IPv4 RDNS server configured,  

DHCPv6 _is_ needed in many cases today due to devices which require options other than RDNS.  For instance, many embedded devices need TFTP servers to boot.  Forcing them to implement a DHCPv6 client just to get one option seems wasteful, given part of the justification for the RDNS option is to remove DHCPv6 from beefy devices like PCs.

> connectivity of the host at any given moment in time.

Not all the world is a PC running a web browser.  Lots of embedded devices have no use for DNS.  They may need other BootP or DHCP options, though.

I don't see why there's resistance to importing either specific DHCP options or the entire lot into the RA, rather than limiting ourselves to RDNS.  In fact, RFC 4339 points this out specifically as a problem with the RDNS RA solution.  If you allow for other _static_ uses of DHCP, nearly all of 4339's objections go away.

S

Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 24 Jul 2006 14:40:05 -0700

> needed in the future where there is no IPv4 RDNS server configured,  

I may be missing something and/or getting this out of context,
but it seems to me that DHCPv6 prefix delegation (RFC3633) will
be one of the more important features of IPv6 going forward.

Is there (or, will there be) a way of doing prefix delegation
w/o DHCPv6?

Fred
[email-masked]

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 24 Jul 2006 21:57:34 +0200

> DHCPv6 _is_ needed in many cases today due to devices which require  
> options other than RDNS.  For instance, many embedded devices need  
> TFTP servers to boot.

:-)

Are you serious? These days more than enough flash to store an  
embedded OS can be had for a buck or so.

> Forcing them to implement a DHCPv6 client just to get one option  
> seems wasteful, given part of the justification for the RDNS option  
> is to remove DHCPv6 from beefy devices like PCs.

If you really think this is useful then go ahead and define something  
using RAs, but I think the days of tftp booting are over. And  
certainly server-wise, if you can run a tftp server you can run a  
dhcpv6 server. In fact, the need to have routers that support the  
tftp boot option could be a deployment issue here.

> Not all the world is a PC running a web browser.  Lots of embedded  
> devices have no use for DNS.

So what kind of communication do they engage in?

> I don't see why there's resistance to importing either specific  
> DHCP options or the entire lot into the RA, rather than limiting  
> ourselves to RDNS.

I don't have insurmountable problems with this, but this not the  
issue under consideration right now, the RA option for DNS  
configuration is.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 24 Jul 2006 23:53:43 +0200

> be one of the more important features of IPv6 going forward.

Prefix delegation is a feature used by routers, not by hosts.

---

From: "Stephen Sprunk" <[email-masked]>
Date: Mon, 24 Jul 2006 16:49:32 -0500

> embedded OS can be had for a buck or so.

Yes, I'm serious.  A couple megs of flash are cheap, but the ROM space to update the OS (or download it the first time) is still precious.  Also, most cheap embedded devices still need to download things like config files to be useful, regardless of whether the OS is in flash, and the _vast_ majority of devices in the VoIP space do so via TFTP.  Ditto for things like thin clients that boot via PXE+TFTP.

I'd love for TFTP to go away and be replaced with something like HTTP, but when you compare the code size, it's no contest.  And then we'd need a new option to specify an HTTP boot URL :-)

> tftp boot option could be a deployment issue here.

In my particular case, the TFTP server is managed by a different entity than the DHCP server, so they're not interchangeable.  Think Vonage -- all those little $25 boxes get addresses via a local DHCP server (or static config), but they grab software and config files from a distant server across the Internet.

> So what kind of communication do they engage in?

I've seen devices that do nothing more than send SNMP traps to a particular IP address, respond to NTP queries, or exchange X11/RFP/RDP with a server.  In my particular case, the device may need RDNS if its servers were configured as hostnames, but if the admin configures the server as an IP address (the normal case), it has no need for RDNS.

While one can argue it's useful for a toaster to support DNS, is it actually _mandatory_?  Is TCP even mandatory if the toaster can get what it needs via UDP?

> issue under consideration right now, the RA option for DNS  

And my answer to that is that this draft solves only a subset of the problem.  If the consensus is that a RDNS-only draft should be advanced, that's fine, but I hope there will be similar support for the next dozen RA options that import other DHCP options the same way.

S

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 24 Jul 2006 17:11:38 -0700

> Prefix delegation is a feature used by routers, not by hosts.

I don't understand this point as it relates to the question of
whether/not DHCPv6 will be needed, and the more I think about
it the more irrelevant it seems. Prefix delegation is a feature
used by clients of a prefix delegation server - in DHCPv6, they
are the DHCP client and DHCP server. What the client actually
*does* with any delegated prefixes is up to the client and
there is no reason to pre-suppose that it will necessarily
behave as a router.

Again, the question is whether there is (or will be) a
way of doing prefix delegation w/o DHCPv6? (If so, would
it be any better than DHCPv6 - or just different?)

Fred

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 28 Jul 2006 15:46:03 +0200

Iljitsch van Beijnum wrote:
>>> DHCPv6 isn't needed today, and the RDNS option makes sure it's
>>> not needed in the future where there is no IPv4 RDNS server
>>> configured, either.
> 
>> I may be missing something and/or getting this out of context, but
>> it seems to me that DHCPv6 prefix delegation (RFC3633) will be one
>> of the more important features of IPv6 going forward.
> 

Indeed, but then there are routers that act as hosts too.  I.e. a Mobile
Router acts as a host when auto-configuring an address on its egress
interface.  And it would be _very_ interesting for the Mobile Router to
auto-configure not only an address for itself but obtain a whole prefix
to be used by nodes in its moving network.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 28 Jul 2006 15:48:51 +0200

Templin, Fred L wrote:
> whether/not DHCPv6 will be needed, and the more I think about it the 
> more irrelevant it seems. Prefix delegation is a feature used by 
> clients of a prefix delegation server - in DHCPv6, they are the DHCP 
> client and DHCP server. What the client actually *does* with any 
> delegated prefixes is up to the client and there is no reason to 
> pre-suppose that it will necessarily behave as a router.
> 
> Again, the question is whether there is (or will be) a way of doing 
> prefix delegation w/o DHCPv6? (If so, would it be any better than 
> DHCPv6 - or just different?)

I have same question.

There exist proposals for distributing a prefix from a HA to the Mobile
Router.  The proposals extend the Mobile IP protocol to distribute the
prefix.

This is the only alternative I know to DHCPv6-PD.

I also have a side question, because it's IPv4.  I wonder whether there
exists a DHCPv4-PD (subnet allocation was called?).  It was a DHC WG
item until last June IIRC, and I can't seem to find an RFC.  But this is
IPv4.

Alex

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 31 Jul 2006 09:24:43 -0700

Hi Alex,

> item until last June IIRC, and I can't seem to find an RFC.  But this
is

Yes, there is an expired draft:

http://www3.ietf.org/proceedings/05nov/IDs/draft-ietf-dhc-subnet-alloc-0
3.txt

but there is also an IPR statement:

https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=237

I had a private correspondence with the draft authors that would
be inappropriate for me to go into detail on, but can say that
in the end I was referred to the IPR statement and contact
information there.

Fred