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 protected]> wrote: > HI Ted, > > Cheers, > Ian > > On 9 Jun 2016, at 14:34, Ted Lemon <[email protected]> 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 protected]> 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 protected] 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:[email protected] <[email protected]>] >> *Envoyé :* mercredi 8 juin 2016 19:10 >> *À :* BOUCADAIR Mohamed IMT/OLN; Softwires WG >> *Cc :* [email protected] >> *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: *<[email protected]> >> *Subject: RE: Problem in draft-ietf-softwire-multicast-prefix-option* >> *Date: *8 June 2016 16:50:51 CEST >> *To: *ian Farrer <[email protected]>, "[email protected]" < >> [email protected]>, Jacni Qin <[email protected]>, "[email protected]" < >> [email protected]> >> *Cc: *"[email protected]" <[email protected]> >> >> Hi Ian, >> >> Please see inline. >> >> Cheers, >> Med >> >> *De :* ian Farrer [mailto:[email protected] <[email protected]>] >> *Envoyé :* mercredi 8 juin 2016 16:11 >> *À :* [email protected]; BOUCADAIR Mohamed IMT/OLN; Jacni Qin; >> [email protected] >> *Cc :* [email protected] >> *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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/softwires >> >> > >
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
