On Wed, Feb 24, 2010 at 12:04:25AM +0100, Ole Troan wrote: > I took the SHOULD from RFC3315, which has that for the ORO option. I > couldn't find any other DHCP option RFCs with SHOULD or MUST for the > PRL option.
I think many option RFC's do not mention the PRL explicitly (how the client gets the option is a basic DHCP protocol feature in that sense), but in this case I'm a little uncomfortable because the language of the MUST about there being one option is so specific. I think in RFC 3315's case the SHOULD is because the client can elect not to send the ORO at all. I wonder if the reason that there be at most one option is because you may be aware of 'option fragmenting'? In DHCPv4, multiple options of the same option code are concatenated together in order to support options whose data is longer than 255 octets (and it is also handy in letting smaller options be split along the options/file/sname fields if out of space and using option overloading, but these details are why I don't like busying a new option specification with this discussion; it gets confusing fast). It may be simpler to say; Because the OPTION_6RD contains one IPv4MaskLen/6rdPrefixLen/6rdPrefix block, and because DHCP cannot convey more than one instance of an option, OPTION_6RD is limited to provision at most a single 6rd domain. Provisioning of a CE router connected to multiple 6rd domains is outside the scope of this protocol specification. And avoid the normative language entirely (leave all those mechanics entirely up to RFC 2131 conformance)? Anyway, it is just an idea. I'm quite happy with there just being a reminder about the PRL with the existing text. -- David W. Hankins BIND 10 needs more DHCP voices. Software Engineer There just aren't enough in our heads. Internet Systems Consortium, Inc. http://bind10.isc.org/
pgptHO96rtlH6.pgp
Description: PGP signature
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
