📄 rfc1688.txt
字号:
3.5. Away From Home
When a router is present, and the correspondent does not implement
mobility functions, the router must be capable of redirecting the
correspondent to communicate directly with the Mobile Node.
When no router is present, Mobile Nodes must be capable of
communicating directly with other nodes on the same link.
Mobility must not create an environment which is less secure than the
current Internet.
Changes in topology must not affect internode security mechanisms.
4. Security
4.1. Authentication
Mobility registration messages must be authenticated between the home
topological repository and Mobile Node.
When the correspondent implements mobility functions, redirection or
path optimization must be authenticated between the correspondent and
Mobile Node.
Simpson [Page 5]
RFC 1688 IPng Mobility August 1994
4.2. Anonymity
The capability to attach to a foreign administrative domain without
the awareness of the foreign administration is not prohibited.
However, any mobility mechanism must provide the ability to prevent
such attachment.
4.3. Location Privacy
The capability to attach to a foreign administrative domain without
the awareness of correspondents is not prohibited. However, any
mobility mechanism must provide the ability for the home
administration to trace the current path to the point of attachment.
4.4. Content Privacy
Security mechanisms which provide content privacy must not obscure or
have a dependency on the topological location of Mobile Nodes.
5. Bandwidth
Mobility must operate in the current link environment, and must not
be dependent on bandwidth improvements. The Mobile Node's directly
attached link is likely to be bandwidth limited.
In particular, radio frequency spectrum is already a scarce
commodity. Higher bandwidth links are likely to continue to be
scarce in the mobile environment.
Current applications of mobility using radio links include HF links
which are subject to serious fading and noise constraints, VHF and
UHF line of sight radio between ships or field sites, and UHF
Satellite Communications links.
The HF radio bandwidth is fixed at 1200 or 2400 bps by international
treaty, statute, and custom, and is not likely to change.
The European standard for cellular radio is 2400 bps GSM.
The most prevalent deployed analog cellular and land-line modulation
used by mobile nodes is 2400 bps.
Current digital cellular deployment is 19,200 bps CDPD shared among
many users. At early installations, under light loads, effective FTP
throughput has been observed as low as 200 bps.
Future digital cellular deployment is 9,600 and 14,400 bps CDMA,
which is shared between voice and data on a per user basis.
Simpson [Page 6]
RFC 1688 IPng Mobility August 1994
Effective FTP throughput has been measured as low as 7,200 bps.
Future Personal Communications Services (PCS) will also have
relatively little bandwidth. In industrialized nations, the
bandwidth available to each user is constrained by the density of
deployment, and is commensurate with planned digital cellular
deployment.
It appears likely that satellite-based PCS will be widely deployed
for basic telephony communications in many newly-industrialized and
lesser-developed countries. There is already significant PCS
interest in East and SouthEast Asia, India, and South America.
Van Jacobson header prediction is widely used, and essential to
making the use of such links viable.
5.1. Administrative Messages
The number of administrative mobility messages sent or received by
the Mobile Node must be limited to as few as possible. In order to
meet the frequency requirement of changing point of attachment once
per second, registration of changes must not require more than a
single request and reply.
The size of administrative mobility messages must be kept as short as
possible. In order to meet the frequency requirement of changing
point of attachment once per second, the registration messages must
not total more than 120 bytes for a complete transaction, including
link and internet headers.
5.2. Response Time
For most mobile links in current use, the typical TCP/IPv4 datagram
overhead of 40 bytes is too large to maintain an acceptable typing
response of 200 milliseconds round trip time.
Therefore, the criteria for IPng mobility is that the response time
not be perceptably worse than IPv4.
This allows no more than 6 bytes of additional overhead per datagram
to be added by IPng.
This was a primary concern in the design of mobility forwarding
headers. Larger headers were rejected outright, and negotiation
is provided for smaller headers than the default method.
Topological headers are removed by the Foreign Agent prior to
datagram transmission over the slower link to the Mobile Node,
which also aids header prediction, as described below.
Simpson [Page 7]
RFC 1688 IPng Mobility August 1994
5.3. Header Prediction
Header prediction can be useful in reducing bandwidth usage on
multiple related datagrams. It requires a point-to-point peer
relationship between nodes, so that a header history can be
maintained between the peers.
Header prediction is less effective in mobile environments, as the
header history is lost each time a Mobile Node changes its point of
attachment. The new Foreign Agent will not have the same history as
the previous Agent.
In order for header prediction to operate successfully, changing
topological information must be removed from datagram overhead prior
to transmission of the datagram on any final hop's directly attached
link. This applies to both the Mobile Node peering with a Foreign
Agent, and also the final link to a Correspondent. Otherwise, header
prediction cannot be relied upon to improve bandwidth utilization on
low-speed Mobile and Correspondent links.
Since the changing topological information cannot be removed in the
forwarding path of the datagram, header prediction will also be
affected at any other pair of routers in the datagram path. Each
time that a Mobile Node moves, the topological portion of the header
will change, and header history used at those routers will be
updated. Unless topological information is limited to as few headers
as possible, this may render header prediction ineffective as more
Mobile Nodes are deployed.
6. Processing
Mobility must operate in the current processor environment, and must
not be dependent on hardware improvements.
Common hardware implementations of Mobile Nodes include lower speed
processors, and highly integrated components. These are not readily
upgradable.
The most prevalent mobile platform is a low speed i86, i286 or i386.
The most common ASIC processor is a low speed i186.
6.1. Fixed Location
The processing limitations require that datagram header fields which
are frequently examined by Mobile Nodes, or used for datagram
forwarding to or from Mobile Nodes, are in a fixed location and do
not require lengths and offsets.
Simpson [Page 8]
RFC 1688 IPng Mobility August 1994
Varied number of fields was explicitly rejected in the design of
mobility registration and forwarding headers.
6.2. Simple Fields
The processing limitations require that datagram header fields which
are frequently examined by Mobile Nodes, or used for datagram
forwarding to or from Mobile Nodes, are simple and fixed size.
Varied length of fields was explicitly rejected in the design of
mobility forwarding headers.
6.3. Simple Tests
Because the most prevalent processors are "little-endian", while
network protocols are in practice "big-endian", the field processing
must primarily use simple equality tests, rather than variable shifts
and prefix matches.
6.4. Type, Length, Value
Fields which are not frequently examined, whether due to infrequent
transmission or content that is not relevant in every message, must
be of the Type, Length, Value format.
Acknowledgements
This compilation is primarily based on the work in progress of the
IETF Mobile IP Working Group.
Security Considerations
Security issues are discussed in section 4.
Author's Address
Questions about this memo can also be directed to:
William Allen Simpson
Daydreamer
Computer Systems Consulting Services
1384 Fontaine
Madison Heights, Michigan 48071
EMail: Bill.Simpson@um.cc.umich.edu or
bsimpson@MorningStar.com
Simpson [Page 9]
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -