Subject: Re: [dhcwg] Call for review: draft-ietf-mif-dns-server-selection-04.txt

From: <[email-masked]>
Date: Tue, 4 Oct 2011 07:47:37 +0000

Hi,

I would especially appreciate review of the sanity of the DHCPv4 option
structure and usage. Comments to DHCPv6 option and other points are of
course welcome as well.

Best regards,

                Teemu

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Savolainen Teemu (Nokia-CTO/Tampere)
Sent: 20. syyskuuta 2011 22:13
To: [email-masked]; [email-masked]
Subject: Re: [dhcwg] Call for review:
draft-ietf-mif-dns-server-selection-04.txt

Hi, we were planning to update to -05 before soliciting dnsext/dnsop/dhc
comments.. here is the -05 as I have it currently updated after quite some
tsv-area comments. Please check out this -05 instead if you did not read -04
yet.

http://www.ietf.org/id/draft-ietf-mif-dns-server-selection-05.txt

Thanks,

                Teemu

From: [email-masked] [mailto:[email-masked]] On Behalf Of
ext Ted Lemon
Sent: 20. syyskuuta 2011 18:52
To: dhc WG     
Subject: [dhcwg] Call for review: draft-ietf-mif-dns-server-selection-04.txt

There's a document going through the mif working group that defines a new
DHCP option for configuring DNS resolvers.   The document allows the DHCP
server to send the DHCP client a list of domains for which specific name
servers should be used instead of the name servers configured in the DNS
Recursive Name Server option.   It would be helpful if some DHC working
group members could review the document to see if they can find any problems
with it.   If you are interested in discussing the validity of the practice
described in the document, dnsop or dnsext is probably the right place; if
you are interested in making sure that it's a well-formed DHCP option that
is clearly described and can be implemented in such a way that
interoperability is likely, this is the place.

The draft is at:

http://tools.ietf.org/id/draft-ietf-mif-dns-server-selection-04.txt

Thanks!

---

From: Matthew Ryan <[email-masked]>
Date: Tue, 4 Oct 2011 15:11:49 -0700

I have two comments on the option formats for this draft.

First, I note that the DHCPv6 version has the preference value
occupying the two most-significant bits of the octet in which
they appear, while in the DHCPv4 version, they occupy the two
least-significant bits.  No reason for this different is given
that I can see, and I can't think of one of the top of my head.
Unless there is some driving need, they should be the same for
consistency's sake.

Second, the format of the DHCPv4 option as currently defined
will almost certainly require special-case code in DHCP servers
and management consoles to provide formatted display and config-
uration (as opposed to an opaque blob of hex), which will hinder
its adoption.

Converting the "domain count" into a octet-length of the
following fields (reserved/prf, address, domains-and-networks)
would make it much simpler to parse, by not requiring the
DHCP server to count domains in order to find the start of a
potential second (concatenated) option.  Even this, while
cleaner to implement (a generic length-prefix container), would
likely require new code in some servers, so other implementors
should weigh in here.

 - Matt

---

From: <[email-masked]>
Date: Wed, 5 Oct 2011 08:14:34 +0000

Hi Matt,

Thank you for your comments, inline:

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of ext Matthew Ryan
> Sent: 05. lokakuuta 2011 01:12
> To: dhc WG
> Subject: Re: [dhcwg] Call for review: draft-ietf-mif-dns-server-selection-
> 04.txt
> 
> First, I note that the DHCPv6 version has the preference value occupying
the
> two most-significant bits of the octet in which they appear, while in the
> DHCPv4 version, they occupy the two least-significant bits.  No reason for
> this different is given that I can see, and I can't think of one of the
top of my
> head.
consistency's
> sake.

Good point, it is that way by accident and I will change for next rev. Which
one btw is better? Nicer to check in code if least-significant bits are
used, perhaps (0, 1, 2, 3 in decimal)?

