T. Narten, E. Nordmark and W. Simpson. Neighbor discovery for ip version 6 (ipv6). In Request for Comments (RFC 2461), 1998.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....Their current definition relies on the assumption that there are no untrustworthy nodes at the local link. In practice, even a single untrustworthy node can launch various kinds of attacks, including Denial ofService (DoS) Man in the Middle (MitM) and masquerade. The current set of RFCs [6][7][8] 9] do acknowledge the situation to a degree, but do not provide much detail about how to use the suggested protection mechanism, IPsec. Unluckily, there are a number of problems when using IPsec for securing Neighbor Discovery [10] In this paper, we outline the current situation and describe ....

....We assume that the reader is familiar with the basic IPv6 architecture and functions. Thus, we concentrate on explaining the essential points of Neighbor and Router Discovery functions, focusing on security related issues. 2. 1 Neighbor Discovery The purpose of IPv6 Neighbor Discovery (ND) [7] is to provide IPv6 nodes with a means to discover the presence and link layer addresses of the other nodes on the local link. Additionally, it provides methods for discovering routers on the local link, for detecting when a local node becomes unreachable, for resolving duplicate addresses, and ....

[Article contains additional citation context not shown here]

T. Narten, E. Nordmark and W. Simpson, Neighbor Discovery for IP Version 6 (IPv6), RFC2641, IETF, December 1998.

....were successfully delivered. The feedback can be received either through an extra end to end network layer message, or by exploiting properties of transport layers, such as TCP with SACK [37] this feedback approach is somewhat similar that used in IPv6 for Neighbor Unreachability Detection [39]. Stronger properties are obtained when the routing protocol sends such feedback packets along a route equal to the reversed route of the triggering packet; otherwise, a malicious node along one route may drop the acknowledgment for a packet transmitted along a functioning route. A node with ....

Thomas Narten, Erik Nordmark, and William Allen Simpson. Neighbor Discovery for IP Version 6 (IPv6). RFC 2461, December 1998.

....packets were successfully delivered. The feedback can be received either through an extra end toend network layer message, or by exploiting properties of transport layers, such as TCP with SACK [21] this feedback approach is somewhat similar that used in IPv6 for Neighbor Unreachability Detection [24]. A node with multiple routes to a single destination can assign a fraction of packets that it originates to be sent along each route. When a substantially smaller fraction of packets sent along any particular route are successfully delivered, the node can begin sending a smaller fraction of its ....

T. Narten, E. Nordmark, and W. A. Simpson. Neighbor discovery for IP version 6 (IPv6). Internet RFC 2461, December 1998.

....were successfully delivered. The feedback can be received either through an extra end to end network layer message, or by exploiting properties of transport layers, such as TCP with SACK [36] this feedback approach is somewhat similar that used in IPv6 for Neighbor Unreachability Detection [38]. Stronger properties are obtained when the routing protocol sends such feedback packets along a route equal to the reversed route of the triggering packet; otherwise, a malicious node along one route may drop the acknowledgment for a packet transmitted along a functioning route. A node with ....

Thomas Narten, Erik Nordmark, and William Allen Simpson. Neighbor Discovery for IP Version 6 (IPv6). RFC 2461, December 1998.

....were successfully delivered. The feedback can be received either through an extra end to end network layer message, or by exploiting properties of transport layers, such as TCP with SACK [37] this feedback approach is somewhat similar that used in 1Pv6 for Neighbor Unreachability Detection [39]. Stronger properties are obtained when the routing protocol sends such feedback packets along a route equal to the reversed route of the triggering packet; otherwise, a malicious node along one route may drop the acknowledgment for a packet transmitted along a functioning route. A node with ....

Thomas Narten, Erik Nordmark, and William Allen Simpson. Neighbor Discovery for IP Version 6 (IPv6). RFC 2461, December 1998.

....were successfully delivered. The feedback can be received either through an extra end to end network layer message, or by exploiting properties of transport layers, such as TCP with SACK [53] this feedback approach is somewhat similar that used in IPv6 for Neighbor Unreachability Detection [60]. Stronger properties are obtained when the routing protocol sends such feedback packets along a route equal to the reversed route of the triggering packet; otherwise, a malicious node along one route may drop the acknowledgment for a packet transmitted along a functioning route. A node with ....

Thomas Narten, Erik Nordmark, and William Allen Simpson. Neighbor Discovery for IP Version 6 (IPv6). RFC 2461, December 1998.

....the branch from its current point of attachment to the top MN, ffl and for each MN on the branch to the top MN, its network prefix and the IP address of the mobility agent. This information is advertised by a new option used in the Router Advertisement messages of the IPv6 Neighbor Discovery [5]. A mechanism similar to the dynamic home agent address Discovery mechanism of Mobile IPv6 could be defined instead. In this case, the Mobile Host would send a Binding request to the anycast address of the MN and get back the address of the mobility agent. 3.2.3 Packet Delivery When a ....

T. Narten, E. Nordmark and W. Simpson. Neighbor Discovery for IP Version 6 (IPv6). IETF RFC 2461, December 1998.

....networking has been laid out as a mandatory requirement for IPv6 [11] and the design for Mobile IP has been modified to take advantage of IPv6 s superior capabilities. All IPv6 nodes are able to autoconfigure an IPv6 address appropriate for their current point of attachment to the Internet [35,60]; moreover there are plenty of IPv6 addresses available, so foreign agents are no longer needed to support mobility. Furthermore, since all IPv6 nodes are required to support authentication and privacy protection at the network layer, binding updates can be supplied in a secure fashion to the ....

