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

From: Erik Kline <[email-masked]>
Date: Thu, 14 Mar 2019 13:41:16 -0700

Can we have some text about what to do when parsing hits something the
parsed output consumer doesn't understand?  For me, I think just saying
consumers must skip options they don't understand is fine (in other words,
I don't think the rfc8200#section-4.2 skip/discard/discard&icmp/...
complexity is necessarily warranted).

I just ran into a use case where it would be nice to decorate the rio_route
with a path_mtu entry.  In other words, the ietf:mtu entry logically
applies to the link (per rfc4861#section-4.6.4) and by extension everything
on the other side of the "default route" through that router.  But RIOs
could really use a ietf:rio_route:path_mtu attribute.

This would let us express: link mtu = 1500 but if you're trying to reach
2001:db8:tunnel::/48 through this router you should use 1400.

On Fri, 28 Dec 2018 at 12:25, Ole Troan <[email-masked]> wrote:

> [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
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Ole Troan <[email-masked]>
Date: Thu, 14 Mar 2019 22:18:05 +0100

Hi Erik,

> Can we have some text about what to do when parsing hits something the parsed output consumer doesn't understand?  For me, I think just saying consumers must skip options they don't understand is fine (in other words, I don't think the rfc8200#section-4.2 skip/discard/discard&icmp/... complexity is necessarily warranted).

pull requests welcome:
https://github.com/ietf-6man/universal-ra

I was imagining this being implemented in a fashion where an interested party (e.g. application) would register with the host RA received for a particular key, and get notifications with that object. In such a scheme it’s obvious that you wouldn’t process anything if there weren’t any consumers for a particular object. I agree that should be made clear. Would it add value to add suggestions for how this could be implemented?

> I just ran into a use case where it would be nice to decorate the rio_route with a path_mtu entry.  In other words, the ietf:mtu entry logically applies to the link (per rfc4861#section-4.6.4) and by extension everything on the other side of the "default route" through that router.  But RIOs could really use a ietf:rio_route:path_mtu attribute.
> 
> This would let us express: link mtu = 1500 but if you're trying to reach 2001:db8:tunnel::/48 through this router you should use 1400.

Right, and I guess as long as fields were optional you could add them to existing objects.
(If they were mandatory, you could just create a new object.)

Tying MTU discovery to routing is something we should have done a long time ago. Thank you.

Cheers,
Ole

> 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]>
>> 
>> 
>> 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:
>> Please note that it may take a couple of minutes from the time of submission

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 15 Mar 2019 08:32:18 +0100

Hi,

I have a high-level question.

Given an unsuccessful earlier attempt to Expand the RA, how can we make 
sure this new direction to Universality avoids the same fate?

My probably limited understanding is that the RA Flags Expansion option 
(RFC 5175, year 2008) has seen only limited deployment:
- it is not implemented in the linux kernel (I dont know about others)
- it is not used by other WG item I-Ds or RFCs
- individual proposals to use that RFC routinely get rejected in the WG.

How can we make sure this Universal RA option avoids the same fate?

Alex

Le 28/12/2018 à 21:25, Ole Troan a écrit :
>> *From: *<[email-masked] <mailto:[email-masked]>>
>> *To: *Ole Troan <[email-masked] <mailto:[email-masked]>>
>>
>>
>> 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: 
>> until the htmlized version and diff are available at tools.ietf.org 
>> <http://tools.ietf.org>.
>>
>> The IETF Secretariat
>>
> 
>

---

From: Ole Troan <[email-masked]>
Date: Fri, 15 Mar 2019 09:48:50 +0100

Alexandre,

> Given an unsuccessful earlier attempt to Expand the RA, how can we make sure this new direction to Universality avoids the same fate?
> 
> My probably limited understanding is that the RA Flags Expansion option (RFC 5175, year 2008) has seen only limited deployment:

The flags expansion is a sort of future proofing, and it wouldn’t make sense to implement it before someone needed more flags.

The universal RA proposal is an experiment in a couple of dimensions.

What are the consequence of using a self-describing format?
On router side allowing network operators to define new RA options without requiring vendor involvement and implementation changes.
On the host side, allowing applications to register for RA options without kernel changes.

What are the consequences of limiting IETF involvement (expert review only)?

It’s an experiment we don’t know the outcome.
If this was used to define new protocols, like Fred was proposing. Or if it was used to define new options like the RA flag, Pref64 or many others that wouldn’t necessarily have IETF consensus to publish… is that a successful experiment? Even if it saw massive deployment.

It’s an experiment in letting go of power and control of a part of the protocol. Scary? Yes. ;-)

Cheers,
Ole

>>> *Subject: **New Version Notification for draft-troan-6man-universal-ra-option-01.txt*
>>> until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org>.
>>> 
>>> The IETF Secretariat
>>>

---

From: Erik Kline <[email-masked]>
Date: Sun, 17 Mar 2019 23:49:44 -0700

> https://github.com/ietf-6man/universal-ra

Attempted.

I'm also happy to send a pull request to add "? mtu : uint .size 2" to
the rio_route element, if you think that's okay.

---

From: Ole Troan <[email-masked]>
Date: Mon, 18 Mar 2019 09:03:33 +0100

Erik,

> the rio_route element, if you think that's okay.

Thank you.
Merged the following patch:
https://github.com/ietf-6man/universal-ra/commit/0bc1f36d2f088cd3295f3bca4cf4706751ac9267

<chair hat>This can also double as an experiment in using github in 6man.</chair hat>

Cheers,
Ole

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 18 Mar 2019 19:01:26 +0900

On Fri, Mar 15, 2019 at 5:49 PM Ole Troan <[email-masked]> wrote:

> If this was used to define new protocols, like Fred was proposing. Or if
> it was used to define new options like the RA flag, Pref64 or many others
> that wouldn’t necessarily have IETF consensus to publish… is that a
> successful experiment? Even if it saw massive deployment.
>

How is it different from, say, RADIUS vendor options, or DHCP vendor
options?

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 18 Mar 2019 16:19:40 +0100

As a side note,

Among the reasons to avoid github:

github messes 'ø' and 'ä' - and potentially others - in the xml authors' 
names.

(not to mention github IPv6 access, or lack thereof)

Alex

---

From: Ole Troan <[email-masked]>
Date: Mon, 18 Mar 2019 19:39:58 +0100

> How is it different from, say, RADIUS vendor options, or DHCP vendor options? 

Vendor options rarely makes it outside of that vendor’s purview.
These would be implementable by anyone who cares. Which I suppose is a good thing.

Cheers,
Ole