Subject: RFC 4191: Relevance of Route Information Option for ::/0 prefix

From: Prabhakar Lakhera <[email-masked]>
Date: Wed, 07 Oct 2015 12:30:44 -0700

Hi,

RFC 4191 implies that Route Information Option can be sent for ::/0.

The RFC itself has done well to address/explain, how this RIO of ::/0 should be handled by a host and how it should override the preference and lifetime values learned through RA header.

However, It is not immediately clear to me as to why should default route configuration be communicated through two different means in the same message, i.e. by RA itself and through Route Information Option.

It is prone to cause some confusions and bugs in certain implementations (different devices on the same network working differently). Also from implementation perspective, sequential processing of message and its options somewhat gets disrupted, as one has to go back and update the default route again. It can surely be done but again what’s the use-case?

My be there is some advantage of sending ::/0 in Route Information Option that I am missing.
I am sure folks here will be able to point me to the reasoning behind it.

However if there’s no strong case for ::/0, I propose RFC 4191 to deprecate this option before binary compatibility issues creep in. The host side processing can also be updated to simply ignore this option without discarding the message altogether keeping in line with Postel’s law :).

---

From: Mark Smith <[email-masked]>
Date: Thu, 8 Oct 2015 08:57:14 +1100

On 8 Oct 2015 6:30 am, "Prabhakar Lakhera" <[email-masked]> wrote:

Hi,

> The RFC itself has done well to address/explain, how this RIO of ::/0
should be handled by a host and how it should override the preference and
lifetime values learned through RA header.
>
> However, It is not immediately clear to me as to why should default route
configuration be communicated through two different means in the same
message, i.e. by RA itself and through Route Information Option.

Support of RIOs is a SHOULD rather than a MUST according to the IPv6 Node
Requirements RFC (RFC6434).

> It is prone to cause some confusions and bugs in certain implementations
(different devices on the same network working differently). Also from
implementation perspective, sequential processing of message and its
options somewhat gets disrupted, as one has to go back and update the
default route again. It can surely be done but again what’s the use-case?
> However if there’s no strong case for ::/0, I propose RFC 4191 to
deprecate this option before binary compatibility issues creep in. The host
side processing can also be updated to simply ignore this option without
discarding the message altogether keeping in line with Postel’s law :).

Are you saying deprecating RIOs completely, or just sending of ::/0 in
them? It seems like the latter, but I'm not completely sure.

Regards,
Mark.
_______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Prabhakar Lakhera <[email-masked]>
Date: Wed, 07 Oct 2015 17:46:32 -0700

Just deprecating the sending of ::/0 in the route information option.

> On Oct 7, 2015, at 2:57 PM, Mark Smith <[email-masked]> wrote:
> 
> 
> Support of RIOs is a SHOULD rather than a MUST according to the IPv6 Node Requirements RFC (RFC6434).
> 
> Are you saying deprecating RIOs completely, or just sending of ::/0 in them? It seems like the latter, but I'm not completely sure.
> 
> Regards,
> Mark.

---

From: [email-masked]
Date: Thu, 8 Oct 2015 09:20:29 +0200

Prabhakar,

> However if there’s no strong case for ::/0, I propose RFC 4191 to deprecate this option before binary compatibility issues creep in. The host side processing can also be updated to simply ignore th…

this exact point is explained in section 5.1 of 4191.

cheers,
Ole

---

From: Prabhakar Lakhera <[email-masked]>
Date: Thu, 08 Oct 2015 13:04:55 -0700

Hi Ole,

Many thanks for pointing me to that section!
I re-read it (more carefully this time) and it cleared the mist for me. I now understand the use case it is trying to address.

Cheers!

> On Oct 8, 2015, at 12:20 AM, [email-masked] <mailto:[email-masked]> wrote:
> 
> Prabhakar,
>