T. Narten, E. Nordmark and W. Simpson, Neighbor discovery for IP version 6 (IPv6), RFC

....hosts on local area networks are trustworthy. Our handoff mechanism is no more and no less secure that ARP itself. Finally, our mechanism extends cleanly to next generation IP networks. In these networks, the functionality of ARP will be available through the neighbor discovery features of IPv6 [21]. 4. Implementation We implemented our local handoff mechanism on a Solaris 2.4 software platform. All protocol elements reside in the Unix kernel under the Streams framework, while some control software resides in a user level program at base stations. We pursued a kernel implementation to ....

T. Narten, E. Nordmark and W. Simpson, Neighbor discovery for IP version 6 (IPv6), RFC

....of various error conditions would need to be changed. Section 5 summarizes the security implications. Finally, Section 6 contains the conclusions of this research. 2 Current and evolving standards The current IPv6 architecture is de ned in a set of RFCs [3] 4] 6] 7] 10] 11] 12] 13] 17] 19][20][23] 26] In addition to the RFCs, there are a number of relatively mature Internet Drafts, including the Mobile IPv6 draft [14] Finally, there are a few drafts in their initial stages, including, for example [22] The latter ones we consider only as trend setters. In this section, we review the ....

T. Narten, E. Nordmark, and W. Simpson. Neighbor Discovery for IP Version 6 (IPv6). IETF, RFC 2461, December 1998.

....to the limited signaling carried out within EMIPv6 RF, a paging mechanism is put in place for locating MHs when needed. A. Signaling for Host Mobility The migration detection and acquisition of COA procedures are assumed to operate the same way as that in MIPv6, using the IPv6 neighbor discovery [7] and address autoconfiguration [8] protocols. When a MH enters a foreign network, it informs the HA using the registration procedure illustrated in Fig. 2. The proposed scheme differs from MIP in that this is the only time a MH registers with its home network while it remains powered on and in the ....

T. Narten, E. Nordmark, and W. Simpson, Neighbor Discovery for IP Version 6 (IPv6), IETF Internet Draft, July 1997.

....a paging mechanism is put in place for locating MHs if needed much like the case in mobile telephony. B. Host Mobility Support The migration detection and acquisition of care of address (COA) procedures are assumed to operate the same way as those in MIPv6 [3] using the IPv6 neighbor discovery [4] and address autoconfiguration [5] protocols. When a MH enters a foreign network or moves to another router, it acquires a COA. Next the MH informs its HA using a registration mechanism similar to that in base MIP and MIP with route optimization (MIP RO) 6] whereby the MH submits the request to ....

T. Narten, E. Nordmark, and W. Simpson, Neighbor Discovery for IP Version 6 (IPv6), IETF Internet Draft, July 1997.

....dynamically allocate IP addresses, as this greatly simplifies the process of network detection and care of address acquisition. However, to prevent multiple devices from accidentally using the same IP address in a network environment, a Duplicate Address Detection (DAD) mechanism has been mandated [4] for IPv6. This demands devices to verify first that a newly acquired address is not already in use before actively utilising that address. Experiments have shown that while addresses can be acquired using stateless autoconfiguration within a few milliseconds, the DAD verification process can take ....

Narten, T., Nordmark, E., Simpson, W.: Neighbor Discovery for IP version 6 (IPv6). Internet RFC 2461. (1998)

No context found.

T. Narten, E. Nordmark and W. Simpson. Neighbor discovery for ip version 6 (ipv6). In Request for Comments (RFC 2461), 1998.

No context found.

Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6), RFC 1970, August 1996.

No context found.

T. Narten, E. Nordmark, and W. Simpson. Neighbor Discovery for IP Version 6 (IPv6). Request for Comments 2461, 1998.

No context found.

T. Narten, E. Nordmark, and W. Simpson. Neighbor Discovery for IP Version 6 (IPv6), December 1998.

No context found.

T. Narten, E. Nordmark and W. Simpson. Neighbor discovery for ip version 6 (ipv6). In Request for Comments (RFC 2461), 1998.

No context found.

Narten, T., Nordmark, E., Simpson, W.: Neighbor discovery for IP version 6 (IPv6). RFC 2461, IETF (1998)

No context found.

T. Narten, E. Nordmark, W. Simpson. Neighbor Discovery for IP Version 6 (IPv6). RFC 2461.

No context found.

T. Narten, E. Nordmark, and W. Simpson. Neighbor Discovery for IP Version 6 (IPv6). Request for Comments 2461, 1998.

No context found.

T. Narten, E. Nordmark, and W. Simpson. Neighbor discovery for IP version 6 (IPv6). RFC 2461, December 1998.

No context found.

Narten, T., E. Nordmark, and W. Simpson. Neighbor Discovery for IP version 6 (IPv6). RFC 1970.

No context found.

T. Narten, E. Nordmark, and W. Simpson. Neighbor Discovery for IP Version 6 (IPv6). RFC 2461, December 1998.

No context found.

E. Nordmark T. Narten. Neighbor discovery for IP version 6 (IPv6). IETF RFC 1970.

First 50 documents

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC