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] > <mailto:[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/ > <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] <mailto:[email protected]>] > Envoyé : mercredi 8 juin 2016 19:10 > À : BOUCADAIR Mohamed IMT/OLN; Softwires WG > Cc : [email protected] <mailto:[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] <mailto:[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] <mailto:[email protected]>>, > "[email protected] <mailto:[email protected]>" <[email protected] > <mailto:[email protected]>>, Jacni Qin <[email protected] > <mailto:[email protected]>>, "[email protected] <mailto:[email protected]>" > <[email protected] <mailto:[email protected]>> > Cc: "[email protected] <mailto:[email protected]>" > <[email protected] <mailto:[email protected]>> > > Hi Ian, > > Please see inline. > > Cheers, > Med > > De : ian Farrer [mailto:[email protected] <mailto:[email protected]>] > Envoyé : mercredi 8 juin 2016 16:11 > À : [email protected] <mailto:[email protected]>; BOUCADAIR Mohamed > IMT/OLN; Jacni Qin; [email protected] <mailto:[email protected]> > Cc : [email protected] <mailto:[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
