[mif] How long domains and networks field is required for DHCPv4 DNS server select option

<teemu.savolainen@nokia.com> Thu, 20 October 2011 05:44 UTC

Return-Path: <teemu.savolainen@nokia.com>
X-Original-To: mif@ietfa.amsl.com
Delivered-To: mif@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 7700F11E8085 for <mif@ietfa.amsl.com>; Wed, 19 Oct 2011 22:44:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id CBl0i3z9YxDk for <mif@ietfa.amsl.com>; Wed, 19 Oct 2011 22:44:28 -0700 (PDT)
Received: from mgw-da01.nokia.com (smtp.nokia.com []) by ietfa.amsl.com (Postfix) with ESMTP id B51DE11E807F for <mif@ietf.org>; Wed, 19 Oct 2011 22:44:28 -0700 (PDT)
Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com []) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p9K5iOct027577; Thu, 20 Oct 2011 08:44:27 +0300
Received: from smtp.mgd.nokia.com ([]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 20 Oct 2011 08:44:20 +0300
Received: from 008-AM1MMR1-001.mgdnok.nokia.com ( by NOK-AM1MHUB-04.mgdnok.nokia.com ( with Microsoft SMTP Server (TLS) id; Thu, 20 Oct 2011 07:44:19 +0200
Received: from 008-AM1MPN1-037.mgdnok.nokia.com ([]) by 008-AM1MMR1-001.mgdnok.nokia.com ([]) with mapi id 14.01.0339.002; Thu, 20 Oct 2011 07:44:14 +0200
From: teemu.savolainen@nokia.com
To: mif@ietf.org
Thread-Topic: How long domains and networks field is required for DHCPv4 DNS server select option
Thread-Index: AQHMjur5NBeT3WUzF0GquxdFNFZq1w==
Date: Thu, 20 Oct 2011 05:44:14 +0000
Message-ID: <916CE6CF87173740BC8A2CE44309696203783C97@008-AM1MPN1-037.mgdnok.nokia.com>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 20 Oct 2011 05:44:20.0156 (UTC) FILETIME=[503D5FC0:01CC8EEB]
X-Nokia-AV: Clean
Cc: Matt.Ryan@nominum.com
Subject: [mif] How long domains and networks field is required for DHCPv4 DNS server select option
X-BeenThere: mif@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiple Interface Discussion List <mif.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mif>, <mailto:mif-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mif>
List-Post: <mailto:mif@ietf.org>
List-Help: <mailto:mif-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mif>, <mailto:mif-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 20 Oct 2011 05:44:29 -0000

Hi Mif,

Is it enough to have 246 octets to describe the domains and networks fields in the case of DHCPv4, or do you want to have possibility for longer list of domains? 

We are discussing at the DHC WG what would be the optimal format for the DHCPv4 option, and the decisions depend on how much domains and networks information is needed in the case of DHCPv4. If we agree that 246 octets is enough, we can design far simpler DHCPv4 option than otherwise.

I prefer the simpler way even though it is more limited in size, as I don't really see need to go beyond that.

Best regards,


From: ext Matthew Ryan [Matt.Ryan@nominum.com]
Sent: Thursday, October 20, 2011 1:45 AM
To: Savolainen Teemu (Nokia-CTO/Tampere)
Cc: dhcwg@ietf.org
Subject: Re: [dhcwg] [mif] 2nd Last Call for MIF DNS server selection document

On Oct 19, 2011, at 14:03 , <teemu.savolainen@nokia.com> <teemu.savolainen@nokia.com> wrote:

> No, we decided against suboptions and concatenation as well - to just have single option and strictly limit the lenght of the domains-field. If I recall correctly, it was due DHCPv4 relays in some cases limiting the available DHCPv4 message size.. That's why the latest version is changed in so many locations related to this issue.
> Ok on alignment issue.
> Could we then remove the second length field and hence gain one additional byte for domains variable lenght field?

That seems strange to me, since the DHPCv6 version is able
to specify multiple redirections.  It's beyond the scope of
DHCP, so I can only assume that the other WG(s) decided
the feature wasn't necessary for IPv4 networks, but is
still necessary for IPv6 networks.

If that is indeed the case, then yes, you can just remove the
payload length octet from section 4.3 in draft -06.

 - Matt