Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcp4o6-saddr-opt-01.txt

"Bernie Volz (volz)" <volz@cisco.com> Wed, 17 January 2018 23:15 UTC

Return-Path: <volz@cisco.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 549C512EACC for <dhcwg@ietfa.amsl.com>; Wed, 17 Jan 2018 15:15:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.53
X-Spam-Level:
X-Spam-Status: No, score=-14.53 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 3sSoMto9CKDs for <dhcwg@ietfa.amsl.com>; Wed, 17 Jan 2018 15:15:26 -0800 (PST)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EED212EACA for <dhcwg@ietf.org>; Wed, 17 Jan 2018 15:15:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5783; q=dns/txt; s=iport; t=1516230926; x=1517440526; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=p+eRx5moyv4WVe5DrxqgpH+ihwnFEurFAw2T33dyRP0=; b=H90YdOiytQP7LphkZQrktfsXMGP0bSzTTbosIA8ZNFCrdVpHEIRsNJD8 CgmBlV+IXZcjG/lK4mrmMMAI70Aubnwe4AvfWpnioI5Euq/atjSp4xn/t ktdrcTNakmJr8M7d7hg6OZSg4VO4s3tfYNRK6Nf19MxIXGtgHg7AaAKLq A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BMAQB42F9a/5NdJa1cGQEBAQEBAQEBAQEBAQcBAQEBAYNBZnQnB44wjl6CApcughYKGA2BXIM6AoRkPxgBAQEBAQEBAQFrHQuFIwEBAQQBATgxAxcEAgEIEQQBAR8JBycLFAkIAgQTCAGKKhCpRolNAQEBAQEBAQEBAQEBAQEBAQEBAQEehlGDQIMugy8BAQIBAReBQIYSBaNsAogMjTyCImeFNotdiRaBVYJYiT8CERkBgTsBHzmBUG8VGSSCKgmETniLOYEXAQEB
X-IronPort-AV: E=Sophos;i="5.46,374,1511827200"; d="scan'208";a="342740976"
Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Jan 2018 23:15:17 +0000
Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id w0HNFHf0027793 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for <dhcwg@ietf.org>; Wed, 17 Jan 2018 23:15:17 GMT
Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 17 Jan 2018 17:15:16 -0600
Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1320.000; Wed, 17 Jan 2018 17:15:16 -0600
From: "Bernie Volz (volz)" <volz@cisco.com>
To: "dhcwg@ietf.org" <dhcwg@ietf.org>
Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-dhcp4o6-saddr-opt-01.txt
Thread-Index: AQHTc06pNykUpJzvTkWa7HHqUsOvG6N441Ww
Date: Wed, 17 Jan 2018 23:15:16 +0000
Message-ID: <db89bc5da65246c5b11c2de201c245a4@XCH-ALN-003.cisco.com>
References: <151308596470.20526.2736052080616451799@ietfa.amsl.com>
In-Reply-To: <151308596470.20526.2736052080616451799@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.98.1.196]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/qo3iGJ3wcxUPYkcviEoiW3KdDk4>
Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcp4o6-saddr-opt-01.txt
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dhcwg/>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Jan 2018 23:15:29 -0000

Hi:

I reviewed the updated draft and have a bunch of comments/issues.

Section 5 (figure and steps):

- Why is "/128 IPv6 software source address" used? Can the /128 be dropped? Isn't IPv6 address sufficient to denote what it is? Does the /128 care any significance above and beyond what "IPv6 address" would infer? (This is also used in other places in the document if I recall.)

- What happens if a DHCPNAK is sent by the server (perhaps the DHCPOFFERed address is no longer available)? This would also impact section 7.1 to add some discussion about DHCPNAK.

Section 6.1:

