Sunteți pe pagina 1din 5

The Neighbor Discovery Protocol (NDP) is a protocol in the Internet protocol sui

te used with IPv6. It operates in the link layer of the Internet model (RFC 1122
) and is responsible for address autoconfiguration of nodes, discovery of other
nodes on the link, determining the link layer addresses of other nodes, duplicat
e address detection, finding available routers and Domain Name System (DNS) serv
ers, address prefix discovery, and maintaining reachability information about th
e paths to other active neighbor nodes (RFC 4861).[1]
The protocol defines five different ICMPv6 packet types to perform functions for
IPv6 similar to the Address Resolution Protocol (ARP) and Internet Control Mess
age Protocol (ICMP) Router Discovery and Router Redirect protocols for IPv4. How
ever, it provides many improvements over its IPv4 counterparts (RFC 4861, sectio
n 3.1). For example, it includes Neighbor Unreachability Detection (NUD), thus i
mproving robustness of packet delivery in the presence of failing routers or lin
ks, or mobile nodes.
The Inverse Neighbor Discovery (IND) protocol extension (RFC 3122) allows nodes
to determine and advertise an IPv6 address corresponding to a given link-layer a
ddress, similar to Reverse ARP for IPv4. The Secure Neighbor Discovery Protocol
(SEND) is a security extension of NDP that uses Cryptographically Generated Addr
esses (CGA) and the Resource Public Key Infrastructure (RPKI) to provide an alte
rnate mechanism for securing NDP with a cryptographic method that is independent
of IPsec. Neighbor Discovery Proxy (ND Proxy) (RFC 4389) provides a service sim
ilar to IPv4 Proxy ARP and allows bridging multiple network segments within a si
ngle subnet prefix when bridging cannot be done at the link layer.
Technical details
NDP defines five ICMPv6 packet types for the purpose of router solicitation, rou
ter advertisement, neighbor solicitation, neighbor advertisement, and network re
directs.[1]
Router Solicitation (Type 133)
Hosts inquire with Router Solicitation messages to locate routers on an atta
ched link.[Definitions 1] Nodes which forward packets not addressed to them gene
rate Router Advertisements immediately upon receipt of this message rather than
at their next scheduled time.
Router Advertisement (Type 134)
Routers advertise their presence together with various link and Internet par
ameters either periodically, or in response to a Router Solicitation message.
Neighbor Solicitation (Type 135)
Neighbor solicitations are used by nodes to determine the link layer address
of a neighbor, or to verify that a neighbor is still reachable via a cached lin
k layer address.
Neighbor Advertisement (Type 136)
Neighbor advertisements are used by nodes to respond to a Neighbor Solicitat
ion message.
Redirect (Type 137)
Routers may inform hosts of a better first hop router for a destination.
These messages are used to provide the following functionality:
Router discovery: hosts can locate routers residing on attached links.
Prefix discovery: hosts can discover address prefixes that are on-link for a
ttached links.
Parameter discovery: hosts can find link parameters (e.g., MTU).
Address autoconfiguration: stateless configuration of addresses of network i
nterfaces.
Address resolution: mapping between IP addresses and link-layer addresses.
Next-hop determination: hosts can find next-hop routers for a destination.

Neighbor unreachability detection (NUD): determine that a neighbor is no lon


