One document matched: draft-oneill-mip-proxyccoa-00.txt
Personal A. O'Neill
Internet Draft Flarion Technologies
Document: draft-oneill-mip-proxyccoa-00.txt 8 May 2002
Expires: Oct 2002
Proxy CCoA Tunneling for Mobile IP
<draft-oneill-mip-proxyccoa-00.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.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
In MIPv4, when a Mobile Node (MN) registers with the 'D' bit, in the
MIP Registration to a Home Agent (HA), then the MN wishes to use a
Co-located Care-of address (CCoA) with a specific Home Address (HoA).
Packets sent to the MN Home Address (HoA) will then be encapsulated in
the CCoA by the HA and forwarded directly to the MN. Alternatively, a
MN can obtain from the local Foreign Agent(FA) a shared FA CoA for
inclusion in its MIP Registration to the FA/HA. In this case, the HA
encapsulates to the FA CoA, and the Foreign Agent then decapsulates and
delivers the HoA addressed packet unencapsulated to the MN. This draft
adds to MIPv4 the ability for the MN to acquire a MN specific FA CoA
that provides the MN with a topologically correct local address and
whose tunnel encaps/decaps is provided by the FA. This address is
called a proxy CCoA (PCCoA) and the associated processing in the MN and
FA is called Proxy CCoA tunneling. This capability is applicable to any
access technology but is especially useful for wir
A.W. O'Neill Expires Sept 2002 [Page 1]
INTERNET-DRAFT Proxy CCoA Tunneling for Mobile IP May 2002
INDEX
Abstract
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions used in this document . . . . . . . . . . . . . . . . . 3
3. Terminology used in this document . . . . . . . . . . . . . . . . . 3
4. MIPv4 Proxy CCoA Tunneling. . . . . . . . . . . . . . . . . . . . . 3
4.1. Proxy CCoA Negotiation . . . . . . . . . . . . . . . . . . . . 3
4.2. Downlink forwarding. . . . . . . . . . . . . . . . . . . . . . 5
4.3. Uplink forwarding and reverse tunneling . . . . . . . . . . . 5
4.4. PCCoAs and smooth hand-off . . . . . . . . . . . . . . . . . . 5
4.5. PCCoA Advantages . . . . . . . . . . . . . . . . . . . . . . . 7
5. New Packet Formats
5.1. Mobility Agent Advertisement Extension . . . . . . . . . . . . 7
5.2. Proxy CCoA Extension . . . . . . . . . . . . . . . . . . . . . 7
5.3. New Registration Reply Codes . . . . . . . . . . . . . . . . . 8
5.4. Binding Update Message . . . . . . . . . . . . . . . . . . . . 8
5.5. Binding Acknowledgement Message. . . . . . . . . . . . . . . . 9
6. MIPv6 Considerations. . . . . . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . . . . 9
8. Notice Regarding Intellectual Property Rights . . . . . . . . . . . 9
9. References. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction
In MIPv4, when a MN registers with the 'D' bit, in the MIP Registration
to a
Home Agent through a Foreign Agent, then the MN wishes to use a
Co-located Care-of address (CCoA) with a specific Home Address
(HoA). Packets sent to the MN Home Address (HoA) will then be
encapsulated in the CCoA by the HA and forwarded direct to the MN
via the best route from any FA advertising the subnet of that
address. In addition, the MN can use that CCoA as a topologically
correct source/destination address for local access on the visited
subnet. In CCoA based reverse tunneling, the MN can encapsulate the
HoA itself into its Co-located Care of Address (CCoA) to cause the
packet to be reverse tunneled to the HA. The MN can in addition
leave the HoA unencapsulated so that the FA delivers the packet
natively and unencapsulated to the destination address. This is
known as selective reverse tunneling and is possible whether or not
the MN registers via the local FA.
Alternatively, a MN can use a shared FA CoA advertised to it by the
FA in an Agent Advertisement. In this case, the HA encapsulates to
the FA CoA who then decapsulates and delivers the HoA addressed
packet natively unencapsulated to the MN. When reverse tunneling,
the MN can select during MIP registration between the default Direct
Delivery Style and the optional Encapsulating Delivery Style. In
Direct Delivery Style, the MN sends packets unencapsulated via the
FA using the HoA as a source address, and the FA undertakes the
encapsulation of those packets towards the HA using the FA CoA as
the source address of the tunnel.
A.W. O'Neill Expires Sept 2002 [Page 2]
INTERNET-DRAFT Proxy CCoA Tunneling for Mobile IP May 2002
In Encapsulating Delivery Style, the MN instead encapsulates packets
with the
HoA as a source address towards the FA, which after decapsulating,
inspects the visitor list and then re-encapsulates into a tunnel
with the FA CoA as the source address. In addition, once
Encapsulating Delivery Style has been negotiated with the FA, then
the MN can selectively bypass reverse tunneling by sending packets
unencapsulated from the HoA.
The MN and the FA in existing MIP specs are therefore able to
selectively send and receive packets, either unencapsulated, or
encapsulated using the HoA as an inner source/destination address
and a CoA as the outer address. When sending unencapsulated between
each other, the MN and the FA avoid the additional bandwidth
incurred by a tunnel header. By using a FA CoA, the MN is however
deprived of a local topologically correct address (so preserving
address space) but is able to selectively avoid tunneling over the
access link, which is beneficial in cellular and other access
systems. By using a CCoA, the MN gets a topologically correct
address (where addresses are available) but then incurs the overhead
of the additional tunnel header for incoming traffic and during any
reverse tunneling operations. The use of a MN specific MIP tunnel
address can also be useful for QoS support.
What is missing in MIPv4 is the ability for the MN to acquire a MN
specific FA CoA as a CCoA, that provides the MN with a topologically
correct local address and whose tunnel encaps/decaps is provided by
the FA. This address is here called a proxy CCoA (PCCoA) and the
associated processing in the MN and FA is called Proxy CCoA
tunneling. This draft also describes reverse tunneling and smooth
hand-off extensions based on the PCCoA.
2. Conventions used in this document
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
[RFC2119].
3. Terminology used in this document
Much of the terminology used in this document borrows from Mobile
IPv4/v6. The following introduces additional terminology.
PCCoA - Proxy Co-located Care of Address PCCoA tunnelling - tunnel
processing carried out by the FA
4. MIPv4 Proxy CCoA Capability
4.1 Proxy CCoA Negotiation
The negotiation of a PCCoA is a local matter between the MN and the FA
and
there is no known reason why the HA should in any way be informed of
the optional configuration of the PCCoA capability by the MN on the
local FA. The HA simply detects a MIP request, via the FA, for CCoA
tunneling. According to Mobile IPv4 [MIPv4] and Reverse tunneling
[RevTun], the HA will expect the following tunneling to occur.
A.W. O'Neill Expires Sept 2002 [Page 3]
INTERNET-DRAFT Proxy CCoA Tunneling for Mobile IP May
2002
The HA will encapsulate all permitted unicast, multicast and
broadcast packets, intended for the MN HoA, in the CCoA included
within the associated MIP Registrations. The HA then sends the
packets to this CCoA from the source address of the HA. If reverse
tunneling is enabled then the HA will decapsulate all permitted
unicast, multicast and broadcast packets that are tunneled from the
CCoA to the HA address, with the inner source address matching the
HoA of the MN.
From the perspective of the HA, the CCoA is located at the MN and so
requires
the MIP signaling to have the 'D' bit set. However, as far as the FA
is concerned the CoA is actually a PCCoA, which as far as Internet
routing is concerned can be considered to be a MN specific FA CoA.
The MN allocated this address is on a link-layer directly attached
to the FA and so the FA can also enable the MN to make use of this
MN specific FA CoA as a source/destination address for local
communications. Therefore, the HA sees the PCCoA as a CCoA, the FA
sees the PCCoA as a special MN specific FA CoA and the MN treats the
PCCoA as an ordinary interface address. A specific implementation of
the PCCoA process would be to simply move the tunnel/detunneling
process for a CCoA to the other end of the link (from the MN to the
FA) but in all other ways treat the address as a CCoA. This is then
a link specific change in much the same way that header compression
is a link specific function.
Proxy CCoA tunneling is therefore possible in MIP if the MN obtains
a CCoA from the FA subnet, the MN then registers for PCCoA service
via the FA, and that FA is able to support PCCoA processing for that
CCoA. The HA forwarding and tunnel processing is unaffected by the
changes in this draft. The availability of the PCCoA capability is
advertised by the FA in a FAA, by setting the new 'P' bit, or could
be triggered via an MIP extension, configuration, PPP, DHCP or other
signalling. To request PCCoA service, the MN MUST register via the
FA, whether or not this is mandated by the FAA 'R' bit, so that the
FA can undertake correct PCCoA processing. The MN can be allocated a
PCCoA either by a unicasted MIP FAA that includes a MN specific FA
CoA, through a DHCP server with a FA specific prefix, or by any
other means that can ensure the address is uniquely bound to a MN on
that FA.
Proxy CCoA tunneling is negotiated by the MN by including the Proxy
CCoA extension in the MIP Registration as well as setting the 'D'
flag used to signal the use of a CCoA. This structure is required so
that the FA can remove the PCCoA extension whilst leaving the 'D'
bit so that the HA will continue to treat the MN as if it had a
CCoA. In the future, if HAs require knowledge of the PCCoA
mechanism, and sufficient deployment has / will occur, then the
extension mechanism could be replaced by instead assigning and
setting a new 'P' flag bit (proxy CCoA) in the MIP Registration, as
well as setting the 'D' bit (CCoA).
The MIP CCoA Registration, when acknowledged by both the HA and the
FA in the MIP Reply, causes the FA to store both the HoA and the
PCCoA in the visitor list for that MN. Both the HoA and the PCCoA
can be used as source / destination addresses to/from the MN. The
HoA is used for remote access to/from the HA whilst the PCCoA can be
used for topologically correct local access whilst the MN remains at
that FA.
A.W. O'Neill Expires Sept 2002 [Page 4]
INTERNET-DRAFT Proxy CCoA Tunneling for Mobile IP May 2002
4.2 Downlink Forwarding
Downlink packets addressed to the HoA, arrive at the FA via the HA,
encapsulated in the PCCoA of the MN. Downlink packets (local traffic
using the PCCoA as a source/dest address) otherwise arrive directly,
and unencapsulated, at the FA. The FA inspects the PCCoA and
searches for it in the visitor list. If the packet is unencapsulated
then it is simply forwarded to the owning MN. If the packet is
encapsulated then it is first decapsulated and the inner unicast
destination header inspected to ensure it matches the HoA state for
that MN. If the decapsulated packet is broadcast/multicast, and the
MIP flags for that MN have requested broadcast traffic and/or the MN
is a member of that multicast group, then the packet is forwarded
unencapsulated to the MN over a point-to-point access medium but
must be sent in its encapsulated form over a broadcast medium.
4.3 Uplink forwarding and reverse tunneling
Uplink unicast packets from the HoA are sent unencapsulated via the FA
and
injected into the routing fabric unencapsulated. In the case of
reverse tunneling, the FA encapsulates the permitted unicast,
broadcast and multicast packets with the PCCoA of the MN as the
tunnel source address, and HA as the tunnel destination address.
This is so that the packets will match the registered binding in the
HA. Broadcast/multicast packets sent over a broadcast access medium
must be encapsulated in the HoA and sent to the shared FA CoA where
they are decapsulated, the visitor list and group membership for
that MN inspected, and permitted packets re-encapsulated to the HA,
as before, within the PCCoA. Note that with proxy CCoA tunneling the
option for selective reverse tunneling from the MN is lost. However,
this ability can be re-instated if the MN provides the FA with a
classifier that specifically defines which of the MNs uplink traffic
SHOULD NOT be reverse tunneled. This is achieved by first selecting
Reverse tunneling for a specific HoA by setting the 'T' bit as
normal in the MIP Registration, and then including a set of excluded
classifiers in the form of quintuples describing the uplink unicast
header.
4.4 PCCoAs and smooth Hand-offs
Smooth hand-offs [RoutOp] enable a MN that was previously registered
at the
old Foreign Agent (oFA) with an oFA CoA, to request the forwarding
of packets, sent to the MN HoA and decapsulated from the oFA HoA, to
the MNs new CoA. This means however, that smooth hand-offs are not
supported for a MN with a CCoA that is either registered or
unregistered at the oFA. This is because a FA is not allowed to
decapsulate from the oCCoA and forward to the new CoA at the new
point of attachment. Smooth forwarding could be supported by instead
having the oFA additionally encapsulate the oCCoA to the nCoA but
this clearly adds overhead and requires the nFA to have knowledge of
the oCCoA to correctly forward in the case of the MN acquiring a nFA
CoA.
A.W. O'Neill Expires Sept 2002 [Page 5]
INTERNET-DRAFT Proxy CCoA Tunneling for Mobile IP May 2002
The PCCoA capability in contrast brings the required functionality to
the FA
to support the smooth forwarding of CCoAs, if the MN registered via
the oFA, irrespective of whether or not the MN is using a CCoA or a
PCCoA. In the case of a normal CCoA, the FA can still transiently
support the PCCoA capability and automatically transition the CCoA
to a PCCoA when the BU is received from the nFA or directly from the
MN. This is only possible if the CCoA is uniquely advertised by that
FA. The incoming BU that includes the nCoA will then create a
binding between the HoA (and indirectly the oCCoA) and the nCCoA,
such that the oFA can decapsulate everything from the oCCoA and re-
encapsulate into the nCoA before forwarding. Broadcast / multicast
traffic is handled by checking the MIP flags and the HoA group
membership and re- encapsulating all permitted packets. The oFA will
also encapsulate into the nCoA all packets that are received
unencapsulated with a destination address equal to the oCCoA (local
traffic using the oCCoA as a network address) during the shorter of
the lifetime of the smooth hand-off or the delay until the oCCoA is
re-allocated. The request to trigger transient PCCoA support is
implicit at the oFA on the reception of a BU. In the case of a MN
that was using a PCCoA at the oFA, the meaning of the BU is again
implicit and the oFA simply proceeds as for the oCCoA after the
PCCoA transition.
If the BU is from the MN then it is for a CCoA at a MN that is not
registering via the nFA. This however does not affect this hand-off
but will affect subsequent hand-offs because the PCCoA transient
forwarding is only possible if a MN registers via a FA. If the BU is
originated by the nFA then the nCoA in the BU is either a nFA CoA or
a nPCCoA, which affects the processing at the oFA. This is because
the sending of a nFA CoA implies that the nFA does not support
PCCoAs and therefore the oFA (which does support PCCoAs) should
undertake all processing required to convert the oCCoA or the oPCCoA
received traffic into a format that will be correctly received and
forwarded by the nFA. This means that any broadcast/multicast
traffic must be first encapsulated into the HoA of the MN before
encapsulating into the nFA CoA. It also means that the BU must
specifically indicate whether it is for a FA CoA or a CCoA/PCCoA by
setting the new 'D' bit. The 'D' bit is set in the BU if the MIP
Registration via the nFA had either the 'D' or the 'P' bit set, or
is set by the MN that is using a CCoA. The difference at the nFA
between a CCoA and a PCCoA is kept within the nFA, and between the
nFA and the MN that requested a PCCoA by including the PCCoA
extension in its registration.
The BU is otherwise unchanged. In addition, the mandatory BUack and
its status codes do not need to be extended because the failure of
the BU for technical reasons at the oFA, for a CCoA, directly
implies a PCCoA processing failure.
When considering reverse smooth tunneling, as described in
<draft-oneill-mip-
revtun-ho-00.txt>, the mechanisms are unchanged for PCCoAs other
than that the reverse smooth tunneling is now between MN specific
and shared FA CoAs, rather than just between shared FA CoAs. The
smooth BU will contain both 'T' and 'D' bits set and the reverse
tunneling will be from the nCCoA to the oFA CoA and then from the
oCCoA/PCCoA to the GFA/HA. Broadcast/multicast must be reverse
tunneled according to the required processing at the receiver for
the CoA type.
Clearly however, the PCCoA capability is only available when the FA
is both able (eg IPSEC) and trusted to perform the tunnel management
for the MN.
A.W. O'Neill Expires Sept 2002 [Page 6]
INTERNET-DRAFT Proxy CCoA Tunneling for Mobile IP May
2002
4.5 PCCoA Advantages
These procedures avoid the CCoA encapsulation for remote access traffic
over
the access link. In addition, the FA is now in a position to police
traffic addressed to a specific HoA from a specific gateway, via the
PCCoA, before it is sent to the MN, and can also effectively support
smooth hand-offs for all CCoAs. In the case of broadcast/multicast
the FA is now in a position to avoid the additional encapsulation
over the air in both directions when the access medium supports
point to point link layer connectivity to/from the MN. Finally, the
MN specific (PCCoA) MIP encapsulation simplifies address-based QoS
support in the network between the HA and the MN.
5. New Packet Formats
5.1. Mobility Agent Advertisement 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 | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime |R|B|H|F|M|G|r|T|S|I|P| reserved|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| zero or more Care-of Addresses |
| ... |
The only change to the Mobility Agent Advertisement Extension [1] is
the additional 'P' bit:
P Agent offers proxy CCoA tunneling.
A foreign agent that sets the 'P' bit MUST support the proxy CCoA
tunneling for any CCoAs that are uniquely advertised into the
routing system by that FA. Using this information, a mobile node is
able to choose a foreign agent that supports proxy CCoA tunneling.
Notice that if a mobile node does not understand this bit, it simply
ignores it as per [MIPv4] and reverts to normal CCoA behaviour. The
ordering of addresses in FAAs is according to the relevant MIP specs
and is not altered by this draft.
5.2. Proxy CCoA Extension
The Proxy CCoA Extension MAY ONLY be included if the 'D' bit is set
and the MN is registering via the FA . If this extension is absent,
and the 'D' bit is set, then normal CCoA behaviour from Mobile IP
[MIPv4] and RevTun[2] is undertaken. The Encapsulating Delivery
Style extension and the Proxy CCoA extension MUST NOT be in the same
registration. Mobile Nodes and Foreign agents SHOULD support the
Proxy CCoA Extension.
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Type: TBA, Length 0.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A.W. O'Neill Expires Sept 2002 [Page 7]
INTERNET-DRAFT Proxy CCoA Tunneling for Mobile IP May 2002
5.3. New Registration Reply Codes
Foreign agent registration replies MUST convey if the
PCCoA request failed. These new reply codes are defined:
Service denied by the foreign agent:
X1 PCCoA capability is mandatory
X2 PCCoA capability is administratively barred
X3 submitted PCCoA is not routable at the FA
X4 submitted PCCoA unavailable
In response to a Registration Request with the 'D' bit set, and
accompanied
by the PCCoA extension, mobile nodes may receive (and MUST accept)
code 70 (poorly formed request) from foreign agents. However,
foreign agents that support PCCoA capability MUST use the
appropriate new code.
If the MN registers via the FA with the 'D' bit set, and does not
include the PCCoA extension, then code X1 should be returned to the
MN to cause the MN to include the extension in any new request. If
the MN does include the PCCoA extension and it is either
administratively barred from using this capability (through either
foreign or home AAA policy state), then code X2 should be returned
to cause the MN to modify the Registration. Code X3 should be used
if the MN attempts to use as a CCoA an address that is not routable
at the FA, and code X4 should be used if the included address is
already being used by another MN. In either case, the MN should
attempt to get a new PCCoA for the local FA, either from the FA or
via some other method.
5.4. Binding Update Message
The binding Update message is modified as described below. A new BU
flag, the
'D' flag, is added to indicate a request for smooth forwarding of
the oCoA to the nCCoA/nPCCoA. The BU 'D' flag is only set if the MIP
Registration to the nFA, that generated the BU also has the 'D' bit
set.
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|D| Rsv | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobile Node Home Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Care-of Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Identification +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions ...
+-+-+-+-+-+-+-+-
A.W. O'Neill Expires Sept 2002 [Page 8]
INTERNET-DRAFT Proxy CCoA Tunneling for Mobile IP May 2002
It is mandatory that a BU with the 'D' bit set must also have the 'A'
bit set so that the BU sender has confirmation that the forwarding
will occur. The absence of this flag indicates that the CoA in the
BU is a nFA CoA. If the oCoA is either a CCoA or a PCCoA, then the
absence of this flag causes the oFA to try to convert any arriving
flows so that they are compatible with the destination nFA CoA. This
specifically means that any permitted broadcast/multicast traffic,
and any packets with the oCCoA/PCCoA as an unencapsulated
destination address (local traffic), must first be encapsulated into
the HoA before being additionally encapsulated into the nFA CoA in
the BU.
5.5. Binding Acknowledge Message
The format of the Binding Acknowledge message is unchanged, apart from
extending the allowed values of the status field to cover the same
cases as identified for the MIP Reg. The processing is such that if
a BU is sent with the 'D' bit set that does not also have the 'A'
bit set, then the oFA should still accept the request, if in all
other ways correct, and return an acknowledgement.
Up-to-date values of the Code field are specified in the most recent
"Assigned Numbers" [13].
6. IPv6 Considerations
IPv6 has the use of a CCoA by the MN as the normal method of tunneling
due to
the better address availability and allocation mechanisms compared
to IPv4. IPv6 does not have the notion of a Foreign Agent though,
but an access router or a Local Mobility Agent could instead be
modified to undertake the PCCoA functionality defined in this draft,
with the obvious required changes. In the case of hand-off, the
option of receiving a BU containing a nFA CoA is not possible and so
the 'D' bit is not required to distinguish between the two CoA types
(nFA CoA or a CCoA/PCCoA).
7. Security Considerations
No new security issues are raised by this draft than are already
considered
in the design of Mobile IPv4 [MIPv4], MIPv4 reverse tunneling
[RevTun], MIP Route Optimization [RoutOpt] and Mobile IPv6 [MIPv6].
8. Notice Regarding Intellectual Property Rights
Flarion's submissions will conform with RFC 2026. Flarion may seek
patent protection on some or all of the technical information
submitted by its employees in connection with the IETF's standards
process. If part(s) of a submission by Flarion is (are) included in
a standard and Flarion owns patent(s) and/or pending patent
application(s) that are essential to implementation of such included
part(s) in said standard, Flarion is prepared to grant a license on
fair, reasonable, reciprocal (license back) and non- discriminatory
terms on such included part(s).
A.W. O'Neill Expires Sept 2002 [Page 9]
INTERNET-DRAFT Proxy CCoA Tunneling for Mobile IP May 2002
9. References
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3",
BCP 9,
RFC 2026, October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997
[MIPv4] C.E. Perkins, Ed., `` IP Mobility Support for IPv4,"
RFC3220, January 2002
[RevTun] G. Montenegro, Ed., "Reverse Tunneling for Mobile IP,
revised," Internet RFC 3024, January 2001.
[RoutOp] C. Perkins, D. Johnson, "Route Optimization in Mobile IP",
Internet- Draft, draft-ietf-mobileip-optim-11.txt (work in
progress), 6 September 2001.
[MIPv6] D. Johnson, C. Perkins, ``Mobility Support in IPv6",
Internet-Draft, draft-ietf-mobileip-ipv6-16.txt (work in progress),
22 March 2002.
[NestMIP] A.W. O'Neill, ``Nested MIP for mobility management,"
Internet- draft, draft-ietf-oneill-mip-nested-00.txt, May 2002.
[ConcatMIP] A.W. O'Neill, ``Concatenated MIP for mobility
management," Internet-draft, draft-ietf-oneill-mip-nested-00.txt,
May 2002.
Author's Addresses
Alan O'Neill
Flarion Technologies
Phone: +1 908 947 7033
Email: oneill@flarion.com
A.W. O'Neill Expires Sept 2002 [Page 10]
| PAFTECH AB 2003-2026 | 2026-04-24 04:27:25 |