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

[Tomek Mrugalski <[e-mail]>]

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