IETF Logo Mail Archive

Re: [v6ops] RFC7849 must not recommend 64share, and must not be recommended itself to 3GPP

Alexandre Petrescu <alexandre.petrescu@gmail.com> Fri, 03 March 2017 17:56 UTC

Return-Path: <alexandre.petrescu@gmail.com>
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 132E3129435 for <v6ops@ietfa.amsl.com>; Fri, 3 Mar 2017 09:56:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.352
X-Spam-Level:
X-Spam-Status: No, score=-5.352 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 LdszRPrMGoIH for <v6ops@ietfa.amsl.com>; Fri, 3 Mar 2017 09:56:43 -0800 (PST)
Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 473521294CD for <v6ops@ietf.org>; Fri, 3 Mar 2017 09:56:42 -0800 (PST)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id v23Huerl030389; Fri, 3 Mar 2017 18:56:40 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 24A6620D61B; Fri, 3 Mar 2017 18:56:40 +0100 (CET)
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 155C3204343; Fri, 3 Mar 2017 18:56:40 +0100 (CET)
Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v23Hud7k030572; Fri, 3 Mar 2017 18:56:39 +0100
To: Ca By <cb.list6@gmail.com>, Erik Kline <ek@google.com>
References: <d1193890-0066-ad01-e521-0d9e8df065a8@gmail.com> <CAAedzxoy+=+FB=U89Fe84hDNwSdZTk0e8YYn934=V3RS3yb=DA@mail.gmail.com> <61403895-2de4-f769-2a8c-486d14a297f4@gmail.com> <CAD6AjGTgCf1qWFxcG9psVFG_nfRj2EWUoy6i7mLY_39COESsYQ@mail.gmail.com> <66d7e60b-32ec-744f-384e-ef66cc01bf8b@gmail.com> <CAD6AjGQC3rpoJU=fPgmxce-1LJHYoOdJW0FEKWa6PxyRrLyN+g@mail.gmail.com>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Message-ID: <c538a328-46ca-d2f5-afcc-395af1fdcdee@gmail.com>
Date: Fri, 03 Mar 2017 18:56:45 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: <CAD6AjGQC3rpoJU=fPgmxce-1LJHYoOdJW0FEKWa6PxyRrLyN+g@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/V6qHAV_wY4Y67xFAUdRxHyOYgQ4>
Cc: "v6ops@ietf.org" <v6ops@ietf.org>
Subject: Re: [v6ops] RFC7849 must not recommend 64share, and must not be recommended itself to 3GPP
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.17
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: Fri, 03 Mar 2017 17:56:45 -0000

Le 03/03/2017 à 18:27, Ca By a écrit :
[...]

> For your convenience, i provide this quote from it.
>
> "DHCPv6 is the best way to delegate a prefix to a LAN link.

I agree.

> The methods described in this document SHOULD only be applied when
> deploying DHCPv6 Prefix Delegation is not achievable in the 3GPP
> network and the UE."

I disagree with this formulation.  It leaves place for applying it.

The method in this document SHOULD NOT be applied because it is not a
scalable networking technology.

Please stop using it.

> "
>
> So telling anyone about 64share is by association telling them
> dhcp-pd is best.
>
> Dhcp-pd will be deployed as soon as the business case justifies it,

I think you are too much immediate business oriented.  Please have a
longer term look.

If you agreed that 64share is evil, then you may open the ways for even
more traffic into your network.

> 64share is a single LAN stop gap.

I agree.  It is single LAN, but it is not a stop gap.

It is a stop in that it stops creating the demand for scalable
networking technologies.  It stops the edge networks from growing.

> Your issue is simply one of supply and demand.

There is demand.  The supply is lacking.  Moreover, it looks as a
purposeful refusal to make supply, without any technical issue.

Are you interested in getting more traffic through your network?  Or not?

If you are interested in getting more traffic through your network then
give people more addresses - it's as simple as that.

> No ietf or 3gpp document is lacking specification for making dhcp-pd
> happen.

Were the above text corrected as I suggest, I would indeed agree with you.

Alex

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

v2.23.0 | Report a Bug | By Email