IETF Logo Mail Archive

Re: [v6ops] New Version Notification for draft-v6ops-rfc7084-bis-00.txt

<mohamed.boucadair@orange.com> Tue, 11 April 2017 06:24 UTC

Return-Path: <mohamed.boucadair@orange.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 604E8126CF9 for <v6ops@ietfa.amsl.com>; Mon, 10 Apr 2017 23:24:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.619
X-Spam-Level:
X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, 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 MXY_ODEXIT1c for <v6ops@ietfa.amsl.com>; Mon, 10 Apr 2017 23:24:04 -0700 (PDT)
Received: from relais-inet.orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB34B12709D for <v6ops@ietf.org>; Mon, 10 Apr 2017 23:24:03 -0700 (PDT)
Received: from opfedar01.francetelecom.fr (unknown [xx.xx.xx.2]) by opfednr20.francetelecom.fr (ESMTP service) with ESMTP id F2948405D6; Tue, 11 Apr 2017 08:24:01 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.63]) by opfedar01.francetelecom.fr (ESMTP service) with ESMTP id 5C6D6160087; Tue, 11 Apr 2017 08:23:50 +0200 (CEST)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM6E.corporate.adroot.infra.ftgroup ([fe80::f5a7:eab1:c095:d9ec%18]) with mapi id 14.03.0319.002; Tue, 11 Apr 2017 08:23:50 +0200
From: mohamed.boucadair@orange.com
To: "jordi.palet@consulintel.es" <jordi.palet@consulintel.es>, "v6ops@ietf.org" <v6ops@ietf.org>
Thread-Topic: New Version Notification for draft-v6ops-rfc7084-bis-00.txt
Thread-Index: AQHSq/r4UyGW5qWPi0GDxpk71O+v4qG/t9sA
Date: Tue, 11 Apr 2017 06:23:49 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B933009E4B714@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
References: <149116663909.4420.6172706668236054402.idtracker@ietfa.amsl.com> <AD1CDD40-CA24-4280-B212-F3E6C98494C2@consulintel.es>
In-Reply-To: <AD1CDD40-CA24-4280-B212-F3E6C98494C2@consulintel.es>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.168.234.5]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/IFFqqzOb6O_0OK-xAl7tBuigqxo>
Subject: Re: [v6ops] New Version Notification for draft-v6ops-rfc7084-bis-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
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: Tue, 11 Apr 2017 06:24:05 -0000

Hi Jordi, 

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : v6ops [mailto:v6ops-bounces@ietf.org] De la part de JORDI PALET
> MARTINEZ
> Envoyé : dimanche 2 avril 2017 23:48
> À : v6ops@ietf.org
> Objet : Re: [v6ops] New Version Notification for draft-v6ops-rfc7084-bis-
> 00.txt
> 
> Hi all,
> 
> I’ve submitted WG 00 for this document.
> 
> https://datatracker.ietf.org/doc/draft-v6ops-rfc7084-bis
> 
> I tried to incorporate all the inputs that I captured in the meeting,
> hopefully didn’t miss anything!, plus some minor edits.
> 
> Here is the summary for the changes:
> 
> 1) Added an annex (A) regarding the code considerations as I mention in my
> presentation.
> 2) Added an annex (B) with the changes from the original RFC7084.
> 3) Transition mechanisms in alphabetical order.
> 4) Changed the IPv6-in-IPv4 transition mechanism (6RD and 6in4) to MAY
> instead of SHOULD.

[Med] I suggest to delete these two sections: 

       5.4.2.  6in4  . . . . . . . . . . . . . . . . . . . . . . . .  16
       5.4.3.  6rd . . . . . . . . . . . . . . . . . . . . . . . . .  17

The revision of RFC7084 should IMHO focus on IPv6 features + requirements to offer IPv4 service continuity over an IPv6 network. 

> 5) Added a new section regarding IPv4 multicast support in IPv6-only-WAN.
> 6) Added some text regarding the PCP support to learn PLAT info in 464XLAT
> (RFC 7225).
> 
> I’ve one question for the WG.
> 
> In all the IPv4-in-IPv6 transition mechanisms, I’m requiring:
> “The CE router MUST support the DHCPv4-over-DHCPv6 (DHCP4o6) transport
> described in [RFC7341].”
> 
> I got a comment that this is not needed, however, my feeling is that the
> configuration of certain IPv4 parameters for the CPE, during the
> transition, are still needed and the ISP may need that.
> 
> So, the question is, what do you think about this?

