IETF Logo Mail Archive

Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt

Rémi Després <remi.despres@free.fr> Mon, 21 March 2011 13:52 UTC

Return-Path: <remi.despres@free.fr>
X-Original-To: v6ops@core3.amsl.com
Delivered-To: v6ops@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C45B928C14B for <v6ops@core3.amsl.com>; Mon, 21 Mar 2011 06:52:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.012
X-Spam-Level:
X-Spam-Status: No, score=-0.012 tagged_above=-999 required=5 tests=[AWL=-0.522, BAYES_20=-0.74, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3]
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 Pui3VQxaUheH for <v6ops@core3.amsl.com>; Mon, 21 Mar 2011 06:52:22 -0700 (PDT)
Received: from smtp23.services.sfr.fr (smtp23.services.sfr.fr [93.17.128.20]) by core3.amsl.com (Postfix) with ESMTP id D05B428C148 for <v6ops@ietf.org>; Mon, 21 Mar 2011 06:52:21 -0700 (PDT)
Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2307.sfr.fr (SMTP Server) with ESMTP id 1D92A700009C; Mon, 21 Mar 2011 14:53:54 +0100 (CET)
Received: from [192.168.0.14] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2307.sfr.fr (SMTP Server) with ESMTP id C45C37000088; Mon, 21 Mar 2011 14:53:53 +0100 (CET)
X-SFR-UUID: 20110321135353804.C45C37000088@msfrf2307.sfr.fr
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset="iso-8859-1"
From: Rémi Després <remi.despres@free.fr>
In-Reply-To: <4D83E139.5000807@gmail.com>
Date: Mon, 21 Mar 2011 14:53:52 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <1B01509B-000B-43A8-A65F-0F772A99B479@free.fr>
References: <20110305184502.18531.25548.idtracker@localhost><5B6B2B64C9FE2A489045EEEADDAFF2C3F8B93C@XMB-RCD-109.cisco.com><C895B643-E461-4191-BAC3-EF735311F2F0@apple.com><5B6B2B64C9FE2A489045EEEADDAFF2C3F8B9B0@XMB-RCD-109.cisco.com><E76372ED-41A1-4987-9ECF-888B285DD606@apple.com><4D7E685A.80202@bogus.com><5B6B2B64C9FE2A489045EEEADDAFF2C301049872@XMB-RCD-109.cisco.com><alpine.DEB.2.00.1103152011560.4842@uplift.swm.pp.se><5B6B2B64C9FE2A489045EEEADDAFF2C301049924@XMB-RCD-109.cisco.com><4D7FE427.7000201@gmail.com><5B6B2B64C9FE2A489045EEEADDAFF2C30104A0ED@XMB-RCD-109.cisco.com><4D8260E2.2080600@gmail.com><alpine.DEB.2.00.1103172035400.4842@uplift.swm.pp.se> <alpine.DEB.2.00.1103182204030.4842@uplift.swm.pp.se> <5B6B2B64C9FE2A489045EEEADDAFF2C3010D29BC@XMB-RCD-109.cisco.com> <alpine.DEB.2.00.1103182233060.4842@uplift.swm.pp.se> <5B6B2B64C9FE2A489045EEEADDAFF2C3010D29CC@XMB-RCD-109.cisco.com> <alpine.DEB.2.00.1103182259460.4842@uplift.swm.pp.se> <4D83E139.5000807@gmail.com>
To: IPv6 Ops WG <v6ops@ietf.org>
X-Mailer: Apple Mail (2.1082)
Subject: Re: [v6ops] I-D Action:draft-ietf-v6ops-ipv6-cpe-router-bis-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 21 Mar 2011 13:52:22 -0000

Le 18 mars 2011 à 23:48, Brian E Carpenter a écrit :

> On 2011-03-19 11:03, Mikael Abrahamsson wrote:
> ...
>> When a host with an address from both PREFIX1 and PREFIX2 which resides
>> on the same LAN, whereto should it send it's outgoing packets? If
>> packets from PREFIX1 ends up on ISP2 it'll be uRPF filtered, and vice
>> versa.
> 
> Yes, that's the exit selection problem in a nutshell. Since we don't
> have a standardised solution yet we can't specify it in
> ipv6-cpe-router-bis. I expect it will have to be left for
> ipv6-cpe-router-ter.
> 
> I think the continuation of the discussion belongs on a thread
> for draft-v6ops-multihoming-without-nat66.

+1
This draft is IMHO a good starting point.

It deals with hosts that know their global addresses, and know which next hop to use depending on their global source addresses. 
For ULA networks, a complement is AFAIK needed. 

RD

 


> 
>   Brian
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops

v2.23.0 | Report a Bug | By Email