Subject: Fwd: New Version Notification for draft-troan-6man-universal-ra-option-01.txt

From: Ole Troan <[email-masked]>
Date: Fri, 28 Dec 2018 21:25:40 +0100

[individual contributor hat firmly on]

New revision of the universal RA option draft. Now with CDDL and CBOR encoding.

I also included all existing options as a suggestion for an alternative encoding of e.g. what’s in intarea PVDs.

And a “there’s absolutely nothing you can possibly trust here” security considerations. ;-)

Cheers,
Ole

> Begin forwarded message:
> 
> From: <[email-masked]>
> Subject: New Version Notification for draft-troan-6man-universal-ra-option-01.txt
> Date: 28 December 2018 at 21:22:39 CET
> To: Ole Troan <[email-masked]>
> 
> 
> A new version of I-D, draft-troan-6man-universal-ra-option-01.txt
> has been successfully submitted by Ole Troan and posted to the
> IETF repository.
> 
> Name:		draft-troan-6man-universal-ra-option
> Revision:	01
> Title:		The Universal IPv6 Router Advertisement Option (experiment)
> Document date:	2018-12-28
> Group:		Individual Submission
> Pages:		7
> URL:            https://www.ietf.org/internet-drafts/draft-troan-6man-universal-ra-option-01.txt
> Status:         https://datatracker.ietf.org/doc/draft-troan-6man-universal-ra-option/
> Htmlized:       https://tools.ietf.org/html/draft-troan-6man-universal-ra-option-01
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-troan-6man-universal-ra-option
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-troan-6man-universal-ra-option-01
> 
> Abstract:
>   One of the original intentions for the IPv6 host configuration, was
>   to configure the network-layer parameters only with IPv6 ND, and use
>   service discovery for other configuration information.  Unfortunately
>   that hasn't panned out quite as planned, and we are in a situation
>   where all kinds of configuration options are added to RAs and DHCP.
>   This document proposes a new universal RA option in a self-describing
>   data format, with the list of elements maintained in an IANA
>   registry, with greatly relaxed rules for registration.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
>

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 29 Dec 2018 14:10:34 +1300

> The option data is described using the schema language CDDL	
> [I-D.ietf-cbor-cddl], with the limitation described in appendix E	
> "Use with JSON" and encoded in CBOR [RFC7049].  The restriction is	
> there to ensure an easy representation in JSON [RFC8259].

Since this is an experiment, could we make this restriction a
SHOULD? 

Why? Because if I encode your example more efficiently but less
legibly in CBOR, using small integers instead of labels, and binary
IPv6 addresses, it gets shorter again:

Raw JSON 148 bytes
CBORized JSON 117 bytes
Non-JSON CBOR 90 bytes

(Trivial Python3 script attached.)

So, I think experiments with and without the JSON restriction would
be of interest.

Regards
   Brian

On 2018-12-29 09:25, Ole Troan wrote:
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Ole Troan <[email-masked]>
Date: Sun, 30 Dec 2018 17:34:59 +0100

Dear Brian,

> So, I think experiments with and without the JSON restriction would

I am not sure about lessening the MUST to a SHOULD.
Wouldn’t that cause interoperability problems for a host stack receiving CBOR that cannot be decoded to JSON?

What if we allowed any valid CBOR map (key/value)?
Then the API would be something like:

dns_cbor = cbor.dumps(o)
router_advertisement.add(sw_if_index, “dns”,  dns_cbor)

Then both the router side and host side applications generating and consuming the configuration information would have to deal with CBOR directly (either decode or encode).
(Implementations could provide JSON convenience wrappers for JSON encodable data.)

This would still allow the option implementation both on router and host side be unchanged, even when new elements that used new tags/types were added.

Cheers,
Ole

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 30 Dec 2018 18:24:46 +0100

> Wouldn’t that cause interoperability problems for a host stack receiving CBOR that cannot be decoded to JSON?

I’m late to this discussion and apparently missed the part where it was divulged why JSON support might be a good idea in the first place.

RA information is often binary in nature and benefits from a compact representation.  For me, this screams for CBOR, but I may be missing something (see above).

Grüße, Carsten

---

From: Ole Troan <[email-masked]>
Date: Sun, 30 Dec 2018 18:36:32 +0100

Carsten,

> RA information is often binary in nature and benefits from a compact representation.  For me, this screams for CBOR, but I may be missing something (see above).

The current drafts says:

  The option data is described using the schema language CDDL   [
  I-D.ietf-cbor-cddl], with the limitation described in appendix E
  "Use with JSON" and encoded in CBOR [RFC7049].  The restriction is
  there to ensure an easy representation in JSON [RFC8259].

Brian suggested relaxing the appendix E restriction. I think that would result in interoperability issues, and suggested we discuss removing the restriction altogether.
The downside is user-friendlyness. User-friendly decoders would require type knowledge either through tags or knowing the CDDL.
Which wouldn’t be required for JSON representation of course.

I’m not sure compact representation matters much. This is low rate control plane traffic after all.

Personally I think I’m fine with any valid CBOR, even though that makes it impossible to provide a good wireshark dissector.
(I’m a little on the fence with regards to CBOR tags. At least tag 260 for IPv6 addresses is broken…)

But given your background here Carsten, I’m more than willing to take your recommendations!

Cheers,
Ole