idnits 2.17.1 draft-ietf-ion-nhrp-flowext-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-24) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 3 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** The abstract seems to contain references ([RFC2332]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: Da When set, this bit indicates that flows may be identified using prefix matching on the Destination IP Address field of the IP Header. Prefix matching uses a specified number of bits from the address field rather than the whole field. This bit is set by the source NHC and MAY NOT be modified by transit or serving NHSs. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: Sa When set, this bit indicates that flows may be identified using prefix matching on the Source IP Address field of the IP Header. This bit is set by the source NHC and MAY NOT be modified by transit or serving NHSs. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: T When set, this bit indicates that flows may be identified based on the Type of Service field of the IP Header. This bit is set by the source NHC and MAY NOT be modified by transit or serving NHSs. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: Type of Service Value of the IP Type of Service field for the associated flow. This value is set by the source NHC and MAY NOT be modified by transit or serving NHSs. This field is only meaningful when the "T" bit is set. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: Protocol Value of the next level protocol field for the associated flow. A value of zero (0) indicates that the source NHC will not include this field in identification of the associated flow. This field is set by the source NHC and MAY NOT be modified by transit or serving NHSs. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: Source IP Address The source IP address for the associated flow. A value of zero (0) indicates that the source NHC will not include this field in flow identification. This field is set by the source NHC and MAY NOT be modified by transit or serving NHSs. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: Destination IP Address The destination IP address of the associated flow. A value of zero (0) indicates that the source NHC will not include this field in flow identification. This field is set by the source NHC and MAY NOT be modified by transit or serving NHSs. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: PT When set, this bit indicates that flows may be identified based on the Prio./Traffic Class and Flow Label fields of the IP Header. This bit is set by the source NHC and MAY NOT be modified by transit or serving NHSs. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: Next Header Value of the IPv6 Next Header field for the associated flow. A value of zero (0) indicates that the source NHC will not include this field in identification of the associated flow. This field is set by the source NHC and MAY NOT be modified by transit or serving NHSs. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: Prio./Traffic Class and Flow Label (PT) The 28-bit PT field for the associated flow. The PT field is composed of two parts. The first part carries either the IPv6 priority value or the the proposed IPv6 Traffic Class field. The second part is the IPv6 Flow Label. This field is set by the source NHC and MAY NOT be modified by transit or serving NHSs. This field is only meaningful when the "PT" bit is set. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: Source IPv6 Address The source IPv6 address for the associated flow. A value of zero (0) indicates that the source NHC will not include this field in flow identification. This field is set by the source NHC and MAY NOT be modified by transit or serving NHSs. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: Destination IPv6 Address The destination IPv6 address of the associated flow. A value of zero (0) indicates that the source NHC will not include this field in flow identification. This field is set by the source NHC and MAY NOT be modified by transit or serving NHSs. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: Dr When set, this bit indicates that flows may be identified using a range of acceptable values in the Destination Port field of the transport header. This bit is set by the source NHC and MAY NOT be modified by transit or serving NHSs. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: Sr When set, this bit indicates that flows may be identified using a range of acceptable values in the Source Port field of the transport header. This bit is set by the source NHC and MAY NOT be modified by transit or serving NHSs. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: Source Port Value of the Source Port field of the transport header for the associated flow. A value of zero (0) indicates that the source NHC has not include this field in flow identification. This field is set by the source NHC and MAY NOT be modified by transit or serving NHSs. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: Destination Port Value of the Destination Port field of the transport header for the associated flow. A value of zero (0) indicates that the source NHC has not include this field in flow identification. This field is set by the source NHC and MAY NOT be modified by transit or serving NHSs. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: Security Parameter Index The Security Parameter Index (SPI) field value associated with the flow. The SPI field is 32-bits long and located at the start of the transport header for ESP, and at bit 32 of the transport header for AH. This value is set by the source NHC and MAY NOT be modified by transit or serving NHSs. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: If the protocol check passes, NHSs processing Request messages containing a Flow Extension MUST examine the described flow to verify that it is acceptable. Both the request and policy information related fields MUST be examined. The request portion of the extension is unacceptable if data packets matching the flow would not be forwarded. The policy information is unacceptable if the Flow Extension cannot be updated to reflect an NHS' policy information. If both portions are acceptable, the NHS MUST update the policy information related fields as needed to reflect its policy and then handle the Request message per [RFC2332]. Note that an NHS MAY NOT change any policy information field to be less restrictive. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 22, 1998) is 9438 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 1826 (Obsoleted by RFC 2402) ** Obsolete normative reference: RFC 1827 (Obsoleted by RFC 2406) Summary: 12 errors (**), 0 flaws (~~), 20 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 ION Working Group Lou Berger 2 INTERNET DRAFT FORE Systems 3 Rob Enns 4 Berkeley Networks 5 Expires: December 1998 7 NHRP Flow Extension 9 June 22, 1998 11 Status of this Memo 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, 15 and its working groups. Note that other groups may also distribute 16 working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as ``work in progress.'' 23 To view the entire list of current Internet-Drafts, please check the 24 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 25 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 26 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 27 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 29 Abstract 31 This document presents an extension to NHRP [RFC2332] that enables 32 resolution of NBMA next hop addresses based on destination flow 33 information. This extension also enables NHSs to relay simple 34 forwarding policy to source stations (NHCs). 36 1. Introduction 38 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 39 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 40 document, are to be interpreted as described in [RFC2119]. 42 The NBMA Next Hop Resolution Protocol provides a mechanism for a 43 station to resolve a destination internetworking layer address into 44 the corresponding NBMA subnetwork addresses of the "NBMA next hop." 45 As defined in [RFC2332], NBMA next hop subnetwork addresses are 46 resolved based on an internetworking layer address and, possibly, an 47 address prefix. 49 Resolution based on destination addresses may not be adequate for all 50 cases. This document is motivated by one such case. The case 51 addressed by this document is when the NBMA next hop is dependent on 52 the contents of a data packet, i.e. its type of traffic. The 53 extension presented in this document provides the ability to resolve 54 NBMA next hops based on destination and additional data packet 55 information. We refer to the presented extension as the "Flow 56 Extension." 58 There are multiple possible reasons why an NBMA next hop may depend 59 on the contents of a data packet. One example is configured 60 administrative policy at serving or transit NHSs. The choice of 61 selecting next hop based on just destination address, or selecting 62 next hop based on additional data packet information is considered to 63 be a local policy decision. The presented extension will 64 interoperate with NHSs and NHCs that don't support the Flow Extension 65 as well as those that implement disparate selection policies. 67 2. Discussion 69 The Flow Extension enables the communication of a limited amount of 70 policy information to the source NHC from NHSs along the routed path. 71 NHRP currently supports a very limited amount of policy communication 72 via a resolution NAK. With the resolution NAK, a source NHS can be 73 informed that a resolution request is administratively prohibited. 74 The Flow Extension allows the communication of additional policy 75 information. This additional policy information indicates which 76 types of data traffic, or flows, can be directed to which NBMA next 77 hops. 79 The Flow Extension supports the communication of one final piece of 80 policy information. With the Flow Extension, the source NHC can be 81 informed that matching data packets should be silently discarded. 82 When a source NHC drops such traffic, network resource usage is 83 reduced since such traffic would be discarded further along the 84 routed path. Source NHCs are not required to discard any data 85 traffic and may forward any data packets along the routed path. 86 Currently, source NHCs that cannot resolve an NBMA next hop are 87 expected to forward data packets along the routed path. 89 The rest of this section covers general issues related to Flow 90 Extension creation and processing. Specific format requirements and 91 Resolution Request and Reply message processing impact are covered in 92 sections 3 and 4 respectively. 94 2.1 Policy Communication 96 The objective of the Flow Extension is twofold. The first is to 97 enable the resolution of a single destination address to more than 98 one NBMA next hop address based on flow information. The second is 99 to allow selected traffic to a particular destination address to be 100 resolved to one or more NBMA next hop addresses while other traffic 101 to the same destination address is not resolved. When traffic is 102 unresolved, the extension allows the source NHC to be informed that 103 such traffic should be dropped. NHCs are permitted to continue 104 handling unresolved traffic in the same fashion as described 105 [RFC2332]. 107 To achieve the two objectives of the Flow Extension, the extension is 108 included in NHRP Resolution Request and Reply messages. In Request 109 messages, the Flow Extension contains a description of the specific 110 flow associated with the request, the flow matching capabilities of 111 the requester, and the policy information from the NHSs that have 112 already processed the Request message. Reply messages are handled in 113 the traditional manner per [RFC2332] and also include the policy 114 information from the serving NHS. 116 When a source NHC creates a Resolution Request with a Flow Extension, 117 it describes its capabilities and the flow associated with the 118 request. The requesting NHC also initializes the policy information 119 fields that will be updated by downstream NHSs to indicate an 120 unrestrictive policy. NHSs add information based on their local 121 administrative policy. This information can indicate that the flow 122 is administratively prohibited and should be dropped at the source 123 NHC, that the specific flow is acceptable or, lastly, that the flow 124 falls within a set of acceptable flows. NHSs processing Request 125 messages may indicate that their policy is more restrictive than the 126 policy described in the received message and are not allowed to 127 indicate a less restrictive policy. Serving NHSs add their policy 128 information when generating a Resolution Reply message. 130 Once the Reply message reaches the requester, the requester is 131 expected to follow the policy information contained in the Reply. 132 This includes only sending data packets matching the described flow 133 to the listed NBMA next hop addresses, and following the drop 134 indication in NAK messages. The requester is permitted to handle NAK 135 Reply messages and associated data packets in the traditional, pre 136 Flow Extension, fashion. The requester is also permitted to forward 137 data packets matching the described flow via the routed path rather 138 than following the information in a non-NAK Reply message. 140 2.2 Compatibility 142 There are no compatibility issues with implementations that do not 143 support the Flow Extension. [RFC2332] requires that the extension be 144 transported even when a processing station does not support the 145 extension. Flow Extension aware stations may generate and handle 146 multiple resolution requests for the same destination each with a 147 different flow descriptions. NHSs that do not support the extension 148 will see such flow specific requests as revalidation requests all for 149 the same destination. 151 From the policy standpoint, NHSs that do not support the extension 152 are able to verify that a request is administratively acceptable, but 153 do so just on a destination rather than flow basis. When a 154 particular Resolution Request message containing a Flow Extension is 155 processed by a combination of extension supporting and non-supporting 156 NHSs, the corresponding Reply message will reflect flow based policy 157 from extension supporting NHSs and the coarser grained destination 158 based policy from non-supporting NHSs. 160 2.3 NHS Handling of Non-Served NHC Resolution Requests 162 The NHRP specification [RFC2332] requires that NHCs only send 163 Resolution Request messages to their serving NHS, but it places no 164 corresponding requirement on NHSs. In order to ensure that a 165 Resolution Request message follows the routed path, NHSs that support 166 the Flow Extension MUST respond to Request messages which contain the 167 Flow Extension from non-served NHCs with an Error Indication. 169 2.4 Security Considerations 171 The Flow Extension is used to communicate a limited amount of policy 172 information. Consequently there are a number of security related 173 issues. The issues have to do with both the communication of the 174 policy information and with the use of the policy information. 176 2.4.1 Trust of NHRP Stations 178 The Flow Extension is used to relay policy information between NHCs 179 and NHSs. For the extension to be useful NHSs and NHCs must rely 180 upon each other to relay policy information correctly, to properly 181 update the information and to act appropriately based on the 182 information. Potential threats include downstream and reverse path 183 NHSs overriding communicated policy information, and NHCs that send 184 NBMA Next Hops traffic not included in the communicated policy 185 information. 187 In environments where reliance (and trust) between NHSs and NHCs 188 posses an unacceptable risk, the NHRP Authentication Extension SHOULD 189 be used to identify trusted NHRP speakers and the Flow Extension 190 SHOULD only be supported (processed from and sent to) between 191 authenticated speakers. In environments where this approach is 192 unacceptable or unavailable support for the Flow Extension SHOULD be 193 disabled. With Extension processing disabled, the threat becomes the 194 same as that posed by standard NHRP. 196 2.4.2 Dissemination of Policy Information 198 With the Flow Extension, an NHS' forwarding policy is communicated to 199 other NHSs and the requesting NHC. In some cases the communication 200 of this policy information will be acceptable, in others the 201 dissemination of such information may be undesirable. In the later 202 case, the communicated policy can be limited to a minimum. If it is 203 unacceptable to communicate any policy information, again, support 204 for the Flow Extension SHOULD be disabled. 206 It should be noted that the Resolution Reply messages containing Flow 207 Extensions may be carried along a different routed path from the 208 serving NHS to the requesting NHC. Forcing symmetric routing was 209 considered in order to limit the dissemination of policy information, 210 but was found to result in incompatibility with existing NHRP 211 implementations. 213 2.4.3 Policy Information Updates 215 An NHS' local policy information may be updated at anytime. Such an 216 update may relate to previously requested resolution information. 217 The new policy information will eventually be communicated once the 218 source NHC refreshes the resolution information. Between the time 219 the information is changed and the resolution is refreshed, the 220 source NHS may handle data packets based on the out of date policy 221 information. 223 The handling of data packets based on old policy information may be 224 an issue for some environments. In cases where this is an issue, 225 NHSs can force the removal of the related resolution information. To 226 do this, an NHS SHOULD cache information related to Resolution 227 Requests that contain a Flow Extension, and then issue Purge Request 228 messages for destinations that are affected by local policy updates. 230 3. NHRP Flow Extension Format 232 Compulsory = 0 233 Type = To Be Assigned 234 Length = variable, see format definitions 235 The NHRP Flow Extension is carried in NHRP Resolution Request and 236 Reply messages to convey flow related information. A source NHC 237 includes the extension to indicate that the extension is supported. 238 Within the extension, the source NHC identifies the flow associated 239 with the resolution request, indicates its flow matching 240 capabilities, and initializes the policy information related fields. 241 Transit NHSs update the policy related fields based on their local 242 policies. The NHS responding to the Request message, the 243 "responder", copies a received Flow Extension to the corresponding 244 Resolution Reply message and updates the policy related fields based 245 on its local policies. 247 The format of the extension varies based on the traffic being 248 described. In all formats, the extension has request and policy 249 information related fields. The request related fields describe the 250 flow from the source NHC's perspective. The policy information 251 related fields are used to relay the policy found along the routed 252 path to the destination, and may be set by transit and serving NHSs. 253 The first byte of the extension indicates the type of flow 254 information associated with the request. The source NHS selects the 255 type based on its capabilities. The traffic type values defined in 256 this document are: 258 Value Label Description 259 ======================================================== 260 0x00 Reserved Illegal Value 261 0x01 IPv4 Generic IPv4 Header 262 0x02 IPv6 Generic IPv6 Header 263 0x03 IPv4-TCP/UDP IPv4 Header with TCP/UDP like ports 264 0x04 IPv6-TCP/UDP IPv6 Header with TCP/UDP like ports 265 0x05 IPv4-IPSEC IPv4 Header with IPSEC SPI 266 0x06 IPv6-IPSEC IPv6 Header with IPSEC SPI 267 0x07-0x7F Reserved To be assigned by IANA 268 0x80-0xFF Reserved Allocated to the ATM forum 270 A Flow Extension containing an unrecognized traffic type values SHALL 271 be treated as an unrecognized extension. 273 3.1 NHRP Flow Extension Format: IPv4 275 This format is used to describe any type of IPv4 data packet. It is 276 expected to be used when a more specific description is not defined 277 or supported. 279 Extension Length = 16 281 0 1 2 3 282 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 |Flow Type=0x01 |D| Flags |Type of Service| Protocol | 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 | Source IP Address | 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 | Destination IP Address | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | ToS Mask | Src Prefix | Dst Prefix | Unused | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 Flow Type 294 Indicates type of flow information carried in the extension. 296 D bit 297 When set, the "D" bit indicates that data packets matching the flow 298 information SHOULD be silently discarded by the source NHC. If the 299 source NHC forwards matching data packets, such packets MUST be 300 forwarded via the routed path. 302 This bit is set to zero (0) in Resolution Request messages and may 303 be set by NHSs. If a Flow Extension is received with a set value 304 (1), an NHS MUST forward the extension with the "D" bit set. 306 Flags 307 The following flags are defined IPv4 flows: 308 0 1 2 3 4 5 6 309 +--+--+--+--+--+--+--+ 310 | unused |Da|Sa|P |T | 311 +--+--+--+--+--+--+--+ 313 Da 314 When set, this bit indicates that flows may be identified using 315 prefix matching on the Destination IP Address field of the IP 316 Header. Prefix matching uses a specified number of bits from the 317 address field rather than the whole field. This bit is set by 318 the source NHC and MAY NOT be modified by transit or serving 319 NHSs. 321 Sa 322 When set, this bit indicates that flows may be identified using 323 prefix matching on the Source IP Address field of the IP Header. 324 This bit is set by the source NHC and MAY NOT be modified by 325 transit or serving NHSs. 327 P 328 When set, this bit indicates that flows MUST be identified using 329 the value in the Protocol field. This bit is only meaningfull if 330 the Protocol field is non-zero. This bit MUST be cleared by the 331 source NHC and MAY be set transit or serving NHSs. When a Flow 332 Extension is received with this bit set, an NHS MUST NOT clear 333 this bit. 335 T 336 When set, this bit indicates that flows may be identified based 337 on the Type of Service field of the IP Header. This bit is set 338 by the source NHC and MAY NOT be modified by transit or serving 339 NHSs. 341 Unused bits and fields MUST be set to zero (0) by the source NHC and 342 not modified by transit or serving NHSs. 344 Type of Service 345 Value of the IP Type of Service field for the associated flow. 346 This value is set by the source NHC and MAY NOT be modified by 347 transit or serving NHSs. This field is only meaningful when the 348 "T" bit is set. 350 Protocol 351 Value of the next level protocol field for the associated flow. A 352 value of zero (0) indicates that the source NHC will not include 353 this field in identification of the associated flow. This field is 354 set by the source NHC and MAY NOT be modified by transit or serving 355 NHSs. 357 Source IP Address 358 The source IP address for the associated flow. A value of zero (0) 359 indicates that the source NHC will not include this field in flow 360 identification. This field is set by the source NHC and MAY NOT be 361 modified by transit or serving NHSs. 363 Destination IP Address 364 The destination IP address of the associated flow. A value of zero 365 (0) indicates that the source NHC will not include this field in 366 flow identification. This field is set by the source NHC and MAY 367 NOT be modified by transit or serving NHSs. 369 ToS Mask 370 This field indicates the bits that must be set in a data packet's 371 Type of Service field in order to be associated with the flow. A 372 value of zero (0) indicates that the field SHALL NOT be included in 373 flow identification. This field is only meaningful when the "T" 374 bit is set. 376 This field MUST be initialized by the source NHC to a value of zero 377 (0). NHSs add their policy information by setting cleared bits in 378 the field. NHSs MUST NOT clear bits in the field. 380 Src Prefix 381 This field carries the number of bits of the Source IP Address 382 field to be used in identifying data packets associated with the 383 flow. A value of zero (0) indicates that the field SHALL NOT be 384 included in flow identification. A value of 32 indicates a host 385 address, i.e. all bits should be used. Values greater than 32 are 386 illegal. This field is only meaningful when the Source IP Address 387 field is non-zero and when the "Sa" bit is set. 389 This field MUST be initialized by the source NHC to a value of zero 390 (0). NHSs MAY increase the value based on their policy 391 information. NHSs MUST NOT decrease the value. 393 Dst Prefix 394 This field carries the number of bits of the Destination IP Address 395 field to be used in identifying data packets associated with the 396 flow. A value of 0 or 32 indicates a host address, i.e. all bits 397 should be used. Values greater than 32 are illegal. This field is 398 only meaningful when the Destination IP Address field is non-zero 399 and when the the "Da" bit is set. 401 This field MUST be initialized by the source NHC to a value of zero 402 (0). NHSs MAY increase the value based on their policy 403 information. NHSs MUST set the value to 32 to indicate a host 404 address policy. NHSs MUST NOT decrease the value. 406 3.2 NHRP Flow Extension Format: IPv6 408 This format is used to describe any type of IPv6 data packet. It is 409 expected to be used when a more specific description is not defined 410 or supported. 412 Extension Length = 48 414 0 1 2 3 415 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 |Flow Type=0x02 |D| IPv6 Flags | Next Header | 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 |PT Len | Prio./Traffic Class/Flow Label (PT) | 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 | | 422 | Source IPv6 Address (16 bytes) | 423 | | 424 | | 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 | | 427 | Destination IPv6 Address (16 bytes) | 428 | | 429 | | 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 |DPT Len| Desired Prio./Traffic Class/Flow Label (DPT) | 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 |IPv6 Src Prefix|IPv6 Dst Prefix| Unused | 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 IPv6 Flags 437 The following flags are defined IPv6 flows: 439 0 1 440 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 441 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 442 | unused |Da |Sa |DPT|PT |NH | 443 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 445 DPT 446 When set, this bit indicates that flows MUST be identified based 447 on the Prio./Traffic Class and Flow Label fields of the IP 448 Header. This bit MUST be zero when the PT bit is zero. This bit 449 MUST be cleared by the source NHC and MAY be set transit or 450 serving NHSs. When a Flow Extension is received with this bit 451 set, an NHS MUST NOT clear this bit. 453 PT 454 When set, this bit indicates that flows may be identified based 455 on the Prio./Traffic Class and Flow Label fields of the IP 456 Header. This bit is set by the source NHC and MAY NOT be 457 modified by transit or serving NHSs. 459 NH 460 When set, this bit indicates that flows MUST be identified using 461 the value in the Next Header field. This bit is only meaning 462 full if the Next Header field is non-zero. This bit MUST be 463 cleared by the source NHC and MAY be set transit or serving NHSs. 464 When a Flow Extension is received with this bit set, an NHS MUST 465 NOT clear this bit. 467 Next Header 468 Value of the IPv6 Next Header field for the associated flow. A 469 value of zero (0) indicates that the source NHC will not include 470 this field in identification of the associated flow. This field is 471 set by the source NHC and MAY NOT be modified by transit or serving 472 NHSs. 474 PT Len 475 Indicates the number of bits in the Prio./Traffic Class (first) 476 portion of the PT field. This field is set by the source NHC and 477 is not modified by transit or serving NHSs. The source NHS MAY set 478 this value to zero (0). This field is only meaningful when the 479 "PT" bit is set. 481 Prio./Traffic Class and Flow Label (PT) 482 The 28-bit PT field for the associated flow. The PT field is 483 composed of two parts. The first part carries either the IPv6 484 priority value or the the proposed IPv6 Traffic Class field. The 485 second part is the IPv6 Flow Label. This field is set by the 486 source NHC and MAY NOT be modified by transit or serving NHSs. 487 This field is only meaningful when the "PT" bit is set. 489 Source IPv6 Address 490 The source IPv6 address for the associated flow. A value of zero 491 (0) indicates that the source NHC will not include this field in 492 flow identification. This field is set by the source NHC and MAY 493 NOT be modified by transit or serving NHSs. 495 Destination IPv6 Address 496 The destination IPv6 address of the associated flow. A value of 497 zero (0) indicates that the source NHC will not include this field 498 in flow identification. This field is set by the source NHC and 499 MAY NOT be modified by transit or serving NHSs. 501 DPT Len 502 This field indicates the number of bits in the Prio./Traffic Class 503 (first) portion of the DPT field. This field is only meaningful 504 when the "DPT" bit is set. Legal values are between 0 and 28. 505 This field may contain a different value than the PT Len field. 507 This field MUST be initialized by the source NHC to a value of zero 508 (0). Transit and serving NHSs MAY set this field only when the 509 received Flow Extension has the DPT bit cleared and the PT bit set. 510 If an NHS sets this field, it MUST also set the DPT bit. 512 Desired Prio./Traffic Class and Flow Label (DPT) 513 This field carries the Prio./Traffic Class and Flow Label fields 514 associated with the flow. The Prio./Traffic Class portion of the 515 DPT field indicates the bits that must be set in a data packet's 516 Prio./Traffic Class field in order to be associated with the flow. 517 The Flow Label portion of the DPT field contains the value that 518 must be in a data packet's Flow Label field in order to be 519 associated with the flow. 521 The division of of the Prio./Traffic Class field is indicated by 522 the DPT Len field. The Prio./Traffic Class field is contained in 523 the first (leftmost) DPT Len bits of the DPT field. The Flow Label 524 portion is in the last (rightmost) 28 minus DPT Len bits of the DPT 525 field. This field is only meaningful when the "DPT" bit is set. 527 This field MUST be initialized by the source NHC to a value of zero 528 (0). NHSs add their Prio./Traffic Class related policy information 529 by setting cleared bits in the Prio./Traffic Class portion of the 530 DPT field. NHSs MUST NOT clear bits in the Prio./Traffic Class 531 field. NHSs MAY set the Flow Label portion of the field when the 532 received Flow Extension has the DPT bit cleared and the PT bit set. 533 If an NHS sets the Flow Label portion of the field, it MUST also 534 set the DPT bit. 536 IPv6 Src Prefix 537 This field carries the number of bits of the Source IPv6 Address 538 field to be used in identifying data packets associated with the 539 flow. A value of zero (0) indicates that the field SHALL NOT be 540 included in flow identification. A value of 128 indicates a host 541 address, i.e. all bits should be used. Values greater than 128 are 542 illegal. This field is only meaningful when the Source IPv6 543 Address field is non-zero and when the "Sa" bit is set. 545 This field MUST be initialized by the source NHC to a value of zero 546 (0). NHSs MAY increase the value based on their policy 547 information. NHSs MUST NOT decrease the value. 549 IPv6 Dst Prefix 550 This field carries the number of bits of the Destination IPv6 551 Address field to be used in identifying data packets associated 552 with the flow. A value of 0 or 128 indicates a host address, i.e. 553 all bits should be used. Values greater than 128 are illegal. 554 This field is only meaningful when the Destination IPv6 Address 555 field is non-zero and when the the "Da" bit is set. 557 This field MUST be initialized by the source NHC to a value of zero 558 (0). NHSs MAY increase the value based on their policy 559 information. NHSs MUST set the value to 128 to indicate a host 560 address policy. NHSs MUST NOT decrease the value. 562 3.3 NHRP Flow Extension Format: IPv4-TCP/UDP 564 This format is used to describe IPv4 data packets carrying a protocol 565 that supports TCP/UDP-like ports. Specifically protocols that carry 566 a 16-bit source port field at the start of the transport header and 567 16-bit destination port field starting at bit 16 of the transport 568 header. 570 Fields and flags not listed have the same meaning as defined in 571 previous sections. 573 Extension Length = 28 575 0 1 2 3 576 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 578 |Flow Type=0x03 |D| Flags |Type of Service| Protocol | 579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 | Source IP Address | 581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 582 | Destination IP Address | 583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 584 | ToS Mask | Src Prefix | Dst Prefix | Unused | 585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 586 | Source Port | Destination Port | 587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 588 | Src Range Start | Src Range End | 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 590 | Dst Range Start | Dst Range End | 591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 Flags 594 0 1 2 3 4 5 6 595 +--+--+--+--+--+--+--+ 596 |0 |Dr|Sr|Da|Sa|P |T | 597 +--+--+--+--+--+--+--+ 599 Dr 600 When set, this bit indicates that flows may be identified using a 601 range of acceptable values in the Destination Port field of the 602 transport header. This bit is set by the source NHC and MAY NOT 603 be modified by transit or serving NHSs. 605 Sr 606 When set, this bit indicates that flows may be identified using a 607 range of acceptable values in the Source Port field of the 608 transport header. This bit is set by the source NHC and MAY NOT 609 be modified by transit or serving NHSs. 611 Source Port 612 Value of the Source Port field of the transport header for the 613 associated flow. A value of zero (0) indicates that the source NHC 614 has not include this field in flow identification. This field is 615 set by the source NHC and MAY NOT be modified by transit or serving 616 NHSs. 618 Destination Port 619 Value of the Destination Port field of the transport header for the 620 associated flow. A value of zero (0) indicates that the source NHC 621 has not include this field in flow identification. This field is 622 set by the source NHC and MAY NOT be modified by transit or serving 623 NHSs. 625 Src Range Start 626 This field carries the lower bound on Source Port field values that 627 will be considered to be associated with the flow. A zero (0) 628 value indicates that the Source Port field of the transport header 629 is not included in flow identification. This field is only 630 meaningful when the Source Port field is non-zero. When the "Sr" 631 bit is cleared (0), an NHS setting this field MUST set the Src 632 Range Start and Src Range End fields to the same value. This field 633 MUST NOT be set to a value greater than the Source Port field. 635 This field MUST be initialized by the source NHC to a value of zero 636 (0). NHSs MAY increase the value based on their policy 637 information. NHSs MUST NOT decrease the value. 639 Src Range End 640 This field carries the upper bound on Source Port field values that 641 will be considered to be associated with the flow. This field is 642 only meaningful when the Source Port and Src Range Start fields are 643 non-zero. When the "Sr" bit is cleared (0), an NHS setting this 644 field MUST set the Src Range Start and Src Range End fields to the 645 same value. This field MUST NOT be set to a value less than the 646 Source Port field. 648 This field MUST be initialized by the source NHC to a value of all 649 ones (0xffff). NHSs MAY decrease the value based on their policy 650 information. NHSs MUST NOT increase the value. 652 Dst Range Start 653 This field carries the lower bound on Destination Port field values 654 that will be considered to be associated with the flow. A zero (0) 655 value indicates that the Destination Port field of the transport 656 header is not included in flow identification. This field is only 657 meaningful when the Destination Port field is non-zero. When the 658 "Dr" bit is cleared (0), an NHS setting this field MUST set the Dst 659 Range Start and Dst Range End fields to the same value. This field 660 MUST NOT be set to a value greater than the Destination Port field. 662 This field MUST be initialized by the source NHC to a value of zero 663 (0). NHSs MAY increase the value based on their policy 664 information. NHSs MUST NOT decrease the value. 666 Dst Range End 667 This field carries the upper bound on Destination Port field values 668 that will be considered to be associated with the flow. This field 669 is only meaningful when the Destination Port and Dst Range Start 670 fields are non-zero. When the "Dr" bit is cleared (0), an NHS 671 setting this field MUST set the Dst Range Start and Dst Range End 672 fields to the same value. This field MUST NOT be set to a value 673 less than the Destination Port field. 675 This field MUST be initialized by the source NHC to a value of all 676 ones (0xffff). NHSs MAY decrease the value based on their policy 677 information. NHSs MUST NOT increase the value. 679 3.4 NHRP Flow Extension Format: IPv6-TCP/UDP 681 This format is used to describe IPv6 data packets carrying a protocol 682 that supports TCP/UDP-like ports. 684 Fields and flags not listed have the same meaning as defined in 685 previous sections. 687 Extension Length = 60 689 0 1 2 3 690 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 692 |Flow Type=0x04 |D| IPv6 Flags | Next Header | 693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 694 |PT Len | Prio./Traffic Class/Flow Label (PT) | 695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 696 | | 697 | Source IPv6 Address (16 bytes) | 698 | | 699 | | 700 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 701 | | 702 | Destination IPv6 Address (16 bytes) | 703 | | 704 | | 705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 706 |DPT Len| Desired Prio./Traffic Class/Flow Label (DPT) | 707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 708 |IPv6 Src Prefix|IPv6 Dst Prefix| Unused | 709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 710 | Source Port | Destination Port | 711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 712 | Src Range Start | Src Range End | 713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 714 | Dst Range Start | Dst Range End | 715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 717 IPv6 Flags 718 0 1 719 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 720 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 721 | unused |Dr |Sr |Da |Sa |DPT|PT |NH | 722 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 724 3.5 NHRP Flow Extension Format: IPv4-IPSEC 726 This format is used to describe IPv4 data packets carrying an IPSEC 727 transport protocol. There are currently two such protocols defined: 728 Authentication Header (AH), for authentication[RFC1826]; and 729 Encapsulating Security Payload (ESP), for integrity and 730 confidentiality[RFC1827]. Flows are identified for both protocols 731 using the protocol's IPSEC Security Parameter Index, or SPI, field. 733 Fields and flags not listed have the same meaning as defined in 734 previous sections. 736 Extension Length = 20 738 0 1 2 3 739 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 741 |Flow Type=0x05 |D| Flags |Type of Service| Protocol | 742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 743 | Source IP Address | 744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 745 | Destination IP Address | 746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 747 | ToS Mask | Src Prefix | Dst Prefix | Unused | 748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 749 | Security Parameter Index (SPI) | 750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 752 Flags 753 0 1 2 3 4 5 6 754 +--+--+--+--+--+--+--+ 755 | unused |Da|Sa|P |T | 756 +--+--+--+--+--+--+--+ 758 Security Parameter Index 759 The Security Parameter Index (SPI) field value associated with the 760 flow. The SPI field is 32-bits long and located at the start of 761 the transport header for ESP, and at bit 32 of the transport header 762 for AH. This value is set by the source NHC and MAY NOT be 763 modified by transit or serving NHSs. 765 3.6 NHRP Flow Extension Format: IPv6-IPSEC 767 This format is used to describe IPv6 data packets carrying an IPSEC 768 transport protocol. 770 Fields and flags not listed have the same meaning as defined in 771 previous sections. 773 Extension Length = 56 775 0 1 2 3 776 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 778 |Flow Type=0x06 |D| IPv6 Flags | Next Header | 779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 780 |PT Len | Prio./Traffic Class/Flow Label (PT) | 781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 782 | | 783 | Source IPv6 Address (16 bytes) | 784 | | 785 | | 786 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 787 | | 788 | Destination IPv6 Address (16 bytes) | 789 | | 790 | | 791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 792 |DPT Len| Desired Prio./Traffic Class/Flow Label (DPT) | 793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 794 |IPv6 Src Prefix|IPv6 Dst Prefix| Unused | 795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 796 | Security Parameter Index (SPI) | 797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 799 IPv6 Flags 800 0 1 801 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 802 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 803 | unused |Da |Sa |DPT|PT |NH | 804 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 806 4. Message Processing 808 If a requester wishes to obtain flow information, it SHALL include 809 the Flow Extension in the NHRP Resolution Request. The requester 810 SHOULD include the most specific flow type that it supports. The 811 requester MAY specify a particular flow or subset of flows by setting 812 some or all of the fields in the flow detail to non-zero values. 814 When processing NHRP Resolution Request messages, NHSs that support 815 the Flow Extension MUST verify that the Request is following the 816 routed path. The NHS checks if the sender of the message is an NHC. 817 When the sender is an NHC, the NHS verifies that the NHC is one of 818 its served NHCs. If the sending NHC is not a served NHC, then the 819 NHS MUST generate an NHRP Error Indication with an Error Code of 820 Protocol Error. 822 If the protocol check passes, NHSs processing Request messages 823 containing a Flow Extension MUST examine the described flow to verify 824 that it is acceptable. Both the request and policy information 825 related fields MUST be examined. The request portion of the 826 extension is unacceptable if data packets matching the flow would not 827 be forwarded. The policy information is unacceptable if the Flow 828 Extension cannot be updated to reflect an NHS' policy information. 829 If both portions are acceptable, the NHS MUST update the policy 830 information related fields as needed to reflect its policy and then 831 handle the Request message per [RFC2332]. Note that an NHS MAY NOT 832 change any policy information field to be less restrictive. 834 If either the request or policy information portions of the Flow 835 Extension is unacceptable, the NHS MUST issue a NAK Resolution Reply 836 of type Administratively Prohibited. The NHS MUST update the Flow 837 Extension to reflect the matching policy and SHOULD set the "D" bit. 838 When updating the policy information portion of the Flow Extension, 839 an NHS SHOULD describe the matching (failed or acceptable) policy in 840 the broadest possible terms rather than simply replaying the 841 requested flow. An NHS responder MAY choose to reply with limited 842 information for security reasons. 844 On receipt of a Resolution Reply message that contains a Flow 845 Extension, a requester that supports the Flow Extension SHOULD follow 846 the policy information relayed in the extension. If the requester 847 does not follow the policy, the requester MUST NOT forward data 848 packets based on the information contained in the reply message. A 849 requester may chose not to follow a relayed policy because the policy 850 is unacceptable or due to resource limitations. 852 In the expected normal case, the requester will follow the policy 853 information relayed in the extension. When the message is a NAK 854 Resolution Reply of type Administratively Prohibited the requester 855 SHOULD check the "D" bit in the Flow Extension. If the bit is set, 856 data packets matching the flow information SHOULD be silently 857 discarded. If the requester forwards matching data packets, such 858 packets MUST be forwarded via the routed path. 860 When the received Resolution Reply message does not contain a NAK, 861 the requester SHOULD forward data packets that match the flow 862 specified in the Flow Extension using the information contained in 863 the Resolution Reply. The requester MUST NOT forward data packets 864 that do not match specified flow using the information contained in 865 the Resolution Reply. 867 5. IANA Considerations 869 IANA is requested to manage and assign the range of Flow Type field 870 values from 0x07 to 0x7F. New assignments should be made with the 871 guidance of the relevant IESG Area Director or their designee. 872 Additionally, all requests for assignments should be honored when the 873 usage of the requested value is documented in a publicly available 874 and unrestricted (including time) form. Preferably the document will 875 be available via a standards organization's web site. 877 6. References 879 [RFC1826] Atkinson, R., "IP Authentication Header", RFC 1826, NRL, 880 August 1995. 882 [RFC1827] Atkinson, R., "IP Encapsulating Security Payload", RFC 883 1827, NRL, August 1995. 885 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 886 Requirement Levels," RFC 2119. 888 [RFC2332] Luciani, J., Katz, D., Piscitello, D., Cole, B., Doraswamy, N., 889 "NBMA Next Hop Resolution Protocol (NHRP)," RFC 2332. 891 7. Acknowledgments 893 The authors thank Rajesh Varadarajan, Ravi Shekhar and Jim Luciani 894 for their valuable comments and corrections. 896 8. Authors' Addresses 898 Lou Berger Rob Enns 899 FORE Systems Berkeley Networks 900 1595 Spring Hill Road 1805 McCandless Drive 901 Vienna, VA 22182 USA Milpitas, CA 95035 902 Phone: +1 703-245-4544 Phone: 408-719-3059 903 Email: lberger@fore.com Email: rpe@berkeleynet.com