Re: [mif] Comments on draft-ietf-mif-mpvd-ndp-support

Jouni Korhonen <jouni.nospam@gmail.com> Fri, 24 July 2015 12:30 UTC

Return-Path: <jouni.nospam@gmail.com>
X-Original-To: mif@ietfa.amsl.com
Delivered-To: mif@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79E301A00A0 for <mif@ietfa.amsl.com>; Fri, 24 Jul 2015 05:30:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
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 ro7YDc-0q6qK for <mif@ietfa.amsl.com>; Fri, 24 Jul 2015 05:30:18 -0700 (PDT)
Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 801E71A00BD for <mif@ietf.org>; Fri, 24 Jul 2015 05:30:17 -0700 (PDT)
Received: by wibxm9 with SMTP id xm9so26836009wib.0 for <mif@ietf.org>; Fri, 24 Jul 2015 05:30:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=BMhEVLOCIoXMlzAHkqG4UZHPUGp6ihOFJNHIL2s4WSE=; b=FDGfMR5tHVVTOCnxBTD4+b6RGJUVPZ6Mt95OPYivqBLAaMO/gpfBradsO6v3jx21m9 G/JWIxPsLifA/Ek7GDLte9CFkswTJMS/d74BU/Gnca8kHhlOJ1D/Msv3XBqMo1xjTTn2 1iBaG39fyw7CTJZkjOCuK9dJ0ZAUj9ETV2A6IFdYeSjbKKSC2RDlOil3DRUI1xUIGJGb 5MuAu9fCgcAJyHjQW9n01lwmF3QvDPKd67J+kdPOao3pes2P4qHOAKwWBl1/dQB2PSM8 53oDIN7MW4kfbdJMlgMh0n7DZLdk/dZwgFn949Yy7XIaZnMLVtxQ6qgW0+79y1pW+bYZ rprw==
X-Received: by 10.180.21.175 with SMTP id w15mr7063292wie.58.1437741016210; Fri, 24 Jul 2015 05:30:16 -0700 (PDT)
Received: from ?IPv6:2001:67c:370:136:cd92:da6:7e97:886f? ([2001:67c:370:136:cd92:da6:7e97:886f]) by smtp.googlemail.com with ESMTPSA id di7sm3299098wib.23.2015.07.24.05.30.14 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 Jul 2015 05:30:14 -0700 (PDT)
To: Steven Barth <cyrus@openwrt.org>
References: <55AF52F1.2040802@openwrt.org> <55B0CB0C.1010301@gmail.com> <55B0D2A8.4060807@openwrt.org> <55B0EFC1.4080502@gmail.com> <55B0F8A9.4060203@openwrt.org> <55B1034C.3010809@gmail.com> <55B1C653.60507@openwrt.org>
From: Jouni Korhonen <jouni.nospam@gmail.com>
Message-ID: <55B22FD5.3070303@gmail.com>
Date: Fri, 24 Jul 2015 05:30:13 -0700
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0
MIME-Version: 1.0
In-Reply-To: <55B1C653.60507@openwrt.org>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/mif/DNTgNuCe5isnthbOuUy-84fNdI0>
Cc: "mif@ietf.org" <mif@ietf.org>
Subject: Re: [mif] Comments on draft-ietf-mif-mpvd-ndp-support
X-BeenThere: mif@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiple Interface Discussion List <mif.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mif>, <mailto:mif-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mif/>
List-Post: <mailto:mif@ietf.org>
List-Help: <mailto:mif-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mif>, <mailto:mif-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 24 Jul 2015 12:30:20 -0000

Steven,

7/23/2015, 10:00 PM, Steven Barth kirjoitti:
>
>>
>> The text says "should the IPv6 packet be fragmented,.." which imho is rather clear it means IPv6 level fragmentation.
>
> It is indeed, I feel rather that the intention for your MUST is not obvious.

You mean having all options that belong to one PDV being inside one 
fragment?

> To me I would either expect all fragmented ND packets to be dropped (esp. multicast), only some to be dropped but the packet to be discarded as a whole because of that, or the whole packet to be correctly reassembled.

I do not understand what your "expactation" and the above sentence has 
to do with the text in the draft. Actually, I do not understand what the 
above sentence tries to say.

> In all these cases I don't get the intention of your requirement.

Trying to keep the container as a whole if someone for some reason wants 
to peek into it before reassembly.. but it is not a sticking point for 
the draft. SHOULD would be ok, even removing the whole fragmentation 
text could be ok.

> Beside that I think this requirement is a layer violation here and would require a very good justification (aside trying to work-around some broken host implementations) since it significantly increases the implementation complexity of the RA server (at least in case your RAs are getting big).

I don't understand the claim for layer violation.. the implementation 
complexity annoynace I understand.

- Jouni

>