> Second, the format of the DHCPv4 option as currently defined will almost
> certainly require special-case code in DHCP servers and management
> consoles to provide formatted display and config- uration (as opposed to
an
> opaque blob of hex), which will hinder its adoption.
> 
> Converting the "domain count" into a octet-length of the following fields
> (reserved/prf, address, domains-and-networks) would make it much simpler
> to parse, by not requiring the DHCP server to count domains in order to
find
> the start of a potential second (concatenated) option.  Even this, while
> cleaner to implement (a generic length-prefix container), would likely
require
> new code in some servers, so other implementors should weigh in here.

I'm not sure I fully get this concern. Why would not the option-len field be
suitable for that purpose?

Best regards,

	Teemu

---

From: Matthew Ryan <[email-masked]>
Date: Wed, 5 Oct 2011 10:18:55 -0700

Responses inline:

On Oct 5, 2011, at 01:14 , <[email-masked]> <[email-masked]> wrote:
[re: preference value positions in octets being different between v4 and v6]
> used, perhaps (0, 1, 2, 3 in decimal)?

Likely.

> suitable for that purpose?

DHCPv4 option concatenation is not a way to get multiple instances of
a given option, but rather a way to encode a /single/ instance that is
longer than 255 bytes.  I'll quote from David Hankins' option guidelines
draft [draft-ietf-dhc-option-guidelines-07]:

   DHCP software processing these fragments will concatenate them, in
   the order they appear as defined by [RFC2131], prior to evaluating
   their contents.  This is an important distinction that is sometimes
   overlooked by authors - these multiple options are not individually
   formatted to convey one unit of information precisely as you have
   defined, but rather one option that has been split along any arbitrary
   octet boundary into multiple containers.

What this boils down to is that, when a server or client is parsing
a packet, the contents of the multiple instances of your option will
be concatenated together into a single buffer, and then parsed according
to the expected content format, so the option-length octet is likely
not available to use as a marker.

The DHCPv4 version of your option should instead be defined as a list
of (reserved/pref, server address, domains-and-networks).  And, since
the domains-and-networks part is of indeterminate length, you need
a way to define the length of it, which is why you needed the domain
count field.  I suggested replacing domain count with an octet count
because it would be more general, and less likely to have the entire
option definition require custom code to implement, as there are no
other options I can think of at the moment which use the "DNS Wire
Format Domain Name List" format along with a count of domains elsewhere
in the option.  There are, on the other hand, several instances of
length-prefixed octet strings (RFC-3925, RFC-3004).

So, one possible way of defining this option would be (stealing
from RFC-3004):

   The format of this option is as follows:

        0                   1
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 
       +---------------+---------------+
       |  option-code  |   option-len  |
       +---------------+---------------+
       |                               |
       :         option-value          :
       |                               |
       +-------------------------------+

   where option-value consists of one or more instances of DNS
   Server Selection Data.  Each instance of DNS Server Selection
   Data is formatted as follows:

        0                   1
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     Len       | Reserved  |prf|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   DNS recursive name server   |
       |         (IPv4 address)        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                               |
       :     Domains and networks      :
       :      (variable length)        :
       +-------------------------------+
 
It is not lost on me that my proposed format also does not stay
within the option-guidelines draft, but it is easier to implement.

 - Matt

---

From: <[email-masked]>
Date: Mon, 10 Oct 2011 10:58:03 +0000

Hi,

> > Good point, it is that way by accident and I will change for next rev.
> > Which one btw is better? Nicer to check in code if least-significant
> > bits are used, perhaps (0, 1, 2, 3 in decimal)?
> 
> Likely.

Okay, will change that way.

> What this boils down to is that, when a server or client is parsing a
packet,
> the contents of the multiple instances of your option will be concatenated
> together into a single buffer, and then parsed according to the expected
> content format, so the option-length octet is likely not available to use
as a
> marker.
> 
> The DHCPv4 version of your option should instead be defined as a list of
> (reserved/pref, server address, domains-and-networks).  And, since the
> domains-and-networks part is of indeterminate length, you need a way to
> define the length of it, which is why you needed the domain count field.
I
> suggested replacing domain count with an octet count because it would be
> more general, and less likely to have the entire option definition require
> custom code to implement, as there are no other options I can think of at
> the moment which use the "DNS Wire Format Domain Name List" format
> along with a count of domains elsewhere in the option.  There are, on the
> other hand, several instances of length-prefixed octet strings (RFC-3925,
> RFC-3004).
> 
> So, one possible way of defining this option would be (stealing from RFC-
> 3004):
> 

