 |
Survey of IPv4 Addresses in Currently Deployed IETF General Area Standards (Obsolete) |
|
Description: This document seeks to document all usage of IPv4 addresses in currently deployed IETF General Area documented standards. |
|
Added on: 13-Apr-2003 | Downloads: 1591
|
|
A View on IPv6 Transition Architecture (Obsolete) |
|
Description: The transition from IPv4 to IPv6 and co-existence of IPv4 and IPv6 is
a subject of much debate. However, the big picture of the transition
doesn't seem to have been discussed sufficiently. Therefore,
different people have different assumptions on the process, which
makes planning the transition architecture very difficult. This memo
tries to point out some issues that will need consideration in the
transition architecture, as well as point out a few personal views on
certain transition approaches.
|
|
Added on: 31-Oct-2003 | Downloads: 1591
|
|
Forwarding Protocol 41 in NAT Boxes (Obsolete) |
|
Description: Some IPv4-only NAT boxes/routers allow the establishment of IPv6
tunnels from systems in the private LAN (using private IPv4
addresses) to routers or tunnel servers in the public Internet.
As far as we know [2] this is not a common way of using IPv6 tunnels;
the usual way is to finish the tunnel directly in a device with an
IPv4 public address.
This behavior provides a big opportunity to rapidly deploy a huge
number of IPv6 nodes and networks, without the need of new transition
mechanism. This option is very important to facilitate the IPv6
deployment when is not possible to offer native IPv6 or 6to4 [3].
From this point of view, this mechanism should be considered only as
a temporary solution until native IPv6 routers, or those that support
6to4, will become widely available.
Not all the IPv4-only NAT boxes/routers support this mechanism, but
this document describes this behavior and consequently provides hints
that should be applied in the IPv4-only NAT boxes and tunnel brokers
to facilitate it.
|
|
Added on: 31-Oct-2003 | Downloads: 1591
|
|
NAT-PT Applicability (Obsolete) |
|
Description: This document discusses the applicability RFC 2766, Network Address
Translation - Protocol Translation (NAT-PT) employing the Stateless
IP/ICMP Translation (SIIT) algorithm, as an IPv4-to-IPv6 transition
and co-existence mechanism. It highlights the NAT-PT/SIIT operational
principles and the network context for which NAT-PT was designed.
Known limitations of NAT-PT/SIIT are presented. Applicable scenarios along with guidelines for deployment are being offered.
|
|
Added on: 31-Oct-2003 | Downloads: 1651
|
|
Considerations for IPv6 Tunneling Solutions in Small End Sites (Obsolete) |
|
Description: Tunneling IPv6 packets over the IPv4 Internet played a major role in
the early stages of IPv6 deployment. This was useful because in the
early days the routers in the internet did not support IPv6.
Nowadays, tunneling is used to get across legacy equipment and ISPs
that do not support IPv6. Many different tunneling mechanisms have
been invented. This document describes the drivers for IPv6
tunneling, the general architectures of existing mechanisms, and a
set of desirable properties against which subsequent analysis of the
mechanisms may be made. The document is aimed at small end sites that may typically utilise tunneling methods in an early IPv6
deployment.
|
|
Added on: 31-Oct-2003 | Downloads: 1591
|
|
Use of VLANs for IPv4-IPv6 Coexistence in Enterprise Networks (Obsolete) |
|
Description: Ethernet VLANs are quite commonly used in enterprise networks for the
purposes of traffic segregation. This document describes how such
VLANs can be readily used to deploy IPv6 networking in an enterprise,
including the most likely scenario of subnets running IPv6 in
parallel with the existing IPv4 subnets in the enterprise. The IPv6
connectivity to the enterprise may or may not enter the site via the
same physical link.
|
|
Added on: 31-Oct-2003 | Downloads: 1591
|
|
IPv6 Implications for TCP/UDP Port Scanning (Obsolete) |
|
Description: The 128 bits of IPv6 address space is considerably bigger than the 32
bits of address space in IPv4. In particular, the IPv6 subnets to
which hosts attach will by default have 64 bits of host address
space. As a result, traditional methods of remote TCP or UDP port
scanning to discover open or running services on a host will
potentially become far less computationally feasible, due to the
larger search space in the subnet. This document discusses that
property of IPv6 subnets, and describes related issues for site
administrators of IPv6 networks to consider.
|
|
Added on: 31-Oct-2003 | Downloads: 1591
|
|
IPv4-Mapped Address API Considered Harmful (Obsolete) |
|
Description: The IPv6 Addressing Architecture [Hinden, 2003] defines the "IPv4-mapped
IPv6 address." This representation is used in the IPv6 basic API
[Gilligan, 2003] to denote IPv4 addresses using AF_INET6 sockets. The
use of IPv4-mapped addresses on AF_INET6 sockets degrades portability,
complicates IPv6 systems, and is likely to create security problems.
This document discusses each issue in turn. Finally, it proposes to
resolve these problems by recommending deprecation of this mechanism.
|
|
Added on: 31-Oct-2003 | Downloads: 1591
|
|
IPv4-Mapped Addresses on the Wire Considered Harmful (Obsolete) |
|
Description: The IPv6 Addressing Architecture [Hinden, 2003] defines the "IPv4-mapped
IPv6 address." These addresses are used in the IPv6 basic API
[Gilligan, 2003] to denote IPv4 addresses using AF_INET6 sockets. These
addresses are used in protocol proposals such as SIIT [Nordmark, 2000]
to denote IPv6 communication using AF_INET6 sockets. Therefore,
IPv4-mapped addresses have two different meanings, and they are not
distinguishable from the user-land applications.
This draft discusses security threats due to this ambiguity of
IPv4-mapped address. It also discusses threats due to the additional
complexities introduced by IPv4-mapped addresses. Finally, it proposes
to resolve these problems by forbidding protocols from using IPv4-mapped
addresses for IPv6 communications. |
|
Added on: 21-Dec-2003 | Downloads: 1591
|
|
Firewalling Considerations for IPv6 (Obsolete) |
|
Description: There are quite a few potential problems regarding firewalling or
packet filtering in IPv6 environment. These include slight ambiguity
in the IPv6 specification, problems parsing packets beyond unknown
Extension Headers and Destination Options, and introduction of end-
to-end encrypted traffic and peer-to-peer applications. There may
also be need to extend packet matching to include some Extension
Header or Destination Option fields. A number of often-raised, but
not necessary relevant, issues are also summarized. This memo
discusses these issues to raise awareness and proposes some tentative
solutions or workarounds. |
|
Added on: 01-Nov-2003 | Downloads: 1591
|
|
NAT-PT Security Considerations (Obsolete) |
|
Description: NAT-PT (RFC2766) is an address translation mechanism designed to
facilitate communications between IPv6-only and IPv4-only nodes.
This mechanism was designed to be used when tunneling transition
mechanisms cannot be used.
This document is intended to be a compilation of known security
issues related to NAT-PT and includes a few new ones. These issues
are discussed in some detail, and suggestions on how to deal with
them are included in this document. |
|
Added on: 01-Nov-2003 | Downloads: 1591
|
|
IPv6 Transition/Co-existence Security Considerations (Obsolete) |
|
Description: The transition/co-existance from IPv4 to IPv4/IPv6 causes one to
consider the security considerations of such a process. In this
memo, I try to give an overview of different aspects relating to IPv6
grouped in three categories: issues due to IPv6 protocol itself,
issues due to transition mechanisms, and issues due to IPv6
deployment.
|
|
Added on: 01-Nov-2003 | Downloads: 1591
|
|
ISP requirements for IPv6 unmanaged networks (Obsolete) |
|
Description: This document proposes to identify the elementary network functions required to
automatically deploy an IPv6 home network, i.e. with the minimum (and ideally
not a single) intervention from any administrator or any user.
The next generation Internet Protocol, IPv6, is expected to being deployed in
environments such as homes and SOHOs. However, most of the people making use
of the Internet at home don't have enough knowledge to set up on their own the
network and services. Therefore, this document exposes the requirements
necessary to ease such a deployment, from an ISP point of view. |
|
Added on: 01-Nov-2003 | Downloads: 1716
|
|
Considerations for Mobility Support in NAT-PT (Obsolete) |
|
Description: The document specifies considerations for mobility support in NAT-
PT (RFC-2766). |
|
Added on: 01-Nov-2003 | Downloads: 1591
|
|
Dual stack vs NAT-PT (Obsolete) |
|
Description: Outside of the IETF community, lot of people think that IPv4 to IPv6
transition consist merely at solving the problem of how does a v4 box
communicate with a v6 box and vice versa. Within the IETF, the dual
stack approach has long been defined. There is an ongoing discussion
to understand if translation with tools like [NAT-PT] is absolutly
needed to enable IPv6 nodes to communicate with an IPv4 node or if we
can/should mandate IPv6 nodes to also deploy an IPv4 stack if/when
they needs to communicate with IPv4 nodes. This draft is aimed at
clarifying the discussion without taking side by studying in 3 cases
the implications of mandating a dual-stack versus the implications of
deploying a translation device. |
|
Added on: 01-Nov-2003 | Downloads: 1629
|
|
Issues when translating between IPv4 and IPv6 (Obsolete) |
|
Description: During the transition from IPv4 to IPv6 both protocols will be used
simultaneously. Most nodes will support both protocols and will be
able to communicate via both IPv4 and IPv6 transport. Problems arise
when a node only supports IPv4 and it wants to communicate with a
node that only supports IPv6. Translation between the two IP
protocols might be needed in some cases. This memo discusses the
problems involved in translation between IPv4 and IPv6. |
|
Added on: 01-Nov-2003 | Downloads: 1591
|
|
Simple IPv6-in-IPv4 Tunnel Establishment Procedure (STEP) (Obsolete) |
|
Description: This memo describes a set of operational procedures, a UDP
encapsulation for configured tunnels, and one implementation
mechanism to provide a very simple and straightforward way to easily
manage IPv6-over-IPv4 configured tunnels between an ISP and a
customer. The configured tunnels work even if the IPv4 addresses
change dynamically, or are private addresses; the procedure provides
at least a /64 prefix per customer and requires no administrative
set-up. NAT traversal is also supported.
|
|
Added on: 07-Dec-2003 | Downloads: 1591
|
|
IPv6 Multicast Deployment Issues (Obsolete) |
|
Description: There are many issues concerning the deployment and implementation,
and to a lesser degree, specification of IPv6 multicast. This memo
describes known problems, trying to raise awareness. Currently,
global IPv6 interdomain multicast is completely impossible except
using SSM: there is no way to convey information about multicast
sources between PIM RPs. Site-scoped multicast is also problematic
when used alongside to global multicast because of that. A few
possible solutions are outlined or referred to. In addition, an
issue regarding link-local multicast-blocking Ethernet switches is
brought up. Finally, a feature request for MLD snooping switches is
noted. |
|
Added on: 21-Dec-2003 | Downloads: 1591
|
|
Transition Scenarios for ISP Networks (Obsolete) |
|
Description: This document describes the different types of Internet Service
Provider (ISP) networks in existence today. It will provide
design and operational considerations in delivering network
services to customers for seven specific areas in an effort to
better identify specific issues which may arise during a
transition to IPv6.
|
|
Added on: 21-Dec-2003 | Downloads: 1591
|
