[dhcwg] FW: dhcwg Digest, Vol 159, Issue 22
Srinivasa Rao Nalluri <srinivasa.rao.nalluri@ericsson.com> Wed, 26 July 2017 06:43 UTC
Return-Path: <srinivasa.rao.nalluri@ericsson.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 B4FED12702E for <dhcwg@ietfa.amsl.com>; Tue, 25 Jul 2017 23:43:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level:
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.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 K7JEadzGW3FP for <dhcwg@ietfa.amsl.com>; Tue, 25 Jul 2017 23:43:50 -0700 (PDT)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5F2A126E64 for <dhcwg@ietf.org>; Tue, 25 Jul 2017 23:43:47 -0700 (PDT)
X-AuditID: c1b4fb25-607ff70000001eeb-94-597839d48f40
Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.183.90]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 6A.C0.07915.4D938795; Wed, 26 Jul 2017 08:42:28 +0200 (CEST)
Received: from EUR01-HE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.90) with Microsoft SMTP Server (TLS) id 14.3.352.0; Wed, 26 Jul 2017 08:42:28 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=whS/96usrvv4aKK7w+dyIudFNbRhQnEgGWfhiF9Ppn4=; b=SNjqtiYgdUhQchgmqiW6UeLGT0ZSjhLgrgkjuPECnSY2DyUW8Uw15e331AFn+KRVcYfVUrQ9lX8+Uc6biJHXkGiPfVxFg7cMuAmolchmCZaIgV78cYZ7L9g3KFwrveS5BE0l0FkRwiZ2az5B8dmeEjOFkp/bapL9PTVfyYHsKXs=
Received: from HE1PR0701MB1914.eurprd07.prod.outlook.com (10.167.189.18) by HE1PR0701MB3017.eurprd07.prod.outlook.com (10.168.93.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.4; Wed, 26 Jul 2017 06:42:26 +0000
Received: from HE1PR0701MB1914.eurprd07.prod.outlook.com ([fe80::50b1:365c:d036:e911]) by HE1PR0701MB1914.eurprd07.prod.outlook.com ([fe80::50b1:365c:d036:e911%14]) with mapi id 15.01.1304.014; Wed, 26 Jul 2017 06:42:26 +0000
From: Srinivasa Rao Nalluri <srinivasa.rao.nalluri@ericsson.com>
To: "Francis.Dupont@fdupont.fr" <Francis.Dupont@fdupont.fr>, "dhcwg@ietf.org" <dhcwg@ietf.org>
Thread-Topic: dhcwg Digest, Vol 159, Issue 22
Thread-Index: AQHTAHve9RdlKtkrV0yJA9DvRXG64qJlpl/Q
Date: Wed, 26 Jul 2017 06:42:26 +0000
Message-ID: <HE1PR0701MB1914DC2079769AD098E30856DEB90@HE1PR0701MB1914.eurprd07.prod.outlook.com>
References: <mailman.2482.1500460965.4234.dhcwg@ietf.org>
In-Reply-To: <mailman.2482.1500460965.4234.dhcwg@ietf.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=srinivasa.rao.nalluri@ericsson.com;
x-originating-ip: [125.16.128.122]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; HE1PR0701MB3017; 7:Hu477ly3U3JPfxzKWaLfTbtTuyv15nx9HVUvY/PZzrvm0TCznPzcbUjTiZC9OpMf37+f+uoUQhdMWHsGw5cPm6IBQeTj+/lHs4I66wpcL0fA7sFqOmicwuUIcvylYU0i1BucK/BdFcSkp3Jo9jGomiDGRthXdF4F1JM7qWmvqjKs7G38wdBvf8iP/L8h6fd8pyDwSFtzK+oHLsTQVeMsvydo3yWSOYHndlu6OhQ47R0wgwqOoluKSCljVV93ysgd4QzTsxSroqGJi61Fi26Lix1+ljoozSv1YJmt21RVOUOCAGXjM2CyPWPjB0DB0pAKI0Qby0l76z5VWuleB0RqyqWGb3EIBEnlTDnwKKJHoJwJG/N6LA/BnyfpgEKdFesPZdAMtjg6XihtuyhZqFserPXjfoihMB+sMdEQx6JEK4rXWqLkOGy5nXzhA34hmf/aRvpDhwsrBnx8QHnU8b/JD94hg51BxnrC2dRJZckb+loAP1qm9eOYzehdQaB/WqzFr7MPs7xsedlfsOSGP0hbv3dWj+VmJYmeLA0KZgl390PXyL4DVGE5o6xJK5q9JBEXi64xq03ks12to5cNAZA17H5jrVMq2F0UWE/WJ4sPf3ZFUd1ClonpASSpdLjBs01oIBdH6/9vjYPrIA6N12yilYho/M7P5EOZmrQTNyY8BGOQi4P+6xcwndV3HWHhP0bTh46qFYvw31BKtvGMoe2nzzznK5TYEd7iVtdtXmN5R1/+zcb+X6Upf4jeTAGBAGf8LD/JR6r36S3mvlB6ziTTvJzLXmzT4/W1nRadRZuZnDs=
x-ms-office365-filtering-correlation-id: 64ca8dfb-091f-4020-6a75-08d4d3f17aa5
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(300000502095)(300135100095)(22001)(2017030254075)(300000503095)(300135400095)(2017052603031)(49563074)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:HE1PR0701MB3017;
x-ms-traffictypediagnostic: HE1PR0701MB3017:
x-exchange-antispam-report-test: UriScan:(158342451672863)(98791786084576)(95692535739014);
x-microsoft-antispam-prvs: <HE1PR0701MB30176A47EDBC6D2FC29A3B8BDEB90@HE1PR0701MB3017.eurprd07.prod.outlook.com>
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(102415395)(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(10201501046)(100000703101)(100105400095)(6041248)(20161123564025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123560025)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:HE1PR0701MB3017; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:HE1PR0701MB3017;
x-forefront-prvs: 038002787A
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39860400002)(39400400002)(39850400002)(39410400002)(39450400003)(39840400002)(18543002)(199003)(13464003)(377454003)(27574002)(5403001)(189002)(10533003)(24454002)(9686003)(5250100002)(575784001)(512874002)(6436002)(99286003)(99936001)(55016002)(76176999)(7696004)(6506006)(5660300001)(6306002)(2473003)(6116002)(2950100002)(3846002)(102836003)(38730400002)(50986999)(97736004)(189998001)(966005)(53936002)(54356999)(86362001)(66066001)(14454004)(105586002)(101416001)(2906002)(33656002)(25786009)(53546010)(106356001)(7736002)(3280700002)(74316002)(8676002)(2900100001)(81156014)(3660700001)(478600001)(8936002)(81166006)(2501003)(68736007)(5890100001)(345774005)(305945005)(229853002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB3017; H:HE1PR0701MB1914.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="SHA1"; boundary="----=_NextPart_000_03D1_01D30608.70AB35D0"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jul 2017 06:42:26.1978 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB3017
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA02SeUhUURTGufMWn9LQa9I8WJJNCipqboGZhAalEEIEhQukY16XckaZZ6YS oWgqmmiipmO4gJlaisuQZSBpWpmRjjHhSjpqo1bmQkqm1cy8F/Tf75zvu9/hHC5DSAYoGyZe kYyVClmClLYgK0O6wlztfFND3cf1Ep/pvGzkoyt/RvmLglbKdqig+vqfovOiMAu/aJwQn4KV x05FWsTtjmyjpLZ2lDq32ENloMkylI/MGWC9Yaz6nYEtGAnbjyB3qMKML94g+JHfTRsLki0k YKmmiOYVlQjUpRmCTY9APVpNGMNo1h/KyxdoI1uykdA0nmlm5P2sC7TeySX5viv0br4X2BOW N/MoI5OsA2jb7pn6YsPb5plVE0vYEzDTmGnymLO+sLW7bpqF2AOw9faxyMgEaw0T8zUifiFL mNUM0TxbwdLcb4r3Y6h6PUbwfSl0Vi4KflsYrSkwHQBYHQ0abYtwmWCY7swieWFFBBXazxQv uIBqd1HgcNCO5AipiaArGxKSNBQUb/QJIw7BzsCWYNqkYeOVE78ahoctt1Exclb9t4XK8J5g CxGM73YQKtM59sFg5TypQoxBcIOcdsT7D0PXt/sEzyehYruX5vkIlBbMmvF8HL4MrKFaxDQj Kw5zUfJYTy83rIy/wnGJCjcFTu5Ahg/Vq/7l8BR9+BrQh1gGSfeI+z1TQyWULIVLk/che0OO ru3RCLIhFYkKLLUUt3sbZHG0LC0dKxMjlNcTMNeHDjKk1Foc0DMSImFjZcn4GsZJWPlPFTHm Nhno9C11bEFJZwu+obkaeNlrqkFiV9eUaaV44PF9L+fUEDNEz1z8Iw7P1To6Zkc76Gp98N0S fWArQ6tmp87o5aNWw5F17cPBWc/DjtZEXJJ0mz851+i+tnw2asA+q+rm6sTkp6QXtoMLDhde iuVFcr+J+manuHRdnnXMLLH+0XamWUpycTIPZ0LJyf4CYnIFSVgDAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/Muoo2CvCCWLQPEUEpIRnLATUp2o>
Subject: [dhcwg] FW: dhcwg Digest, Vol 159, Issue 22
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, 26 Jul 2017 06:43:54 -0000
Hi Francis, Thank you for review and comments. Please see my response inline prefixed with [Srinivas] I red draft-nalluri-dhc-dhcpv6-lwm2m-bootstrap-options-02.txt (it is in the agenda this afternnon) and I found two loose references to RFC 7296 (IKEv2) section 3.6 (CERT payload). I have two concerns about this: - certificates can be very large, at least larger than a DHCPv4 option can carry [Srinivas] We already have an RFC that talks about encoding larger content in DHCPv4 option. So, I mentioned following in section 4. "Maximum possible value of DHCPv4 "option-len" is 255. LWM2M-server-certificate MAY be of length more than 255. To accommodate larger certificate, DHCP server SHOULD follow encoding as mentioned in [RFC3396]." - as IKEv2 is over UDP too this problem is addressed in RFC 7296 by allowing many different "encodings" (currently 15 in the IANA registry). So I am afraid authors just took a good text about certificate transport (BTW I'd pick the same one so my concern is not about the choice) but missed to add an additional statement about application. I propose: - add something about the encoding byte so nobody will forget to read RFC 7296 and for instance put a X.509 certificate as the whole content [Srinivas] I need a bit more clarity on this comment. Encoding byte is explained in RFC 7296. It will be same even if we explain in our draft. Is that ok to repeat details of "cert encoding" byte of section 3.6, RFC7296? Or Do you say that option format defined in section 3.2 "DHCPv6 option for LWM2M server certificate" should include "cert encoding" byte and same should be explicitly explained in our draft? I see later makes more sense. - make a few encodings mandatory to support (*) [Srinivas] I will check what formats/encodings make more sense in LWM2M deployments and I will add them as mandatory list in next version of draft. Thanks Srinivas -----Original Message----- From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of dhcwg-request@ietf.org Sent: Wednesday, July 19, 2017 4:13 PM To: dhcwg@ietf.org Subject: dhcwg Digest, Vol 159, Issue 22 Send dhcwg mailing list submissions to dhcwg@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/dhcwg or, via email, send a message with subject or body 'help' to dhcwg-request@ietf.org You can reach the person managing the list at dhcwg-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of dhcwg digest..." Today's Topics: 1. draft-moses-dmm-dhcp-ondemand-mobility - minor comments. (W?odzimierz Wencel) 2. Re: I-D Action: draft-ietf-dhc-rfc3315bis-09.txt - questions about Solicit Prefix Delegation (Alexandre Petrescu) 3. Re: I-D Action: draft-ietf-dhc-rfc3315bis-09.txt - questions about Solicit Prefix Delegation (Ted Lemon) 4. Re: I-D Action: draft-ietf-dhc-rfc3315bis-09.txt - questions about Solicit Prefix Delegation (Alexandre Petrescu) 5. about draft-nalluri-dhc-dhcpv6-lwm2m-bootstrap-options-02.txt (Francis Dupont) ---------------------------------------------------------------------- Message: 1 Date: Wed, 19 Jul 2017 11:02:23 +0200 From: W?odzimierz Wencel <wlodek@isc.org> To: dhcwg@ietf.org Subject: [dhcwg] draft-moses-dmm-dhcp-ondemand-mobility - minor comments. Message-ID: <5e618d45-5290-69e1-5c2d-e94de0c69e19@isc.org> Content-Type: text/plain; charset="utf-8" There are two minor issues in the draft. 1. in section 3 and section 4 usage of status code NoAddrsAvail should be replaced with NoPrefixAvail 2. Anchor Preference Option should be formatted as IA Prefix Option (3315): - valid-lifetime value is missing - ip6-prefix should have fixed length to keep it easy to parse instead of: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_ANCHOR_PREFERENCE | option-length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | preferred-lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | prefix6len | ipv6-prefix | +-+-+-+-+-+-+-+-+ (variable length) | . . |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IAanchor_preference-options | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ should be: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_ANCHOR_PREFERENCE | option-length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | preferred-lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | valid-lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | prefix6len | ipv6-prefix | +-+-+-+-+-+-+-+-+ (16 octets) | . . |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IAanchor_preference-options | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Thanks, W?odek Wencel ISC -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://mailarchive.ietf.org/arch/browse/dhcwg/attachments/20170719/3b6a1f2 4/attachment.html> ------------------------------ Message: 2 Date: Wed, 19 Jul 2017 11:10:25 +0200 From: Alexandre Petrescu <alexandre.petrescu@gmail.com> To: Ted Lemon <mellon@fugue.com>, V?zdal Ale? <ales.vizdal@t-mobile.cz> Cc: dhcwg <dhcwg@ietf.org>, "Bernie Volz (volz)" <volz@cisco.com> Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-rfc3315bis-09.txt - questions about Solicit Prefix Delegation Message-ID: <56aee165-9dd3-7633-a3bb-9d62b469b48a@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Ted, Let me explain. I no longer have a request for the spec 3315bis. Sorry for the intrusion. Le 18/07/2017 ? 11:07, Ted Lemon a ?crit : > He later said that he'd observed this behavior when using the ISC > DHCP client. My theory is that this is an artifact of the way the > ISC DHCP client transmits packets on the network, and not a problem > with the tunneling protocol. It would be nice to validate that > conjecture. We work on this conjencture, but it takes time, because it involves many people, I am the only who speaks, and some times wrongly. Now I prefer to stay silent until I get some resolution to talk about. Until then, all I can say is that I have packet dumps that show encapsulation, and ICMP hoplimit exceeded, and that the DHCP Solicit had hoplimit 1. It is however not clear whether or not that's anybody's fault. This is not a matter of someone's fault; the goal is to make it work. I am sorry for the confusion this may have created. Alex ------------------------------ Message: 3 Date: Wed, 19 Jul 2017 11:52:35 +0200 From: Ted Lemon <mellon@fugue.com> To: Alexandre Petrescu <alexandre.petrescu@gmail.com> Cc: V?zdal Ale? <ales.vizdal@t-mobile.cz>, dhcwg <dhcwg@ietf.org>, "Bernie Volz (volz)" <volz@cisco.com> Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-rfc3315bis-09.txt - questions about Solicit Prefix Delegation Message-ID: <CAPt1N1mDcKo5G19t38HcNh_WErYg8n0yswy-Wk7QCL26mpwFeg@mail.gmail.com> Content-Type: text/plain; charset="utf-8" No worries. Have you tried compiling with USE_SOCKETS? Does that produce the same result? On Wed, Jul 19, 2017 at 11:10 AM, Alexandre Petrescu < alexandre.petrescu@gmail.com> wrote: > Ted, > > Let me explain. I no longer have a request for the spec 3315bis. > Sorry for the intrusion. > > Le 18/07/2017 ? 11:07, Ted Lemon a ?crit : > >> He later said that he'd observed this behavior when using the ISC DHCP >> client. My theory is that this is an artifact of the way the ISC DHCP >> client transmits packets on the network, and not a problem with the >> tunneling protocol. It would be nice to validate that conjecture. >> > > We work on this conjencture, but it takes time, because it involves > many people, I am the only who speaks, and some times wrongly. Now I > prefer to stay silent until I get some resolution to talk about. > > Until then, all I can say is that I have packet dumps that show > encapsulation, and ICMP hoplimit exceeded, and that the DHCP Solicit > had hoplimit 1. It is however not clear whether or not that's anybody's fault. > > This is not a matter of someone's fault; the goal is to make it work. > > I am sorry for the confusion this may have created. > > Alex > -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://mailarchive.ietf.org/arch/browse/dhcwg/attachments/20170719/aad17a7 6/attachment.html> ------------------------------ Message: 4 Date: Wed, 19 Jul 2017 11:57:49 +0200 From: Alexandre Petrescu <alexandre.petrescu@gmail.com> To: Ted Lemon <mellon@fugue.com> Cc: V?zdal Ale? <ales.vizdal@t-mobile.cz>, dhcwg <dhcwg@ietf.org>, "Bernie Volz (volz)" <volz@cisco.com> Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-rfc3315bis-09.txt - questions about Solicit Prefix Delegation Message-ID: <bf368c54-29a5-3384-00ea-f397d0213939@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Le 19/07/2017 ? 11:52, Ted Lemon a ?crit : > No worries. Have you tried compiling with USE_SOCKETS? Does that > produce the same result? Yes and results are different but still not satisfactorily overall. (FWIW #define USE_SOCKETS 1 goes in build/includes/config.h) Alex > > On Wed, Jul 19, 2017 at 11:10 AM, Alexandre Petrescu > <alexandre.petrescu@gmail.com <mailto:alexandre.petrescu@gmail.com>> wrote: > > Ted, > > Let me explain. I no longer have a request for the spec 3315bis. Sorry > for the intrusion. > > Le 18/07/2017 ? 11:07, Ted Lemon a ?crit : > > He later said that he'd observed this behavior when using the > ISC DHCP client. My theory is that this is an artifact of the > way the ISC DHCP client transmits packets on the network, and > not a problem with the tunneling protocol. It would be nice to > validate that conjecture. > > > We work on this conjencture, but it takes time, because it involves many > people, I am the only who speaks, and some times wrongly. Now I prefer > to stay silent until I get some resolution to talk about. > > Until then, all I can say is that I have packet dumps that show > encapsulation, and ICMP hoplimit exceeded, and that the DHCP Solicit had > hoplimit 1. It is however not clear whether or not that's anybody's > fault. > > This is not a matter of someone's fault; the goal is to make it work. > > I am sorry for the confusion this may have created. > > Alex > > ------------------------------ Message: 5 Date: Wed, 19 Jul 2017 12:26:08 +0200 From: Francis Dupont <Francis.Dupont@fdupont.fr> To: dhcwg@ietf.org Subject: [dhcwg] about draft-nalluri-dhc-dhcpv6-lwm2m-bootstrap-options-02.txt Message-ID: <201707191026.v6JAQ8Wx034118@givry.fdupont.fr> I red draft-nalluri-dhc-dhcpv6-lwm2m-bootstrap-options-02.txt (it is in the agenda this afternnon) and I found two loose references to RFC 7296 (IKEv2) section 3.6 (CERT payload). I have two concerns about this: - certificates can be very large, at least larger than a DHCPv4 option can carry - as IKEv2 is over UDP too this problem is addressed in RFC 7296 by allowing many different "encodings" (currently 15 in the IANA registry). So I am afraid authors just took a good text about certificate transport (BTW I'd pick the same one so my concern is not about the choice) but missed to add an additional statement about application. I propose: - add something about the encoding byte so nobody will forget to read RFC 7296 and for instance put a X.509 certificate as the whole content - make a few encodings mandatory to support (*) Thanks Francis.Dupont@fdupont.fr PS (*): if it makes sense in environments where LWM2M is/will be deployed I highly recommend the hash and URL formats. BTW they were introduced in IKEv2 so in RFC 7296 a notify was added to indicate support. This is no necessary for this I-D and of course it avoids large payload problems (it was designed with this goal). ------------------------------ Subject: Digest Footer _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg ------------------------------ End of dhcwg Digest, Vol 159, Issue 22 **************************************
- [dhcwg] FW: dhcwg Digest, Vol 159, Issue 22 Srinivasa Rao Nalluri
- Re: [dhcwg] FW: dhcwg Digest, Vol 159, Issue 22 Francis Dupont