Ok, I think I now see how this concatenation works.

But your proposal seems to describe suboption(s) within an option.. Not that
fun either - I noticed when implementing client for
draft-ietf-mif-dhcpv6-route-option.

How about following stealing of reserved bits? 

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       | Len of domains in oct |Res|prf|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            DNS-recursive-name-server (IPv4 address)           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ....

This would limit to single (possibly concatenated) option , though. If there
is need for backup DNS server configuration, then maybe this option should
include that as well, i.e:

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       | Len of domains in oct |Res|prf|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Primary DNS-recursive-name-server (IPv4 address)          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Secondary DNS-recursive-name-server (IPv4 address)        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| .....

?

Best regards,

Teemu

---

From: <[email-masked]>
Date: Mon, 17 Oct 2011 07:21:49 +0000

I need to update the draft quite soon, so I think I'll go for this approach
if no objections:

> |     Domains and networks  .....

The Option 6 (Domain Name Server Option)  of RFC1533 allows 1 or more domain
name server addresses, but for this option, for sake of simplicity, two
should suffice?

Maybe a question then would be, if there needs to be two IPv6 addresses for
DNS servers in the case of DHCPv6 option, or whether just single address is
enough there (and then have multiple option instances if multiple servers
need to be configured).

Best regards,

	Teemu

---

From: Danny Mayer <[email-masked]>
Date: Mon, 17 Oct 2011 07:26:29 -0400

