You are using IPv4 from 54.92.163.188
Consulintel: logos
 
SEARCH
Are you a...?
> ISP
Keep informed, visit our
Tell us your thoughts
on IPv6 > POLL
Looking for an
IPv6 Task Force? >
Questions? > FAQS
Jump to PROJECTS
Next EVENTS
000 members
030 guests
LOGIN 
Password 
Not member yet?
Get "extras". Register
Search Bar Plug-in
Firefox      IE7
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: 647

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: 743

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: 730

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: 692

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: 677

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: 651

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: 690

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: 671

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: 783

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: 624

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: 665

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: 725

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: 633

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: 649

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: 664

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: 659

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: 684

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: 839

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: 820