- "The field is padded on the right with zero bits up to the nearest octet boundary". Wouldn't "next octet boundary" be more correct? I guess you can't pad to less bits, so perhaps it "nearest" is OK? (i.e., if length is 41 the nearest is 40 if padded is ignored; 48 is what you'd want and so next would be cleaner?)

Section 6.2

- Option field definition ... "that the client has bound". If I understand correctly, this is sent in the DHCPREQUEST / (and DHCPACK). But until the client receives the DHCPACK, it probably hasn't bound to this yet. So, is "will bind" more appropriate than "has bound"? (Of course, in the renewal case the "has bound" is more correct.)

- I think in last paragraph, "DHCP-RESPONSE" should be "DHCPV4-RESPONSE"? There are 2 places that need to be fixed in the document.

Section 7

- "... client has already obtained a suitable IPv6 prefix to use for its local softwire endpoint using DHCPv6, SLAAC or another mechanism."

When SLAAC is referenced here it is a bit odd as SLAAC is for stateless addresses, not prefixes? But of course, there is the RFC 8273 (Unique IPv6 Prefix per Host) and draft-pioxfolks-6man-pio-exclusive-bit work. I would think you'd need the draft-pioxfolks-6man-pio-exclusive-bit draft to use this for this document so perhaps a reference to it? Or perhaps remove SLAAC if it really is a prefix that is needed?

Section 7.1

- As mentioned earlier, consider DHCPNAK implications?

Section 7.2.1

- Again, DHCPNAK could be returned by a server?

Section 7.4

- "The receiver MUST only use bits the bind-ipv6-prefix". I think from is missing "bits from the"?

Section 10

- Please improve the IANA considerations to specify the URL for the pages to update. This has been more recent practice to avoid any possible confusion. See https://tools.ietf.org/html/draft-ietf-dhc-access-network-identifier-13 as an example. Something like:

   IANA is requested to assign the OPTION_DHCP4O6_S46_SADDR option code from the
  "BOOTP Vendor Extensions and DHCP Options"  registry,
   <http://www.iana.org/assignments/bootp-dhcp-parameters>.

   IANA is requested to assign the OPTION_S46_BIND_IPV6_PREFIX option code from the
   DHCPv6 "Option Codes" registry,
   <http://www.iana.org/assignments/dhcpv6-parameters>.


Otherwise, the document looks pretty good (though I am not a softwires expert by any means!).

- Bernie

-----Original Message-----
From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org
Sent: Tuesday, December 12, 2017 8:39 AM
To: i-d-announce@ietf.org
Cc: dhcwg@ietf.org
Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcp4o6-saddr-opt-01.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Dynamic Host Configuration WG of the IETF.

        Title           : DHCPv4 over DHCPv6 Source Address Option
        Authors         : Ian Farrer
                          Qi Sun
                          Yong Cui
                          Linhui Sun
	Filename        : draft-ietf-dhc-dhcp4o6-saddr-opt-01.txt
	Pages           : 12
	Date            : 2017-12-12

Abstract:
   DHCPv4 over DHCPv6 is a mechanism for dynamically configuring IPv4
   over an IPv6-only network.  For DHCPv4 over DHCPv6 to function with
   some IPv4-over-IPv6 softwire mechanisms and deployment scenarios, the
   operator needs to know the /128 IPv6 address that the client will use
   as the source of IPv4-in-IPv6 softwire tunnel.  This address, in
   conjunction with the clients IPv4 address and (in some deployments),
   the Port Set ID are used to create a binding table entry in the
   operator's softwire tunnel concentrator.  This memo defines a DHCPv6
   option to convey IPv6 parameters for establishing the softwire tunnel
   and a DHCPv4 option (to be used only with DHCP 4o6) to communicate
   the source tunnel IPv6 address between the DHCP 4o6 client and
   server.  It is designed to work in conjunction with the IPv4 address
   allocation process.  This document updates "DHCPv6 Options for
   Configuration of Softwire Address and Port-Mapped Clients" to allow
   the DHCPv6 option OPTION_S46_BR(90) to appear outside of DHCPv6
   softwire container options.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcp4o6-saddr-opt/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-dhc-dhcp4o6-saddr-opt-01
https://datatracker.ietf.org/doc/html/draft-ietf-dhc-dhcp4o6-saddr-opt-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-dhcp4o6-saddr-opt-01


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg