Re: [v6ops] Iotdir last call review of draft-ietf-v6ops-nd-cache-init-05

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Tue, 15 September 2020 10:52 UTC

Return-Path: <pthubert@cisco.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DA3D3A0EED; Tue, 15 Sep 2020 03:52:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -11.92
X-Spam-Level:
X-Spam-Status: No, score=-11.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 header.b=mURsijHS; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=iao4cN0f
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 u039csfY2U47; Tue, 15 Sep 2020 03:52:56 -0700 (PDT)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 765D13A0EEB; Tue, 15 Sep 2020 03:52:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16184; q=dns/txt; s=iport; t=1600167176; x=1601376776; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=5H5Md8OU2vPkpkTUipLuvlOYxei0rfN7fW8ML69pX2w=; b=mURsijHSTBC7uZaRs2ogCBcPLWraA0SvLeE9VDbLM0CCzZFx01wog9Ok Y4gKLFuU8UrYUWrIfyVE/KzR1mb8/tkbCY5Lsbxj0DD/t6EtDrl1oC1KK mcuYIYCAa7DqC/AzHUAAhB7Bq6Ri7w41nsn1YSTg9soaHs0O/KN9/3RKX A=;
IronPort-PHdr: 9a23:HQrebhfdddg4srcWTqBrjtoxlGMj4e+mNxMJ6pchl7NFe7ii+JKnJkHE+PFxlwaQB9fa5u5Kze3MvPOoVW8B5MOHt3YPONxJWgQegMob1wonHIaeCEL9IfKrCk5yHMlLWFJ/uX3uN09TFZX/akHc5Hqo4m1aFhD2LwEgIOPzF8bbhNi20Obn/ZrVbk1IiTOxbKk0Ig+xqFDat9Idhs1pLaNixw==
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0APAADim2Bf/4UNJK1gGgEBAQEBAQEBAQEDAQEBARIBAQEBAgIBAQEBQIE7BQEBAQELAYFRUQeBSS8sCoQvg0YDhFmJF4ECl3CBLhSBEQNVCwEBAQ0BAS0CBAEBgVaCdQIXggcCJDQJDgIDAQELAQEFAQEBAgEGBG2FXAyFcgEBAQECARIRBA0MAQE3AQQLAgEGAg4KAgImAgICMBUQAgQOBRsHgwSCTAMOIAEDmWSQaQKBOYhhdn8zgwEBAQWFNRiCEAmBDioBgnCCXEtChAeCSxuBQT+BESccgU9JNT6CXASBKAEJAgEGAQcCgy8zgi2PYhgMByqCcIoYiByPP3EIgQAKgmWOc4RLhwQDHpU4hXOFQ64phCoCBAIEBQIOAQEFgVQ6Z3BwFTsqAYI+UBcCDY4fDBeDTopVAXQCNQIGAQkBAQMJfI0OASeBDQExXwEB
X-IronPort-AV: E=Sophos;i="5.76,429,1592870400"; d="scan'208";a="542583285"
Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 15 Sep 2020 10:52:55 +0000
Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by alln-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id 08FAqtAo003080 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 15 Sep 2020 10:52:55 GMT
Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 15 Sep 2020 05:52:54 -0500
Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 15 Sep 2020 06:52:53 -0400
Received: from NAM10-DM6-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Tue, 15 Sep 2020 05:52:53 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=YXPM091O/G8wl74/sjfwnzROqTotCZc0mjLpoapYHbHYueG9ZTG4z0rtAoyK4zg5WKVKut7GjJhJW0Pw4ufk/+eCOTYzQQaJG0xDPe9r81H15UWTSecAbEHO4VWxvpomhOUJ8xMcmXowfZMBs72a23cWI7uKeBZe+opAA4K17WidkboyhT+8EY9ikSKWdwfe4as1rx93rCdo7HBD0K2ct+LCbA71HZd943kAkM+SMTdD2a3b6NQv+7lu/pqlQwSt9i7BzVc767DenYGg64w6DHtXPnykdwlL2L5BH4TY3hJI7lcxvEDrRKijuxGJSht49s3FtO21GZmiq9VvKHfkNw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=5H5Md8OU2vPkpkTUipLuvlOYxei0rfN7fW8ML69pX2w=; b=dThc7RkM3g8QC1SHsZO3+H91v3j9pR1HHh87dPMSfnbOyNtQCjvFDsv/RgGBjenFkX4bPXNJLjF1Y4rHTd55obeOGXKzTVxzSMk1GovJqTztfmJkWw3Ae7YJFwmfmwrrXlFfh15prMRVjn+NSlsGPlvShmZc4PF5schfKGoa97Q+Xk29uGCgtRTmFtbL7NszMEanmcLeui3vo7V15FQZe9SEchNHQS+azkWDw+CgtFg+2AcmFqZ/AkS2HZ7LEWAw3QWKsx6r9PO6EiiF9Nw2yYuVvst/xQsWLyBsbqTJn+a49h/Akbi9dY2A/bqBM9+sQgRBoQIAiUT0+2wryziDSw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=5H5Md8OU2vPkpkTUipLuvlOYxei0rfN7fW8ML69pX2w=; b=iao4cN0fBlW9wsj99zL//JLlJ8UF0S2sIMRPzI8tISTdfnTPY6DkXdHws8nxCwdxzeRvdJutJk0BIPp5AtrE9IDASv/JbKU00uH5sn2SM5B9/Jf8Kilx5G+fMnLdGGQqXHG+Nwr38yH91a5H42crryIsT6+hxTKiBxhENJLufuc=
Received: from MN2PR11MB3565.namprd11.prod.outlook.com (2603:10b6:208:ea::31) by MN2PR11MB4030.namprd11.prod.outlook.com (2603:10b6:208:156::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3391.11; Tue, 15 Sep 2020 10:52:52 +0000
Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::119:f851:5860:da95]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::119:f851:5860:da95%4]) with mapi id 15.20.3370.019; Tue, 15 Sep 2020 10:52:52 +0000
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Jen Linkova <furry13@gmail.com>
CC: "iot-directorate@ietf.org" <iot-directorate@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>, "v6ops@ietf.org" <v6ops@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>
Thread-Topic: [v6ops] Iotdir last call review of draft-ietf-v6ops-nd-cache-init-05
Thread-Index: AQHWi0BKGej2Cj4C8kGkBTdtCE3mKKlphjcZ
Date: Tue, 15 Sep 2020 10:52:52 +0000
Message-ID: <3A6E80C9-07FC-4B4E-9A20-D02C8743448F@cisco.com>
References: <MN2PR11MB35651BFF4671D89D12E7703DD8270@MN2PR11MB3565.namprd11.prod.outlook.com>, <CAFU7BATkRYD6m++gb6_is6oU=PGpQDTx8V2vm0gcJEcAnc1Tgg@mail.gmail.com>
In-Reply-To: <CAFU7BATkRYD6m++gb6_is6oU=PGpQDTx8V2vm0gcJEcAnc1Tgg@mail.gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [90.118.138.11]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: ecb301e6-a50f-4a4e-49f3-08d859657ea5
x-ms-traffictypediagnostic: MN2PR11MB4030:
x-microsoft-antispam-prvs: <MN2PR11MB403046A173998AE3273E8B20D8200@MN2PR11MB4030.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: ncQYAdUDPSvetBeDEBXPW63gu5KHtMLZuxIXo++FTNh2HyTpbcY/F3LSNjTLsxiWKgQ69hn3fzvAQzqFZ5gPaRfZOSKMyLkcsP5ZIE5o+px/XFKLzuZ6264ejnIAung9PDlJT1yuwU0KQw3ELB9SglJBJKFN5WZsy37lGqW+PAmJchOCK0eu/lFLvq9E6av8CKCUNUpAtX5LFZbOmRnWJECbyFd8EuiJbixuNR5GvfTJuOXb+zn3TXrevviSU/MKp6w004u2BobVRMXEXRPvaEvJww6ROR2u5ayNZY1o2xUkIFIZJdiZuUbtRosY59K1VF65ZEtXy3wpRlMCsRuGcw==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB3565.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(136003)(396003)(376002)(39860400002)(366004)(346002)(30864003)(6506007)(2906002)(36756003)(8676002)(54906003)(66446008)(91956017)(66574015)(71200400001)(53546011)(76116006)(83380400001)(5660300002)(66946007)(66476007)(66556008)(64756008)(2616005)(478600001)(316002)(4326008)(86362001)(6486002)(26005)(6512007)(186003)(33656002)(6916009)(8936002); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: mlxH2Thn7joAgTHVqUSdoz4FMbEep+GI2U8abL2d4UUaO3E/Yl4f5fqU+ODH8TlTNP9JeREhYvYkDgrpnV9IZOui4BprTCDagUSXWicT6S8iFC6nzQsESAVlCGxON7MyHJyu4fekKjkQGCh2T4DwqsscTq6WzxZrosYfd9Yea6shplOdJahI0+o5nUm+tEnrNe+MAJWobKDfiQXgSWCK7j1ZZXegtktDJX8YbB2CotFa0y26NmfNQDtS42nRus+750jmHa2+7/aYSg5TNTdCD7Tjs+QyW/BTtW8sauDqtWcSAzvnyivpRAzw8EnZUqLfmyjcj4MU8pxjw5jEYg+TthBLCBaSJi3FPf8rdXJo2CcVZaorkyEISaU4EgpksgVFR4RZrzpT2zmJbI3VvBEoPVPVB/LNZbVARI4E9hG/vcxuHkAcJ8LINPaCFPfjesL4E2pkkSeDOWBOwOG2rhd9Gqz5FjHIGjqXJXvH8ZyE/aB6Z23lNE9iezVVmVxrtWZ/fYEhOUKiYOrGeFOOa8OX9xgIl+TVRLZJ3TZgDOCHw24RquMS/09BuMGZJCTSqew9C++gSIONpBxGdjaWC5sVaii80rX/Buz5rjGUvuoPNxm0yB25KbZS2E0XgW1olOJ3gvB3n4uPtJqO7qbszF0vow==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MN2PR11MB3565.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: ecb301e6-a50f-4a4e-49f3-08d859657ea5
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Sep 2020 10:52:52.2556 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: iPIx0JvOJ85gH10F3qDD11RKENcTXgKTv6G52YepvxWJdZAkmOq472YOfYgfFwRQoWpDsbcKAioSCDK4Y75noA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4030
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.15, xch-aln-005.cisco.com
X-Outbound-Node: alln-core-11.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/_EHDtl-dHNIDif5m0caxjhT9wEE>
Subject: Re: [v6ops] Iotdir last call review of draft-ietf-v6ops-nd-cache-init-05
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 15 Sep 2020 10:52:59 -0000

Hello Jen

Many thanks for your detailed answer. Let’s see below :

Note that I added the IESG in cc since the merge was on their request.

> Le 15 sept. 2020 
My birthday 🎂😏

> Thanks a lot for your review and comments!
> The IESG asked me to merge this draft and 6man-grand so only the
> latter will be published.
> However as most of the text from nd-cache-init has been moved to
> 6man-grand, your comments still apply - sorry, I missed your email and
> did not address them in 6man-grand-02. The changes mentioned below
> will appear in -03

Better this way if you ask me on both a accounts. Merging looks good. And then we can isolate the review changes.

> 
>> On Fri, Sep 11, 2020 at 12:03 AM Pascal Thubert (pthubert)
>> <pthubert=40cisco.com@dmarc.ietf.org> wrote:
>> ===========================================================================================================
>> Major
>> ===========================================================================================================
>> 
>> 
>> Section 3 lists a number of approaches, but that list does not match the sections 3.x coming next.
>> In particular there is no section that explains why we are not " Making the probing logic on hosts more robust."
>> It seems that if the host sends just one probe to start with, the problem goes away. There must be a reason why this is not done today.
> 
> I've added the following text:
> "
> 
> 8.7. Making the Probing Logic on Hosts More Robust
> 
> Theoretically the probing logic on hosts might be modified to deal
> better with initial packet loss. For example, only one probe can be
> sent or probes retransmit intervals can be reduced. However,
> 
> - This approach does not fix the root cause but just provides a
> work-around for one particular case of probing traffic. Packets are
> still being lost.

