Subject: draft ra guidelines: Worth the effort?

From: Dan Lüdtke <[email-masked]>
Date: Tue, 25 Aug 2015 09:46:46 +0200

Hi everyone,

we have released a revised version of our draft:
> This document defines simple rules to follow when defining new router
>   advertisement options.

As the interest on the first version was very low, we would like to ask again for comments and review. If you feel that this document should not be worked on further but should be dropped, please tell us. We would prefer not wasting anyones time (including ours) for a document that nobody sees a need for. We just felt that this was an issue some time ago and needs to be addressed to avoid further confusions of RA option authors.

Thanks!

Dan

> A new version of I-D, draft-sarikaya-6man-ra-guidelines-01.txt
> has been successfully submitted by Behcet Sarikaya and posted to the
> IETF repository.
> 
> Name:		draft-sarikaya-6man-ra-guidelines
> Revision:	01
> Title:		Guidelines for New Router Advertisement Options
> Document date:	2015-08-21
> Group:		Individual Submission
> Pages:		10
> URL:            https://www.ietf.org/internet-drafts/draft-sarikaya-6man-ra-guidelines-01.txt
> Status:         https://datatracker.ietf.org/doc/draft-sarikaya-6man-ra-guidelines/
> Htmlized:       https://tools.ietf.org/html/draft-sarikaya-6man-ra-guidelines-01
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-sarikaya-6man-ra-guidelines-01
> 
> Abstract:
>   This document defines simple rules to follow when defining new router
>   advertisement options.

---

From: Mark Smith <[email-masked]>
Date: Tue, 25 Aug 2015 21:12:42 +1000

Hi,

> As the interest on the first version was very low, we would like to ask again for comments and review. If you feel that this document should not be worked on further but should be dropped, please t…

I've been intending to read it in detail, apologies for not doing so yet.

Having briefly looked though it, one thing I was hoping it would
provide an overt answer to is when are RA options appropriate compared
to DHCPv6 options.

It does mention that RAs normally go to all hosts, which means that if
there are host specific parameters, then DHCPv6 should be used, so the
corresponding option should be a DHCPv6 one (or perhaps something
else).

I think other consideration in the DHCPv6 vs RA option decision is
what sort of effort is involved and what needs to be upgraded to
support and use a new RA  or DHCPv6 option.

Upgrading a router to support a new RA option will involve upgrading
the control plane software, and for most routers, upgrading control
plane software also involves rebooting the router, disrupting
forwarding. This assumes there is a software upgrade available that
supports your intended new RA option - which there may never be.

Additionally, there are many routers out there who's owners won't be
competent to upgrade the software in them even if it is available,
specifically owner operated residential CPE.

This is why I came to the conclusion that DHCPv6 relays in routers are
better for supporting upper layer/application oriented host
parameters, because DHCPv6 relays are DHCPv6 option transparent -
there is no need to upgrade a router's control plane software to
support new DHCPv6 options - it is only necessary to upgrade the
DHCPv6 server and interested client's DHCPv6 client software to
support new DHCPv6 options. For the same sort of reasons, I then came
to the conclusion that RAs should be limited to options to configure
link-specific network layer parameters.

Although the following is about using a DHCPv6 relay on a CPE instead
of a combination of a DHCPv6 Server and Client, the section on
"Internet Transparency and Application Configuration" was some general
discussion about application configuration transparency in the
Internet which may be useful to think about. If there is any text in
the draft that would be useful, feel free to copy it.

"IPv6 CE Device DHCPv6 Option Transparency"
https://tools.ietf.org/html/draft-smith-v6ops-ce-dhcpv6-transparency-00

RFC5505 discusses host configuration principles, so I think this draft
could be seen to be applying those arguments to the more specific case
of RA options verses DHCPv6 options.

Regards,
Mark.

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

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 25 Aug 2015 16:08:05 +0200 (CEST)

On Tue, 25 Aug 2015, Dan Lüdtke wrote:

> As the interest on the first version was very low, we would like to ask 
> again for comments and review. If you feel that this document should not 
> be worked on further but should be dropped, please tell us. We would 
> prefer not wasting anyones time (including ours) for a document that 
> nobody sees a need for. We just felt that this was an issue some time 
> ago and needs to be addressed to avoid further confusions of RA option 
> authors.

I agree that this is an issue and I would like this worked on.

There might also be other places where we would like to insert more 
information and properties, for instance MTU:

https://tools.ietf.org/html/draft-van-beijnum-multi-mtu-04

It would be useful to be able to say "this LAN has MTU 9000 generally", 
but saying "I'm a router and I can speak 9000 frames on this LAN, but the 
default route you might point at me because I sent this RA, should only be 
set to 1500 MTU".

So perhaps we should not focus on RA guidelines but ND guidelines that 
would also include RAs?

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: 神明達哉 <[email-masked]>
Date: Thu, 27 Aug 2015 11:31:06 -0700

At Tue, 25 Aug 2015 09:46:46 +0200,
Dan Lüdtke <[email-masked]> wrote:

> As the interest on the first version was very low, we would like to
> ask again for comments and review. If you feel that this document
> should not be worked on further but should be dropped, please tell
> us. We would prefer not wasting anyones time (including ours) for a
> document that nobody sees a need for. We just felt that this was an
> issue some time ago and needs to be addressed to avoid further
> confusions of RA option authors.

Personally I'm neutral on the draft.  I see a possibility that this
can matter, but from a quick glance at the abstract and introduction,
it was not clear to me whether this is based on actual confusions in
development or standardization efforts or rather theoretical (I
thought RFC7227 belonged to the former category).  Your above comment
seems to suggest this is also the former.  If so, you might share the
specific experiences at least here, and maybe also in an updated
version of the draft.  Depending on the reality of the background
motivation I'd be more positive on the draft and probably be willing
to review it more carefully.

--
JINMEI, Tatuya

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 27 Aug 2015 15:12:21 -0500

Hi Jinmei,

> Personally I'm neutral on the draft.  I see a possibility that this

you mean RA guidelines document?

> seems to suggest this is also the former.

Yes.

> If so, you might share the

I agree that background motivation in the introduction should be
improved. As you mentioned, we could use similar treatment in RFC 7227
as a starting point.

Thanks,

Behcet

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 27 Aug 2015 15:54:38 -0500

On Tue, Aug 25, 2015 at 9:08 AM, Mikael Abrahamsson <[email-masked]> wrote:
>> again for comments and review. If you feel that this document should not be
>> worked on further but should be dropped, please tell us. We would prefer not
>> wasting anyones time (including ours) for a document that nobody sees a need
>> for. We just felt that this was an issue some time ago and needs to be
>> addressed to avoid further confusions of RA option authors.
>
>

Thanks.

> It would be useful to be able to say "this LAN has MTU 9000 generally", but
> saying "I'm a router and I can speak 9000 frames on this LAN, but the

I think Iljitsch's draft is saying that
Remove limitation that all nodes on subnet
must use the same MTU
instead,
use standard MTU as default and
negotiate per
-neighbor MTU and test it.

> So perhaps we should not focus on RA guidelines but ND guidelines that would
> also include RAs?

again the above draft is suggesting to change RA MTU option {RFC 4861]
semantics to enable the neighbors to send their own MTU in order to
negotiate per-neighbor MTU. And so on.

Maybe these are good ideas but no consensus on it has yet been
reached, so I don't know what we can do in an RA Guidelines document?
So this point seems to negate what you said above.  Can you clarify it
maybe we can understand better?

Regards,

Behcet