One document matched: draft-nomad-mobileip-filters-02.txt
Differences from draft-nomad-mobileip-filters-01.txt
Mobile IP Working Group N. A. Fikouras
INTERNET-DRAFT A. J. Koensgen
Expires: January 2003 C. Goerg
ComNets, IKOM
University of Bremen
W. Zirwas
M. Lott
Siemens AG
July 2002
Filters for Mobile IP Bindings (NOMAD)
draft-nomad-mobileip-filters-02.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This document is an individual submission to the IETF. Comments
should be directed to the authors.
Abstract
In Mobile IP, a mobile node that maintains simultaneous bindings will
receive at each registered care-of address a duplicate copy of every
datagram from every active flow. However, a mobile node with multiple
points of attachment may wish to receive different flows at each one.
The purpose of this document is to enable mobile nodes to associate a
list of filters with a binding during its establishment
(registration, binding update). In this manner, a mobile node may
select for each flow the most appropriate point of attachment. In
order not to violate layer independence, the filtering of individual
flows or groups of them is managed through flow description
components made available by existing approaches to QoS support.
Page 2
Table of Contents
1 Introduction ............................................. 3
2 Terminology .............................................. 4
3 NOMAD Extensions Protocol Overview ....................... 5
3.1 Protocol Description ..................................... 5
3.2 Model of Operation ....................................... 6
4 Associating Filters with Bindings ........................ 9
4.1 Mobile Node Considerations ............................... 9
4.2 Binding Agent Considerations ............................. 9
5 NOMAD Extensions to RFC2002 Registration Messages ........ 10
5.1 Behavior Aggregate Filter Extension (BAF) ................ 11
5.2 Protocol Extension ....................................... 11
5.3 Source Address Extension ................................. 12
5.4 Source Network Extension ................................. 12
5.5 Source Port Extension .................................... 12
5.6 Source Port Range Extension .............................. 13
5.7 Free From Extension ...................................... 13
5.8 Routing Optimization Extension for Simultaneous Bindings . 14
5.9 Control Extension ........................................ 14
6 Mobile IP version 6 Considerations ....................... 15
7 Intellectual Property Considerations ..................... 16
References ................................................... 17
Authors' Addresses ........................................... 18
Page 3
1 Introduction
This document extends the Mobile IP [1] protocol by providing the
means for mobile nodes with simultaneous bindings to notify Binding
Agents (Mobile IP entities that can maintain simultaneous bindings)
of an association between filters and specific bindings. As such,
traffic intercepted by, or originating from a Binding Agent will be
filtered and individual flows will be redirected to the care-of
address indicated by the respective binding. This enables mobile
nodes to distribute active flows amongst their available points of
attachment.
Mobility Agents are unable to distinguish between individual flows
and therefore redirect all intercepted traffic for a mobile node to
the care-of address indicated by its binding. Consequently, as the
binding is updated with every hand-off, the total of a mobile node's
active flows are redirected to the most recently registered care-of
address. Furthermore, if a mobile node requests for simultaneous
bindings, it will receive at each registered care-of address a
duplicate copy of every active flow. However, a mobile node that
maintains multiple access interfaces and hence multiple points of
attachment may wish to associate certain flows with specific access
interfaces. As these access interfaces vary their care-of address a
mobile node should be able to perform a Mobile IP (IP-layer) hand-off
for only a subset of its active flows.
A functionality similar to the one described earlier can be provided
through the routing optimization extension [3] whereby the mobile
node is enabled to communicate directly with a correspondent node
(CN), bypassing all mobility agents. In that case, it is possible for
the mobile node to register a different care-of address with each CN,
therefore associating all of a CN's communications with one of its
points of attachment. However, with this approach it is not possible
to distribute the communications of a given CN between multiple
points of attachment. The reason for this is because, in routing
optimization, CNs may not maintain multiple bindings for a mobile
node. Moreover, CNs, just like mobility agents, are equally unable to
distinguish between individual flows in spite of being their origin.
Filters for bindings require that a mobile node includes in its
registration requests or binding updates a list of filters. Flows
that match the conditions listed in the filters are associated with
the registered care-of address. In this manner the Binding Agent (CN,
Home or Hierarchical Agents) becomes aware of the relationship
between certain flows and specific bindings. However, the existence
of those filters does not affect in any way the mobile node's choice
on the point of attachment to be utilized for the return path.
In order to provide simultaneous bindings to CNs with routing
optimization support, the 'S' bit is introduced in the binding update
message. In order not to violate layer independence, the filtering of
flows occurs through components made available by protocols for QoS
support. The consideration presented in this document are
collectively referred to as the NOMAD Extension.
Page 4
In addition to the description of the filter management for Mobile IP
version 4 [1] protocol, considerations to apply the filters to
Mobile IP version 6 [10] are given in this document.
2 Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC-2119 [2].
This document uses the following terms:
Domain A collection of networks sharing a common network
administration.
Home domain
As defined in [5].
Visited domain
The domain where the mobile node has one or more
points of attachment.
Gateway Foreign Agent (GFA)
As defined in [5].
Regional Foreign Agent (RFA)
As defined in [5].
Home Agent (HA)
As defined in [1].
Home Network
As defined in [1].
Correspondent Node (CN)
As defined in [1].
Mobile Node (MN)
As defined in [1].
Mobility Binding
As defined in [1].
Binding Agent (BA)
Any Mobile IP entity (HA, GFA, RFA, CN) that can maintain
Simultaneous mobility bindings.
Binding Request
Mobile IP signaling (registration request, binding update)
with the purpose of establishing or updating a mobility
binding.
Page 5
Binding Reply
Mobile IP signaling (registration reply, binding
acknowledgment) for acknowledging the successful updating
or establishment of a mobility binding.
3 NOMAD Extensions Protocol Overview
This section provides an overview of how filters for Mobile IP
bindings can be realized.
3.1 Protocol Description
Every time that a mobile node acquires a care-of address through one
of its points of attachment it is required to issue a registration
request or binding update (collectively termed as binding requests)
to the respective Binding Agent. A Binding Agent can be any Mobile IP
entity that can maintain bindings, like a HA, GFA, RFA even a CN when
routing optimization is supported. In any case, the mobile node is
required to include in its binding request a list of filters that
indicate which flows are associated with the registered care-of
address. The rules by which a mobile node decides on the set of
filters is considered beyond the scope of this document.
A Binding Agent that receives a binding request that includes a list
of filters is required to establish a tunnel as per [1]. However,
this tunnel is only applicable for flows that match the criteria
present in any of the filters associated with the binding. If a
Binding Agent receives simultaneous registrations (bindings) it is
required to establish different tunnels, each associated with
different filters. It is noted that, filters of simultaneous bindings
need not be mutually exclusive. In the case of overlapping filters,
the Binding Agent is required to duplicate flows that match the
overlapping criteria and direct them to the corresponding care-of
addresses.
A mobile node may issue filters that correspond to flows that do not
yet exist. In that case, when such a flow is initiated it will be
handled by the Binding Agents as indicated by the filter.
A binding without any filters is considered as the default binding.
The default binding is used for all flows for which no filters have
been defined. In the absence of filter-less bindings, the default
binding is considered the one with the longest outstanding lifetime.
It is possible for a mobile node to maintain multiple filter-less as
well as other bindings at the same time. In that case, all flows for
which a matching filter exists will be directed to the corresponding
care-of address while the rest will be duplicated and directed to the
care-of addresses indicated by all the filter-less bindings.
Page 6
If a specific filter is not accepted by a Binding Agent then it is
required to include this filter in its registration reply/binding
acknowledgement (termed collectively as binding reply). Otherwise no
other indication is required. When returning traffic the mobile node
is not bound in any way by the extensions presented as to which point
of attachment should be used.
A filter remains valid for the lifetime of the corresponding binding.
When the lifetime of a binding expires then all associated filters
are cancelled. In order for a mobile node to modify a filter
(add/remove predicates) it is required to issue a new Binding Request
for the care-of address associated with the filter, including a new
filter entry or the part of the filter that needs to be changed. The
filter extensions presented later in this document include special
fields for filter management.
In order to protect layer independence the structure of filters that
may be added to a Binding Request is based on existing filter
specification for QoS support.
3.2 Model of Operation
The general model of operation is illustrated in figure 1. It shows a
mobile node that maintains multiple access interfaces. Each interface
provides a point of attachment through a visited domain. The
extensions presented do not provide any restriction as to how many
points of attachment a mobile node may maintain within a domain. For
example, the mobile node in figure 1 has two separate points of
attachment in the Mobile IP hierarchy of visited domain A. In
addition, the mobile node maintains two more points of attachment
through visited domains B and C. The extensions presented operate
independently of whether the point of attachment provides a normal or
collocated care-of address.
In figure 1, the mobile node maintains four communications with
correspondent nodes CN1 and CN2. Flows associated with CN1 are
denoted with 'a' and 'b' while the respective flows for CN2 are
denoted with 'c' and 'd'.
When routing optimization is used in conjunction with hierarchical
Mobile IP the Binding Agent can be the HA or any of hierarchy
Mobility Agents such as the GFA and RFA as well as the CN itself. The
level at which filtering may occur is determined by the mobile node
depending on the micro/macro mobility character of every hand-off as
well as internal rules. In general, the Binding Agent that issues the
registration reply or binding acknowledgement (collectively termed as
binding reply) is also required to deploy the filters.
For communications with CN1, routing optimization has been assumed
but the GFA has been selected as the filtering Binding Agent.
Communications with CN2 do not assume routing optimization and
therefore all flows are first directed to the mobile node's HA.
Page 7
In the example presented in figure 1, the mobile node has issued a
separate binding request for each care-of address acquired by its
points of attachment. Every binding request contained a set of
filters that forces the respective Binding Agents to redirect
different flows to different care-of addresses. As such, even though
the GFA intercepts the total of CN1's traffic destined for the mobile
node, separate flows are directed to different points of attachment.
The same is observed at the HA, which intercepts incoming traffic
from the CN2 and after filtering it redirects them to different
locations.
To return traffic a mobile node may choose any of the available
points of attachment.
Page 8
+---------------------+ +-------+
| Visited Domain A | | CN1 |
| | +-------+
| | |a
a a a a a a +------+ a a a | |b
-----------| FA |----- | +------|a-----+
a| | +------+ |a | |b |
| | +-------+ | |a |
a| | | GFA |------------ b |
| | +-------+ babababababa |
a| | +------+ |b | | |
| --------| FA |----- | | |
a| |b b b b +------+b b b b | | |
| | | | | |
a| |b +---------------------+ | Public | +-----------+
+------+ | Network | | |
| MN | +---------------------+ | | | Home |
+------+ | Visited Domain B | | | | Network |
|d |c | | | | | |
| | c c c +------+ c c c c c c c c c c c c c c c c c c c c c |
|d --------| FA |----------------------------------------- |
| | +------+ | | d d d d d d d d d d |c |
|d | | | d ------------------ | |
| | | | | | | |d |c |
|d | | | d| dcdcdcdcdcdc +------+ |
| +---------------------+ | | c ------------| HA | |
|d | d| d| | | +------+ |
| +---------------------+ +-- |--c|-----+ | |
|d | | d| d| | |
| d d d d d d d d d d d d d d d d d d | c| +-----------+
-------------------------------------- d|
| | c|
| Visited Domain C | +-------+
| | | CN2 |
+---------------------+ +-------+
Figure 1: A mobile node with multiple points of attachment in
different visited domains. Incoming flows are redirected by
the respective Binding Agents to a different care-of
address.
Page 9
4 Associating Filters with Bindings
This section gives a detailed description of the steps taken by a
mobile node that wishes to associate filters with its bindings.
Furthermore, it is presented how a Binding Agent reacts to the
receipt of a binding request containing a list of filters.
4.1 Mobile Node Considerations
A mobile node that acquires a care-of address within a domain (home
or visited) may issue a binding request containing a list of filters.
All included filters will be associated with the registered care-of
address at the Binding Agent that issues the Binding Reply. A mobile
node that can maintain multiple points of attachment may request for
simultaneous bindings by setting the 'S' bit on in its Bindings
Requests. However, each of the Binding Requests must contain its own
list of filters. Consequently, flows that match any of the filters
will be received at the corresponding point of attachment. Similarly,
flows that match overlapping filters will be received at multiple
points of attachment. Finally, flows that do not match any of the
declared filters will be received at the point of attachment
indicated by the default binding.
Should a Binding Agent fail to apply one of the filters or individual
predicates of a filter then it is required to include them in the
Binding Reply. If routing optimization is supported then in the case
of a declined filter a Binding Acknowledgment with the failed filter
must be generated independently of whether the 'A' bit was set in
the Binding Update or not.
4.2 Binding Agent Considerations
Binding Agents that receive a Binding Request containing a list of
filters are required to make a record of the filters regardless of
whether they must issue a Binding Reply or not. If the Binding Agent
is required to issue a Binding Reply then it is also required to
apply the filters, else no further action is required. Should the
Binding Agent fail to apply any of the filters then the failed filter
(or predicate) must be included with the Binding Reply. If
authentication of the Binding Request fails then none of the filters
must be applied nor is it necessary to copy them in the Binding
Reply.
When a Binding Agent intercepts a packet for a mobile node for which
it maintains simultaneous bindings it is required to identify whether
the packet matches any of the filters. If so, the packet is
redirected to the care-of address indicated by the respective
binding. If no matching filter is found then the packet is redirected
to the care-of address indicated by the default binding.
Page 10
5 NOMAD Extensions to RFC2002 Registration Messages
In this section the new Mobile IP registration extensions required
for the support of filters for bindings are specified. Furthermore,
the lack of support for simultaneous bindings in CNs with routing
optimization requires the introduction of the 'S' bit to binding
update messages.
In Differentiated Services (DS) [7] the DS header field is defined
as a replacement for the IPv4 TOS [6] and IPv6 Traffic Class [8]
octets. Six bits of the DS field are used as a codepoint (DSCP) to
select the per-hop-behavior that a packet receives at each node. For
the purposes of NOMAD the DSCP along with other header fields is
used to construct filters that identify a specific flow or groups of
them.
In NOMAD, nine types of filter extensions are defined. To form a
valid rule, at least one of the extensions 1 to 7 must be included.
Any type of extensions 1 to 7 must not be included more than once.
A data packet matches the rule if it matches all of the extensions
1 to 7 which have been included. The extension 8 is optional. The
extension 9 is mandatory.
1. Behavior Aggregate Filter Extension (BAF)
Specifies to filter data packets dependent of the content of
the DSCP field.
2. Protocol Extension
Specifies one or more protocols to be filtered.
3. Source Address Extension
Specifies one or more source adresses to be filtered.
4. Source Network Extension
Specifies one or more source networks (i.e. a interval of
IP addresses) to be filtered.
5. Source Port Extension
Specifies one or more source ports to be filtered.
6. Source Port Range Extension
Specifies one or more ranges of source ports to be filtered.
7. Free-Form Extension
It allows for the definition of complex filters based on the
value of an area anywhere within a packet. The mobile node
is required to provide the packet offset, the qualifying
value as well as a mask.
Page 11
8. Routing Optimization Extension for Simultaneous Bindings
The Binding Update message is defined in [3]. With this message it
is possible for the mobile node to establish a binding with a CN
with routing optimization support. However, with every subsequent
Binding Update the CN is required to update the binding. In order
to enable simultaneous binding support the 'S' bit is introduced in
the Binding Update message. It occupies one of previously reserved
bits.
9. Control Extension
The Control Extension contains information about where to insert
a rule into the rule table and what rule to insert.
The filters presented do not in any way alter or affect the DSCP
value of intercepted packets. They only enable a Binding Agent to
determine for each packet the most appropriate binding when a mobile
node maintains a range of them.
5.1 Behavior Aggregate Filters (BAF) Extension
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | DSCP |RSV|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type To Be Defined
Length (N), where N is the number of DSCP entries
DSCP Differentiated Services Codepoint
5.2 Protocol Extension
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type To Be Defined
Length (N), where N is the number of Protocol fields
Protocol Identifies the next level protocol used in the data
portion of the internet datagram. The values for
various protocols are specified in [4].
Page 12
5.3 Source Address Extension
The Source Address Extension is defined for IPv4 and IPv6.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Source IP Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Source IP Address (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type To Be Defined
Length (4*N), where N is the number of source IP address fields
5.4 Source Network Extension
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Source IP Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Source IP Address (cont.) | Source IP Address Mask
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Source IP Address Mask (cont.)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type To Be Defined
Length (8*N), where N is the number of pairs of a
source IP address and a corresponding source
IP address mask entry
5.5 Source Port Extension
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Source Port Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type To Be Defined
Length (2*N), where N is the number of port entries
Page 13
5.6 Source Port Range Extension
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Source Port Number Min |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port Number Max |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type To Be Defined
Length (4*N), where N is the number of port range entries
Port Number Min
Defines the start point of a range of
port numbers
Port Number Max
Defines the end point of a range of source port numbers
5.7 Free-Form Extension
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |P|A| Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value |
....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask |
....
Type To Be Defined
Length Is variable, depends on the length of Value and Mask.
Offset Indicates a location within a packet to be filtered
in bytes.
The area indicated by the offset and for a length equivalent to that
of Mask is compared against Mask with the bitwise operator AND. The
result of this operation is compared against Value. A match would
indicate that the packet qualifies the filter.
Value and Mask fields MUST have exactly the same size. However, this
size may vary with every free-form filter. For the sizes of Value
and Mask the following condition holds:
Value = Mask = (Length - 2) / 2
Page 14
5.8 Routing Optimization Extension for Simultaneous Bindings
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |A|I|M|G|S| Rsv | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobile Node Home Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Care-of Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Identification +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions ...
+-+-+-+-+-+-+-+-
S Simultaneous bindings. If the 'S' bit is set on, the mobile
node is requesting that the correspondent node retains its
prior mobility bindings.
All other fields are defined in [3].
5.9 Control Extension
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | ACT | TG |IDX|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ACT Action to be undertaken for this filter
TG Target of the filter
IDX Filter index number
Admissible values for the ACT field are as follows:
Value Filter Management
0 Insert at the beginning of existing
filters for the registered address
1 append at the end of existing filters
for the registered address
2 Delete from an exiting filter
3 Replace entry in an existing filter
4 Flush all filter entries for address
Admissible values for the TG field are as follows:
Value Filter Target
0 Drop incoming packets without notification
1 Reject incoming packets with notification
2 Accept incoming packets
3 Accept incoming packets but avoid route
optimization
4 Masquerade
Page 15
6 Mobile IP Version 6 Considerations
Mobile IP version 6 (MIPv6) [10] supports multiple bindings.
Therefore, in MIPv6, it is possible to introduce
the filtering mechanism being described in this document. In contrast
to MIPv4, some changes in the terminology and in the format of the
filtering messages habe to be applied:
1. The filter extensions are added to MIPv6 binding update or
binding refresh messages as defined in [10].
2. In MIPv6, there are no dedicated FAs, GFAs, or RFAs. The roles of
these entities are taken over by the entities (HA, MN, routers)
which are located along the path which a packet traverses from the
HA to the MN. This is important when considering the model of
operation being described in section 3.2.
3. The format of the Source Address Extension described in section 5.3
is modified to cope with the 16-byte IPv6 addresses.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Source IP Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Source IP Address (cont.)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Source IP Address (cont.)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Source IP Address (cont.)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Source IP Address (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type To Be Defined
Length (16*N), where N is the number of source IP address fields
Page 16
4. The format of the Source Network Extension described in section 5.4
is modified to cope with the 16-byte IPv6 addresses and the IPv6
prefixes.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Source IP Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Source IP Address (cont.)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Source IP Address (cont.)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Source IP Address (cont.)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Source IP Address (cont.) | Prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type To Be Defined
Prefix Source IP Address Prefix
Length (17*N), where N is the number of pairs of a
source IP address and a corresponding source
IP address prefix
5. The Routing Optimization Extension described in section 5.8
is not needed because MIPv6 supports multiple bindings in
combination with route optimization.
7 Intellectual Property Considerations
This proposal is in full conformity with [9].
Siemens may have patent rights on technology described in this
document which employees of Siemens contribute for use in IETF
standard discussions. In relation to any IETF standard incorporating
any such technology, Siemens hereby agrees to license on fair,
reasonable and non-discriminatory terms, based on reciprocity, any
patent claims it owns covering such technology, to the extent such
technology is essential to comply with such standard.
Page 17
References
[1] C. Perkins. IP Mobility Support. RFC (Proposed Standard) 2002,
IETF, October 1996.
[2] S. Bradner. Key words for use in RFCs to Indicate Requirement
Levels. RFC 2119, IETF, March 1997.
[3] C. Perkins and D. Johnson. Route Optimization in Mobile IP.
(work in progress). draft-ietf-mobileip-optim-11.txt,
IETF, September 2001. (expired; not updated)
[4] J. Reynolds and J. Postel. Assigned Numbers. Request for
Comments 1700, STD 2, IETF, October 1994.
[5] E. Gustafsson, A. Jonsson and C. Perkins. Mobile IP Regional
Registration. (work in progress).
draft-ietf-mobileip-reg-tunnel-06.txt, IETF, March 2002.
[6] Postel, J. Internet Protocol. STD 5, RFC 791, IETF,
September 1981.
[7] K. Nichols, S. Blake, F. Baker, and D. Black. Definition of
the Differentiated Services Field (DS Field) in the IPv4 and
IPv6 Headers. RFC 2474, IETF, December 1998.
[8] S. Deering and R. Hinden, Internet Protocol, Version 6 (IPv6)
Specification. RFC 2460, IETF, December 1998.
[9] S. Brander. The Internet Standards Process -- Revision 3.
RFC 2026, IETF, October 1996
[10] D. Johnson, C. Perkins, J. Arkko. Mobility Support in IPv6
(work in progress). draft-ietf-mobileip-ipv6-18.txt, IETF,
June 2002.
Page 18
Authors' Addresses
Niko A. Fikouras
Department of Communication Networks (ComNets)
Center for Information and Communication Technology (ikom)
University of Bremen Phone: +49-421-218-3339
D-28219 Bremen, Germany Email: niko@comnets.uni-bremen.de
Andreas J. Koensgen
Department of Communication Networks (ComNets)
Center for Information and Communication Technology (ikom)
University of Bremen Phone: +49-421-218-3339
D-28219 Bremen, Germany Email: ajk@comnets.uni-bremen.de
Carmelita Goerg
Department of Communication Networks (ComNets)
Center for Information and Communication Technology (ikom)
University of Bremen Phone: +49-421-218-2277
28219, Bremen, Germany Email: cg@comnets.uni-bremen.de
Wolfgang Zirwas
Siemens AG
ICM N MR-ST 8
Werner-von-Siemens-Ring 20
D-85630 Grasbrunn Phone: +49-89-722-34369
Germany Email: wolfgang.zirwas@icn.siemens.de
Matthias Lott
Siemens AG
ICM N MR-ST 8
Werner-von-Siemens-Ring 20
D-85630 Grasbrunn Phone: +49-89-722-28097
Germany Email: matthias.lott@icn.siemens.de
Expires: January 2003
| PAFTECH AB 2003-2026 | 2026-04-22 23:20:07 |