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

Ted Lemon <mellon@fugue.com> Thu, 09 June 2016 13:37 UTC

Return-Path: <mellon@fugue.com>
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12A7E12D751 for <softwires@ietfa.amsl.com>; Thu, 9 Jun 2016 06:37:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 cu2heeMRzwTL for <softwires@ietfa.amsl.com>; Thu, 9 Jun 2016 06:37:26 -0700 (PDT)
Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (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 349DF12D0A9 for <softwires@ietf.org>; Thu, 9 Jun 2016 06:37:26 -0700 (PDT)
Received: by mail-lf0-x22d.google.com with SMTP id j5so26429555lfb.3 for <softwires@ietf.org>; Thu, 09 Jun 2016 06:37:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wVjzZC+djdtdhZkV+l52XIGVzvmA6t4Wbrt/E2fa/NU=; b=WpteQ2yzYQ9a5iVuY5EhMIuCOxenOD92FMcO+uFxoZATrSNCztYZD+IpNTv9mGIA9G RHp6tFdvjn0BGiYRhV7oPst9in6AoWsPHYq2P3eG0NvbNj3quAbS0Y4vhdyTB7DvXAAS sjWYBim9JwGcPSFsYJ/LyDCfD7VKyRHFMyXNq4nqmmtYC9U8WpLxX5x5yOpo3fdgHdBk uxl6fmcgFtpnEyDQzm3WUMH+b3ybBOV36NK8rbed3e1jb9zwRfsiapt286G2Ioxo9WGc dgV1zQFDgsFQSdCGa0uLjBHiLnyZOBjRv3x74dDr0QSJph08kBIfTF60fftLObADkvqf p9dg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wVjzZC+djdtdhZkV+l52XIGVzvmA6t4Wbrt/E2fa/NU=; b=TE5828+N1qOONnqjmBxaLdOfpfciEq84qR4mCByZDrMxYfWtk53u/qTU5T+61keNdE wkswCu7vhQKu1xrLhFLiuMVrqWtNVEWyY0EEywDIXvkBukVFe+oln4mob2TURqLN58y+ bI9Wk6j9bnxO77mLbDgiE9yoeQ9Nb2UuaF0VL2Y4b9nqdhO1xJE0TtcEif2DrDeyJxPd OKwfFMapNWP7EQXNSX/rF4qXJ6HZ4NznIg5rHGykePPWb0nCm/kuWamRwYc+Sw0vRsFN rA8ckRksiS1KBPvA1No+AuB6t5yzQGJklQb8NH0PJNndETUir8I/p4QngoM5kEgcKmgr razA==
X-Gm-Message-State: ALyK8tJBm65/5K8davVV8dpny9atu2HKw8+pgpHaPw9F7Bz8lkEkXNK7IPBIxYUwVO7/BwRpflc0sscfUjYtzA==
X-Received: by 10.25.210.205 with SMTP id j196mr6036209lfg.139.1465479444171; Thu, 09 Jun 2016 06:37:24 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.153.135 with HTTP; Thu, 9 Jun 2016 06:36:44 -0700 (PDT)
In-Reply-To: <2CDDF3C1-1F18-4621-8223-9CD5ADCBDDD1@gmx.com>
References: <787AE7BB302AE849A7480A190F8B933008DAECE0@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <D5ABB288-99F9-4038-9E13-A9FC2ADAC0EF@gmx.com> <787AE7BB302AE849A7480A190F8B933008DAF3A6@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <0B27AECD-13CD-4B05-A34C-70E901807D40@gmx.com> <CAPt1N1=ZGhkG4jU1+iZGqjiCg6M2j0GOSogADNj4=pK8cxYwHg@mail.gmail.com> <2CDDF3C1-1F18-4621-8223-9CD5ADCBDDD1@gmx.com>
From: Ted Lemon <mellon@fugue.com>
Date: Thu, 9 Jun 2016 09:36:44 -0400
Message-ID: <CAPt1N1ktcG6AQpWKyDEBjAOOq4BHvVZ2gkPwAyQDtnAaaa-OQQ@mail.gmail.com>
To: Ian Farrer <ianfarrer@gmx.com>
Content-Type: multipart/alternative; boundary=001a11403562b3f2e90534d885ac
Archived-At: <https://mailarchive.ietf.org/arch/msg/softwires/ksAksIkjYtIHEOcVEoPZnyy7J-E>
Cc: Softwires WG <softwires@ietf.org>, "dhcwg-chairs@ietf.org" <dhcwg-chairs@ietf.org>
Subject: Re: [Softwires] 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: Thu, 09 Jun 2016 13:37:31 -0000

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 <ianfarrer@gmx.com> wrote:

> HI Ted,
>
> Cheers,
> Ian
>
> On 9 Jun 2016, at 14:34, Ted Lemon <mellon@fugue.com> 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 <ianfarrer@gmx.com> 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.
>>
>> Thanks,
>> Ian
>>
>> On 9 Jun 2016, at 08:49, mohamed.boucadair@orange.com wrote:
>>
>> Hi Ian,
>>
>> There are two options:
>>
>> (1)
>>
>> Maintain the current text in the draft but add the following text to
>> Section 4:
>>
>>    Servers SHOULD NOT send more than one instance of OPTION_V6_PREFIX64,
>>    except if distinct IPv6 multicast prefixes with distinct scopes are
>>    configured.
>>
>> This is the behavior defined in
>> https://tools.ietf.org/html/rfc6334#section-5/.
>>
>> (2)
>>
>> Add this text in Section 4:
>>
>>    Servers MUST NOT send more than one instance of OPTION_V6_PREFIX64,
>>    except if distinct IPv6 multicast prefixes with distinct scopes are
>>    configured.
>>
>> And modify the text in Section 5 to indicate that the client must discard
>> the options if all enclosed addresses are of the same scope.
>>
>> I agree with you that (2) will help to identify a server error, but with
>> a risk to induce service disruptions.
>>
>> Which one do you prefer to be implemented in the draft?
>>
>> Thank you.
>>
>> Cheers,
>> Med
>>
>> *De :* Ian Farrer [mailto:ianfarrer@gmx.com <ianfarrer@gmx.com>]
>> *Envoyé :* mercredi 8 juin 2016 19:10
>> *À :* BOUCADAIR Mohamed IMT/OLN; Softwires WG
>> *Cc :* dhcwg-chairs@ietf.org
>> *Objet :* Fwd: Problem in draft-ietf-softwire-multicast-prefix-option
>>
>> Hi Med,
>>
>> Forwarding this to the list (the left group mailing addresses were not
>> working earlier).
>>
>> Please see inline below.
>>
>> Thanks,
>> Ian
>>
>>
>> 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>gt;, 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 <ianfarrer@gmx.com>]
>> *Envoyé :* mercredi 8 juin 2016 16:11
>> *À :* softwires@ietf.org; BOUCADAIR Mohamed IMT/OLN; Jacni Qin;
>> dxhbupt@gmail.com
>> *Cc :* 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
>>
>>
>>
>> _______________________________________________
>> Softwires mailing list
>> Softwires@ietf.org
>> https://www.ietf.org/mailman/listinfo/softwires
>>
>>
>
>