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

From: <[email-masked]>
Date: Wed, 8 Jun 2016 14:50:51 +0000

Hi Ian,

Please see inline.

Cheers,
Med

De : ian Farrer [mailto:[email-masked]]
Envoyé : mercredi 8 juin 2016 16:11
À : [email-masked]; BOUCADAIR Mohamed IMT/OLN; Jacni Qin; [email-masked]
Cc : [email-masked]
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).

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

---

From: Ian Farrer <[email-masked]>
Date: Wed, 8 Jun 2016 19:09:39 +0200

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: <[email-masked]>
> Subject: RE: Problem in draft-ietf-softwire-multicast-prefix-option
> Date: 8 June 2016 16:50:51 CEST
> To: ian Farrer <[email-masked]>, "[email-masked]" <[email-masked]>, Jacni Qin <[email-masked]>, "[email-masked]" <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> 
> Hi Ian,
>  
> Please see inline.
>  
> Cheers,
> Med
>  
> De : ian Farrer [mailto:[email-masked] <mailto:[email-masked]>] 
> À : [email-masked] <mailto:[email-masked]>; BOUCADAIR Mohamed IMT/OLN; Jacni Qin; [email-masked] <mailto:[email-masked]>
> Cc : [email-masked] <mailto:[email-masked]>

[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?]

---

From: <[email-masked]>
Date: Thu, 9 Jun 2016 06:49:09 +0000

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:[email-masked]]
Envoyé : mercredi 8 juin 2016 19:10
À : BOUCADAIR Mohamed IMT/OLN; Softwires WG
Cc : [email-masked]
Objet : Fwd: Problem in draft-ietf-softwire-multicast-prefix-option

Hi Med,

Please see inline below.

Thanks,
Ian

Begin forwarded message:

From: <[email-masked]<mailto:[email-masked]>>
Subject: RE: Problem in draft-ietf-softwire-multicast-prefix-option
Date: 8 June 2016 16:50:51 CEST
To: ian Farrer <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Jacni Qin <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>

Hi Ian,

Please see inline.

Cheers,
Med

De : ian Farrer [mailto:[email-masked]]
Envoyé : mercredi 8 juin 2016 16:11
À : [email-masked]<mailto:[email-masked]>; BOUCADAIR Mohamed IMT/OLN; Jacni Qin; [email-masked]<mailto:[email-masked]>
Cc : [email-masked]<mailto:[email-masked]>
Objet : Problem in draft-ietf-softwire-multicast-prefix-option

Hi,

Thanks,
Ian

---

From: Ian Farrer <[email-masked]>
Date: Thu, 9 Jun 2016 09:44:39 +0200

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, [email-masked] <mailto:[email-masked]> wrote:
> 
> Hi Ian,
>  
> There are two options:
>  
> (1)
>  
> This is the behavior defined in https://tools.ietf.org/html/rfc6334#section-5/ <https://tools.ietf.org/html/rfc6334#section-5/>.
>  
> (2)
>  
> De : Ian Farrer [mailto:[email-masked] <mailto:[email-masked]>] 
> From: <[email-masked] <mailto:[email-masked]>>
> To: ian Farrer <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, Jacni Qin <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
> Cc: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
>  
> Hi Ian,
>  
> Please see inline.
>  
> Cheers,
> Med
>

---

From: Ted Lemon <[email-masked]>
Date: Thu, 9 Jun 2016 08:34:12 -0400

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 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 <[email-masked]> 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, [email-masked] wrote:
>
> Hi Ian,
>
> There are two options:
>
> (1)
>
> This is the behavior defined in
> https://tools.ietf.org/html/rfc6334#section-5/.
>
> (2)
>
> 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.
>
> *De :* Ian Farrer [mailto:[email-masked] <[email-masked]>]
> *Envoyé :* mercredi 8 juin 2016 19:10
> *À :* BOUCADAIR Mohamed IMT/OLN; Softwires WG
> *Cc :* [email-masked]
> *Objet :* Fwd: Problem in draft-ietf-softwire-multicast-prefix-option
>
> Hi Med,
>
> *From: *<[email-masked]>
> *Subject: RE: Problem in draft-ietf-softwire-multicast-prefix-option*
> *Date: *8 June 2016 16:50:51 CEST
> *To: *ian Farrer <[email-masked]>, "[email-masked]" <
> [email-masked]>, Jacni Qin <[email-masked]>, "[email-masked]" <
> [email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>
>
> Hi Ian,
>
> Please see inline.
>
> Cheers,
> Med
>
> *De :* ian Farrer [mailto:[email-masked] <[email-masked]>]
> *Envoyé :* mercredi 8 juin 2016 16:11
> *À :* [email-masked]; BOUCADAIR Mohamed IMT/OLN; Jacni Qin;
> [email-masked]
> *Cc :* [email-masked]
> *Objet :* Problem in draft-ietf-softwire-multicast-prefix-option
>
> Hi,
>
> "If all the enclosed IPv4-embedded IPv6 multicast prefixes have the same
> scope, the first instance of the option MUST be used."
>
> [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?]
>
>
>
>
>
>
> _______________________________________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires
>
>

---

From: Ian Farrer <[email-masked]>
Date: Thu, 9 Jun 2016 15:08:29 +0200

HI Ted,

Cheers,
Ian

> On 9 Jun 2016, at 14:34, Ted Lemon <[email-masked]> 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 <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Med,
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/softwires <https://www.ietf.org/mailman/listinfo/softwires>
> 
>

---

From: Ted Lemon <[email-masked]>
Date: Thu, 9 Jun 2016 09:36:44 -0400

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 <[email-masked]> 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
> [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.
>
>> 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
>> 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.
>>
>> 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

---

From: <[email-masked]>
Date: Fri, 10 Jun 2016 06:07:13 +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].

Comments?

Cheers,
Med

De : Ted Lemon [mailto:[email-masked]]
Envoyé : jeudi 9 juin 2016 15:37
À : Ian Farrer
Cc : BOUCADAIR Mohamed IMT/OLN; Softwires WG; [email-masked]
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 <[email-masked]<mailto:[email-masked]>> wrote:
HI Ted,

Cheers,
Ian

On 9 Jun 2016, at 14:34, Ted Lemon <[email-masked]<mailto:[email-masked]>> wrote:

On Thu, Jun 9, 2016 at 3:44 AM, Ian Farrer <[email-masked]<mailto:[email-masked]>> wrote:
Hi Med,

Thanks,
Ian