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

JORDI PALET MARTINEZ <jordi.palet@consulintel.es> Tue, 11 April 2017 15:04 UTC

Return-Path: <prvs=1274da9a4c=jordi.palet@consulintel.es>
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 9732612EA8C for <v6ops@ietfa.amsl.com>; Tue, 11 Apr 2017 08:04:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es 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 2MxozgEHH9Vh for <v6ops@ietfa.amsl.com>; Tue, 11 Apr 2017 08:04:27 -0700 (PDT)
Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B208412EAA6 for <v6ops@ietf.org>; Tue, 11 Apr 2017 08:04:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1491923062; x=1492527862; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=NFf/EjxYb1+mqlh95btArbBhR 5cnQjOtQMg0eUpT1pE=; b=FXz3AkcJ1GXOfAwwRJT3N2TrxKxO7gWUuKw9rpdh1 8fBcK7/Qo+HQ7raB4q6b+/NtxaiCuEHqNCwip4odNXeftcP/yB0no7MS5zOGBw7M DIj8JRoczi6rHTVijMfbCIC+7ZiMP97NZSgqw7r0XIYQ1mJ3oRguH1ujuCjJWPki l4=
DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=ebvoMTIF9v8N6zOhbVpq4gaUm7owi0wV9hZWkEuDjaOciYddpuI2udouRkLM 5wFHHsDJ5l58yK2Wk1g9JimHPl7UODbgc/zSoIZro8cLvgtv6fFC+L3Kw YidYEXOivRVk9G7OiN4dDVZgX8SDInhGhYqQGmygWu9oyTu8s2RT/k=;
X-MDAV-Processed: mail.consulintel.es, Tue, 11 Apr 2017 17:04:22 +0200
X-Spam-Processed: mail.consulintel.es, Tue, 11 Apr 2017 17:04:21 +0200
Received: from [10.10.10.99] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005406313.msg for <v6ops@ietf.org>; Tue, 11 Apr 2017 17:04:21 +0200
X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0)
X-Authenticated-Sender: jordi.palet@consulintel.es
X-HashCash: 1:20:170411:md50005406313::83UT18uk8uxEb4WW:00001D+X
X-Return-Path: prvs=1274da9a4c=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ietf.org
User-Agent: Microsoft-MacOutlook/f.20.0.170309
Date: Tue, 11 Apr 2017 17:04:17 +0200
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: "v6ops@ietf.org" <v6ops@ietf.org>
Message-ID: <CC8F352D-FD5C-4203-8E21-78B24BDAEA02@consulintel.es>
Thread-Topic: New Version Notification for draft-v6ops-rfc7084-bis-00.txt
References: <149116663909.4420.6172706668236054402.idtracker@ietfa.amsl.com> <AD1CDD40-CA24-4280-B212-F3E6C98494C2@consulintel.es> <787AE7BB302AE849A7480A190F8B933009E4B714@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
In-Reply-To: <787AE7BB302AE849A7480A190F8B933009E4B714@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Reply-To: jordi.palet@consulintel.es
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/quANhCHod351C_2t_SOmp-7e44w>
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 15:04:30 -0000

Hi again ;-)

See in-line.

Saludos,
Jordi
 

-----Mensaje original-----
De: <mohamed.boucadair@orange.com>
Responder a: <mohamed.boucadair@orange.com>
Fecha: martes, 11 de abril de 2017, 8:23
Para: "jordi.palet@consulintel.es" <jordi.palet@consulintel.es>, "v6ops@ietf.org" <v6ops@ietf.org>
Asunto: RE: New Version Notification for draft-v6ops-rfc7084-bis-00.txt

    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. 

[Jordi] I fully agree with the focus of this document to be IPv6-only access and IPv4 as an overlay service. However, it also makes sense to find a compromise, considering that this support was already required in the previous version of this document for IPv6-in-IPv4 technologies and it has actually been included in the products in the market. What I see is the situation of many ISPs that start with either dual-stack in the WAN or IPv6-in-IPv4 when dual-stack is not possible, and then they move to IPv6-only when they run-out of IPv4 addresses. Keeping 6in4 protocols support avoids the ISPs to replace the CE, but do a gradual “migration” from IPv4-only-WAN to IPv6-only-WAN. This is why I think is reasonable to keep them but only as MAY instead of SHOULD (as in the original RFC7084).
    
    > 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. 

[Jordi] I think the status is now clear from the previous emails exchanged.
   
    > 
    > 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.

[Jordi] Yes, this has been already modified in the version I’m working on. I don’t think is necessary to include the full text, just a reference to port-restricted, as we are in any case mandating the usage of each of the transition mechs RFCs.
    
    Further, I suggest to remove pointers to individual drafts. 

[Jordi] I guess you refer to draft-li-intarea-nat64-prefix-dhcp-option ? I’m still considering it … I’m keeping the text at the time being for some more discussion about that option and also this document itself.
    
    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
    



**********************************************
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.