> enough there (and then have multiple option instances if multiple servers

You need to support both IPv4 and IPv6 addresses here. This has nothing
whatsoever to do with DHCPv6.

Danny

---

From: Matthew Ryan <[email-masked]>
Date: Mon, 17 Oct 2011 06:10:18 -0700

Apologies for the delay in response...

> I need to update the draft quite soon, so I think I'll go for this approach

  This is guaranteed to require custom code to parse.  If you
truly believe users of this option will need to specify more
domains than will fit in 255 octets, then bump it to two octets;
this will be vastly easier to implement (and, thus more likely
to be implemented - and implemented /correctly/).

  Remember, though, that space in DHCPv4 packets is even more
limited than in DHCPv6.  Best case (assuming a MTU of 1500),
one has 1236 octets to use for options - but some of that is
needed for protocol options, relay agent options, and other
client configuration options.  Worst case, you have only 284
octets total, which means you almost certainly can not fit
more than 255 octets of domain names into the packet.

  Because of this, I would be inclined to leave len-of-domains
at one octet.

  You already note under Scalability Concerns that users should
chose the domains they want to use this for carefully due to space
limitations.  You should update this section to emphasize this
for DHCPv4.

 - Matt

---

From: <[email-masked]>
Date: Mon, 17 Oct 2011 13:18:45 +0000

> > Maybe a question then would be, if there needs to be two IPv6
> > addresses for DNS servers in the case of DHCPv6 option, or whether
> > just single address is enough there (and then have multiple option
> > instances if multiple servers need to be configured).
> 

How come? DNS servers' IPv6 addresses are configured via DHCPv6 option(s). I
don't think DHCPv4 option needs to convey IPv6 addresses for DNS servers.

	Teemu

---

From: <[email-masked]>
Date: Mon, 17 Oct 2011 13:28:05 +0000

Hi,

> From: ext Matthew Ryan [mailto:[email-masked]]
> Sent: 17. lokakuuta 2011 16:10
> To: Savolainen Teemu (Nokia-CTO/Tampere)
> Cc: [email-masked]
> > I need to update the draft quite soon, so I think I'll go for this
> > approach if no objections:
> >
> >> 0                   1                   2                   3
>   This is guaranteed to require custom code to parse.  If you truly
believe
> users of this option will need to specify more domains than will fit in
255
> octets, then bump it to two octets; this will be vastly easier to
implement
> (and, thus more likely to be implemented - and implemented /correctly/).

The scenarios I've seen include just few domains, but in order to prepare
for more.. so something like this perhaps? Is there need to align IPv4
addresses into 16 or 32-bit boundaries in DHCPv4 option? (if 16, then I'd
add one more reserved byte, or 3 to fit for 32 bit boundary).

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       |     Len of domains in oct     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved  |prf| Primary DNS-recursive-name-server IPv4 addr   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               | Secondary DNS-recursive-name-server           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 addr     |  Domains and networks  .....                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     .....

> Remember, though, that space in DHCPv4 packets is even more limited than
> in DHCPv6.  Best case (assuming a MTU of 1500), one has 1236 octets to use
> for options - but some of that is needed for protocol options, relay agent
> options, and other client configuration options.  Worst case, you have
only
> 284 octets total, which means you almost certainly can not fit more than
255
> octets of domain names into the packet.
>
>   Because of this, I would be inclined to leave len-of-domains at one
octet.

Hmm, I could easily agree also on placing that kind of limitation. Would it
be better then to go this road? But still 2 DNS server addresses like (and
this would fit much more nicely to 32-bit boundaries as well:

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       |   domains     |   Res     |prf|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Primary DNS-recursive-name-server IPv4 addr            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Secondary DNS-recursive-name-server                    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Domains and networks  .....                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     .....

>   You already note under Scalability Concerns that users should chose the
> domains they want to use this for carefully due to space limitations.  You
> should update this section to emphasize this for DHCPv4.

Good suggestion. I will.

	Teemu

---

From: Matthew Ryan <[email-masked]>
Date: Mon, 17 Oct 2011 07:01:09 -0700

> addresses into 16 or 32-bit boundaries in DHCPv4 option? (if 16, then I'd

There is no need to align on 16 or 32 bit boundaries; indeed,
even if you did, there's no guarantee that the server packing
your option would preserve any such alignment.

> this would fit much more nicely to 32-bit boundaries as well:

Assuming 'domains' is "length of domains in octets", then yes.

- Matt

---

From: <[email-masked]>
Date: Mon, 17 Oct 2011 14:35:40 +0000

> Assuming 'domains' is "length of domains in octets", then yes.

Yes, in octets (will clarify). Ok, I'll go with this approach and note the
limitations in length, if no other comments.

	Teemu

---

From: Ted Lemon <[email-masked]>
Date: Mon, 17 Oct 2011 15:08:11 +0000

On Oct 17, 2011, at 7:26 AM, Danny Mayer wrote:
You need to support both IPv4 and IPv6 addresses here. This has nothing
whatsoever to do with DHCPv6.

Can you provide a reason for this bizarre assertion?

---

From: Danny Mayer <[email-masked]>
Date: Tue, 18 Oct 2011 00:14:12 -0400

> don't think DHCPv4 option needs to convey IPv6 addresses for DNS servers.

So you prefer that not only do the people programming the clients have
to deal with two separate protocols to get both the IPv4 and IPv6
addresses you also condemn the admins of the dhcp servers to configure
this separately?

Danny

---

From: <[email-masked]>
Date: Tue, 18 Oct 2011 11:20:16 +0000

> >> You need to support both IPv4 and IPv6 addresses here. This has
> >> nothing whatsoever to do with DHCPv6.
> >
> > How come? DNS servers' IPv6 addresses are configured via DHCPv6
> > option(s). I don't think DHCPv4 option needs to convey IPv6 addresses
for
> DNS servers.
> >
> > 	Teemu
> 
> So you prefer that not only do the people programming the clients have to
> deal with two separate protocols to get both the IPv4 and IPv6 addresses
> you also condemn the admins of the dhcp servers to configure this
> separately?

That's the life in the DHCP-land, I'm afraid. It is also impossible, last
time I checked, to perform IPv6 stateful address autoconfiguration with
DHCPv4:-) 

	Teemu

---

From: Ted Lemon <[email-masked]>
Date: Tue, 18 Oct 2011 14:52:33 +0000

On Oct 18, 2011, at 12:14 AM, Danny Mayer wrote:
So you prefer that not only do the people programming the clients have
to deal with two separate protocols to get both the IPv4 and IPv6
addresses you also condemn the admins of the dhcp servers to configure
this separately?

They have to implement these protocols anyway.   A dual-stack DHCP protocol is out of scope.