If no one knows your address but the guy who replies I’m not sure of this. Maybe this item could be merged with your last point?


> - It's rather unlikely that all affected systems could be updated in
> any reasonable timeframe.

Not sure if I get you there. Isn’t it the same for getting this spec implemented ? If so maybe we can omit this argument. Or did you mean something else?


> - It would not solve the problem if there are multiple applications on
> the same host sending traffic and return packets arrive
> simultaneously.

True. It would have to be done in the OS when forming the address and before any application can open a socket. 

Note that some phones send a crafted packet to detect, e.g., a hotel portal. Is that really different ?

> - Even if a host sends a single probe, the response might consist of
> multiple packets and therefore might be still affected by the problem
> described in this document.

I guess it takes a special crafting to make sure we get only one packet in response, e.g. a TCP SYN. But then that locks ressources on the other end. 

A variation of a ping over udp looks more suited. Or forming a security association with the DNS server? Hard to live with no DNS anyway.

> 
> 8.8. Increasing the Buffer Size on Routers
> 
> Increasing the buffer size and buffering more packets would exacerbate
> issues described in [RFC6583] and make the router more vulnerable to
> ND-based denial of service attacks."
> 

Considering the vast address space that can be attacked there is no amount of memory that will fully protect against a sweeping DOS attack.

