Subject: [mif] Conluding this question RE: DNS server selection and whether to support DHCPv4 or not

From: <[email-masked]>
Date: Fri, 10 Jun 2011 14:29:43 +0000

Hi,

So.. is there anyone who really wants to have DHCPv4 option for DNS server selection? I don't see real need for it, but this is one big question that needs to be sorted out - preferably before last call:)

Best regards,

	Teemu

---

From: liu dapeng <[email-masked]>
Date: Mon, 13 Jun 2011 01:34:44 +0800

Hi Teemu,

Since DHCPv4 is currently widely used, I think it would be helpful to
support DHCPv4 option for DNS server selection.

BR,
Dapeng Liu

2011/6/10, [email-masked] <[email-masked]>:
> Hi,
>
> So.. is there anyone who really wants to have DHCPv4 option for DNS server
> selection? I don't see real need for it, but this is one big question that
> needs to be sorted out - preferably before last call:)
>
> Best regards,
>
> 	Teemu
> _______________________________________________
> mif mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mif
>

-- 

------
Best Regards,
Dapeng Liu

---

From: Ted Lemon <[email-masked]>
Date: Sun, 12 Jun 2011 15:33:40 -0400

> support DHCPv4 option for DNS server selection.

You raise a good point.   As long as we define the DHCPv4 option to only send IPv4 addresses, it should be straightforward.   Hm, except that it can only be a single option, so we need to define the format so that it can contain multiple "delegations."

---

From: <[email-masked]>
Date: Tue, 14 Jun 2011 14:49:42 +0000

Something like this, perhaps, for DHCPv4 option format:

0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Code         |   Len         |prf| Reserved                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            DNS-recursive-name-server (IPv4 address)           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                          DNS suffixes and prefixes            |
|                          (variable length)                    |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Or is there need to have multiple DNS server IPv4 addresses included in an option?

	Teemu

> -----Original Message-----
> From: ext Ted Lemon [mailto:[email-masked]]
> Sent: 12. kesäkuuta 2011 22:34
> To: liu dapeng
> Cc: Savolainen Teemu (Nokia-CTO/Tampere); [email-masked]
> Subject: Re: [mif] Conluding this question RE: DNS server selection and whether
> to support DHCPv4 or not
> 
> You raise a good point.   As long as we define the DHCPv4 option to only send
> IPv4 addresses, it should be straightforward.   Hm, except that it can only be a
> single option, so we need to define the format so that it can contain multiple
> "delegations."

---

From: Ted Lemon <[email-masked]>
Date: Tue, 14 Jun 2011 09:57:54 -0700

> Or is there need to have multiple DNS server IPv4 addresses included in an option?

Isn't that a feature of the DHCPv6 option?  That is, I thought I understood the draft to be saying that you could send more than one of these options, and by doing so, provide more than one server/domain set.   In DHCPv4, if you send two of the same option, the DHCP client will concatenate them and treat the payload as if it were a single option.

---

From: <[email-masked]>
Date: Wed, 15 Jun 2011 15:14:43 +0000

Yes.. I understand feature parity is a nice thing, but a container option (or nested option) for DHCPv4 sounds complex.. So does feature parity justify this complexity, or would it be enough with DHCPv4 learn just one DNS server capable of serving certain namespaces?

Or do you have some idea how this option could be formatted nicely for DHCPv4?

	Teemu

> Sent: 14. kesäkuuta 2011 19:58
> To: Savolainen Teemu (Nokia-CTO/Tampere)
> Cc: [email-masked]; [email-masked]
> Isn't that a feature of the DHCPv6 option?  That is, I thought I understood the
> draft to be saying that you could send more than one of these options, and by
> doing so, provide more than one server/domain set.   In DHCPv4, if you send
> two of the same option, the DHCP client will concatenate them and treat the
> payload as if it were a single option.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 15 Jun 2011 08:39:58 -0700

> Yes.. I understand feature parity is a nice thing, but a container option (or nested option) for DHCPv4 sounds complex.. So does feature parity justify this complexity, or would it be enough with D…

It seems as though if the feature is useful in IPv6, it's also useful in IPv4.   I can't think of a reason why you'd care less about it in IPv4.

> Or do you have some idea how this option could be formatted nicely for DHCPv4?

I think if you just add a count field for the number of suffixes, it should work.

---

From: <[email-masked]>
Date: Wed, 15 Jun 2011 17:19:05 +0000

Because with IPv4 multihoming is painful..

I'm not sure how count field for suffixes help.... Or does it hint receiver's parser to notice where to expect next preference field etc after multiple option instances have been concatenated? How the concatenation btw works? Receiver sums options up and creates one large with one code field, total length field, and the payloads are then just concatenated? And suffix count helps to find beginning of next instance?

Teemu