Subject: [Softwires] Review of draft-ietf-softwire-multicast-prefix-option-11

From: Tomek Mrugalski <[email-masked]>
Date: Tue, 10 Jan 2017 17:57:24 +0100

I have reviewed draft-ietf-softwire-multicast-prefix-option-11 and have
one significant and several minor comments.

Major issues:

1. The DHCPv6 option format. The format used (3 prefixes stuffed in a
single option) are not the preferred way to convey this kind of
information. This format is against the recommendation of DHCPv6 Option
Guidelines (RFC7227). See section 5.3 of that RFC. This is not a
nit-pick. There are a number of strong arguments for favouring 3 simple
options over one complex one. Here they are:

- implementing simple option is trivial as this format is already
supported by most DHCPv6 implementations, so it's a matter of extending
existing code to cover additional option codes.

- deploying is easier. Many implementations allow to define this kind of
option with configuration change and no need for software change.

- better handling of optional prefixes. Section 3 says that the
asm-length, ssm-length and unicast-length can be 0. This means that
depending on the deployment, all of those fields are optional. This
would be better handled with separate options that are simply not
configured on the server when not needed.

- better failure recovery. The text in section 2 says that some of the
prefixes are supposed to belong to well known prefixes. What the client
is supposed to do when the server sends a value that does not meet that
criteria? With a single option you'd have some sort of unclear decision
tree to ignore part of the option content. With 3 separate options, it's
simple - ignore the whole option.

Now, there's one complication here: scope preservation. I'm not familiar
with the multicast technologies you're configuring, so I won't make any
specific recommendations here. If you send multiple instances of the
ASM, SSM and prefix64, are they logically grouped together? My
understanding is that the scope is encoded on the second octet of the
multicast address, right? So when you send multiple instances, it should
be possible to preserve the scope by matching whatever scope you have in
IPv4 with the IPv6 prefix with the same scope. I don't claim to know
much about multicast, though. I may be wrong on this.

Now, if you considered all of the above, read RFC7227 and still believe
that having a single option rather than 3 is better way to go, I won't
insist. But you should add an explanation of the benefits of having a
single complex option that outweigh the simplicity proposed by 7227.

Minor issues:

2. The explanation in last paragraph in Section 3 doesn't work for me.
It says one option rather than three are easier to detect environments
where multicastis not enabled. Not configuring 3 options is as simple as
not configuring 1 option. Also, the text references Section 6 of
RFC7051, which only says nothing about one complex vs three simple
options. It just says the DHCPv6 server and client code has to be
modified. If you want to follow that recommendation, using 3 options is
actually easier, because you can configure most clients and server with
custom options. That's a big plus for easier deployment when you can
just tweak the config file and be done rather than needing a new version
of the software.

3. Failure recovery. The text doesn't say what the client is supposed to
do when the server is misconfigured. In particular, if the prefixes are
supposed to belong to well known pools (e.g. a supposedly multicast
prefix that does not start with ff), what to do when they aren't. Should
just that prefix be discarded or the whole option?

4. What's the allowed prefix length is for ASM_PREFIX64 and SSM_PREFIX64
is? Section 4, 2nd paragraph says it must be /96, but section 3 says
allowed values are from 0 to 128. As a DHCPv6 client and server
implementor, I'm confused what sanity checks I'm supposed to implement
here. Those two paragraphs seem to contradict each other.

5. Nit: I would add "DHCPv6" in the title of section 4.

6. Nit: Section 5: "DHCPv6 client MUST include OPTION_V6_PREFIX64 in its
OPTION_ORO." => "DHCPv6 client MUST include OPTION_V6_PREFIX64 code in
its OPTION_ORO".

That's it. IANA asked me to formulate my opinion on this draft no later
than Jan. 17th, so I'd appreciate authors' response before that date.

Tomek

---

From: <[email-masked]>
Date: Wed, 11 Jan 2017 07:23:16 +0000

Hi Tomek, 

Thank you for the review. 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Softwires [mailto:[email-masked]] De la part de Tomek
> Mrugalski
> Envoyé : mardi 10 janvier 2017 17:57
> À : Softwires-wg
> Objet : [Softwires] Review of draft-ietf-softwire-multicast-prefix-option-
> 11
> 

[Med] I'm aware of RFC7227 but the design of one single option is on purpose as recorded in the document: 

   Note that it was tempting to define three distinct DHCPv6 options,
   but that approach was not adopted because it has a side effect: the
   specification of a DHCPv6 option that could be used to discover
   unicast PREFIX64s in environments where multicast is not enabled.
   Such side effect conflicts with the recommendation documented in
   Section 6 of [RFC7051].

We don't want to interfere with unicast-only recommendation in RFC7051. This DHCPv6 option is only used for multicast IPv4 service continuity.   

Note, the encoding of the IPv6 prefix follows the one in https://tools.ietf.org/html/rfc7227#section-5.3. It would be easy to define those as standalone options, but we are not doing that for the reason I mentioned above and for another technical reason that I'm discussing below.  

> ASM, SSM and prefix64, are they logically grouped together?

[Med] The scope is encoded in the multicast prefix itself. 

 My
> much about multicast, though. I may be wrong on this.

[Med] The problem is that distinct IPv4 prefixes may be used for each of these scopes: the issue then is how to associate each multicast prefix and unicast prefix. With the current encoding, this is not an issue.  

> insist.

[Med] Ok, thanks.

 But you should add an explanation of the benefits of having a
> single complex option that outweigh the simplicity proposed by 7227.

[Med] There is already the text I quoted above that calls out this point. Please let me know if you think that more text is needed.   

> just tweak the config file and be done rather than needing a new version

[Med] Actually, I'm not trying to argue in favor or against the text in Section 6 of RFC7051. The key point from that section is: it is recommended to use the Well-Known DNS Name heuristic discovery-based method for unicast-only environments.

I changed the text to make this clear: 

OLD:
   Such side effect conflicts with the recommendation documented in
   Section 6 of [RFC7051].

NEW:
   Such side effect conflicts with the recommendation to support the
   Well-Known DNS Name heuristic discovery-based method for unicast-only
   environments (Section 6 of [RFC7051]).

> just that prefix be discarded or the whole option?

[Med] The checks whether the received prefix is a multicast prefix + (it is in ASM range for ASM, it is in the SSM range for SSM) is up to the multicast library not the DHCP client. We didn't want to overload the client with such processing that is done anyway by the multicast client that will make use of these prefixes.

> here. Those two paragraphs seem to contradict each other.

[Med] ASM_PREFIX64 and SSM_PREFIX64 must be /96. I fixed the text in Section 3. 

> OPTION_ORO." => "DHCPv6 client MUST include OPTION_V6_PREFIX64 code in

[Med] Fixed.

> _______________________________________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires