Internet DRAFT - draft-ryu-nemo-ingress-filtering
draft-ryu-nemo-ingress-filtering
NEMO Working Group J. Ryu
Internet-Draft N. Choi
Expires: December 21, 2006 Seoul National University
E. Paik
KT
T. Kwon
C. Park
Seoul National University
June 19, 2006
Bypassing Ingress Filtering for Multihomed mobile network
draft-ryu-nemo-ingress-filtering-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that 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 becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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.
This Internet-Draft will expire on December 21, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
In this draft, a solution of the ingress filtering problem is
proposed for a NEMO with multiple mobile routers. Extending the
multiple care-of address registration mechanism and introducing a
Ryu, et al. Expires December 21, 2006 [Page 1]
Internet-Draft Bypassing Ingress Filtering for NEMO June 2006
"prefix peer" relationship among the mobile routers, we can solve the
ingress filtering problem in a NEMO with multiple mobile routers.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Prefix peer care-of address registration . . . . . . . . . 5
4.2. Prefix peer care-of address de-registration . . . . . . . 6
4.3. Bypassing ingress filtering . . . . . . . . . . . . . . . 6
5. Multiple care-of address extensions . . . . . . . . . . . . . 7
5.1. Binding Cache Structure Changes . . . . . . . . . . . . . 7
5.2. Binding Update Structure Changes . . . . . . . . . . . . . 7
5.3. Message Format Changes . . . . . . . . . . . . . . . . . . 7
5.3.1. Binding Unique Identifier sub-option . . . . . . . . . 7
5.4. HA Operation . . . . . . . . . . . . . . . . . . . . . . . 8
5.4.1. Registration and de-registration . . . . . . . . . . . 8
5.5. MR Operation . . . . . . . . . . . . . . . . . . . . . . . 8
5.5.1. Registration and de-registration . . . . . . . . . . . 8
5.6. New Message Format . . . . . . . . . . . . . . . . . . . . 9
5.6.1. ICMP Mobile Router Hint . . . . . . . . . . . . . . . 9
5.6.2. ICMP Mobile Router Hint Acknowledgement . . . . . . . 10
6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 11
7. Security Consideration . . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Appendix A. MR Failover . . . . . . . . . . . . . . . . . . . . . 12
A.1. HA operation . . . . . . . . . . . . . . . . . . . . . . . 13
A.2. MR operation . . . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . . . 17
Ryu, et al. Expires December 21, 2006 [Page 2]
Internet-Draft Bypassing Ingress Filtering for NEMO June 2006
1. Introduction
Recently, the NEMO working group [1] is dealing with the multihoming
issues [2] in NEMO and is also concerned about an ingress filtering
problem. However, there is no suitable solution for the ingress
filtering problem in multihomed NEMO. So, we consider about this
ingress filtering problem when there are multiple MRs, HAs, and MNPs.
Suppose that there is a multihomed NEMO which has multiple MRs. If
any MN wnats to handover to other MRs it should change its address.
The stateless or stateful auto-configuration procedure of IPv6 for
the acquisition of a new care-of address is used in this case, it
takes very long time and connectivity cannot be sustained. In
addition, if any MR fails, and hence it cannot provide any more
service, one of the backup MRs should provide service on behalf of
the blocked one. But in this case, if the mobile and fixed nodes are
provided the Internet service by the backup MR with no change of
their addresses, ingress filtering problem will occur. Accordingly,
we propose a prefix peer CoA registration mechanism in this draft.
The mobile and fixed nodes can be provided the Internet service
without the ingress filtering problem nor address changing in the
above situation using our proposed mechanism. And MN's soft handover
is also possible while maintain its connectivity. Our proposed
mechanism extends the multiple CoA registration mechanism for a
multihomed host [3].
2. Terminology
Terms used in this draft are defined in [4], [5] and [6]. We define
or redefine the following ones:
Active Mobile Router
An Active mobile router is an MR that is currently used and
advertises its own mobile network prefix (MNP).
Blocked Mobile Router
A blocked mobile router is an MR i) whose egress interface or
ingress interface fails. ii) itself fails. Here, "failure" means
an MR loses the connectivity due to mobility, fading and so on.
Peer Mobile Router
A peer mobile router is an MR capable of providing Internet
services instead of a blocked or an active MR. A peer MR (PMR)
should be first authenticated by an active MR or its HA in the
same NEMO to prevent malicious nodes from spoofing. An MR hearing
Ryu, et al. Expires December 21, 2006 [Page 3]
Internet-Draft Bypassing Ingress Filtering for NEMO June 2006
router advertisement (RA) messages from neighboring MRs initiates
a PMR authentication depending on its policy. Also, the technique
proposed in [7] can be also used for the PMR authentication.
Prefix Peer Binding Update (PPBU)
Prefix peer binding update means that this binding update message
is sent by PMRs. PPBU has different meanings depending on the
alternative flag in Binding Unique Identifier sub-option. If the
alternative flag is set to 1, it means that a PMR sends this
binding update message for PMR registration. Otherwise, this
binding update message is sent by a PMR to change the active CoA
of the MNP in binding cache of a HA.
Active CoA
An active CoA is a CoA that is currently used in the NEMO. The
active field in binding cache entry of the HA corresponding to the
CoA is set to 1.
Peer CoA
A peer CoA is a CoA that is assigned to the egress interface of a
PMR. This CoA will be used to provide Internet service instead of
a blocked mobile router.
ICMP Mobile Router Hint
The ICMP Mobile Router Hint message is sent by the active or
blocked MR to its PMR. By this message, the PMR can know the
state of the active MR more quickly and HA address of the active
or blocked MR to perform PPBU. This is an option.
3. Problem Statement
When there are multiple MRs in a multihomed mobile network, the MNP
of each MR can be different from each other. When an MN wants to
handover to another MRs without address changes or an MN of the
blocked MR directly uses the peer MR without address change, an MN
will send a packet to peer MR. The MR2, which is the peer MR, has
only one tunnel to HA2 so all packets arrived at MR2 will be
forwarded. And then this packet must be discarded at a home network
of the peer MR because of the ingress filtering according to a policy
of ISP. So, we need the solution of ingress filtering. For this, we
introduce how to bypass ingress filtering. The detailed operation is
followed.
Ryu, et al. Expires December 21, 2006 [Page 4]
Internet-Draft Bypassing Ingress Filtering for NEMO June 2006
+-----+ +-----+
| HA1 | | HA2 ==(Discarded)
+--+--+ +--=--+
| =
+--+----------=----+ MR2's +-----+
| Internet === |=======| MR2 |
+--------------+---+ CoA +--+--+
| | = |
+--+--+ | = |
| CN | MR1's|CoA = |
+-----+ +-----+ = |MNP2(+ MNP1)
| MR1 | = |
+--+--+ = |
MN leaves MR1 = |
| = |
+--+-=------------+--+
| === NEMO |
+--------------------+
= : path of MR1's packet when MR1 has some problem
Figure 1. Ingress filtering problem.
4. Protocol Overview
To provide a way to bypass ingress filtering for a multihomed mobile
network, we propose to make a "prefix peer" relationship among the
MRs. The prefix peer relationship is realized by introducing a
prefix peer binding update (PPBU) message. Detailed operations are
described in the following chapters.
4.1. Prefix peer care-of address registration
Prefix peer CoA registration is an extended version of multiple CoAs
registration mechanism for mobile IPv6 [4]. An MR can register not
only its CoA but also delegate its PMR to register the PMR's CoA as a
peer CoAs by using multiple CoAs registration. The registered CoA of
PMRs is used to provide continuous Internet service and to bypass
ingress filtering. If the MR wants to delegate its PMR to register
the PMR's CoA, it must generate a BID and use this when it sends BU.
The PMR also generate a BID and use that when it sends a PPBU. After
receiving the BU or the PPBU, the HA adds or updates an entry
corresponding to the CoA in the BU or the PPBU into its binding
cache.
Ryu, et al. Expires December 21, 2006 [Page 5]
Internet-Draft Bypassing Ingress Filtering for NEMO June 2006
4.2. Prefix peer care-of address de-registration
If the MR is plan to move another network or it can not provide peer
services, it should de-register its CoA. When the MR wants to de-
register its CoA, it sends a PPBU with the unset prefix peer flag in
the Binding Update identifier sub-option to the HA which has this CoA
entry as a peer CoA in its binding cache. After receiving this PPBU,
the HA deletes this CoA entry from its binding cache.
4.3. Bypassing ingress filtering
The point of our mechanism is that there are no IP address changes.
The PMR takes over service of an active or a blocked MR by relaying
the packets from an active or a blocked MR's node. Since a source
address of that packet is not changed, ingress filtering will not
occur. IF the PMR starts advertising the MNP of the active or
blocked MR in addition to its own MNP, the PMR can provide Internet
service for the active or blocked MR's node. That is, if the PMR
receives a packet from fixed nodes or MNs belonging to the MNP of the
active or the blocked MR, it forwards the packet through an
appropriate tunnel between the HA of the active or the blocked MR and
itself for seamless connectivity. So, ingress filtering problem is
solved because there are no IP address changes.
+-----+ +-----+
| HA2 | ==| HA1 |
+--+--+ = +--=--+
| = = =
+--+-=--------=----+ MR2's +-----+
| = Internet = = |=======| MR2 |
+--=-----------+---+ CoA +--+--+
= | = |
+--+--+ | = |
| CN | MR1's|CoA = |
+-----+ +-----+ = |MNP2(+ MNP1)
| MR1 | = |
+--+--+ = |
MN leaves MR1 = |
| = |
+--+-=------------+--+
| === NEMO |
+--------------------+
= : path of MR1's packet when MR1 has some problem
Figure 2. Bypassing ingress filtering concept.
Ryu, et al. Expires December 21, 2006 [Page 6]
Internet-Draft Bypassing Ingress Filtering for NEMO June 2006
Especially, we illustrate the multihomed NEMO which consists of 2
HAs, 2 MRs, and 2 MNPs. The MR1 and the MR2 have a peer relationship
each other using prefix peer binding update. If MN of MR1 wants to
handover to MR2 or there are some problem (ingress or egress
interface failure) at MR1, the peer MR (MR2) will take over the MR1's
service. Packets from an MN or a fixed node of MR1 will be forwarded
to HA1 through MR2, so there is no ingress filtering problem.
5. Multiple care-of address extensions
5.1. Binding Cache Structure Changes
To support bypassing ingress filtering, there are multiple MRs in a
multihomed NEMO. Hence, additional fields are defined in the binding
cache structure as follow:
- Active : Active means the CoA is now in use. The value MUST be
zero if the CoA is not active.
- Peer : Peer means this CoA is a PMR's one. The value MUST be zero
if the CoA is not a PMR's CoA.
5.2. Binding Update Structure Changes
Additional flags are required in the binding update structure, which
are:
- Prefix peer flag : Prefix peer flag MUST be set to 0 if the binding
update is not sent by a peer MR or is used for de-registration of
prefix peer CoA by PMR.
- Alternative flag : Alternative flag MUST be set to 1 if the CoA is
the peer CoA.
5.3. Message Format Changes
Additional flags are required in the binding update structure, which
are:
5.3.1. Binding Unique Identifier sub-option
New Alternative (A) flag and new prefix peer flag (P) are included in
the Binding Unique Identifier sub-option. The rest of the Binding
Unique Identifier sub-option format remains the same as defined in
[3].
Ryu, et al. Expires December 21, 2006 [Page 7]
Internet-Draft Bypassing Ingress Filtering for NEMO June 2006
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 = TBD | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Binding Unique ID (BID) | Priority |B|P|A| Reserved|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+
Prefix Peer (P)
The prefix peer flag is set to indicate to the HA whether this BU
is sent by the PMR (PPBU) or a peer CoA de-registration for
already registered one. If the flag is set to 0, it is just a BU
or the de-registration sent by PMR.
Alternative (A)
The alternative flag is set to indicate to the HA whether the CoA
in the binding update is a peer CoA or not. If this flag in PPBU
is set to 0, the active filed of this CoA in binding cache should
be set.
For descriptions of the other fields in the message, see [3].
5.4. HA Operation
5.4.1. Registration and de-registration
When the HA receives the PPBU message that includes the CoA of a PMR
with alternative flag set to 1, it checks its binding cache. If the
HA does not have this CoA entry in its binding cache, it adds an
entry corresponding to this CoA as a peer CoA. The binding cache
entry has an active field set to 0 and a peer field set to 1. When
the HA receive the BU message that includes the CoA of a PMR with
alternative flag set to 1, it also checks its binding cache. If the
HA does not have this CoA entry in its binding cache, it silently
discards this packet. If it does, it deletes this CoA entry. After
management its binding cache, the HA responds BU ACK to the PMR.
5.5. MR Operation
5.5.1. Registration and de-registration
After the successful PMR authentication, the PMR sends a PPBU to the
HA of the active MR for peer MR registration. This PPBU includes the
CoA of a PMR and alternative flag set to 1 in Binding Update
Identifier sub-option. If the PMR wants to de-register its CoA, it
sends a PPBU with the unset prefix peer flag in the Binding Update
Ryu, et al. Expires December 21, 2006 [Page 8]
Internet-Draft Bypassing Ingress Filtering for NEMO June 2006
identifier sub-option and alternative flag set to 1 to the HA which
has this CoA entry as a peer CoA in its binding cache.
5.6. New Message Format
5.6.1. ICMP Mobile Router Hint
The ICMP Mobile Router Hint message is sent by the active or blocked
MR to its PMR. By this message, the PMR can know the state of the
active MR more quickly and HA address of the active or blocked MR to
perform PPBU. If code value is 1, it means that this Hint message
(Failure Notify) doesn't need an ACK message. This ICMP MR Hint
message is an option.
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 | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
. .
. HA Address .
. .
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IP Fields:
Source Address
Home address of the active or blocked MR.
Destination Address
Home address of the PMR.
ICMP Fields:
Type
Ryu, et al. Expires December 21, 2006 [Page 9]
Internet-Draft Bypassing Ingress Filtering for NEMO June 2006
154
Code
0 = Failure notify;
1 = Failure notify without ACK;
2 ~ 255 = reserved.
Checksum
The ICMP checksum [8].
Identifier
An identifier to aid in matching MR Hint acknowledgement messages
to this MR Hint message.
Reserved
This field is unused. It MUST be initialized to zero by the
sender and MUST be ignored by the receiver.
HA address
HA address of the blocked MR.
5.6.2. ICMP Mobile Router Hint Acknowledgement
The ICMP Mobile Router Hint Acknowledgement message is used by a PMR
to respond to the active or blocked MR that sends an ICMP Mobile
Router Hint message.
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 | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IP Fields:
Ryu, et al. Expires December 21, 2006 [Page 10]
Internet-Draft Bypassing Ingress Filtering for NEMO June 2006
Source Address
Home address of the PMR.
Destination Address
Home address of the active or blocked MR.
ICMP Fields:
Type
155
Code
0 = Failure notify ACK;
1 ~ 255 = reserved.
Checksum
The ICMP checksum [8].
Identifier
The identifier from the invoking MR Hint message.
Reserved
This field is unused. It MUST be initialized to zero by the
sender and MUST be ignored by the receiver.
6. Conclusion
In this draft, we propose a solution of the ingress filtering problem
on multihomed NEMO. The peer MRs can provide continuous Internet
service to an MN for seamless MR handover or any node that has been
attached to a blocked MR, thus ingress filtering problem can be
avoided. For our proposed scheme, very few modifications to multiple
care-of address registration and NEMO are required.
7. Security Consideration
In this draft, we assume that a peer MR is already authenticated by
using an MR authentication mechanism [7]. However, it is necessary
Ryu, et al. Expires December 21, 2006 [Page 11]
Internet-Draft Bypassing Ingress Filtering for NEMO June 2006
to design more secure authentication mechanism with low overhead.
8. References
[1] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert,
"Network Mobility (NEMO) Basic Support Protocol", RFC 3963,
January 2005.
[2] Ng, C., "Analysis of Multihoming in Network Mobility Support",
draft-ietf-nemo-multihoming-issues-05 (work in progress),
February 2006.
[3] Wakikawa, R., "Multiple Care-of Addresses Registration",
draft-wakikawa-mobileip-multiplecoa-05 (work in progress),
March 2006.
[4] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[5] Manner, J. and M. Kojo, "Mobility Related Terminology",
RFC 3753, June 2004.
[6] Ernst, T. and H. Lach, "Network Mobility Support Terminology",
draft-ietf-nemo-terminology-05 (work in progress), March 2006.
[7] Choi, S., "Neighbor MR Authentication and Registration Mechanism
in Multihomed Mobile Networks",
draft-cho-nemo-mr-registration-00 (work in progress),
April 2004.
[8] Conta, A. and S. Deering, "Internet Control Message Protocol
(ICMPv6) for the Internet Protocol Version 6 (IPv6)
Specification", RFC 2463, December 1998.
Appendix A. MR Failover
In this section, the mechanism of MR failover is described. In
general, an MR uses the wireless channel as an egress interface for
NEMO support. Because this wireless channel is subject to
disconnectivity due to channel error, blackout, or handover, some
link failures may occur. After the HA of an active MR authenticates
and registers a PMR successfully, the PMR should be able to take over
if the active MR fails.
Ryu, et al. Expires December 21, 2006 [Page 12]
Internet-Draft Bypassing Ingress Filtering for NEMO June 2006
+-----+ +-----+
| HA1 | | HA2 |
+--+--+ +--+--+
| |
| |
+---+----------+----+MR2's +-----+
| Internet |------| MR2 |
+---+----------+----+ CoA +--+--+
|MNP2(with MNP1)
(failure) |
+-----+ |
| MR1 | |
+--+--+ |
| |
| |
+--+--------------+--+
| NEMO |
+--------------------+
Figure 3. Multi-homed NEMO with blocked MR1
A.1. HA operation
When a HA1 receives a PPBU with the unset alternative flag in the
Binding Update Identifier sub-option but the peer field in binding
cache entry of this HA corresponding to the CoA in the PPBU is set to
1, the HA1 assumes that the MR1 fails. If the HA1 does not have any
entry corresponding to this CoA, it silently discards this message.
The CoA of the active MR1 in binding cache whose active field set to
1 cannot be used because of active MR failure. Thus its active field
is set to 0. An active field corresponding to the CoA in a PPBU is
set to 1.
A.2. MR operation
If an MR1 detects its ingress (or egress) interface failure, it
should immediately stop advertising its prefix and may send a new
ICMP Mobile Router Hint message (code = 0) to the PMR (MR2). Any PMR
detects an egress (or ingress) interface failure of the active MR
(MR1), the PMR sends a PPBU to the HA1. The alternative flag of the
Binding Update Identifier sub-option in this PPBU is set to 0. After
receiving the PPBU ACK, this PMR replies a new ICMP Mobile Router
Hint Acknowledgement (code = 0) to the blocked MR if it received ICMP
MR Hint message. The PMR (MR2) starts advertising the MNP1 in
addition to its own MNP (MNP2). The PMR (MR2) can provide Internet
service for fixed and MNs instead of the blocked MR (MR1). That is,
if the PMR (MR2) receives a packet from fixed or mobile nodes
Ryu, et al. Expires December 21, 2006 [Page 13]
Internet-Draft Bypassing Ingress Filtering for NEMO June 2006
belonging to the MNP of the blocked MR, it can forward the packet
through an appropriate tunnel between the HA of the blocked MR and
itself for seamless connectivity.
Ryu, et al. Expires December 21, 2006 [Page 14]
Internet-Draft Bypassing Ingress Filtering for NEMO June 2006
Authors' Addresses
Jiho Ryu
Seoul National University
Multimedia Communications Lab., Seoul National Univ.
Shillim-dong, Kwanak-gu
Seoul 151-744
Korea
Phone: +82-2-880-1848
Fax: +82-2-872-2045
Email: jhryu@mmlab.snu.ac.kr
URI: http://mmlab.snu.ac.kr/~jhryu/
Nakjung Choi
Seoul National University
Multimedia Communications Lab., Seoul National Univ.
Shillim-dong, Kwanak-gu
Seoul 151-744
Korea
Phone: +82-2-876-7170
Fax: +82-2-876-7170
Email: fomula@mmlab.snu.ac.kr
URI: http://mmlab.snu.ac.kr/~fomula/
Eunkyoung Paik
KT
Advanced Technology Lab. KT
17 Woomyeon-dong, Seocho-gu
Seoul 137-792
Korea
Phone: +82-2-526-5233
Fax: +82-2-526-5759
Email: euna@kt.co.kr
URI: http://mmlab.snu.ac.kr/~eun/
Ryu, et al. Expires December 21, 2006 [Page 15]
Internet-Draft Bypassing Ingress Filtering for NEMO June 2006
Taekyoung Kwon
Seoul National University
Multimedia Communications Lab., Seoul National Univ.
Shillim-dong, Kwanak-gu
Seoul 151-744
Korea
Phone: +82-2-880-9105
Fax: +82-2-872-2045
Email: tk@mmlab.snu.ac.kr
URI: http://mmlab.snu.ac.kr/~tk/
Chulhyun Park
Seoul National University
Multimedia Communications Lab., Seoul National Univ.
Shillim-dong, Kwanak-gu
Seoul 151-744
Korea
Phone: +82-2-876-7170
Fax: +82-2-876-7170
Email: chpark@mmlab.snu.ac.kr
URI: http://mmlab.snu.ac.kr/~chpark/
Ryu, et al. Expires December 21, 2006 [Page 16]
Internet-Draft Bypassing Ingress Filtering for NEMO June 2006
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
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). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Ryu, et al. Expires December 21, 2006 [Page 17]
