[Softwires] Fwd: Problem in draft-ietf-softwire-multicast-prefix-option

Ian Farrer <ianfarrer@gmx.com> Wed, 08 June 2016 17:09 UTC

Return-Path: <ianfarrer@gmx.com>
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 5DC1A12D75B for <softwires@ietfa.amsl.com>; Wed, 8 Jun 2016 10:09:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.6
X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id TC2VfZy5B-9A for <softwires@ietfa.amsl.com>; Wed, 8 Jun 2016 10:09:45 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net []) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF75612D512 for <softwires@ietf.org>; Wed, 8 Jun 2016 10:09:44 -0700 (PDT)
Received: from ians-mbp.lan ([]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0M4nM5-1bN88012ab-00ywVF; Wed, 08 Jun 2016 19:09:41 +0200
From: Ian Farrer <ianfarrer@gmx.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_2F89F692-11F8-4825-B5DA-BFD113213456"
Message-Id: <D5ABB288-99F9-4038-9E13-A9FC2ADAC0EF@gmx.com>
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
Date: Wed, 8 Jun 2016 19:09:39 +0200
References: <787AE7BB302AE849A7480A190F8B933008DAECE0@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
To: mohamed Boucadair <mohamed.boucadair@orange.com>, Softwires WG <softwires@ietf.org>
X-Mailer: Apple Mail (2.2104)
X-Provags-ID: V03:K0:NLTMWFtSsbyGX0B9/zAj0drGugYpAq4ytzrhOcJHnhwZuOgkQ31 qM08DmNQmSUXNTaZurhoQYJpk6KoHX/QfP4Zrp6Qb+jlaHS8eoBZYPNBIzDztcEo2GX+ziG pJD30cHRpzIs32+gU5FRwgaqsyvC8t2B5jeknKU9EorZ7LI2YUGVdbBmi0N2K4QFJCwOPSb T5I++GhS0ifYsdtHxEj2Q==
X-UI-Out-Filterresults: notjunk:1;V01:K0:1Xowt35OzTw=:j6mO0SudvBOmkJG+GEngqZ G6S1DvDnEhtYX/MSlfnMMWYasuU88ib+qA3A586rYV2H0U/+1e+qU+/xGiJJAMqWa/bqlb+4m VqFwVSCJMbnPxeuBPOewXOuqW2KZA8NC+Z/mP8MBXjIzYbZMGl0RUFXuYvbe8ady6gxqfQDyt zsHkZkZIC+S7SRmOz0vow4dqIDCF2WIBawIf7KaLnC3qqBoXUEl+JvbcjdkABS3HL2rnfg0NL wQRYjMTOSZUDcWILIzxrq5AJs194AsIHYiDzz5zuVtyWP92sSGy5WqTOhI+q60FTt+U381FZr tUgyRnUO6rd3lgn8v0J6TaqFN1MLslkVImSmIWVw6s6GSu+J7fIfojg+btbPygV9J8xpzmLnV b/Mx9MXsBJYzzhEHRQ3JJC5lvRX67AGjOC6X+nZ3cFNSHy5UEQaz9GnWln9Tjj8NzqigblpZa 42Y7uwXj2EbVYAs71UAy7hTQWWLSgLZ9/La6cRe4C8iSe94byDnb2a5/HXArczLOnr43+gZwl bwTuZLMtO03Db8SVzV733gCvLlfzi+3wSyOrlB5BzWGZQf1hjsCE8XvOJ2wh95XPNcnOPePQs NmGEWriYuR4qY8ibPhS1ow86rqMCNcchE8RmScwHdHSwttnCGNP4tRssGydVD3EiAnLWR+2y5 bhzS1TkMII2IBKSDTXwX5BCWqvjnt0+wijfWMBo7jQtHJMZaBfsaeMGUEl+ynu9K85xxkMGia 5W1kL6dkPRKe8MIsiQIZbh6fzF5vhmZCwyQRMzmSeqQhqml/+45bPeCICq8B4nThPEorFmZOa AozX7Ee
Archived-At: <https://mailarchive.ietf.org/arch/msg/softwires/oxS5h71W9K_YM3gyRCX5oJLmZ6E>
Cc: dhcwg-chairs@ietf.org
Subject: [Softwires] Fwd: Problem in draft-ietf-softwire-multicast-prefix-option
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: softwires wg discussion list <softwires.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/softwires>, <mailto:softwires-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/softwires/>
List-Post: <mailto:softwires@ietf.org>
List-Help: <mailto:softwires-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/softwires>, <mailto:softwires-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Jun 2016 17:09:48 -0000

Hi Med,

Forwarding this to the list (the left group mailing addresses were not working earlier).

Please see inline below.


> Begin forwarded message:
> From: <mohamed.boucadair@orange.com>
> Subject: RE: Problem in draft-ietf-softwire-multicast-prefix-option
> Date: 8 June 2016 16:50:51 CEST
> To: ian Farrer <ianfarrer@gmx.com>om>, "softwires@ietf.org" <softwires@ietf.org>rg>, Jacni Qin <jacni@jacni.com>om>, "dxhbupt@gmail.com" <dxhbupt@gmail.com>
> Cc: "dhcwg-chairs@ietf.org" <dhcwg-chairs@ietf.org>
> Hi Ian,
> Please see inline.
> Cheers,
> Med
> De : ian Farrer [mailto:ianfarrer@gmx.com <mailto:ianfarrer@gmx.com>] 
> Envoyé : mercredi 8 juin 2016 16:11
> À : softwires@ietf.org <mailto:softwires@ietf.org>; BOUCADAIR Mohamed IMT/OLN; Jacni Qin; dxhbupt@gmail.com <mailto:dxhbupt@gmail.com>
> Cc : dhcwg-chairs@ietf.org <mailto:dhcwg-chairs@ietf.org>
> Objet : Problem in draft-ietf-softwire-multicast-prefix-option
> Hi,
> On reviewing this draft I would like to raise a problem with section 5 of the draft. The text is:
> "If all the enclosed IPv4-embedded IPv6 multicast prefixes have the same scope, the first instance of the option MUST be used."
> The problem is that this contravenes section 17 of RFC7227:
> Option order, either the order among many DHCPv6 options or the order
>    of multiple instances of the same option, SHOULD NOT be significant.
>    New documents MUST NOT assume any specific option processing order.
> [Med] That sentence does not assume any (preference) order. It does only provide one way to select one instance among that list. As a reminder, the server is supposed to return one instance (per scope).

[if - If the client is taking the first occurrence within the option and attempting to configure it, then it is preferring this option over other instances based on the order in which it occurs in the message.

The current text which describes the server behaviour (section 4) does not mention scope at all and does not specify any limitations on the number of instances or criteria for which they may be included - see RFC7227 sec 16.

If the server is meant to only return a single instance of the option per scope, but it is sending more than one, then this is a server configuration error. A quasi-random mechanism for the client to try and work around this just means that the configuration error may get masked.

As a suggestion, wouldn’t it be better to specify what the valid cases for the server including multiple option instances are and are not (with normative language). The client’s behaviour can then be defined to discard the options if they do not meet this criteria?]

> I raised this with the DHC WG chairs, and they have a couple of suggestions:
> 1. Define an encapsulating option - as the data inside an option can be order dependent.
> 2. Add a “preference” (octet?) and then a client can sort them based on this preference.
> Thanks,
> Ian