Subject: universal RA option

From: j h woodyatt <[email-masked]>
Date: Mon, 1 Apr 2019 12:57:00 -0700

Hi everyone,

If a universal option format is warranted for Router Advertisement messages, then I suggest defining it for all the messages in section 4 of RFC 4861, and not just for the Router Advertisement message. That would allow, for example, refactoring of this expired draft to use it:

	<https://tools.ietf.org/html/draft-templin-6man-rio-redirect>

--james woodyatt <[email-masked]>

---

From: Ole Troan <[email-masked]>
Date: Mon, 8 Apr 2019 15:41:47 +0200

James,

> 	<https://tools.ietf.org/html/draft-templin-6man-rio-redirect>

Right…
Do we want to evolve ND into a poor mans routing protocol though?
Or a “static route negotiation protocol”?

Cheers,
Ole

---

From: james woodyatt <[email-masked]>
Date: Mon, 8 Apr 2019 06:59:47 -0700

Hi Ole,

By some lights, neighbor discovery is already a routing protocol. One with a lot of terrible limitations that are the subject of various recurring debates in 6MAN.

The question you’re asking, by those lights, seems to be this one: do we want to improve the protocol by addressing those limitations? Or do we reaffirm the case that hosts sensitive to dynamic routing changes should participate in existing standard routing protocols?

I think if we publish this draft, then we’re kind of inviting experimentation aimed to improve neighbor discovery, and we would do well to optimize it for the opportunity. Otherwise, I’m not sure I see the point of limiting the utility of the universal option to just Routing Advertisement messages.

—sent from my phone

> On Apr 8, 2019, at 06:41, Ole Troan <[email-masked]> wrote:
> 
> James,
>

---

From: Ole Troan <[email-masked]>
Date: Mon, 8 Apr 2019 20:15:29 +0200

Hi James,

> I think if we publish this draft, then we’re kind of inviting experimentation aimed to improve neighbor discovery, and we would do well to optimize it for the opportunity. Otherwise, I’m not sure I…

So you’d prefer it to be the universal ND option. And then each option specify which message type it was applicable to?

Cheers,
Ole

---

From: Erik Kline <[email-masked]>
Date: Mon, 8 Apr 2019 11:44:46 -0700

On Mon, 8 Apr 2019 at 11:15, Ole Troan <[email-masked]> wrote:

> Hi James,
>
> > By some lights, neighbor discovery is already a routing protocol. One
> with a lot of terrible limitations that are the subject of various
> recurring debates in 6MAN.
> >
> > The question you’re asking, by those lights, seems to be this one: do we
> want to improve the protocol by addressing those limitations? Or do we
> reaffirm the case that hosts sensitive to dynamic routing changes should
> participate in existing standard routing protocols?
> >
> > I think if we publish this draft, then we’re kind of inviting
> experimentation aimed to improve neighbor discovery, and we would do well
> to optimize it for the opportunity. Otherwise, I’m not sure I see the point
> of limiting the utility of the universal option to just Routing
> Advertisement messages.
>
> So you’d prefer it to be the universal ND option. And then each option
> specify which message type it was applicable to?
>

