Re: [Int-area] draft-manner-router-alert-iana WGLC

Here's Bob Hinden's directorate review. Thanks for the review, Bob!

> I think the biggest issue I see with this document is change the IPv6
> RAO "3" to be reserved.  See the comments I wrote in 3.2.  It's not
> clear to me if this will break any running code or where the error was
> introduced.  It may have been in RFC3175.
>
> This looks to me like the scope of the document was reduced to not
> change IPv6 allocation methods, but the text wasn't updated to be
> consistent with that change.
>
> There are still issues with some of the allocations that are left
> ambiguous.
>
> The text needs a "which hunt".  I think most uses of "which" should be
> "that".
>
> Many specific comments below.
>
> Bob
>
>
>>
>>
>>
>> Network Working Group                                        A. McDonald
>> Internet-Draft                                              Siemens/Roke
>> Updates: RFC2113, RFC2711                                      J. Manner
>> (if approved)                                                        TKK
>> Intended status: Standards Track                       February 25, 2008
>> Expires: August 28, 2008
>>
>>
>>      IANA Considerations for the IPv4 and IPv6 Router Alert Option
>>                    draft-manner-router-alert-iana-02
>
> ....
>
>> Abstract
>>
>>    This document provides new instructions to IANA on the allocation of
>>    IPv4 and IPv6 Router Alert Option Values.
>>
>
> This isn't correct.  The current draft does not provide new
> instructions for IANA on the allocation of IPv6 Router Alert Option
> Values.  Quoting from Section 3.2:  "The registry for IPv6 Router
> Alert Option Values should continue to be maintained as specified in
> [RFC2711]."  It does change two assignments, but the procedure doesn't
> change.
>
> ...
>
>>
>>
>> 1.  Introduction
>>
>>    The IP Router Alert Option is defined for IPv4 in [RFC2113].  A
>>    similar IPv6 option is defined in [RFC2711].  When one of these
>>    options is present in an IP datagram, it indicates that the contents
>>    of the datagram may be interesting to routers.  The Router Alert
>>    Option (RAO) is used by protocols such as RSVP [RFC2205] and IGMP
>>    [RFC3376].
>>
>>    Both the IPv4 and IPv6 option contain a two octet value field to
>>    carry extra information.  This information can be used, for example,
>>    by routers to determine whether or not the packet should be more
>>    closely examined by them.
>>
>>    There can be up to 65536 values for the RAO.  Yet, currently there is
>>    only a repository for IPv6 values.  No repository or allocation
>>    policies are defined for IPv4.
>>
>>    This document proposes the creation of a new IANA registry for
>>    managing IPv4 Router Alert Option Values.  In conjunction with this,
>>    it also proposes an update to the way in which IPv6 Router Alert
>>    Option Values are assigned in the existing IANA registry, and
>>    proposes small changes to the current allocations.
>
> ditto as above.
>
>> 2.  Use of the Router Alert Option Value Field
>>
>>    One difference betwen the specifications for the IPv4 and IPv6 Router
>>    Alert Options is the way in which values for the value field are
>>    managed.  In [RFC2113], the IPv4 Router Alert Option value field has
>>    the value 0 assigned to "Router shall examine packet".  All other
>>    values (1-65535) are reserved.  No mechanism is provided for the
>>    allocation of these values by IANA.
>>
>>    The IPv6 Router Alert Option has an IANA managed registry
>>    [IANA-IPv6RAO] containing allocations for the value field.  All
>>    values in this registry are assigned by IETF consensus.
>>
>>    In [RFC3175] the IPv4 Router Alert Option Value is described as a
>>    parameter which provides "additional information" to the router in
>>    making its interception decision, rather than as a registry managed
>>    by IANA.  As such, this aggregation mechanism makes use of the value
>>    field to carry the reservation aggregation level.  For the IPv6
>>    option, this document requests a set of 32 values to be assigned by
>>    IANA for indicating reservation levels.  However, since other
>>    registrations had already been made in that registry these values are
>>    from 3-35 (which is actually a set of 33 values).
>>
>>
>>
>>
>> McDonald & Manner        Expires August 28, 2008                [Page 3]
>> Internet-Draft    IANA Considerations for Router Alert     February 2008
>>
>>
>>    Although it would be desirable to have the same values being used in
>
> s/it would be/it might have been/
>
>>    both the IPv4 and IPv6 registries, the initial allocations in
>>    [RFC2711] and the aggregation level allocations in [RFC3175] have
>>    made this impossible.  The following table shows the allocations in
>>    the IPv6 registry and values used in the IPv4 registry, where the
>>    latter have been deduced from [RFC2113] and [RFC3175] with the
>>    assumption that the number of aggregation levels can be limited to 32
>>    as in the IPv6 case.  Entries for values 6 to 31 have been elided for
>>    brevity.
>>
>>    +----------+-------------------------+------------------------------+
>>    | Value    | IPv4 RAO Meaning        | IPv6 RAO Meaning             |
>>    +----------+-------------------------+------------------------------+
>>    | 0        | Router shall examine    | Datagram contains a          |
>>    |          | packet [RFC2113]        | Multicast Listener Discovery |
>>    |          | [RFC2205] [RFC3376]     | message [RFC2711] [RFC2710]  |
>>    |          | [RFC4286]               | [RFC4286]                    |
>>    | 1        | Aggregated Reservation  | Datagram contains RSVP       |
>>    |          | Nesting Level 1         | message [RFC2711] [RFC2205]  |
>>    |          | [RFC3175]               |                              |
>>    | 2        | Aggregated Reservation  | Datagram contains an Active  |
>>    |          | Nesting Level 2         | Networks message [RFC2711]   |
>>    |          | [RFC3175]               | [Schwartz2000]               |
>>    | 3        | Aggregated Reservation  | Aggregated Reservation       |
>>    |          | Nesting Level 3         | Nesting Level 0 [RFC3175]    |
>>    |          | [RFC3175]               |                              |
>>    | 4        | Aggregated Reservation  | Aggregated Reservation       |
>>    |          | Nesting Level 4         | Nesting Level 1 [RFC3175]    |
>>    |          | [RFC3175]               |                              |
>>    | 5        | Aggregated Reservation  | Aggregated Reservation       |
>>    |          | Nesting Level 5         | Nesting Level 2 [RFC3175]    |
>>    |          | [RFC3175]               |                              |
>>    | ...      | ...                     | ...                          |
>>    | 32       | Aggregated Reservation  | Aggregated Reservation       |
>>    |          | Nesting Level 32        | Nesting Level 29 [RFC3175]   |
>>    |          | [RFC3175]               |                              |
>>    | 33       | Reserved                | Aggregated Reservation       |
>>    |          |                         | Nesting Level 30 [RFC3175]   |
>>    | 34       | Reserved                | Aggregated Reservation       |
>>    |          |                         | Nesting Level 31 [RFC3175]   |
>>    | 35       | Reserved                | Aggregated Reservation       |
>>    |          |                         | Nesting Level 32(?)          |
>
>
> The question mark (discussion below) needs to be resolved.  This would
> be better if the "?" was replaced with an "*" and the text below was a
> note.
>
>
>>    |          |                         | [RFC3175]                    |
>>    | 36-65534 | Reserved                | Reserved to IANA for future  |
>>    |          |                         | use                          |
>>    | 65535    | Reserved                | Reserved [IANA-IPv6RAO]      |
>>    +----------+-------------------------+------------------------------+
>>
>>
>>
>>
>> McDonald & Manner        Expires August 28, 2008                [Page 4]
>> Internet-Draft    IANA Considerations for Router Alert     February 2008
>>
>>
>>    The entry in the above table for the IPv6 RAO Value of 35 (Aggregated
>>    Reservation Nesting Level 32) 2 has been marked with a question mark
>>    due to an inconsistency in the text of [RFC3175], which is
>>    consequently reflected in the IANA registry.  In that document the
>>    values 3-35 (i.e. 33 values) are defined for nesting levels 0-31
>>    (i.e. 32 levels).
>
> The above should be a note.  Should this document define how to
> resolve this issue? I don't know the answer.
>
>>    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]).
>
> I would guess because IPv4 tended to keep zero values reserved, and
> IPv6 did not.  This is just a guess.
>
>>
>>
>> 3.  IANA Considerations
>>
>>    This section contains the proposed new procedures for managing Router
>>    Alert Option Values.  This requires the creation of a registry for
>
> s/Router Alert Option/IPv4 Router Alert Option/
>
>>    IPv4 Router Alert Option Values (described in Section 3.1) and
>>    changes to the way in which IPv6 Router Alert Option Values are
>>    managed (described in Section 3.2).
>
> There isn't any changes to the way that IPv6 Router Alert Options
> Values are managed.
>
>>
>> 3.1.  IANA Considerations for IPv4 Router Alert Option Values
>>
>>    The value field, as specified in [RFC2113] is two octets in length.
>>    The value field is registered and maintained by IANA.  The initial
>>    contents of this registry are:
>>
>>     +-------------+--------------------------------------+-----------+
>>     | Value       | Description                          | Reference |
>>     +-------------+--------------------------------------+-----------+
>>     | 0           | Router shall examine packet          | [RFC2113] |
>>     | 1-32        | Aggregated Reservation Nesting Level | [RFC3175] |
>>     | 33-65502    | Reserved to IANA for future use      |           |
>>     | 65503-65534 | Reserved for experimental use        |           |
>>     | 65535       | Reserved                             |           |
>>     +-------------+--------------------------------------+-----------+
>>
>>    New values are to be assigned via IETF Consensus as defined in
>>    [RFC2434].
>>
>> 3.2.  IANA Considerations for IPv6 Router Alert Option Values
>>
>>    The registry for IPv6 Router Alert Option Values should continue to
>>    be maintained as specified in [RFC2711].
>>
>>    In addition, the following value should be removed from the IANA
>>    registry and reserved for possible future use (not to be allocated
>>    currently).  The reason is that it is a duplicate value, aggreagation
>>    level 0 means end-to-end signaling, and this already has an IPv6 RAO
>>
>>
>>
>> McDonald & Manner        Expires August 28, 2008                [Page 5]
>> Internet-Draft    IANA Considerations for Router Alert     February 2008
>>
>>
>>    value "1" assigned.
>>
>>    3: "RSVP Aggregation level 0"
>
>
> I don't know if this change will effect any implementations.  If
> anyone is using the "3" value, then this would require this code to
> change.  This needs to be better understood before making this
> change.  Was this a mistake in RFC3175?  If so, this should be
> described and this document should be an update to RFC3175 as well. 
> But again, if this breaks running code, than the change probably
> shouldn't be made.
>
> Also, the above text is a little hard to parse.  It took me a while to
> figure out that it was the 3: value being changed.
>
>>
>>    The following IPv6 RAO values should be reserved for experimental
>>    use:
>>
>>    65503-65534: "Experimental use"
>>
>>
>> 4.  Security Considerations
>>
>>    Since this document is only concerned with the IANA management of the
>>    IPv4 and IPv6 Router Alert Option values registry it raises no new
>>    security issues beyond those identified in [RFC2113] and [RFC2711].
>>
>>
>> 5.  Acknowledgements
>>
>>    Thanks to Robert Hancock, Martin Stiemerling, Alan Ford and Francois
>>    Le Faucher for their helpful comments on this document.
>>
>>
>> 6.  References
>>
>> 6.1.  Normative References
>>
>>    [RFC2113]  Katz, D., "IP Router Alert Option", RFC 2113,
>>               February 1997.
>>
>>    [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
>>               IANA Considerations Section in RFCs", BCP 26, RFC 2434,
>>               October 1998.
>>
>>    [RFC2711]  Partridge, C. and A. Jackson, "IPv6 Router Alert Option",
>>               RFC 2711, October 1999.
>>
>>    [RFC3175]  Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie,
>>               "Aggregation of RSVP for IPv4 and IPv6 Reservations",
>>               RFC 3175, September 2001.
>>
>>  6.2.   Informative References
>>
>>     [IANA-IPv6RAO]
>>                "IANA Registry for Internet Protocol version 6 (IPv6)
>>               Router Alert Option Values" .
>>
>>               <http://www.iana.org/assignments/ipv6-routeralert-values>
>
>
> Since this document is changing the above, it should be a Normative
> reference.
>
>>
>>
>>
>> McDonald & Manner        Expires August 28, 2008                [Page 6]
>> Internet-Draft    IANA Considerations for Router Alert     February 2008
>>
>>
>>    [RFC2205]  Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
>>               Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
>>               Functional Specification", RFC 2205, September 1997.
>>
>>    [RFC2710]  Deering, S., Fenner, W., and B. Haberman, "Multicast
>>               Listener Discovery (MLD) for IPv6", RFC 2710,
>>               October 1999.
>>
>>    [RFC3376]  Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
>>               Thyagarajan, "Internet Group Management Protocol, Version
>>               3", RFC 3376, October 2002.
>>
>>    [RFC4286]  Haberman, B. and J. Martin, "Multicast Router Discovery",
>>               RFC 4286, December 2005.
>>
>>    [Schwartz2000]
>>               Schwartz, B., Jackson, A., Strayer, W., Zhou, W.,
>>               Rockwell, D., and C. Partridge, "Smart Packets: Applying
>>               Active Networks to Network Management", ACM Transactions
>>               on Computer Systems (TOCS) Volume 18 ,  Issue 1,
>>               February 2000.
>>
>>
>
>

_______________________________________________
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area