Re: [dhcwg] 3315bis (RFC8415) - Thanks to all!!
"Bernie Volz (volz)" <volz@cisco.com> Tue, 18 December 2018 21:20 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 82F8C130F63 for <dhcwg@ietfa.amsl.com>; Tue, 18 Dec 2018 13:20:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.564
X-Spam-Level:
X-Spam-Status: No, score=-14.564 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.065, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 I1BbKhmRiPGw for <dhcwg@ietfa.amsl.com>; Tue, 18 Dec 2018 13:20:53 -0800 (PST)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 512E61292F1 for <dhcwg@ietf.org>; Tue, 18 Dec 2018 13:20:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=31392; q=dns/txt; s=iport; t=1545168053; x=1546377653; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=H6yk01/k9sMilLpddLn1k0GGopkpXU2hk/j+Rod8kIA=; b=XABCQLpfh3cSTlNxYnzIO2PNMFHmtEdiAJX+lZBe4bDnr88TGfzQuvbe PXgaNDSdkScEjm4URohSkI+OhTgztV4UTexohgeVRRIdgfHfIhBev/GSA 7i5G5+pzDtzWa0Xw9F6lhsYgly9yMETZv+6kBJ8bVi1JbV1DVfmR4Tyf5 A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0ADAABGYxlc/5BdJa1jGQEBAQEBAQEBAQEBAQcBAQEBAQGBUQQBAQEBAQsBgQ1NKWaBAicKg3OIGYt7gg2JFY5FgXsLAQEjhEkCF4JEIjQJDQEDAQECAQECbRwMhTwBAQEEIwpMEAIBCBEEAQEhBwMCAgIfERQJCAEBBA4FCIMbgRxMAxUPpxyBL4RBQIMCDYIYBYw/F4F/gRABgxKBQYEWRwIDAYFkBwkPEIJSglcCjzqROjAJAocNhyCDKSCBXYUfgzGHKoMJizKBEol/AhEUgScfOIFWcBWDJ4M9AQiHVoU/QTEBjUeBHwEB
X-IronPort-AV: E=Sophos;i="5.56,370,1539648000"; d="scan'208,217";a="215026292"
Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Dec 2018 21:20:52 +0000
Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by rcdn-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id wBILKpjW024194 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 18 Dec 2018 21:20:51 GMT
Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 18 Dec 2018 15:20:51 -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.1395.000; Tue, 18 Dec 2018 15:20:50 -0600
From: "Bernie Volz (volz)" <volz@cisco.com>
To: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>
CC: "dhcwg@ietf.org" <dhcwg@ietf.org>, Ralph Droms <rdroms.ietf@gmail.com>
Thread-Topic: 3315bis (RFC8415) - Thanks to all!!
Thread-Index: AdSHVHuxUve/ZLJHTKme2uv0Tm245APFyPlAAABcXbQAJJKaoAAF+khg
Date: Tue, 18 Dec 2018 21:20:50 +0000
Message-ID: <2223128111fd4d938c502c8dd279587e@XCH-ALN-003.cisco.com>
References: <f5aa4f0dde51481da312accbd1882c09@XCH-ALN-003.cisco.com>, <e92109fc30874a4f95a3d3441db5feb3@boeing.com> <402FDE5D-6D1C-4C3B-9ECA-510DAE1580FB@cisco.com> <8f077b6a37c0497a81df5f60bb8c6661@boeing.com>
In-Reply-To: <8f077b6a37c0497a81df5f60bb8c6661@boeing.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.131.33.58]
Content-Type: multipart/alternative; boundary="_000_2223128111fd4d938c502c8dd279587eXCHALN003ciscocom_"
MIME-Version: 1.0
X-Outbound-SMTP-Client: 173.37.102.14, xch-rcd-004.cisco.com
X-Outbound-Node: rcdn-core-8.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/SvJXix77qKEjKI1JFPodgwaR8ng>
Subject: Re: [dhcwg] 3315bis (RFC8415) - Thanks to all!!
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 18 Dec 2018 21:20:56 -0000
With a quick read and look at the context in the draft, seems OK to me. You do articulate the issues if the prefix were assigned. - Bernie From: Templin (US), Fred L <Fred.L.Templin@boeing.com> Sent: Tuesday, December 18, 2018 2:48 PM To: Bernie Volz (volz) <volz@cisco.com> Cc: dhcwg@ietf.org; Ralph Droms <rdroms.ietf@gmail.com> Subject: RE: 3315bis (RFC8415) - Thanks to all!! Hi Bernie, We have such an operational document aligned with v6ops: https://datatracker.ietf.org/doc/draft-templin-v6ops-pdhost/ Here is the text that speaks to this subject (where “the node” refers to the DHCPv6 PD requesting router/client and “the prefix” refers to the delegated prefix): “In a second alternative, the node can assign as many addresses as it wants from the prefix to the upstream interface over which the prefix was received, but in normal practice does not assign the prefix itself (or subnets from the prefix) to the upstream interface. If the node assigned the prefix to the upstream interface, any neighbors on the upstream link receiving an RA could configure addresses from the prefix and a default route with the node as the next hop. This could create a loop where upstream link neighbors send packets to the node which in turn forwards them to another upstream link neighbor. Still, there may be cases where the node provides services for dependent neighbors on the upstream link that have no other means of connecting to the network. ([RFC8415] chose to remain silent on this subject since it is operational rather than functional in nature.)” How does this look? Thanks - Fred From: Bernie Volz (volz) [mailto:volz@cisco.com] Sent: Monday, December 17, 2018 5:00 PM To: Templin (US), Fred L <Fred.L.Templin@boeing.com<mailto:Fred.L.Templin@boeing.com>> Cc: dhcwg@ietf.org<mailto:dhcwg@ietf.org>; Ralph Droms <rdroms.ietf@gmail.com<mailto:rdroms.ietf@gmail.com>> Subject: Re: 3315bis (RFC8415) - Thanks to all!! Thanks ... it was a major effort by many - including you! Regarding your questions, I believe it is the “Or, is it the case that RFC8415 simply chose to remain silent on the subject and leave it to other documents of a more operational nature to deal with the subject?” - Bernie On Dec 17, 2018, at 7:56 PM, Templin (US), Fred L <Fred.L.Templin@boeing.com<mailto:Fred.L.Templin@boeing.com>> wrote: Bernie, Congratulations on seeing this important work through to successful publication! I do have one question regarding prefix delegation: in RFC3633, it says: “Upon the receipt of a valid Reply message, for each IA_PD the requesting router assigns a subnet from each of the delegated prefixes to each of the links to which the associated interfaces are attached, with the following exception: the requesting router MUST NOT assign any delegated prefixes or subnets from the delegated prefix(es) to the link through which it received the DHCP message from the delegating router.” Unless I missed it, I do not see the same “MUST NOT” in RFC8415. What can we infer from this? Does it mean that it is now OK for the RR to assign the prefix to the upstream link? Or, is it the case that RFC8415 simply chose to remain silent on the subject and leave it to other documents of a more operational nature to deal with the subject? Thanks in advance, Fred From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Bernie Volz (volz) Sent: Wednesday, November 28, 2018 12:02 PM To: dhcwg@ietf.org<mailto:dhcwg@ietf.org> Cc: Ralph Droms <rdroms.ietf@gmail.com<mailto:rdroms.ietf@gmail.com>> Subject: [dhcwg] 3315bis (RFC8415) - Thanks to all!! Hi: It was great to finally see the multi-year effort on 3315bis be published (RFC8415). draft-dhcwg-dhc-rfc3315bis-00 was published January 2014. My guess is that this has taken about 5 years as work began a few months prior to convert RFC3315 text into an XML to produce this first document. Thanks to the co-authors, Ralph Droms (as document shepherd), the many reviewers for their feedback, and the WG in supporting the effort. And, to the RFC-Editor in their work to finalize the document. But … We’re not done yet, as hopefully we’ll work to advance DHCPv6 to full standard – hopefully that will be a much smaller (and shorter) effort!! If you do find issues or areas of concern as you reference the document (and please start using it instead of 3315!), please be sure to file an errata or at least drop the co-authors a note. Again, thanks for everyone’s efforts!! - Bernie Volz
- [dhcwg] 3315bis (RFC8415) - Thanks to all!! Bernie Volz (volz)
- Re: [dhcwg] 3315bis (RFC8415) - Thanks to all!! Templin (US), Fred L
- Re: [dhcwg] 3315bis (RFC8415) - Thanks to all!! Bernie Volz (volz)
- Re: [dhcwg] 3315bis (RFC8415) - Thanks to all!! Templin (US), Fred L
- Re: [dhcwg] 3315bis (RFC8415) - Thanks to all!! Bernie Volz (volz)
- Re: [dhcwg] 3315bis (RFC8415) - Thanks to all!! Roy Marples
- Re: [dhcwg] 3315bis (RFC8415) - Thanks to all!! Templin (US), Fred L