Re: [shim6] IPv6 multihoming

Vlad Ion <vlad.thoth@gmail.com> Mon, 25 January 2010 11:37 UTC

Return-Path: <vlad.thoth@gmail.com>
X-Original-To: shim6@core3.amsl.com
Delivered-To: shim6@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0874F3A6852 for <shim6@core3.amsl.com>; Mon, 25 Jan 2010 03:37:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.444
X-Spam-Level:
X-Spam-Status: No, score=-0.444 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_BELOW2=2.154, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mOv+u7KAlLCw for <shim6@core3.amsl.com>; Mon, 25 Jan 2010 03:37:57 -0800 (PST)
Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.152]) by core3.amsl.com (Postfix) with ESMTP id 619FC3A65A6 for <shim6@ietf.org>; Mon, 25 Jan 2010 03:37:57 -0800 (PST)
Received: by fg-out-1718.google.com with SMTP id 19so130999fgg.13 for <shim6@ietf.org>; Mon, 25 Jan 2010 03:37:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=O98ippeRVRVGhSIPqiPu7/0/cMhubVnOamPcXZtKTm4=; b=EPp0sNWZ6dejMg/BFaz6mKKeva5YWin189ManUeQKN2OnkfJfJMA3Hk4AOCeSu5uiz Vqq/OTohvj8ZZU/VOgXSBNFhg90VmFHduaj8kII9ZuX9k66WlMwMd80Q2pymhnb1pF+I 8N2W6KvahhLjRdGsJcTpzLUzLA6fUGtJ35i1w=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ZrSejPApITGfySxxRitpEC/x8ybRsKt2A5oc5sNjvafHwFNtvK1makfe9PVBjD8GZU E66Ig10buKYlMmNmuX9YMepOCS9xsNHisuTjeV4OFLLAbaUi2wlyL0ZioDK2YS6r2Raq T0e/3yjzS/UO8v3MMSSBb3h4kAMzV8cFADzc4=
MIME-Version: 1.0
Received: by 10.103.67.31 with SMTP id u31mr1109613muk.122.1264419479160; Mon, 25 Jan 2010 03:37:59 -0800 (PST)
In-Reply-To: <alpine.BSF.2.00.1001251133160.97205@mignon.ki.iif.hu>
References: <a5456ccb1001250055y26928d3ar954c1799716cd3a9@mail.gmail.com> <alpine.BSF.2.00.1001251133160.97205@mignon.ki.iif.hu>
Date: Mon, 25 Jan 2010 13:37:59 +0200
Message-ID: <a5456ccb1001250337u39a9cef3kbc40bdfd987d572d@mail.gmail.com>
From: Vlad Ion <vlad.thoth@gmail.com>
To: Mohacsi Janos <mohacsi@niif.hu>
Content-Type: multipart/alternative; boundary="0016e65c8e26e7080d047dfb9938"
Cc: v6ops@ops.ietf.org, shim6@ietf.org
Subject: Re: [shim6] IPv6 multihoming
X-BeenThere: shim6@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SHIM6 Working Group Mailing List <shim6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/shim6>, <mailto:shim6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/shim6>
List-Post: <mailto:shim6@ietf.org>
List-Help: <mailto:shim6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/shim6>, <mailto:shim6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 25 Jan 2010 11:37:59 -0000

Hi Janos,

Its simple:

1&2. Make the whole 2002:: class provider independent, not provider
aggregable so it will be dedicated for transition and multi-homing purposes
only
.
3. Just allow everybody to use their IPv4 address as PI IPv6 address. I see
no problem with that. It even makes it a lot easier for everyone to
transition their existing space to IPv6.

4. Everybody should accept /48 in IPv6 routing just because there's a clear
need to have multi-homing and you can't get around it. A simple procedure to
reduce, in time, the size of the /48 classes that are announced is for
people to slowly give back their v4 space to the RIRs as v6 expansion gains
momentum and slowly dedicate v4 and their 2002:: counterparts to
multi-homing only.

5. All ISPs and carriers that take the possible RIR offer to take free IPv6
space in exchange to announcing their v4 space in v6 format should deploy
6to4 relays. Relays should also be deployed by anyone wanting to make use of
v6 multi-homing.

I agree, 6to4 is a good solution, but the problem remains with the slow
deployment rate of IPv6. The problems IPv6 has with multihoming were the key
factor in all the deployment projects I saw that gave up eventually on IPv6
be it in telco or enterprise scenarios.

One fact remains clear as daylight: a unified solution has to be picked that
solves the multi-homing issue and a strategy has to be adopted to provide
access to the existing v4 internet in v6 form before we run out of v4 space
and more and more 2-layer deploayments of NAT will be introduced such as
carrier-grade NAT


Best regards,
Vlad Ion.

On Mon, Jan 25, 2010 at 12:48 PM, Mohacsi Janos <mohacsi@niif.hu> wrote:

>
>
>
> On Mon, 25 Jan 2010, Vlad Ion wrote:
>
>  Hi,
>>
>> For a year now whenever it comes to IPv6 telco implementations I keep
>> facing 2 problems so I was hoping you can
>> guide me towards find a group that deals with these issues or discussion
>> solutions. The 2 problems are related to
>> IPv6 multi-homing and access to the internet in IPv6 format for a quick
>> transitions from v4 to v6. Also I need some
>> guidance as to what needs to be done for a draft document proposal to be
>> created about the proposed solutions
>> mentioned bellow and who needs to be involved in this process.
>>
>> As far as multi-homing goes in IPv6 the solution discussion generated by
>> using provider-independent address space
>> like mentioned in draft-hain-ipv6-pi-addr-10 seems too complicated to
>> implement efficiently and generates a lot of
>> unnecessary work. Because IPv6 will never really be adopted by ISPs, telco
>> and enterprises until it offers a
>> feasible multi-homing solution my proposal is that some solutions are
>> redefined such as provider independent address
>> space and the 6to4 standard.
>>
>> I propose that the 6to4 ip conversion space from ipv4 addresses to
>> 2002::ipv6 space will be redefined as provider
>> independent address space. This way whoever wants to implement ipv6 with
>> multi-homing can simply redefine their
>> existing IPv4 addresses in IPv6 6to4 format and have multi-homing in ipv6.
>> Everyone already uses ipv4 multi-homing
>> with success so I see no point in defining a new addressing system for v6
>> when everyone can simply use the same v4
>> address space for multi-homing but converted in 6to4 format.
>>
>
>
> I believe this more a policy and RIR business to treat 2002:pi_ipv4 as PI
> IPV6. May I have some questions:
>
> 1. Do you want to treat differently 2002:pi_ipv4 and 2002:pa_ipv4? 2. How
> do you recognise that a particular IPv4 address PI or PA?
>
> 3. How do you prevent everybody to use their IPv4 address as PI IPv6
> address?
>
> 4. What will happen if everybody will use their single /32 IPv4 address as
> IPv6 PI address space?  Everybody should accept /48 in IPv6 routing?
>
> 5. Who will operate 6to4 relays? Every Tier1? Every ISP? Every PI customer?
> Everybody?
>
>
>
>
>> Also, another issue faced by whoever uses IPv6 is that access to the
>> internet in v6 format is limited so a proposal
>> has to be made to the RIRs to offer incentives such as free IPv6 space for
>> anyone who implements 6to4 relay routers
>> and advertises their existing v4 space in v6 format along with the newly
>> received free v6 space.
>>
>
>
> 6to4 is very good solution for interconnect IPv6 islands, but fundamentally
> relying on existing IPv4 infrastructure. In long term the IPv4 usage should
> be decreased as IPv6 fully adopted.
>
>
>
>> I believe that as long as ietf gets involved and a rfc is written on these
>> 2 proposals starting with the redefining
>> of  the provider independent address space and its inclusion in the 6to4
>> format things will be a lot more compact
>> and give some additional momentum to the IPv6 migration process.
>>
>
>
> Best Regards,
>                Janos Mohacsi