IETF Logo Mail Archive

[Softwires] updating RFC8026 with draft-ietf-v6ops-transition-ipv4aas

JORDI PALET MARTINEZ <jordi.palet@consulintel.es> Wed, 13 June 2018 16:46 UTC

Return-Path: <prvs=17023f6860=jordi.palet@consulintel.es>
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D37B7130ECE; Wed, 13 Jun 2018 09:46:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es
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 XtEWh_HkdPN9; Wed, 13 Jun 2018 09:46:13 -0700 (PDT)
Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0585130E6C; Wed, 13 Jun 2018 09:46:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1528908370; x=1529513170; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:Mime-version: Content-type:Content-transfer-encoding; bh=HkBo4+1LxcgUpt9tUPeA8 7UK+rvGiGdkdGgm07LpJKE=; b=YfnU7AfJX7j4+aqugcGUtrMk3Mtx2dooXVPK1 jhJoVfDzetlVB7D0WNz6Rv4MPoH06CYr8u0T/k7aRBAYjahm2OsrofBPbyVkMByW gXLEX54dmq4/WqTBVAoWeYGwUBgnuBu11xNf9b8NSAcmkx2+lLGQKJMSA7OIt2+g Forb2U=
X-MDAV-Result: clean
X-MDAV-Processed: mail.consulintel.es, Wed, 13 Jun 2018 18:46:10 +0200
X-Spam-Processed: mail.consulintel.es, Wed, 13 Jun 2018 18:46:10 +0200
Received: from [10.10.10.129] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005788924.msg; Wed, 13 Jun 2018 18:46:09 +0200
X-MDRemoteIP: 2001:470:1f09:495:c0a2:a933:6e2:70df
X-MDHelo: [10.10.10.129]
X-MDArrival-Date: Wed, 13 Jun 2018 18:46:09 +0200
X-Authenticated-Sender: jordi.palet@consulintel.es
X-Return-Path: prvs=17023f6860=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
User-Agent: Microsoft-MacOutlook/10.e.0.180610
Date: Wed, 13 Jun 2018 18:46:08 +0200
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: dhcwg@ietf.org, softwires@ietf.org, v6ops@ietf.org
Message-ID: <26F14014-305A-4521-A657-7CB746A4309B@consulintel.es>
Thread-Topic: updating RFC8026 with draft-ietf-v6ops-transition-ipv4aas
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/softwires/_XU0WSTksW-eo0jdMDl7B_bnSm0>
Subject: [Softwires] updating RFC8026 with draft-ietf-v6ops-transition-ipv4aas
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: softwires wg discussion list <softwires.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/softwires>, <mailto:softwires-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/softwires/>
List-Post: <mailto:softwires@ietf.org>
List-Help: <mailto:softwires-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/softwires>, <mailto:softwires-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Jun 2018 16:46:20 -0000

Hi all,



I'm sending this to Sotfwires and DHC WGs, in order to let know and seek review, but please keep the discussion only in v6ops which is responsible of this document



https://datatracker.ietf.org/doc/draft-ietf-v6ops-transition-ipv4aas/



Here is the short summary of the reasons for the update.



In order to prioritize the different IPv4-as-a-Service (in IPv6-only networks) transition mechanisms (so the ISP can "agree" with each CPE which one to use or even if none), we are using RFC8026 (in short "a DHCPv6-Based Prioritization Mechanism for IPv4-in-IPv6 CPEs"), which was developed in softwires, but it is a DHCPv6 based mechanism.



The interesting issue is that because 464XLAT don't have an option code in RFC8026, it can't be ranked the same way, and ideally it should be, as we use also that in order to facilitate the operator to "manage" each transition mechanism status to be on/off (even to different customers).



So, what we do with this update, is adding that option code for 464XLAT to the existing ones and instruct IANA about that.



If you want to understand the suggested updated and how our algorithm works, you can read directly section 3.3, 7 and 10. Of course, inputs on the complete document are welcome!



Thanks!



Regards,

Jordi

 

 




**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

v2.23.0 | Report a Bug | By Email