[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>om>, V?zdal Ale?
	<ales.vizdal@t-mobile.cz>
Cc: dhcwg <dhcwg@ietf.org>rg>, "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>cz>, dhcwg <dhcwg@ietf.org>rg>,
	"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>cz>, dhcwg <dhcwg@ietf.org>rg>,
	"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
**************************************