[Med] DHCPv4-over-DHCPv6 is not a required for many of the techniques listed in this draft. I suggest to delete it from the text. 

> 
> Please, note that the original RFC7084 didn’t considered this (RFC7341
> didn’t exist when it was published), so the actual version is requesting
> this not just for the new supported transition mechanisms (lw4o6, MAP T/E,
> 464XLAT), but also for DS-Lite.
> 
> Please provide inputs ASAP. I will like to avoid having this document
> sleeping for too many weeks, and my goal is to publish a new version in
> about 2 weeks with any comments received.
> 

[Med] I have the following comments about the NAT requirements:

OLD:
   LW4O6-4:  The IPv6 CE router MUST perform IPv4 Network Address
             Translation (NAT) on IPv4 traffic encapsulated using lw4o6.

This one should mention port restricted NAT. FWIW, you can reuse the same wording in RFC7596:

"  An lwB4 MUST support dynamic port-restricted IPv4 address
   provisioning.  The port-set algorithm for provisioning this is
   described in Section 5.1 of [RFC7597].  For lw4o6, the number of
   a-bits SHOULD be 0, thus allocating a single contiguous port set to
   each lwB4." 


OLD:
   MAP*-4:  The IPv6 CE router MUST perform IPv4 Network Address
            Translation (NAT) on IPv4 traffic encapsulated using MAP-*.

Idem as above. Port-restricted NAT should be mentioned explicitly. You can reuse this text from RFC7597/RFC7599:

   The NAT44 implemented in the MAP CE SHOULD conform to the behavior
   and best current practices documented in [RFC4787], [RFC5508], and
   [RFC5382].  In MAP address-sharing mode (determined by the MAP
   domain / rule configuration parameters), the operation of the NAT44
   MUST be restricted to the available port numbers derived via the
   Basic Mapping Rule.

Further, I suggest to remove pointers to individual drafts. 

Thank you.

> Regards,
> Jordi
> 
> 
> -----Mensaje original-----
> De: <internet-drafts@ietf.org>
> Responder a: <internet-drafts@ietf.org>
> Fecha: domingo, 2 de abril de 2017, 22:57
> Para: Jordi Palet <jordi.palet@consulintel.es>, Jordi Palet Martinez
> <jordi.palet@consulintel.es>
> Asunto: New Version Notification for draft-v6ops-rfc7084-bis-00.txt
> 
> 
>     A new version of I-D, draft-v6ops-rfc7084-bis-00.txt
>     has been successfully submitted by Jordi Palet Martinez and posted to
> the
>     IETF repository.
> 
>     Name:		draft-v6ops-rfc7084-bis
>     Revision:	00
>     Title:		Basic Requirements for IPv6 Customer Edge Routers
>     Document date:	2017-03-31
>     Group:		Individual Submission
>     Pages:		29
>     URL:            https://www.ietf.org/internet-drafts/draft-v6ops-
> rfc7084-bis-00.txt
>     Status:         https://datatracker.ietf.org/doc/draft-v6ops-rfc7084-
> bis/
>     Htmlized:       https://tools.ietf.org/html/draft-v6ops-rfc7084-bis-00
>     Htmlized:       https://datatracker.ietf.org/doc/html/draft-v6ops-
> rfc7084-bis-00
> 
> 
>     Abstract:
>        This document specifies requirements for an IPv6 Customer Edge (CE)
>        router.  Specifically, the current version of this document focuses
>        on the basic provisioning of an IPv6 CE router and the provisioning
>        of IPv6 hosts attached to it.  The document also covers several
>        transition technologies, as required in a world where IPv4
> addresses
>        are no longer available, so hosts in the customer LANs with IPv4-
> only
>        or IPv6-only applications or devices, requiring to communicate with
>        IPv4-only services at the Internet, are able to do so.  The
> document
>        obsoletes RFC 7084.
> 
> 
> 
> 
>     Please note that it may take a couple of minutes from the time of
> submission
>     until the htmlized version and diff are available at tools.ietf.org.
> 
>     The IETF Secretariat
> 
> 
> 
> 
> 
> 
> 
> 
> **********************************************
> 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 use of the
> individual(s) named above. If you are not the intended recipient be aware
> that any disclosure, copying, distribution or use of the contents of this
> information, including attached files, is prohibited.
> 
> 
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops

v2.23.0 | Report a Bug | By Email