Re: New Version Notification for draft-troan-6man-universal-ra-option-03.txt

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

On 08-Oct-20 03:47, [e-mail] wrote:
> Philip,
> 
>>> The idea of the encoding is to use a higher level more modern level
>>> abstraction.  Parsing implementation would be done once for all
>>> possible options, and most likely an implementor of the general
>>> option could use existing libraries for that.
>>
>> This means extra code which could be an issue for embedded systems. For 
>> systems that process RAs in the operation system kernel, this may mean linking
>> with a library that potentially causes remotely expoitable security holes.
> 
> The CBOR parser is quite simple. Having one parser for all options is possibly more efficient that having to parse each option separately with it's different representations of IPV6 prefixes etc. Same thing might apply security wise too, although allowing for passing "anything" might also open new security issues in implementation.

I think it's worth re-reading the Abstract of the CBOR spec:

   The Concise Binary Object Representation (CBOR) is a data format
   whose design goals include the possibility of extremely small code
   size, fairly small message size, and extensibility without the need
   for version negotiation.

That's why future embedded systems are highly likely to include a CBOR
encoder/decoder anyway, and as anyone who has used them knows, cbor
loads() and dumps() make life very easy for the programmer.

(I happen to have written a Python package to simulate loads() and dumps() 
for TLVs. That made it possible to play with a direct comparison between
coding a CBOR application or a TLV application for the same purpose.
If you care, https://github.com/becarpenter/tlv )

>>> So while the work of supporting the option infrastructure in itself
>>> is more work than the simple TVL option, 

I'm not sure that's even true.

>>> adding new data to the
>>> option has very little overhead.  The architectural change that
>>> this brings, is that no longer is changes to router operating
>>> systems or the host stack kernel required.  
>>
>> I don't think something like CBOR is required for this. A router can have
>> a setup where an external service supplies options. 
>>
>> The DHCP world never felt the need to come up with a high level encoding and
>> DHCP has a huge number of options.
> 
> No, CBOR isn't required. The original proposal was to carry text encoded JSON objects.
> The previous discussions on this draft resulted in CBOR as a more effective encoding.

Which supports JSON trivially, if needed.

    Brian

> Using CDDL also gives us a modelling language.
> 
>>
>>>> However, the complete syntax for an option still needs the names of fields,
>>>> use of arrays and dicts, etc.
>>>
>>> Right, that's modelled in CDDL in the IANA registry.
>>
>> I don't think it is progress to publish protocols in the IANA registry.
>> The IANA registry should be for code points (private or public) and data
>> extracted from RFCs.
>>
>> I think it would be really bad if IANA would be the sole place where 
>> essential RAs options are decribed. 
> 
> It depends.
> If I develop an application that just needs a configuration option from the network, then fine.
> Like e.g. the boot URL option that's been suggested in 6man.
> If it's an option that revamps the behaviour of the whole host stack, whatever that would be, perhaps not.
> 
>>
>>> Why would an option be "standards track"? Nothing prohibiting
>>> standards track for a universal configuration option either, but
>>> the proposal here is that only expert review is required to define
>>> new options.
>>
>> To give a couple of examples:
>> 1) For some reason we don't have a DHCPv6 option for default router. This is
>>   commonly requested, is not a particularly complex option, and DHCPv6 
>>   has plenty of code points. This is a discussion we should have out in the
>>   open, but as some expert review for an IANA registry.
>>
>> 2) We have a DHCPv6 IA_PD with poorly defined semantics. Again, a simple
>>   option but with complex semantics. This is again a case where we should
>>   have a public discussion.
>>
>> 3) We had an endless discussion about an 'IPV4-only' option. Again this 
>>   requires more discussion than just a bit of expert review.
>>
>> I think that all options that we want to rely on in other RFCs should be
>> standards track. Yes, if some vendor has a private light bulb protocol, it
>> should be easy to get a code point for that. But anything that is required
>> for most routers or hosts should have rough consensus.
> 
> This option would resolve all those discussions. It's partly a proposal to free all the time spent on 6man solutions. ;-)
> (only partly tongue in cheek).
> 
> Best regards,
> Ole
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> .
>