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