draft-ietf-mip4-rfc2006bis-02.txt   draft-ietf-mip4-rfc2006bis-03.txt 
Mobile IP Working Group R. Rathi MIP4 Working Group R. Rathi
Internet Draft K. Leung Internet Draft K. Leung
H. Sjostrand Intended status: Standards Track Cisco Systems
June 15, 2006 Expires: July 18, 2007 H. Sjostrand
ipUnplugged
January 18, 2007
The Definitions of Managed Objects for IP Mobility Support The Definitions of Managed Objects for IP Mobility Support
using SMIv2, revised using SMIv2, revised
draft-ietf-mip4-rfc2006bis-02.txt draft-ietf-mip4-rfc2006bis-03.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that By submitting this Internet-Draft, each author represents that
any applicable patent or other IPR claims of which he or she is any applicable patent or other IPR claims of which he or she is
aware have been or will be disclosed, and any of which he or she aware have been or will be disclosed, and any of which he or she
becomes aware will be disclosed, in accordance with Section 6 of becomes aware will be disclosed, in accordance with Section 6 of
BCP 79. BCP 79.
This document may not be modified, and derivative works of it may not This document may not be modified, and derivative works of it may not
be created, other than to extract section "Mobile IP MIP definitions" be created, other than to extract section "Mobile IP MIP definitions"
as-is for separate use. as-is for separate use.
This document may only be posted in an Internet-Draft.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on Nov 15, 2006. This Internet-Draft will expire on July 18, 2007.
Abstract
This memo defines the Management Information Base (MIB) for use with Copyright Notice
network management protocols in TCP/IP-based internets. In
particular, it describes managed objects used for managing the Mobile
Node, Foreign Agent and Home Agent of the Mobile IP Protocol.
This memo is intended to update and possibly obsolete RFC 2006, Copyright (C) The IETF Trust (2007).
however, it is designed to be backward compatible
Conventions used in this document Abstract
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", This memo defines a portion of the Management Information Base (MIB)
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this for use with network management protocols in the Internet community.
document are to be interpreted as described in RFC2119 [RFC2119]. In particular, it describes managed objects used for managing the
Mobile Node, Foreign Agent and Home Agent of the Mobile IP Protocol.
Table of Contents Table of Contents
1. The Internet-Standard Management Framework.....................2 1. Introduction...................................................3
2. Structure of the MIB...........................................3 2. The Internet-Standard Management Framework.....................3
2.1. Structure of the Mobile IP................................3 3. Structure of the MIB...........................................3
2.2. MIB Groups................................................4 3.1. Structure of the Mobile IP................................3
2.3. Protocol Extensions.......................................4 3.2. MIB Groups................................................4
2.4. Textual Conventions.......................................5 3.3. Protocol Extensions.......................................5
3. Mobile IP MIB Definitions......................................5 3.4. Textual Conventions.......................................5
4. Security Considerations.......................................99 4. Mobile IP MIB Definitions......................................5
5. IANA Considerations..........................................100 5. Security Considerations.......................................99
6. Acknowledgments..............................................100 6. IANA Considerations..........................................101
7. Acknowledgments..............................................101
APPENDIX A: Changes from RFC 2006...............................102 APPENDIX A: Changes from RFC 2006...............................102
A.1. Changes in draft-ietf-mobileip-rfc2006bis-00............102 A.1. Changes in draft-ietf-mobileip-rfc2006bis-00............102
A.2. Changes in draft-ietf-mobileip-rfc2006bis-02............105 A.2. Changes in draft-ietf-mobileip-rfc2006bis-02............106
A.3. Changes in draft-ietf-mobileip-rfc2006bis-03............106 A.3. Changes in draft-ietf-mobileip-rfc2006bis-03............107
A.4. Changes in draft-ietf-mip4-rfc2006bis-00................107 A.4. Changes in draft-ietf-mip4-rfc2006bis-00................107
A.5. Changes in draft-ietf-mip4-rfc2006bis-01................107 A.5. Changes in draft-ietf-mip4-rfc2006bis-01................107
A.6. Changes in draft-ietf-mip4-rfc2006bis-02................107 A.6. Changes in draft-ietf-mip4-rfc2006bis-02................107
7. References...................................................108 A.7. Changes in draft-ietf-mip4-rfc2006bis-03................109
7.1. Normative References....................................108 8. References...................................................109
7.2. Informative References..................................110 8.1. Normative References....................................109
Author's Addresses..............................................110 8.2. Informative References..................................110
Intellectual Property Statement.................................110 Author's Addresses..............................................111
Disclaimer of Validity..........................................111 Intellectual Property Statement.................................111
Copyright Statement.............................................111
Acknowledgment..................................................111
1. The Internet-Standard Management Framework 1. Introduction
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it describes managed objects used for managing the
Mobile Node, Foreign Agent and Home Agent of the Mobile IP Protocol.
This memo is intended to update and possibly obsolete RFC 2006,
however, it is designed to be backward compatible
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 RFC2119 [RFC2119].
2. The Internet-Standard Management Framework
For a detailed overview of the documents that describe the current For a detailed overview of the documents that describe the current
Internet-Standard Management Framework, please refer to section 7 of Internet-Standard Management Framework, please refer to section 7 of
RFC 3410 [RFC3410]. RFC 3410 [RFC3410].
Managed objects are accessed via a virtual information store, termed Managed objects are accessed via a virtual information store, termed
the Management Information Base or MIB. MIB objects are generally the Management Information Base or MIB. MIB objects are generally
accessed through the Simple Network Management Protocol (SNMP). accessed through the Simple Network Management Protocol (SNMP).
Objects in the MIB are defined using the mechanisms defined in the Objects in the MIB are defined using the mechanisms defined in the
Structure of Management Information (SMI). This memo specifies a MIB Structure of Management Information (SMI). This memo specifies a MIB
module that is compliant to the SMIv2, which is described in STD 58, module that is compliant to the SMIv2, which is described in STD 58,
RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580
[RFC2580]. [RFC2580].
2. Structure of the MIB 3. Structure of the MIB
This memo defines a portion of the Management Information Base (MIB) This memo defines a portion of the Management Information Base (MIB)
for the use with network management protocols in the Internet for the use with network management protocols in the Internet
community. In particular, it describes managed objects for the community. In particular, it describes managed objects for the
Mobile IP Protocol (MIP), as defined in [RFC3344]. Mobile IP Protocol (MIP), as defined in [RFC3344].
2.1. Structure of the Mobile IP 3.1. Structure of the Mobile IP
This section describes the basic model of Mobile IP used in This section describes the basic model of Mobile IP used in
developing the Mobile IP MIB. This information should be useful to developing the Mobile IP MIB. This information should be useful to
the implementor in understanding some of the basic design decisions the implementor in understanding some of the basic design decisions
of the MIB. of the MIB.
The Mobile IP Protocol introduces these new functional entities: The Mobile IP Protocol introduces these new functional entities:
Mobile Node Mobile Node
A host or router that changes its point of attachment from one A host or router that changes its point of attachment from one
network or subnetwork to another. A mobile node may change its network or subnetwork to another. A mobile node may change its
location without losing connectivity and without changing its IP location without losing connectivity and without changing its IP
address; it may continue to communicate with other Internet nodes address; it may continue to communicate with other Internet nodes
at any location using its (constant) IP address, assuming link- at any location using its (constant) IP address, assuming link-
layer connectivity to a point of attachment is available. layer connectivity to a point of attachment is available.
Home Agent Home Agent
A router on a mobile node's home network which tunnels packets for A router on a mobile node's home network which tunnels packets for
skipping to change at page 4, line 10 skipping to change at page 4, line 29
A router on a mobile node's visited network which provides routing A router on a mobile node's visited network which provides routing
services to the mobile node while registered. The foreign agent services to the mobile node while registered. The foreign agent
detunnels and delivers packets to the mobile node that were detunnels and delivers packets to the mobile node that were
tunneled by the mobile node's home agent. For datagrams sent by a tunneled by the mobile node's home agent. For datagrams sent by a
mobile node, the foreign agent may serve as a default router for mobile node, the foreign agent may serve as a default router for
registered mobile nodes. registered mobile nodes.
This document specifies the objects used in managing these entities; This document specifies the objects used in managing these entities;
namely, the Mobile Node, the Home Agent, and the Foreign Agent. namely, the Mobile Node, the Home Agent, and the Foreign Agent.
2.2. MIB Groups 3.2. MIB Groups
Objects in this MIB are arranged into groups. Each group is Objects in this MIB are arranged into groups. Each group is
organized as a set of related objects. The overall structure and the organized as a set of related objects. The overall structure and the
relationship between groups and the Mobile IP entities are shown relationship between groups and the Mobile IP entities are shown
below: below:
Groups Mobile Node Foreign Agent Home Agent Groups Mobile Node Foreign Agent Home Agent
MipSystemGroup X X X MipSystemGroup X X X
MipSecAssociationGroup2 X X X MipSecAssociationGroup2 X X X
skipping to change at page 4, line 34 skipping to change at page 5, line 6
mnRegistrationGroup2 X mnRegistrationGroup2 X
maAdvertisementGroup2 X X maAdvertisementGroup2 X X
maAdvertisementNAIGroup X X maAdvertisementNAIGroup X X
faSystemGroup X faSystemGroup X
faAdvertisementGroup2 X faAdvertisementGroup2 X
faRegistrationGroup2 X faRegistrationGroup2 X
haRegistrationGroup2 X haRegistrationGroup2 X
haRegNodeCountersGroup2 X haRegNodeCountersGroup2 X
mipSecNotificationsGroup2 X X mipSecNotificationsGroup2 X X
2.3. Protocol Extensions 3.3. Protocol Extensions
Apart from changes to base specification of Mobile IP [RFC3344], it Apart from changes to base specification of Mobile IP [RFC3344], it
has been enhanced in number of ways through its ability for added has been enhanced in number of ways through its ability for added
capabilities. Implementations of those capabilities have not been capabilities. Implementations of those capabilities have not been
able to have any management capabilities present in RFC 2006 able to have any management capabilities present in RFC 2006
compliant compliant [RFC2006] MIB module agents, since the capabilities
themselves postdated the adoption of RFC 2006. For several
MIB module agents, since the capabilities themselves postdated the significant capabilities, in the form of NAI extension [RFC2794],
adoption of RFC 2006. For several significant capabilities, in the Challenge/Response Extensions [RFC3012], Reverse Tunneling [RFC3024],
form of NAI extension [RFC2794], Challenge/Response Extensions Vendor/Organization-Specific Extensions [RFC3115] and Extensions for
[RFC3012], Reverse Tunneling [RFC3024], Vendor/Organization-Specific carrying NAI [RFC3846], the MIB Module defined in this document
Extensions [RFC3115] and Extensions for carrying NAI [RFC3846], the exposes object types to manage those extended capabilities and their
MIB Module defined in this document exposes object types to manage operation.
those extended capabilities and their operation.
NAI extension requires a thorough redefinition of MIB table row NAI extension requires a thorough redefinition of MIB table row
indices from the RFC 2006 state since it provides a one more way to indices from the RFC 2006 state since it provides a one more way to
identify the mobile nodes apart from home address. The functional identify the mobile nodes apart from home address. The functional
differences between this memo and RFC 2006 [RFC2002] are explained in differences between this memo and RFC 2006 [RFC2002] are explained in
Appendix A. Appendix A.
2.4. Textual Conventions 3.4. Textual Conventions
The RegistrationFlags, MipEntityIdentifierType, MipEntityIdentifier, The RegistrationFlags, MipEntityIdentifierType, MipEntityIdentifier,
MipEntityIdentifierNAI and MipDeliveryStyle are used as textual MipEntityIdentifierNAI and MipDeliveryStyle are used as textual
conventions in this document. These textual conventions are used for conventions in this document. These textual conventions are used for
the convenience of humans reading the MIB. Objects defined using the convenience of humans reading the MIB. Objects defined using
these conventions are always encoded by means of the rules that these conventions are always encoded by means of the rules that
define their primitive type. However, the textual conventions define their primitive type. However, the textual conventions
havecspecial semantics associated with them. Hence, no changes to havecspecial semantics associated with them. Hence, no changes to
the SMI or the SNMP are necessary to accommodate these textual the SMI or the SNMP are necessary to accommodate these textual
conventions which are adopted merely for the convenience of readers. conventions which are adopted merely for the convenience of readers.
3. Mobile IP MIB Definitions 4. Mobile IP MIB Definitions
MIP-MIB DEFINITIONS ::= BEGIN MIP-MIB DEFINITIONS ::= BEGIN
IMPORTS IMPORTS
Counter32, Gauge32, Integer32, IpAddress, Counter32, Gauge32, Integer32, IpAddress,
Unsigned32, MODULE-IDENTITY, OBJECT-TYPE, Unsigned32, MODULE-IDENTITY, OBJECT-TYPE,
NOTIFICATION-TYPE, mib-2 NOTIFICATION-TYPE, mib-2
FROM SNMPv2-SMI -- [RFC2578] FROM SNMPv2-SMI -- [RFC2578]
RowStatus, TruthValue, TimeStamp, RowStatus, TruthValue, TimeStamp,
StorageType, TEXTUAL-CONVENTION StorageType, TEXTUAL-CONVENTION
FROM SNMPv2-TC -- [RFC2579] FROM SNMPv2-TC -- [RFC2579]
MODULE-COMPLIANCE, OBJECT-GROUP, MODULE-COMPLIANCE, OBJECT-GROUP,
NOTIFICATION-GROUP NOTIFICATION-GROUP
FROM SNMPv2-CONF -- [RFC2580] FROM SNMPv2-CONF -- [RFC2580]
InterfaceIndex InterfaceIndex
FROM IF-MIB; -- [RFC2863] FROM IF-MIB; -- [RFC2863]
mipMIB MODULE-IDENTITY mipMIB MODULE-IDENTITY
LAST-UPDATED "200605260000Z" LAST-UPDATED "200701160000Z"
ORGANIZATION "IETF Mobile IP Working Group" ORGANIZATION "IETF Mobile IP Working Group"
CONTACT-INFO CONTACT-INFO
" Ravindra Rathi " Ravindra Rathi
Greenfield Networks Cisco Systems, Inc.
rrathi@greenfieldnetworks.com rathi@cisco.com
Kent Leung Kent Leung
Cisco Systems, Inc. Cisco Systems, Inc.
kleung@cisco.com kleung@cisco.com
Hans Sjostrand Hans Sjostrand
ipUnplugged ipUnplugged
hans@ipunplugged.com" hans@ipunplugged.com"
DESCRIPTION DESCRIPTION
"The MIB module for configuring and displaying Mobile "The MIB module for configuring and displaying Mobile
IP Information. IP Information.
Copyright (C) The Internet Society (2006). This version Copyright (C) IETF Trust (2007). This version
of this MIB module is part of RFC yyyy; see the RFC of this MIB module is part of RFC yyyy; see the RFC
itself for full legal notices." itself for full legal notices."
REVISION "200605260000Z" REVISION "200701160000Z"
DESCRIPTION DESCRIPTION
"Updated for latest changes to Mobile IP." "Updated for latest changes to Mobile IP."
REVISION "199606040000Z" REVISION "199606040000Z"
DESCRIPTION DESCRIPTION
"Initial revision, published as part of RFC 2006." "Initial revision, published as part of RFC 2006."
::= { mib-2 44 } ::= { mib-2 44 }
mipMIBObjects OBJECT IDENTIFIER ::= { mipMIB 1 } mipMIBObjects OBJECT IDENTIFIER ::= { mipMIB 1 }
-- ================================================================= -- =================================================================
skipping to change at page 99, line 12 skipping to change at page 99, line 27
mipSecNotificationsGroup NOTIFICATION-GROUP mipSecNotificationsGroup NOTIFICATION-GROUP
NOTIFICATIONS { mipAuthFailure } NOTIFICATIONS { mipAuthFailure }
STATUS deprecated STATUS deprecated
DESCRIPTION DESCRIPTION
"The notification related to security violations." "The notification related to security violations."
::= { mipGroups 13 } ::= { mipGroups 13 }
END END
4. Security Considerations 5. Security Considerations
Assuming that secure network management (such as SNMP v3) is Assuming that secure network management (such as SNMP v3) is
implemented, the objects represented in this MIB do not pose a threat implemented, the objects represented in this MIB do not pose a threat
to the security of the network. to the security of the network.
There are a number of management objects defined in this MIB that There are a number of management objects defined in this MIB that
have a MAX-ACCESS clause of read-write and/or read-create. Such have a MAX-ACCESS clause of read-write and/or read-create. Such
objects may be considered sensitive or vulnerable in some network objects may be considered sensitive or vulnerable in some network
environments. The support for SET operations in a non-secure environments. The support for SET operations in a non-secure
environment without proper protection can have a negative effect on environment without proper protection can have a negative effect on
skipping to change at page 100, line 32 skipping to change at page 101, line 5
features as provided by the SNMPv3 framework. Specifically, the use features as provided by the SNMPv3 framework. Specifically, the use
of the User-based Security Model RFC 2574 [RFC2574] and the View- of the User-based Security Model RFC 2574 [RFC2574] and the View-
based Access Control Model RFC 2575 [RFC2575] is recommended. based Access Control Model RFC 2575 [RFC2575] is recommended.
It is then a customer/user responsibility to ensure that the SNMP It is then a customer/user responsibility to ensure that the SNMP
entity giving access to an instance of this MIB, is properly entity giving access to an instance of this MIB, is properly
configured to give access to the objects only to those principals configured to give access to the objects only to those principals
(users) that have legitimate rights to indeed GET or SET (users) that have legitimate rights to indeed GET or SET
(change/create/delete) them. (change/create/delete) them.
5. IANA Considerations 6. IANA Considerations
The MIB module in this document uses the following IANA-assigned The MIB module in this document uses the following IANA-assigned
OBJECT IDENTIFIER values recorded in the SMI Numbers registry: OBJECT IDENTIFIER values recorded in the SMI Numbers registry:
Descriptor OBJECT IDENTIFIER value Descriptor OBJECT IDENTIFIER value
---------- ----------------------- ---------- -----------------------
mipMIB { mib-2 44 } mipMIB { mib-2 44 }
Editor's Note (to be removed prior to publication): this draft makes Editor's Note (to be removed prior to publication): this draft makes
no additional requests of the IANA. no additional requests of the IANA.
6. Acknowledgments 7. Acknowledgments
The origin of this document is from RFC 2006 "The Definitions of The origin of this document is from RFC 2006 "The Definitions of
Managed Objects for IP Mobility Support using SMIv2" written by D. Managed Objects for IP Mobility Support using SMIv2" written by D.
Cong, M. Hamlen and C. Perkins. The editor wishes to acknowledge the Cong, M. Hamlen and C. Perkins. The editor wishes to acknowledge the
good work of these original authors. Thanks to Roy Jose, Rudreshwar good work of these original authors. Thanks to Roy Jose, Rudreshwar
N, Basavaraj Patil, Sri Gundavelli and Olavi Kompulainen for their N, Basavaraj Patil, Sri Gundavelli and Olavi Kompulainen for their
useful comments and contributions. useful comments and contributions.
APPENDIX A: Changes from RFC 2006 APPENDIX A: Changes from RFC 2006
There has been a substantial update of this MIP-MIB since RFC2006.
However, sometimes backwards compatibility is preferred over
perfection. So, some mib peculiarities still exist in this mib.
RFC2006 had some index elements with read access. Although this is
not recommended, these index object are not made not-accessible. The
non deprecated objects are mnRegAgentAddress and mnRegCOA of row
mnRegistrationEntry; and haMobilityBindingMN and haMobilityBindingCOA
of row haMobilityBindingEntry. To get a clean compile with smilint,
use the "-i index-element-accessible" option.
RFC2006 had BITS constructs for RegistrationFlags and the mnAdvFlags
that made sense in relation to RFC2002 but was hard to extend to in
relation to the bits flags used in RFC3344. The editors have decided
that backwards compatibility and not deprecate more objects than
necessary is more important than a direct relation to the flags in
later MIP RFCs. Extra care should be taken when RegistrationFlags and
mnAdvFlags are implemented.
A.1. Changes in draft-ietf-mobileip-rfc2006bis-00 A.1. Changes in draft-ietf-mobileip-rfc2006bis-00
- Section "The Network Management Framework" was updated. - Section "The Network Management Framework" was updated.
- Subsection Protocol Extensions was created under section - Subsection Protocol Extensions was created under Overview
Overview. section.
- Section Security Considerations was updated. - Section Security Considerations was updated.
- Changes to the MIB definition are following. Changes are - Changes to the MIB definition are following. Changes are
listed in the order of their occurrence in the MIB definition. listed in the order of their occurrence in the MIB definition.
(1) The textual convention RegistrationFlags was updated. The (1) The textual convention RegistrationFlags was updated. The
bit for VJ compression was removed and bit for reverse bit for VJ compression was removed and bit for reverse
tunneling was added. tunneling was added.
Three new textual conventions were added : Three new textual conventions were added :
MipEntityIdentifierType, MipEntityIdentifier and MipEntityIdentifierType, MipEntityIdentifier and
skipping to change at page 107, line 29 skipping to change at page 107, line 50
(1) Draft retitled to draft-ietf-mip4-rfc2006bis-00.txt (1) Draft retitled to draft-ietf-mip4-rfc2006bis-00.txt
A.5. Changes in draft-ietf-mip4-rfc2006bis-01 A.5. Changes in draft-ietf-mip4-rfc2006bis-01
(1) Chair addresses updated. (1) Chair addresses updated.
A.6. Changes in draft-ietf-mip4-rfc2006bis-02 A.6. Changes in draft-ietf-mip4-rfc2006bis-02
1) Aligned RegistrationFlags with rfc2006. 1) Aligned RegistrationFlags with rfc2006.
Issue:
mnAdvFlags are totally difeerent from teh adverticed octet, but has
the same dataformat (octet). Shouldn't we change it to the 3344 octet
|R|B|H|F|M|G|r|T|
2) mipEncapsulationSupported OBJECT-TYPE should also contain RFC3519 2) mipEncapsulationSupported OBJECT-TYPE should also contain RFC3519
UDP Tunnel option. Aded new bit to the object since new bit is [RFC3519] UDP Tunnel option. Aded new bit to the object since new bit
allowed for MIB revision. (RFC 2578, section 10.2 and RFC4181, is allowed for MIB revision. (RFC 2578, section 10.2 and RFC4181,
section 4.9). section 4.9).
3) mipSecurityAssocEntry and mipSecurityViolationEntry now contain 3) mipSecurityAssocEntry and mipSecurityViolationEntry now contain
the full NAI and the address objects. Since the index could be either the full NAI and the address objects. Since the index could be either
or, and the NAI could be crippled in the index. or, and the NAI could be crippled in the index.
4) The error code for a security violation is added. The reason 4) The error code for a security violation is added. The reason
object itself isn't enough (it's almost always other(6). Added object itself isn't enough (it's almost always other(6). Added
mipSecRecentViolationErrorCode to mipSecViolationTable mipSecRecentViolationErrorCode to mipSecViolationTable
skipping to change at page 108, line 37 skipping to change at page 109, line 5
11) The mipAuthFailure2 notification needs additional objects. Traps 11) The mipAuthFailure2 notification needs additional objects. Traps
should be complete and don't require addditional read operations. the should be complete and don't require addditional read operations. the
mipAuthFailure2 trap adds objects from hte seviolation table. mipAuthFailure2 trap adds objects from hte seviolation table.
12) StorageType a'la rfc2579 is added to those tables where they are 12) StorageType a'la rfc2579 is added to those tables where they are
needed. needed.
13) Updated template stuff, such as mib boiler plate, security 13) Updated template stuff, such as mib boiler plate, security
considerations, references and TC conventions. considerations, references and TC conventions.
7. References A.7. Changes in draft-ietf-mip4-rfc2006bis-03
7.1. Normative References 1) No functional changes at all. Updated boilerplate, dates and
address information.
8. References
8.1. Normative References
[RFC1701] Hanks S. et. al., "Generic Routing Encapsulation (GRE)", [RFC1701] Hanks S. et. al., "Generic Routing Encapsulation (GRE)",
RFC1701, October 1994. RFC1701, October 1994.
[RFC2002] Perkins C., "IP Mobility Support", RFC 2002, Octoer 1996. [RFC2002] Perkins C., "IP Mobility Support", RFC 2002, Octoer 1996.
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003,
October 1996. October 1996.
[RFC2004] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, [RFC2004] Perkins, C., "Minimal Encapsulation within IP", RFC 2004,
skipping to change at page 110, line 8 skipping to change at page 110, line 30
[RFC3115] Dommety, G. and K. Leung, "Mobile IP Vendor/Organization [RFC3115] Dommety, G. and K. Leung, "Mobile IP Vendor/Organization
Specific Extensions", RFC 3115, April 2001. Specific Extensions", RFC 3115, April 2001.
[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
August 2002. August 2002.
[RFC3519] H. Levkowetz and S. Vaarala, "Mobile IP Traversal of [RFC3519] H. Levkowetz and S. Vaarala, "Mobile IP Traversal of
[RFC3846] F. Johansson and T. Johansson, Mobile IPv4 Extension for [RFC3846] F. Johansson and T. Johansson, Mobile IPv4 Extension for
7.2. Informative References 8.2. Informative References
[RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart,
"Introduction and Applicability Statements for Internet- "Introduction and Applicability Statements for Internet-
Standard Management Framework", RFC 3410, December 2002. Standard Management Framework", RFC 3410, December 2002.
Author's Addresses Author's Addresses
Ravindra Rathi Kent Leung Ravindra Rathi Kent Leung
Greenfield Networks Cisco Systems, Inc. Cisco Systems, Inc Cisco Systems, Inc.
#2/2, Union Street 170 West Tasman Drive 12, Bannerghatta Road 170 West Tasman Drive
Bangalore - 560 001 San Jose, CA. 95134 Subramanya Arcade Block San Jose, CA. 95134
Bangalore - 560 029
India USA India USA
Phone: +91 80 4151 8871 Phone: +1 408 526 5030 Phone: +91 80 4154 1000 Phone: +1 408 526 5030
Email: rrathi@greenfieldnetworks.com Email: kleung@cisco.com Email: rathi@cisco.com Email: kleung@cisco.com
Hans Sjostrand Hans Sjostrand
ipUnplugged ipUnplugged
Arenavagen 21 Arenavagen 21
121 29 Stockholm 121 29 Stockholm
Sweden Sweden
Phone: +46 8 725 5900 Phone: +46 8 725 5900
Email: hans@ipunplugged.com Email: hans@ipunplugged.com
Intellectual Property Statement Intellectual Property Statement
skipping to change at page 111, line 18 skipping to change at page 112, line 5
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Disclaimer of Validity Full Copyright Statement
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 41 change blocks. 
94 lines changed or deleted 118 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/