Subject: Universal RA option draft

From: Ole Troan <[email-masked]>
Date: Mon, 17 Dec 2018 11:20:32 +0100

Hello,

For another tack on the RA configuration options, I just posted the following draft:
https://datatracker.ietf.org/doc/draft-troan-6man-universal-ra-option/?include_text=1

It proposes an experiment, where change control by the IETF is significantly relaxed, and the option format is self describing and in an “infinite” name space.
The experiment is to see if chaos ensues or not.

Best regards,
Ole

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 17 Dec 2018 13:30:46 +0100

draft-troan-6man-universal-ra-option:
> Was any of the
>    options implemented and deployed?

Any licensing conditions?

Alex

Le 17/12/2018 à 11:20, Ole Troan a écrit :
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Mark Smith <[email-masked]>
Date: Mon, 17 Dec 2018 23:46:11 +1100

> The experiment is to see if chaos ensues or not.

The chaos isn't in the defining the RA options in the IETF, it is the
amount of additional effort that would be imposed on network operators
to upgrade routers' firmware to support new RA options as they're
defined and then requested by end-users on any medium to large scale.
This is assuming that the router vendor firmware supporting the new
option is available when you need it, rather than either in 6 months
time, or never.

The network and services that use it are supposed to be decoupled, so
that deploying a new service doesn't require upgrading the network -
RFC 4924:

"Networks that provide oblivious transport enable the
   deployment of new services without requiring changes to the core.  It
   is this flexibility that is perhaps both the Internet's most
   essential characteristic as well as one of the most important
   contributors to its success."

Using RA options to configure applications is tightly coupling
together the network and the services that operate over it.

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 17 Dec 2018 22:17:29 +0900

> together the network and the services that operate over it.

That problems seem straightforward to solve. Just specify a RADIUS framing
for arbitrary RA options.

---

From: Ole Troan <[email-masked]>
Date: Mon, 17 Dec 2018 14:20:17 +0100

Mark,

> option is available when you need it, rather than either in 6 months

Any sane implementation of this option would of course let the user specify the JSON objects directly.
So the router support is a one-off for option 42.

Cheers,
Ole

---

From: Simon Hobson <[email-masked]>
Date: Mon, 17 Dec 2018 14:15:18 +0000

> Any sane implementation of this option would of course let the user specify the JSON objects directly.

It could be argued that any sane implementation would apply (at the very least) syntax checking, and ideally full semantics checking. Allowing free-form text entry is guaranteed to cause problems. I know you can do some checking (that the basic JSON is valid in syntax) - but without per-option knowledge (and we're back to vendor support again) it could well be valid JSON with complete gibberish in it.
What does a device do if (or rather, when) it gets an RA with an invalidly built option in it ?

---

From: Ole Troan <[email-masked]>
Date: Mon, 17 Dec 2018 15:24:08 +0100

Simon,

> On 17 Dec 2018, at 15:15, Simon Hobson <[email-masked]> wrote:
> 

The host must do validation. 
There is no expectation that the router would. I could add text stating that unparsable json should be dropped.

As both a router implementor as an IETF participant, the goal is to never hear about configuration options ever again. :-)

Ole

---

From: Erik Kline <[email-masked]>
Date: Mon, 17 Dec 2018 12:48:48 -0800

LGTM.  This seems like PVD info for implicit PVDs.  =)

A few thoughts.

[1] 2 years may be just a bit too short, but any other number I might think
to suggest (3-5) could be similarly critiqued.

[2] some text w.r.t. splitting across RAs?

In light of the last paragraph of
https://tools.ietf.org/html/rfc4861#section-6.2.3 what should a router do
with this option (especially since this one option alone could grow beyond
$MTU)?

On Mon, 17 Dec 2018 at 02:20, Ole Troan <[email-masked]> wrote:

> It proposes an experiment, where change control by the IETF is
> significantly relaxed, and the option format is self describing and in an
> “infinite” name space.

---

From: Ole Troan <[email-masked]>
Date: Mon, 17 Dec 2018 22:15:44 +0100

> LGTM.  This seems like PVD info for implicit PVDs.  =)

You could of course encode PVD options this way too. :-)

> A few thoughts.
> 
> [1] 2 years may be just a bit too short, but any other number I might think to suggest (3-5) could be similarly critiqued.

Indeed. RFC5006 (experimental) took from July 2003 until September 2007.

> In light of the last paragraph of https://tools.ietf.org/html/rfc4861#section-6.2.3 what should a router do with this option (especially since this one option alone could grow beyond $MTU)?

Yes, if there ever was support to doing something like this, we can add that.
A single option is limited to about 2K, you could put multiple options in a packet, split options across packets or even fragment (sic!)

Cheers,
Ole

---

From: Erik Kline <[email-masked]>
Date: Mon, 17 Dec 2018 13:26:03 -0800

> A single option is limited to about 2K, you could put multiple options in
> a packet, split options across packets or even fragment (sic!)
>

It's not clear to me how that would work given the current protocol
semantics.  You would need to know the order of fragment reconstruction.

RA1: { "ietf": "dns": {
RA3: } }
RA2: "rdnss": [ "2001:db8::1", "2001:db8::2" ]

If you received the above fragments in this order you *could* try to stitch
together all possible orderings until the JSON parser was happy.  But I
think it would be easy to construct a scenario where that approach wouldn't
work. And then there's what to do if you never hear RA2 at all (given that
RA1 and RA3 could parse together just fine)...

