Re: [dhcwg] draft-guo-softwire-sc-discovery-03

[Brian E Carpenter <[e-mail]>]

Thanks Bernie, very helpful.

Regards
   Brian Carpenter

On 2010-03-25 04:43, Bernie Volz (volz) wrote:
> Hi:
> 
> Regarding your draft, I have two comments regarding the formatting of
> options:
> 
> 3.1. DHCPv4 Softwire Concentrator Discovery (SCD) Option
> 
> ...
> 
>    A DHCP message may carry more than one SCD Option.
> 
> 
> Please read http://tools.ietf.org/html/rfc3396 as to why this isn't
> valid and won't work with your currently proposed option layout.
> Multiple instances of an option in DHCPv4 are CONCATENATED and thus any
> encoding that wants 'multiple' instances needs to be formatted that a
> single instance contains the option data and is set up in such a way
> that it can be decoded as multiple instances.
> 
> An easy way to accomplish this would be to add an instance-length byte
> before the Tunnel Type field that indicates how long this instance is.
> That way, multiple instances can be encoded (code, len, instance1-len,
> instance1-data, [instance2-len, instance2-data, [...]]).
> 
> Note that in DHCPv6 multiple instances are perfectly valid and are NOT
> concatenated.
> 
> 
> However, for the DHCPv6 options, suboptions MUST be encoded in DHCPv6
> option format. This means 16-bit suboption code, 16-bit suboption
> length. Please do NOT define yet another format for clients and servers
> to support - DHCPv6 uses 16-bit fields.
> 
> - Bernie
> 
>