Re: [Softwires] Last Call: <draft-ietf-softwire-4rd-08.txt> (IPv4 Residual Deployment via IPv6 - a Stateless Solution (4rd)) to Experimental RFC
Ted Lemon <Ted.Lemon@nominum.com> Fri, 26 September 2014 19:35 UTC
Return-Path: <Ted.Lemon@nominum.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A00A11A6EFB for <ietf@ietfa.amsl.com>; Fri, 26 Sep 2014 12:35:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.686
X-Spam-Level:
X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hs5YOzHJHtO9 for <ietf@ietfa.amsl.com>; Fri, 26 Sep 2014 12:35:08 -0700 (PDT)
Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCC481A01EE for <ietf@ietf.org>; Fri, 26 Sep 2014 12:35:08 -0700 (PDT)
Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id DEF1A1B864A for <ietf@ietf.org>; Fri, 26 Sep 2014 12:35:07 -0700 (PDT)
Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id D39E153E07B for <ietf@ietf.org>; Fri, 26 Sep 2014 12:35:07 -0700 (PDT)
Received: from [10.0.10.40] (71.233.43.215) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.195.1; Fri, 26 Sep 2014 12:35:07 -0700
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Subject: Re: [Softwires] Last Call: <draft-ietf-softwire-4rd-08.txt> (IPv4 Residual Deployment via IPv6 - a Stateless Solution (4rd)) to Experimental RFC
From: Ted Lemon <Ted.Lemon@nominum.com>
In-Reply-To: <20140926161017.19101.92744.idtracker@ietfa.amsl.com>
Date: Fri, 26 Sep 2014 15:34:47 -0400
Content-Transfer-Encoding: quoted-printable
Message-ID: <C7BC69BB-6AC8-4294-AC14-2D43493EF030@nominum.com>
References: <20140926161017.19101.92744.idtracker@ietfa.amsl.com>
To: ietf@ietf.org
X-Mailer: Apple Mail (2.1878.6)
X-Originating-IP: [71.233.43.215]
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/b9a4EWMud_KcWOqbxcTidsPLrS0
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Sep 2014 19:35:10 -0000
So this is a little bit embarrassing given that I just did my AD review of this document, but the way the DHCP options were done violates the recommendation in the DHCPv6 Option Guidelines document (RFC 7227) in that it uses suboption codes for the 4RD_MAP_RULE and 4RD_NON_MAP_RULE options, instead of treating OPTION_4RD as an encapsulating option, and the other two options as encapsulated options (see section 9 of RFC 7227).
o One DHCPv6 option codes TBD1 for OPTION_4RD of Section 4.9
respectively (to be added to section 24.3 of [RFC3315]. Suboption
values of 4RD_MAP_RULE (0) and 4RD_NON_MAP_RULE (1) should also be
recorded into the DHCPv6 option code space.
Also, the suboption configuration is expressed as a server requirement, when it's actually an operational requirement:
OLD:
o 4rd rule suboptions: the 4RD DHCPv6 option SHOULD contain at least
one 4RD_MAP_RULE suboption and maximum one 4RD_NON_MAP_RULE
suboption. the length of suboptions in octets
NEW:
o 4rd rule suboptions: the 4RD DHCPv6 option contains at least
one 4RD_MAP_RULE suboption and maximum one 4RD_NON_MAP_RULE
suboption. Since DHCP servers normally send whatever options
the operator configures, operators should be advised to
configure these options appropriately. DHCP servers MAY
check to see that the configuration follows these rules and
notify the operator in an implementation-dependent manner
if the settings for these options aren't valid.