📄 rfc3024.txt
字号:
Montenegro Standards Track [Page 6]
RFC 3024 Reverse Tunneling for Mobile IP, revised January 2001
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 |S|B|D|M|G|V|T|-| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Agent |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Care-of Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions ...
+-+-+-+-+-+-+-+-
The only change to the Registration Request packet is the additional
'T' bit:
T If the 'T' bit is set, the mobile node asks its home
agent to accept a reverse tunnel from the care-of
address. Mobile nodes using a foreign agent care-of
address ask the foreign agent to reverse-tunnel its
packets.
3.3. Encapsulating Delivery Style Extension
The Encapsulating Delivery Style Extension MAY be included by the
mobile node in registration requests to further specify reverse
tunneling behavior. It is expected to be used only by the foreign
agent. Accordingly, the foreign agent MUST consume this extension
(that is, it must not relay it to the home agent or include it in
replies to the mobile node). As per Section 3.6.1.3 of [1], the
mobile node MUST include the Encapsulating Delivery Style Extension
after the Mobile-Home Authentication Extension, and before the
Mobile-Foreign Authentication Extension, if present.
The Encapsulating Delivery Style Extension MUST NOT be included if
the 'T' bit is not set in the Registration Request.
If this extension is absent, Direct Delivery is assumed.
Encapsulation is done according to what was negotiated for the
forward tunnel (that is, IP in IP is assumed unless specified
otherwise). For more details on the delivery styles, please refer to
section 5.
Montenegro Standards Track [Page 7]
RFC 3024 Reverse Tunneling for Mobile IP, revised January 2001
Foreign agents SHOULD support the Encapsulating Delivery Style
Extension.
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
130
Length
0
3.4. New Registration Reply Codes
Foreign and home agent registration replies MUST convey if the
reverse tunnel request failed. These new reply codes are defined:
Service denied by the foreign agent:
74 requested reverse tunnel unavailable
75 reverse tunnel is mandatory and 'T' bit not set
76 mobile node too distant
79 delivery style not supported
NOTE: Code 79 has not yet been assigned by IANA.
and
Service denied by the home agent:
137 requested reverse tunnel unavailable
138 reverse tunnel is mandatory and 'T' bit not set
139 requested encapsulation unavailable
In response to a Registration Request with the 'T' bit set, mobile
nodes may receive (and MUST accept) code 70 (poorly formed request)
from foreign agents and code 134 (poorly formed request) from home
agents. However, foreign and home agents that support reverse
tunneling MUST use codes 74 and 137, respectively.
In addition to setting the 'T' bit, the mobile node also MAY request
the Encapsulating Delivery Style by including the corresponding
extension. If a foreign agent does not implement the Encapsulating
Montenegro Standards Track [Page 8]
RFC 3024 Reverse Tunneling for Mobile IP, revised January 2001
Delivery Style, it MUST respond to the mobile node with code 79
(delivery style not supported). This also applies if the foreign
agent does not support a requested delivery style that may be defined
in the future.
Absence of the 'T' bit in a Registration Request MAY elicit denials
with codes 75 and 138 at the foreign agent and the home agent,
respectively.
Forward and reverse tunnels are symmetric, that is, both are able to
use the same tunneling options negotiated at registration. This
implies that the home agent MUST deny registrations if an unsupported
form of tunneling is requested (code 139). Notice that Mobile IP [1]
already defines the analogous failure code 72 for use by the foreign
agent.
4. Changes in Protocol Behavior
Unless otherwise specified, behavior specified by Mobile IP [1] is
assumed. In particular, if any two entities share a mobility
security association, they MUST use the appropriate Authentication
Extension (Mobile-Foreign, Foreign-Home or Mobile-Home Authentication
Extension) when exchanging registration protocol datagrams. An
admissible authentication extension (for example the Mobile-Home
Authentication Extension) MUST always be present to authenticate
registration messages between a mobile node and its home agent.
Reverse tunneling imposes additional protocol processing requirements
on mobile entities. Differences in protocol behavior with respect to
Mobile IP [1] are specified in the subsequent sections.
4.1. Mobile Node Considerations
This section describes how the mobile node handles registrations that
request a reverse tunnel.
4.1.1. Sending Registration Requests to the Foreign Agent
In addition to the considerations in [1], a mobile node sets the 'T'
bit in its Registration Request to petition a reverse tunnel.
The mobile node MUST set the TTL field of the IP header to 255. This
is meant to limit the reverse tunnel hijacking attack (Section 6).
The mobile node MAY optionally include an Encapsulating Delivery
Style Extension.
Montenegro Standards Track [Page 9]
RFC 3024 Reverse Tunneling for Mobile IP, revised January 2001
4.1.2. Receiving Registration Replies from the Foreign Agent
Possible valid responses are:
- A registration denial issued by either the home agent or the
foreign agent:
a. The mobile node follows the error checking guidelines in
[1], and depending on the reply code, MAY try modifying the
registration request (for example, by eliminating the
request for alternate forms of encapsulation or delivery
style), and issuing a new registration.
b. Depending on the reply code, the mobile node MAY try zeroing
the 'T' bit, eliminating the Encapsulating Delivery Style
Extension (if one was present), and issuing a new
registration. Notice that after doing so the registration
may succeed, but due to the lack of a reverse tunnel data
transfer may not be possible.
- The home agent returns a Registration Reply indicating that the
service will be provided.
In this last case, the mobile node has succeeded in establishing a
reverse tunnel between its care-of address and its home agent. If
the mobile node is operating with a co-located care-of address, it
MAY encapsulate outgoing data such that the destination address of
the outer header is the home agent. This ability to selectively
reverse-tunnel packets is discussed further in section 5.4.
If the care-of address belongs to a separate foreign agent, the
mobile node MUST employ whatever delivery style was requested (Direct
or Encapsulating) and proceed as specified in section 5.
A successful registration reply is an assurance that both the foreign
agent and the home agent support whatever alternate forms of
encapsulation (other than IP in IP) were requested. Accordingly, the
mobile node MAY use them at its discretion.
4.2. Foreign Agent Considerations
This section describes how the foreign agent handles registrations
that request a reverse tunnel.
Montenegro Standards Track [Page 10]
RFC 3024 Reverse Tunneling for Mobile IP, revised January 2001
4.2.1. Receiving Registration Requests from the Mobile Node
A foreign agent that receives a Registration Request with the 'T' bit
set processes the packet as specified in the Mobile IP specification
[1], and determines whether it can accommodate the forward tunnel
request. If it cannot, it returns an appropriate code. In
particular, if the foreign agent is unable to support the requested
form of encapsulation it MUST return code 72. If it cannot support
the requested form of delivery style it MUST return code 79 (delivery
style not supported).
The foreign agent MAY reject Registration Requests without the 'T'
bit set by denying them with code 75 (reverse tunnel is mandatory and
'T' bit not set).
The foreign agent MUST verify that the TTL field of the IP header is
set to 255. Otherwise, it MUST reject the registration with code 76
(mobile node too distant). The foreign agent MUST limit the rate at
which it sends these registration replies to a maximum of one per
second.
As a last check, the foreign agent verifies that it can support a
reverse tunnel with the same configuration. If it cannot, it MUST
return a Registration Reply denying the request with code 74
(requested reverse tunnel unavailable).
4.2.2. Relaying Registration Requests to the Home Agent
Otherwise, the foreign agent MUST relay the Registration Request to
the home agent.
Upon receipt of a Registration Reply that satisfies validity checks,
the foreign agent MUST update its visitor list, including indication
that this mobile node has been granted a reverse tunnel and the
delivery style expected (section 5).
While this visitor list entry is in effect, the foreign agent MUST
process incoming traffic according to the delivery style, encapsulate
it and tunnel it from the care-of address to the home agent's
address.
4.3. Home Agent Considerations
This section describes how the home agent handles registrations that
request a reverse tunnel.
Montenegro Standards Track [Page 11]
RFC 3024 Reverse Tunneling for Mobile IP, revised January 2001
4.3.1. Receiving Registration Requests from the Foreign Agent
A home agent that receives a Registration Request with the 'T' bit
set processes the packet as specified in the Mobile IP specification
[1] and determines whether it can accommodate the forward tunnel
request. If it cannot, it returns an appropriate code. In
particular, if the home agent is unable to support the requested form
of encapsulation it MUST return code 139 (requested encapsulation
unavailable).
The home agent MAY reject registration requests without the 'T' bit
set by denying them with code 138 (reverse tunnel is mandatory and '
T' bit not set).
As a last check, the home agent determines whether it can support a
reverse tunnel with the same configuration as the forward tunnel. If
it cannot, it MUST send back a registration denial with code 137
(requested reverse tunnel unavailable).
Upon receipt of a Registration Reply that satisfies validity checks,
the home agent MUST update its mobility bindings list to indicate
that this mobile node has been granted a reverse tunnel and the type
of encapsulation expected.
4.3.2. Sending Registration Replies to the Foreign Agent
In response to a valid Registration Request, a home agent MUST issue
a Registration Reply to the mobile node.
After a successful registration, the home agent may receive
encapsulated packets addressed to itself. Decapsulating such packets
and blindly injecting them into the network is a potential security
weakness (section 6.1). Accordingly, the home agent MUST implement,
and, by default, SHOULD enable the following check for encapsulated
packets addressed to itself:
The home agent searches for a mobility binding whose care-of
address is the source of the outer header, and whose mobile node
address is the source of the inner header.
If no such binding is found, or if the packet uses an encapsulation
mechanism that was not negotiated at registration the home agent MUST
silently discard the packet and SHOULD log the event as a security
exception.
Home agents that terminate tunnels unrelated to Mobile IP (for
example, multicast tunnels) MAY turn off the above check, but this
practice is discouraged for the aforementioned reasons.
Montenegro Standards Track [Page 12]
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -