Re: [Int-area] draft-manner-router-alert-iana WGLC
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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 at ietf.org
https://www.ietf.org/mailman/listinfo/int-area
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.