The memory in a router is not constrained as it was 20 + years ago. We can allocate many times what we could at the time of the writing of classic ND. The attack can also be many times faster but then that makes the anomaly more recognizable and the router can raise defenses.

I suppose that a platform that is worth attacking can throttle incoming requests.

That is not a perfect response to the sweeping DOS attack though. You can only defeat it if the network has a full knowledge of all the addresses On Link and, e.g, the router plainly drops any cache miss in hardware. Sadly this draft doesn’t give us that, that’s the other point later below.

Also hardware assistance for the forwarding was just emerging and the related issues were disregarded. Implementing a reactive protocol with hardware assist is a great penalty to the router. The draft helps a lot as the situation can be mostly avoided. 

But the complicated code path cannot be removed for the same reason as above, we do not have a complete list. Less exercising may mean deteriorating, least exercised code paths being a familiar location for a bug nest.

All in all, this argument pleads for the full proactive solution more than the partial one (voluntarily avoiding quick and dirty because it is not the latter).




> Would it address your comment?
> 

Not yet as you see. There are pros and cons.

Sending a single probe provides a local solution with no dependency on the router.

I believe that the NA is a good thing, better than current state of affairs.

Ideally the draft would describe both and provide recommendations on how to do the single packet as a step 0. Then it would do what it does today as step 1. Then it would open in conclusion to a future with a full proactive solution where the DOS attack is not possible any more.


>> ---------------------------------------------------------------------------------------------------------------------------------------------
>> "
>> Implementing such functionality is much more complicated than all
>>      other solutions as it would involve complex data-control planes
>>      interaction."
>> 
>> As it goes, reactive ND as it stands involve complex data-control planes interactions, the hardware needs to interrupt its process and tell the software in case of a cache miss.
>> This process is not only complicated but subject to DoS attacks and all prone to bugs. The solution eliminates that activity for a new address and that is a major plus for the router. Sadly it does not fix the problem permanently as the cache may be flushed. I believe it is important to mention both early in the draft to better position its value (great) and limits (the Neighbor cache is still a cache so the problem is not eliminated).
> 
> I've added a "Solution Limitations" section:
> 
> Solution Limitations
> 
> The solution described in this document provides some improvement for
> a node configuring a new IPv6 address and start sending traffic from
> it. However that approach does not completely eliminate the scenario
> when a router receives some transit traffic for an address without the
> corresponding Neighbor Cache entry. For example:
> 
> -- If the host starts using an already configured IPv6 address after a
> long period of inactivity, the router might not have the NC entry for
> that address anymore, as old/expired entries are deleted.
> - Flashing the router Neighbor Cache would trigger the packet loss for
> all actively used addresses removed from the cache.
> 
> 

