You are using IPv4 from
Consulintel: logos
Are you a...?
Keep informed, visit our
Tell us your thoughts
on IPv6 > POLL
Looking for an
IPv6 Task Force? >
Questions? > FAQS
000 members
023 guests
Not member yet?
Get "extras". Register
Search Bar Plug-in
Firefox      IE7
IPv6 Address Assignment and Route Selection (Obsolete)
Description: In this document, we propose a way of address assignment and route selection suitable for "Host-Centric" or "End-to-End" multihoming, where an end node plays the main role of multihoming. The key techniques are a hierarchical address assignment and a source address based routing (SABR) for only default route entry. In our proposal, an IP address itself has some sense of routing information. We propose that an address assignment SHOULD be hierarchical. Under the conditions that address assignment is hierarchical, when someone delegates an address block, it means that he also hands routing information to his downstream at the same time. In this manner, a host which has several addresses can select which upstream to go through with by selecting its source address.
Added on: 31-Oct-2003 | Downloads: 723

Multihoming without IP Identifiers (Obsolete)
Description: This document outlines a potential solution to IPv6 multihoming in order to stimulate discussion. This proposed solution relies on verification using the existing DNS to prevent redirection attacks, while allowing locator rewriting by (border) routers, with no per-packet overhead. The solution does not introduce a "stack name" type of identifier, instead it ensures that all upper layer protocols can operate unmodified in a multihomed setting while still seeing a stable IPv6 address.
Added on: 31-Oct-2003 | Downloads: 670

Strong Identity Multihoming using 128 bit Identifiers (SIM/CBID128) (Obsolete)
Description: This document contains a rough outline of a potential solution to IPv6 multihoming in order to stimulate discussion. This proposed solution uses 126 bit identifiers which are hashes of public keys (know as Cryptographically-based Identifiers) which are created in an autonomous fashion by every host. When there is a need to verify whether a new locator should be used with an identifier than a public-key based challenge-response is used. The proposal allows locator rewriting by (border) routers, and ensures that the upper layer protocols can operate unmodified in a multihomed setting using the stable identifiers.
Added on: 31-Oct-2003 | Downloads: 683

Threats relating to IPv6 multihoming solutions (Obsolete)
Description: This document lists security threats related to IPv6 multihoming. Multihoming can introduce new opportunities to redirect packets to different, unintended IP addresses. The intent is to look at how IPv6 multihoming solutions might make the Internet less secure than the current Internet, without studying any proposed solution but instead looking at threats that are inherent in the problem itself. The threats in this document build upon the threats discovered and discussed as part of the Mobile IPv6 work.
Added on: 31-Oct-2003 | Downloads: 698

An Application of BGP Extended Community Attribute for Distributed IPv6 Site Multihoming (Obsolete)
Description: This document presents for a new IPv6 site multihoming scheme and its operational requirements. It aims at solving potential deployment problems in "IPv6 Multihoming Support at Site Exit Routers [2]" using an application of BGP extended community attribute, called multihomed community. In case of link failure in [2], basic operations to support multihoming are entirely dependent on functionality of border router in other ISPs. Hence, it causes following problems; centralized encapsulation overhead for re-routing, packet delivery along un-optimized tunneling session, and losing connectivity in case of ISP failure.
Added on: 31-Oct-2003 | Downloads: 681

IPv6 Site Multihoming: Now What? (Obsolete)
Description: ROUTING ARCHITECT'S WARNING: flagrant IPv4 site multihoming practices cause a significant increase the routing table size, change rates and instability, the tragedy of the commons by encouraging selfish routing practices, the exhaustion of the 16-bit AS number space, and may collapse the Internet interdomain routing architecture. As there has been a desire to avoid similar problems as seen with IPv4, the use of similar techniques to achieve site multihoming has been prevented operationally in IPv6. However, the long effort to proceed with other IPv6 multihoming mechanisms has produced lots of heat but little light. This memo tries to list available techniques, split the organizations to different types to separately examine their multihoming needs, to look at the immediate and short-term solutions for these organization types, and to list a few immediate action items on how to proceed with IPv6 site multihoming.
Added on: 01-Nov-2003 | Downloads: 678