In chatting about this more with Lorenzo the other week, I actually came to
feel like we ought to just let people innovate in the PVD keyspace
instead.  In other words: publish the PVD option doc, and let apps and
other consumers bootstrap their way from there.  I think that is probably
also easier for apps to use (they just need to be given the PVD URL and
away they're off to the races...).

---

From: "Chongfeng Xie" <[email-masked]>
Date: Tue, 9 Apr 2019 10:41:52 +0800

I don't think it is necessary to do the universal ND option for the change of basic features of IPv6 may make ISPs confused during the process of deployment.   
Chongfeng Xie

[email-masked]
 
From: Erik Kline
Date: 2019-04-09 02:44
To: Ole Troan
CC: 6man
Subject: Re: universal RA option

In chatting about this more with Lorenzo the other week, I actually came to feel like we ought to just let people innovate in the PVD keyspace instead.  In other words: publish the PVD option doc, and let apps and other consumers bootstrap their way from there.  I think that is probably also easier for apps to use (they just need to be given the PVD URL and away they're off to the races...).

---

From: Ole Troan <[email-masked]>
Date: Tue, 9 Apr 2019 09:19:21 +0200

Erik,

> In chatting about this more with Lorenzo the other week, I actually came to feel like we ought to just let people innovate in the PVD keyspace instead.  In other words: publish the PVD option doc,…

I would have thought it made more sense to to do it the other way around, and represent PVDs in the universal RA format.
Nothing stopping you from adding a universal RA object for “here’s a URL where you can download configuration information blobs.

What would be the benefit of tying and limiting configuration options to PVDs?
(I see PVDs as something trying to emulate the PPPoE user experience of the 90s, so I’m not a big fan. ;-))

Cheers,
Ole

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 11 Apr 2019 14:02:35 +0200

Hi,

In my deployment I consider the use of an IPv4 prefix in an RIO of an RA.

I wonder where would it better fit: in PVD or in Universal RA option?

(for explanation of why IPv4, why ICMPv6 RA, etc. I can do in the IPWAVE 
WG).

Alex

Le 09/04/2019 à 09:19, Ole Troan a écrit :
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: j h woodyatt <[email-masked]>
Date: Thu, 11 Apr 2019 10:10:57 -0700

On Apr 8, 2019, at 11:15, Ole Troan <[email-masked]> wrote:
> [I wrote:]

Bearing in mind that this is an Experimental category draft, yes that would be my preference.

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 12 Apr 2019 09:36:53 +0900

On Tue, Apr 9, 2019 at 4:19 PM Ole Troan <[email-masked]> wrote:

> > In chatting about this more with Lorenzo the other week, I actually came
> to feel like we ought to just let people innovate in the PVD keyspace
> I would have thought it made more sense to to do it the other way around,
> and represent PVDs in the universal RA format.
> Nothing stopping you from adding a universal RA object for “here’s a URL
> where you can download configuration information blobs.
>

There are other advantages of moving the information to PVDs. For example,
encrypted/authenticated communications and no size limits (RAs are
basically limited to 1500 bytes at most). I think it makes sense for RAs to
remain a very low-level protocol focused on only the information that is
necessary to get on to the network.

---

From: Tommy Pauly <[email-masked]>
Date: Thu, 11 Apr 2019 17:47:41 -0700

> On Apr 11, 2019, at 5:36 PM, Lorenzo Colitti <lorenzo=[email-masked]> wrote:
> 
> On Tue, Apr 9, 2019 at 4:19 PM Ole Troan <[email-masked] <mailto:[email-masked]>> wrote:
> There are other advantages of moving the information to PVDs. For example, encrypted/authenticated communications and no size limits (RAs are basically limited to 1500 bytes at most). I think it makes sense for RAs to remain a very low-level protocol focused on only the information that is necessary to get on to the network.

+1 to having the larger extension points be encrypted/authenticated. That's the point of PvDs; they also allow for potential other mechanisms (other than RAs, or DHCP) to point to the PvD information blob, which makes the information more useful across domains.

Thanks,
Tommy

---

From: Ole Troan <[email-masked]>
Date: Fri, 12 Apr 2019 08:36:09 +0200

> There are other advantages of moving the information to PVDs. For example, encrypted/authenticated communications and no size limits (RAs are basically limited to 1500 bytes at most). I think it ma…

PVDs provide information about the / from the upstream network. RAs provide information about the local network.
Leaking information across that administrative boundary has security implications, and the security consequences of requiring end hosts inside a network to request configuration from another domain needs to be evaluated.

Cheers,
Ole

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 12 Apr 2019 10:55:40 +0200

Le 12/04/2019 à 02:36, Lorenzo Colitti a écrit :
>      > In chatting about this more with Lorenzo the other week, I
>     actually came to feel like we ought to just let people innovate in
>     the PVD keyspace instead.  In other words: publish the PVD option
>     doc, and let apps and other consumers bootstrap their way from
>     there.  I think that is probably also easier for apps to use (they
>     just need to be given the PVD URL and away they're off to the races...).
> 
>     I would have thought it made more sense to to do it the other way
>     around, and represent PVDs in the universal RA format.
>     Nothing stopping you from adding a universal RA object for “here’s a
>     URL where you can download configuration information blobs.
> 
> There are other advantages of moving the information to PVDs. For 
> example, encrypted/authenticated communications and no size limits (RAs 
> are basically limited to 1500 bytes at most).

What is the protocol that transports PVD (UDP ?).
Can PVD transport an RIO with IPv4 prefix inside?

The security aspects are very important.

Alex

  I think it makes sense for
> RAs to remain a very low-level protocol focused on only the information 
> that is necessary to get on to the network.
>