Flushing ?

>> ===========================================================================================================
>> Minor
>> ==========================================================================================================="
>>   1.  A host joins the network and receives a Router Advertisement (RA)
>>       packet from the first-hop router (either a periodic unsolicited
>>       RA or a response to a Router Solicitation sent by the host).
>> "
>> Maybe clarify that this is a multicast RA sent to all hosts
> 
> Not necessary. Solicited RAs can be (should be) unicast.
> 

Sure, but then, using another address like link local 

>> "
>> The
>>       RA contains information the host needs to perform Stateless
>>       Address Autoconfiguration ([RFC4862]) and to configure its
>>       network stack.
>> "
>> You could say "SLAAC and/or DHCPv6" for completeness.
> 
> Does RA contain information the host needs to perform DHCPv6? I'm not so sure..
> 

The M and/or O bits ... DHCP goes a very long way to configure the stack.


> 
>> "
>>                             As in most cases the RA also contains the link-
>>       layer address of the router, the host can populate its Neighbor
>>       Cache with the router's link-local and link-layer addresses.
>> "
>> Maybe also clarify in before that sentence that the source IPv6 address of the RA is a link local address of the router (section 4.2 of RFC 4861)
> 
> Done:
> "
> 
> The RA contains information the host needs to perform SLAAC and to
> configure its network stack. The RA is send from the router's
> link-local address and in most cases also contains the link-layer
> address of the router. As a result the host can populate its Neighbor
> Cache with the router's link-local and link-layer addresses.
> "
> 

-> is sent. Maybe avoid « in most cases » and uses « may » instead ?

>> "
>>                                                                          Most router
>>       implementations buffer only one data packet while
>> "
>> Is that something you know for sure? Else, you may indicate instead that the standard only requires the router to hold one data packet.
>> For memory, RFC 4861 section 7.2.2.  "Sending Neighbor Solicitations" says:
>> "
>> ...
>>   While waiting for address resolution to complete, the sender MUST,
>>   for each neighbor, retain a small queue of packets waiting for
>>   address resolution to complete.  The queue MUST hold at least one
>>   packet, and MAY contain more.  However, the number of queued packets
>>   per neighbor SHOULD be limited to some small value.  When a queue
>>   overflows, the new arrival SHOULD replace the oldest entry.  Once
>>   address resolution completes, the node transmits any queued packets.
>> ...
>> "
> 
> Changed to:
> "As per Section 7.2.2 of [RFC4861] Routers MUST buffer at least one
> data packet and MAY buffer more, while resolving the packet
> destination address. However most router implementations limit the
> buffer size to a few packets only, so all subsequent packets for the
> host global address are dropped, until the address resolution process
> is completed."

Not untrue. Does that mean true?


> 
>> ---------------------------------------------------------------------------------------------------------------------------------------------
>> 
>> "connects to the network for the first time or after a timeout long"
>> 
>> Maybe "inactivity time" is more suitable than "timeout"
> 
> Done.
> 
>> " This option
>>   requires some investigation and discussions and seems to be excessive
>>   for the problem described in this document. "
>> 
>> The option itself is not "excessive", it is a technical solution. Maybe you could clarify what is excessive, e.g., the complexity to migrate, to implement and deploy, or the time till a solution is available commercially on all devices.
> 
> Changed to "This option requires some investigation and discussion.
> However the implementation complexity and unclear adoption timeline
> makes this approach less preferable than one proposed in this
> document."
> 

I’m good with that 


>> ===========================================================================================================
>> Nits
>> ===========================================================================================================
>> 
>> "if a host A has an neighbor": an -> a
>> "same sequence of events happen": happen -> happens
> 
> This text did not make it to 6man-grand anyway.
> 
>> Voila!
> 
> Merci! ;)
> 

De même (me too ;)

Pascal 

> --
> SY, Jen Linkova aka Furry