Re: [v6ops] 6204bis and WAN disappearing

Rémi Després <despres.remi@laposte.net> Thu, 23 February 2012 14:30 UTC

Return-Path: <despres.remi@laposte.net>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F304421F876F for <v6ops@ietfa.amsl.com>; Thu, 23 Feb 2012 06:30:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.057
X-Spam-Level:
X-Spam-Status: No, score=-2.057 tagged_above=-999 required=5 tests=[AWL=0.241, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fjhjv88+9TjX for <v6ops@ietfa.amsl.com>; Thu, 23 Feb 2012 06:30:08 -0800 (PST)
Received: from smtpout.laposte.net (smtpout1.laposte.net [193.253.67.226]) by ietfa.amsl.com (Postfix) with ESMTP id 6541E21F876E for <v6ops@ietf.org>; Thu, 23 Feb 2012 06:30:06 -0800 (PST)
Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8502-out with ME id dSVw1i00837Y3f403SVw7y; Thu, 23 Feb 2012 15:30:05 +0100
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary="Apple-Mail-25--487122062"
From: Rémi Després <despres.remi@laposte.net>
In-Reply-To: <867F4B6A1672E541A94676D556793ACD0E9AFBC07A@MOPESMBX01.eu.thmulti.com>
Date: Thu, 23 Feb 2012 15:29:56 +0100
Message-Id: <D7BDE099-971F-4904-816D-4DF9AA53FF3B@laposte.net>
References: <CB6A5688.11F1C%jason.weil@twcable.com> <A2AF4739-4868-4538-B743-936E6E918F8A@nominum.com> <0655863C-0DA5-4FC5-9E76-38D5B11883DF@laposte.net> <18D317CD-8ED9-4C78-BB06-77A8102EFD12@nominum.com> <93E9B156-8549-40CB-A05D-5ECF55232A70@laposte.net> <4667B6CE-6E67-4613-ACDF-E1A6CD8EE1BF@nominum.com> <B455749D-09BF-4956-BF95-2F25E68F889B@laposte.net> <867F4B6A1672E541A94676D556793ACD0E9AFBC07A@MOPESMBX01.eu.thmulti.com>
To: Wuyts Carl <Carl.Wuyts@technicolor.com>
X-Mailer: Apple Mail (2.1084)
Cc: "v6ops@ietf.org" <v6ops@ietf.org>, "draft-ietf-v6ops-6204bis@tools.ietf.org" <draft-ietf-v6ops-6204bis@tools.ietf.org>
Subject: Re: [v6ops] 6204bis and WAN disappearing
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Thu, 23 Feb 2012 14:30:09 -0000

Le 2012-02-23 à 15:15, Wuyts Carl a écrit :

> Well, you have people pro and contra ULA-support.  Lots of people question the real need for ULA as well.
> I tend to agree you don’t really need it, at least not in the most common deployments (we’re mainly doing residential CPEs), although our CPE supports it today (configurable).  It indeed adds a little extra complexity, as you get more and more addresses.  In a residential scenario, you often only have 1 LAN segment, hence the need for ULA becomes less important I guess.
>  
> It’s there for people who want to use it, I guess, and can be maybe useful in some more advanced roll-outs or future home-net solutions with multiple LAN segments in the home.  As we’re deploying in a managed CPE, it’s up to our customer to either enable or not the ULA creation on the advertising interface(s).

Right.
Thanks,
RD


>  
> Regs
> Carl
>  
>  
> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Rémi Després
> Sent: donderdag 23 februari 2012 15:08
> To: Ted Lemon
> Cc: v6ops@ietf.org; draft-ietf-v6ops-6204bis@tools.ietf.org
> Subject: Re: [v6ops] 6204bis and WAN disappearing
>  
>  
> Le 2012-02-23 à 14:37, Ted Lemon a écrit :
> 
> 
> On Feb 23, 2012, at 3:26 AM, Rémi Després <despres.remi@laposte.net>
>  wrote:
> Even if it doesn't, it isn't a serious problem: the host is informed in ICMPv6 that unreachability of the destination is due to ingress or egress filtering (Type 1 code 5 per RFC4443).
> What it does next is implementation dependent, but checking its source address makes sense.
>  
> This is true, but it leaves the problem of what happens to net-local communication when this happens.
>  
> If local communication uses GUAs and, as I suggest, GUAs remain valid in case of WAN-link failure, local communication continues undisrupted.
> 
> 
>  As a reminder, the original point I was making was simply that it is in fact necessary, or at least desirable, to use ULAs for internal communication.
>  
> AFAIK, it creates more problems than it solves.
> My home site uses IPv6 without ULAs. It has no problem, and I don't know how I could use ULAs today if I wanted to.
>  
> Wanting to use ULA it in my understanding against the keep-it-simple principle.
>  
>  
> Besides, this only happens when ISPs change IPv6 prefix assignments, which is always a problem for external connections.
>  
> If this is true, it seems like a pretty big problem.   It's bad enough when ISPs change my IP address; now they are going to renumber my entire network?  
>  
> At least on a single-link, changing an IPv6 prefix isn't more complex than changing the external address of a NAT44: It breaks current connections but everything else is automatically fixed.
>  
> For instance, when Free obtained a /26 instead of its initial /32, in 2008, my IPv6 prefix changed but I didn't notice it before examining which IPv6 address (GUA) my Mac was using. 
>  
>  
> DHCP has generally been designed to prevent this: when you renew your address, you get the same address, not a different one, and when you renew your prefix, the same is true.
>  
> If I get it right, you assume that each host has both a ULA, for local sessions, and a GUA, have Internet e2e transparency.
> But, as noticed, not all hosts can do this, so that this model less workable than the current one where only GUAs are used.
>  
> RD
>  
>