But perhaps that's also for future work (which itself would imply that
Section 2 success criteria had been met/exceeded).

---

From: Ole Troan <[email-masked]>
Date: Mon, 17 Dec 2018 22:37:52 +0100

Erik,

> It's not clear to me how that would work given the current protocol semantics.  You would need to know the order of fragment reconstruction.
> 
> RA1: { "ietf": "dns": {
> RA3: } }
> If you received the above fragments in this order you *could* try to stitch together all possible orderings until the JSON parser was happy.  But I think it would be easy to construct a scenario where that approach wouldn't work. And then there's what to do if you never hear RA2 at all (given that RA1 and RA3 could parse together just fine)…

I would either use IP fragments. Or have each option be self contained within a single packet.

RA1: {“ietf”: “dns”: {}}
RA2: {“ietf”: “pvd”: {}}

and so on. 

>  
> But perhaps that's also for future work (which itself would imply that Section 2 success criteria had been met/exceeded).

Perhaps. ;-)

Cheers,
Ole

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 18 Dec 2018 14:02:48 +0100

If the conditions of implementations are fine (IPR, licensing, etc)

Why JSON and not ASN1?

JSON cleartext in RA is wonderful for exploring implementers who can see 
ASCII, another Universal format.

But numerous JSON accolades and brackets may overload less permissive links.

I must say I dont know whether it is possible to generate some more 
compressed format out of JSON.

This is why I suggest in specification to use ASN.1, and leave open the 
question of sending cleartext or compressed (JSON, XML, compressed GZIP, 
or Unaligned Packed Encoding and why not a new encoding called 'IPv6 
padded octet-aligned format').

This is the automatically generated ASN1 schema from the JSON Example in 
the draft (with a freely available JSON-to-ASN1 web tool).  I suggest to 
use this in the draft, rather than JSON.
> GeneratedSchema DEFINITIONS AUTOMATIC TAGS ::= BEGIN
> GeneratedType ::= SEQUENCE {
>     ietf SEQUENCE {
>         dns SEQUENCE {
>             dnssl SEQUENCE OF UTF8String,
>             lifetime INTEGER,
>             rdnss SEQUENCE OF UTF8String
>         },
>         nat64 SEQUENCE {
>             lifetime INTEGER,
>             prefix UTF8String
>         }
>     }
> }
> END

Alex

---

From: Philip Homburg <[email-masked]>
Date: Tue, 18 Dec 2018 14:06:51 +0100

> compressed format out of JSON.

The relevant IETF standard would be CBOR (RFC 7049)

---

From: Ole Troan <[email-masked]>
Date: Tue, 18 Dec 2018 14:27:17 +0100

> The relevant IETF standard would be CBOR (RFC 7049)

Indeed. ASN.1 was a blast from the past. ;-)
I did think about putting in a encoding field. On the other hand this is just control plane traffic.
I put focus on ease of implementation, and for reading the option, not for wire image efficiency.

Cheers,
Ole

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 18 Dec 2018 15:04:49 +0100

>> The relevant IETF standard would be CBOR (RFC 7049)

Thanks I did not know it.  So that would be a CBOR option in RA, not JSON.

> Indeed. ASN.1 was a blast from the past. ;-)

ASN.1 blast from the past yes - there is an RFC about translating from 
the past ASN.1 to present. "ASN.1 Translation".

> I put focus on ease of implementation, and for reading the option, not for wire image efficiency.

Yes ease of implementation is very important.  To that end, if there 
were an ASN.1 schema, isntead of a JSON text, and if licensing 
conditions were fine, then I could provide a howto about how to 
implement with open source.

Control plane traffic: yes, but it would be hard to imagine too many 
options in a huge JSON RA.

I think a JSON RA containing a DNS server address, a delegated prefix 
and an on-link prefix (plus a few other fields I would like to propose) 
would be too long for IoT Routers.

Alex

---

From: Philip Homburg <[email-masked]>
Date: Tue, 18 Dec 2018 15:18:17 +0100

>would be too long for IoT Routers.

In my opinion, we should stop inventing new subsets of DHCP. So a bad encoding
seems fine for an experiment.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 18 Dec 2018 15:31:46 +0100 (CET)

> for wire image efficiency.

Considering the problems with fragmented RAs and SAVI etc, I'd like to 
keep RAs generally under 1280 total packet size. In the PVD work we 
discussed this, and I think the consensus around the table when discussing 
this that RA option size should be kept at a minimum so encoding 
efficiency for anything that goes into RA should be kept high.

I've had proponents for DHCPv6 stateless use exactly that argument, that 
DHCPv6 messages can be fragmented whereas RAs cannot (which I agree with, 
let's not do that).

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Philip Homburg <[email-masked]>
Date: Tue, 18 Dec 2018 16:16:52 +0100

>DHCPv6 messages can be fragmented whereas RAs cannot (which I agree with, 

I guess that for DHCPv6 stateless it is probably be possible to come up with
a mechanism that reports that the full message would be fragmented and the
tell the client to resubmit with fewer options.

(I think it is best to try to kill all use of the fragmentation header)

---

From: Sander Steffann <[email-masked]>
Date: Tue, 18 Dec 2018 16:36:49 +0100

Hi,

> Op 18 dec. 2018, om 14:06 heeft Philip Homburg <[email-masked]> het volgende geschreven:
> 

I was discussing exactly this with Ole before he submitted the draft. It would be interesting to see how much space is actually saved by using CBOR instead of JSON with all optional white space stripped.

Anyway, whatever encoding is chosen, I hereby volunteer to write code for Wireshark to decode the option so it becomes easier to experiment/debug/etc.

Cheers,
Sander

---

From: Ole Troan <[email-masked]>
Date: Tue, 18 Dec 2018 16:37:40 +0100

With RAs you just send multiple messages. Sized to the MTU. 

But are we seriously thinking of sending RAs with many thousands of bytes?

Cheers 
Ole

> On 18 Dec 2018, at 15:31, Mikael Abrahamsson <[email-masked]> wrote:
> 
> Considering the problems with fragmented RAs and SAVI etc, I'd like to keep RAs generally under 1280 total packet size. In the PVD work we discussed this, and I think the consensus around the table when discussing this that RA option size should be kept at a minimum so encoding efficiency for anything that goes into RA should be kept high.
> 
> I've had proponents for DHCPv6 stateless use exactly that argument, that DHCPv6 messages can be fragmented whereas RAs cannot (which I agree with, let's not do that).
> 
> --

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 18 Dec 2018 16:39:46 +0100 (CET)

> But are we seriously thinking of sending RAs with many thousands of bytes?

I have no idea what people might want to put into these packets. I do hope 
we do not plan to send RAs that big. If someone does, then we need to 
discuss if there is a better way to solve whatever deployment scenario 
someone is trying to do with that much information in RAs.

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Tue, 18 Dec 2018 17:23:34 +0000

> Considering the problems with fragmented RAs and SAVI etc, I'd like to keep
> RAs generally under 1280 total packet size

Perhaps consider Google's protobuf (version 3)
https://developers.google.com/protocol-buffers/docs/reference/proto3-spec

It's extremely efficient on the wire, very simple, and available in open source for many languages.
But it does have the downsides of (1) not a "standard", and (2) not invented here.
Barbara

---

From: Simon Hobson <[email-masked]>
Date: Tue, 18 Dec 2018 18:51:43 +0000

> With RAs you just send multiple messages. Sized to the MTU.

Just throwing random thoughts in the air ...
Would it be valid for a "device" to send an RA with no addressing or routing information ? The reason ...

> But are we seriously thinking of sending RAs with many thousands of bytes?

Well the example given seems to expand a few bytes by orders of magnitude. It doesn't need much imagination to see that if the plan is to send all sorts of information that's previously (in IPv4 world) been done with DHCP then the size could quickly mount up.
For example, if you have SIP phones, then it's common to serve up SIP related information to them - even if it's only a configuration URL.
For diskless devices, it's common to send them bootup information.
Etc, Etc

So, instead of a router sending out huge packets with all the options any device on the network may need - could the phone system (or a proxy for it) send "RA"s with just the SIP config info, another device send "RA"s with just the bootup information for the diskless devices, etc, etc.

Thinking about SIP, I've worked with clients where most devices are provisioned by (in this case) a Windows DHCP server, while the PBX ran it's own DHCP server which provisioned the phones. In this specific case there was no conflict since the phones were pre-configured to only listen to the PBX DHCP server, and the PBX was pre-configured to only serve the phones ("closed" system so the vendor controlled both parts). In the general case, it would need more work to run two (IPv4) DHCP servers, but there being multiple devices sending RAs is part of the standard in IPv6 world.

So if it's "valid" to send an RA with no addressing or routing information, then such a universal option would allow devices to send config info for the subset of devices & information they are responsible for - eg a VoIP PBX configuring the phone handsets.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 19 Dec 2018 08:41:43 +1300

> I put focus on ease of implementation, and for reading the option, not for wire image efficiency.

CBOR is fine for that, and the various CBOR libraries make implementation easy. It supports JSON nicely but there's no need to restrict the content to JSON, and CBOR diagnostic format is readable. You can specify the syntax in CDDL. And CBOR is fine for constrained devices.

In fact, if your goal is to encode the contents of the kitchen sink, I can't think of a better solution than CBOR.

   Brian

---

From: Erik Kline <[email-masked]>
Date: Tue, 18 Dec 2018 11:59:29 -0800

On Tue, 18 Dec 2018 at 11:42, Brian E Carpenter <[email-masked]>
wrote:

> CBOR is fine for that, and the various CBOR libraries make implementation
> easy. It supports JSON nicely but there's no need to restrict the content
> to JSON, and CBOR diagnostic format is readable. You can specify the syntax
> in CDDL. And CBOR is fine for constrained devices.
>
> In fact, if your goal is to encode the contents of the kitchen sink, I
> can't think of a better solution than CBOR.
>
>
+1 for CBOR over JSON

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Tue, 18 Dec 2018 20:02:24 +0000

CBOR is used in a growing number of focused areas, e.g., the DTN program recently
adopted CBOR for the Bundle Protocol version 7 spec:

https://www.ietf.org/id/draft-ietf-dtn-bpbis-12.txt

Fred

> -----Original Message-----
> From: ipv6 [mailto:[email-masked]] On Behalf Of Brian E Carpenter
> Sent: Tuesday, December 18, 2018 11:42 AM
> To: Ole Troan <[email-masked]>; Philip Homburg <[email-masked]>
> Cc: Alexandre Petrescu <[email-masked]>; 6man WG <[email-masked]>
> Subject: Re: Universal RA option draft - ASN1 and not JSON in specification
> 
> CBOR is fine for that, and the various CBOR libraries make implementation easy. It supports JSON nicely but there's no need to restrict
> the content to JSON, and CBOR diagnostic format is readable. You can specify the syntax in CDDL. And CBOR is fine for constrained
> devices.
>

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 19 Dec 2018 14:20:55 +1300

FYI, the example given in the draft is 148 bytes long as JSON text (without whitespace) and 117 bytes encoded in CBOR using the Python cbor module. If MTU size is a concern, that's a useful saving. You could save more by reducing readability.

Regards
   Brian

---

From: Tim Chown <[email-masked]>
Date: Wed, 19 Dec 2018 13:02:52 +0000

> On 18 Dec 2018, at 15:39, Mikael Abrahamsson <[email-masked]> wrote:
> 
> I have no idea what people might want to put into these packets. I do hope we do not plan to send RAs that big. If someone does, then we need to discuss if there is a better way to solve whatever deployment scenario someone is trying to do with that much information in RAs.

Is there a length limitation to the IPv6 RA RickRoll option defined in https://tools.ietf.org/html/rfc7710#section-2.3 ?  I think URIs can exceed the length of a typical access network MTU.

Tim

---

From: Ole Troan <[email-masked]>
Date: Wed, 19 Dec 2018 14:12:42 +0100

Tim,

> Is there a length limitation to the IPv6 RA RickRoll option defined in https://tools.ietf.org/html/rfc7710#section-2.3 ?  I think URIs can exceed the length of a typical access network MTU.

Max length of option is 256*8 ish.

And if your URI is longer than the MTU… well, IP fragmentation. Alternatively if it hurts hitting head in wall, stop?

Ole

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 19 Dec 2018 14:54:07 +0100 (CET)

On Wed, 19 Dec 2018, Ole Troan wrote:

> And if your URI is longer than the MTU… well, IP fragmentation.

Seems we forbid that since 2013.

https://tools.ietf.org/html/rfc6980

5.  Specification

    Nodes MUST NOT employ IPv6 fragmentation for sending any of the
    following Neighbor Discovery and SEcure Neighbor Discovery messages:

    o  Neighbor Solicitation

    o  Neighbor Advertisement

    o  Router Solicitation

    o  Router Advertisement

    o  Redirect

    o  Certification Path Solicitation

---

From: 神明達哉 <[email-masked]>
Date: Wed, 19 Dec 2018 09:52:53 -0800

At Wed, 19 Dec 2018 14:54:07 +0100 (CET),

> Seems we forbid that since 2013.

It's actually (effectively) forbidden almost from the beginning of
ND.  RFC4861 states:

   The size of an ND packet including the IP header is limited to the
   link MTU.  When adding options to an ND packet, a node MUST NOT
   exceed the link MTU.

and essentially the same text has been in the spec since RFC1970.

BTW, I'd wonder how a router implements the consistency check for this
option:

   Routers SHOULD inspect valid Router Advertisements sent by other
   routers and verify that the routers are advertising consistent
   information on a link.  Detected inconsistencies indicate that one or
(Section 6.2.7 of RFC4861)

Maybe it's already sufficiently unrealistic for newer options like
those defined in RFC8106, but this universal option is even more
flexible and even routers that support the syntax of the option can be
agnostic about its real semantics, I suspect it's nearly impossible to
check the consistency.

--
JINMEI, Tatuya

---

From: Sander Steffann <[email-masked]>
Date: Thu, 20 Dec 2018 12:26:41 +0100

Hi,

> FYI, the example given in the draft is 148 bytes long as JSON text (without whitespace) and 117 bytes encoded in CBOR using the Python cbor module. If MTU size is a concern, that's a useful saving.…

Thanks Brian! Useful information.
Sander

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 21 Dec 2018 10:03:40 +0100

that (JSON vs CBOR encoding of RA: 148 bytes vs 117 bytes) is indeed 
useful information for me too.

To add, if I understand correctly: CBOR could be an encoding out of 
ASN.1 specification, instead of a competitor to ASN.1 (the CBOR RFC 
seems to present it so).

That means: could write the I-D containing the ASN.1 spec ('grammar', 
'schema'), and leave open whether the encoding out of that spec is in 
CBOR, JSON, XML or IPv6-padded-aligned-octets.  Automated software tools 
could be improved to generate CBOR output from ASN.1, or IPv6-aligned 
output (they already output JSON, XML and similar).

I think this could be a good way.

Alex

Le 20/12/2018 à 12:26, Sander Steffann a écrit :
> Hi,
> 
>> FYI, the example given in the draft is 148 bytes long as JSON text
>> (without whitespace) and 117 bytes encoded in CBOR using the Python
>> cbor module. If MTU size is a concern, that's a useful saving. You
>> could save more by reducing readability.
> 
> Thanks Brian! Useful information. Sander
> 
> IETF IPv6 working group mailing list [email-masked] Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: Ole Troan <[email-masked]>
Date: Fri, 21 Dec 2018 10:26:48 +0100

Taking Brian’s suggestion of schema language (CDDL).

This good look something like this (if we stick with JSON compliant types).

ietf-object = {
  ? dns : dns
  ? nat64: nat64
  ? ipv6-only: bool
  ? pvd : pvd
  ? mtu : uint
  ? rio : rio
}

dns = {
  dnssl : dnssl
  rdnss : rdnss
  ? lifetime : uint
}
rdnss = {
  ipv6-addresses : [* tstr]
}
dnssl = {
  domain-names : [* tstr]
}

nat64 = {
  prefix : tstr
  ? lifetime : uint
}

pio = {
  prefix : tstr
  preferred-lifetime : uint
  valid-lifetime : uint
  a-flag : bool
  l-flag : bool
}

rio_route = {
  prefix : tstr
  preference : (0..3)
  ? lifetime : uint
}
rio = {
  routes : [+ rio_route]
}

pvd = {
  fqdn : tstr
  ? dns : dns
  ? nat64: nat64
  ? pio : pio
}

Cheers,
Ole

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 21 Dec 2018 10:37:47 +0100

Hi Alexandre,

On Dec 21, 2018, at 10:03, Alexandre Petrescu <[email-masked]> wrote:
> 
> that (JSON vs CBOR encoding of RA: 148 bytes vs 117 bytes) is indeed useful information for me too.
> 
> To add, if I understand correctly: CBOR could be an encoding out of ASN.1 specification, instead of a competitor to ASN.1 (the CBOR RFC seems to present it so).

ASN.1 the data description language (“Abstract Syntax Notation”) needs “encoding rules” to map a specification to an encoding.  Because of the substantial idiosyncrasies of ASN.1, mapping an ASN.1 specification to JSON or CBOR is not trivial.  I don’t think anybody has done that work yet, and I also don’t think would be likely to be used much with the general perception that ASN.1 is no longer a preferred data description language.

> That means: could write the I-D containing the ASN.1 spec (‘grammar', 'schema'), and leave open whether the encoding out of that spec is in CBOR, JSON, XML or IPv6-padded-aligned-octets.  

Again, the work of mapping the ASN.1 spec to the specific serialization would need to be done (it has been done for XML, the “XML Encoding Rules”, but please have a look to see if you like the outcome).

> Automated software tools could be improved to generate CBOR output from ASN.1, or IPv6-aligned output (they already output JSON, XML and similar).

I think it is more likely that people will use a data description language such as CDDL for JSON/CBOR-like data descriptions.  As of today, the CDDL spec (which is in IESG processing) is in use in ~ 25 I-Ds and several RFCs (8007, 8152, 8428).  There is, of course, also the possibility to use YANG as such a data description language (both JSON and CBOR mappings exist).

Grüße, Carsten

---

From: Ole Troan <[email-masked]>
Date: Fri, 21 Dec 2018 11:18:08 +0100

> On 21 Dec 2018, at 10:26, Ole Troan <[email-masked]> wrote:
> 

s/good/could

I didn’t mean to imply it looked good. Only that it could look like this.

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 21 Dec 2018 16:47:49 +0100

Le 19/12/2018 à 18:52, 神明達哉 a écrit :
> Mikael Abrahamsson <[email-masked] <mailto:[email-masked]>> wrote:
> 

I think the consistency of the Universal RA option check could be made 
only on the values of Type and Length.  If the Type is not in the IANA 
list of Types then discard (in assembly, this comparison is a CMP, and 
in hw it's a XOR operation - they're a little costly, but it's just 
one).  If the value of the Length field is beyond the packet length (as 
offered by the driver) then discard.

More consistency checks (like grammar checks on the JSON syntax of the 
payload) is  probably too heavy to happen at each packet. (parsing can 
be NP complete at times).

This is why I read that 'consistency check' of RFC4861 to be something 
happening only on the Type and Length fields, not on the Value.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 21 Dec 2018 17:01:30 +0100

> But are we seriously thinking of sending RAs with many thousands of bytes?

It can happen that one wants to send something very small but uses a lot 
of embelishments.

An RA containing a default route just says this: a 16 byte address.  But 
the length of that RA is 194 bytes.

By the same scaling factor, we can expect an RA that communicates the 
default route (16byte), the delegated prefix (24byte), the DNS resolver 
(16byte), the Prefix Information Option (24byte) can hit the MTU 1280 bytes.

To that, one should add the 'decoration' in the form of speaking a 
particular language like JSON.

For a word like "fe80::1" (7byte) JSON would add at least a bunch (4, 
6?) of brackets ('{', '[') and 1 or 2 keywords ('nat64', 'lifetime', 
'prefix'). Total 32 bytes for just one paramter (the address).

This would easily bring it above the MTU.

This calculation is speculative and not precise enough.  For this 
reason, maybe the way things get encoded in the RA (CBOR, 
IPv6-octet-padded, UPER) could be left out for later: either we agree to 
use a particular encoding (certainly not JSON), or we put a field that 
specifies the encoding.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 21 Dec 2018 17:10:59 +0100

> Taking Brian’s suggestion of schema language (CDDL).

CDDL can output CBOR encoding.  That can make for short RAs that are 
accommodated ok by less permissive links.

The problem could be that CDDL could not output a clear text like JSON 
or pure ASCII.  JSON and ASCII are ok on more permissive links like 
Ethernet.  Why should Ethernet people use compressed formats on hugely 
capable Ethernet links (MTU 10k?)

I wonder what is the software available to speak CDDL.

For ASN.1 there is some open source available, like asn1c package.

>    preferred-lifetime : uint

It's good to know.

I am happy to see rio there.  I would like to extend that 'rio' to tell 
that it can be - optionally - accepted by a router.  (at this time RIO 
can only be accepted by a Host, its RFC says).  I suggest this to be 
made part of it:

rio_route-router = {
    prefix : tstr
    preference : (0..3)
    ? lifetime : uint
}

Alex

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 21 Dec 2018 18:24:01 +0100

On Dec 21, 2018, at 17:10, Alexandre Petrescu <[email-masked]> wrote:
> CDDL can output CBOR encoding.  

That’s not how it works.
CDDL can describe data structures that can be serialized in CBOR.
(There are 50-something implementations of CBOR for 20 programming languages, by the way; see http://cbor.io/impls.html .)

Implementations that generate and consume CBOR data items usually do not employ CDDL at the implementation level, just as it is rare (but by now possible!) to use an ABNF parser generator to read your mail.

The same data structures can also be serialized in JSON, unless they use generic data model elements that aren’t serializable in JSON (CBOR’s generic data model is a superset of JSON’s which is in turn a superset of I-JSON, the data model most of us use with JSON).  Ole’s example didn’t.

> The problem could be that CDDL could not output a clear text like JSON or pure ASCII. 

JSON (unless you employ beyond-ASCII characters in its strings) already is pure ASCII.

>  JSON and ASCII are ok on more permissive links like Ethernet.  Why should Ethernet people use compressed formats on hugely capable Ethernet links (MTU 10k?)

I don’t have an Ethernet with an MTU of 10k.

> I wonder what is the software available to speak CDDL.

Your code doesn’t have to speak CDDL, it speaks CBOR (or JSON).

> For ASN.1 there is some open source available, like asn1c package.

ASN.1 needs such software because of the tight binding between the serialization (e.g., basic encoding rules BER) and the ASN.1 specification system.  No such need for CBOR or JSON.

(ASN.1 did not have open source software until about year 20 of its life.  Although CDDL is much younger, there already is some software for it.  But again, you are not stuck with actually having to tie your program to such CDDL software in the same way you are with ASN.1.)

Grüße, Carsten

---

From: Raymond Burkholder <[email-masked]>
Date: Fri, 21 Dec 2018 11:26:07 -0700

On 2018-12-18 7:04 a.m., Alexandre Petrescu wrote:
> Thanks I did not know it.  So that would be a CBOR option in RA, not 
> JSON. Indeed. ASN.1 was a blast from the past. ;-)

I've followed along most of the discussion, and recent entries are 
getting into the nuts and bolts.  So I decided to reply to a message 
early in the sequence near where the discussion started.

As an implementor, I am very concerned about this.  I'd say TLV style 
encoding is the mainstay in many RFC's.  Encoding/Decoding against the 
RFC specification is 'reasonably' easy.

I think we have to remember that this is very low level communications 
and has to work with many different devices: small embedded/limited cpu 
devices, to the, well, more powerful.

Having to add JSON or ASN1 or CBOR libraries makes light-weight packet 
encoding/decoding ... cumbersome.

'ease of implementation' has different connotations, depending upon the 
implementor.  In my mind, and based upon recent experience of 
encoding/decoding various low level wire based protocols, JSON or ASN or 
CBOR won't be 'easy'.  I can deal with TLV.

Raymond Burkholder

> and an on-link prefix (plus a few other fields I would like to 
> propose) would be too long for IoT Routers.

Long and complex for the type of embedded software implementors who work 
with IoT style devices.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 22 Dec 2018 08:39:51 +1300

Raymond,

...
> encoding/decoding ... cumbersome.

That is certainly true of ASN1. In many cases these days, JSON libraries
are already loaded, but obviously a text format is always going to be
heavier to handle. However, I think you're specifically wrong for CBOR,
where there are lightweight libraries available.

> CBOR won't be 'easy'.  I can deal with TLV.

CBOR is a bit less transparent than TLV, it's true. But a lot more
flexible and easily extensible. To take a simple example, in TLV you
must define a type code field as, say, 8 bits long, with an escape
code if you need more than 255 values. In CBOR you define it as an
integer and its length automatically adjusts.

By the way, when we switched the GRASP protocol design from TLV to CBOR,
we did evaluate the impact on message size for a worked example, and the
size difference was +3% to -3% depending on assumptions.

Regards
    Brian Carpenter

---

From: Ole Troan <[email-masked]>
Date: Fri, 21 Dec 2018 20:51:15 +0100

Right CBOR seems easier to parse than text, and adds only a one off cost at the sender. 

They goal here is to:
 - be able to define new options without code changes on the router 
 - define new options without requiring an rfc

Cheers 
Ole

> On 21 Dec 2018, at 20:39, Brian E Carpenter <[email-masked]> wrote:
> 
> Raymond,
> 
> ...

---

From: Raymond Burkholder <[email-masked]>
Date: Fri, 21 Dec 2018 13:47:19 -0700

> where there are lightweight libraries available.
I did a quick look at the RFC and and at some of the open source 
libraries, one of which I use in a different aspect, but most are 
reasonably small and appear easy to work with.

I appreciate the fact that CBOR handles binary values natively.

If I had to throw my hat into the ring, it would be for CBOR.

The only drawback I see is that many RFC's I've decoded have been 
concerned about word alignment.  Is that concern of value?

And since this is an ipv6 group, would the standard be extended for an 
ipv6 address with optional prefix?  RFC7049, as I read it doesn't have a 
16/17 byte structure.  Maybe I missed the discussion of that as I was 
still getting my head wrapped around the concept of adding a 
serializer/deserializer library to packet interpretation.

Raymond.

---

From: Ole Troan <[email-masked]>
Date: Fri, 21 Dec 2018 22:07:27 +0100

Raymond,

> I did a quick look at the RFC and and at some of the open source libraries, one of which I use in a different aspect, but most are reasonably small and appear easy to work with.
> 
> The only drawback I see is that many RFC's I've decoded have been concerned about word alignment.  Is that concern of value?
> 
> And since this is an ipv6 group, would the standard be extended for an ipv6 address with optional prefix?  RFC7049, as I read it doesn't have a 16/17 byte structure.  Maybe I missed the discussion of that as I was still getting my head wrapped around the concept of adding a serializer/deserializer library to packet interpretation.

The revision 01 (not posted) follows CDDL limited to https://tools.ietf.org/html/draft-ietf-cbor-cddl-06#appendix-E

It is limited to the types in JSON. So an IPv6 prefix would be represented as a string. “2001:db8::/32”.
We could add binary types. But then we cannot directly represent it in JSON anymore.

Cheers,
Ole

---

From: Raymond Burkholder <[email-masked]>
Date: Fri, 21 Dec 2018 14:47:31 -0700

> We could add binary types. But then we cannot directly represent it in JSON anymore.

Does that mean that there is consideration being given to serializing 
everything as text?  That would be some thing more to think about as 
this then requires text/binary conversions at this low layer of the 
protocol stack.  Unless, of course, I am mis-understanding use-cases.

In the compiled language realm in which I work, when considering these 
low level protocols, I have been used to moving fields directly between 
native binary data structures and their relevant wire format.  I would 
have thought that the tricky bits of converting to and from shortened 
string representations would happen higher up in the call stack, nearer 
the human interface?  If this binary <-> text representation becomes 
required, any decent c/c++ parsers for ipv6 text representations out there?

---

From: Ole Troan <[email-masked]>
Date: Fri, 21 Dec 2018 22:57:19 +0100

> Does that mean that there is consideration being given to serializing everything as text?  That would be some thing more to think about as this then requires text/binary conversions at this low layer of the protocol stack.  Unless, of course, I am mis-understanding use-cases.

I probably shouldn’t have put PIO/RIO options in my CDDL example.
The use case here, if there is one, this is a proposed experiment,  is for using RAs as a generic transport for any configuration option. Typically not directly related to configuring the network layer. Stuff which really belongs in service discovery.

> In the compiled language realm in which I work, when considering these low level protocols, I have been used to moving fields directly between native binary data structures and their relevant wire format.  I would have thought that the tricky bits of converting to and from shortened string representations would happen higher up in the call stack, nearer the human interface?  If this binary <-> text representation becomes required, any decent c/c++ parsers for ipv6 text representations out there?

I would imagine the typical case would be that the RA parser just parsed the dictionary in the option, and let higher level code deal with interpreting it.
(You got inet_pton() btw).

Cheers,
Ole

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 22 Dec 2018 14:31:43 +1300

I've changed the subject line to indicate the drift off-topic,
and if the WG chairs tell us to shut up, we could go to the
CBOR list. More below...
> serializer/deserializer library to packet interpretation.

Again referring to what we did in GRASP, we simply encoded an IPv6
address as a byte string. Or in CDDL:
   ipv6-address = bytes .size 16
And in draft-ietf-anima-prefix-management, we chose to represent
a prefix as [length, prefix] where:
   length = 0..128
   prefix = bytes .size 16
This avoids sending addresses as text, which is all you can with JSON.

(I have demo code for all this stuff in Python.)

    Brian

---

From: Alexandre Petrescu <[email-masked]>
Date: Sat, 22 Dec 2018 12:53:46 +0100

Raymond,

Thansk for the reply.

> devices, to the, well, more powerful.

I agree with this perspective fully.  TLV is the mainstay in many RFCs. 
RA kinds of messages are more lower layer, where the cpu and iface 
architecture are very important.

> CBOR won't be 'easy'.  I can deal with TLV.

I agree with the need of TLV.  Let write about ASN.1.

I do not propose to send ASN.1 in the RA.  ASN.1 is a notation to write 
'schemas' (or grammars).  This schema stays in the RFC.  Out of this 
schema one generates text, or XML, or... TLV (an 'encoding').

In the RA goes that 'encoding' (text, XML, or TLV).  Ole said he 
considered adding a field in the RA which specifies which encoding is 
that (JSON, TLV, CBOR, etc), but subsequently discarded the idea.  I 
wonder why he discarded the idea.

The generation of an 'encoding' needs to have a specification.  For 
example, we would need a specification of 'text' encoding.  There 
already exist 'XML' encodings, and 'JSON' encodings.  There already 
exist many encodings that are similar in nature to CBOR; e.g. the 'UPER' 
existing encoding stands for 'Unaligned Packed Encoding': it means the 
values are not aligned on byte boundaries, and so the payload is more 
'packed'.  UPER is very difficult to understand, but it exists, and 
achieves compression.

We would probably need an encoding RFC called 'TLV' which generates the 
TLV encoding (out of ASN.1 schema) as we know it in IPv6: byte-aligned, 
or 32bit aligned, padded with Pad1 and PadN, etc.  I suppose this would 
satisfy the need you express when you say you can deal with TLV.

Finally, two parallels:
- CDDL is to CBOR what ASN.1 is to UPER;
- one uses XML and schemas to write Internet Drafts and then
   generates pdf, or txt, or other formats.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Sat, 22 Dec 2018 12:59:41 +0100

> concerned about word alignment.  Is that concern of value?

Word, and memory, alignment is a huge concern.

Typically constrained links are attached to CPUs who define a word very 
differently than other larger CPUs.  (e.g. you're never sure it's a 
16bit or 32bit or even 8bit; endianness is also a huge issue).

This shows up every now on then on asn1c forum discussions.

Alex

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Sat, 22 Dec 2018 16:09:26 +0000

Hi Alex,

> can only be accepted by a Host, its RFC says).  I suggest this to be

We talk more about RIOs in 'draft-templin-6man-rio-redirect':

https://datatracker.ietf.org/doc/draft-templin-6man-rio-redirect/

In that document, we also define an optional "attributes" extension.
Would that also need to appear here?

Incidentally, RIO with attributes might be useful for the ITS use cases
where some other drafts were proposing the definition of a new ND
option. I think a new ND option is not needed if we can leverage RIO.
What do you think?

Thanks - Fred

---

From: Alexandre Petrescu <[email-masked]>
Date: Sun, 23 Dec 2018 17:35:46 +0100

> option. I think a new ND option is not needed if we can leverage RIO.

Currently we do use some prefixes in RIOs.  We think we may need some 
more attributes than just the existing in RIO, because we dont know how 
these RIOs work when there are more than two cars in a convoy.

In particular, I am almost sure to think that your draft's mentioning of 
an S flag for 'soliciting' a particular prefix in RIO is something worth 
pursuing.

Universal RA - yes, but accompanied by an Universal RS too.

Alex

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Mon, 24 Dec 2018 22:16:39 +0000

Hi Alex,

> Universal RA - yes, but accompanied by an Universal RS too.

Yes, I agree with you. I think we would want a universal option for
any IPv6ND message (RS/RA/NS/NA/Redirect) and not just RA.

Thanks - Fred

---

From: Erik Kline <[email-masked]>
Date: Wed, 26 Dec 2018 12:31:26 -0800

> any IPv6ND message (RS/RA/NS/NA/Redirect) and not just RA.

Of course they need not be in the same document (could be in a subsequent
document).

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Thu, 27 Dec 2018 14:48:06 +0000

Hi Erik,

Why not define a universal option that can be used in any IPv6 ND
message (I.e., and not just RA) while we have the document open
for edits?

Thanks - Fred

From: Erik Kline [mailto:[email-masked]]
Sent: Wednesday, December 26, 2018 12:31 PM
To: Templin (US), Fred L <[email-masked]>
Cc: Alexandre Petrescu <[email-masked]>; IETF IPv6 Mailing List <[email-masked]>
Subject: Re: Universal RA option draft - ASN1 JSON CBOR

On Mon, 24 Dec 2018 at 14:16, Templin (US), Fred L <[email-masked]<mailto:[email-masked]>> wrote:
Hi Alex,

Of course they need not be in the same document (could be in a subsequent document).

---

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

> message (I.e., and not just RA) while we have the document open

Because that would be a very different experiment.
The intent of the proposed option is to allow the use of RAs as an opaque carrier for configuration information.
No code change should be required on either the router or the host side (RA processing), only for the host side application using the configuration information.

If we added this to all ND messages, or went even one step further and created the univeral ICMP option, the use for this option would be to create new protocol machinery. That might be an interesting avenue to explore, but not one I was interested in here.

Ole

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Sat, 29 Dec 2018 15:13:30 +0000

Hi Ole,

> From: Ole Troan [mailto:[email-masked]]
> Sent: Friday, December 28, 2018 12:30 PM
> Cc: [email-masked]; Alexandre Petrescu <[email-masked]>; 6man WG <[email-masked]>

As with any other unrecognized ND option, nodes that don't recognize the option
would simply ignore it and process the rest of the message as if it weren't there.
So, backwards compatibility is built-in and it applies to any IPv6ND message and
not just RA.

> If we added this to all ND messages, or went even one step further and created the univeral ICMP option, the use for this option
> would be to create new protocol machinery. That might be an interesting avenue to explore, but not one I was interested in here.

What would it take to get you interested?

Thanks - Fred

---

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

Fred,

> What would it take to get you interested?

To quote Harari: “Humans were always far better at inventing tools than using them wisely.”

The purpose of the universal RA option was to provide an opaque carrier for configuration information between network and host.
What you are proposing seems to me to have much more far reaching consequences. Wouldn’t what you are proposing a mechanism to create new protocols?
I don’t see how you can do that without some level of standardisation, which was something I wanted to avoid as part of the experiment.

Cheers,
Ole

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Sun, 30 Dec 2018 16:35:56 +0000

HI Ole,

> Sent: Sunday, December 30, 2018 8:04 AM
> >> No code change should be required on either the router or the host side (RA processing), only for the host side application using
> the
> >> configuration information.
> >

Why not call it a "universal ND option" and then, within the context of this document,
discuss its use with RA and leave use with other ND messages as out of scope? That
would be more consistent with the spirit of RFC4861 where options such as S/TLLAO
can be used by any ND message type, and not just RA. (Actually, I think to be
consistent with RFC4861 it would be more correct to call it an ND option and not
an RA option.)

Thanks - Fred

---

From: Sander Steffann <[email-masked]>
Date: Mon, 31 Dec 2018 00:22:50 +0100

Hi Fred,

> consistent with RFC4861 it would be more correct to call it an ND option and not

I see how that would allow other use cases besides the experiment described in Ole's draft. I don't have a problem with that. I do think those other use cases would then deserve/need a draft of their own to describe the other experiments.

Cheers,
Sander