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

<> Fri, 10 June 2016 06:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F18EA12DAA8; Thu, 9 Jun 2016 23:07:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.618
X-Spam-Status: No, score=-1.618 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1xizZcT0VFVF; Thu, 9 Jun 2016 23:07:16 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BCE2612D1A2; Thu, 9 Jun 2016 23:07:15 -0700 (PDT)
Received: from (unknown [xx.xx.xx.2]) by (ESMTP service) with ESMTP id 1B03018C814; Fri, 10 Jun 2016 08:07:14 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown []) by (ESMTP service) with ESMTP id E254B27C06F; Fri, 10 Jun 2016 08:07:13 +0200 (CEST)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM23.corporate.adroot.infra.ftgroup ([fe80::787e:db0c:23c4:71b3%19]) with mapi id 14.03.0294.000; Fri, 10 Jun 2016 08:07:13 +0200
To: Ted Lemon <>, Ian Farrer <>
Thread-Topic: [Softwires] Problem in draft-ietf-softwire-multicast-prefix-option
Thread-Index: AQHRwlQQhAAP6utZe0OknJXCUR55T5/iLi6g
Date: Fri, 10 Jun 2016 06:07:13 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B933008DAFC9A@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
References: <787AE7BB302AE849A7480A190F8B933008DAECE0@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <> <787AE7BB302AE849A7480A190F8B933008DAF3A6@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <> <> <> <>
In-Reply-To: <>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933008DAFC9AOPEXCLILMA3corp_"
MIME-Version: 1.0
X-PMX-Version:, Antispam-Engine:, Antispam-Data: 2016.6.7.90315
Archived-At: <>
Cc: Softwires WG <>, "" <>
Subject: Re: [Softwires] Problem in draft-ietf-softwire-multicast-prefix-option
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: softwires wg discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 10 Jun 2016 06:07:18 -0000

Hi Ted, Ian,

What I understand from Ted’s comment is he is objecting to add restrictions to the server’s behavior proposed by Ian.

In order to address the initial comment from Ian, I suggest this text:

   If distinct multicast PREFIX64s per scope are configured, the DHCP
   server returns multiple OPTION_V6_PREFIX64s; each instance is
   enclosing distinct ASM_PREFIX64 and SSM_PREFIX64 per scope.  Refer to
   Section 8 of [RFC2365] for a mapping between IPv4 multicast prefixes
   to IPv6 multicast address scopes [RFC7346].



De : Ted Lemon []
Envoyé : jeudi 9 juin 2016 15:37
À : Ian Farrer
Cc : BOUCADAIR Mohamed IMT/OLN; Softwires WG;
Objet : Re: [Softwires] Problem in draft-ietf-softwire-multicast-prefix-option

I would suggest:

  *   Two options, with different semantics
  *   Option format is one IP address per option
  *   This means that servers can't send two IP addresses, because that's not the format of the option
  *   Clients silently discard malformed options (don't need to specify this--it's just what clients should do in general)
  *   Define the semantics for the case where the client receives both options.

On Thu, Jun 9, 2016 at 9:08 AM, Ian Farrer <<>> wrote:
HI Ted,


On 9 Jun 2016, at 14:34, Ted Lemon <<>> wrote:

Actually, this is a classic example of what we try to avoid: special server behavior for options.   Options are just payload, not protocol, unless they are intended to affect the flow of the protocol.   It should not be necessary for the server to have special code to support a different payload, any more than the TCP stack should have to be modified in order to support new extensions to HTTP.

So you could make an operational note about how servers ought to be configured, but you should not require that the server check to make sure it is configured that way.   You should not require that the server understand the semantics of the option--what it means for there to be two of them, or what order they should occur in, or what meaning that ordering has.

[if - So, for the original reason that the point was raised, do you suggest that enforcing this only in the client (i.e. if it receives an invalid option combination/content then drop all instances) in addition to the operation guidance for server config?]

If you have two different uses for an option, with different semantics, you should define two different options, each of which has only one semantics.

On Thu, Jun 9, 2016 at 3:44 AM, Ian Farrer <<>> wrote:
Hi Med,

To be clear, both of the suggestions include the modification to the Section 5 client text? I think this is necessary. But is the error condition that all of the enclosed options are the same scope, or that two or more are?

Between the two, I would prefer (1) - a MUST NOT with an exception is a SHOULD NOT. An alternative wording that tries to get the best of both:

A server MUST NOT send more than on one instance of OPTION_V6_PREFIX64 per scope. Servers MAY send one instance of OPTION_V6_PREFIX64 for each distinct IPv6 multicast prefix with a distinct scope.