Re: Ideas for IPv6 BGP and tunnelling

Ole Troan <otroan@employees.org> Thu, 23 April 2009 13:04 UTC

Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D05003A6E2C for <ietfarch-v6ops-archive@core3.amsl.com>; Thu, 23 Apr 2009 06:04:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.127
X-Spam-Level:
X-Spam-Status: No, score=0.127 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
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 901w1xU8gUld for <ietfarch-v6ops-archive@core3.amsl.com>; Thu, 23 Apr 2009 06:04:29 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id F33C23A67CC for <v6ops-archive@lists.ietf.org>; Thu, 23 Apr 2009 06:04:28 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from <owner-v6ops@ops.ietf.org>) id 1LwyZn-000LDD-Vc for v6ops-data0@psg.com; Thu, 23 Apr 2009 13:02:51 +0000
Received: from [209.85.220.169] (helo=mail-fx0-f169.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from <ichiroumakino@gmail.com>) id 1LwyZV-000LBj-It for v6ops@ops.ietf.org; Thu, 23 Apr 2009 13:02:43 +0000
Received: by fxm17 with SMTP id 17so247685fxm.41 for <v6ops@ops.ietf.org>; Thu, 23 Apr 2009 06:02:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=zjpMiq/zmI3uOJn0hEqZ+VJg5cFnMUuTrtZ7Zjqgzeg=; b=v6YktS0AfQkRyVKILC4Kz4yaKljycZLnkJcWhr/NGSAQq/d7HcJu8MNSkHW9pxQIqS 39x+SNL4ca2DSOkW7tqvKuXqDaaRN+xAsz0gvfx5lOYuobizeOom0PtYpocOyaM3GU/G uuz5vtzHtwwmBKafWdV1AIzEWaz+Il0zcO2tU=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=rSKoKWcmAKBEBLPUDhwZYjhziqu8ytcPRnlThAy0JAiMEr2IRgGmFYqig9TlBvW8SZ +lxnlWfKCzdjRyYVF4tW8guXIxd1QShw00lLx20HLH+4H5ticX2O44A1P6+izT7BRFho 6G/PxbaTm1UOphKScO9ekoxwPryrC929qZCOw=
MIME-Version: 1.0
Received: by 10.204.121.131 with SMTP id h3mr933303bkr.66.1240491752090; Thu, 23 Apr 2009 06:02:32 -0700 (PDT)
In-Reply-To: <alpine.LRH.2.00.0904231507420.32331@netcore.fi>
References: <20090422020001.5A1013A6FF2@core3.amsl.com> <49EE7DC1.2090008@gmail.com> <49EF1EF8.1090206@spaghetti.zurich.ibm.com> <49EF91AC.1080308@gmail.com> <49EFEB97.8040807@mesh.ad.jp> <49F0396E.1040608@aaisp.net.uk> <alpine.BSF.2.00.0904231235460.48529@mignon.ki.iif.hu> <49F04E93.8090905@aaisp.net.uk> <alpine.LRH.2.00.0904231507420.32331@netcore.fi>
Date: Thu, 23 Apr 2009 15:02:32 +0200
X-Google-Sender-Auth: b0141a26c54332e0
Message-ID: <2bbba3c10904230602p44df97cfl5f5cb2c48a496364@mail.gmail.com>
Subject: Re: Ideas for IPv6 BGP and tunnelling
From: Ole Troan <otroan@employees.org>
To: Pekka Savola <pekkas@netcore.fi>
Cc: Adrian Kennard <ietf-v6ops@aaisp.net.uk>, Mohacsi Janos <mohacsi@niif.hu>, v6ops@ops.ietf.org
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

> But I fear there so far the idea hasn't gotten much traction. In fact, the
> RFC4798 predecessor documents [1] included ability to set up tunnels over
> GRE and similar non-MPLS encapsulations.  This was explicitly _removed_
> because the solution was targeted at MPLS networks, not as a general purpose
> BGP-signalled tunneling mechanism.
>
> [1] take a look at e.g:
> http://tools.ietf.org/html/draft-ooms-v6ops-bgp-tunnel-00

I thought 6PE and BGP tunnelling got split into separate documents?
obviously my memory isn't serving me right.

you can still do BGP tunnelling with existing mechanisms. PEs are
connected through a full mesh of BGP peerings. each PE has an
automatic tunnelling interface (6to4, automatic tunnelling). BGP
next-hops are the 6to4/v4compatible address. note that 6to4 is only
used internally and the sites connecting to the PE uses native
addresses.

cheers,
Ole