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 _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