Multihoming Using IPv6 Addressing Derived from AS Numbers (Obsolete)
Description: In IPv6, the current IPv4 site multihoming practises have been operationally disabled, to prevent a creation of an unmanageable swamp of more specific routes. Some argue that the lack of a comprehensive site multihoming solution is hindering the deployment of IPv6. This memo presents a few proposals for end-sites with autonomous system (AS) number to be able to derive a provider independent block of addresses from the first half of the 16-bit AS- number space. This could enable a temporary IPv6 site multihoming solution for those that already employ similar mechanisms in IPv4.
Added on: 01-Nov-2003 | Downloads: 579

Evaluating Multi-homing Support in NEMO Basic Solution (Obsolete)
Description: This draft describes and explains prerequisites for NEMO Basic to support Multi-homing. We study those prerequisites with respect to each case of a taxonomy proposed to the NEMO WG and we analyze how the NEMO basic support solution fits with them. The analysis of each case listed in this taxonomy is broken into three parts, prerequisites, comments, and solution behaviors.
Added on: 01-Nov-2003 | Downloads: 620

Choices for Multiaddressing (Obsolete)
Description: An IP Address serves the dual roles as references to a "place" on the Internet and to a host on the Internet, labeled "locator" and "identifier", respectively. Systems that use IP Addresses as identifiers cannot support dynamic changes in the mapping between the identifier and the locator. For a system to use a different IP Address pair, participants must initiate a new exchange. In the case of TCP, this means a new connection. In recent years, there have been efforts to overcome this limitation, through different approaches at different places in the Internet architecture. This paper reviews the basic requirements for support of multiaddressing (mobility and multihoming), and the efforts to support them. Barriers to adoption, administrative overhead, and operational efficiency are of particular concern.
Added on: 01-Nov-2003 | Downloads: 664

Multiple Address Service for Transport (MAST): an Extended Proposal (Obsolete)
Description: Classic Internet transport protocols use a single source IP address and a single destination IP address, as part of the identification for an individual data flow. TCP includes these in its definition of a connection and its calculation of the header checksum. Hence the transport service is tied to a particular IP address pair. This is problematic for multihomed hosts and for mobile hosts. They cannot use more than one, for any single transport association (context). Multiple Address Service for Transport (MAST) defines a mechanism that supports association of multiple IP addresses with any transport association. It requires no change to the Internet infrastructure, no change to IP modules or transport modules in the end-systems, and no new administrative effort. Instead, it defines a layer between classic IP and transport that operates only in the end systems and affects only participating hosts. Additional functionality is obtained by use of a DNS and "presence" rendezvous service.
Added on: 01-Nov-2003 | Downloads: 616

Multihomed ISPs and Policy Control (Obsolete)
Description: Policy control of next level ISPs, delegated address spaces from top level ISPs, is discussed. While global policy coodination requires top level aggregators, local policy can be controlled with next level aggregators.
Added on: 01-Nov-2003 | Downloads: 679

Multihoming using 64-bit Crypto-based IDs (Obsolete)
Description: This document outlines a potential solution to IPv6 multihoming in order to stimulate discussion. This proposal is a middle ground between the NOID and CB128 proposals. This proposed solution relies on verification the crypto-based identifier properties (using public-key crypto during uncommon operations), while allowing locator rewriting by (border) routers, with no per-packet overhead. The solution does have something which could be viewed as a "stack name" type of identifier, but this isn't exposed to upper layer protocols. Instead it ensures that all upper layer protocols can operate unmodified in a multihomed setting while still seeing a stable IPv6 address, even though the address internally consists of 64-bits worth of subnet locator plus 64-bits of crypto-based identifier.
Added on: 24-Nov-2003 | Downloads: 618

Operation of the NOID Multihoming Protocol on ISATAP Nodes (Obsolete)
Description: This document describes the operation of the NOID multihoming proposal on nodes with ISATAP interfaces. It uses the global DNS and ISATAP link-local addresses as next-hop addresses for IPv6 routes.
Added on: 07-Dec-2003 | Downloads: 649