One document matched: draft-ietf-ion-nhrp-flowext-00.txt
ION Working Group Lou Berger
INTERNET DRAFT FORE Systems
<draft-ietf-ion-nhrp-flowext-00.txt> Rob Enns
Berkeley Networks
Expires: December 1998
NHRP Flow Extension
June 22, 1998
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress.''
To view the entire list of current Internet-Drafts, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
Abstract
This document presents an extension to NHRP [RFC2332] that enables
resolution of NBMA next hop addresses based on destination flow
information. This extension also enables NHSs to relay simple
forwarding policy to source stations (NHCs).
1. Introduction
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
document, are to be interpreted as described in [RFC2119].
The NBMA Next Hop Resolution Protocol provides a mechanism for a
station to resolve a destination internetworking layer address into
the corresponding NBMA subnetwork addresses of the "NBMA next hop."
As defined in [RFC2332], NBMA next hop subnetwork addresses are
Berger, Enns Expires: December 1998 [Page 1]
Internet Draft NHRP Flow Extension June 1998
resolved based on an internetworking layer address and, possibly, an
address prefix.
Resolution based on destination addresses may not be adequate for all
cases. This document is motivated by one such case. The case
addressed by this document is when the NBMA next hop is dependent on
the contents of a data packet, i.e. its type of traffic. The
extension presented in this document provides the ability to resolve
NBMA next hops based on destination and additional data packet
information. We refer to the presented extension as the "Flow
Extension."
There are multiple possible reasons why an NBMA next hop may depend
on the contents of a data packet. One example is configured
administrative policy at serving or transit NHSs. The choice of
selecting next hop based on just destination address, or selecting
next hop based on additional data packet information is considered to
be a local policy decision. The presented extension will
interoperate with NHSs and NHCs that don't support the Flow Extension
as well as those that implement disparate selection policies.
2. Discussion
The Flow Extension enables the communication of a limited amount of
policy information to the source NHC from NHSs along the routed path.
NHRP currently supports a very limited amount of policy communication
via a resolution NAK. With the resolution NAK, a source NHS can be
informed that a resolution request is administratively prohibited.
The Flow Extension allows the communication of additional policy
information. This additional policy information indicates which
types of data traffic, or flows, can be directed to which NBMA next
hops.
The Flow Extension supports the communication of one final piece of
policy information. With the Flow Extension, the source NHC can be
informed that matching data packets should be silently discarded.
When a source NHC drops such traffic, network resource usage is
reduced since such traffic would be discarded further along the
routed path. Source NHCs are not required to discard any data
traffic and may forward any data packets along the routed path.
Currently, source NHCs that cannot resolve an NBMA next hop are
expected to forward data packets along the routed path.
The rest of this section covers general issues related to Flow
Extension creation and processing. Specific format requirements and
Resolution Request and Reply message processing impact are covered in
sections 3 and 4 respectively.
Berger, Enns Expires: December 1998 [Page 2]
Internet Draft NHRP Flow Extension June 1998
2.1 Policy Communication
The objective of the Flow Extension is twofold. The first is to
enable the resolution of a single destination address to more than
one NBMA next hop address based on flow information. The second is
to allow selected traffic to a particular destination address to be
resolved to one or more NBMA next hop addresses while other traffic
to the same destination address is not resolved. When traffic is
unresolved, the extension allows the source NHC to be informed that
such traffic should be dropped. NHCs are permitted to continue
handling unresolved traffic in the same fashion as described
[RFC2332].
To achieve the two objectives of the Flow Extension, the extension is
included in NHRP Resolution Request and Reply messages. In Request
messages, the Flow Extension contains a description of the specific
flow associated with the request, the flow matching capabilities of
the requester, and the policy information from the NHSs that have
already processed the Request message. Reply messages are handled in
the traditional manner per [RFC2332] and also include the policy
information from the serving NHS.
When a source NHC creates a Resolution Request with a Flow Extension,
it describes its capabilities and the flow associated with the
request. The requesting NHC also initializes the policy information
fields that will be updated by downstream NHSs to indicate an
unrestrictive policy. NHSs add information based on their local
administrative policy. This information can indicate that the flow
is administratively prohibited and should be dropped at the source
NHC, that the specific flow is acceptable or, lastly, that the flow
falls within a set of acceptable flows. NHSs processing Request
messages may indicate that their policy is more restrictive than the
policy described in the received message and are not allowed to
indicate a less restrictive policy. Serving NHSs add their policy
information when generating a Resolution Reply message.
Once the Reply message reaches the requester, the requester is
expected to follow the policy information contained in the Reply.
This includes only sending data packets matching the described flow
to the listed NBMA next hop addresses, and following the drop
indication in NAK messages. The requester is permitted to handle NAK
Reply messages and associated data packets in the traditional, pre
Flow Extension, fashion. The requester is also permitted to forward
data packets matching the described flow via the routed path rather
than following the information in a non-NAK Reply message.
Berger, Enns Expires: December 1998 [Page 3]
Internet Draft NHRP Flow Extension June 1998
2.2 Compatibility
There are no compatibility issues with implementations that do not
support the Flow Extension. [RFC2332] requires that the extension be
transported even when a processing station does not support the
extension. Flow Extension aware stations may generate and handle
multiple resolution requests for the same destination each with a
different flow descriptions. NHSs that do not support the extension
will see such flow specific requests as revalidation requests all for
the same destination.
From the policy standpoint, NHSs that do not support the extension
are able to verify that a request is administratively acceptable, but
do so just on a destination rather than flow basis. When a
particular Resolution Request message containing a Flow Extension is
processed by a combination of extension supporting and non-supporting
NHSs, the corresponding Reply message will reflect flow based policy
from extension supporting NHSs and the coarser grained destination
based policy from non-supporting NHSs.
2.3 NHS Handling of Non-Served NHC Resolution Requests
The NHRP specification [RFC2332] requires that NHCs only send
Resolution Request messages to their serving NHS, but it places no
corresponding requirement on NHSs. In order to ensure that a
Resolution Request message follows the routed path, NHSs that support
the Flow Extension MUST respond to Request messages which contain the
Flow Extension from non-served NHCs with an Error Indication.
2.4 Security Considerations
The Flow Extension is used to communicate a limited amount of policy
information. Consequently there are a number of security related
issues. The issues have to do with both the communication of the
policy information and with the use of the policy information.
2.4.1 Trust of NHRP Stations
The Flow Extension is used to relay policy information between NHCs
and NHSs. For the extension to be useful NHSs and NHCs must rely
upon each other to relay policy information correctly, to properly
update the information and to act appropriately based on the
information. Potential threats include downstream and reverse path
NHSs overriding communicated policy information, and NHCs that send
NBMA Next Hops traffic not included in the communicated policy
information.
In environments where reliance (and trust) between NHSs and NHCs
Berger, Enns Expires: December 1998 [Page 4]
Internet Draft NHRP Flow Extension June 1998
posses an unacceptable risk, the NHRP Authentication Extension SHOULD
be used to identify trusted NHRP speakers and the Flow Extension
SHOULD only be supported (processed from and sent to) between
authenticated speakers. In environments where this approach is
unacceptable or unavailable support for the Flow Extension SHOULD be
disabled. With Extension processing disabled, the threat becomes the
same as that posed by standard NHRP.
2.4.2 Dissemination of Policy Information
With the Flow Extension, an NHS' forwarding policy is communicated to
other NHSs and the requesting NHC. In some cases the communication
of this policy information will be acceptable, in others the
dissemination of such information may be undesirable. In the later
case, the communicated policy can be limited to a minimum. If it is
unacceptable to communicate any policy information, again, support
for the Flow Extension SHOULD be disabled.
It should be noted that the Resolution Reply messages containing Flow
Extensions may be carried along a different routed path from the
serving NHS to the requesting NHC. Forcing symmetric routing was
considered in order to limit the dissemination of policy information,
but was found to result in incompatibility with existing NHRP
implementations.
2.4.3 Policy Information Updates
An NHS' local policy information may be updated at anytime. Such an
update may relate to previously requested resolution information.
The new policy information will eventually be communicated once the
source NHC refreshes the resolution information. Between the time
the information is changed and the resolution is refreshed, the
source NHS may handle data packets based on the out of date policy
information.
The handling of data packets based on old policy information may be
an issue for some environments. In cases where this is an issue,
NHSs can force the removal of the related resolution information. To
do this, an NHS SHOULD cache information related to Resolution
Requests that contain a Flow Extension, and then issue Purge Request
messages for destinations that are affected by local policy updates.
3. NHRP Flow Extension Format
Compulsory = 0
Type = To Be Assigned
Length = variable, see format definitions
Berger, Enns Expires: December 1998 [Page 5]
Internet Draft NHRP Flow Extension June 1998
The NHRP Flow Extension is carried in NHRP Resolution Request and
Reply messages to convey flow related information. A source NHC
includes the extension to indicate that the extension is supported.
Within the extension, the source NHC identifies the flow associated
with the resolution request, indicates its flow matching
capabilities, and initializes the policy information related fields.
Transit NHSs update the policy related fields based on their local
policies. The NHS responding to the Request message, the
"responder", copies a received Flow Extension to the corresponding
Resolution Reply message and updates the policy related fields based
on its local policies.
The format of the extension varies based on the traffic being
described. In all formats, the extension has request and policy
information related fields. The request related fields describe the
flow from the source NHC's perspective. The policy information
related fields are used to relay the policy found along the routed
path to the destination, and may be set by transit and serving NHSs.
The first byte of the extension indicates the type of flow
information associated with the request. The source NHS selects the
type based on its capabilities. The traffic type values defined in
this document are:
Value Label Description
========================================================
0x00 Reserved Illegal Value
0x01 IPv4 Generic IPv4 Header
0x02 IPv6 Generic IPv6 Header
0x03 IPv4-TCP/UDP IPv4 Header with TCP/UDP like ports
0x04 IPv6-TCP/UDP IPv6 Header with TCP/UDP like ports
0x05 IPv4-IPSEC IPv4 Header with IPSEC SPI
0x06 IPv6-IPSEC IPv6 Header with IPSEC SPI
0x07-0x7F Reserved To be assigned by IANA
0x80-0xFF Reserved Allocated to the ATM forum
A Flow Extension containing an unrecognized traffic type values SHALL
be treated as an unrecognized extension.
3.1 NHRP Flow Extension Format: IPv4
This format is used to describe any type of IPv4 data packet. It is
expected to be used when a more specific description is not defined
or supported.
Berger, Enns Expires: December 1998 [Page 6]
Internet Draft NHRP Flow Extension June 1998
Extension Length = 16
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Flow Type=0x01 |D| Flags |Type of Service| Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ToS Mask | Src Prefix | Dst Prefix | Unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Flow Type
Indicates type of flow information carried in the extension.
D bit
When set, the "D" bit indicates that data packets matching the flow
information SHOULD be silently discarded by the source NHC. If the
source NHC forwards matching data packets, such packets MUST be
forwarded via the routed path.
This bit is set to zero (0) in Resolution Request messages and may
be set by NHSs. If a Flow Extension is received with a set value
(1), an NHS MUST forward the extension with the "D" bit set.
Flags
The following flags are defined IPv4 flows:
0 1 2 3 4 5 6
+--+--+--+--+--+--+--+
| unused |Da|Sa|P |T |
+--+--+--+--+--+--+--+
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.
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.
Berger, Enns Expires: December 1998 [Page 7]
Internet Draft NHRP Flow Extension June 1998
P
When set, this bit indicates that flows MUST be identified using
the value in the Protocol field. This bit is only meaningfull if
the Protocol field is non-zero. This bit MUST be cleared by the
source NHC and MAY be set transit or serving NHSs. When a Flow
Extension is received with this bit set, an NHS MUST NOT clear
this bit.
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.
Unused bits and fields MUST be set to zero (0) by the source NHC and
not modified by transit or serving NHSs.
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.
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.
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.
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.
ToS Mask
This field indicates the bits that must be set in a data packet's
Type of Service field in order to be associated with the flow. A
value of zero (0) indicates that the field SHALL NOT be included in
flow identification. This field is only meaningful when the "T"
bit is set.
Berger, Enns Expires: December 1998 [Page 8]
Internet Draft NHRP Flow Extension June 1998
This field MUST be initialized by the source NHC to a value of zero
(0). NHSs add their policy information by setting cleared bits in
the field. NHSs MUST NOT clear bits in the field.
Src Prefix
This field carries the number of bits of the Source IP Address
field to be used in identifying data packets associated with the
flow. A value of zero (0) indicates that the field SHALL NOT be
included in flow identification. A value of 32 indicates a host
address, i.e. all bits should be used. Values greater than 32 are
illegal. This field is only meaningful when the Source IP Address
field is non-zero and when the "Sa" bit is set.
This field MUST be initialized by the source NHC to a value of zero
(0). NHSs MAY increase the value based on their policy
information. NHSs MUST NOT decrease the value.
Dst Prefix
This field carries the number of bits of the Destination IP Address
field to be used in identifying data packets associated with the
flow. A value of 0 or 32 indicates a host address, i.e. all bits
should be used. Values greater than 32 are illegal. This field is
only meaningful when the Destination IP Address field is non-zero
and when the the "Da" bit is set.
This field MUST be initialized by the source NHC to a value of zero
(0). NHSs MAY increase the value based on their policy
information. NHSs MUST set the value to 32 to indicate a host
address policy. NHSs MUST NOT decrease the value.
3.2 NHRP Flow Extension Format: IPv6
This format is used to describe any type of IPv6 data packet. It is
expected to be used when a more specific description is not defined
or supported.
Berger, Enns Expires: December 1998 [Page 9]
Internet Draft NHRP Flow Extension June 1998
Extension Length = 48
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Flow Type=0x02 |D| IPv6 Flags | Next Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PT Len | Prio./Traffic Class/Flow Label (PT) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Source IPv6 Address (16 bytes) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Destination IPv6 Address (16 bytes) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|DPT Len| Desired Prio./Traffic Class/Flow Label (DPT) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|IPv6 Src Prefix|IPv6 Dst Prefix| Unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6 Flags
The following flags are defined IPv6 flows:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| unused |Da |Sa |DPT|PT |NH |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
DPT
When set, this bit indicates that flows MUST be identified based
on the Prio./Traffic Class and Flow Label fields of the IP
Header. This bit MUST be zero when the PT bit is zero. This bit
MUST be cleared by the source NHC and MAY be set transit or
serving NHSs. When a Flow Extension is received with this bit
set, an NHS MUST NOT clear this bit.
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.
Berger, Enns Expires: December 1998 [Page 10]
Internet Draft NHRP Flow Extension June 1998
NH
When set, this bit indicates that flows MUST be identified using
the value in the Next Header field. This bit is only meaning
full if the Next Header field is non-zero. This bit MUST be
cleared by the source NHC and MAY be set transit or serving NHSs.
When a Flow Extension is received with this bit set, an NHS MUST
NOT clear this bit.
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.
PT Len
Indicates the number of bits in the Prio./Traffic Class (first)
portion of the PT field. This field is set by the source NHC and
is not modified by transit or serving NHSs. The source NHS MAY set
this value to zero (0). This field is only meaningful when the
"PT" bit is set.
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.
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.
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.
DPT Len
This field indicates the number of bits in the Prio./Traffic Class
(first) portion of the DPT field. This field is only meaningful
when the "DPT" bit is set. Legal values are between 0 and 28.
This field may contain a different value than the PT Len field.
Berger, Enns Expires: December 1998 [Page 11]
Internet Draft NHRP Flow Extension June 1998
This field MUST be initialized by the source NHC to a value of zero
(0). Transit and serving NHSs MAY set this field only when the
received Flow Extension has the DPT bit cleared and the PT bit set.
If an NHS sets this field, it MUST also set the DPT bit.
Desired Prio./Traffic Class and Flow Label (DPT)
This field carries the Prio./Traffic Class and Flow Label fields
associated with the flow. The Prio./Traffic Class portion of the
DPT field indicates the bits that must be set in a data packet's
Prio./Traffic Class field in order to be associated with the flow.
The Flow Label portion of the DPT field contains the value that
must be in a data packet's Flow Label field in order to be
associated with the flow.
The division of of the Prio./Traffic Class field is indicated by
the DPT Len field. The Prio./Traffic Class field is contained in
the first (leftmost) DPT Len bits of the DPT field. The Flow Label
portion is in the last (rightmost) 28 minus DPT Len bits of the DPT
field. This field is only meaningful when the "DPT" bit is set.
This field MUST be initialized by the source NHC to a value of zero
(0). NHSs add their Prio./Traffic Class related policy information
by setting cleared bits in the Prio./Traffic Class portion of the
DPT field. NHSs MUST NOT clear bits in the Prio./Traffic Class
field. NHSs MAY set the Flow Label portion of the field when the
received Flow Extension has the DPT bit cleared and the PT bit set.
If an NHS sets the Flow Label portion of the field, it MUST also
set the DPT bit.
IPv6 Src Prefix
This field carries the number of bits of the Source IPv6 Address
field to be used in identifying data packets associated with the
flow. A value of zero (0) indicates that the field SHALL NOT be
included in flow identification. A value of 128 indicates a host
address, i.e. all bits should be used. Values greater than 128 are
illegal. This field is only meaningful when the Source IPv6
Address field is non-zero and when the "Sa" bit is set.
This field MUST be initialized by the source NHC to a value of zero
(0). NHSs MAY increase the value based on their policy
information. NHSs MUST NOT decrease the value.
IPv6 Dst Prefix
This field carries the number of bits of the Destination IPv6
Address field to be used in identifying data packets associated
with the flow. A value of 0 or 128 indicates a host address, i.e.
all bits should be used. Values greater than 128 are illegal.
This field is only meaningful when the Destination IPv6 Address
Berger, Enns Expires: December 1998 [Page 12]
Internet Draft NHRP Flow Extension June 1998
field is non-zero and when the the "Da" bit is set.
This field MUST be initialized by the source NHC to a value of zero
(0). NHSs MAY increase the value based on their policy
information. NHSs MUST set the value to 128 to indicate a host
address policy. NHSs MUST NOT decrease the value.
3.3 NHRP Flow Extension Format: IPv4-TCP/UDP
This format is used to describe IPv4 data packets carrying a protocol
that supports TCP/UDP-like ports. Specifically protocols that carry
a 16-bit source port field at the start of the transport header and
16-bit destination port field starting at bit 16 of the transport
header.
Fields and flags not listed have the same meaning as defined in
previous sections.
Extension Length = 28
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Flow Type=0x03 |D| Flags |Type of Service| Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ToS Mask | Src Prefix | Dst Prefix | Unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Src Range Start | Src Range End |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Dst Range Start | Dst Range End |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Flags
0 1 2 3 4 5 6
+--+--+--+--+--+--+--+
|0 |Dr|Sr|Da|Sa|P |T |
+--+--+--+--+--+--+--+
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
Berger, Enns Expires: December 1998 [Page 13]
Internet Draft NHRP Flow Extension June 1998
be modified by transit or serving NHSs.
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.
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.
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.
Src Range Start
This field carries the lower bound on Source Port field values that
will be considered to be associated with the flow. A zero (0)
value indicates that the Source Port field of the transport header
is not included in flow identification. This field is only
meaningful when the Source Port field is non-zero. When the "Sr"
bit is cleared (0), an NHS setting this field MUST set the Src
Range Start and Src Range End fields to the same value. This field
MUST NOT be set to a value greater than the Source Port field.
This field MUST be initialized by the source NHC to a value of zero
(0). NHSs MAY increase the value based on their policy
information. NHSs MUST NOT decrease the value.
Src Range End
This field carries the upper bound on Source Port field values that
will be considered to be associated with the flow. This field is
only meaningful when the Source Port and Src Range Start fields are
non-zero. When the "Sr" bit is cleared (0), an NHS setting this
field MUST set the Src Range Start and Src Range End fields to the
same value. This field MUST NOT be set to a value less than the
Source Port field.
This field MUST be initialized by the source NHC to a value of all
ones (0xffff). NHSs MAY decrease the value based on their policy
information. NHSs MUST NOT increase the value.
Berger, Enns Expires: December 1998 [Page 14]
Internet Draft NHRP Flow Extension June 1998
Dst Range Start
This field carries the lower bound on Destination Port field values
that will be considered to be associated with the flow. A zero (0)
value indicates that the Destination Port field of the transport
header is not included in flow identification. This field is only
meaningful when the Destination Port field is non-zero. When the
"Dr" bit is cleared (0), an NHS setting this field MUST set the Dst
Range Start and Dst Range End fields to the same value. This field
MUST NOT be set to a value greater than the Destination Port field.
This field MUST be initialized by the source NHC to a value of zero
(0). NHSs MAY increase the value based on their policy
information. NHSs MUST NOT decrease the value.
Dst Range End
This field carries the upper bound on Destination Port field values
that will be considered to be associated with the flow. This field
is only meaningful when the Destination Port and Dst Range Start
fields are non-zero. When the "Dr" bit is cleared (0), an NHS
setting this field MUST set the Dst Range Start and Dst Range End
fields to the same value. This field MUST NOT be set to a value
less than the Destination Port field.
This field MUST be initialized by the source NHC to a value of all
ones (0xffff). NHSs MAY decrease the value based on their policy
information. NHSs MUST NOT increase the value.
3.4 NHRP Flow Extension Format: IPv6-TCP/UDP
This format is used to describe IPv6 data packets carrying a protocol
that supports TCP/UDP-like ports.
Fields and flags not listed have the same meaning as defined in
previous sections.
Berger, Enns Expires: December 1998 [Page 15]
Internet Draft NHRP Flow Extension June 1998
Extension Length = 60
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Flow Type=0x04 |D| IPv6 Flags | Next Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PT Len | Prio./Traffic Class/Flow Label (PT) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Source IPv6 Address (16 bytes) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Destination IPv6 Address (16 bytes) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|DPT Len| Desired Prio./Traffic Class/Flow Label (DPT) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|IPv6 Src Prefix|IPv6 Dst Prefix| Unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Src Range Start | Src Range End |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Dst Range Start | Dst Range End |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6 Flags
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| unused |Dr |Sr |Da |Sa |DPT|PT |NH |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
3.5 NHRP Flow Extension Format: IPv4-IPSEC
This format is used to describe IPv4 data packets carrying an IPSEC
transport protocol. There are currently two such protocols defined:
Authentication Header (AH), for authentication[RFC1826]; and
Encapsulating Security Payload (ESP), for integrity and
confidentiality[RFC1827]. Flows are identified for both protocols
using the protocol's IPSEC Security Parameter Index, or SPI, field.
Fields and flags not listed have the same meaning as defined in
previous sections.
Berger, Enns Expires: December 1998 [Page 16]
Internet Draft NHRP Flow Extension June 1998
Extension Length = 20
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Flow Type=0x05 |D| Flags |Type of Service| Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ToS Mask | Src Prefix | Dst Prefix | Unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Parameter Index (SPI) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Flags
0 1 2 3 4 5 6
+--+--+--+--+--+--+--+
| unused |Da|Sa|P |T |
+--+--+--+--+--+--+--+
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.
3.6 NHRP Flow Extension Format: IPv6-IPSEC
This format is used to describe IPv6 data packets carrying an IPSEC
transport protocol.
Fields and flags not listed have the same meaning as defined in
previous sections.
Berger, Enns Expires: December 1998 [Page 17]
Internet Draft NHRP Flow Extension June 1998
Extension Length = 56
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Flow Type=0x06 |D| IPv6 Flags | Next Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PT Len | Prio./Traffic Class/Flow Label (PT) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Source IPv6 Address (16 bytes) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Destination IPv6 Address (16 bytes) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|DPT Len| Desired Prio./Traffic Class/Flow Label (DPT) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|IPv6 Src Prefix|IPv6 Dst Prefix| Unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Parameter Index (SPI) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6 Flags
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| unused |Da |Sa |DPT|PT |NH |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
4. Message Processing
If a requester wishes to obtain flow information, it SHALL include
the Flow Extension in the NHRP Resolution Request. The requester
SHOULD include the most specific flow type that it supports. The
requester MAY specify a particular flow or subset of flows by setting
some or all of the fields in the flow detail to non-zero values.
When processing NHRP Resolution Request messages, NHSs that support
the Flow Extension MUST verify that the Request is following the
routed path. The NHS checks if the sender of the message is an NHC.
When the sender is an NHC, the NHS verifies that the NHC is one of
its served NHCs. If the sending NHC is not a served NHC, then the
NHS MUST generate an NHRP Error Indication with an Error Code of
Protocol Error.
Berger, Enns Expires: December 1998 [Page 18]
Internet Draft NHRP Flow Extension June 1998
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.
If either the request or policy information portions of the Flow
Extension is unacceptable, the NHS MUST issue a NAK Resolution Reply
of type Administratively Prohibited. The NHS MUST update the Flow
Extension to reflect the matching policy and SHOULD set the "D" bit.
When updating the policy information portion of the Flow Extension,
an NHS SHOULD describe the matching (failed or acceptable) policy in
the broadest possible terms rather than simply replaying the
requested flow. An NHS responder MAY choose to reply with limited
information for security reasons.
On receipt of a Resolution Reply message that contains a Flow
Extension, a requester that supports the Flow Extension SHOULD follow
the policy information relayed in the extension. If the requester
does not follow the policy, the requester MUST NOT forward data
packets based on the information contained in the reply message. A
requester may chose not to follow a relayed policy because the policy
is unacceptable or due to resource limitations.
In the expected normal case, the requester will follow the policy
information relayed in the extension. When the message is a NAK
Resolution Reply of type Administratively Prohibited the requester
SHOULD check the "D" bit in the Flow Extension. If the bit is set,
data packets matching the flow information SHOULD be silently
discarded. If the requester forwards matching data packets, such
packets MUST be forwarded via the routed path.
When the received Resolution Reply message does not contain a NAK,
the requester SHOULD forward data packets that match the flow
specified in the Flow Extension using the information contained in
the Resolution Reply. The requester MUST NOT forward data packets
that do not match specified flow using the information contained in
the Resolution Reply.
Berger, Enns Expires: December 1998 [Page 19]
Internet Draft NHRP Flow Extension June 1998
5. IANA Considerations
IANA is requested to manage and assign the range of Flow Type field
values from 0x07 to 0x7F. New assignments should be made with the
guidance of the relevant IESG Area Director or their designee.
Additionally, all requests for assignments should be honored when the
usage of the requested value is documented in a publicly available
and unrestricted (including time) form. Preferably the document will
be available via a standards organization's web site.
6. References
[RFC1826] Atkinson, R., "IP Authentication Header", RFC 1826, NRL,
August 1995.
[RFC1827] Atkinson, R., "IP Encapsulating Security Payload", RFC
1827, NRL, August 1995.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels," RFC 2119.
[RFC2332] Luciani, J., Katz, D., Piscitello, D., Cole, B., Doraswamy, N.,
"NBMA Next Hop Resolution Protocol (NHRP)," RFC 2332.
7. Acknowledgments
The authors thank Rajesh Varadarajan, Ravi Shekhar and Jim Luciani
for their valuable comments and corrections.
8. Authors' Addresses
Lou Berger Rob Enns
FORE Systems Berkeley Networks
1595 Spring Hill Road 1805 McCandless Drive
Vienna, VA 22182 USA Milpitas, CA 95035
Phone: +1 703-245-4544 Phone: 408-719-3059
Email: lberger@fore.com Email: rpe@berkeleynet.com
Berger, Enns Expires: December 1998 [Page 20]
| PAFTECH AB 2003-2026 | 2026-04-23 01:34:22 |