NOTE: This charter is a snapshot of the 42nd IETF Meeting in Chicago, Illinois. It may now be out-of-date. Last Modified: 23-Jul-98
Erik Nordmark <firstname.lastname@example.org>
Jim Solomon <email@example.com>
Routing Area Director(s):
Rob Coltun <firstname.lastname@example.org>
Routing Area Advisor:
Rob Coltun <email@example.com>
To Subscribe: firstname.lastname@example.org
In Body: subscribe mobile-ip
Description of Working Group:
The Mobile IP Working Group is chartered to develop or adopt architectures and protocols to support mobility within the Internet. In the near-term, protocols for supporting transparent host ``roaming'' among different subnetworks and different media (e.g., LANs, dial-up links, and wireless communication channels) shall be developed and entered into the Internet standards track. The work is expected to consist mainly of new and/or revised protocols at the (inter)network layer, but may also include proposed modifications to higher-layer protocols (e.g., transport or directory). However, it shall be a requirement that the proposed solutions allow mobile hosts to interoperate with existing Internet systems.
In the longer term, the group may address, to the extent not covered by the mobile host solutions, other types of internet mobility, such as mobile subnets (e.g., a local network within a vehicle), or mobile clusters of subnets (e.g., a collection of hosts, routers, and subnets within a large vehicle, like a ship or spacecraft, or a collection of wireless, mobile routers that provide a dynamically changing internet topology).
Goals and Milestones:
Review and approve the charter, making any changes deemed necessary.
Post an Internet-Draft documenting the Mobile Hosts protocol.
Review the charter of the Mobile IP Working Group for additional work required to facilitate non-host mobility.
Submit the IPv4 Mobile Host Protocol to the IESG as a Proposed Standard.
Submit the IPv6 Mobile Host Protocol to the IESG as a Proposed Standard.
Review the WG charter and update as needed.
Request For Comments:
IP in IP Tunneling
Applicability Statement for IP Mobility Support
Minimal Encapsulation within IP
IP Encapsulation within IP
IP Mobility Support
The Definitions of Managed Objects for IP Mobility Support using SMIv2
Reverse Tunneling for Mobile IP
Sun's SKIP Firewall Traversal for Mobile IP
IP Routing for Wireless/Mobile Hosts (mobileip)
Monday, 8/24/98, 0930 - 1130
Co-chairs: Erik Nordmark <email@example.com>
Jim Solomon <firstname.lastname@example.org>
Minutes by: John Zao <email@example.com>
1. Stuart Jacobs <firstname.lastname@example.org>,
Mobile IP and Public Key Based Authentication,
This Internet Draft proposed a set of extensions to Mobile IPv4 control messages
including Mobility Agent Advertisements, Registration Requests and Replies for
providing non-repudiated proof of origin and integrity of the control messages using
public key digital signatures. Two types of extensions are used:
1. Signature Extensions - that affix digital signatures of specific algorithms to the
2. Certificate Extensions - that contain a chain of certificates needed for verifying the
signature in the associated Signature Extensions.
X.509 certificates and certificate revocation lists (CRLs) are used to distribute the public
keys necessary to verify the digital signatures.
1. What are the computation complexity of digital signatures and its impacts towards
the latency of Mobile IP registration?
Answer: Verification of a 512-bit RSA signature using a Pentium P-166 laptop takes
less than 1/20 of a second. We expect it will take even less time as the computing power
of laptops continue to increase.
1a. Can 512-bit RSA signatures provide sufficient protection?
Answer: They are probably strong enough for practical purposes since Mobile IP
registrations tend to have relatively short life spans. We may consider to use longer
keys (e.g. 1024-bit keys) when the need arises.
2. Why not use public key infrastructure (PKI) and the certificate dispatch mechanisms
it provides rather than sending certificates in every registration exchange? Besides,
how do the mobility agents (MNs, FAs and HAs) obtain CRLs?
Answer: Including certificates in the control messages may use up certain amount of
bandwidth, but it simplifies the process of getting necessary certificates. The exchanges of
CRLs will be addressed in future work.
2. Charles Perkins <email@example.com>,
Mobile IP and DIAMETER,
Lack of authentication/authorization/accounting (AAA) support is slowing down and
even preventing the wide-spread adoption of Mobile IP. This draft proposes security
mechanisms and Attribute/Value Pairs (AVPs) to provide AAA support for Mobile IP
using DIAMETER protocol.
DIAMETER <draft-calhoun-diameter-04.txt> is a functional extension of RADIUS for
conducting general server based AAA operations. This work uses the protocol to meet
the AAA demands associated with Mobile IP registration. Trusted AAA agents will be
added to Mobile IP home and foreign domains. Challenge-response exchanges will be
passed between the AAA agents and the mobility support entities. The outcome will be
authentication of MNs by the AAA agents in their home domains, authori-zation of MN-
FA connectivity by the AAA agents in the foreign domains, and accounting managed by
FAs under the supervision of AAA agents in the foreign domains. As an option, the AAA
agents in home and foreign domains may depend on inter-domain service brokers to
establish mutual trust relations.
1. How does AAAF, AAAH, and 3rd-party broker(s) discover one another and
establish mutual trust?
Answer: Agent discovery and trust management lie beyond the scope of this work and
are dealt with in the Roaming Operations (roamops) working group.
2. What's the status of DIAMETER?
Answer: The detail of DIAMETER protocol will be presented in the AAA BOF on
3. Could this proposal be "transliterated" into RADIUS?
Answer: RADIUS can probably be used to support simple Mobile IP AAA but not this
full set of exchanges. Remember, RADIUS does not support server-server authenti-cation
and was meant to be used for dial-up connections. It may be proper to keep it that way.
3. Shin We <firstname.lastname@example.org>,
Reverse Network Address Translators (RAT),
This Internet Draft proposed to use network address translations (NAT) to perform
location management and packet forwarding for Mobile IP. The purpose was to promote
Mobile IP deployment by leveraging on the increasing popular NAT technology.
The RAT system consists of the Mobile Nodes (MNs), a Registration Server (RS) and
one or more RAT devices. Both the RS and the RAT devices are present in MNs' home
domain. The RAT devices perform the address translations and play the role similar to
HAs. The RS functions as the trusted proxy of MNs to initiate and end NAT sessions
for the MNs.
As noted by the speaker, RAT is not capable of supporting seamless Mobile IP handoffs
and has end-to-end service limitations similar to NAT. Also, the RAT devices functioning
like HAs in home domains may become the bottleneck and the single point of failure.
No authentication mechanisms are in place at the present stage.
Is this an alternative to SOCKS? SOCKS can also be used to signal address translation
devices existing in network domains. References to SOCKS v5 were given to the speaker.
4. Gabriel Montenegro <email@example.com>,
Negotiated Address Reuse (NAR),
NAR is a SOCKS v5 based scheme for managing mappings of IP addresses and other
packet header fields between two networking realms in different address spaces. This
presentation described the use of NAR to reconcile NAT technology with layer 3
tunneling protocols such as Mobile IP and TEP.
NAR has two operation modes, (1) end-to-end address mapping and (2) address
translation. Both can be used for Mobile IP packet forwarding. The header fields
used for packet demultiplexing are (1) inner header destination address, (2) outer
header source address and (3) outer header destination IP address.
Can the NAR protocol work with multiple/nested address spaces?
5. Dave Johnson <firstname.lastname@example.org>
Mobility Support in IPv6,
The presentation constituted the last call for changes to the Internet Draft <draft-ietf-
mobileip-ipv6-06.txt>. Following were major issues and changes discussed at the
meeting. Also, please refer to the latest draft for a list of recent changes.
1. Is the tunnel a hop or not?
Answer: Yes, you need to have one hop left.
2. Rules for binding lifetime -- what if you're registering multiple addresses?
Consensus: Choose to use the minimum of all proposed lifetime.
3. Need to specify the duration for remembering the sequence number after the
deletion of an address binding.
Consensus: Minimum of 120 seconds or remaining lifetime.
Issue: CDPD keeps states around for ages. The end-to-end working group couldn't think
of anything better than 120sec even after plenty of discussions.
4. Update IPSEC references to the new documents. What if the MN-HA security
association expires while the MN is away from home?
Decision: look further into the issue and discuss it to the mailing list.
1. Mention to IESG/RFC-EDITOR that this document "updates" IPv6 specifications.
2. Place in the Mobile IPv6 draft, perhaps in the ABSTRACT but definitely up front,
that this document places some requirements on **ALL** IPv6 nodes, so don't blow
it off just because you don't care about mobility.
1. Add IPCPv6 as a method for obtaining a COA.
Mobile IP and Public Key Authentication
AAA Extensions for Mobile IP
Reverse Network Address Translators
Negotiated Address Reuse
Mobility Support in IPv6
go to list