|
|
|
|
|
|
|
|
|
|
| Last Update: Aug 23, 2010
|
|
|
|
|
|
|
|
|
|
|
| | |
RFC5453
02/2009
(6 p.)
pdf(2p)
|
S. Krishnan |
|
Reserved IPv6 Interface Identifiers |
|
Interface identifiers in IPv6 unicast addresses are used to identify
interfaces on a link. They are required to be unique within a
subnet. Several RFCs have specified interface identifiers or
identifier ranges that have a special meaning attached to them. An
IPv6 node autoconfiguring an interface identifier in these ranges
will encounter unexpected consequences. Since there is no
centralized repository for such reserved identifiers, this document
aims to create one.
|
|
|
| |
| List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
| | |
RFC5722
12/2009
(6 p.)
pdf(2p)
|
S. Krishnan |
|
Handling of Overlapping IPv6 Fragments |
|
The fragmentation and reassembly algorithm specified in the base IPv6
specification allows fragments to overlap. This document
demonstrates the security issues associated with allowing overlapping
fragments and updates the IPv6 specification to explicitly forbid
overlapping fragments.
|
|
|
| |
| List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
|
|
| |
| List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
| | |
RFC5942
07/2010
(11 p.)
pdf(2p)
|
H. Singh
W. Beebee
E. Nordmark |
|
IPv6 Subnet Model: The Relationship between Links and Subnet Prefixes |
|
IPv6 specifies a model of a subnet that is different than the IPv4
subnet model. The subtlety of the differences has resulted in
incorrect implementations that do not interoperate. This document
spells out the most important difference: that an IPv6 address isn't
automatically associated with an IPv6 on-link prefix. This document
also updates (partially due to security concerns caused by incorrect
implementations) a part of the definition of "on-link" from RFC 4861.
|
|
|
| |
| List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
| | |
RFC5952
08/2010
(14 p.)
pdf(2p)
|
S. Kawamura
M. Kawashima |
|
A Recommendation for IPv6 Address Text Representation |
|
As IPv6 deployment increases, there will be a dramatic increase in
the need to use IPv6 addresses in text. While the IPv6 address
architecture in Section 2.2 of RFC 4291 describes a flexible model
for text representation of an IPv6 address, this flexibility has been
causing problems for operators, system engineers, and users. This
document defines a canonical textual representation format. It does
not define a format for internal storage, such as within an
application or database. It is expected that the canonical format
will be followed by humans and systems when representing IPv6
addresses as text, but all implementations must accept and be able to
handle any legitimate RFC 4291 format.
|
|
|
| |
| List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
