Re: Last Call: draft-manner-router-alert-iana (IANA Considerations for the IPv4 and IPv6 Router Alert Option) to Proposed Standard

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

About cutting most of the Security Considerations section, I don't personally have a preference, either is fine. Yet, I tend to agree with Jari that stating the obvious isn't such a big problem, it just reminds people that there are issues to consider. (Whether the use of an arbitrary RAO value kills routers, I don't know - if we ask router manufacturers surely they will not tell us. ;) )

Both registries will use 32 values for the aggregation levels. For IPv6 RAO, value 3 is removed but value 35 is kept. Thus, IPv6 will have values 4-35 (=32 values) for the 32 levels.

We can make this more clear, yet, I already answered a question from IANA about this a couple of weeks ago, so they are aware of how the registry should be changed.

Jukka

Jari Arkko wrote:
Kre, authors,

First (last sentence of section 2):

   It is unclear why nesting levels begin at 1 for IPv4 (described in
   section 1.4.9 of [RFC3175]) and 0 for IPv6 (allocated in section 6 of
   [RFC3175]).

isn't the kind of sentence that belongs in a doc like this.   If the
authors are mystified, just omit the sentence, including it adds nothing.
Better, of course, would be to ask, and discover, and provide an
explanation.

But, this doc deletes aggregation level 0 from IPv6 anyway, which makes
all of this even stranger.

There has been an effort to determine why the values do not match and why there's 33 instead of 32 values. We still do not know. I think it is valuable to point out problems (like the 33 values) and the fact that implementations have to use different values for v4 and v6.

However, your question about level 0 deletion prompts me to ask the authors: given that you are doing this, does this restore both the alignment to both using the range 1-32 and exactly 32 values? Does that mean that in IPv6 the value 35 (3+32) is used? If yes, maybe that should be clearer from the doc. Or is the intent that IPv6 will use 1-31?

Second (section 4, security considerations):
It has been a long standing practice that we allocate experimental code points for different protocol fields.

I agree that the security considerations section is largely about common sense. I do not necessarily agree that the considerations can be removed, however. The fact of the matter is that experiments can collide and it may even be possible that some equipment has interesting failure modes when it sees previously untested values. Worth the two paragraphs? I'd rather err on the side of stating the obvious.

Jari

_______________________________________________

Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]