ger reachable on the link.
Duplicate address detection (DAD): nodes can check whether an address is alr
eady in use.
Recursive DNS Server (RDNSS) and DNS Search List (DNSSL) assignment via a ro
uter advertisement (RA) options.[2] This is a new feature and not widely support
ed by clients.
Packet redirection to provide a better next-hop route for certain destinatio
ns.
Message-based multi-streaming
SCTP applications submit their data to be transmitted in messages (groups of byt
es) to the SCTP transport layer. SCTP places messages and control information in
to separate chunks (data chunks and control chunks), each identified by a chunk
header. The protocol can fragment a message into a number of data chunks, but ea
ch data chunk contains data from only one user message. SCTP bundles the chunks
into SCTP packets. The SCTP packet, which is submitted to the Internet Protocol,
consists of a packet header, SCTP control chunks (when necessary), followed by
SCTP data chunks (when available).
SCTP may be characterized as message-oriented, meaning it transports a sequence
of messages (each being a group of bytes), rather than transporting an unbroken
stream of bytes as does TCP. As in UDP, in SCTP a sender sends a message in one
operation, and that exact message is passed to the receiving application process
in one operation. In contrast, TCP is a stream-oriented protocol, transporting
streams of bytes reliably and in order. However TCP does not allow the receiver
to know how many times the sender application called on the TCP transport passin
g it groups of bytes to be sent out. At the sender, TCP simply appends more byte
s to a queue of bytes waiting to go out over the network, rather than having to
keep a queue of individual separate outbound messages which must be preserved as
such.
The term multi-streaming refers to the capability of SCTP to transmit several in
dependent streams of chunks in parallel, for example transmitting web page image
s together with the web page text. In essence, it involves bundling several conn
ections into a single SCTP association, operating on messages (or chunks) rather
than bytes.
TCP preserves byte order in the stream by assigning a sequence number to each pa
cket. SCTP, on the other hand, assigns a sequence number to each message sent in
a stream. This allows independent ordering of messages in different streams. Ho
wever, message ordering is optional in SCTP; a receiving application may choose
to process messages in the order of receipt instead of the order they were sent.
Features
Features of SCTP include:
Multihoming support in which one or both endpoints of a connection can consi
st of more than one IP address, enabling transparent fail-over between redundant
network paths.
Delivery of chunks within independent streams eliminate unnecessary head-ofline blocking, as opposed to TCP byte-stream delivery.
Path selection and monitoring to select a primary data transmission path and
test the connectivity of the transmission path.
Validation and acknowledgment mechanisms protect against flooding attacks an
d provide notification of duplicated or missing data chunks.
Improved error detection suitable for Ethernet jumbo frames.
The designers of SCTP originally intended it for the transport of telephony (Sig
naling System 7) over Internet Protocol, with the goal of duplicating some of th

e reliability attributes of the SS7 signaling network in IP. This IETF effort is
known as SIGTRAN. In the meantime, other uses have been proposed, for example,
the Diameter protocol[5] and Reliable server pooling (RSerPool).[6]
Motivations
TCP has provided the primary means to transfer data reliably across the Internet
. However, TCP has imposed limitations on several applications. From RFC 4960:
TCP provides both reliable data transfer and strict order-of-transmissio
n delivery of data. Some applications need reliable transfer without sequence ma
intenance, while others would be satisfied with partial ordering of the data. In
both of these cases, the head-of-line blocking offered by TCP causes unnecessar
y delay.
The stream-oriented nature of TCP is often an inconvenience. Application
s must add their own record marking to delineate their messages, and must make e
xplicit use of the push facility to ensure that a complete message is transferre
d in a reasonable time.
The limited scope of TCP sockets complicates the task of providing highl
y-available data transfer capability using multi-homed hosts.
TCP is relatively vulnerable to denial-of-service attacks, such as SYN a
ttacks.
Packet structure
Main article: SCTP packet structure
8 15
16 23 24 31
Bits
0 7
+0
Source port
Destination port
32
Verification tag
64
Checksum
96
Chunk 1 type
Chunk 1 flags Chunk 1 length
128
Chunk 1 data
Chunk N type
Chunk N data

Chunk N flags

Chunk N length

SCTP packets have a simpler basic structure than TCP packets. Each consists of t
wo basic sections:
The common header, which occupies the first 12 bytes and is highlighted in b
lue, and
The data chunks, which occupy the remaining portion of the packet. The first
chunk is highlighted in green, and the last of N chunks (Chunk N) is highlighte
d in red.
Each chunk has a type identifier that is one byte long yielding, at most, 255 di
fferent chunk types. RFC 4960 defines a list of chunk types and there are curren
tly 15 types defined. The remainder of the chunk is a two byte length (maximum s
ize of 65,535 bytes) and the data. If the chunk does not form a multiple of 4 by
tes (i.e., the length is not a multiple of 4) then it is implicitly padded with
zeros which are not included in the chunk length.
Security
Although encryption was not part of the original SCTP design, SCTP was designed
with features for improved security, such as 4-way handshake (compared to TCP 3way handshake) to protect against SYN flooding attacks, and large "cookies" for
association verification and authenticity.
Reliability was also a key part of the security design of SCTP. Multihoming enab
les an association to stay open even when some routes and interfaces are down. T
his is of particular importance for SIGTRAN as it carries SS7 over an IP network

using SCTP, and requires strong resilience during link outages to maintain tele
communication service even when enduring network anomalies.
SCTP is sometimes a good fingerprinting candidate. Some operating systems ship w
ith SCTP support enabled, and, as it is not as well known as TCP or UDP, it is s
ometimes overlooked in firewall and intrusion detection configurations, thus oft
en permitting probing traffic.
Implementations
The SCTP reference implementation runs on FreeBSD, Mac OS X, Microsoft Windows,
and Linux.[7]
The following operating systems implement SCTP:
AIX Version 5 and newer
Generic BSD with external patch at KAME project
Cisco IOS 12
DragonFly BSD since version 1.4
FreeBSD, version 7 and above, contains the reference SCTP implementation[8]
HP-UX, 11i v2 and above[9]
Linux kernel-based 2.4 and newer
QNX Neutrino Realtime OS,[10] 6.3.0 to 6.3.2 but not 6.4.0 and above[citatio
n needed]
Sun Solaris 10 and above[11]
VxWorks versions 6.2.x to 6.4.x, and 6.7 and newer
Third-party drivers:
Microsoft Windows:
The SctpDrv kernel driver is a port of the BSD SCTP stack to Windows[12]
Userspace library:
The SCTP library[13]
Windows XP port[14]
Oracle Java SE 7
The following applications implement SCTP:
Spot-on - P2P library[15]
GoldBug - Instant Messenger[16]
RFC history
RFC 7053 SACK-IMMEDIATELY Extension for the Stream Control Transmission Prot
ocol (updates RFC 4960)
RFC 6525 Stream Control Transmission Protocol (SCTP) Stream Reconfiguration
RFC 6458 Sockets API Extensions for the Stream Control Transmission Protocol
(SCTP)
RFC 6096 Stream Control Transmission Protocol (SCTP) Chunk Flags Registratio
n (updates RFC 4960)
RFC 5062 Security Attacks Found Against the Stream Control Transmission Prot
ocol (SCTP) and Current Countermeasures
RFC 5061 Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfi
guration
RFC 5043 Stream Control Transmission Protocol (SCTP) Direct Data Placement (
DDP) Adaptation
RFC 4960 Stream Control Transmission Protocol
RFC 4895 Authenticated Chunks for the Stream Control Transmission Protocol (
SCTP)

RFC 4820 Padding Chunk and Parameter for the Stream Control Transmission Pro
tocol (SCTP)
RFC 4460 Stream Control Transmission Protocol (SCTP) Specification Errata an
d Issues
RFC 3873 Stream Control Transmission Protocol (SCTP) Management Information
Base (MIB)
RFC 3758 Stream Control Transmission Protocol (SCTP) Partial Reliability Ext
ension
RFC 3554 On the Use of Stream Control Transmission Protocol (SCTP) with IPse
c
RFC 3436 Transport Layer Security over Stream Control Transmission Protocol
RFC 3309 Stream Control Transmission Protocol (SCTP) Checksum Change (obsole
ted by RFC 4960)
RFC 3286 An Introduction to the Stream Control Transmission Protocol
RFC 3257 Stream Control Transmission Protocol Applicability Statement
RFC 2960 Stream Control Transmission Protocol (updated by RFC 3309 and obsol
eted by RFC 4960)

S-ar putea să vă placă și