IETF Logo Mail Archive

Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon?

Alexandre Petrescu <alexandre.petrescu@gmail.com> Thu, 05 November 2015 01:11 UTC

Return-Path: <alexandre.petrescu@gmail.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B32941A0143 for <v6ops@ietfa.amsl.com>; Wed, 4 Nov 2015 17:11:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.983
X-Spam-Level:
X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7nzixi0aqsAE for <v6ops@ietfa.amsl.com>; Wed, 4 Nov 2015 17:10:58 -0800 (PST)
Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 333991B352B for <v6ops@ietf.org>; Wed, 4 Nov 2015 17:10:58 -0800 (PST)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id tA51AuIR025723 for <v6ops@ietf.org>; Thu, 5 Nov 2015 02:10:56 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 37627200EAC for <v6ops@ietf.org>; Thu, 5 Nov 2015 02:16:56 +0100 (CET)
Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 2EF43200CB8 for <v6ops@ietf.org>; Thu, 5 Nov 2015 02:16:56 +0100 (CET)
Received: from [127.0.0.1] ([132.166.84.3]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id tA51Apg4008313 for <v6ops@ietf.org>; Thu, 5 Nov 2015 02:10:54 +0100
To: v6ops@ietf.org
References: <20151103204237.GJ70452@Space.Net> <CAO42Z2xen4gCfkJphZYKfjff5ZsEn_jOf5V16OtYOYNw2VKVAA@mail.gmail.com> <CAKD1Yr3Qn48eQ1Q4VovCsr_S2+RADRZKzi9qBDoh8G2w6Be+=g@mail.gmail.com> <20151104024731.0DCDE3BC3CBF@rock.dv.isc.org> <D25FB58B.C9B04%Lee.Howard@twcable.com> <20151104104208.GL70452@Space.Net> <0EE48C9B-801D-4670-8D02-248789E2F411@umn.edu> <50027DBA-C4C2-4679-8D1C-2992BE7C3B75@delong.com> <20151104170711.GV70452@Space.Net> <ADA388DF-1E4D-43E4-B2EC-7D3E1B93FCD0@delong.com> <20151104195254.GW70452@Space.Net> <CAO42Z2wq4qtUuVLMF2hLkJH268Aij8L=5uX+vkRKbbZ-reZtiw@mail.gmail.com>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Message-ID: <563AAC9A.6050304@gmail.com>
Date: Thu, 05 Nov 2015 10:10:50 +0900
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <CAO42Z2wq4qtUuVLMF2hLkJH268Aij8L=5uX+vkRKbbZ-reZtiw@mail.gmail.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/mcYIjtEL8js8r6vaY_8SF1fL-lg>
Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon?
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
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: <https://mailarchive.ietf.org/arch/browse/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, 05 Nov 2015 01:11:02 -0000


Le 05/11/2015 05:14, Mark Smith a écrit :
[...]

> Are people who use it "successfully" aware of the limitations it imposes
> i.e. those described in RFC2993?

Which makes think the RFC 2993's section on IPv6 may need update given 
that now IPv6 NATs do exist, that 6to4 is deprecated, that ULAs 
substituted site-locals, etc.

Alex


>
> Something working doesn't mean it works well, or that the costs imposed
> by it are immediately obvious or possibly ever obvious if they're
> externalised costs, that you may indirectly pay (e.g., periodic "bubble"
> packets to keep NAT sessions alive so that VoIP handsets can receive
> calls when they're behind a NAT)
>
>  > And none of this is the trivial case of conflicting RFC1918 IP address
>  > usage in enterprise VPN scenarios.
>  >
>  > Or the case of destination NAT used for load-balancing...  (still NAT,
>  > even if not N:1 source NAPT).
>  >
>
> Breaks PMTUD because a unicast address isn't being used as a unicast
> address - an address to identify a unique destination/host.
>
> The PMTUD problems would go away if the LB terminated the TCP
> connections - which has also then restored the unicast address = unique
> (single) destination property.
>
> Regards,
> Mark.
>
>  > Gert Doering
>  >         -- NetMaster
>  > --
>  > have you enabled IPv6 on something today...?
>  >
>  > SpaceNet AG                        Vorstand: Sebastian v. Bomhard
>  > Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A.
> Grundner-Culemann
>  > D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
>  > Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279
>  >
>  > _______________________________________________
>  > v6ops mailing list
>  > v6ops@ietf.org <mailto:v6ops@ietf.org>
>  > https://www.ietf.org/mailman/listinfo/v6ops
>  >
>
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>

v2.23.0 | Report a Bug | By Email