From suresh.krishnan@ericsson.com Tue Feb 4 11:16:59 2014 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 271A21A0203 for ; Tue, 4 Feb 2014 11:16:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] 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 r587EwYetCTS for ; Tue, 4 Feb 2014 11:16:55 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 020A41A01E4 for ; Tue, 4 Feb 2014 11:16:47 -0800 (PST) X-AuditID: c6180641-b7f2f8e000002cdc-4b-52f13c9f317e Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id E2.FA.11484.F9C31F25; Tue, 4 Feb 2014 20:16:47 +0100 (CET) Received: from [142.133.113.185] (147.117.188.8) by smtps-am.internal.ericsson.com (147.117.188.84) with Microsoft SMTP Server (TLS) id 14.2.347.0; Tue, 4 Feb 2014 14:16:46 -0500 Message-ID: <52F13C9E.3050207@ericsson.com> Date: Tue, 4 Feb 2014 14:16:46 -0500 From: Suresh Krishnan User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Softwires WG Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [147.117.188.8] X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOJMWRmVeSWpSXmKPExsUyuXRPiO58m49BBi8/ylv82JJscXjZViYH Jo8lS34yeRz//JY5gCmKyyYlNSezLLVI3y6BK+PRwpNsBVNYKs5cT21gXMTcxcjJISFgInFm +gZWCFtM4sK99WwgtpDAEUaJP61GXYxcQPY2Rokne/rBingFtCVuXF7FBGKzCKhItKzeDhZn Axq0YednsLioQJhE+4WZzBD1ghInZz5hAbFFBFQlnux8ALaAWUBNYubzn2D1wgIaEod2TmOF iNtKXJhznQXClpfY/nYOM8RBmhJb13yHOlRR4sXxn0wTGAVmIVkxC0n7LCTtCxiZVzFylBan luWmGxluYgQG3jEJNscdjAs+WR5ilOZgURLn/fLWOUhIID2xJDU7NbUgtSi+qDQntfgQIxMH p1QDo9K3iqD7gloLPl1yCjqQM2Wfv/ry33/8mkxMm0z8D8u8nTz7ClfWopJTkatfnfXVnKjm vduOt2fmv5r1+kIlac1v/qZumuB+Q2RCykTWnpJrNnfZxE7VzL47n2fBOYHOkzLfIj0nXTdY Jr2qo3n26xl+Ek22X3jCfSZ46116+KC8vKdc9/Q8HSWW4oxEQy3mouJEAAdbjnkKAgAA Cc: Yong Cui Subject: [Softwires] Call for agenda items at IETF89 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 19:17:00 -0000 Hi all, The softwire WG will be meeting at the London IETF (we have been allocated a two and half hour slot) and we are in the process of setting the agenda. We will prioritize requests for working group documents and documents that have been discussed on the mailing list. Please send us your request for slots to softwire-chairs@tools.ietf.org detailing * Name of the draft * Short description of why you think the item needs to be discussed in the softwire meeting * Time required Thanks Suresh and Yong From sarikaya2012@gmail.com Wed Feb 5 10:28:40 2014 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B9D71A017D for ; Wed, 5 Feb 2014 10:28:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 h18frcE0GLdp for ; Wed, 5 Feb 2014 10:28:39 -0800 (PST) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 281501A014E for ; Wed, 5 Feb 2014 10:28:37 -0800 (PST) Received: by mail-lb0-f174.google.com with SMTP id l4so627499lbv.5 for ; Wed, 05 Feb 2014 10:28:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=9uVzlP8poGUwZ5YxXUxPlmhaliBo1Sp6SOVzLFabgwo=; b=kHuvkrc/Lkj+4hhfidD97ALpBdTXrvq/t8zAw5ssKJ9OZeOKOQF/irsjWsZQtIqZlm 2RwcfP7o7hK5wkJFVCIO/rgfdJyupffNe9oX9Y5jyfNvx8314g/FgnmxvFBMagkidOtq +ShpVhRMrJo73cJuvUeDECGjQlDvcyOLlCHwhxropQoNUo6DtJUDIfqdYJAwNWCJ+T75 Bfh25c9n6vBLmtbuMq3ZqdUYzX+s5DiX+4w3HVlsuZf71olKR/xdkS56LJWIknWRvTXt khndPW4pg0Rj7ycf+XZVzqbVPwxZdLIiYEKJd/EqVyihA+nSJ2RgaeDg/P/KIQfSlcnI kC/A== MIME-Version: 1.0 X-Received: by 10.152.205.163 with SMTP id lh3mr2135283lac.10.1391624916674; Wed, 05 Feb 2014 10:28:36 -0800 (PST) Received: by 10.114.170.193 with HTTP; Wed, 5 Feb 2014 10:28:36 -0800 (PST) In-Reply-To: <20140205182556.13019.43420.idtracker@ietfa.amsl.com> References: <20140205182556.13019.43420.idtracker@ietfa.amsl.com> Date: Wed, 5 Feb 2014 12:28:36 -0600 Message-ID: From: Behcet Sarikaya To: Softwires-wg Content-Type: multipart/alternative; boundary=001a1137fb1ad1ad3504f1acec49 Subject: [Softwires] Fwd: New Version Notification for draft-sarikaya-softwire-map-multicast-01.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: sarikaya@ieee.org List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 18:28:40 -0000 --001a1137fb1ad1ad3504f1acec49 Content-Type: text/plain; charset=ISO-8859-1 Folks, I have updated Map-E Multicast support draft as follows. Enjoy. Behcet A new version of I-D, draft-sarikaya-softwire-map-multicast-01.txt has been successfully submitted by Behcet Sarikaya and posted to the IETF repository. Name: draft-sarikaya-softwire-map-multicast Revision: 01 Title: Multicast Support for Mapping of Address and Port Protocol Document date: 2014-02-05 Group: Individual Submission Pages: 20 URL: http://www.ietf.org/internet-drafts/draft-sarikaya-softwire-map-multicast-01.txt Status: https://datatracker.ietf.org/doc/draft-sarikaya-softwire-map-multicast/ Htmlized: http://tools.ietf.org/html/draft-sarikaya-softwire-map-multicast-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-sarikaya-softwire-map-multicast-01 Abstract: This memo specifies MAP-E's multicast component so that IPv4 hosts can receive multicast data from IPv4 servers over an IPv6 network. In the encapsulation solution for encapsulation variant of Mapping of Address and Port (MAP), MAP-E, IGMP Proxy at the MAP-E Customer Edge router uses IPv4-in-IPv6 tunnel established by MAP-E to exchange IGMP messages to establish multicast state at MAP-E Border Relay so that MAP-E Border Relay can tunnel IPv4 multicast data to IPv4 hosts connected to MAP-E Customer Edge device. In the Translation Multicast solution for the translation variant of MAP, MAP-T and 4rd, IGMP messages are translated into MLD messages at the CE router which is IGMP/MLD Proxy and sent to the network in IPv6. MAP-T/4rd Border Relay does the reverse translation and joins IPv4 multicast group for MAP-T/4rd hosts. Border Relay as multicast router receives IPv4 multicast data and translates the packet into IPv6 multicast data and sends downstream on the multicast tree. Member CEs receive multicast data, translate it back to IPv4 and transmit to the hosts. 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 --001a1137fb1ad1ad3504f1acec49 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Folks, I have updated Map-E Multicast support dr= aft as follows.

Enjoy.

Behcet
=


A new version of I-D, draft-sarikaya-softwire-map-multicast-01.txt
has been successfully submitted by Behcet Sarikaya and posted to the
IETF repository.

Name: =A0 =A0 =A0 =A0 =A0 draft-sarikaya-softwire-map-multicast
Revision: =A0 =A0 =A0 01
Title: =A0 =A0 =A0 =A0 =A0Multicast Support for Mapping of Address and Port= Protocol
Document date: =A02014-02-05
Group: =A0 =A0 =A0 =A0 =A0Individual Submission
Pages: =A0 =A0 =A0 =A0 =A020
URL: =A0 =A0 =A0 =A0 =A0 =A0http://www.= ietf.org/internet-drafts/draft-sarikaya-softwire-map-multicast-01.txt Status: =A0 =A0 =A0 =A0 https://datatracker.ietf= .org/doc/draft-sarikaya-softwire-map-multicast/
Htmlized: =A0 =A0 =A0 http://tools.ietf.org/html/dra= ft-sarikaya-softwire-map-multicast-01
Diff: =A0 =A0 =A0 =A0 =A0 http://www.ietf.or= g/rfcdiff?url2=3Ddraft-sarikaya-softwire-map-multicast-01

Abstract:
=A0 =A0This memo specifies MAP-E's multicast component so that IPv4 hos= ts
=A0 =A0can receive multicast data from IPv4 servers over an IPv6 network. =A0 =A0In the encapsulation solution for encapsulation variant of Mapping o= f
=A0 =A0Address and Port (MAP), MAP-E, IGMP Proxy at the MAP-E Customer Edge=
=A0 =A0router uses IPv4-in-IPv6 tunnel established by MAP-E to exchange IGM= P
=A0 =A0messages to establish multicast state at MAP-E Border Relay so that<= br> =A0 =A0MAP-E Border Relay can tunnel IPv4 multicast data to IPv4 hosts
=A0 =A0connected to MAP-E Customer Edge device. =A0In the Translation
=A0 =A0Multicast solution for the translation variant of MAP, MAP-T and 4rd= ,
=A0 =A0IGMP messages are translated into MLD messages at the CE router whic= h
=A0 =A0is IGMP/MLD Proxy and sent to the network in IPv6. =A0MAP-T/4rd Bord= er
=A0 =A0Relay does the reverse translation and joins IPv4 multicast group fo= r
=A0 =A0MAP-T/4rd hosts. =A0Border Relay as multicast router receives IPv4 =A0 =A0multicast data and translates the packet into IPv6 multicast data an= d
=A0 =A0sends downstream on the multicast tree. =A0Member CEs receive multic= ast
=A0 =A0data, translate it back to IPv4 and transmit to the hosts.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


--001a1137fb1ad1ad3504f1acec49-- From internet-drafts@ietf.org Thu Feb 6 09:27:17 2014 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79C1E1A01BD; Thu, 6 Feb 2014 09:27:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 yoxmmIMapyWS; Thu, 6 Feb 2014 09:27:16 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 20A801A01CE; Thu, 6 Feb 2014 09:27:16 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140206172715.4006.31443.idtracker@ietfa.amsl.com> Date: Thu, 06 Feb 2014 09:27:15 -0800 Cc: softwires@ietf.org Subject: [Softwires] I-D Action: draft-ietf-softwire-lw4over6-04.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 17:27:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Softwires Working Group of the IETF. Title : Lightweight 4over6: An Extension to the DS-Lite Architecture Authors : Yong Cui Qiong Sun Mohamed Boucadair Tina Tsou Yiu L. Lee Ian Farrer Filename : draft-ietf-softwire-lw4over6-04.txt Pages : 21 Date : 2014-02-06 Abstract: Dual-Stack Lite (RFC 6333) describes an architecture for transporting IPv4 packets over an IPv6 network. This document specifies an extension to DS-Lite called Lightweight 4over6 which moves the Network Address and Port Translation (NAPT) function from the centralized DS-Lite tunnel concentrator to the tunnel client located in the Customer Premises Equipment (CPE). This removes the requirement for a Carrier Grade NAT function in the tunnel concentrator and reduces the amount of centralized state that must be held to a per-subscriber level. In order to delegate the NAPT function and make IPv4 Address sharing possible, port-restricted IPv4 addresses are allocated to the CPEs. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-softwire-lw4over6/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-softwire-lw4over6-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-softwire-lw4over6-04 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Thu Feb 6 23:47:41 2014 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7C5B1A05C7; Thu, 6 Feb 2014 23:47:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 dIU-yU5aOh_0; Thu, 6 Feb 2014 23:47:38 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F29B1A05BD; Thu, 6 Feb 2014 23:47:38 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140207074738.9960.68519.idtracker@ietfa.amsl.com> Date: Thu, 06 Feb 2014 23:47:38 -0800 Cc: softwires@ietf.org Subject: [Softwires] I-D Action: draft-ietf-softwire-lw4over6-05.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 07:47:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Softwires Working Group of the IETF. Title : Lightweight 4over6: An Extension to the DS-Lite Architecture Authors : Yong Cui Qiong Sun Mohamed Boucadair Tina Tsou Yiu L. Lee Ian Farrer Filename : draft-ietf-softwire-lw4over6-05.txt Pages : 21 Date : 2014-02-06 Abstract: Dual-Stack Lite (RFC 6333) describes an architecture for transporting IPv4 packets over an IPv6 network. This document specifies an extension to DS-Lite called Lightweight 4over6 which moves the Network Address and Port Translation (NAPT) function from the centralized DS-Lite tunnel concentrator to the tunnel client located in the Customer Premises Equipment (CPE). This removes the requirement for a Carrier Grade NAT function in the tunnel concentrator and reduces the amount of centralized state that must be held to a per-subscriber level. In order to delegate the NAPT function and make IPv4 Address sharing possible, port-restricted IPv4 addresses are allocated to the CPEs. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-softwire-lw4over6/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-softwire-lw4over6-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-softwire-lw4over6-05 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From swmike@swm.pp.se Fri Feb 7 01:17:49 2014 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF0DA1A0090 for ; Fri, 7 Feb 2014 01:17:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.386 X-Spam-Level: X-Spam-Status: No, score=-4.386 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] 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 llZfPPwfb07f for ; Fri, 7 Feb 2014 01:17:48 -0800 (PST) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) by ietfa.amsl.com (Postfix) with ESMTP id 99BB21A00AB for ; Fri, 7 Feb 2014 01:17:47 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 759C69C; Fri, 7 Feb 2014 10:17:44 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 70F139A for ; Fri, 7 Feb 2014 10:17:44 +0100 (CET) Date: Fri, 7 Feb 2014 10:17:44 +0100 (CET) From: Mikael Abrahamsson To: softwires@ietf.org In-Reply-To: <20140207074738.9960.68519.idtracker@ietfa.amsl.com> Message-ID: References: <20140207074738.9960.68519.idtracker@ietfa.amsl.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-lw4over6-05.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 09:17:50 -0000 On Thu, 6 Feb 2014, internet-drafts@ietf.org wrote: > Filename : draft-ietf-softwire-lw4over6-05.txt > Pages : 21 > Date : 2014-02-06 I have re-read this document in its entirety and I think it's in good shape after the recent edits. I support proceeding this document for the next step, whatever that is :) -- Mikael Abrahamsson email: swmike@swm.pp.se From simon.perreault@viagenie.ca Fri Feb 7 05:54:37 2014 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D060F1A03C3 for ; Fri, 7 Feb 2014 05:54:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] 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 ZfzQn364KnbU for ; Fri, 7 Feb 2014 05:54:36 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 1525F1A00F6 for ; Fri, 7 Feb 2014 05:54:36 -0800 (PST) Received: from porto.nomis80.org (ringo.viagenie.ca [IPv6:2620:0:230:c000:3e97:eff:fe0b:dd8a]) by jazz.viagenie.ca (Postfix) with ESMTPSA id CF2A4403B0 for ; Fri, 7 Feb 2014 08:54:35 -0500 (EST) Message-ID: <52F4E59B.60402@viagenie.ca> Date: Fri, 07 Feb 2014 08:54:35 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: softwires@ietf.org References: <20140207074738.9960.68519.idtracker@ietfa.amsl.com> In-Reply-To: <20140207074738.9960.68519.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-lw4over6-05.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 13:54:38 -0000 This part is still not OK: > 5.2.1. Changes to RFC2473 and RFC6333 Fragmentation Behaviour > > On receiving an encapsulated packet containing an IPv4 fragment, the > lwB4 SHOULD wait until all other fragments have been received and de- > capsulated. The original packet is then re-assembled before > performing NAPT. This is necessary because layer-4 protocol > information is only present in the first fragment. I'll repeat what I wrote on 2014-01-16: It's possible to do it correctly without waiting for all fragments (e.g., what Cisco calls "virtual reassembly"). My suggestion would be to steal the very carefully written text from RFC 6146, page 19. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From ian.farrer@telekom.de Fri Feb 7 08:01:14 2014 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FC421A03CC for ; Fri, 7 Feb 2014 08:01:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.785 X-Spam-Level: X-Spam-Status: No, score=-2.785 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.535] 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 8D6yuIxPdRX0 for ; Fri, 7 Feb 2014 08:01:12 -0800 (PST) Received: from tcmail13.telekom.de (tcmail13.telekom.de [80.149.113.165]) by ietfa.amsl.com (Postfix) with ESMTP id 94A521A03C7 for ; Fri, 7 Feb 2014 08:01:12 -0800 (PST) Received: from he110890.emea1.cds.t-internal.com ([10.134.92.131]) by tcmail11.telekom.de with ESMTP/TLS/AES128-SHA; 07 Feb 2014 17:01:11 +0100 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by he110890 ([10.134.92.131]) with mapi; Fri, 7 Feb 2014 17:01:10 +0100 From: To: , Date: Fri, 7 Feb 2014 17:01:06 +0100 Thread-Topic: [Softwires] I-D Action: draft-ietf-softwire-lw4over6-05.txt Thread-Index: Ac8kHdH/ivWMaJ6RRTej0FNTDxVXpw== Message-ID: References: <20140207074738.9960.68519.idtracker@ietfa.amsl.com> <52F4E59B.60402@viagenie.ca> In-Reply-To: <52F4E59B.60402@viagenie.ca> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-lw4over6-05.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 16:01:14 -0000 Hi Simon, See inline. Cheers, Ian >This part is still not OK: > >> 5.2.1. Changes to RFC2473 and RFC6333 Fragmentation Behaviour >>=20 >> On receiving an encapsulated packet containing an IPv4 fragment, the >> lwB4 SHOULD wait until all other fragments have been received and de- >> capsulated. The original packet is then re-assembled before >> performing NAPT. This is necessary because layer-4 protocol >> information is only present in the first fragment. > >I'll repeat what I wrote on 2014-01-16: > >It's possible to do it correctly without waiting for all fragments >(e.g., what Cisco calls "virtual reassembly"). My suggestion would be to >steal the very carefully written text from RFC 6146, page 19. [ian] My apologies - I wasn=B9t familiar with the Cisco feature that you mentioned, so researched it and all of the information that I=B9ve found is the Cisco VFR (virtual fragment reassembly). I thought that I=B9d captured this with the RFC4459 reference, but it looks like it=B9s also covering the tiny fragment attacks described in RFC1858. What about: 5.2.1. Changes to RFC2473 and RFC6333 Fragmentation Behaviour On receiving an encapsulated packet containing an IPv4 fragment, the lwB4 SHOULD wait until all other fragments have been received and de- capsulated. The original packet is then re-assembled before performing NAPT. This is necessary because layer-4 protocol information is only present in the first fragment. However, as this provides potential security flaws (as discussed in [RFC1858] and [RFC4459] Section 5) it is RECOMMENDED that the lwB4 implements mechanisms to prevent against tiny fragment attacks and buffer memory exhaustion. Section 3.4 of [RFC6146] describes potential mitigations for these attacks which could be adapted for use here. From simon.perreault@viagenie.ca Fri Feb 7 09:12:55 2014 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEFC31ACC89 for ; Fri, 7 Feb 2014 09:12:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] 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 QBYLD-RfJzrn for ; Fri, 7 Feb 2014 09:12:53 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 5FF451AC497 for ; Fri, 7 Feb 2014 09:12:53 -0800 (PST) Received: from porto.nomis80.org (ringo.viagenie.ca [IPv6:2620:0:230:c000:3e97:eff:fe0b:dd8a]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 1FD4540415; Fri, 7 Feb 2014 12:12:53 -0500 (EST) Message-ID: <52F51414.1070604@viagenie.ca> Date: Fri, 07 Feb 2014 12:12:52 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: ian.farrer@telekom.de, softwires@ietf.org References: <20140207074738.9960.68519.idtracker@ietfa.amsl.com> <52F4E59B.60402@viagenie.ca> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-lw4over6-05.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 17:12:55 -0000 Le 2014-02-07 11:01, ian.farrer@telekom.de a écrit : >> This part is still not OK: >> >>> 5.2.1. Changes to RFC2473 and RFC6333 Fragmentation Behaviour >>> >>> On receiving an encapsulated packet containing an IPv4 fragment, the >>> lwB4 SHOULD wait until all other fragments have been received and de- >>> capsulated. The original packet is then re-assembled before >>> performing NAPT. This is necessary because layer-4 protocol >>> information is only present in the first fragment. >> >> I'll repeat what I wrote on 2014-01-16: >> >> It's possible to do it correctly without waiting for all fragments >> (e.g., what Cisco calls "virtual reassembly"). My suggestion would be to >> steal the very carefully written text from RFC 6146, page 19. > > [ian] My apologies - I wasn¹t familiar with the Cisco feature that you > mentioned, so researched it and all of the information that I¹ve found is > the Cisco VFR (virtual fragment reassembly). It's just an example. Maybe not well chosen, since I can't find documentation explaining exactly the behaviour I think it implements. Anyway, the point is that waiting until all fragments have been received is not necessary. For example, it's 100% correct to only wait until fragments sufficient for knowing the L4 info have been received. That will often be just the first fragment. So you buffer fragments until the first one has been received (just in case there is packet reordering, often the first fragment you receive will be the packet's first fragment), you extract the L4 info, you keep that info in memory, and you forward/NAT the fragment. For the following fragments, you just look up the stored L4 info from memory. There is no actual reassembly. > I thought that I¹d captured > this with the RFC4459 reference, but it looks like it¹s also covering the > tiny fragment attacks described in RFC1858. > > What about: > > 5.2.1. Changes to RFC2473 and RFC6333 Fragmentation Behaviour > > > On receiving an encapsulated packet containing an IPv4 fragment, the > lwB4 SHOULD wait until all other fragments have been received and de- > capsulated. No, the point is that it's not necessary to wait until all other fragments have been received. I'll say it again: my suggestion would be to steal the very carefully written text from RFC 6146, page 19. (We spent *many* emails coming up with that text, and I don't want to do this again!) Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From ssenthil@cisco.com Fri Feb 7 11:17:08 2014 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E99981ACCE8 for ; Fri, 7 Feb 2014 11:17:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.036 X-Spam-Level: X-Spam-Status: No, score=-15.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 ZzLGwZjbQ83m for ; Fri, 7 Feb 2014 11:17:06 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 19FDD1A0416 for ; Fri, 7 Feb 2014 11:17:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3345; q=dns/txt; s=iport; t=1391800626; x=1393010226; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=7kCF6XaFhfK1PVY9gqVECZcF57NlXqinPxVKfPqB2qw=; b=YtXIMgAl56Z5lnPMHF5Aw/5G1RkZLfLF8NxflrfsGni7OT2IlwoUfs9i NCQfLyyqAgdSGRc10zhLoSeWe3LTjv6rzx4MaWuoWzVnquBy+/yYMQ/za fEAI00fmupmkVUlWJxDzgz+cRbY3Ga0sMMzOcPIXG1ZFa2h6abJs5ybmC E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAM8v9VKtJV2a/2dsb2JhbABZgww4V74ZT4EOFnSCJQEBAQMBAQEBJEcbAgEIRicLJQIEARKHfQgNzBcXjwSEOASUQoNpgTKQb4Mtgio X-IronPort-AV: E=Sophos;i="4.95,802,1384300800"; d="scan'208";a="302635420" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-6.cisco.com with ESMTP; 07 Feb 2014 19:17:05 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s17JH5eb031646 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 7 Feb 2014 19:17:05 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.177]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0123.003; Fri, 7 Feb 2014 13:17:05 -0600 From: "Senthil Sivakumar (ssenthil)" To: Simon Perreault , "ian.farrer@telekom.de" , "softwires@ietf.org" Thread-Topic: [Softwires] I-D Action: draft-ietf-softwire-lw4over6-05.txt Thread-Index: AQHPI9js3AHykHFYkECOgnbgISaLTJqqNSeAgAAjWgCAABQNAP//zuCA Date: Fri, 7 Feb 2014 19:17:04 +0000 Message-ID: References: <20140207074738.9960.68519.idtracker@ietfa.amsl.com> <52F4E59B.60402@viagenie.ca> <52F51414.1070604@viagenie.ca> In-Reply-To: <52F51414.1070604@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.82.234.28] Content-Type: text/plain; charset="windows-1254" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-lw4over6-05.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 19:17:08 -0000 On 2/7/14 12:12 PM, "Simon Perreault" wrote: >Le 2014-02-07 11:01, ian.farrer@telekom.de a =E9crit : >>> This part is still not OK: >>> >>>> 5.2.1. Changes to RFC2473 and RFC6333 Fragmentation Behaviour >>>> >>>> On receiving an encapsulated packet containing an IPv4 fragment, >>>>the >>>> lwB4 SHOULD wait until all other fragments have been received and >>>>de- >>>> capsulated. The original packet is then re-assembled before >>>> performing NAPT. This is necessary because layer-4 protocol >>>> information is only present in the first fragment. >>> >>> I'll repeat what I wrote on 2014-01-16: >>> >>> It's possible to do it correctly without waiting for all fragments >>> (e.g., what Cisco calls "virtual reassembly"). My suggestion would be >>>to >>> steal the very carefully written text from RFC 6146, page 19. >>=20 >> [ian] My apologies - I wasn=B9t familiar with the Cisco feature that you >> mentioned, so researched it and all of the information that I=B9ve found >>is >> the Cisco VFR (virtual fragment reassembly). > >It's just an example. Maybe not well chosen, since I can't find >documentation explaining exactly the behaviour I think it implements. > >Anyway, the point is that waiting until all fragments have been received >is not necessary. For example, it's 100% correct to only wait until >fragments sufficient for knowing the L4 info have been received. That >will often be just the first fragment. So you buffer fragments until the >first one has been received (just in case there is packet reordering, >often the first fragment you receive will be the packet's first >fragment), you extract the L4 info, you keep that info in memory, and >you forward/NAT the fragment. For the following fragments, you just look >up the stored L4 info from memory. There is no actual reassembly. I agree, there is no need to wait for all the fragments if all you need is the l4 info. Just save the context and l4 info for the first fragment. If you get out of order fragments, and The first fragment is not received, the non-first fragments would have to be buffered until the First fragment arrives.. Thanks Senthil > >> I thought that I=B9d captured >> this with the RFC4459 reference, but it looks like it=B9s also covering >>the >> tiny fragment attacks described in RFC1858. >>=20 >> What about: >>=20 >> 5.2.1. Changes to RFC2473 and RFC6333 Fragmentation Behaviour >>=20 >>=20 >> On receiving an encapsulated packet containing an IPv4 fragment, the >> lwB4 SHOULD wait until all other fragments have been received and de- >> capsulated. > >No, the point is that it's not necessary to wait until all other >fragments have been received. > >I'll say it again: my suggestion would be to steal the very carefully >written text from RFC 6146, page 19. (We spent *many* emails coming up >with that text, and I don't want to do this again!) > >Simon >--=20 >DTN made easy, lean, and smart --> http://postellation.viagenie.ca >NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca >STUN/TURN server --> http://numb.viagenie.ca >_______________________________________________ >Softwires mailing list >Softwires@ietf.org >https://www.ietf.org/mailman/listinfo/softwires From ian.farrer@telekom.de Mon Feb 10 03:46:18 2014 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33C5E1A0821 for ; Mon, 10 Feb 2014 03:46:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.798 X-Spam-Level: X-Spam-Status: No, score=-2.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548] 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 wnVDijmhe16Y for ; Mon, 10 Feb 2014 03:46:14 -0800 (PST) Received: from tcmail13.telekom.de (tcmail13.telekom.de [80.149.113.165]) by ietfa.amsl.com (Postfix) with ESMTP id DAC541A0828 for ; Mon, 10 Feb 2014 03:46:13 -0800 (PST) Received: from he110889.emea1.cds.t-internal.com ([10.134.92.130]) by tcmail11.telekom.de with ESMTP/TLS/AES128-SHA; 10 Feb 2014 12:46:11 +0100 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE110889.emea1.cds.t-internal.com ([fe80::841f:f92c:15ca:8526%16]) with mapi; Mon, 10 Feb 2014 12:46:11 +0100 From: To: , , Date: Mon, 10 Feb 2014 12:46:17 +0100 Thread-Topic: [Softwires] I-D Action: draft-ietf-softwire-lw4over6-05.txt Thread-Index: Ac8mVbFWYhg18FK/TdCNInPNv62o9g== Message-ID: References: <20140207074738.9960.68519.idtracker@ietfa.amsl.com> <52F4E59B.60402@viagenie.ca> <52F51414.1070604@viagenie.ca> In-Reply-To: <52F51414.1070604@viagenie.ca> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="euc-kr" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-lw4over6-05.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 11:46:18 -0000 SGkgU2ltb24gLyBTZW50aGlsLA0KDQpQbGVhc2Ugc2VlIGJlbG93Lg0KDQpDaGVlcnMsDQpJYW4N Cg0KPj4+DQo+Pj4gSXQncyBwb3NzaWJsZSB0byBkbyBpdCBjb3JyZWN0bHkgd2l0aG91dCB3YWl0 aW5nIGZvciBhbGwgZnJhZ21lbnRzDQo+Pj4gKGUuZy4sIHdoYXQgQ2lzY28gY2FsbHMgInZpcnR1 YWwgcmVhc3NlbWJseSIpLiBNeSBzdWdnZXN0aW9uIHdvdWxkIGJlDQo+Pj50bw0KPj4+IHN0ZWFs IHRoZSB2ZXJ5IGNhcmVmdWxseSB3cml0dGVuIHRleHQgZnJvbSBSRkMgNjE0NiwgcGFnZSAxOS4N Cj4+IA0KPj4gW2lhbl0gTXkgYXBvbG9naWVzIC0gSSB3YXNuqfZ0IGZhbWlsaWFyIHdpdGggdGhl IENpc2NvIGZlYXR1cmUgdGhhdCB5b3UNCj4+IG1lbnRpb25lZCwgc28gcmVzZWFyY2hlZCBpdCBh bmQgYWxsIG9mIHRoZSBpbmZvcm1hdGlvbiB0aGF0IEmp9nZlIGZvdW5kDQo+PmlzDQo+PiB0aGUg Q2lzY28gVkZSICh2aXJ0dWFsIGZyYWdtZW50IHJlYXNzZW1ibHkpLg0KPg0KPkl0J3MganVzdCBh biBleGFtcGxlLiBNYXliZSBub3Qgd2VsbCBjaG9zZW4sIHNpbmNlIEkgY2FuJ3QgZmluZA0KPmRv Y3VtZW50YXRpb24gZXhwbGFpbmluZyBleGFjdGx5IHRoZSBiZWhhdmlvdXIgSSB0aGluayBpdCBp bXBsZW1lbnRzLg0KDQpbaWFuXSBUaGF0oa9zIHdoYXQgdGhyZXcgbWUuDQoNCk9LLCB3aGF0IGFi b3V0IChmb3IgdGhlIHdob2xlIG9mIHRoZSBsd0I0IGZyYWdtZW50YXRpb24gc2VjdGlvbik6DQoN CjUuMi4xLiAgQ2hhbmdlcyB0byBSRkMyNDczIGFuZCBSRkM2MzMzIEZyYWdtZW50YXRpb24gQmVo YXZpb3VyDQoNCjUuMi4xLjEuIFByb2Nlc3Npbmcgb2YgSW5jb21pbmcgSVB2NCBGcmFnbWVudHMg RW5jYXBzdWxhdGVkIGluIElQdjYNCg0KICAgDQogICBUaGUgZm9sbG93aW5nIHByb2Nlc3MgZm9y IGhhbmRsaW5nIGZyYWdtZW50ZWQgcGFja2V0cyBpcyB0YWtlbiBmcm9tDQogICBTZWN0aW9uIDMu NCBvZiBbUkZDNjE0Nl0sIGFkYXB0ZWQgZm9yIHVzZSB3aXRoIGZyYWdtZW50YXRpb24gb2YNCiAg IGVuY2Fwc3VsYXRlZCBJUHY0IHR1bm5lbCB0cmFmZmljIGFuZCBOQVBUNDQuDQoNCiAgIA0KICAg T24gcmVjZWl2aW5nIGFuIGVuY2Fwc3VsYXRlZCBwYWNrZXQgY29udGFpbmluZyBhbiBJUHY0IGZy YWdtZW50LA0KICAgdGhlbiBtb3JlIHByb2Nlc3NpbmcgbWF5IGJlIG5lZWRlZCB0aGFuIGZvciBu b24tZnJhZ21lbnRlZCBwYXlsb2Fkcy4NCiAgIFRoaXMgc3BlY2lmaWNhdGlvbiBsZWF2ZXMgb3Bl biB0aGUgZXhhY3QgZGV0YWlscyBvZiBob3cgdGhlIGx3QjQgaGFuZGxlcw0KICAgaW5jb21pbmcg ZW5jYXBzdWxhdGVkIElQdjYgcGFja2V0cyBjb250YWluaW5nIElQdjQgZnJhZ21lbnRzLCBhbmQN CiAgIHNpbXBseSByZXF1aXJlcyB0aGF0IHRoZSBleHRlcm5hbCBiZWhhdmlvciBvZiB0aGUgbHdC NCBiZSBjb21wbGlhbnQNCndpdGggDQp0aGUgZm9sbG93aW5nIGNvbmRpdGlvbnM6IFRoZSBsd0I0 IE1VU1QgaGFuZGxlIGVuY2Fwc3VsYXRlZCBJUHY0DQpmcmFnbWVudHMuICBJbiBwYXJ0aWN1bGFy LCB0aGUgbHdCNCBNVVNUIGhhbmRsZSBmcmFnbWVudHMgYXJyaXZpbmcNCm91dCBvZiBvcmRlciwg Y29uZGl0aW9uYWwgb24gdGhlIGZvbGxvd2luZzoNCg0KICAgICAgDQogICAgICAqICBUaGUgbHdC NCBNVVNUIGxpbWl0IHRoZSBhbW91bnQgb2YgcmVzb3VyY2VzIGRldm90ZWQgdG8gdGhlDQogICAg ICAgICBzdG9yYWdlIG9mIGZyYWdtZW50ZWQgcGFja2V0cyBpbiBvcmRlciB0byBwcm90ZWN0IGZy b20gRG9TDQogICAgICAgICBhdHRhY2tzLg0KICAgICAgKiAgQXMgbG9uZyBhcyB0aGUgbHdCNCBo YXMgYXZhaWxhYmxlIHJlc291cmNlcywgdGhlIGx3QjQgTVVTVA0KICAgICAgICAgYWxsb3cgdGhl IGZyYWdtZW50cyB0byBhcnJpdmUgb3ZlciBhIHRpbWUgaW50ZXJ2YWwuICBUaGUgdGltZQ0KICAg ICAgICAgaW50ZXJ2YWwgU0hPVUxEIGJlIGNvbmZpZ3VyYWJsZSBhbmQgdGhlIGRlZmF1bHQgdmFs dWUgTVVTVCBiZQ0KICAgICAgICAgb2YgYXQgbGVhc3QgRlJBR01FTlRfTUlOLg0KICAgICAgKiAg VGhlIGx3QjQgTUFZIHJlcXVpcmUgdGhhdCB0aGUgVURQLCBUQ1AsIG9yIElDTVAgaGVhZGVyIGJl DQogICAgICAgICBjb21wbGV0ZWx5IGNvbnRhaW5lZCB3aXRoaW4gdGhlIGZyYWdtZW50IHRoYXQg Y29udGFpbnMgZnJhZ21lbnQNCiAgICAgICAgIG9mZnNldCBlcXVhbCB0byB6ZXJvLg0KDQogICAg ICAgICANCiAgICAgIEZvciBpbmNvbWluZyBwYWNrZXRzIGNhcnJ5aW5nIFRDUCBvciBVRFAgSVB2 NCBmcmFnbWVudHMgd2l0aCBhDQpub24temVybw0KICAgICAgY2hlY2tzdW0sIGFmdGVyIGRlLWNh cHN1bGF0aW9uLCB0aGUgbHdCNCBNQVkgZWxlY3QgdG8gcXVldWUgdGhlDQogICAgICBmcmFnbWVu dHMgYXMgdGhleSBhcnJpdmUgYW5kIHBlcmZvcm0gTkFQVDQ0IG9uIGFsbCBmcmFnbWVudHMgYXQN CiAgICAgIHRoZSBzYW1lIHRpbWUuICBJbiB0aGlzIGNhc2UsIHRoZSBpbmNvbWluZyA1LXR1cGxl IGlzIGRldGVybWluZWQNCiAgICAgIGJ5IGV4dHJhY3RpbmcgdGhlIGFwcHJvcHJpYXRlIGZpZWxk cyBmcm9tIHRoZSByZWNlaXZlZCBwYWNrZXQuDQogICAgICBBbHRlcm5hdGl2ZWx5LCBhIGx3QjQg TUFZIHRyYW5zbGF0ZSB0aGUgZGUtY2Fwc3VsYXRlZCBmcmFnbWVudHMgYXMNCiAgICAgIHRoZXkg YXJyaXZlLCBieSBzdG9yaW5nICBpbmZvcm1hdGlvbiB0aGF0IGFsbG93cyBpdCB0byBjb21wdXRl IHRoZQ0KICAgICAgNS10dXBsZSBmb3IgZnJhZ21lbnRzIG90aGVyIHRoYW4gdGhlIGZpcnN0LiAg SW4gdGhlDQogICAgICBsYXR0ZXIgY2FzZSwgc3Vic2VxdWVudCBmcmFnbWVudHMgbWF5IGFycml2 ZSBiZWZvcmUgdGhlIGZpcnN0LCBhbmQNCiAgICAgIHRoZSBydWxlcyAoaW4gdGhlIGJ1bGxldGVk IGxpc3QgYWJvdmUpIGFib3V0IGhvdyB0aGUgbHdCNCBoYW5kbGVzDQogICAgICAob3V0LW9mLW9y ZGVyKSBmcmFnbWVudHMgYXBwbHkNCg0KICAgICAgDQogICAgICBGb3IgaW5jb21pbmcgZGUtY2Fw c3VsYXRlZCBJUHY0IHBhY2tldHMgY2FycnlpbmcgVURQIHBhY2tldHMgd2l0aA0KICAgICAgYSB6 ZXJvIGNoZWNrc3VtLCBpZiB0aGUgbHdCNCBoYXMgZW5vdWdoIHJlc291cmNlcywgdGhlIGx3QjQg TVVTVA0KICAgICAgcmVhc3NlbWJsZSB0aGUgcGFja2V0cyBhbmQgTVVTVCBjYWxjdWxhdGUgdGhl IGNoZWNrc3VtLiAgSWYgdGhlDQogICAgICBsd0I0IGRvZXMgbm90IGhhdmUgZW5vdWdoIHJlc291 cmNlcywgdGhlbiBpdCBNVVNUIHNpbGVudGx5DQogICAgICBkaXNjYXJkIHRoZSBwYWNrZXRzLiAg VGhlIGhhbmRsaW5nIG9mIGZyYWdtZW50ZWQgYW5kIHVuLWZyYWdtZW50ZWQNCiAgICAgIFVEUCBw YWNrZXRzIHdpdGggYSB6ZXJvIGNoZWNrc3VtIGFzIHNwZWNpZmllZCBhYm92ZSBkZXZpYXRlcyBm cm9tDQogICAgICB0aGF0IHNwZWNpZmllZCBpbiBbUkZDNjE0NV0uDQoNCiAgICAgIEltcGxlbWVu dGVycyBvZiBhbiBsd0I0IHNob3VsZCBiZSBhd2FyZSB0aGF0IHRoZXJlIGFyZSBhIG51bWJlciBv Zg0KICAgICAgd2VsbC1rbm93biBhdHRhY2tzIGFnYWluc3QgSVAgZnJhZ21lbnRhdGlvbjsgc2Vl IFtSRkMxODU4XSBhbmQNCiAgICAgIFtSRkMzMTI4XS4gIEltcGxlbWVudGVycyBzaG91bGQgYWxz byBiZSBhd2FyZSBvZiBhZGRpdGlvbmFsIGlzc3Vlcw0KICAgICAgd2l0aCByZWFzc2VtYmxpbmcg cGFja2V0cyBhdCBoaWdoIHJhdGVzLCBkZXNjcmliZWQgaW4gW1JGQzQ5NjNdLg0KICAgICAgDQoN CjUuMi4xLjIuIFByb2Nlc3Npbmcgb2YgT3V0Ym91bmQgSVB2NCBQYWNrZXRzIFJlcXVpcmluZyBG cmFnbWVudGF0aW9uIGZvcg0KRW5jYXBzdWxhdGlvbiAgICAgDQogICAgICANCg0KICAgICAgV2hl biBhbiBsd0I0IHJlY2VpdmVzIGFuIElQdjQgcGFja2V0IGZyb20gYSBjb25uZWN0ZWQgaG9zdCB0 aGF0DQogICAgICBleGNlZWRzIHRoZSBJUHY2IE1UVSBzaXplIGFmdGVyIGVuY2Fwc3VsYXRpb24s IHRoZSBsd0I0IFNIT1VMRA0KICAgICAgZnJhZ21lbnQgdGhlIElQdjQgcGFja2V0IGJlZm9yZSBl bmNhcHN1bGF0aW9uLiAgVGhpcyBsd0I0IGJlaGF2aW9yDQogICAgICBhdm9pZHMgSVB2NiBmcmFn bWVudGF0aW9uLCBzbyB0aGF0IHRoZSBsd0FGVFIgaXMgbm90IHJlcXVpcmVkIHRvDQogICAgICBy ZS1hc3NlbWJsZSBmcmFnbWVudGVkIElQdjYgcGFja2V0cy4gIElmIHRoZSB0aGUgRG9uJ3QgRnJh Z21lbnQgKERGKQ0KICAgICAgYml0IGlzIHNldCBpbiB0aGUgSVB2NCBwYWNrZXQgaGVhZGVyIChl LmcuIGZvciBQTVRVRCBkaXNjb3ZlcnkpLCB0aGVuDQogICAgICB0aGUgSVB2NCBwYWNrZXQgaXMg ZHJvcHBlZCBieSB0aGUgbHdCNCBhbmQgYW4gSUNNUCBGcmFnbWVudGF0aW9uDQogICAgICBOZWVk ZWQgKFR5cGUgMywgQ29kZSA0KSB3aXRoIHRoZSBjb3JyZWN0IHR1bm5lbCBNVFUgaXMgc2VudC4N Cg0KDQo= From ssenthil@cisco.com Mon Feb 10 06:44:03 2014 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4A711A0862 for ; Mon, 10 Feb 2014 06:44:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.049 X-Spam-Level: X-Spam-Status: No, score=-15.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 h89BGoyGTpSy for ; Mon, 10 Feb 2014 06:44:01 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id ED6121A0865 for ; Mon, 10 Feb 2014 06:44:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6402; q=dns/txt; s=iport; t=1392043441; x=1393253041; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=YhSNX0QwqZOwnq0fY8ZvUlkBw3lo0u6jnSik04IUCJk=; b=Zzf+LHIFbYw7B3b1YdqL80SCj7iT/6107ilZ/pN/H9gnPj9ALJ6AUIT2 4Rv7hdOfaCGBdXx7ruI/z+X6exAgadTqJGWWRz+uS73+IIS9WU3eaR1z6 jAqy3zj4UkLwDmCvPNr0K2a7rROQV8T39kTh6mcBo5/nB4h/TnfytPAmB A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFADTl+FKtJV2Z/2dsb2JhbABZgwyBD4MBvDwYeBZ0giYBAQQ0VQIBCBwoAgIwJQIEARKIBYx/m3cGoFsXgSONAw4WOoJpgU8ElEKDaZIhgy2BaUE X-IronPort-AV: E=Sophos;i="4.95,818,1384300800"; d="scan'208";a="303000513" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-7.cisco.com with ESMTP; 10 Feb 2014 14:44:00 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s1AEi0oo020539 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 10 Feb 2014 14:44:00 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.177]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0123.003; Mon, 10 Feb 2014 08:44:00 -0600 From: "Senthil Sivakumar (ssenthil)" To: "ian.farrer@telekom.de" , "simon.perreault@viagenie.ca" , "softwires@ietf.org" Thread-Topic: [Softwires] I-D Action: draft-ietf-softwire-lw4over6-05.txt Thread-Index: AQHPI9js3AHykHFYkECOgnbgISaLTJqqNSeAgAAjWgCAABQNAIAEW7+A///d0oA= Date: Mon, 10 Feb 2014 14:44:00 +0000 Message-ID: References: <20140207074738.9960.68519.idtracker@ietfa.amsl.com> <52F4E59B.60402@viagenie.ca> <52F51414.1070604@viagenie.ca> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [64.102.83.140] Content-Type: text/plain; charset="euc-kr" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-lw4over6-05.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 14:44:04 -0000 TG9va3MgZ29vZCB0byBtZS4uDQoNClRoYW5rcw0KU2VudGhpbA0KDQpPbiAyLzEwLzE0IDY6NDYg QU0sICJpYW4uZmFycmVyQHRlbGVrb20uZGUiIDxpYW4uZmFycmVyQHRlbGVrb20uZGU+IHdyb3Rl Og0KDQo+SGkgU2ltb24gLyBTZW50aGlsLA0KPg0KPlBsZWFzZSBzZWUgYmVsb3cuDQo+DQo+Q2hl ZXJzLA0KPklhbg0KPg0KPj4+Pg0KPj4+PiBJdCdzIHBvc3NpYmxlIHRvIGRvIGl0IGNvcnJlY3Rs eSB3aXRob3V0IHdhaXRpbmcgZm9yIGFsbCBmcmFnbWVudHMNCj4+Pj4gKGUuZy4sIHdoYXQgQ2lz Y28gY2FsbHMgInZpcnR1YWwgcmVhc3NlbWJseSIpLiBNeSBzdWdnZXN0aW9uIHdvdWxkIGJlDQo+ Pj4+dG8NCj4+Pj4gc3RlYWwgdGhlIHZlcnkgY2FyZWZ1bGx5IHdyaXR0ZW4gdGV4dCBmcm9tIFJG QyA2MTQ2LCBwYWdlIDE5Lg0KPj4+IA0KPj4+IFtpYW5dIE15IGFwb2xvZ2llcyAtIEkgd2Fzbqn2 dCBmYW1pbGlhciB3aXRoIHRoZSBDaXNjbyBmZWF0dXJlIHRoYXQgeW91DQo+Pj4gbWVudGlvbmVk LCBzbyByZXNlYXJjaGVkIGl0IGFuZCBhbGwgb2YgdGhlIGluZm9ybWF0aW9uIHRoYXQgSan2dmUg Zm91bmQNCj4+PmlzDQo+Pj4gdGhlIENpc2NvIFZGUiAodmlydHVhbCBmcmFnbWVudCByZWFzc2Vt Ymx5KS4NCj4+DQo+Pkl0J3MganVzdCBhbiBleGFtcGxlLiBNYXliZSBub3Qgd2VsbCBjaG9zZW4s IHNpbmNlIEkgY2FuJ3QgZmluZA0KPj5kb2N1bWVudGF0aW9uIGV4cGxhaW5pbmcgZXhhY3RseSB0 aGUgYmVoYXZpb3VyIEkgdGhpbmsgaXQgaW1wbGVtZW50cy4NCj4NCj5baWFuXSBUaGF0oa9zIHdo YXQgdGhyZXcgbWUuDQo+DQo+T0ssIHdoYXQgYWJvdXQgKGZvciB0aGUgd2hvbGUgb2YgdGhlIGx3 QjQgZnJhZ21lbnRhdGlvbiBzZWN0aW9uKToNCj4NCj41LjIuMS4gIENoYW5nZXMgdG8gUkZDMjQ3 MyBhbmQgUkZDNjMzMyBGcmFnbWVudGF0aW9uIEJlaGF2aW91cg0KPg0KPjUuMi4xLjEuIFByb2Nl c3Npbmcgb2YgSW5jb21pbmcgSVB2NCBGcmFnbWVudHMgRW5jYXBzdWxhdGVkIGluIElQdjYNCj4N Cj4gICANCj4gICBUaGUgZm9sbG93aW5nIHByb2Nlc3MgZm9yIGhhbmRsaW5nIGZyYWdtZW50ZWQg cGFja2V0cyBpcyB0YWtlbiBmcm9tDQo+ICAgU2VjdGlvbiAzLjQgb2YgW1JGQzYxNDZdLCBhZGFw dGVkIGZvciB1c2Ugd2l0aCBmcmFnbWVudGF0aW9uIG9mDQo+ICAgZW5jYXBzdWxhdGVkIElQdjQg dHVubmVsIHRyYWZmaWMgYW5kIE5BUFQ0NC4NCj4NCj4gICANCj4gICBPbiByZWNlaXZpbmcgYW4g ZW5jYXBzdWxhdGVkIHBhY2tldCBjb250YWluaW5nIGFuIElQdjQgZnJhZ21lbnQsDQo+ICAgdGhl biBtb3JlIHByb2Nlc3NpbmcgbWF5IGJlIG5lZWRlZCB0aGFuIGZvciBub24tZnJhZ21lbnRlZCBw YXlsb2Fkcy4NCj4gICBUaGlzIHNwZWNpZmljYXRpb24gbGVhdmVzIG9wZW4gdGhlIGV4YWN0IGRl dGFpbHMgb2YgaG93IHRoZSBsd0I0DQo+aGFuZGxlcw0KPiAgIGluY29taW5nIGVuY2Fwc3VsYXRl ZCBJUHY2IHBhY2tldHMgY29udGFpbmluZyBJUHY0IGZyYWdtZW50cywgYW5kDQo+ICAgc2ltcGx5 IHJlcXVpcmVzIHRoYXQgdGhlIGV4dGVybmFsIGJlaGF2aW9yIG9mIHRoZSBsd0I0IGJlIGNvbXBs aWFudA0KPndpdGggDQo+dGhlIGZvbGxvd2luZyBjb25kaXRpb25zOiBUaGUgbHdCNCBNVVNUIGhh bmRsZSBlbmNhcHN1bGF0ZWQgSVB2NA0KPmZyYWdtZW50cy4gIEluIHBhcnRpY3VsYXIsIHRoZSBs d0I0IE1VU1QgaGFuZGxlIGZyYWdtZW50cyBhcnJpdmluZw0KPm91dCBvZiBvcmRlciwgY29uZGl0 aW9uYWwgb24gdGhlIGZvbGxvd2luZzoNCj4NCj4gICAgICANCj4gICAgICAqICBUaGUgbHdCNCBN VVNUIGxpbWl0IHRoZSBhbW91bnQgb2YgcmVzb3VyY2VzIGRldm90ZWQgdG8gdGhlDQo+ICAgICAg ICAgc3RvcmFnZSBvZiBmcmFnbWVudGVkIHBhY2tldHMgaW4gb3JkZXIgdG8gcHJvdGVjdCBmcm9t IERvUw0KPiAgICAgICAgIGF0dGFja3MuDQo+ICAgICAgKiAgQXMgbG9uZyBhcyB0aGUgbHdCNCBo YXMgYXZhaWxhYmxlIHJlc291cmNlcywgdGhlIGx3QjQgTVVTVA0KPiAgICAgICAgIGFsbG93IHRo ZSBmcmFnbWVudHMgdG8gYXJyaXZlIG92ZXIgYSB0aW1lIGludGVydmFsLiAgVGhlIHRpbWUNCj4g ICAgICAgICBpbnRlcnZhbCBTSE9VTEQgYmUgY29uZmlndXJhYmxlIGFuZCB0aGUgZGVmYXVsdCB2 YWx1ZSBNVVNUIGJlDQo+ICAgICAgICAgb2YgYXQgbGVhc3QgRlJBR01FTlRfTUlOLg0KPiAgICAg ICogIFRoZSBsd0I0IE1BWSByZXF1aXJlIHRoYXQgdGhlIFVEUCwgVENQLCBvciBJQ01QIGhlYWRl ciBiZQ0KPiAgICAgICAgIGNvbXBsZXRlbHkgY29udGFpbmVkIHdpdGhpbiB0aGUgZnJhZ21lbnQg dGhhdCBjb250YWlucyBmcmFnbWVudA0KPiAgICAgICAgIG9mZnNldCBlcXVhbCB0byB6ZXJvLg0K Pg0KPiAgICAgICAgIA0KPiAgICAgIEZvciBpbmNvbWluZyBwYWNrZXRzIGNhcnJ5aW5nIFRDUCBv ciBVRFAgSVB2NCBmcmFnbWVudHMgd2l0aCBhDQo+bm9uLXplcm8NCj4gICAgICBjaGVja3N1bSwg YWZ0ZXIgZGUtY2Fwc3VsYXRpb24sIHRoZSBsd0I0IE1BWSBlbGVjdCB0byBxdWV1ZSB0aGUNCj4g ICAgICBmcmFnbWVudHMgYXMgdGhleSBhcnJpdmUgYW5kIHBlcmZvcm0gTkFQVDQ0IG9uIGFsbCBm cmFnbWVudHMgYXQNCj4gICAgICB0aGUgc2FtZSB0aW1lLiAgSW4gdGhpcyBjYXNlLCB0aGUgaW5j b21pbmcgNS10dXBsZSBpcyBkZXRlcm1pbmVkDQo+ICAgICAgYnkgZXh0cmFjdGluZyB0aGUgYXBw cm9wcmlhdGUgZmllbGRzIGZyb20gdGhlIHJlY2VpdmVkIHBhY2tldC4NCj4gICAgICBBbHRlcm5h dGl2ZWx5LCBhIGx3QjQgTUFZIHRyYW5zbGF0ZSB0aGUgZGUtY2Fwc3VsYXRlZCBmcmFnbWVudHMg YXMNCj4gICAgICB0aGV5IGFycml2ZSwgYnkgc3RvcmluZyAgaW5mb3JtYXRpb24gdGhhdCBhbGxv d3MgaXQgdG8gY29tcHV0ZSB0aGUNCj4gICAgICA1LXR1cGxlIGZvciBmcmFnbWVudHMgb3RoZXIg dGhhbiB0aGUgZmlyc3QuICBJbiB0aGUNCj4gICAgICBsYXR0ZXIgY2FzZSwgc3Vic2VxdWVudCBm cmFnbWVudHMgbWF5IGFycml2ZSBiZWZvcmUgdGhlIGZpcnN0LCBhbmQNCj4gICAgICB0aGUgcnVs ZXMgKGluIHRoZSBidWxsZXRlZCBsaXN0IGFib3ZlKSBhYm91dCBob3cgdGhlIGx3QjQgaGFuZGxl cw0KPiAgICAgIChvdXQtb2Ytb3JkZXIpIGZyYWdtZW50cyBhcHBseQ0KPg0KPiAgICAgIA0KPiAg ICAgIEZvciBpbmNvbWluZyBkZS1jYXBzdWxhdGVkIElQdjQgcGFja2V0cyBjYXJyeWluZyBVRFAg cGFja2V0cyB3aXRoDQo+ICAgICAgYSB6ZXJvIGNoZWNrc3VtLCBpZiB0aGUgbHdCNCBoYXMgZW5v dWdoIHJlc291cmNlcywgdGhlIGx3QjQgTVVTVA0KPiAgICAgIHJlYXNzZW1ibGUgdGhlIHBhY2tl dHMgYW5kIE1VU1QgY2FsY3VsYXRlIHRoZSBjaGVja3N1bS4gIElmIHRoZQ0KPiAgICAgIGx3QjQg ZG9lcyBub3QgaGF2ZSBlbm91Z2ggcmVzb3VyY2VzLCB0aGVuIGl0IE1VU1Qgc2lsZW50bHkNCj4g ICAgICBkaXNjYXJkIHRoZSBwYWNrZXRzLiAgVGhlIGhhbmRsaW5nIG9mIGZyYWdtZW50ZWQgYW5k IHVuLWZyYWdtZW50ZWQNCj4gICAgICBVRFAgcGFja2V0cyB3aXRoIGEgemVybyBjaGVja3N1bSBh cyBzcGVjaWZpZWQgYWJvdmUgZGV2aWF0ZXMgZnJvbQ0KPiAgICAgIHRoYXQgc3BlY2lmaWVkIGlu IFtSRkM2MTQ1XS4NCj4NCj4gICAgICBJbXBsZW1lbnRlcnMgb2YgYW4gbHdCNCBzaG91bGQgYmUg YXdhcmUgdGhhdCB0aGVyZSBhcmUgYSBudW1iZXIgb2YNCj4gICAgICB3ZWxsLWtub3duIGF0dGFj a3MgYWdhaW5zdCBJUCBmcmFnbWVudGF0aW9uOyBzZWUgW1JGQzE4NThdIGFuZA0KPiAgICAgIFtS RkMzMTI4XS4gIEltcGxlbWVudGVycyBzaG91bGQgYWxzbyBiZSBhd2FyZSBvZiBhZGRpdGlvbmFs IGlzc3Vlcw0KPiAgICAgIHdpdGggcmVhc3NlbWJsaW5nIHBhY2tldHMgYXQgaGlnaCByYXRlcywg ZGVzY3JpYmVkIGluIFtSRkM0OTYzXS4NCj4gICAgICANCj4NCj41LjIuMS4yLiBQcm9jZXNzaW5n IG9mIE91dGJvdW5kIElQdjQgUGFja2V0cyBSZXF1aXJpbmcgRnJhZ21lbnRhdGlvbiBmb3INCj5F bmNhcHN1bGF0aW9uICAgICANCj4gICAgICANCj4NCj4gICAgICBXaGVuIGFuIGx3QjQgcmVjZWl2 ZXMgYW4gSVB2NCBwYWNrZXQgZnJvbSBhIGNvbm5lY3RlZCBob3N0IHRoYXQNCj4gICAgICBleGNl ZWRzIHRoZSBJUHY2IE1UVSBzaXplIGFmdGVyIGVuY2Fwc3VsYXRpb24sIHRoZSBsd0I0IFNIT1VM RA0KPiAgICAgIGZyYWdtZW50IHRoZSBJUHY0IHBhY2tldCBiZWZvcmUgZW5jYXBzdWxhdGlvbi4g IFRoaXMgbHdCNCBiZWhhdmlvcg0KPiAgICAgIGF2b2lkcyBJUHY2IGZyYWdtZW50YXRpb24sIHNv IHRoYXQgdGhlIGx3QUZUUiBpcyBub3QgcmVxdWlyZWQgdG8NCj4gICAgICByZS1hc3NlbWJsZSBm cmFnbWVudGVkIElQdjYgcGFja2V0cy4gIElmIHRoZSB0aGUgRG9uJ3QgRnJhZ21lbnQgKERGKQ0K PiAgICAgIGJpdCBpcyBzZXQgaW4gdGhlIElQdjQgcGFja2V0IGhlYWRlciAoZS5nLiBmb3IgUE1U VUQgZGlzY292ZXJ5KSwNCj50aGVuDQo+ICAgICAgdGhlIElQdjQgcGFja2V0IGlzIGRyb3BwZWQg YnkgdGhlIGx3QjQgYW5kIGFuIElDTVAgRnJhZ21lbnRhdGlvbg0KPiAgICAgIE5lZWRlZCAoVHlw ZSAzLCBDb2RlIDQpIHdpdGggdGhlIGNvcnJlY3QgdHVubmVsIE1UVSBpcyBzZW50Lg0KPg0KPg0K DQo= From simon.perreault@viagenie.ca Mon Feb 10 08:48:38 2014 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FA2D1A06F4 for ; Mon, 10 Feb 2014 08:48:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] 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 2VsOKP3b4qYf for ; Mon, 10 Feb 2014 08:48:36 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 6FD421A031B for ; Mon, 10 Feb 2014 08:48:35 -0800 (PST) Received: from porto.nomis80.org (ringo.viagenie.ca [IPv6:2620:0:230:c000:3e97:eff:fe0b:dd8a]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 5482640405; Mon, 10 Feb 2014 11:48:34 -0500 (EST) Message-ID: <52F902E2.4000301@viagenie.ca> Date: Mon, 10 Feb 2014 11:48:34 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Senthil Sivakumar (ssenthil)" , "ian.farrer@telekom.de" , "softwires@ietf.org" References: <20140207074738.9960.68519.idtracker@ietfa.amsl.com> <52F4E59B.60402@viagenie.ca> <52F51414.1070604@viagenie.ca> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-lw4over6-05.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 16:48:38 -0000 Le 2014-02-10 09:44, Senthil Sivakumar (ssenthil) a écrit : > Looks good to me.. +1 Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From internet-drafts@ietf.org Mon Feb 10 10:46:54 2014 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FE6C1A0813; Mon, 10 Feb 2014 10:46:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 mHOQh68ZKnGV; Mon, 10 Feb 2014 10:46:52 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DB5521A07EC; Mon, 10 Feb 2014 10:46:52 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140210184652.1427.35461.idtracker@ietfa.amsl.com> Date: Mon, 10 Feb 2014 10:46:52 -0800 Cc: softwires@ietf.org Subject: [Softwires] I-D Action: draft-ietf-softwire-map-t-05.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 18:46:54 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Softwires Working Group of the IETF. Title : Mapping of Address and Port using Translation (MAP-T) Authors : Xing Li Congxiao Bao Wojciech Dec Ole Troan Satoru Matsushima Tetsuya Murakami Filename : draft-ietf-softwire-map-t-05.txt Pages : 24 Date : 2014-02-10 Abstract: This document specifies the "Mapping of Address and Port" stateless IPv6-IPv4 Network Address Translation (NAT64) based solution architecture for providing shared or non-shared IPv4 address connectivity to and across an IPv6 network. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-softwire-map-t/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-softwire-map-t-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-softwire-map-t-05 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon Feb 10 23:54:47 2014 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5D801A08E9; Mon, 10 Feb 2014 23:54:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 8DuxM8mzf5DJ; Mon, 10 Feb 2014 23:54:46 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 01F491A07B0; Mon, 10 Feb 2014 23:54:46 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140211075445.17615.61208.idtracker@ietfa.amsl.com> Date: Mon, 10 Feb 2014 23:54:45 -0800 Cc: softwires@ietf.org Subject: [Softwires] I-D Action: draft-ietf-softwire-lw4over6-06.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 07:54:47 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Softwires Working Group of the IETF. Title : Lightweight 4over6: An Extension to the DS-Lite Architecture Authors : Yong Cui Qiong Sun Mohamed Boucadair Tina Tsou Yiu L. Lee Ian Farrer Filename : draft-ietf-softwire-lw4over6-06.txt Pages : 22 Date : 2014-02-10 Abstract: Dual-Stack Lite (RFC 6333) describes an architecture for transporting IPv4 packets over an IPv6 network. This document specifies an extension to DS-Lite called Lightweight 4over6 which moves the Network Address and Port Translation (NAPT) function from the centralized DS-Lite tunnel concentrator to the tunnel client located in the Customer Premises Equipment (CPE). This removes the requirement for a Carrier Grade NAT function in the tunnel concentrator and reduces the amount of centralized state that must be held to a per-subscriber level. In order to delegate the NAPT function and make IPv4 Address sharing possible, port-restricted IPv4 addresses are allocated to the CPEs. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-softwire-lw4over6/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-softwire-lw4over6-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-softwire-lw4over6-06 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From otroan@employees.org Tue Feb 11 02:28:29 2014 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E7321A093E for ; Tue, 11 Feb 2014 02:28:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] 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 y51K2FUhE3uR for ; Tue, 11 Feb 2014 02:28:27 -0800 (PST) Received: from banjo.employees.org (banjo.employees.org [IPv6:2001:1868:205::19]) by ietfa.amsl.com (Postfix) with ESMTP id C2EF61A095D for ; Tue, 11 Feb 2014 02:28:23 -0800 (PST) Received: from dhcp-lys01-vla250-10-147-113-220.cisco.com (173-38-208-169.cisco.com [173.38.208.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 971FE6056 for ; Tue, 11 Feb 2014 02:28:21 -0800 (PST) From: Ole Troan Content-Type: multipart/signed; boundary="Apple-Mail=_C001754F-DACA-41ED-BB8F-FBCA489974AF"; protocol="application/pgp-signature"; micalg=pgp-sha512 Message-Id: Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Date: Tue, 11 Feb 2014 11:28:18 +0100 References: <20140211075445.17615.61208.idtracker@ietfa.amsl.com> To: Softwires WG In-Reply-To: <20140211075445.17615.61208.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.1827) Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-lw4over6-06.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 10:28:29 -0000 --Apple-Mail=_C001754F-DACA-41ED-BB8F-FBCA489974AF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii a few initial comments: s/connectivity services/connectivity/ s/OPTION_SW46_LW/OPTION_S46_CONT_LW/ section 5.1 An IPv6 address from an assigned prefix is also required for the lwB4 to use as the encapsulation source address for the softwire. In order to enable end-to-end provisioning, the IPv6 address is constructed by taking a /64 prefix assigned to the WAN interface and suffixing 64-bits for the interface identifier. As there may be multiple WAN prefixes, of which only one can be used for lw4o6, the CPE is provisioned with the logic to select the correct one. The / 128 prefix is then constructed as follows: that seems awfully hand-wavy? how is the CPE supposed to pick which prefix to use? does it have to be = from the WAN interface? could it be from the PD block as well? reference MAP for the interface-id? (or perhaps just state that it is = the same) define PSID somewhere? (reference MAP document)? why SHOULD the a-bits be 0? isn't that an operational choice? I really don't think overriding the ICMP type 1 code 5 is appropriate to = signal "no binding". do you think the BR reachability check from RFC5969 could be adopted = instead? should you say something about using anycast addresses for the AFTR? a general comment. we're going to have quite a bit of redundant text = between the MAP documents and the LW46 document, e.g. ICMP handling, = fragmentation. I don't have a big problem with that as such, but should = ensure that the text isn't conflicting at least. cheers, Ole On 11 Feb 2014, at 8:54 , internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Softwires Working Group of the IETF. >=20 > Title : Lightweight 4over6: An Extension to the = DS-Lite Architecture > Authors : Yong Cui > Qiong Sun > Mohamed Boucadair > Tina Tsou > Yiu L. Lee > Ian Farrer > Filename : draft-ietf-softwire-lw4over6-06.txt > Pages : 22 > Date : 2014-02-10 >=20 > Abstract: > Dual-Stack Lite (RFC 6333) describes an architecture for = transporting > IPv4 packets over an IPv6 network. This document specifies an > extension to DS-Lite called Lightweight 4over6 which moves the > Network Address and Port Translation (NAPT) function from the > centralized DS-Lite tunnel concentrator to the tunnel client located > in the Customer Premises Equipment (CPE). This removes the > requirement for a Carrier Grade NAT function in the tunnel > concentrator and reduces the amount of centralized state that must = be > held to a per-subscriber level. In order to delegate the NAPT > function and make IPv4 Address sharing possible, port-restricted = IPv4 > addresses are allocated to the CPEs. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-softwire-lw4over6/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-softwire-lw4over6-06 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-softwire-lw4over6-06 >=20 >=20 > 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. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires --Apple-Mail=_C001754F-DACA-41ED-BB8F-FBCA489974AF Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJS+ftCAAoJEFuJXizso86gtMsIAL+1prLsAeSr0P3Ml2H4D/UM Kfqym49wlZJ2HsnawBz6LXtq1u7z0aqNVQ6diRNkEA8OAfY5+EpRs7ONVGvqWgnO mSmEbze28v7IXULx9goTeW6ypnJgShARWmUwduzLOxM3h7+n7VwRstfmKu6rCEYx G/hR8sZUHqjaaTzSn1PtjUUMk2w9VEN6jy1Ta4JAgMyh7n9qlHjwuBT1cvqoi9ZD iT3PyDZPRu+5p1UHnh1GeWOEiiZx/ZLf+nQi+iJ0RQg6azaEYwMZItFP2Xywyy1W 5ysBGjK8Io2yEwBg4FV6GZP/IBPcGHJAtRg+xU2AUU09Iv0WXPuuCH4Hqdu6L7Y= =wlzO -----END PGP SIGNATURE----- --Apple-Mail=_C001754F-DACA-41ED-BB8F-FBCA489974AF-- From nobody Thu Feb 13 21:49:59 2014 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C91481A00EC for ; Thu, 13 Feb 2014 21:49:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] 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 6TUsD86peP3s for ; Thu, 13 Feb 2014 21:49:55 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id CB0B11A00EE for ; Thu, 13 Feb 2014 21:49:55 -0800 (PST) X-AuditID: c618062d-b7f858e0000031c7-75-52fdae7d20e3 Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 2D.91.12743.D7EADF25; Fri, 14 Feb 2014 06:49:50 +0100 (CET) Received: from [164.48.125.58] (147.117.188.8) by smtps-am.internal.ericsson.com (147.117.188.93) with Microsoft SMTP Server (TLS) id 14.2.347.0; Fri, 14 Feb 2014 00:49:52 -0500 Message-ID: <52FDAE7B.8090009@ericsson.com> Date: Fri, 14 Feb 2014 00:49:47 -0500 From: Suresh Krishnan User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Softwires WG Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [147.117.188.8] X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpiluLIzCtJLcpLzFFi42KZXLonVrdu3d8gg1lfeC1+bEm2OLxsK5PF 1u5YB2aPJUt+Mnm8PjCf1eP457fMAcxRXDYpqTmZZalF+nYJXBk9uy+wFdxjrXhzZh1zA+Nt li5GTg4JAROJLxOvQ9liEhfurWfrYuTiEBI4wigx+9d5VghnK6PErhWnmUCqeAW0JZb+2MIK YrMIqEq097ayg9hsQJM27PwMViMqECbRfmEmM0S9oMTJmU/ANogA1T/Z+YANxGYW8JRYseEb I4gtLOAoMf3bGlaIuK3EhTkQFzELyEtsfzsHbI6QgKbE1jXfWSEuVZR4cfwn0wRGgVlIVsxC 0j4LSfsCRuZVjBylxalluelGBpsYgeF4TIJNdwfjnpeWhxilOViUxHm/vHUOEhJITyxJzU5N LUgtii8qzUktPsTIxMEp1cDYXMejuY5v5+qdzLIvj/06mGYftvo4w4+Mz0ZTEo/rZU5d/XzJ hcWaxZUnz4jHGzZ0RHpPTPc8VhH4PF21vuuZa8gmCfWVU9yOXygKFLFabT1LSfmZ9fY1AZG8 S/JZnzTelW82vXRJivnYvdo1n9/eubm5pznxn+WtdRO3Jh+p5Ih7MevpY2EjJZbijERDLeai 4kQAnx9gCxUCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/softwires/zhr8lle15VKE33QKhaHgY8g_ttI Cc: Yong Cui Subject: [Softwires] Working group last call for draft-ietf-softwire-map-t-05 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 05:49:58 -0000 Hi all, This message starts a two week softwire working group last call on advancing the draft about providing Mapping of Address and Port using Translation as an Experimental RFC. The authors believe that this version has addressed all the issues raised on the document till date. The latest version of the draft is available at http://www.ietf.org/id/draft-ietf-softwire-map-t-05.txt http://tools.ietf.org/html/draft-ietf-softwire-map-t-05 Substantive comments and statements of support/opposition for advancing this document should be directed to the mailing list. Editorial suggestions can be sent directly to the authors. This last call will conclude on February 28, 2014 Regards, Suresh & Yong From nobody Thu Feb 13 21:52:13 2014 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68AB61A00FB for ; Thu, 13 Feb 2014 21:52:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] 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 K6z7QtPao9Jj for ; Thu, 13 Feb 2014 21:52:09 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id A16071A00FE for ; Thu, 13 Feb 2014 21:52:09 -0800 (PST) X-AuditID: c6180641-b7f2f8e000002cdc-e9-52fdaf08fde8 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 6B.06.11484.80FADF25; Fri, 14 Feb 2014 06:52:09 +0100 (CET) Received: from [164.48.125.58] (147.117.188.8) by smtps-am.internal.ericsson.com (147.117.188.84) with Microsoft SMTP Server (TLS) id 14.2.347.0; Fri, 14 Feb 2014 00:52:06 -0500 Message-ID: <52FDAF01.6080308@ericsson.com> Date: Fri, 14 Feb 2014 00:52:01 -0500 From: Suresh Krishnan User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Softwires WG Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [147.117.188.8] X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpiluLIzCtJLcpLzFFi42KZXLonRJdz/d8gg2s/+Sx+bEm2OLxsK5PF 1u5YB2aPJUt+Mnm8PjCf1eP457fMAcxRXDYpqTmZZalF+nYJXBk3uiezFTxkrZjw5QZ7A+Md li5GTg4JAROJ610PoWwxiQv31rN1MXJxCAkcYZTYdnUBM4SzlVFi+88nrCBVvALaEh97X7GB 2CwCqhJzd/5nB7HZgCZt2PmZCcQWFQiTaL8wkxmiXlDi5MwnYBtEgOqf7HwA1sss4CmxYsM3 RhBbWMBeYvKEL6wQcVuJC3Ous0DY8hLb384BmyMkoCmxdc13VohLFSVeHP/JNIFRYBaSFbOQ tM9C0r6AkXkVI0dpcWpZbrqR4SZGYDgek2Bz3MG44JPlIUZpDhYlcd4vb52DhATSE0tSs1NT C1KL4otKc1KLDzEycXBKNTAK7ClvsmKs1366YNutC/GJGrxnJ30Rvtx6+8OPV0+FZzVPqDKT /Xh0poql/v3zX+a+aT9lwtY/5bek/LY35T/5z0ybW+TWekhkWl3yx5eaL65l1C80M/1iXi72 3WGm/KdlAoLnp13R1bilNF0zmHWBwAUJ5iMNaxesaFh61PyknefrgP3ZpX/FlFiKMxINtZiL ihMBXClzThUCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/softwires/EFsg1LSmosHKTHsSjp2yAGEM7A0 Cc: Yong Cui Subject: [Softwires] Working group last call for draft-ietf-softwire-4rd-07 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 05:52:11 -0000 Hi all, This message starts a two week softwire working group last call on advancing the draft about IPv4 Residual Deployment via IPv6 - a Stateless Solution (4rd) as an Experimental RFC. The authors believe that this version has addressed all the issues raised on the document till date. The latest version of the draft is available at http://www.ietf.org/id/draft-ietf-softwire-4rd-07.txt http://tools.ietf.org/html/draft-ietf-softwire-4rd-07 Substantive comments and statements of support/opposition for advancing this document should be directed to the mailing list. Editorial suggestions can be sent directly to the authors. This last call will conclude on February 28, 2014 Regards, Suresh & Yong From nobody Fri Feb 14 01:31:45 2014 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 018731A00BA for ; Fri, 14 Feb 2014 01:31:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.798 X-Spam-Level: X-Spam-Status: No, score=-2.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548] 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 OtYzQDh2Rbxh for ; Fri, 14 Feb 2014 01:31:39 -0800 (PST) Received: from tcmail93.telekom.de (tcmail93.telekom.de [80.149.113.205]) by ietfa.amsl.com (Postfix) with ESMTP id 275C91A00F7 for ; Fri, 14 Feb 2014 01:31:38 -0800 (PST) Received: from he111630.emea1.cds.t-internal.com ([10.134.93.22]) by tcmail91.telekom.de with ESMTP/TLS/AES128-SHA; 14 Feb 2014 10:18:09 +0100 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE111630.emea1.cds.t-internal.com ([::1]) with mapi; Fri, 14 Feb 2014 10:18:09 +0100 From: To: , Date: Fri, 14 Feb 2014 10:18:07 +0100 Thread-Topic: [Softwires] I-D Action: draft-ietf-softwire-lw4over6-06.txt Thread-Index: Ac8pZa0W4V9PTEpVQMGF1bdHdkdDFg== Message-ID: References: <20140211075445.17615.61208.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/softwires/F86l74IAU6cp0LgzBDEKgey012E Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-lw4over6-06.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 09:31:43 -0000 Hi Ole, Thanks for the review. Please see inline. Cheers, Ian On 11/02/2014 11:28, "Ole Troan" wrote: >a few initial comments: > >s/connectivity services/connectivity/ >s/OPTION_SW46_LW/OPTION_S46_CONT_LW/ [ian] OK > >section 5.1 > An IPv6 address from an assigned prefix is also required for the lwB4 > to use as the encapsulation source address for the softwire. In > order to enable end-to-end provisioning, the IPv6 address is > constructed by taking a /64 prefix assigned to the WAN interface and > suffixing 64-bits for the interface identifier. As there may be > multiple WAN prefixes, of which only one can be used for lw4o6, the > CPE is provisioned with the logic to select the correct one. The / > 128 prefix is then constructed as follows: > >that seems awfully hand-wavy? >how is the CPE supposed to pick which prefix to use? does it have to be >from the WAN interface? [ian]Yes, it=B9s built on the WAN interface. The intention is that the CPE builds the tunnel from the prefix which it has just created. I guess it=B9s the following line that causes the hand waving: As there may be multiple WAN prefixes, of which only one can be used for lw4o6, the CPE is provisioned with the logic to select the correct one. What about?: As there may be multiple WAN prefixes, of which only one can be used for lw4o6, the CPE creates a new WAN prefix specifically for use as the tunnel source address. >could it be from the PD block as well? [ian] It could be from the PD block if it=B9s using the PD_EXCLUDE=B9d pref= ix, but there=B9s no requirement / necessity for the device with the lwB4 function to support PD to build a tunnel. The lwB4 function could be implemented in an end host which wouldn=B9t support PD. > >reference MAP for the interface-id? (or perhaps just state that it is the >same) [ian] I=B9ll update to say that it=B9s the same. >define PSID somewhere? (reference MAP document)? [ian] Currently, sect 5.1 says: An lwB4 MUST support dynamic port-restricted IPv4 address provisioning. The port set algorithm for provisioning this is described in Section 5.1 of [I-D.ietf-softwire-map]. > >why SHOULD the a-bits be 0? isn't that an operational choice? [ian]Because there=B9s no reason to use non-0 if you=B9re not algorithmical= ly mapping, it just increases the complexity. > >I really don't think overriding the ICMP type 1 code 5 is appropriate to >signal "no binding". [ian] Do you think a different error ICMP error should be sent, or that should be silently dropped? >do you think the BR reachability check from RFC5969 could be adopted >instead? [ian] Possibly, although this would mandate that your lwAFTRs always had traffic hair pinning enabled so the check could succeed. This is a common softwire problem, though. From what I can see, if there were inconsistencies in the MAP provisioning domain between CEs and BRs, for any reason then it would fail with no errors being sent (although there would be counters on the problem devices). > >should you say something about using anycast addresses for the AFTR? > >a general comment. we're going to have quite a bit of redundant text >between the MAP documents and the LW46 document, e.g. ICMP handling, >fragmentation. I don't have a big problem with that as such, but should >ensure that the text isn't conflicting at least. [ian] Some redundancy is inevitable. I _hope_ that by now we=B9ve ironed ou= t any conflicts - I=B9m certainly not aware of any. > >cheers, >Ole > >On 11 Feb 2014, at 8:54 , internet-drafts@ietf.org wrote: > >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts >>directories. >> This draft is a work item of the Softwires Working Group of the IETF. >>=20 >> Title : Lightweight 4over6: An Extension to the >>DS-Lite Architecture >> Authors : Yong Cui >> Qiong Sun >> Mohamed Boucadair >> Tina Tsou >> Yiu L. Lee >> Ian Farrer >> Filename : draft-ietf-softwire-lw4over6-06.txt >> Pages : 22 >> Date : 2014-02-10 >>=20 >> Abstract: >> Dual-Stack Lite (RFC 6333) describes an architecture for transporting >> IPv4 packets over an IPv6 network. This document specifies an >> extension to DS-Lite called Lightweight 4over6 which moves the >> Network Address and Port Translation (NAPT) function from the >> centralized DS-Lite tunnel concentrator to the tunnel client located >> in the Customer Premises Equipment (CPE). This removes the >> requirement for a Carrier Grade NAT function in the tunnel >> concentrator and reduces the amount of centralized state that must be >> held to a per-subscriber level. In order to delegate the NAPT >> function and make IPv4 Address sharing possible, port-restricted IPv4 >> addresses are allocated to the CPEs. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-softwire-lw4over6/ >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-softwire-lw4over6-06 >>=20 >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-softwire-lw4over6-06 >>=20 >>=20 >> 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. >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires > From nobody Fri Feb 14 06:19:10 2014 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 711441A025C for ; Fri, 14 Feb 2014 06:19:02 -0800 (PST) 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 uNbR5tHNXyzk for ; Fri, 14 Feb 2014 06:18:58 -0800 (PST) Received: from mail-pb0-x22f.google.com (mail-pb0-x22f.google.com [IPv6:2607:f8b0:400e:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id A48AA1A02AF for ; Fri, 14 Feb 2014 06:18:42 -0800 (PST) Received: by mail-pb0-f47.google.com with SMTP id rp16so12412569pbb.20 for ; Fri, 14 Feb 2014 06:18:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nMpNxrr4sKT2oCAsffh7KpSL5oV9ROzruxt83Vi0N50=; b=M+2QYCLSwgH3SYI8yWXCxvPGczBg38HGwQn4MHptdyXw8vELQN2+zq9O0vB4mWcXBQ YaNJ1B6nAGRhmxm9RVlnIQNVFvL6TI854wfZen7dEaP0V82BOWCv0LveTKCJong4iiia j7jXx4JzVm+R1UE42RhFgVnAmgTqTZOqLtcohKOq48YvjdBc5htyOftf/kBGd9BiMTdY XjqjjMB6YafoP1qxPmxOMw+3Sr0ofKSFeRypJlo0z9HBbVPvMniXT1ve6xWHWizx9kJt V5ZE0Hku4IEGfDEUSJwOV38eK37ECYh8zLuS04ajxlNNmlwxqDLeMahOLG+uAYo0c3H+ yysQ== MIME-Version: 1.0 X-Received: by 10.66.26.236 with SMTP id o12mr9500052pag.15.1392387521110; Fri, 14 Feb 2014 06:18:41 -0800 (PST) Received: by 10.70.1.70 with HTTP; Fri, 14 Feb 2014 06:18:41 -0800 (PST) In-Reply-To: References: <20140211075445.17615.61208.idtracker@ietfa.amsl.com> Date: Fri, 14 Feb 2014 15:18:41 +0100 Message-ID: From: Wojciech Dec To: "ian.farrer@telekom.de" Content-Type: multipart/alternative; boundary=bcaec529985f95e6df04f25e7b96 Archived-At: http://mailarchive.ietf.org/arch/msg/softwires/XSBOGY5IDYqBE45sRrdOQu990mk Cc: Softwires-wg Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-lw4over6-06.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 14:19:02 -0000 --bcaec529985f95e6df04f25e7b96 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Ian, All, I read the latest draft and have a number of comments. High level: Based on my understanding the lwB4 architecture now has the following ingredients: - The PSID and the port range are algorithmically derived & related as per the MAP algorithm (covered in Section 5.1) - The assigned IPv4 address and port-set form part of the IPv6 address of a lwB4, and are included in the interface-identifier in the same place and format as MAP (Section 5.1) - The lw46 CPE should be provisioned using the MAP DHCP (also Section 5.1). This indicates that lw46 actually share pretty much everything with MAP-E bar the N:1 mode and text on this "specialization" would appear to be warranted and much more appropriate than the current text that refers to it being a ds-lite extension, with which both solutions simply share IPv4inIPv6 tunnelling. It would be good to have text in Section 1 stating this specialization, e.g. in terms of lw46 realizing the MAP-E 1:1 (EA-bit =3D 0) case. In general it would appear to be really useful to make extra sure that there are no data-plane (as per Ole's comment, and some added ones below) between lw46 and MAP-E, or at least arrive at some justification what that is the case, as it's quite clear that a common implementation can cover both drafts rather easily. A reference would actually make things much easier. Detailed comments: * Section 5.1 WAN prefix selection and address forming - as per Ole's comment. This is indeed hand wavy in the current draft (how to select the WAN?) * Section 5.1* and *6.2 has text about ICMPv6 message processing/generation based on incorrect IPv4+port usage, using existing ICMPv6 code type 1 code 5. This appears not in line with at least the IPv6 interpretation of that message (the source address that failed was the IPv4 source, not IPv6, and actually it was a lack of binding rule that failed). * Section 6.2: Text: "If no match is found (e.g., no matching IPv4 address entry, port out of range, etc.), the lwAFTR MUST discard or implement ..." This would suggests that the behaviour is not a MUST, but having said that, the "or implement a redirect..." case makes no sense. If the AFTR has no binding, there is no way that some other node would be able to correspond with the sender, etc. * Processing of IPv4 fragments Section 5.2. Text " The lwB4 MAY require that the UDP, TCP, or ICMP header be completely contained within the fragment that contains fragment offset equal to zero." What does that mean? Is it trying to say that the IPv4 MTU > 40? Section 5.2: " For incoming packets carrying TCP or UDP IPv4 fragments with a non- zero checksum, after de-capsulation, the lwB4 MAY elect to queue the fragments as they arrive and perform NAPT44 on all fragments at the same time" ?? Queue based on what? Presumably the fragment identifier field, and if so then that is no different to 2473. * Section 5.2: Text: For incoming de-capsulated IPv4 packets carrying UDP packets with a zero checksum, if the lwB4 has enough resources, the lwB4 MUST reassemble the packets and MUST calculate the checksum. If the lwB4 does not have enough resources, then it MUST silently discard the packets. Wouldn't it be easier to say that the lwb4 MAY reassemble the packet and recalculate the checksum? It's clearly not a MUST... Cheers, Wojciech On 14 February 2014 10:18, wrote: > Hi Ole, > > > Thanks for the review. Please see inline. > > Cheers, > Ian > > On 11/02/2014 11:28, "Ole Troan" wrote: > >>a few initial comments: >> >>s/connectivity services/connectivity/ >>s/OPTION_SW46_LW/OPTION_S46_CONT_LW/ > > [ian] OK > >> >>section 5.1 >> An IPv6 address from an assigned prefix is also required for the lwB4 >> to use as the encapsulation source address for the softwire. In >> order to enable end-to-end provisioning, the IPv6 address is >> constructed by taking a /64 prefix assigned to the WAN interface and >> suffixing 64-bits for the interface identifier. As there may be >> multiple WAN prefixes, of which only one can be used for lw4o6, the >> CPE is provisioned with the logic to select the correct one. The / >> 128 prefix is then constructed as follows: >> >>that seems awfully hand-wavy? >>how is the CPE supposed to pick which prefix to use? does it have to be >>from the WAN interface? > > [ian]Yes, it=B9s built on the WAN interface. The intention is that the CP= E > builds the tunnel from the prefix which it has just created. I guess it= =B9s > the following line that causes the hand waving: > > As there may be multiple WAN prefixes, of which only one can be used for > lw4o6, the CPE is provisioned with the logic to select the correct one. > > What about?: > > As there may be multiple WAN prefixes, of which only one can be used for > lw4o6, the CPE creates a new WAN prefix specifically for use as the tunne= l > source address. > > > >>could it be from the PD block as well? > > [ian] It could be from the PD block if it=B9s using the PD_EXCLUDE=B9d pr= efix, > but there=B9s no requirement / necessity for the device with the lwB4 > function to support PD to build a tunnel. The lwB4 function could be > implemented in an end host which wouldn=B9t support PD. > >> >>reference MAP for the interface-id? (or perhaps just state that it is the >>same) > > [ian] I=B9ll update to say that it=B9s the same. > >>define PSID somewhere? (reference MAP document)? > > [ian] Currently, sect 5.1 says: An lwB4 MUST support dynamic > port-restricted IPv4 address > provisioning. The port set algorithm for provisioning this is > described in Section 5.1 of [I-D.ietf-softwire-map]. > >> >>why SHOULD the a-bits be 0? isn't that an operational choice? > > [ian]Because there=B9s no reason to use non-0 if you=B9re not algorithmic= ally > mapping, it just increases the complexity. > >> >>I really don't think overriding the ICMP type 1 code 5 is appropriate to >>signal "no binding". > > [ian] Do you think a different error ICMP error should be sent, or that > should be silently dropped? > >>do you think the BR reachability check from RFC5969 could be adopted >>instead? > > [ian] Possibly, although this would mandate that your lwAFTRs always had > traffic hair pinning enabled so the check could succeed. > > This is a common softwire problem, though. From what I can see, if there > were inconsistencies in the MAP provisioning domain between CEs and BRs, > for any reason then it would fail with no errors being sent (although > there would be counters on the problem devices). > >> >>should you say something about using anycast addresses for the AFTR? >> >>a general comment. we're going to have quite a bit of redundant text >>between the MAP documents and the LW46 document, e.g. ICMP handling, >>fragmentation. I don't have a big problem with that as such, but should >>ensure that the text isn't conflicting at least. > > [ian] Some redundancy is inevitable. I _hope_ that by now we=B9ve ironed = out > any conflicts - I=B9m certainly not aware of any. > >> >>cheers, >>Ole >> >>On 11 Feb 2014, at 8:54 , internet-drafts@ietf.org wrote: >> >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>>directories. >>> This draft is a work item of the Softwires Working Group of the IETF. >>> >>> Title : Lightweight 4over6: An Extension to the >>>DS-Lite Architecture >>> Authors : Yong Cui >>> Qiong Sun >>> Mohamed Boucadair >>> Tina Tsou >>> Yiu L. Lee >>> Ian Farrer >>> Filename : draft-ietf-softwire-lw4over6-06.txt >>> Pages : 22 >>> Date : 2014-02-10 >>> >>> Abstract: >>> Dual-Stack Lite (RFC 6333) describes an architecture for transporting >>> IPv4 packets over an IPv6 network. This document specifies an >>> extension to DS-Lite called Lightweight 4over6 which moves the >>> Network Address and Port Translation (NAPT) function from the >>> centralized DS-Lite tunnel concentrator to the tunnel client located >>> in the Customer Premises Equipment (CPE). This removes the >>> requirement for a Carrier Grade NAT function in the tunnel >>> concentrator and reduces the amount of centralized state that must be >>> held to a per-subscriber level. In order to delegate the NAPT >>> function and make IPv4 Address sharing possible, port-restricted IPv4 >>> addresses are allocated to the CPEs. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-softwire-lw4over6/ >>> >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-ietf-softwire-lw4over6-06 >>> >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-softwire-lw4over6-06 >>> >>> >>> 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. >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> _______________________________________________ >>> Softwires mailing list >>> Softwires@ietf.org >>> https://www.ietf.org/mailman/listinfo/softwires >> > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires --bcaec529985f95e6df04f25e7b96 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Ian, All,

I read the latest = draft and have a number of comments.

High level:
Based on my unde= rstanding the lwB4 architecture now has the following ingredients:
- The= PSID and the port range are algorithmically derived & related as per t= he MAP algorithm (covered in Section 5.1)
- The assigned IPv4 address and port-set form part of the IPv6 address of a= lwB4, and are included in the interface-identifier in the same place and f= ormat as MAP (Section 5.1)
- The lw46 CPE should be provisioned using th= e MAP DHCP (also Section 5.1).

This indicates that lw46 actually share pretty much everything with MAP= -E bar the N:1 mode and text on this "specialization" would appea= r to be warranted and much more appropriate than the current text that refe= rs to it being a ds-lite extension, with which both solutions simply share = IPv4inIPv6 tunnelling. It would be good to have text in Section 1 stating t= his specialization, e.g. in terms of lw46 realizing the MAP-E 1:1 (EA-bit = =3D 0) case.

In general it would appear to be really useful to make extra sure that = there are no data-plane (as per Ole's comment, and some added ones belo= w) between lw46 and MAP-E, or at least arrive at some justification what th= at is the case, as it's quite clear that a common implementation can co= ver both drafts rather easily. A reference would actually make things much = easier.

Detailed comments:

* Section 5.1 WAN prefix selection and addres= s forming - as per Ole's comment. This is indeed hand wavy in the curre= nt draft (how to select the WAN?)
* Section 5.1 and 6.2 ha= s text about ICMPv6 message processing/generation based on incorrect IPv4+p= ort usage, using existing ICMPv6 code type 1 code 5. This appears not in li= ne with at least the IPv6 interpretation of that message (the source addres= s that failed was the IPv4 source, not IPv6, and actually it was a lack of = binding rule that failed).
* Section 6.2: Text: "If no match is found (e.g., no matching IP= v4 address entry, port out of range, etc.), the lwAFTR MUST discard or implement ..." This wou= ld suggests that the behaviour is not a MUST, but having said that, the &qu= ot;or implement a redirect..." case makes no sense. If the AFTR has no= binding, there is no way that some other node would be able to correspond = with the sender, etc.
* Processing of IPv4 fragments Section 5.2. Text " The lwB4 MAY = require that the UDP, TCP, or ICMP header be completely contained within the fragment that contains fragment offset equal to zero."
What does that mean? Is it tryin= g to say that the IPv4 MTU > 40?
Section 5.2: "
For incoming packets carrying TCP or UDP IPv4 fragments with a non=
-
   zero checksum, after de-capsulation, the lwB4 MAY elect to queue the
   fragments as they arrive and perform NAPT44 on all fragments at the
   same time"
?? Queue based on what? Presuma=
bly the fragment identifier field, and if so then that is no different to 2=
473.
* Section 5.2: Text:
For incoming de-capsu=
lated IPv4 packets carrying UDP packets with a
   zero checksum, if the lwB4 has enough resources, the lwB4 MUST
   reassemble the packets and MUST calculate the checksum.  If the lwB4
   does not have enough resources, then it MUST silently discard the
   packets.
Wouldn't it be easier to say that the lwb4 MAY reass= emble the packet and recalculate the checksum? It's clearly not a MUST.= ..

Cheers,
Wojciech



On 14 February 2014 10:18, =A0<ian.farrer@telekom.de> wrote:
> H= i Ole,
>
>
> Thanks for the review. Please see inline. >
> Cheers,
> Ian
>
> On 11/02/2014 11:28, "= ;Ole Troan" <otroan@employe= es.org> wrote:
>
>>a few initial comments:
>>= ;
>>s/connectivity services/connectivity/
>>s/OPTION_SW46_LW/O= PTION_S46_CONT_LW/
>
> [ian] OK
>
>>
>>= section 5.1
>> =A0 An IPv6 address from an assigned prefix is also= required for the lwB4
>> =A0 to use as the encapsulation source address for the softwire. = =A0In
>> =A0 order to enable end-to-end provisioning, the IPv6 add= ress is
>> =A0 constructed by taking a /64 prefix assigned to the = WAN interface and
>> =A0 suffixing 64-bits for the interface identifier. =A0As there ma= y be
>> =A0 multiple WAN prefixes, of which only one can be used f= or lw4o6, the
>> =A0 CPE is provisioned with the logic to select t= he correct one. =A0The /
>> =A0 128 prefix is then constructed as follows:
>>
>= >that seems awfully hand-wavy?
>>how is the CPE supposed to pic= k which prefix to use? does it have to be
>>from the WAN interface= ?
>
> [ian]Yes, it=B9s built on the WAN interface. The intention is = that the CPE
> builds the tunnel from the prefix which it has just cr= eated. I guess it=B9s
> the following line that causes the hand wavin= g:
>
> As there may be multiple WAN prefixes, of which only one can b= e used for
> lw4o6, the CPE is provisioned with the logic to select t= he correct one.
>
> What about?:
>
> As there may b= e multiple WAN prefixes, of which only one can be used for
> lw4o6, the CPE creates a new WAN prefix specifically for use as the tu= nnel
> source address.
>
>
>
>>could it be= from the PD block as well?
>
> [ian] It could be from the PD b= lock if it=B9s using the PD_EXCLUDE=B9d prefix,
> but there=B9s no requirement / necessity for the device with the lwB4<= br>> function to support PD to build a tunnel. The lwB4 function could b= e
> implemented in an end host which wouldn=B9t support PD.
> >>
>>reference MAP for the interface-id? (or perhaps just st= ate that it is the
>>same)
>
> [ian] I=B9ll update to = say that it=B9s the same.
>
>>define PSID somewhere? (refere= nce MAP document)?
>
> [ian] Currently, sect 5.1 says: An lwB4 MUST support dynamic> port-restricted IPv4 address
> =A0 =A0 =A0 =A0 provisioning. = =A0The port set algorithm for provisioning this is
> =A0 =A0 =A0 =A0 = described in Section 5.1 of [I-D.ietf-softwire-map].
>
>>
>>why SHOULD the a-bits be 0? isn't that an o= perational choice?
>
> [ian]Because there=B9s no reason to use = non-0 if you=B9re not algorithmically
> mapping, it just increases th= e complexity.
>
>>
>>I really don't think overriding the ICMP ty= pe 1 code 5 is appropriate to
>>signal "no binding".
= >
> [ian] Do you think a different error ICMP error should be sent= , or that
> should be silently dropped?
>
>>do you think the BR rea= chability check from RFC5969 could be adopted
>>instead?
>> [ian] Possibly, although this would mandate that your lwAFTRs always= had
> traffic hair pinning enabled so the check could succeed.
>
&g= t; This is a common softwire problem, though. From what I can see, if there=
> were inconsistencies in the MAP provisioning domain between CEs an= d BRs,
> for any reason then it would fail with no errors being sent (although<= br>> there would be counters on the problem devices).
>
>>= ;
>>should you say something about using anycast addresses for the= AFTR?
>>
>>a general comment. we're going to have quite a bit = of redundant text
>>between the MAP documents and the LW46 documen= t, e.g. ICMP handling,
>>fragmentation. I don't have a big pro= blem with that as such, but should
>>ensure that the text isn't conflicting at least.
>
>= ; [ian] Some redundancy is inevitable. I _hope_ that by now we=B9ve ironed = out
> any conflicts - I=B9m certainly not aware of any.
>
&g= t;>
>>cheers,
>>Ole
>>
>>On 11 Feb 2014, at 8:= 54 , internet-drafts@ietf.org wrote:
>>
>>>
>>> A New Internet-Draft = is available from the on-line Internet-Drafts
>>>directories.
>>> This draft is a work item of the S= oftwires Working Group of the IETF.
>>>
>>> =A0 =A0= =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Lightweight 4over6: An Extension to the=
>>>DS-Lite Architecture
>>> =A0 =A0 =A0 =A0Authors =A0 =A0 =A0 =A0 : Yong Cui
>>&= gt; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Qiong Sun
>>= ;> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Mohamed Boucadair<= br>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Tina Tso= u
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Yiu L.= Lee
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Ian Farrer<= br>>>> =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-softwire-lw= 4over6-06.txt
>>> =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 22
= >>> =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2014-02-10
>>= ;>
>>> Abstract:
>>> =A0 Dual-Stack Lite (RFC 6333) descr= ibes an architecture for transporting
>>> =A0 IPv4 packets over= an IPv6 network. =A0This document specifies an
>>> =A0 extensi= on to DS-Lite called Lightweight 4over6 which moves the
>>> =A0 Network Address and Port Translation (NAPT) function from = the
>>> =A0 centralized DS-Lite tunnel concentrator to the tunn= el client located
>>> =A0 in the Customer Premises Equipment (C= PE). =A0This removes the
>>> =A0 requirement for a Carrier Grade NAT function in the tunnel=
>>> =A0 concentrator and reduces the amount of centralized sta= te that must be
>>> =A0 held to a per-subscriber level. =A0In o= rder to delegate the NAPT
>>> =A0 function and make IPv4 Address sharing possible, port-rest= ricted IPv4
>>> =A0 addresses are allocated to the CPEs.
>= ;>>
>>>
>>> The IETF datatracker status page = for this draft is:
>>> https://datatracker.ietf.org/doc/draft-ietf-softwire-lw4over6/=
>>>
>>> There's also a htmlized version av= ailable at:
>>> http://tools.ietf.org/html/draft-ietf-softwire-lw4over6-06
= >>>
>>> A diff from the previous version is available = at:
>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-softwire-lw4= over6-06
>>>
>>>
>>> Please note th= at it may take a couple of minutes from the time of
>>>submission
>>> until the htmlized version and diff = are available at tools.ietf.org.
&= gt;>>
>>> Internet-Drafts are also available by anonymous= FTP at:
>>> ftp://ftp.ietf= .org/internet-drafts/
>>>
>>> _________________= ______________________________
>>> Softwires mailing list
>>> Softwires@ietf.org>>> = https://www.ietf.org/mailman/listinfo/softwires
>>
>
> _______________________________________________
> Softwires mail= ing list
> Softwires@ietf.org
> http= s://www.ietf.org/mailman/listinfo/softwires
--bcaec529985f95e6df04f25e7b96-- From nobody Fri Feb 14 11:24:15 2014 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FD961A0278; Fri, 14 Feb 2014 11:24:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 nETWPNgQ4CSO; Fri, 14 Feb 2014 11:24:08 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A69061A02AF; Fri, 14 Feb 2014 11:24:08 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140214192408.14378.67935.idtracker@ietfa.amsl.com> Date: Fri, 14 Feb 2014 11:24:08 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/softwires/t7V2j6MLYzs-VIfMtwGcbhGgNtA Cc: softwires@ietf.org Subject: [Softwires] I-D Action: draft-ietf-softwire-lw4over6-07.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 19:24:11 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Softwires Working Group of the IETF. Title : Lightweight 4over6: An Extension to the DS-Lite Architecture Authors : Yong Cui Qiong Sun Mohamed Boucadair Tina Tsou Yiu L. Lee Ian Farrer Filename : draft-ietf-softwire-lw4over6-07.txt Pages : 22 Date : 2014-02-14 Abstract: Dual-Stack Lite (RFC 6333) describes an architecture for transporting IPv4 packets over an IPv6 network. This document specifies an extension to DS-Lite called Lightweight 4over6 which moves the Network Address and Port Translation (NAPT) function from the centralized DS-Lite tunnel concentrator to the tunnel client located in the Customer Premises Equipment (CPE). This removes the requirement for a Carrier Grade NAT function in the tunnel concentrator and reduces the amount of centralized state that must be held to a per-subscriber level. In order to delegate the NAPT function and make IPv4 Address sharing possible, port-restricted IPv4 addresses are allocated to the CPEs. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-softwire-lw4over6/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-softwire-lw4over6-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-softwire-lw4over6-07 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Feb 14 11:25:05 2014 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C768F1A0323 for ; Fri, 14 Feb 2014 11:25:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.548] 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 hFPvmAc5-Cvk for ; Fri, 14 Feb 2014 11:24:55 -0800 (PST) Received: from tcmail33.telekom.de (tcmail33.telekom.de [80.149.113.247]) by ietfa.amsl.com (Postfix) with ESMTP id 5C0931A02EA for ; Fri, 14 Feb 2014 11:24:53 -0800 (PST) Received: from he113656.emea1.cds.t-internal.com ([10.134.99.16]) by tcmail31.telekom.de with ESMTP/TLS/AES128-SHA; 14 Feb 2014 20:24:51 +0100 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE113656.emea1.cds.t-internal.com ([10.134.99.16]) with mapi; Fri, 14 Feb 2014 20:24:50 +0100 From: To: Date: Fri, 14 Feb 2014 20:24:48 +0100 Thread-Topic: [Softwires] I-D Action: draft-ietf-softwire-lw4over6-06.txt Thread-Index: Ac8pj7RKbh7eDpJpRimkUc61gKmhiQAKS7XA Message-ID: <8A1B81989BCFAE44A22B2B86BF2B76318A2CDB8ED2@HE111643.EMEA1.CDS.T-INTERNAL.COM> References: <20140211075445.17615.61208.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: multipart/alternative; boundary="_000_8A1B81989BCFAE44A22B2B86BF2B76318A2CDB8ED2HE111643EMEA1_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/softwires/DOhMr_wl-0B1EzDnd5dkxOvrcyQ Cc: softwires@ietf.org Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-lw4over6-06.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 19:25:02 -0000 --_000_8A1B81989BCFAE44A22B2B86BF2B76318A2CDB8ED2HE111643EMEA1_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Woj, Thanks for the review. Inline are some comments specifically related to you= r points on the new text that's been added since WGLC. Cheers, Ian Detailed comments: * Section 5.1 WAN prefix selection and address forming - as per Ole's comme= nt. This is indeed hand wavy in the current draft (how to select the WAN?) [ian] I've updated with the wording that I proposed to Ole. The CPE WAN interface is a fairly well used term in a number of other RFCs.= Both RFC6333 and RFC7084 use the term (and have implementations based on t= hem) without defining how the CPE has identified it. Why does that need to = be specifically defined here? * Processing of IPv4 fragments Section 5.2. Text " The lwB4 MAY require tha= t the UDP, TCP, or ICMP header be completely contained within the fragment = that contains fragment offset equal to zero." What does that mean? Is it trying to say that the IPv4 MTU > 40? [ian] The text is taken directly from RFC6146. I guess that doesn't specify= is as a defined MTU size of > 40 bytes (or anything else) as the IPv4 head= er could feasibly be longer than 20 bytes if options were included in it, s= o the fragmented L4 header problem could still exist. Section 5.2: " For incoming packets carrying TCP or UDP IPv4 fragments with a non- zero checksum, after de-capsulation, the lwB4 MAY elect to queue the fragments as they arrive and perform NAPT44 on all fragments at the same time" ?? Queue based on what? Presumably the fragment identifier field, and if so= then that is no different to 2473. [ian] Updated the text to note that. * Section 5.2: Text: For incoming de-capsulated IPv4 packets carrying UDP packets with a zero checksum, if the lwB4 has enough resources, the lwB4 MUST reassemble the packets and MUST calculate the checksum. If the lwB4 does not have enough resources, then it MUST silently discard the packets. Wouldn't it be easier to say that the lwb4 MAY reassemble the packet and re= calculate the checksum? It's clearly not a MUST... [ian] Why is it not a MUST? If one condition is met you MUST do this, if a = different condition is met, you MUST do that. A MAY would make re-assembly = of the packets optional, meaning that an implementation could not implement= support for fragment reassembly at all and still say that it is compliant = with the spec. Cheers, Wojciech On 14 February 2014 10:18, > wrote: > Hi Ole, > > > Thanks for the review. Please see inline. > > Cheers, > Ian > > On 11/02/2014 11:28, "Ole Troan" > wrote: > >>a few initial comments: >> >>s/connectivity services/connectivity/ >>s/OPTION_SW46_LW/OPTION_S46_CONT_LW/ > > [ian] OK > >> >>section 5.1 >> An IPv6 address from an assigned prefix is also required for the lwB4 >> to use as the encapsulation source address for the softwire. In >> order to enable end-to-end provisioning, the IPv6 address is >> constructed by taking a /64 prefix assigned to the WAN interface and >> suffixing 64-bits for the interface identifier. As there may be >> multiple WAN prefixes, of which only one can be used for lw4o6, the >> CPE is provisioned with the logic to select the correct one. The / >> 128 prefix is then constructed as follows: >> >>that seems awfully hand-wavy? >>how is the CPE supposed to pick which prefix to use? does it have to be >>from the WAN interface? > > [ian]Yes, it=B9s built on the WAN interface. The intention is that the CP= E > builds the tunnel from the prefix which it has just created. I guess it= =B9s > the following line that causes the hand waving: > > As there may be multiple WAN prefixes, of which only one can be used for > lw4o6, the CPE is provisioned with the logic to select the correct one. > > What about?: > > As there may be multiple WAN prefixes, of which only one can be used for > lw4o6, the CPE creates a new WAN prefix specifically for use as the tunne= l > source address. > > > >>could it be from the PD block as well? > > [ian] It could be from the PD block if it=B9s using the PD_EXCLUDE=B9d pr= efix, > but there=B9s no requirement / necessity for the device with the lwB4 > function to support PD to build a tunnel. The lwB4 function could be > implemented in an end host which wouldn=B9t support PD. > >> >>reference MAP for the interface-id? (or perhaps just state that it is the >>same) > > [ian] I=B9ll update to say that it=B9s the same. > >>define PSID somewhere? (reference MAP document)? > > [ian] Currently, sect 5.1 says: An lwB4 MUST support dynamic > port-restricted IPv4 address > provisioning. The port set algorithm for provisioning this is > described in Section 5.1 of [I-D.ietf-softwire-map]. > >> >>why SHOULD the a-bits be 0? isn't that an operational choice? > > [ian]Because there=B9s no reason to use non-0 if you=B9re not algorithmic= ally > mapping, it just increases the complexity. > >> >>I really don't think overriding the ICMP type 1 code 5 is appropriate to >>signal "no binding". > > [ian] Do you think a different error ICMP error should be sent, or that > should be silently dropped? > >>do you think the BR reachability check from RFC5969 could be adopted >>instead? > > [ian] Possibly, although this would mandate that your lwAFTRs always had > traffic hair pinning enabled so the check could succeed. > > This is a common softwire problem, though. From what I can see, if there > were inconsistencies in the MAP provisioning domain between CEs and BRs, > for any reason then it would fail with no errors being sent (although > there would be counters on the problem devices). > >> >>should you say something about using anycast addresses for the AFTR? >> >>a general comment. we're going to have quite a bit of redundant text >>between the MAP documents and the LW46 document, e.g. ICMP handling, >>fragmentation. I don't have a big problem with that as such, but should >>ensure that the text isn't conflicting at least. > > [ian] Some redundancy is inevitable. I _hope_ that by now we=B9ve ironed = out > any conflicts - I=B9m certainly not aware of any. > >> >>cheers, >>Ole >> >>On 11 Feb 2014, at 8:54 , internet-drafts@ietf.org wrote: >> >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>>directories. >>> This draft is a work item of the Softwires Working Group of the IETF. >>> >>> Title : Lightweight 4over6: An Extension to the >>>DS-Lite Architecture >>> Authors : Yong Cui >>> Qiong Sun >>> Mohamed Boucadair >>> Tina Tsou >>> Yiu L. Lee >>> Ian Farrer >>> Filename : draft-ietf-softwire-lw4over6-06.txt >>> Pages : 22 >>> Date : 2014-02-10 >>> >>> Abstract: >>> Dual-Stack Lite (RFC 6333) describes an architecture for transporting >>> IPv4 packets over an IPv6 network. This document specifies an >>> extension to DS-Lite called Lightweight 4over6 which moves the >>> Network Address and Port Translation (NAPT) function from the >>> centralized DS-Lite tunnel concentrator to the tunnel client located >>> in the Customer Premises Equipment (CPE). This removes the >>> requirement for a Carrier Grade NAT function in the tunnel >>> concentrator and reduces the amount of centralized state that must be >>> held to a per-subscriber level. In order to delegate the NAPT >>> function and make IPv4 Address sharing possible, port-restricted IPv4 >>> addresses are allocated to the CPEs. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-softwire-lw4over6/ >>> >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-ietf-softwire-lw4over6-06 >>> >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-softwire-lw4over6-06 >>> >>> >>> 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. >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> _______________________________________________ >>> Softwires mailing list >>> Softwires@ietf.org >>> https://www.ietf.org/mailman/listinfo/softwires >> > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires --_000_8A1B81989BCFAE44A22B2B86BF2B76318A2CDB8ED2HE111643EMEA1_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Woj,

 

Thanks fo= r the review. Inline are some comments specifically related to your points = on the new text that’s been added since WGLC.

 

Cheers,

Ian

 <= /p>

Detailed comments:

* Sect= ion 5.1 WAN prefix selection and address forming - as per Ole's comment. This is indeed hand wavy in the current draft (how to select the WAN?)=

[ian] I’ve updated with the wording that I proposed to Ol= e.

The CPE WAN interface is= a fairly well used term in a number of other RFCs. Both RFC6333 and RFC708= 4 use the term (and have implementations based on them) without defining ho= w the CPE has identified it. Why does that need to be specifically defined = here?

&n= bsp;

* = Processing of IPv4 fragments Section 5.2. Text " The lwB4 MAY r= equire that the UDP, TCP, or ICMP header be completely contained within the= fragment that contains fragment offset equal to zero."

=

What does that mean? Is it trying to say that th= e IPv4 MTU > 40?

 

[ian= ] The text is taken directly from RFC6146. I guess that doesn’t speci= fy is as a defined MTU size of > 40 bytes (or anything else) as the IPv4= header could feasibly be longer than 20 bytes if options were included in = it, so the fragmented L4 header problem could still exist.

 

<= p class=3DMsoNormal>Section 5.2: "

For incoming pac=
kets carrying TCP or UDP IPv4 fragments with a non-
=
=A0=A0 zero checksum, after de-capsulation, the lwB4 MAY elect to queue the=

=A0=A0 fragments as they arrive and perform NAPT44 on=
 all fragments at the
=A0=A0 same time"
?? Queue based on what? Presumably the fragment identifier fiel=
d, and if so then that is no different to 2473.
 

[ian] Updated the= text to note that.

&nbs=
p;

* Section 5.2: Text:

For incoming de-capsulated IPv4 packets carrying UDP packets with a<=
o:p>
=A0=A0 zero checksum, if the lwB4 has enough resources=
, the lwB4 MUST
=A0=A0 reassemble the packets and MUST=
 calculate the checksum.=A0 If the lwB4
=A0=A0 does no=
t have enough resources, then it MUST silently discard the
= 
=A0=A0 packets.=A0

Wouldn't it b= e easier to say that the lwb4 MAY reassemble the packet and recalculate the= checksum? It's clearly not a MUST...

 <= /o:p>

[ian] Why is it not a MUST? If o= ne condition is met you MUST do this, if a different condition is met, you = MUST do that. A MAY would make re-assembly of the packets optional, meaning= that an implementation could not implement support for fragment reassembly= at all and still say that it is compliant with the spec.=

 

Cheers,

Wojciech



On 14 February 2014 10:18,  <ian.farrer@telekom.de> wrote:> Hi Ole,
>
>
> Thanks for the review. Please see inl= ine.
>
> Cheers,
> Ian
>
> On 11/02/2014 11:2= 8, "Ole Troan" <otroan= @employees.org> wrote:
>
>>a few initial comments:>>
>>s/connectivity services/connectivity/
>>s/OPT= ION_SW46_LW/OPTION_S46_CONT_LW/
>
> [ian] OK
>
>>= ;
>>section 5.1
>>   An IPv6 address from an assigne= d prefix is also required for the lwB4
>>   to use as the enc= apsulation source address for the softwire.  In
>>   ord= er to enable end-to-end provisioning, the IPv6 address is
>>  = ; constructed by taking a /64 prefix assigned to the WAN interface and
&= gt;>   suffixing 64-bits for the interface identifier.  As the= re may be
>>   multiple WAN prefixes, of which only one can b= e used for lw4o6, the
>>   CPE is provisioned with the logic = to select the correct one.  The /
>>   128 prefix is the= n constructed as follows:
>>
>>that seems awfully hand-wa= vy?
>>how is the CPE supposed to pick which prefix to use? does it= have to be
>>from the WAN interface?
>
> [ian]Yes, it= =B9s built on the WAN interface. The intention is that the CPE
> buil= ds the tunnel from the prefix which it has just created. I guess it=B9s
= > the following line that causes the hand waving:
>
> As the= re may be multiple WAN prefixes, of which only one can be used for
> = lw4o6, the CPE is provisioned with the logic to select the correct one.
= >
> What about?:
>
> As there may be multiple WAN pref= ixes, of which only one can be used for
> lw4o6, the CPE creates a ne= w WAN prefix specifically for use as the tunnel
> source address.
= >
>
>
>>could it be from the PD block as well?
&= gt;
> [ian] It could be from the PD block if it=B9s using the PD_EXCL= UDE=B9d prefix,
> but there=B9s no requirement / necessity for the de= vice with the lwB4
> function to support PD to build a tunnel. The lw= B4 function could be
> implemented in an end host which wouldn=B9t su= pport PD.
>
>>
>>reference MAP for the interface-id= ? (or perhaps just state that it is the
>>same)
>
> [i= an] I=B9ll update to say that it=B9s the same.
>
>>define PS= ID somewhere? (reference MAP document)?
>
> [ian] Currently, se= ct 5.1 says: An lwB4 MUST support dynamic
> port-restricted IPv4 addr= ess
>         provisioning.  The port set al= gorithm for provisioning this is
>         descri= bed in Section 5.1 of [I-D.ietf-softwire-map].
>
>>
>&= gt;why SHOULD the a-bits be 0? isn't that an operational choice?
>> [ian]Because there=B9s no reason to use non-0 if you=B9re not algorit= hmically
> mapping, it just increases the complexity.
>
>= >
>>I really don't think overriding the ICMP type 1 code 5 is a= ppropriate to
>>signal "no binding".
>
> [ia= n] Do you think a different error ICMP error should be sent, or that
>= ; should be silently dropped?
>
>>do you think the BR reacha= bility check from RFC5969 could be adopted
>>instead?
>
&= gt; [ian] Possibly, although this would mandate that your lwAFTRs always ha= d
> traffic hair pinning enabled so the check could succeed.
><= br>> This is a common softwire problem, though. From what I can see, if = there
> were inconsistencies in the MAP provisioning domain between C= Es and BRs,
> for any reason then it would fail with no errors being = sent (although
> there would be counters on the problem devices).
= >
>>
>>should you say something about using anycast ad= dresses for the AFTR?
>>
>>a general comment. we're going= to have quite a bit of redundant text
>>between the MAP documents= and the LW46 document, e.g. ICMP handling,
>>fragmentation. I don= 't have a big problem with that as such, but should
>>ensure that = the text isn't conflicting at least.
>
> [ian] Some redundancy = is inevitable. I _hope_ that by now we=B9ve ironed out
> any conflict= s - I=B9m certainly not aware of any.
>
>>
>>cheers= ,
>>Ole
>>
>>On 11 Feb 2014, at 8:54 , internet-drafts@ietf.org wrote:>>
>>>
>>> A New Internet-Draft is available= from the on-line Internet-Drafts
>>>directories.
>>&g= t; This draft is a work item of the Softwires Working Group of the IETF.>>>
>>>        Title    = ;       : Lightweight 4over6: An Extension to the
>>= ;>DS-Lite Architecture
>>>        Author= s         : Yong Cui
>>>     &nbs= p;                    Qio= ng Sun
>>>               &nb= sp;          Mohamed Boucadair
>>> &nb= sp;                     &= nbsp;  Tina Tsou
>>>           &n= bsp;              Yiu L. Lee
>>= >                     =      Ian Farrer
>>>      Filename=        : draft-ietf-softwire-lw4over6-06.txt
>&g= t;>      Pages           : 22>>>      Date           &= nbsp;: 2014-02-10
>>>
>>> Abstract:
>>>=   Dual-Stack Lite (RFC 6333) describes an architecture for transporti= ng
>>>   IPv4 packets over an IPv6 network.  This doc= ument specifies an
>>>   extension to DS-Lite called Light= weight 4over6 which moves the
>>>   Network Address and Po= rt Translation (NAPT) function from the
>>>   centralized = DS-Lite tunnel concentrator to the tunnel client located
>>> &n= bsp; in the Customer Premises Equipment (CPE).  This removes the
&g= t;>>   requirement for a Carrier Grade NAT function in the tunne= l
>>>   concentrator and reduces the amount of centralized= state that must be
>>>   held to a per-subscriber level. =  In order to delegate the NAPT
>>>   function and mak= e IPv4 Address sharing possible, port-restricted IPv4
>>>  = ; addresses are allocated to the CPEs.
>>>
>>>
&= gt;>> The IETF datatracker status page for this draft is:
>>= > https://datatracker.ietf.org/doc/draft-ietf-softwire-lw4over6/
= >>>
>>> There's also a htmlized version available at:<= br>>>> http://tools.ietf.org/html/draft-ietf-softwire-lw4over6-06<= br>>>>
>>> A diff from the previous version is availab= le at:
>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-so= ftwire-lw4over6-06
>>>
>>>
>>> Plea= se note that it may take a couple of minutes from the time of
>>&g= t;submission
>>> until the htmlized version and diff are availa= ble at tools.ietf.org.
>>>= ;
>>> Internet-Drafts are also available by anonymous FTP at:>>> ftp://ftp.ie= tf.org/internet-drafts/
>>>
>>> _______________= ________________________________
>>> Softwires mailing list
= >>> Softwires@ietf.org>>> = https://www.ietf.org/mailman/listinfo/softwires
>>
>
= > _______________________________________________
> Softwires mail= ing list
> Softwires@ietf.org
> http= s://www.ietf.org/mailman/listinfo/softwires

<= /div>
= --_000_8A1B81989BCFAE44A22B2B86BF2B76318A2CDB8ED2HE111643EMEA1_-- From nobody Sun Feb 16 08:32:22 2014 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0CA41A002C for ; Sun, 16 Feb 2014 08:32:21 -0800 (PST) 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 zd0FyVcY_N1J for ; Sun, 16 Feb 2014 08:32:16 -0800 (PST) Received: from mail-pd0-x233.google.com (mail-pd0-x233.google.com [IPv6:2607:f8b0:400e:c02::233]) by ietfa.amsl.com (Postfix) with ESMTP id 46F551A0105 for ; Sun, 16 Feb 2014 08:32:16 -0800 (PST) Received: by mail-pd0-f179.google.com with SMTP id fp1so13522889pdb.38 for ; Sun, 16 Feb 2014 08:32:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6puqtcfTOzc438XBkVaX9bglWYGzqIU6/yVyBGCODS0=; b=UYI2s7X3//nZAGHpqm2LxFznwBEEP+c+9zAAra5WFuu1VkJfIDHB45FgZoiHjHiElQ FRWwPd7yR1rNMVHZ2WaRuplTTF+iMGGwjVGaovqCslH/4Q+NsDgQzRF9N6kIlS37zL1x o6KsFeUECWmp5788ur2/IqdyswPQalHFPTx4tRtQs+HzdsE0IRIvK6zXzK3Xb8mAbDaY WBX5CoC8pbUqGxwprjTeSx1r3h/9PrB3N/qOXV2grM5viJMBbv2UhsMXiK3u5pfhu9mg o2GOVjJ6V9YM/6schncPNZ0Lo67ia50jK1Z1abgyPr87CT8bfSNYE2NRcBvgR48X2Ecw yEYw== MIME-Version: 1.0 X-Received: by 10.66.149.231 with SMTP id ud7mr21710194pab.8.1392568334132; Sun, 16 Feb 2014 08:32:14 -0800 (PST) Received: by 10.70.1.70 with HTTP; Sun, 16 Feb 2014 08:32:14 -0800 (PST) In-Reply-To: <8A1B81989BCFAE44A22B2B86BF2B76318A2CDB8ED2@HE111643.EMEA1.CDS.T-INTERNAL.COM> References: <20140211075445.17615.61208.idtracker@ietfa.amsl.com> <8A1B81989BCFAE44A22B2B86BF2B76318A2CDB8ED2@HE111643.EMEA1.CDS.T-INTERNAL.COM> Date: Sun, 16 Feb 2014 17:32:14 +0100 Message-ID: From: Wojciech Dec To: "ian.farrer@telekom.de" Content-Type: multipart/alternative; boundary=047d7b6d95d0e1acec04f2889408 Archived-At: http://mailarchive.ietf.org/arch/msg/softwires/2YKh-pHouipDG7Dsj13GvqPRf-Q Cc: Softwires-wg Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-lw4over6-06.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Feb 2014 16:32:22 -0000 --047d7b6d95d0e1acec04f2889408 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Ian, you haven't replied on my high level comment - would appreciate if you introduced changes to that effect in the draft. Continued inline... On 14 February 2014 20:24, wrote: > Hi Woj, > > > > Thanks for the review. Inline are some comments specifically related to > your points on the new text that's been added since WGLC. > > > > Cheers, > > Ian > > > > Detailed comments: > > * Section 5.1 WAN prefix selection and address forming - as per Ole's > comment. This is indeed hand wavy in the current draft (how to select the > WAN?) > > [ian] I've updated with the wording that I proposed to Ole. > > The CPE WAN interface is a fairly well used term in a number of other > RFCs. Both RFC6333 and RFC7084 use the term (and have implementations bas= ed > on them) without defining how the CPE has identified it. Why does that ne= ed > to be specifically defined here? > Woj> What is the WAN interface is, and how should the CPE "find it" not said. That other drafts fail to clarify that doesn't make it quite right... > > > * Processing of IPv4 fragments Section 5.2. Text " The lwB4 MAY require > that the UDP, TCP, or ICMP header be completely contained within the > fragment that contains fragment offset equal to zero." > > What does that mean? Is it trying to say that the IPv4 MTU > 40? > > > > [ian] The text is taken directly from RFC6146. I guess that doesn't > specify is as a defined MTU size of > 40 bytes (or anything else) as the > IPv4 header could feasibly be longer than 20 bytes if options were includ= ed > in it, so the fragmented L4 header problem could still exist. > Here we're talking about tunneling, and I cannot see a case whereby the IPv4 TCP/UDP header would get fragmented, unless the MTU of the IPv6 tunnel was <40. rfc6146 is about translation where other effects come to apply. > > > Section 5.2: " > > For incoming packets carrying TCP or UDP IPv4 fragments with a non- > > zero checksum, after de-capsulation, the lwB4 MAY elect to queue the > > fragments as they arrive and perform NAPT44 on all fragments at the > > same time" > > ?? Queue based on what? Presumably the fragment identifier field, and if = so then that is no different to 2473. > > > > [ian] Updated the text to note that. > Ok, but in essence, it would be actually better removing the text since it adds nothing above 2473. > > > * Section 5.2: Text: > > For incoming de-capsulated IPv4 packets carrying UDP packets with a > > zero checksum, if the lwB4 has enough resources, the lwB4 MUST > > reassemble the packets and MUST calculate the checksum. If the lwB4 > > does not have enough resources, then it MUST silently discard the > > packets. > > Wouldn't it be easier to say that the lwb4 MAY reassemble the packet and > recalculate the checksum? It's clearly not a MUST... > > > > [ian] Why is it not a MUST? If one condition is met you MUST do this, if = a > different condition is met, you MUST do that. A MAY would make re-assembl= y > of the packets optional, meaning that an implementation could not impleme= nt > support for fragment reassembly at all and still say that it is compliant > with the spec. > If it were a MUST then something would horribly break if it were not done. The above clearly says that this reassembly operation is at the discretion of the device, subject to an arbitrary "enough resources" condition. If you'd like it to be a MUST then the condition should be removed. Cheers, Wojciech. > > > Cheers, > > Wojciech > > > > On 14 February 2014 10:18, wrote: > > Hi Ole, > > > > > > Thanks for the review. Please see inline. > > > > Cheers, > > Ian > > > > On 11/02/2014 11:28, "Ole Troan" wrote: > > > >>a few initial comments: > >> > >>s/connectivity services/connectivity/ > >>s/OPTION_SW46_LW/OPTION_S46_CONT_LW/ > > > > [ian] OK > > > >> > >>section 5.1 > >> An IPv6 address from an assigned prefix is also required for the lwB= 4 > >> to use as the encapsulation source address for the softwire. In > >> order to enable end-to-end provisioning, the IPv6 address is > >> constructed by taking a /64 prefix assigned to the WAN interface and > >> suffixing 64-bits for the interface identifier. As there may be > >> multiple WAN prefixes, of which only one can be used for lw4o6, the > >> CPE is provisioned with the logic to select the correct one. The / > >> 128 prefix is then constructed as follows: > >> > >>that seems awfully hand-wavy? > >>how is the CPE supposed to pick which prefix to use? does it have to be > >>from the WAN interface? > > > > [ian]Yes, it=B9s built on the WAN interface. The intention is that the = CPE > > builds the tunnel from the prefix which it has just created. I guess it= =B9s > > the following line that causes the hand waving: > > > > As there may be multiple WAN prefixes, of which only one can be used fo= r > > lw4o6, the CPE is provisioned with the logic to select the correct one. > > > > What about?: > > > > As there may be multiple WAN prefixes, of which only one can be used fo= r > > lw4o6, the CPE creates a new WAN prefix specifically for use as the > tunnel > > source address. > > > > > > > >>could it be from the PD block as well? > > > > [ian] It could be from the PD block if it=B9s using the PD_EXCLUDE=B9d > prefix, > > but there=B9s no requirement / necessity for the device with the lwB4 > > function to support PD to build a tunnel. The lwB4 function could be > > implemented in an end host which wouldn=B9t support PD. > > > >> > >>reference MAP for the interface-id? (or perhaps just state that it is t= he > >>same) > > > > [ian] I=B9ll update to say that it=B9s the same. > > > >>define PSID somewhere? (reference MAP document)? > > > > [ian] Currently, sect 5.1 says: An lwB4 MUST support dynamic > > port-restricted IPv4 address > > provisioning. The port set algorithm for provisioning this is > > described in Section 5.1 of [I-D.ietf-softwire-map]. > > > >> > >>why SHOULD the a-bits be 0? isn't that an operational choice? > > > > [ian]Because there=B9s no reason to use non-0 if you=B9re not algorithm= ically > > mapping, it just increases the complexity. > > > >> > >>I really don't think overriding the ICMP type 1 code 5 is appropriate t= o > >>signal "no binding". > > > > [ian] Do you think a different error ICMP error should be sent, or that > > should be silently dropped? > > > >>do you think the BR reachability check from RFC5969 could be adopted > >>instead? > > > > [ian] Possibly, although this would mandate that your lwAFTRs always ha= d > > traffic hair pinning enabled so the check could succeed. > > > > This is a common softwire problem, though. From what I can see, if ther= e > > were inconsistencies in the MAP provisioning domain between CEs and BRs= , > > for any reason then it would fail with no errors being sent (although > > there would be counters on the problem devices). > > > >> > >>should you say something about using anycast addresses for the AFTR? > >> > >>a general comment. we're going to have quite a bit of redundant text > >>between the MAP documents and the LW46 document, e.g. ICMP handling, > >>fragmentation. I don't have a big problem with that as such, but should > >>ensure that the text isn't conflicting at least. > > > > [ian] Some redundancy is inevitable. I _hope_ that by now we=B9ve irone= d > out > > any conflicts - I=B9m certainly not aware of any. > > > >> > >>cheers, > >>Ole > >> > >>On 11 Feb 2014, at 8:54 , internet-drafts@ietf.org wrote: > >> > >>> > >>> A New Internet-Draft is available from the on-line Internet-Drafts > >>>directories. > >>> This draft is a work item of the Softwires Working Group of the IETF. > >>> > >>> Title : Lightweight 4over6: An Extension to the > >>>DS-Lite Architecture > >>> Authors : Yong Cui > >>> Qiong Sun > >>> Mohamed Boucadair > >>> Tina Tsou > >>> Yiu L. Lee > >>> Ian Farrer > >>> Filename : draft-ietf-softwire-lw4over6-06.txt > >>> Pages : 22 > >>> Date : 2014-02-10 > >>> > >>> Abstract: > >>> Dual-Stack Lite (RFC 6333) describes an architecture for transporti= ng > >>> IPv4 packets over an IPv6 network. This document specifies an > >>> extension to DS-Lite called Lightweight 4over6 which moves the > >>> Network Address and Port Translation (NAPT) function from the > >>> centralized DS-Lite tunnel concentrator to the tunnel client locate= d > >>> in the Customer Premises Equipment (CPE). This removes the > >>> requirement for a Carrier Grade NAT function in the tunnel > >>> concentrator and reduces the amount of centralized state that must = be > >>> held to a per-subscriber level. In order to delegate the NAPT > >>> function and make IPv4 Address sharing possible, port-restricted IP= v4 > >>> addresses are allocated to the CPEs. > >>> > >>> > >>> The IETF datatracker status page for this draft is: > >>> https://datatracker.ietf.org/doc/draft-ietf-softwire-lw4over6/ > >>> > >>> There's also a htmlized version available at: > >>> http://tools.ietf.org/html/draft-ietf-softwire-lw4over6-06 > >>> > >>> A diff from the previous version is available at: > >>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-softwire-lw4over6-06 > >>> > >>> > >>> 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. > >>> > >>> Internet-Drafts are also available by anonymous FTP at: > >>> ftp://ftp.ietf.org/internet-drafts/ > >>> > >>> _______________________________________________ > >>> Softwires mailing list > >>> Softwires@ietf.org > >>> https://www.ietf.org/mailman/listinfo/softwires > >> > > > > _______________________________________________ > > Softwires mailing list > > Softwires@ietf.org > > https://www.ietf.org/mailman/listinfo/softwires > --047d7b6d95d0e1acec04f2889408 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Ian,

you haven't replied on = my high level comment - would appreciate if you introduced changes to that = effect in the draft.

Continued inline...


On 14 February 2014 20:24, <ian.fa= rrer@telekom.de> wrote:

Hi Woj,

 <= /p>

Th= anks for the review. Inline are some comments specifically related to your = points on the new text that’s been added since WGLC.

 

Cheers,

Ian

 

Detailed comments:
=
* Section 5.1 WAN prefix selection and address forming - as per Ole'= ;s comment. This is indeed hand wavy in the current draft (how to se= lect the WAN?)

[ian] I’ve updated wi= th the wording that I proposed to Ole.

The CPE WAN interface is= a fairly well used term in a number of other RFCs. Both RFC6333 and RFC708= 4 use the term (and have implementations based on them) without defining ho= w the CPE has identified it. Why does that need to be specifically defined = here?


= Woj>  What is the WAN interface is, and how should the CPE "fi= nd it" not said. That other drafts fail to clarify that doesn't ma= ke it quite right...

 

* Processing of IPv4 fragments Section 5.2. T= ext " The lwB4 MAY require that the UDP, TCP, or ICMP header be comple= tely contained within the fragment that contains fragment offset equal to z= ero."

What does that mean? Is = it trying to say that the IPv4 MTU > 40?

 <= /u>

[ian] The text is taken = directly from RFC6146. I guess that doesn’t specify is as a defined M= TU size of > 40 bytes (or anything else) as the IPv4 header could feasib= ly be longer than 20 bytes if options were included in it, so the fragmente= d L4 header problem could still exist.


Here we're talking a= bout tunneling, and I cannot see a case whereby the IPv4 TCP/UDP header wou= ld get fragmented, unless the MTU of the IPv6 tunnel was <40. rfc6146 is= about translation where other effects come to apply.

 

Section 5.= 2: "

For incoming packets carrying TCP or UDP IPv4 fragments with a non-=

   zero checksum, after de-capsulation, the=
 lwB4 MAY elect to queue the
   fragments=
 as they arrive and perform NAPT44 on all fragments at the

   same time"
?? Queue based on=
 what? Presumably the fragment identifier field, and if so then that is no =
different to 2473.
=
 

[ian] Updated the = text to note that.


=
Ok, but in essence, it would be actually better removing the text since it = adds nothing above 2473.

= 
 

* Section 5.2: Text:

For incom=
ing de-capsulated IPv4 packets carrying UDP packets with a
   zero checksum, if the lwB4 has enough resources, the l=
wB4 MUST


   reassemble the packets and MUST calculate the checksum.&n=
bsp; If the lwB4
   does not have enough =
resources, then it MUST silently discard the
 =
  packets.  


Wouldn't it be easier to say that the lwb4 MAY r=
eassemble the packet and recalculate the checksum? It's clearly not a M=
UST...

 

[ian] Why is it not a MUST? If = one condition is met you MUST do this, if a different condition is met, you= MUST do that. A MAY would make re-assembly of the packets optional, meanin= g that an implementation could not implement support for fragment reassembl= y at all and still say that it is compliant with the spec.


If it were a MUST then something would horribly break if = it were not done. The above clearly says that this reassembly operation is = at the discretion of the device,  subject to an arbitrary "enough= resources" condition. If you'd like it to be a MUST then the cond= ition should be removed.

Cheers,
Wojciech.
 

 

Cheers,<= /u>

Wojciech



On 14 Febr= uary 2014 10:18,  <ian.farrer@telekom.de> wrote:
> Hi Ole,
>
>
> Thanks for the review. Please see inli= ne.
>
> Cheers,
> Ian
>
> On 11/02/2014 11:28= , "Ole Troan" <otroan@employees.org> wrote:
>
>>a few initial comments:
>>
>>s/connectivi= ty services/connectivity/
>>s/OPTION_SW46_LW/OPTION_S46_CONT_LW/>
> [ian] OK
>
>>
>>section 5.1
>&= gt;   An IPv6 address from an assigned prefix is also required for the= lwB4
>>   to use as the encapsulation source address for the softwire= .  In
>>   order to enable end-to-end provisioning, the = IPv6 address is
>>   constructed by taking a /64 prefix assig= ned to the WAN interface and
>>   suffixing 64-bits for the interface identifier.  As th= ere may be
>>   multiple WAN prefixes, of which only one can = be used for lw4o6, the
>>   CPE is provisioned with the logic= to select the correct one.  The /
>>   128 prefix is then constructed as follows:
>>
&= gt;>that seems awfully hand-wavy?
>>how is the CPE supposed to = pick which prefix to use? does it have to be
>>from the WAN interf= ace?
>
> [ian]Yes, it=B9s built on the WAN interface. The intention is = that the CPE
> builds the tunnel from the prefix which it has just cr= eated. I guess it=B9s
> the following line that causes the hand wavin= g:
>
> As there may be multiple WAN prefixes, of which only one can b= e used for
> lw4o6, the CPE is provisioned with the logic to select t= he correct one.
>
> What about?:
>
> As there may b= e multiple WAN prefixes, of which only one can be used for
> lw4o6, the CPE creates a new WAN prefix specifically for use as the tu= nnel
> source address.
>
>
>
>>could it be= from the PD block as well?
>
> [ian] It could be from the PD b= lock if it=B9s using the PD_EXCLUDE=B9d prefix,
> but there=B9s no requirement / necessity for the device with the lwB4<= br>> function to support PD to build a tunnel. The lwB4 function could b= e
> implemented in an end host which wouldn=B9t support PD.
> >>
>>reference MAP for the interface-id? (or perhaps just st= ate that it is the
>>same)
>
> [ian] I=B9ll update to = say that it=B9s the same.
>
>>define PSID somewhere? (refere= nce MAP document)?
>
> [ian] Currently, sect 5.1 says: An lwB4 MUST support dynamic> port-restricted IPv4 address
>         pro= visioning.  The port set algorithm for provisioning this is
> &n= bsp;       described in Section 5.1 of [I-D.ietf-softwire-ma= p].
>
>>
>>why SHOULD the a-bits be 0? isn't that an o= perational choice?
>
> [ian]Because there=B9s no reason to use = non-0 if you=B9re not algorithmically
> mapping, it just increases th= e complexity.
>
>>
>>I really don't think overriding the ICMP ty= pe 1 code 5 is appropriate to
>>signal "no binding".
= >
> [ian] Do you think a different error ICMP error should be sent= , or that
> should be silently dropped?
>
>>do you think the BR rea= chability check from RFC5969 could be adopted
>>instead?
>> [ian] Possibly, although this would mandate that your lwAFTRs always= had
> traffic hair pinning enabled so the check could succeed.
>
&g= t; This is a common softwire problem, though. From what I can see, if there=
> were inconsistencies in the MAP provisioning domain between CEs an= d BRs,
> for any reason then it would fail with no errors being sent (although<= br>> there would be counters on the problem devices).
>
>>= ;
>>should you say something about using anycast addresses for the= AFTR?
>>
>>a general comment. we're going to have quite a bit = of redundant text
>>between the MAP documents and the LW46 documen= t, e.g. ICMP handling,
>>fragmentation. I don't have a big pro= blem with that as such, but should
>>ensure that the text isn't conflicting at least.
>
>= ; [ian] Some redundancy is inevitable. I _hope_ that by now we=B9ve ironed = out
> any conflicts - I=B9m certainly not aware of any.
>
&g= t;>
>>cheers,
>>Ole
>>
>>On 11 Feb 2014, at 8:= 54 , internet= -drafts@ietf.org wrote:
>>
>>>
>>> A N= ew Internet-Draft is available from the on-line Internet-Drafts
>>>directories.
>>> This draft is a work item of the S= oftwires Working Group of the IETF.
>>>
>>>   =      Title           : Lightweight = 4over6: An Extension to the
>>>DS-Lite Architecture
>>>        Authors        = : Yong Cui
>>>              = ;            Qiong Sun
>>>  =                     &nbs= p;  Mohamed Boucadair
>>>         &nbs= p;                Tina Tsou
>= >>                   &nb= sp;      Yiu L. Lee
>>>                  =        Ian Farrer
>>>      = Filename        : draft-ietf-softwire-lw4over6-06.txt>>>      Pages          = : 22
>>>      Date         =    : 2014-02-10
>>>
>>> Abstract:
>>>   Dual-Stack Lite (RFC 6333) de= scribes an architecture for transporting
>>>   IPv4 packet= s over an IPv6 network.  This document specifies an
>>> &n= bsp; extension to DS-Lite called Lightweight 4over6 which moves the
>>>   Network Address and Port Translation (NAPT) function fr= om the
>>>   centralized DS-Lite tunnel concentrator to th= e tunnel client located
>>>   in the Customer Premises Equ= ipment (CPE).  This removes the
>>>   requirement for a Carrier Grade NAT function in the tun= nel
>>>   concentrator and reduces the amount of centraliz= ed state that must be
>>>   held to a per-subscriber level= .  In order to delegate the NAPT
>>>   function and make IPv4 Address sharing possible, port-r= estricted IPv4
>>>   addresses are allocated to the CPEs.<= br>>>>
>>>
>>> The IETF datatracker status= page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-ietf-= softwire-lw4over6/
>>>
>>> There's also a h= tmlized version available at:
>>> http://tools.ietf.org/html/draft-ietf-softwire-l= w4over6-06
>>>
>>> A diff from the previous ver= sion is available at:
>>> http://www.ietf.org/rfcdiff?url2=3Ddraft= -ietf-softwire-lw4over6-06
>>>
>>>
>>&= gt; 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.
>>>
>>> Internet-Drafts are also avai= lable by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>>
>>>= _______________________________________________
>>> Softwires = mailing list
>>> Softwi= res@ietf.org
>>> https://www.ietf.org/mailman/listinfo/s= oftwires
>>
>
> _______________________________________________> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/ma= ilman/listinfo/softwires


--047d7b6d95d0e1acec04f2889408-- From nobody Sun Feb 16 11:39:56 2014 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9AD11A0265 for ; Sun, 16 Feb 2014 11:39:55 -0800 (PST) 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 nrR2xU3d5ZCd for ; Sun, 16 Feb 2014 11:39:53 -0800 (PST) Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d:c04::233]) by ietfa.amsl.com (Postfix) with ESMTP id 987E31A0262 for ; Sun, 16 Feb 2014 11:39:53 -0800 (PST) Received: by mail-qg0-f51.google.com with SMTP id q108so3834096qgd.10 for ; Sun, 16 Feb 2014 11:39:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=9sOt+bYmrmZNScoDhmQJjGxp5oySRLMIwOf3odP8Vps=; b=ZPTGxYSuHM75mAV77GGHSNvtlqMp2yzgqmBcQ9o4jo5KQjZZh7L4cqMFVvbcZemSeK HFjoQ5UABa2BzXO8BgAG9fXq5hO85Fjqh11Jk7celKx359syIuqDu6bGinAP2XQEpZ2H 2NrgkiYBamRoFqeAAvdvrqaHJz9pozzS8HUqZHm0MSgU1Z7WWSnwzP13h46Bzl4kPDYb mpcKrjeIeYNr4q6UwBil3mISSunyCAkB27zbRYhVvdqnzrEdAiBrrIAa07WONpXRVcgK R1G/4Dpz+dPIYqgSD9RokGmA/UJgJZDyAI9vismF3K6awXLKvfZ9Lsl0zxdamkGvFVU6 p/lw== X-Received: by 10.224.103.66 with SMTP id j2mr18710918qao.13.1392579591011; Sun, 16 Feb 2014 11:39:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.96.92.35 with HTTP; Sun, 16 Feb 2014 11:39:30 -0800 (PST) In-Reply-To: <20140214164219.10575.89835.idtracker@ietfa.amsl.com> References: <20140214164219.10575.89835.idtracker@ietfa.amsl.com> From: Cong Liu Date: Mon, 17 Feb 2014 03:39:30 +0800 Message-ID: To: softwires Content-Type: multipart/alternative; boundary=047d7b67001fd8023904f28b33d3 Archived-At: http://mailarchive.ietf.org/arch/msg/softwires/YGn-oKiJiAyKQWBHU4_tG_b01YM Subject: [Softwires] Fwd: New Version Notification for draft-liu-softwire-ce-comm-shared-addr-00.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Feb 2014 19:39:56 -0000 --047d7b67001fd8023904f28b33d3 Content-Type: text/plain; charset=ISO-8859-1 Hi all, We submitted a new draft about an issue on IPv4 communication between two Softwire CEs with the same IPv4 addr and different port set. Any comments are appreciate. Best Wishes, Cong ---------- Forwarded message ---------- From: Date: 2014-02-15 0:42 GMT+08:00 Subject: New Version Notification for draft-liu-softwire-ce-comm-shared-addr-00.txt To: Jianping Wu , Cong Liu A new version of I-D, draft-liu-softwire-ce-comm-shared-addr-00.txt has been successfully submitted by Cong Liu and posted to the IETF repository. Name: draft-liu-softwire-ce-comm-shared-addr Revision: 00 Title: Communication between Softwire CEs with shared addresses Document date: 2014-02-14 Group: Individual Submission Pages: 5 URL: http://www.ietf.org/internet-drafts/draft-liu-softwire-ce-comm-shared-addr-00.txt Status: https://datatracker.ietf.org/doc/draft-liu-softwire-ce-comm-shared-addr/ Htmlized: http://tools.ietf.org/html/draft-liu-softwire-ce-comm-shared-addr-00 Abstract: In some Softwire mechanisms, multiple Customer Edge (CE) devices can share the same IPv4 address by using different port sets. This document describes a problem of the IPv4 communication between Softwire CEs with the same IPv4 address. 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 --047d7b67001fd8023904f28b33d3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi all,

We submitted a new draft about = an issue on IPv4 communication between two Softwire CEs with the same IPv4 = addr and different port set.
Any comments are=A0appreciate.
Best Wishes,
Cong

--= -------- Forwarded message ----------
From: <in= ternet-drafts@ietf.org>
Date: 2014-02-15 0:42 GMT+08:00
Subject: New Version Notification for dr= aft-liu-softwire-ce-comm-shared-addr-00.txt
To: Jianping Wu <jianping@cernet.edu.cn>, Cong Liu= <gnocuil@gmail.com>



A new version of I-D, draft-liu-softwire-ce-comm-shared-addr-00.txt
has been successfully submitted by Cong Liu and posted to the
IETF repository.

Name: =A0 =A0 =A0 =A0 =A0 draft-liu-softwire-ce-comm-shared-addr
Revision: =A0 =A0 =A0 00
Title: =A0 =A0 =A0 =A0 =A0Communication between Softwire CEs with shared ad= dresses
Document date: =A02014-02-14
Group: =A0 =A0 =A0 =A0 =A0Individual Submission
Pages: =A0 =A0 =A0 =A0 =A05
URL: =A0 =A0 =A0 =A0 =A0 =A0http://www= .ietf.org/internet-drafts/draft-liu-softwire-ce-comm-shared-addr-00.txt=
Status: =A0 =A0 =A0 =A0 https://datatracker.iet= f.org/doc/draft-liu-softwire-ce-comm-shared-addr/
Htmlized: =A0 =A0 =A0 http://tools.ietf.org/html/dr= aft-liu-softwire-ce-comm-shared-addr-00


Abstract:
=A0 =A0In some Softwire mechanisms, multiple Customer Edge (CE) devices can=
=A0 =A0share the same IPv4 address by using different port sets. =A0This =A0 =A0document describes a problem of the IPv4 communication between
=A0 =A0Softwire CEs with the same IPv4 address.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


--047d7b67001fd8023904f28b33d3-- From nobody Mon Feb 17 08:16:09 2014 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F43F1A020A for ; Mon, 17 Feb 2014 08:16:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 jtBKsLLSCuA7 for ; Mon, 17 Feb 2014 08:16:06 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id 1C8BB1A00B8 for ; Mon, 17 Feb 2014 08:16:06 -0800 (PST) Received: from ians-mbp.fritz.box ([89.0.109.16]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0Mh9cj-1WbkwK30cr-00MJbp for ; Mon, 17 Feb 2014 17:16:02 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_91AE9791-1D44-4976-8099-05769F9A83EC" Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ian Farrer In-Reply-To: Date: Mon, 17 Feb 2014 17:15:59 +0100 Message-Id: References: <20140211075445.17615.61208.idtracker@ietfa.amsl.com> <8A1B81989BCFAE44A22B2B86BF2B76318A2CDB8ED2@HE111643.EMEA1.CDS.T-INTERNAL.COM> To: Wojciech Dec X-Mailer: Apple Mail (2.1827) X-Provags-ID: V03:K0:9ea3eKT/ZmmR2hIG6fG1vJsLZ1WtVqClVk74XRpn4FPrwvZ2CBg KoJlFHQ+6f7CnZ2xvzX8gGr148yWpkOrc99psOlVFo206X4C+OZ5QZUrkPhXbGq3LybcLmI AzPog2hVZRwJuRVTwHraVamv0Yvu0BHWopbyIhHhL2qL6E4mtU8Hzwo7qJsLCSV1ejFNW5c BF2Zg4jQ39vfHS1JdS7DQ== Archived-At: http://mailarchive.ietf.org/arch/msg/softwires/94ZJW4PICLXb-LrFtIY3OtjpdX0 Cc: Softwires-wg Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-lw4over6-06.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 16:16:08 -0000 --Apple-Mail=_91AE9791-1D44-4976-8099-05769F9A83EC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Woj, Please see inline. Cheers, Ian On 16 Feb 2014, at 17:32, Wojciech Dec wrote: > Hi Ian, >=20 > you haven't replied on my high level comment - would appreciate if you = introduced changes to that effect in the draft. >=20 > Continued inline=85 [ian] The draft already contains the following text (and has for some = time): Lightweight 4over6 provides a solution for a hub-and-spoke softwire architecture only. It does not offer direct, meshed IPv4 connectivity between subscribers without packets traversing the AFTR. If this type of meshed interconnectivity is required, [I-D.ietf-softwire-map] provides a suitable solution. So, are you not happy with the wording of the current reference, or are = you requesting that the draft is rewritten to be cast as a =91specialised'= case of MAP? Either way, I don=92t really agree with your justification points for a = change: - The PSID and the port range are algorithmically derived & related as = per the MAP algorithm (covered in Section 5.1) [ian] The PSID usage in lw4o6 is written so that you don=92t have to = implement the MAP algorithm to use it (hence the should requirement for = a=3D0). This makes it functionally identical to the PSID originally = described in draft-bajko-pripaddrassign. So lw4o6 does not require you = to implement the MAP algorithm, but it doesn=92t prevent you from using = MAP to implement it (which was the reason for the agreement on using the = MAP PSID DHCP format). - The assigned IPv4 address and port-set form part of the IPv6 address = of a lwB4, and are included in the interface-identifier in the same = place and format as MAP (Section 5.1) [ian] This is noted and already referenced in the lw4o6 draft. - The lw46 CPE should be provisioned using the MAP DHCP (also Section = 5.1). [ian] The draft which is called map-dhcp has been re-written extensively = with input from people across the WG to be a DHCP option for = provisioning map & lw4o6. It is now map-dhcp by filename alone and once = it progresses, won=92t even be called that anymore. How does this make = lw4o6 a =91specialisation' of MAP? As it=92s potentially a significant change that you are requesting here, = I=92d appreciate the opinions of other members of the WG on this. >=20 > Detailed comments: >=20 > * Section 5.1 WAN prefix selection and address forming - as per Ole's = comment. This is indeed hand wavy in the current draft (how to select = the WAN?) >=20 >=20 > [ian] I=92ve updated with the wording that I proposed to Ole. >=20 > The CPE WAN interface is a fairly well used term in a number of other = RFCs. Both RFC6333 and RFC7084 use the term (and have implementations = based on them) without defining how the CPE has identified it. Why does = that need to be specifically defined here? >=20 >=20 > Woj> What is the WAN interface is, and how should the CPE "find it" = not said. That other drafts fail to clarify that doesn't make it quite = right=85 [ian] This is entirely implementation specific and something that hasn=92t= stopped millions of CPEs being built and deployed that support both = RFC6333 and RFC7084 (n=E9 RFC6204). What=92s the problem that you are = trying to solve? > * Processing of IPv4 fragments Section 5.2. Text " The lwB4 MAY = require that the UDP, TCP, or ICMP header be completely contained within = the fragment that contains fragment offset equal to zero." >=20 > What does that mean? Is it trying to say that the IPv4 MTU > 40? >=20 > =20 >=20 > [ian] The text is taken directly from RFC6146. I guess that doesn=92t = specify is as a defined MTU size of > 40 bytes (or anything else) as the = IPv4 header could feasibly be longer than 20 bytes if options were = included in it, so the fragmented L4 header problem could still exist. >=20 >=20 > Here we're talking about tunneling, and I cannot see a case whereby = the IPv4 TCP/UDP header would get fragmented, unless the MTU of the IPv6 = tunnel was <40. rfc6146 is about translation where other effects come to = apply. [ian] No, this is related to fragmentation in respect to the RFC1858 = 'Tiny Fragment attack' which affects the IPv4 payload. The same = problems exist for the lwB4s NAT44 function as exist for a NAT64 in this = respect, which is why it was included. > =20 >=20 > Section 5.2: " >=20 > For incoming packets carrying TCP or UDP IPv4 fragments with a non- > zero checksum, after de-capsulation, the lwB4 MAY elect to queue = the > fragments as they arrive and perform NAPT44 on all fragments at the > same time" > ?? Queue based on what? Presumably the fragment identifier field, and = if so then that is no different to 2473. > =20 > [ian] Updated the text to note that. >=20 >=20 > Ok, but in essence, it would be actually better removing the text = since it adds nothing above 2473.=20 [ian] The text in the current version reads: For incoming packets carrying TCP or UDP IPv4 fragments with a non- zero checksum, after de-capsulation, the lwB4 MAY elect to queue the fragments as they arrive and perform NAPT44 on all fragments at the same time. In this case, the incoming 5-tuple is determined by extracting the appropriate fields from the received packet, as described in [RFC2473]. Alternatively, a lwB4 MAY translate the de- capsulated fragments as they arrive, by storing information that allows it to compute the 5-tuple for fragments other than the first. In the context of the above, is this a problem? > =20 > * Section 5.2: Text: >=20 > For incoming de-capsulated IPv4 packets carrying UDP packets with a > zero checksum, if the lwB4 has enough resources, the lwB4 MUST > reassemble the packets and MUST calculate the checksum. If the = lwB4 > does not have enough resources, then it MUST silently discard the > packets. =20 > Wouldn't it be easier to say that the lwb4 MAY reassemble the packet = and recalculate the checksum? It's clearly not a MUST... >=20 > =20 >=20 > [ian] Why is it not a MUST? If one condition is met you MUST do this, = if a different condition is met, you MUST do that. A MAY would make = re-assembly of the packets optional, meaning that an implementation = could not implement support for fragment reassembly at all and still say = that it is compliant with the spec. >=20 >=20 > If it were a MUST then something would horribly break if it were not = done. The above clearly says that this reassembly operation is at the = discretion of the device, subject to an arbitrary "enough resources" = condition. If you'd like it to be a MUST then the condition should be = removed. [ian] Then surely re-assembly is a SHOULD requirement, with a a MUST to = discard if cannot be re-assembled. As I said, if it was a MAY = requirement, then implementation would be completely optional.=20 --Apple-Mail=_91AE9791-1D44-4976-8099-05769F9A83EC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Hi Woj,

Please = see = inline.

Cheers,
Ian

On 16 Feb 2014, at 17:32, Wojciech Dec <wdec.ietf@gmail.com> = wrote:

Hi Ian,

you haven't replied on my = high level comment - would appreciate if you introduced changes to that = effect in the draft.

Continued = inline=85

[ian] The draft already contains the following text = (and has for some time):
   Lightweight 4over6 provides a solution for a hub-and-spoke =
softwire
   architecture only.  It does not offer direct, meshed IPv4
   connectivity between subscribers without packets traversing the AFTR.
   If this type of meshed interconnectivity is required,
   [I-D.ietf-softwire-map] provides a suitable solution.
So, are you = not happy with the wording of the current reference, or are = you requesting that the draft is rewritten to be cast as = a =91specialised' case of MAP?
Either way, I don=92t really agree with your = justification points for a change:
- The PSID and the = port range are algorithmically derived & related as per the MAP = algorithm (covered in Section 5.1)
 [ian] The PSID usage in lw4o6 is written so that = you don=92t have to implement the MAP algorithm to use it (hence the = should requirement for a=3D0). This makes it functionally identical to = the PSID originally described in draft-bajko-pripaddrassign. So lw4o6 = does not require you to implement the MAP algorithm, but it doesn=92t = prevent you from using MAP to implement it (which was the reason for the = agreement on using the MAP PSID DHCP format).
- The assigned IPv4 address and port-set form part of the IPv6 = address of a lwB4, and are included in the interface-identifier in the = same place and format as MAP (Section 5.1)
[ian] This is noted and already = referenced in the lw4o6 draft.
- The lw46 CPE should = be provisioned using the MAP DHCP (also Section 5.1).
[ian] The draft which is called map-dhcp has been = re-written extensively with input from people across the WG to be a DHCP = option for provisioning map & lw4o6. It is now map-dhcp by filename = alone and once it progresses, won=92t even be called that anymore. How = does this make lw4o6 a =91specialisation' of MAP?
As it=92s potentially a significant change that you = are requesting here, I=92d appreciate the opinions of other members of = the WG on this.


Detailed comments:

* Section 5.1 WAN prefix = selection and address forming - as per Ole's comment. This = is indeed hand wavy in the current draft (how to select the = WAN?)

[ian] I=92ve updated with the wording that I proposed to = Ole.

The CPE = WAN interface is a fairly well used term in a number of other RFCs. Both = RFC6333 and RFC7084 use the term (and have implementations based on = them) without defining how the CPE has identified it. Why does that need = to be specifically defined = here?


Woj>  = What is the WAN interface is, and how should the CPE "find it" not said. = That other drafts fail to clarify that doesn't make it quite = right=85

[ian] This is entirely implementation specific and = something that hasn=92t stopped millions of CPEs being built = and deployed that support both RFC6333 and RFC7084 (n=E9 RFC6204). = What=92s the problem that you are trying to = solve?

* Processing of IPv4 fragments = Section 5.2. Text= " The lwB4 MAY require that the UDP, TCP, or ICMP header be completely = contained within the fragment that contains fragment offset equal to = zero."

What does that mean? Is it trying to say that the = IPv4 MTU > 40?

 

[ian] The text is taken directly from RFC6146. I guess that = doesn=92t specify is as a defined MTU size of > 40 bytes (or anything = else) as the IPv4 header could feasibly be longer than 20 bytes if = options were included in it, so the fragmented L4 header problem could = still exist.


Here we're = talking about tunneling, and I cannot see a case whereby the IPv4 = TCP/UDP header would get fragmented, unless the MTU of the IPv6 tunnel = was <40. rfc6146 is about translation where other effects come to = apply.

[ian] No, this is related to fragmentation in respect = to the RFC1858 'Tiny Fragment attack' which affects  the IPv4 = payload. The same problems exist for the lwB4s NAT44 function as exist = for a NAT64 in this respect, which is why it was = included.

 

Section = 5.2: "

For incoming packets carrying TCP or UDP =
IPv4 fragments with a non-
   zero =
checksum, after de-capsulation, the lwB4 MAY elect to queue =
the
   fragments as they arrive and =
perform NAPT44 on all fragments at =
the
   same =
time"
?? Queue based on what? Presumably the =
fragment identifier field, and if so then that is no different to =
2473.
 

[ian] Updated the text to note = that.


Ok, but in = essence, it would be actually better removing the text since it adds = nothing above 2473. 
<= /div>

[ian] The = text in the current version reads:

For incoming packets carrying TCP =
or UDP IPv4 fragments with a non-
   zero checksum, after de-capsulation, the lwB4 MAY elect to queue the
   fragments as they arrive and perform NAPT44 on all fragments at the
   same time.  In this case, the incoming 5-tuple is determined by
   extracting the appropriate fields from the received packet, as
   described in [RFC2473].  Alternatively, a lwB4 MAY translate the de-
   capsulated fragments as they arrive, by storing information that
   allows it to compute the 5-tuple for fragments other than the =
first.
In the context of the above, is this a = problem?

 

* Section = 5.2: Text:

For incoming de-capsulated IPv4 packets =
carrying UDP packets with a
   zero =
checksum, if the lwB4 has enough resources, the lwB4 =
MUST
   reassemble the packets and =
MUST calculate the checksum.  If the =
lwB4
   does not have enough =
resources, then it MUST silently discard =
the
   packets.  =

Wouldn't it be easier to say = that the lwb4 MAY reassemble the packet and recalculate the checksum? = It's clearly not a MUST...

 

[ian] Why is it not a MUST? If one condition is met you = MUST do this, if a different condition is met, you MUST do that. A MAY = would make re-assembly of the packets optional, meaning that an = implementation could not implement support for fragment reassembly at = all and still say that it is compliant with the = spec.


If it were = a MUST then something would horribly break if it were not done. The = above clearly says that this reassembly operation is at the discretion = of the device,  subject to an arbitrary "enough resources" = condition. If you'd like it to be a MUST then the condition should be = removed.

[ian= ] Then surely re-assembly is a SHOULD requirement, with a a MUST to = discard if cannot be re-assembled. As I said, if it was a MAY = requirement, then implementation would be completely = optional. 

= --Apple-Mail=_91AE9791-1D44-4976-8099-05769F9A83EC-- From nobody Mon Feb 17 09:37:40 2014 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57F871A0239 for ; Mon, 17 Feb 2014 09:37:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] 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 alycq2cpwh0l for ; Mon, 17 Feb 2014 09:37:32 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 832191A03DB for ; Mon, 17 Feb 2014 09:37:30 -0800 (PST) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:b419:c7ff:fe35:ac8e]) by jazz.viagenie.ca (Postfix) with ESMTPSA id DF05E4040D for ; Mon, 17 Feb 2014 12:37:27 -0500 (EST) Message-ID: <530248D7.7030009@viagenie.ca> Date: Mon, 17 Feb 2014 12:37:27 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: softwires@ietf.org References: <20140214164219.10575.89835.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/softwires/WTvOtsMItyQsBOKhf_bKx6OnPGw Subject: Re: [Softwires] Fwd: New Version Notification for draft-liu-softwire-ce-comm-shared-addr-00.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 17:37:36 -0000 Le 2014-02-16 14:39, Cong Liu a écrit : > We submitted a new draft about an issue on IPv4 communication between > two Softwire CEs with the same IPv4 addr and different port set. > Any comments are appreciate. Here's the translation of this draft's recommendation into implementer-speak: - Do not assign the shared address to any interface. - Ensure that NAT is applied after routing. Should work "out of the box" on Linux. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From nobody Tue Feb 18 01:19:57 2014 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C1D51A03FA for ; Tue, 18 Feb 2014 01:19:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=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 tvfqLO0y9qrB for ; Tue, 18 Feb 2014 01:19:55 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id F25FE1A00A6 for ; Tue, 18 Feb 2014 01:19:54 -0800 (PST) X-Files: signature.asc : 496 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFAGAkA1OQ/khL/2dsb2JhbABPCoMGwF6BFRZ0giUBAQEDAXcSCxI0SQ4GiBAIyyMXjiVjgySBFAEDkECaD4FvgT87 X-IronPort-AV: E=Sophos; i="4.97,500,1389744000"; d="asc'?scan'208"; a="5377479" Received: from ams-core-2.cisco.com ([144.254.72.75]) by aer-iport-1.cisco.com with ESMTP; 18 Feb 2014 09:19:52 +0000 Received: from dhcp-10-61-101-237.cisco.com (dhcp-10-61-101-237.cisco.com [10.61.101.237]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s1I9JeYt025626 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 18 Feb 2014 09:19:49 GMT From: Ole Troan Content-Type: multipart/signed; boundary="Apple-Mail=_A6EDB2EE-7EB4-49B3-8F48-D51A605658DC"; protocol="application/pgp-signature"; micalg=pgp-sha512 Message-Id: Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Date: Tue, 18 Feb 2014 10:19:40 +0100 References: <20140214164219.10575.89835.idtracker@ietfa.amsl.com> <530248D7.7030009@viagenie.ca> To: Softwires WG In-Reply-To: <530248D7.7030009@viagenie.ca> X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/softwires/8xxKhGjvPQcrwmt8Hw49-ONmzqw Subject: Re: [Softwires] New Version Notification for draft-liu-softwire-ce-comm-shared-addr-00.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 09:19:56 -0000 --Apple-Mail=_A6EDB2EE-7EB4-49B3-8F48-D51A605658DC Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=iso-8859-1 >> We submitted a new draft about an issue on IPv4 communication between >> two Softwire CEs with the same IPv4 addr and different port set. >> Any comments are appreciate. the MAP draft already has: The MAP architecture described here restricts the use of the shared IPv4 address to only be used as the global address (outside) of the NAPT [RFC2663] running on the CE. A shared IPv4 address MUST NOT be used to identify an interface. While it is theoretically possible to make host stacks and applications port-aware, it would be a drastic change to the IP model [RFC6250]. cheers, Ole --Apple-Mail=_A6EDB2EE-7EB4-49B3-8F48-D51A605658DC Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJTAyWsAAoJEFuJXizso86gPRAIAKSMJpScx+sNN0Stv6DOmhHv gV/HgVe+i9w/tmWFAsFH99iGOdtfhGyvQ3jrIxvy0//fvVNUMj3asdVQZji3SqDo J2w/y0xZwfkhQYf9chyif2TJY0l2WlHadfABprchJeP1YdvHaLFNmHVDIL5JoKTm a9fqYhUE+wKxHTpibYeFjvBYQqpP2AOUFEIklIb0U0oo7RK7HTGdsBL1pOCV9jNE cJopFVDcbyJuvk9v8S+sHc6JNGonGtHEPyCUEo1iwCDfA7OW5GM2uggEqsFitG9V H/oiT1aQvnp24DfhJDBKgCH9o2FJa9yPG0YuF+vzBECDJ3X3nNhsxa95Pl5XC9c= =zCr/ -----END PGP SIGNATURE----- --Apple-Mail=_A6EDB2EE-7EB4-49B3-8F48-D51A605658DC-- From nobody Tue Feb 18 23:44:56 2014 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3BAD1A0366 for ; Tue, 18 Feb 2014 23:44:54 -0800 (PST) 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 me2E3k7woIKJ for ; Tue, 18 Feb 2014 23:44:52 -0800 (PST) Received: from mail-qa0-x234.google.com (mail-qa0-x234.google.com [IPv6:2607:f8b0:400d:c00::234]) by ietfa.amsl.com (Postfix) with ESMTP id 0DB101A00FD for ; Tue, 18 Feb 2014 23:44:51 -0800 (PST) Received: by mail-qa0-f52.google.com with SMTP id j15so25267qaq.25 for ; Tue, 18 Feb 2014 23:44:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=wI8ad4EkUaTPaCcjJdT81yeRVLRBYOgBfUQFBvNIXzM=; b=LXB/MR4ZUd+DALxcLmRsD72SrGSYJG5Q1a9d3fBSu0ooqw/tElDrIL4S2pUf1eXxUY BNt+LK99vPkGo17Bm28SIakjUoRo/I8+S03MuhQg/0b2isMfz/dn0t3FFXyWviMw9fkM Ij3j8WURyCzMvVztcLXgPDXzLFdlwobfdit5omiq+M5NSZx+Ja9svukE6jhFT4I8UAjy 0afibhcquUtDSIpgwH6kH5l6Ql8H1X+mvHWBPxs0iwJtL+2dVl+/+xI7HJsd5UwGyA7s 2eXlImaIwtcM4e8b25o2p7NhrVrZHczRDMiuK2kg3isF4ZGy9zpF4VD8HvqJlTOtmeAz 5TEQ== X-Received: by 10.140.97.73 with SMTP id l67mr46264812qge.56.1392795888808; Tue, 18 Feb 2014 23:44:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.96.92.35 with HTTP; Tue, 18 Feb 2014 23:44:28 -0800 (PST) In-Reply-To: <530248D7.7030009@viagenie.ca> References: <20140214164219.10575.89835.idtracker@ietfa.amsl.com> <530248D7.7030009@viagenie.ca> From: Cong Liu Date: Wed, 19 Feb 2014 15:44:28 +0800 Message-ID: To: Simon Perreault Content-Type: multipart/alternative; boundary=001a113a9cc4327a4c04f2bd908e Archived-At: http://mailarchive.ietf.org/arch/msg/softwires/zwoD_6GGVPdYG9yYzJMyl3GxY8U Cc: softwires Subject: Re: [Softwires] Fwd: New Version Notification for draft-liu-softwire-ce-comm-shared-addr-00.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 07:44:55 -0000 --001a113a9cc4327a4c04f2bd908e Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Simon, Thanks for your comments. It's a good implementation to the draft. Another way is to assign the shared address to the interface, and to perform a port-based routing. On Linux, netfilter and ip-rule can be used, to route all such packets using "main" table instead of "local" table. Best Regards, Cong 2014-02-18 1:37 GMT+08:00 Simon Perreault : > Le 2014-02-16 14:39, Cong Liu a =E9crit : > > We submitted a new draft about an issue on IPv4 communication between > > two Softwire CEs with the same IPv4 addr and different port set. > > Any comments are appreciate. > > Here's the translation of this draft's recommendation into > implementer-speak: > > - Do not assign the shared address to any interface. > - Ensure that NAT is applied after routing. > > Should work "out of the box" on Linux. > > Simon > -- > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > --001a113a9cc4327a4c04f2bd908e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Simon,

Thanks for your comments. It&= #39;s a good implementation to the draft.
<= br>
Another way is to assign the shared add= ress to the interface, and to perform a port-based routing.
On Linux, netfilter and ip-rule can be used, to = route all such packets using "main" table instead of "local&= quot; table.

Best Regards,
Cong

2014-02-18 1:37 GMT+08:00 Simon Perreault <<= a href=3D"mailto:simon.perreault@viagenie.ca" target=3D"_blank">simon.perre= ault@viagenie.ca>:
Le 2014-02-16 14:39, Cong Liu a =E9crit :
> We submitted a new draft about an issue on IPv4 commun= ication between
> two Softwire CEs with the same IPv4 addr and different port set.
> Any comments are appreciate.

Here's the translation of this draft's recommendation into implementer-speak:

- Do not assign the shared address to any interface.
- Ensure that NAT is applied after routing.

Should work "out of the box" on Linux.

Simon
--
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source =A0 =A0 =A0 =A0--> http://ecdysis.viagenie.ca
STUN/TURN server =A0 =A0 =A0 =A0 =A0 =A0 =A0 --> http://numb.viagenie.ca

_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

--001a113a9cc4327a4c04f2bd908e-- From nobody Wed Feb 19 00:04:13 2014 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A4331A00AD for ; Wed, 19 Feb 2014 00:04:12 -0800 (PST) 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 LgA5H9Orn7EH for ; Wed, 19 Feb 2014 00:04:10 -0800 (PST) Received: from mail-qc0-x233.google.com (mail-qc0-x233.google.com [IPv6:2607:f8b0:400d:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 3C6231A0074 for ; Wed, 19 Feb 2014 00:04:10 -0800 (PST) Received: by mail-qc0-f179.google.com with SMTP id e16so43280qcx.24 for ; Wed, 19 Feb 2014 00:04:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Pxw9+vdeX1tS7RPf/Y15n16sdTfu9WhmsBczuwT3abw=; b=sK7N5pZanJEq8tendzA3nBd82ZWmNFbfIUmGSdaCVZ3zWspNrvqZqd46HDw5//tn53 W5BTVkmKCEpomcAf1Y2k30qUdsgG8lJcIT8I1MenNVp8LVqvsm1wro+dRiSLG5Hyd0VT jfq80wKuFTkgpx4FOhtQi1/OYFJIZV8OrGT7Dk/ujBYBlB/DbtWRHA5Ovg8zjx2W4BeT bJedtbIk+NKakoDPBn8zO28YpujEURSPF3DFfgxGTYARA18lUL0u+IesXliHVqK+Uk8R Oj+esKgZKxH7AcOM5YcZRAa6RzAshWAGvxYEW61xPtDIMxLl/QdktAxIoqGppsxnpwwQ 2vrQ== X-Received: by 10.140.47.101 with SMTP id l92mr46479870qga.9.1392797046924; Wed, 19 Feb 2014 00:04:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.96.92.35 with HTTP; Wed, 19 Feb 2014 00:03:46 -0800 (PST) In-Reply-To: References: <20140214164219.10575.89835.idtracker@ietfa.amsl.com> <530248D7.7030009@viagenie.ca> From: Cong Liu Date: Wed, 19 Feb 2014 16:03:46 +0800 Message-ID: To: Ole Troan Content-Type: multipart/alternative; boundary=001a11c1640e39e9f404f2bdd58c Archived-At: http://mailarchive.ietf.org/arch/msg/softwires/p9OIb_IAXjLnAYHaQgnjn8mtz6s Cc: Softwires WG Subject: Re: [Softwires] New Version Notification for draft-liu-softwire-ce-comm-shared-addr-00.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 08:04:12 -0000 --001a11c1640e39e9f404f2bdd58c Content-Type: text/plain; charset=ISO-8859-1 Hi Ole, Thanks for your comments. The paragraph meets the requirement of this draft. This draft is to provide advices to MAP, lw4o6, and any other potential mechanisms. Do you think it would be helpful, or the description in MAP-E draft is enough? Best Regards, Cong 2014-02-18 17:19 GMT+08:00 Ole Troan : > >> We submitted a new draft about an issue on IPv4 communication between > >> two Softwire CEs with the same IPv4 addr and different port set. > >> Any comments are appreciate. > > the MAP draft already has: > > The MAP architecture described here restricts the use of the shared > IPv4 address to only be used as the global address (outside) of the > NAPT [RFC2663] running on the CE. A shared IPv4 address MUST NOT be > used to identify an interface. While it is theoretically possible to > make host stacks and applications port-aware, it would be a drastic > change to the IP model [RFC6250]. > > cheers, > Ole > > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > > --001a11c1640e39e9f404f2bdd58c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Ole,

Thanks for your comments. The p= aragraph meets the requirement of this draft.

This= draft is to provide advices to MAP, lw4o6, and any other potential mechani= sms.
Do you think it would be helpful, or the description in MAP-E draft is= enough?

Best Regards,
Cong
<= div class=3D"gmail_extra">

2014-02-18 17:= 19 GMT+08:00 Ole Troan <otroan@employees.org>:
>> We submitted a new = draft about an issue on IPv4 communication between
>> two Softwire CEs with the same IPv4 addr and different port set. >> Any comments are appreciate.

the MAP draft already has:

=A0 =A0The MAP architecture described here restricts the use of the shared<= br> =A0 =A0IPv4 address to only be used as the global address (outside) of the<= br> =A0 =A0NAPT [RFC2663] running on the CE. =A0A shared IPv4 address MUST NOT = be
=A0 =A0used to identify an interface. =A0While it is theoretically possible= to
=A0 =A0make host stacks and applications port-aware, it would be a drastic<= br> =A0 =A0change to the IP model [RFC6250].

cheers,
Ole


_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires


--001a11c1640e39e9f404f2bdd58c-- From nobody Wed Feb 19 00:34:13 2014 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5D9F1A042F for ; Wed, 19 Feb 2014 00:34:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, SPF_PASS=-0.001] autolearn=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 PgdcvgTXOo16 for ; Wed, 19 Feb 2014 00:34:05 -0800 (PST) Received: from mail-pd0-x235.google.com (mail-pd0-x235.google.com [IPv6:2607:f8b0:400e:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id B97231A0080 for ; Wed, 19 Feb 2014 00:34:05 -0800 (PST) Received: by mail-pd0-f181.google.com with SMTP id y10so79113pdj.26 for ; Wed, 19 Feb 2014 00:34:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XWBTjkv6ogY0ZvBxwT4Nd7/oO24w9YV+17xI7HX3d1k=; b=0OvPNaTjuDbgRpFGhfEbzwneFZg7cU+z3o4On+d0TJRLHsHtV3ZW74onRFIEIR6CCl WptocoOAD30AzV20v0IL52z6SRhMsu+JK2G4otZQWYWebydzi6PTJwpKU7qlHCLk9zPj evB4/bOb9AW8KhIjIfduUjZ705gs6NFWqUvdCHAOPTGAa20aEgtXDg1ioBSSSTWm3Mv9 9c2dSDvpmgaToyc1FsXTE1G4F4MdHeBP+C+++Ncwfj7Kqyow4fqKyV4l716tiWntpXu3 c1ksqrOalt0nsFuDL3CnZ9XqVD+/ymQV2QG/CTFs5JC9dzqYbHGP1D+FihwJU7tTjGxq c++w== MIME-Version: 1.0 X-Received: by 10.66.26.10 with SMTP id h10mr37961443pag.24.1392798842658; Wed, 19 Feb 2014 00:34:02 -0800 (PST) Received: by 10.70.1.70 with HTTP; Wed, 19 Feb 2014 00:34:02 -0800 (PST) In-Reply-To: References: <20140211075445.17615.61208.idtracker@ietfa.amsl.com> <8A1B81989BCFAE44A22B2B86BF2B76318A2CDB8ED2@HE111643.EMEA1.CDS.T-INTERNAL.COM> Date: Wed, 19 Feb 2014 09:34:02 +0100 Message-ID: From: Wojciech Dec To: Ian Farrer Content-Type: multipart/alternative; boundary=bcaec520f2e942a3e404f2be406a Archived-At: http://mailarchive.ietf.org/arch/msg/softwires/j3LCnHZsz51RVjNdXY8poIgEfb0 Cc: Softwires-wg Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-lw4over6-06.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 08:34:11 -0000 --bcaec520f2e942a3e404f2be406a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Ian, Just to be clear: I'm ok with lw46 defining a specific functional mode as I believe it does in this draft, also leaving "as-is" the DHCP part of it (i.e. it's a capability that can be signalled using the lw46 container, etc). General items remain open (as commented): - Cleanup text that does not belong to lw46 (eg 2473 fixes, or NAT44 best practice). - Clarification of WAN selection or assumptions That said, abundant technical evidence (summarized in previous mail) indicates that this mode is in near total overlap with MAP 1:1, certainly much more than at the outset of this work. Given this, why not align the text and actually make MAP 1:1 and lw46 be the same? On all of the data plane IPv6, IPv4, NAT44, tunneling and ICMP handling parts I see there no reason for there being a difference... continued inline... On 17 February 2014 17:15, Ian Farrer wrote: > Hi Woj, > > Please see inline. > > Cheers, > Ian > > On 16 Feb 2014, at 17:32, Wojciech Dec wrote: > > Hi Ian, > > you haven't replied on my high level comment - would appreciate if you > introduced changes to that effect in the draft. > > Continued inline... > > > [ian] The draft already contains the following text (and has for some > time): > > Lightweight 4over6 provides a solution for a hub-and-spoke softwire > architecture only. It does not offer direct, meshed IPv4 > connectivity between subscribers without packets traversing the AFTR. > If this type of meshed interconnectivity is required, > [I-D.ietf-softwire-map] provides a suitable solution. > > So, are you not happy with the wording of the current reference, or are > you requesting that the draft is rewritten to be cast as a 'specialised' > case of MAP? > What I pointed out is that the Lw46 draft has major if near total overlap with MAP-E 1:1 mode. Stating that lw46 realizes this mode, in a standalone way from the N:1 mesh mode, is what I propose. This would greatly help in implementing it and "digesting" the array of solutions. Additional comment Now that you mention it, the stated characterisation of map isn't quite right; MAP does not force the use of mesh mode, nor is mesh mode its defining characteristic. The characterisation should be restated as " lw46 does not seek to offer the optimization of AFTR subscriber state and the AFTR is expected to have configuration state for each lwB4 node. If optimization of this state is required, [id-ietf-softwire-map] provides a suitable solution ". Alternatively, state that "lw46 describes a deployment/implementation of MAP 1:1" > Either way, I don't really agree with your justification points for a > change: > - The PSID and the port range are algorithmically derived & related as pe= r > the MAP algorithm (covered in Section 5.1) > [ian] The PSID usage in lw4o6 is written so that you don't have to > implement the MAP algorithm to use it (hence the should requirement for > a=3D0). This makes it functionally identical to the PSID originally descr= ibed > in draft-bajko-pripaddrassign. So lw4o6 does not require you to implement > the MAP algorithm, but it doesn't prevent you from using MAP to implement > it (which was the reason for the agreement on using the MAP PSID DHCP > format). > I'm actually fine with the current lw46 text in section 5.1, but your response seems to conflict with that. I'll start another thread on this topic. > - The assigned IPv4 address and port-set form part of the IPv6 address > of a lwB4, and are included in the interface-identifier in the same place > and format as MAP (Section 5.1) > [ian] This is noted and already referenced in the lw4o6 draft. > - The lw46 CPE should be provisioned using the MAP DHCP (also Section 5.1= ). > [ian] The draft which is called map-dhcp has been re-written extensively > with input from people across the WG to be a DHCP option for provisioning > map & lw4o6. It is now map-dhcp by filename alone and once it progresses, > won't even be called that anymore. How does this make lw4o6 > a 'specialisation' of MAP? > As it's potentially a significant change that you are requesting here, I'= d > appreciate the opinions of other members of the WG on this. > > >> Detailed comments: >> >> * Section 5.1 WAN prefix selection and address forming - as per Ole's >> comment. This is indeed hand wavy in the current draft (how to select >> the WAN?) >> >> [ian] I've updated with the wording that I proposed to Ole. >> >> The CPE WAN interface is a fairly well used term in a number of other >> RFCs. Both RFC6333 and RFC7084 use the term (and have implementations ba= sed >> on them) without defining how the CPE has identified it. Why does that n= eed >> to be specifically defined here? >> > > Woj> What is the WAN interface is, and how should the CPE "find it" not > said. That other drafts fail to clarify that doesn't make it quite right.= .. > > > [ian] This is entirely implementation specific and something that hasn't > stopped millions of CPEs being built and deployed that support both RFC63= 33 > and RFC7084 (n=E9 RFC6204). What's the problem that you are trying to sol= ve? > Woj> None of those texts attempt to create a deterministic ip interface, and in case of 6333 that is a known operational issue. So, in terms of the lw46 draft specifying how a CPE is to get to the IP prefix of "the WAN interface" is an important aspect, or at least stating the assumptions about this WAN interface. Some obvious questions apply here: is the WAN the interface which has the default route? Is it the interface that has a DHCPv6 client? What if there are multiple such "WAN" interfaces? What if a single "WAN" has multiple IPv6 prefixes? What if it has NO global IPv6 prefix? What if it doesn't have a /64 prefix. etc. Coincidentally, all of the latter are options allowed for by RFC7084. > > * Processing of IPv4 fragments Section 5.2. Text " The lwB4 MAY require >> that the UDP, TCP, or ICMP header be completely contained within the >> fragment that contains fragment offset equal to zero." >> >> What does that mean? Is it trying to say that the IPv4 MTU > 40? >> >> >> >> [ian] The text is taken directly from RFC6146. I guess that doesn't >> specify is as a defined MTU size of > 40 bytes (or anything else) as the >> IPv4 header could feasibly be longer than 20 bytes if options were inclu= ded >> in it, so the fragmented L4 header problem could still exist. >> > > Here we're talking about tunneling, and I cannot see a case whereby the > IPv4 TCP/UDP header would get fragmented, unless the MTU of the IPv6 tunn= el > was <40. rfc6146 is about translation where other effects come to apply. > > > [ian] No, this is related to fragmentation in respect to the RFC1858 'Tin= y > Fragment attack' which affects the IPv4 payload. The same problems exist > for the lwB4s NAT44 function as exist for a NAT64 in this respect, which = is > why it was included. > Woj> Ok, but what does "MAY require" mean, and how should a device go about requiring it? > >> >> Section 5.2: " >> >> For incoming packets carrying TCP or UDP IPv4 fragments with a non- >> >> zero checksum, after de-capsulation, the lwB4 MAY elect to queue the >> >> fragments as they arrive and perform NAPT44 on all fragments at the >> >> same time" >> >> ?? Queue based on what? Presumably the fragment identifier field, and if= so then that is no different to 2473. >> >> >> >> [ian] Updated the text to note that. >> > > Ok, but in essence, it would be actually better removing the text since i= t > adds nothing above 2473. > > > [ian] The text in the current version reads: > > For incoming packets carrying TCP or UDP IPv4 fragments with a non- > zero checksum, after de-capsulation, the lwB4 MAY elect to queue the > fragments as they arrive and perform NAPT44 on all fragments at the > same time. In this case, the incoming 5-tuple is determined by > extracting the appropriate fields from the received packet, as > described in [RFC2473]. Alternatively, a lwB4 MAY translate the de- > capsulated fragments as they arrive, by storing information that > allows it to compute the 5-tuple for fragments other than the first. > > In the context of the above, is this a problem? > Woj> Well, what strikes me is that the above text does not bring in anything other than what's already in 2473 for IPinIP fragementation and [RFC5508], and [RFC5382] for NAT. The text should refer to those documents, or file errata. In other words, IPv4inIPv6 fragments and handling of IPv4 fragments with NAT44 is not a lwB4 specific function, and is already well documented. > > >> >> * Section 5.2: Text: >> >> For incoming de-capsulated IPv4 packets carrying UDP packets with a >> >> zero checksum, if the lwB4 has enough resources, the lwB4 MUST >> >> reassemble the packets and MUST calculate the checksum. If the lwB4 >> >> does not have enough resources, then it MUST silently discard the >> >> packets. >> >> Wouldn't it be easier to say that the lwb4 MAY reassemble the packet and >> recalculate the checksum? It's clearly not a MUST... >> >> >> >> [ian] Why is it not a MUST? If one condition is met you MUST do this, if >> a different condition is met, you MUST do that. A MAY would make >> re-assembly of the packets optional, meaning that an implementation coul= d >> not implement support for fragment reassembly at all and still say that = it >> is compliant with the spec. >> > > If it were a MUST then something would horribly break if it were not done= . > The above clearly says that this reassembly operation is at the discretio= n > of the device, subject to an arbitrary "enough resources" condition. If > you'd like it to be a MUST then the condition should be removed. > > > [ian] Then surely re-assembly is a SHOULD requirement, with a a MUST to > discard if cannot be re-assembled. As I said, if it was a MAY requirement= , > then implementation would be completely optional. > Woj> Yes, and that's what the above text reads from a test perspective, i.e. since one has no way of determining whether there are "enough resources", a lwB4 that discards all such packets would comply. As I said, if one would like to tighten the spec; a) the un-testable "enough resources" condition should be removed b) with that either a MUST used, if this is something super important, or a SHOULD (as it seems to me). Alternatively a MAY as "nice to have" may also do. Cheers, Wojciech. --bcaec520f2e942a3e404f2be406a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Ian,

Just to be clear= : I'm ok with lw46 defining a specific functional=20 mode as I believe it does in this draft, also leaving "as-is" the= DHCP part of=20 it (i.e. it's a capability that can be signalled using the lw46 contain= er, etc).
General items remain open (as commented):
- Cleanup text t= hat does not belong to lw46 (eg 2473 fixes, or NAT44 best practice).
- Clarification of WAN selection or assumptions

That said, abundant = technical evidence (summarized in previous mail) indicates that this mode i= s in near total overlap with MAP 1:1, certainly much more than at the outse= t of this work. Given this, why not align the text and actually make MAP 1:= 1 and lw46 be the same? On all of the data plane IPv6, IPv4, NAT44, tunneli= ng and ICMP handling parts I see there no reason for there being a differen= ce...

continued inline...


On 17 February 2014 17:15, Ian Farrer <= ianfarrer@gmx.com> wrote:
Hi Woj,

Please see inlin= e.

Cheers,
Ian

On 16 Feb 2014, at 17:32, Wojciech Dec <wdec.ietf@gmail.com> wrote:

Hi Ian,

you haven't replie= d on my high level comment - would appreciate if you introduced changes to = that effect in the draft.

Continued inline…

[ian] The draft already contains = the following text (and has for some time):
   Lightweight 4over6 provides a solutio=
n for a hub-and-spoke softwire
   architecture only.  It does not offer direct, meshed IPv4
   connectivity between subscribers without packets traversing the AFTR.
   If this type of meshed interconnectivity is required,
   [I-D.ietf-softwire-map] provides a suitable solution.
So, are you not happy with the= wording of the current reference, or are you requesting that the draf= t is rewritten to be cast as a ‘specialised' case of MAP?
What I pointed out is = that the Lw46 draft has major if near total overlap with MAP-E 1:1 mode. Stating that lw46 realizes this mode, in a standalone way = from the N:1 mesh mode, is what I propose. This would greatly help in imple= menting it and "digesting" the array of solutions.
Additional comment Now that you mention it, the stated character= isation of map isn't quite right; MAP does not force the use of mesh mo= de, nor is mesh mode its defining characteristic. The characterisation should be restated as " lw46 does not seek to offer= =20 the optimization of AFTR subscriber state and the AFTR is expected to have = configuration state for each lwB4 node. If optimization of this state is re= quired, [id-ietf-softwire-map] provides a suitable solution ".
Alternatively, state that "lw46 describes a deployment/implementation = of MAP 1:1"
 
Either way, I don’t = really agree with your justification points for a change:
- The PSID and the port range are algorithmically derived & re= lated as per the MAP algorithm (covered in Section 5.1)
 [ian] The PSID usage in lw4o6 is written so that you don&rsq= uo;t have to implement the MAP algorithm to use it (hence the should requir= ement for a=3D0). This makes it functionally identical to the PSID original= ly described in draft-bajko-pripaddrassign. So lw4o6 does not require you t= o implement the MAP algorithm, but it doesn’t prevent you from using = MAP to implement it (which was the reason for the agreement on using the MA= P PSID DHCP format).
I'm actually fine with the cu= rrent lw46 text in section 5.1, but your response seems to conflict with th= at. I'll start another thread on this topic.

 
- The assigned IPv4 address and port-set form part of the IPv6= address of a lwB4, and are included in the interface-identifier in the sam= e place and format as MAP (Section 5.1)
[ian] This is noted and alread= y referenced in the lw4o6 draft.
- The lw46 CPE should = be provisioned using the MAP DHCP (also Section 5.1).
[ian] The draft which is called map-dhcp has been re-written = extensively with input from people across the WG to be a DHCP option for pr= ovisioning map & lw4o6. It is now map-dhcp by filename alone and once i= t progresses, won’t even be called that anymore. How does this make l= w4o6 a ‘specialisation' of MAP?
As it’s pot= entially a significant change that you are requesting here, I’d appre= ciate the opinions of other members of the WG on this.
 

Detailed comments= :

* Section 5.1 WAN prefix selection and address forming - as per Ol= e's comment. This is indeed hand wavy in the current draft = (how to select the WAN?)

[ian] I’ve updated with the wordin= g that I proposed to Ole.

The CPE WAN interface is a fairly well used term= in a number of other RFCs. Both RFC6333 and RFC7084 use the term (and have= implementations based on them) without defining how the CPE has identified= it. Why does that need to be specifically defined here?


Woj>  What is the= WAN interface is, and how should the CPE "find it" not said. Tha= t other drafts fail to clarify that doesn't make it quite right…=

[ian] Thi= s is entirely implementation specific and something that hasn’t stopp= ed millions of CPEs being built and deployed that support both RFC6333= and RFC7084 (n=E9 RFC6204). What’s the problem that you are trying t= o solve?

Woj> None of those te= xts attempt to create a deterministic ip interface, and in case of 6333 tha= t is a known operational issue. So, in terms of the lw46 draft specifying h= ow a CPE is to get to the IP prefix of  "the WAN interface" = is an important aspect, or at least stating the assumptions about this WAN = interface. Some obvious questions apply here:
is the WAN the interface which has the default route? Is it the interface t= hat has a DHCPv6 client? What if there are multiple such "WAN" in= terfaces? What if a single "WAN" has multiple IPv6 prefixes? What= if it has NO global IPv6 prefix? What if it doesn't have a /64 prefix.= etc.

Coincidentally, all of the latter are options allowed for by RFC7084.
 

* Processing of = IPv4 fragments Section 5.2. Text " The lwB4 M= AY require that the UDP, TCP, or ICMP header be completely contained within= the fragment that contains fragment offset equal to zero."<= /u>

What does that mean? Is it trying t= o say that the IPv4 MTU > 40?

 <= /p>

[ian] The text is taken directly from RFC6146. I guess that doesn&rsquo= ;t specify is as a defined MTU size of > 40 bytes (or anything else) as = the IPv4 header could feasibly be longer than 20 bytes if options were incl= uded in it, so the fragmented L4 header problem could still exist.


Here we're talking about tunneli= ng, and I cannot see a case whereby the IPv4 TCP/UDP header would get fragm= ented, unless the MTU of the IPv6 tunnel was <40. rfc6146 is about trans= lation where other effects come to apply.

[i= an] No, this is related to fragmentation in respect to the RFC1858 'Tin= y Fragment attack' which affects  the IPv4 payload. The same probl= ems exist for the lwB4s NAT44 function as exist for a NAT64 in this respect= , which is why it was included.

Woj> Ok, but what doe= s "MAY require" mean, and how should a device go about requiring = it?

 

Section 5.2: "

For i=
ncoming packets carrying TCP or UDP IPv4 fragments with a non-
   zero checksum, after de-capsulation, the lwB4 MAY =
elect to queue the
   fragments as they arrive and perform NAPT44 on all fragme=
nts at the
   same time"
?? Queue based on what? Presumably the fragment identifier fie=
ld, and if so then that is no different to 2473.
 

[ian] Updated the text to note that.


Ok, but in essence, it wo= uld be actually better removing the text since it adds nothing above 2473.<= span> 

[ian] The text in the current versio= n reads:

For incoming packets carrying TCP or UDP IPv4 =
fragments with a non-
   zero checksum, after de-capsulation, the lwB4 MAY elect to queue the
   fragments as they arrive and perform NAPT44 on all fragments at the
   same time.  In this case, the incoming 5-tuple is determined by
   extracting the appropriate fields from the received packet, as
   described in [RFC2473].  Alternatively, a lwB4 MAY translate the de-
   capsulated fragments as they arrive, by storing information that
   allows it to compute the 5-tuple for fragments other than the first.
In the context of the above, is this a problem?

Woj> Well, what str= ikes me is that the above text does not bring in anything other than what&#= 39;s already in 2473 for IPinIP fragementation and  [RFC5508], and&nbs= p; [RFC5382] for NAT. The text should refer to those documents, or file err= ata. In other words, IPv4inIPv6 fragments and handling of IPv4 fragments wi= th NAT44 is not a lwB4 specific function, and is already well documented.

 

 

* Section 5.2: Text:

For =
incoming de-capsulated IPv4 packets carrying UDP packets with a
   zero checksum, if the lwB4 has enough resources, =
the lwB4 MUST
   reassemble the packets and MUST calculate the checksum.&n=
bsp; If the lwB4
   does not have enough =
resources, then it MUST silently discard the
 =
  packets. 

Wouldn't it be easier to say that the lwb4 MAY r= eassemble the packet and recalculate the checksum? It's clearly not a M= UST...

 

[ian] Why is it not a MUST? If one condition is met you= MUST do this, if a different condition is met, you MUST do that. A MAY wou= ld make re-assembly of the packets optional, meaning that an implementation= could not implement support for fragment reassembly at all and still say t= hat it is compliant with the spec.


If it were a MUST t= hen something would horribly break if it were not done. The above clearly s= ays that this reassembly operation is at the discretion of the device, = ; subject to an arbitrary "enough resources" condition. If you= 9;d like it to be a MUST then the condition should be removed.

[ian] = Then surely re-assembly is a SHOULD requirement, with a a MUST to discard i= f cannot be re-assembled. As I said, if it was a MAY requirement, then impl= ementation would be completely optional. 

Woj> Yes, and that= 9;s what the above text reads from a test perspective, i.e. since one has n= o way of determining whether there are "enough resources", a lwB4= that discards all such packets would comply. As I said, if one would like = to tighten the spec; a) the un-testable "enough resources" condit= ion should be removed b) with that either a MUST used, if this is something= super important, or a SHOULD (as it seems to me). Alternatively a MAY as &= quot;nice to have" may also do.

Cheers,
Wojciech.

--bcaec520f2e942a3e404f2be406a-- From nobody Wed Feb 19 05:48:10 2014 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A05001A0148 for ; Wed, 19 Feb 2014 05:48:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] 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 2BCuD_amoSUN for ; Wed, 19 Feb 2014 05:48:07 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0391B1A01D3 for ; Wed, 19 Feb 2014 05:48:07 -0800 (PST) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:b419:c7ff:fe35:ac8e]) by jazz.viagenie.ca (Postfix) with ESMTPSA id A18E9403CE; Wed, 19 Feb 2014 08:48:03 -0500 (EST) Message-ID: <5304B613.2090204@viagenie.ca> Date: Wed, 19 Feb 2014 08:48:03 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Cong Liu References: <20140214164219.10575.89835.idtracker@ietfa.amsl.com> <530248D7.7030009@viagenie.ca> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/softwires/RjP47lRtci3YgtsJtsHIgRMHpiU Cc: softwires Subject: Re: [Softwires] Fwd: New Version Notification for draft-liu-softwire-ce-comm-shared-addr-00.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 13:48:08 -0000 Le 2014-02-19 02:44, Cong Liu a écrit : > Another way is to assign the shared address to the interface, and to > perform a port-based routing. > On Linux, netfilter and ip-rule can be used, to route all such packets > using "main" table instead of "local" table. I think that would be asking for trouble. What's the point? Does it even work with packets sourced by the CPE? Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From nobody Thu Feb 20 03:05:23 2014 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DF671A00AD for ; Thu, 20 Feb 2014 03:05:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 tYNueGgNKTQU for ; Thu, 20 Feb 2014 03:05:20 -0800 (PST) Received: from mail.nic.br (mail.nic.br [IPv6:2001:12ff:0:4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 097E91A00AB for ; Thu, 20 Feb 2014 03:05:20 -0800 (PST) Received: from ecordeiro.in.nic.br (5.110.net.registro.br [200.160.5.110]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.nic.br (Postfix) with ESMTPSA id 69B9F2080287 for ; Thu, 20 Feb 2014 08:05:14 -0300 (BRT) Message-ID: <5305E16F.90007@nic.br> Date: Thu, 20 Feb 2014 08:05:19 -0300 From: Edwin Cordeiro User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: softwires@ietf.org References: <52FDAE7B.8090009@ericsson.com> In-Reply-To: <52FDAE7B.8090009@ericsson.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/softwires/ttAxXBsA5jUZBEj13Dv1NCKSDco Subject: Re: [Softwires] Working group last call for draft-ietf-softwire-map-t-05 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 11:05:21 -0000 Hi all, I've just reviewed the draft and I support it. I've tested CERNET's MAP-T prototype as described in http://www.ietf.org/id/draft-cordeiro-softwire-experience-mapt-02.txt and I believe it is an option that should be accepted as an Experimental RFC. Regards, Edwin Cordeiro NIC.br Em 14/02/14 03:49, Suresh Krishnan escreveu: > Hi all, > This message starts a two week softwire working group last call on > advancing the draft about providing Mapping of Address and Port using > Translation as an Experimental RFC. The authors believe that this > version has addressed all the issues raised on the document till date. > The latest version of the draft is available at > > http://www.ietf.org/id/draft-ietf-softwire-map-t-05.txt > http://tools.ietf.org/html/draft-ietf-softwire-map-t-05 > > Substantive comments and statements of support/opposition for > advancing this document should be directed to the mailing list. > Editorial suggestions can be sent directly to the authors. This last > call will conclude on February 28, 2014 > > Regards, > Suresh & Yong > > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From nobody Thu Feb 20 06:33:15 2014 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F8551A019D for ; Thu, 20 Feb 2014 06:33:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.312 X-Spam-Level: X-Spam-Status: No, score=-1.312 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=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 BtMeCFl1zvJu for ; Thu, 20 Feb 2014 06:33:13 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id A4B581A0199 for ; Thu, 20 Feb 2014 06:33:12 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id c11so1378205lbj.3 for ; Thu, 20 Feb 2014 06:33:08 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=fR7xKa8BJCMZnNKw9asZHlKgKGMNH8m780lxhbvQrVA=; b=fPZ2iIig2KhwqvYrrUOMAReGTpWsfUkZ05JkgidDOzzZgePtuZhzNpecnng/1REG6D WsM9stq6OBZzS14U+PAV3FQnK0Vkt+kItaXZr8nOAJka+GG3qfDcTnoBJGYipAWdr/7H OYlVKXYZhvI7HxpeqNXq4iKtRKdfuojuBvqODKec1gSaytO76/2Pk2czeGDBR5YTHQ/s kQ1CiAD6u7hnoxHyEWElAfRacWL2ays0+3dDurVAsk7XK2/q9j+g2rRO0eukEwHhlNE7 V9fImQlVJXHd5LoQ37ZZiFBza626x9hUOoo3THtazn/vDt8Od6xIa3bC33/KN3DAxsS9 A0qQ== X-Gm-Message-State: ALoCoQmbrPnYcLweM3obLmSEPSs1LOlz3iIwc4VIxUoX4qqw0tn3iA3UiOLVlEKD1xsHH4JAqIOj MIME-Version: 1.0 X-Received: by 10.152.121.105 with SMTP id lj9mr1312211lab.37.1392906788010; Thu, 20 Feb 2014 06:33:08 -0800 (PST) Received: by 10.112.236.33 with HTTP; Thu, 20 Feb 2014 06:33:07 -0800 (PST) X-Originating-IP: [24.114.255.99] Date: Thu, 20 Feb 2014 09:33:07 -0500 Message-ID: From: Ida Leung To: softwires@ietf.org Content-Type: multipart/alternative; boundary=089e012277164ea13204f2d7623a Archived-At: http://mailarchive.ietf.org/arch/msg/softwires/eB4_whYx-LypWGggCJJlzPF-JCg Subject: [Softwires] reply: Working group last call for draft-ietf-softwire-map-t-05 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 14:33:14 -0000 --089e012277164ea13204f2d7623a Content-Type: text/plain; charset=ISO-8859-1 I support to move this draft to advance to an experimental RFC. Thanks, ...Ida --089e012277164ea13204f2d7623a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I support to move this draft to advance to an experimental= RFC. =A0

Thanks,

...Ida



=
--089e012277164ea13204f2d7623a-- From nobody Thu Feb 20 06:53:00 2014 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8403F1A01DA for ; Thu, 20 Feb 2014 06:52:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.049 X-Spam-Level: X-Spam-Status: No, score=-10.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 nakXD3Y4pobn for ; Thu, 20 Feb 2014 06:52:48 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) by ietfa.amsl.com (Postfix) with ESMTP id 3581A1A01D2 for ; Thu, 20 Feb 2014 06:52:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1294; q=dns/txt; s=iport; t=1392907964; x=1394117564; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ifOGmNU6FfHgVixAMnHHbQ+rTROleTXSivQft5RWQnM=; b=aGioSPouvm3EG3D0NtdltWCz065KQhM9HcSmGcJH/l266LnqqUKu5nOq X+NwAABSaBWU4i4j0Fk4qYuZASwofRZMU2GQB3TwrN/v8FYm8y2o4qqWo w7vOwGEcov2Lm4Dze4kdkkn8SN3wzzVyByBn8QQMqL3ofIVv1KM2PaDkG c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAOoVBlOtJXG8/2dsb2JhbABZgwY4V788T4EOFnSCJQEBAQQBAQEaHTQLDAQCAQgRBAEBCxQJBycLFAkIAgQOBQgBEodqDc4vF44zMQcGgx6BFASZYpBygy2CKg X-IronPort-AV: E=Sophos;i="4.97,512,1389744000"; d="scan'208";a="21894381" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by alln-iport-6.cisco.com with ESMTP; 20 Feb 2014 14:52:44 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id s1KEqisL004634 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 20 Feb 2014 14:52:44 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.84]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0123.003; Thu, 20 Feb 2014 08:52:44 -0600 From: "Roberta Maglione (robmgl)" To: Softwires WG Thread-Topic: [Softwires] Working group last call for draft-ietf-softwire-map-t-05 Thread-Index: AQHPKUiczyk1VkQ+fkirwZ1Q990Ru5q+QloQ Date: Thu, 20 Feb 2014 14:52:43 +0000 Message-ID: <57C3345230A4F94C9B2F5CFA05D7F2BD1D615868@xmb-rcd-x01.cisco.com> References: <52FDAE7B.8090009@ericsson.com> In-Reply-To: <52FDAE7B.8090009@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.149.95] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/softwires/Xv9EZySZpboMooLMXR4mEhQn_J4 Cc: Yong Cui Subject: Re: [Softwires] Working group last call for draft-ietf-softwire-map-t-05 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 14:52:51 -0000 Hello, we have several customers asking for this solution: I support advancing thi= s draft as an experimental RFC. Regards Roberta -----Original Message----- From: Softwires [mailto:softwires-bounces@ietf.org] On Behalf Of Suresh Kri= shnan Sent: Friday, February 14, 2014 12:50 AM To: Softwires WG Cc: Yong Cui Subject: [Softwires] Working group last call for draft-ietf-softwire-map-t-= 05 Hi all, This message starts a two week softwire working group last call on advan= cing the draft about providing Mapping of Address and Port using Translatio= n as an Experimental RFC. The authors believe that this version has address= ed all the issues raised on the document till date.=20 The latest version of the draft is available at http://www.ietf.org/id/draft-ietf-softwire-map-t-05.txt http://tools.ietf.org/html/draft-ietf-softwire-map-t-05 Substantive comments and statements of support/opposition for advancing thi= s document should be directed to the mailing list. Editorial suggestions ca= n be sent directly to the authors. This last call will conclude on February= 28, 2014 Regards, Suresh & Yong _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires From nobody Thu Feb 20 07:25:37 2014 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF2291A01CC for ; Thu, 20 Feb 2014 07:25:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 lChVu4IIiVI6 for ; Thu, 20 Feb 2014 07:25:31 -0800 (PST) Received: from mx2.mybrighthouse.com (MX2.mybrighthouse.com [209.16.122.104]) by ietfa.amsl.com (Postfix) with ESMTP id 89D161A01CA for ; Thu, 20 Feb 2014 07:25:31 -0800 (PST) Received: from pps.filterd (mx2.mybrighthouse.com [127.0.0.1]) by mx2.mybrighthouse.com (8.14.5/8.14.5) with SMTP id s1KFMuVN012797; Thu, 20 Feb 2014 10:25:27 -0500 Received: from cnaabex1.corp.local ([10.225.131.11]) by mx2.mybrighthouse.com with ESMTP id 1j5hnej7se-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 20 Feb 2014 10:25:27 -0500 Received: from CNAABEX3.corp.local ([fe80::8cb1:5fdb:b0df:98de]) by CNAABEX1.corp.local ([::1]) with mapi id 14.03.0158.001; Thu, 20 Feb 2014 10:25:27 -0500 From: "Mallette, Edwin J." To: Softwires WG Thread-Topic: [Softwires] Working group last call for draft-ietf-softwire-map-t-05 Thread-Index: AQHPKUic0MfDAHKJGUabpsOEG4bEwJq+QloQgAALdwA= Date: Thu, 20 Feb 2014 15:25:25 +0000 Message-ID: References: <52FDAE7B.8090009@ericsson.com> <57C3345230A4F94C9B2F5CFA05D7F2BD1D615868@xmb-rcd-x01.cisco.com> In-Reply-To: <57C3345230A4F94C9B2F5CFA05D7F2BD1D615868@xmb-rcd-x01.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.225.5.12] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1402200072 Archived-At: http://mailarchive.ietf.org/arch/msg/softwires/HT5tW75rkdI4hZ3OfyoT1UslcBo Cc: Yong Cui Subject: Re: [Softwires] Working group last call for draft-ietf-softwire-map-t-05 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 15:25:36 -0000 Support. >-----Original Message----- >From: Softwires [mailto:softwires-bounces@ietf.org] On Behalf Of Suresh >Krishnan >Sent: Friday, February 14, 2014 12:50 AM >To: Softwires WG >Cc: Yong Cui >Subject: [Softwires] Working group last call for >draft-ietf-softwire-map-t-05 > >Hi all, > This message starts a two week softwire working group last call on >advancing the draft about providing Mapping of Address and Port using >Translation as an Experimental RFC. The authors believe that this version >has addressed all the issues raised on the document till date. >The latest version of the draft is available at > >http://www.ietf.org/id/draft-ietf-softwire-map-t-05.txt >http://tools.ietf.org/html/draft-ietf-softwire-map-t-05 > >Substantive comments and statements of support/opposition for advancing >this document should be directed to the mailing list. Editorial >suggestions can be sent directly to the authors. This last call will >conclude on February 28, 2014 > >Regards, >Suresh & Yong > > >_______________________________________________ >Softwires mailing list >Softwires@ietf.org >https://www.ietf.org/mailman/listinfo/softwires > >_______________________________________________ >Softwires mailing list >Softwires@ietf.org >https://www.ietf.org/mailman/listinfo/softwires ________________________________ CONFIDENTIALITY NOTICE: This e-mail may contain information that is privile= ged, confidential or otherwise protected from disclosure. **If you are not = the intended recipient of this e-mail, please notify the sender immediately= by return e-mail, purge it and do not disseminate or copy it. From nobody Thu Feb 20 10:10:36 2014 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4CB01A00CA for ; Thu, 20 Feb 2014 10:10:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.049 X-Spam-Level: X-Spam-Status: No, score=-15.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 wN9r0B5i1rLF for ; Thu, 20 Feb 2014 10:10:31 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 765C81A00A3 for ; Thu, 20 Feb 2014 10:10:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2242; q=dns/txt; s=iport; t=1392919828; x=1394129428; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=Xxq99hJtbBGs8eIr9V2whYUxUiJzITMTkcibJQrG4PQ=; b=gzXOmTC2QnZqaCdx7E223pQxkVnn5ZP5d6OtXtIj0SRXqwOS/UX/efmb EAs10wG+FXrkcEH12FnP8cPCWKytUyOw61amNjlE72Y5wN2dMU9gNH6e7 wbhdVzQwbYm1ht363RdEowbI3GX6sTg34UnohKORsPiXgy66g1N8UBs48 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAItEBlOtJXHA/2dsb2JhbABZgwY4V78/T4EQFnSCJQEBAQQBAQEaHTQLDAYBCBEDAQEBHwkuCxQJCAIEAQ0FCYd8Dc4YF445KwcCBIQyBJgwgTKQcoMtgio X-IronPort-AV: E=Sophos;i="4.97,513,1389744000"; d="scan'208";a="305497728" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-4.cisco.com with ESMTP; 20 Feb 2014 18:10:27 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id s1KIAR56019489 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 20 Feb 2014 18:10:27 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.236]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0123.003; Thu, 20 Feb 2014 12:10:27 -0600 From: "Rajiv Asati (rajiva)" To: "Mallette, Edwin J." , Softwires WG Thread-Topic: [Softwires] Working group last call for draft-ietf-softwire-map-t-05 Thread-Index: AQHPKUicXHWX7GBEdkas2mjzSs0Ywpq+QloQgABvnoD//9pCAA== Date: Thu, 20 Feb 2014 18:10:26 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [64.102.38.115] Content-Type: text/plain; charset="us-ascii" Content-ID: <99E319280D36BB45B8BD906F73CEDD8F@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/softwires/v-kdX9_MIGj7N8WafZbXVJnd_IA Cc: Yong Cui Subject: Re: [Softwires] Working group last call for draft-ietf-softwire-map-t-05 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 18:10:33 -0000 Support. --=20 Cheers, Rajiv Asati Distinguished Engineer, Cisco -----Original Message----- From: , Edwin Mallette Date: Thursday, February 20, 2014 10:25 AM To: Softwires-wg list Cc: Yong Cui Subject: Re: [Softwires] Working group last call for draft-ietf-softwire-map-t-05 >Support. > >>-----Original Message----- >>From: Softwires [mailto:softwires-bounces@ietf.org] On Behalf Of Suresh >>Krishnan >>Sent: Friday, February 14, 2014 12:50 AM >>To: Softwires WG >>Cc: Yong Cui >>Subject: [Softwires] Working group last call for >>draft-ietf-softwire-map-t-05 >> >>Hi all, >> This message starts a two week softwire working group last call on >>advancing the draft about providing Mapping of Address and Port using >>Translation as an Experimental RFC. The authors believe that this version >>has addressed all the issues raised on the document till date. >>The latest version of the draft is available at >> >>http://www.ietf.org/id/draft-ietf-softwire-map-t-05.txt >>http://tools.ietf.org/html/draft-ietf-softwire-map-t-05 >> >>Substantive comments and statements of support/opposition for advancing >>this document should be directed to the mailing list. Editorial >>suggestions can be sent directly to the authors. This last call will >>conclude on February 28, 2014 >> >>Regards, >>Suresh & Yong >> >> >>_______________________________________________ >>Softwires mailing list >>Softwires@ietf.org >>https://www.ietf.org/mailman/listinfo/softwires >> >>_______________________________________________ >>Softwires mailing list >>Softwires@ietf.org >>https://www.ietf.org/mailman/listinfo/softwires > > >________________________________ > >CONFIDENTIALITY NOTICE: This e-mail may contain information that is >privileged, confidential or otherwise protected from disclosure. **If you >are not the intended recipient of this e-mail, please notify the sender >immediately by return e-mail, purge it and do not disseminate or copy it. > >_______________________________________________ >Softwires mailing list >Softwires@ietf.org >https://www.ietf.org/mailman/listinfo/softwires From nobody Thu Feb 20 18:46:55 2014 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BE341A01E7 for ; Thu, 20 Feb 2014 18:46:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] 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 loxbWpxOXdHa for ; Thu, 20 Feb 2014 18:46:52 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 020821A027B for ; Thu, 20 Feb 2014 18:46:51 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BDU59307; Fri, 21 Feb 2014 02:46:47 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 21 Feb 2014 02:46:30 +0000 Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 21 Feb 2014 02:46:46 +0000 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.72]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Fri, 21 Feb 2014 10:46:43 +0800 From: "Liubing (Leo)" To: Softwires WG Thread-Topic: [Softwires] Working group last call for draft-ietf-softwire-4rd-07 Thread-Index: AQHPKUjtcvo8FPPyT0iIBVlxUDS8Qpq/Cr7w Date: Fri, 21 Feb 2014 02:46:42 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D8362CF@nkgeml506-mbx.china.huawei.com> References: <52FDAF01.6080308@ericsson.com> In-Reply-To: <52FDAF01.6080308@ericsson.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.132] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/softwires/q1iVyzZnMCu7aqb3U3j7qgzODtg Subject: Re: [Softwires] Working group last call for draft-ietf-softwire-4rd-07 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 02:46:54 -0000 Hi all, I support advancing 4rd as an experimental RFC. Regards, Bing > -----Original Message----- > From: Softwires [mailto:softwires-bounces@ietf.org] On Behalf Of Suresh > Krishnan > Sent: Friday, February 14, 2014 1:52 PM > To: Softwires WG > Cc: Yong Cui > Subject: [Softwires] Working group last call for draft-ietf-softwire-4rd-= 07 >=20 > Hi all, > This message starts a two week softwire working group last call on > advancing the draft about IPv4 Residual Deployment via IPv6 - a Stateless > Solution (4rd) as an Experimental RFC. The authors believe that this vers= ion > has addressed all the issues raised on the document till date. The latest > version of the draft is available at >=20 > http://www.ietf.org/id/draft-ietf-softwire-4rd-07.txt > http://tools.ietf.org/html/draft-ietf-softwire-4rd-07 >=20 > Substantive comments and statements of support/opposition for advancing > this document should be directed to the mailing list. Editorial suggestio= ns > can be sent directly to the authors. This last call will conclude on Febr= uary 28, > 2014 >=20 > Regards, > Suresh & Yong >=20 >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From nobody Thu Feb 20 19:53:40 2014 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6916B1A03F0 for ; Thu, 20 Feb 2014 19:53:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.748 X-Spam-Level: X-Spam-Status: No, score=-0.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_EQ_MODEMCABLE=1.368, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 QmOrvOJa7bXX for ; Thu, 20 Feb 2014 19:53:31 -0800 (PST) Received: from cable.comcast.com (pacdcavout01.cable.comcast.com [69.241.43.119]) by ietfa.amsl.com (Postfix) with ESMTP id 874F21A03E7 for ; Thu, 20 Feb 2014 19:53:30 -0800 (PST) Received: from ([24.40.56.114]) by pacdcavout01.cable.comcast.com with ESMTP id 97wm3m1.84026247; Thu, 20 Feb 2014 22:53:24 -0500 Received: from PACDCEXMB05.cable.comcast.com ([169.254.7.116]) by PACDCEXHUB01.cable.comcast.com ([fe80::84e8:95f3:f13b:169e%12]) with mapi id 14.03.0158.001; Thu, 20 Feb 2014 22:53:24 -0500 From: "Lee, Yiu" To: Softwires WG Thread-Topic: [Softwires] Working group last call for draft-ietf-softwire-map-t-05 Thread-Index: AQHPLrh3rSu7FMBLp0CXOab/5wPYqQ== Date: Fri, 21 Feb 2014 03:54:55 +0000 Message-ID: References: <52FDAE7B.8090009@ericsson.com> In-Reply-To: <52FDAE7B.8090009@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [68.87.16.246] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3475781603_977911" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/softwires/NNnkTm6Hzl5qQMSMs_md0Fb_-4Q Subject: Re: [Softwires] Working group last call for draft-ietf-softwire-map-t-05 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 03:53:32 -0000 --B_3475781603_977911 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit support On 2/14/14, 12:49 AM, "Suresh Krishnan" wrote: >Hi all, > This message starts a two week softwire working group last call on >advancing the draft about providing Mapping of Address and Port using >Translation as an Experimental RFC. The authors believe that this >version has addressed all the issues raised on the document till date. >The latest version of the draft is available at > >http://www.ietf.org/id/draft-ietf-softwire-map-t-05.txt >http://tools.ietf.org/html/draft-ietf-softwire-map-t-05 > >Substantive comments and statements of support/opposition for advancing >this document should be directed to the mailing list. Editorial >suggestions can be sent directly to the authors. This last call will >conclude on February 28, 2014 > >Regards, >Suresh & Yong > > >_______________________________________________ >Softwires mailing list >Softwires@ietf.org >https://www.ietf.org/mailman/listinfo/softwires --B_3475781603_977911 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIVmQYJKoZIhvcNAQcCoIIVijCCFYYCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EzEwggU0MIIEHKADAgECAhEAhv91O+XLvFe6aL7jamWK/zANBgkqhkiG9w0BAQUFADCBkzEL MAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGll bnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xMzEwMjkwMDAwMDBa Fw0xNDEwMjkyMzU5NTlaMCoxKDAmBgkqhkiG9w0BCQEWGXlpdV9sZWVAY2FibGUuY29tY2Fz dC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC68JKaZEJ0LViFfKWqzK16 nmjp8sC/1jA2TzrY2At4mju7v3WF1auk6Vqu2eTNoOIrkAvmseseON8/1jekEzEcDejhGAIf WypQyVw0Dxi+0FVdUi59simiUcP3S4bU9sCIUbJl9Pbl83gtzqZ6rg20K0OHgHWCJ/Yk47qd y8aHN8iOX88YFKzvYM5tbDp2La6c1cO5aXujFL5/31Ua6Q+YB/C/vqRtUxGgqU/akpem+mUl sVlmJEyeBcS8M4goFFWeHidg17gjtMFEdZOwmueJ8+mlVpo+LFlE9Mm8Kk+qEwLLbdht8vDX hpmnpT/ZQBGFhI2lF9x5Cy6nw50PpIEvAgMBAAGjggHpMIIB5TAfBgNVHSMEGDAWgBR6E04A dFvGeGNkJ8Ev4qBbvHnFezAdBgNVHQ4EFgQUoLfLQmNdcYV5HlfkXY4zHV0EjpQwDgYDVR0P AQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0lBBkwFwYIKwYBBQUHAwQGCysGAQQBsjEB AwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEBATArMCkG CCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBXBgNVHR8EUDBOMEyg SqBIhkZodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlv bmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGIBggrBgEFBQcBAQR8MHowUgYIKwYBBQUHMAKGRmh0 dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2Vj dXJlRW1haWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAk BgNVHREEHTAbgRl5aXVfbGVlQGNhYmxlLmNvbWNhc3QuY29tMA0GCSqGSIb3DQEBBQUAA4IB AQBRECrUaqaZ9idV79Ty+gKD3ikFYrD/oXOAYQUeccSscBzy8DlahjhnDM8NXaA2ny5vI85/ vMJl3WUWD5J7Ft9L8uw9k0EfsUCIqZQp+9mZcXtqynCeKcAL/p2Ys0p//aqf00wyWooUwhPW aniWqP1+VqoTHVrIOQ1xrbBeLbm3f3F4DXVxO9wRlFndeyqStECo9jamYsLnHOFeCfxtmXE/ czOemMA3ZFWeycKD688z2vrDK5RS54fyTUZBpDR+xZJ0tQIDZu4cwoVd0tD+3yjgDpxCdSw7 zkWyqCZ/MmhTlMx0Jc7b2X3QcHNud5lDyYgy8tvaUjlQTrW3Hx2XbeFXMIIFGjCCBAKgAwIB AgIQbRnqpxlPajMi5iIyeqpx3jANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJU UlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNV BAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0x MTA0MjgwMDAwMDBaFw0yMDA1MzAxMDQ4MzhaMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMS R3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8g Q0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg U2VjdXJlIEVtYWlsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoSEW0tX mNReL4uk4UDIo1NYX2Zl8TJO958yfVXQeExVt0KU4PkncQfFxmmkuTLE8UAakMwnVmJ/F7Vx aa7lIBvky2NeYMqiQfZq4aP/uN8fSG1lQ4wqLitjOHffsReswtqCAtbUMmrUZ28gE49cNfrl VICv2HEKHTcKAlBTbJUdqRAUtJmVWRIx/wmi0kzcUtve4kABW0ho3cVKtODtJB86r3FfB+Os vxQ7sCVxaD30D9YXWEYVgTxoi4uDD216IVfmNLDbMn7jSuGlUnJkJpFOpZIP/+CxYP0ab2hR mWONGoulzEKbm30iY9OpoPzOnpDfRBn0XFs1uhbzp5v/wQIDAQABo4IBSzCCAUcwHwYDVR0j BBgwFoAUiYJnfcSdJnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFHoTTgB0W8Z4Y2QnwS/ioFu8 ecV7MA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEAMBEGA1UdIAQKMAgwBgYE VR0gADBYBgNVHR8EUTBPME2gS6BJhkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVROLVVT RVJGaXJzdC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDB0BggrBgEFBQcBAQRo MGYwPQYIKwYBBQUHMAKGMWh0dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BZGRUcnVzdENs aWVudF9DQS5jcnQwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJ KoZIhvcNAQEFBQADggEBAIXWvnhXVW0zf0RS/kLVBqgBA4CK+w2y/Uq/9q9BSfUbWsXSrRtz bj7pJnzmTJjBMCjfy/tCPKElPgp11tA9OYZm0aGbtU2bb68obB2v5ep0WqjascDxdXovnrqT ecr+4pEeVnSy+I3T4ENyG+2P/WA5IEf7i686ZUg8mD2lJb+972DgSeUWyOs/Q4Pw4O4NwdPN M1+b0L1garM7/vrUyTo8H+2b/5tJM75CKTmD7jNpLoKdRU2oadqAGx490hpdfEeZpZsIbRKZ htZdVwcbpzC+S0lEuJB+ytF5OOu0M/qgOl0mWJ5hVRi0IdWZ1eBDQEIwvuql55TSsP7zdfl/ bucwggSdMIIDhaADAgECAhA0PekrrCc0/4/LNJT7zHBUMA0GCSqGSIb3DQEBBQUAMG8xCzAJ BgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0 ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3Qw HhcNMDUwNjA3MDgwOTEwWhcNMjAwNTMwMTA0ODM4WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNV BAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVT VCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMT LVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjM apjVTTUZuaRC5c5J4oovHnzSMQfHTrSDZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKT zMmkMpW7DE8wvZigC4vlbhuiRvp4vKJvq1lepS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZG zaCl6r4LznY6eg6b6vzaJ1s9cx8i5khhxkzzabGoLhu21DEgLLyCio6kDqXXiUP8FlqvHXHX EVnauocNr/rz4cLwpMVnjNbWVDreCqS6A3ezZcj9HtN0YqoYymiTHqGFfvVHZcv4TVcodNI0 /zC27vZiMBSMLOsCAwEAAaOB9DCB8TAfBgNVHSMEGDAWgBStvZh6NLQm9/rEJlTvA73gJMtU GjAdBgNVHQ4EFgQUiYJnfcSdJnAAS7RQSHzePa4Ebn0wDgYDVR0PAQH/BAQDAgEGMA8GA1Ud EwEB/wQFMAMBAf8wEQYDVR0gBAowCDAGBgRVHSAAMEQGA1UdHwQ9MDswOaA3oDWGM2h0dHA6 Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFsQ0FSb290LmNybDA1BggrBgEF BQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZI hvcNAQEFBQADggEBAAG8nONjKLDzMQHC33vdYqABnSMxD5ySc1NR6h9M+tafxMovZ354Mw90 FrmRh5H1iib6ZHAA2B75CwRiUIeTgdTa9SPbNLuFVrRwNG54gzcehRzFERWSX4cXvaxq/fHC 0cyJX7F88D5R8jXzfOxgmGs6K+Dv37N9huu1G/Vb7KJ8mBPXAFC50S1z3gN4dOEFhTFey5q5 nZTGuZQ3dXLcRPtn6PD6JR5Sp9ol6UfgoMc8oE6xCjb7d0if75eK+7T+45QUqIO8XC0/0mBx YO7CcYIM6Yg249ogtKOgbKqWS7iAjnXKSQf2OxS639wF2Z/b4LLmTaB4JufnLW5/X8YeiBUw ggQ2MIIDHqADAgECAgEBMA0GCSqGSIb3DQEBBQUAMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQK EwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsx IjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMDAwNTMwMTA0ODM4WhcN MjAwNTMwMTA0ODM4WjBvMQswCQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAk BgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVz dCBFeHRlcm5hbCBDQSBSb290MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAt/ca M+byAAQtOeBOW+0fvGwPzbX6I7bO3psRM5ekKUx9k5+9SryT7QMa44/P5W1QWtaXKZRagLBJ etsulf24yr83OC0ePpFBrXBWx/BPP+gynnTKyJBU6cZfD3idmkA8Dqxhql4Uj56HoWpQ3Nea Tq8Fs6ZxlJxxs1BgCscTnTgHhgKo6ahpJhiQq0ywTyOrOk+E2N/On+Fpb7vXQtdrROTHre5t QV9yWnEIN7N5ZaRZoJQ39wAvDcKSctrQOHLbFKhFxF0qfbe01sTurM0TRLfJK91DACX6Yblp algjEbenM49WdVn1zSnXRrcKK2W200JvFbK4e/vv6V1T1TRaJwIDAQABo4HcMIHZMB0GA1Ud DgQWBBStvZh6NLQm9/rEJlTvA73gJMtUGjALBgNVHQ8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB /zCBmQYDVR0jBIGRMIGOgBStvZh6NLQm9/rEJlTvA73gJMtUGqFzpHEwbzELMAkGA1UEBhMC U0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBU VFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdIIBATANBgkq hkiG9w0BAQUFAAOCAQEAsJvghSXC1iPiD5YGkp1BmJzZhHmB2R5bFAcjNmWPsNh3u6xBbEdg g1Gw+TI95/z2JhPHgBalv1r8h894eYkhmuJMBwqGNbzy3lHE0pa33H5O7nD9HDnrDAJRFC2O vRbgwd9Gdeckrez0QrSFk3AQZ7qdBjVKGNMresxRQqF6Y9Hmu6HFK8I2vhMN5r1jfnl7pwkN QKtq3Y+Kw/b2jBpCBVHURfWfp2IhaBUgQzyZ53y9JNipkRdziD9WGzE4GLRxD5rNyA6eji4b 4YyYg8sfMfFETMYEc0l2YA/H+L0XgGsu6cxMDlqaeQ8gCi7VnmMmHlWSlNiCF1p70LzHj06G BDGCAjAwggIsAgEBMIGpMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5j aGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5 MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBAhEAhv91O+XLvFe6aL7jamWK/zAJBgUrDgMCGgUAoF0wIwYJKoZIhvcNAQkEMRYEFEHQ Wy93M+NdZWaE9KdMvyW9UCSTMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTE0MDIyMTAzNTMyMVowDQYJKoZIhvcNAQEBBQAEggEATYifCuCECnv62REevkPA TJ98W6QabDgNsXmtewrCcpKcqI/9bzks2UmXSnh5pwR1LOQnKnXjpKsiG1X980gMa60JQ7oG Ld8kCjqBxvYdeLF8Ov3oDbogCryJoJZ2P2z/mr34Gu/dGasuiyxpEDu+02FMgRMPdBn7s7Hn CKrqxLn4wlpb7hvac08K5THJAHiAClJRB94t+GuKFpYuL2PK4Cy+oyJoKdDuJcCBJ7Sn5gwR urZnLhnOKXza41GNHlkorhLx0GpJJU5haauHa0PxOK20cqxEYr54hQxJX6U1aRd01azKc1wc o8M8xvuUMRWJr0CE58xKiXM1RXAWsDL/7A== --B_3475781603_977911-- From nobody Thu Feb 20 19:53:48 2014 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AB2E1A03E0 for ; Thu, 20 Feb 2014 19:53:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.382 X-Spam-Level: X-Spam-Status: No, score=-3.382 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 OccZhU7YQYPp for ; Thu, 20 Feb 2014 19:53:42 -0800 (PST) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 961FE1A03F3 for ; Thu, 20 Feb 2014 19:53:42 -0800 (PST) Received: from ([24.40.56.116]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.118066830; Thu, 20 Feb 2014 20:53:35 -0700 Received: from PACDCEXMB05.cable.comcast.com ([169.254.7.116]) by pacdcexhub03.cable.comcast.com ([fe80::5527:6d6b:29a7:f414%13]) with mapi id 14.03.0158.001; Thu, 20 Feb 2014 22:53:35 -0500 From: "Lee, Yiu" To: Softwires WG Thread-Topic: [Softwires] Working group last call for draft-ietf-softwire-4rd-07 Thread-Index: AQHPLrh+RpqWZSS+8U+mkq95DMcKwg== Date: Fri, 21 Feb 2014 03:55:07 +0000 Message-ID: References: <52FDAF01.6080308@ericsson.com> In-Reply-To: <52FDAF01.6080308@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [68.87.16.249] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3475781614_981472" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/softwires/3PGKGyFXyqFCebxHoWYShgshzno Subject: Re: [Softwires] Working group last call for draft-ietf-softwire-4rd-07 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 03:53:46 -0000 --B_3475781614_981472 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit support On 2/14/14, 12:52 AM, "Suresh Krishnan" wrote: >Hi all, > This message starts a two week softwire working group last call on >advancing the draft about IPv4 Residual Deployment via IPv6 - a >Stateless Solution (4rd) as an Experimental RFC. The authors believe >that this version has addressed all the issues raised on the document >till date. The latest version of the draft is available at > >http://www.ietf.org/id/draft-ietf-softwire-4rd-07.txt >http://tools.ietf.org/html/draft-ietf-softwire-4rd-07 > >Substantive comments and statements of support/opposition for advancing >this document should be directed to the mailing list. Editorial >suggestions can be sent directly to the authors. This last call will >conclude on February 28, 2014 > >Regards, >Suresh & Yong > > >_______________________________________________ >Softwires mailing list >Softwires@ietf.org >https://www.ietf.org/mailman/listinfo/softwires --B_3475781614_981472 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIVmQYJKoZIhvcNAQcCoIIVijCCFYYCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EzEwggU0MIIEHKADAgECAhEAhv91O+XLvFe6aL7jamWK/zANBgkqhkiG9w0BAQUFADCBkzEL MAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGll bnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xMzEwMjkwMDAwMDBa Fw0xNDEwMjkyMzU5NTlaMCoxKDAmBgkqhkiG9w0BCQEWGXlpdV9sZWVAY2FibGUuY29tY2Fz dC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC68JKaZEJ0LViFfKWqzK16 nmjp8sC/1jA2TzrY2At4mju7v3WF1auk6Vqu2eTNoOIrkAvmseseON8/1jekEzEcDejhGAIf WypQyVw0Dxi+0FVdUi59simiUcP3S4bU9sCIUbJl9Pbl83gtzqZ6rg20K0OHgHWCJ/Yk47qd y8aHN8iOX88YFKzvYM5tbDp2La6c1cO5aXujFL5/31Ua6Q+YB/C/vqRtUxGgqU/akpem+mUl sVlmJEyeBcS8M4goFFWeHidg17gjtMFEdZOwmueJ8+mlVpo+LFlE9Mm8Kk+qEwLLbdht8vDX hpmnpT/ZQBGFhI2lF9x5Cy6nw50PpIEvAgMBAAGjggHpMIIB5TAfBgNVHSMEGDAWgBR6E04A dFvGeGNkJ8Ev4qBbvHnFezAdBgNVHQ4EFgQUoLfLQmNdcYV5HlfkXY4zHV0EjpQwDgYDVR0P AQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0lBBkwFwYIKwYBBQUHAwQGCysGAQQBsjEB AwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEBATArMCkG CCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBXBgNVHR8EUDBOMEyg SqBIhkZodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlv bmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGIBggrBgEFBQcBAQR8MHowUgYIKwYBBQUHMAKGRmh0 dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2Vj dXJlRW1haWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAk BgNVHREEHTAbgRl5aXVfbGVlQGNhYmxlLmNvbWNhc3QuY29tMA0GCSqGSIb3DQEBBQUAA4IB AQBRECrUaqaZ9idV79Ty+gKD3ikFYrD/oXOAYQUeccSscBzy8DlahjhnDM8NXaA2ny5vI85/ vMJl3WUWD5J7Ft9L8uw9k0EfsUCIqZQp+9mZcXtqynCeKcAL/p2Ys0p//aqf00wyWooUwhPW aniWqP1+VqoTHVrIOQ1xrbBeLbm3f3F4DXVxO9wRlFndeyqStECo9jamYsLnHOFeCfxtmXE/ czOemMA3ZFWeycKD688z2vrDK5RS54fyTUZBpDR+xZJ0tQIDZu4cwoVd0tD+3yjgDpxCdSw7 zkWyqCZ/MmhTlMx0Jc7b2X3QcHNud5lDyYgy8tvaUjlQTrW3Hx2XbeFXMIIFGjCCBAKgAwIB AgIQbRnqpxlPajMi5iIyeqpx3jANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJU UlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNV BAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0x MTA0MjgwMDAwMDBaFw0yMDA1MzAxMDQ4MzhaMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMS R3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8g Q0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg U2VjdXJlIEVtYWlsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoSEW0tX mNReL4uk4UDIo1NYX2Zl8TJO958yfVXQeExVt0KU4PkncQfFxmmkuTLE8UAakMwnVmJ/F7Vx aa7lIBvky2NeYMqiQfZq4aP/uN8fSG1lQ4wqLitjOHffsReswtqCAtbUMmrUZ28gE49cNfrl VICv2HEKHTcKAlBTbJUdqRAUtJmVWRIx/wmi0kzcUtve4kABW0ho3cVKtODtJB86r3FfB+Os vxQ7sCVxaD30D9YXWEYVgTxoi4uDD216IVfmNLDbMn7jSuGlUnJkJpFOpZIP/+CxYP0ab2hR mWONGoulzEKbm30iY9OpoPzOnpDfRBn0XFs1uhbzp5v/wQIDAQABo4IBSzCCAUcwHwYDVR0j BBgwFoAUiYJnfcSdJnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFHoTTgB0W8Z4Y2QnwS/ioFu8 ecV7MA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEAMBEGA1UdIAQKMAgwBgYE VR0gADBYBgNVHR8EUTBPME2gS6BJhkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVROLVVT RVJGaXJzdC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDB0BggrBgEFBQcBAQRo MGYwPQYIKwYBBQUHMAKGMWh0dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BZGRUcnVzdENs aWVudF9DQS5jcnQwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJ KoZIhvcNAQEFBQADggEBAIXWvnhXVW0zf0RS/kLVBqgBA4CK+w2y/Uq/9q9BSfUbWsXSrRtz bj7pJnzmTJjBMCjfy/tCPKElPgp11tA9OYZm0aGbtU2bb68obB2v5ep0WqjascDxdXovnrqT ecr+4pEeVnSy+I3T4ENyG+2P/WA5IEf7i686ZUg8mD2lJb+972DgSeUWyOs/Q4Pw4O4NwdPN M1+b0L1garM7/vrUyTo8H+2b/5tJM75CKTmD7jNpLoKdRU2oadqAGx490hpdfEeZpZsIbRKZ htZdVwcbpzC+S0lEuJB+ytF5OOu0M/qgOl0mWJ5hVRi0IdWZ1eBDQEIwvuql55TSsP7zdfl/ bucwggSdMIIDhaADAgECAhA0PekrrCc0/4/LNJT7zHBUMA0GCSqGSIb3DQEBBQUAMG8xCzAJ BgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0 ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3Qw HhcNMDUwNjA3MDgwOTEwWhcNMjAwNTMwMTA0ODM4WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNV BAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVT VCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMT LVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjM apjVTTUZuaRC5c5J4oovHnzSMQfHTrSDZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKT zMmkMpW7DE8wvZigC4vlbhuiRvp4vKJvq1lepS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZG zaCl6r4LznY6eg6b6vzaJ1s9cx8i5khhxkzzabGoLhu21DEgLLyCio6kDqXXiUP8FlqvHXHX EVnauocNr/rz4cLwpMVnjNbWVDreCqS6A3ezZcj9HtN0YqoYymiTHqGFfvVHZcv4TVcodNI0 /zC27vZiMBSMLOsCAwEAAaOB9DCB8TAfBgNVHSMEGDAWgBStvZh6NLQm9/rEJlTvA73gJMtU GjAdBgNVHQ4EFgQUiYJnfcSdJnAAS7RQSHzePa4Ebn0wDgYDVR0PAQH/BAQDAgEGMA8GA1Ud EwEB/wQFMAMBAf8wEQYDVR0gBAowCDAGBgRVHSAAMEQGA1UdHwQ9MDswOaA3oDWGM2h0dHA6 Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFsQ0FSb290LmNybDA1BggrBgEF BQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZI hvcNAQEFBQADggEBAAG8nONjKLDzMQHC33vdYqABnSMxD5ySc1NR6h9M+tafxMovZ354Mw90 FrmRh5H1iib6ZHAA2B75CwRiUIeTgdTa9SPbNLuFVrRwNG54gzcehRzFERWSX4cXvaxq/fHC 0cyJX7F88D5R8jXzfOxgmGs6K+Dv37N9huu1G/Vb7KJ8mBPXAFC50S1z3gN4dOEFhTFey5q5 nZTGuZQ3dXLcRPtn6PD6JR5Sp9ol6UfgoMc8oE6xCjb7d0if75eK+7T+45QUqIO8XC0/0mBx YO7CcYIM6Yg249ogtKOgbKqWS7iAjnXKSQf2OxS639wF2Z/b4LLmTaB4JufnLW5/X8YeiBUw ggQ2MIIDHqADAgECAgEBMA0GCSqGSIb3DQEBBQUAMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQK EwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsx IjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMDAwNTMwMTA0ODM4WhcN MjAwNTMwMTA0ODM4WjBvMQswCQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAk BgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVz dCBFeHRlcm5hbCBDQSBSb290MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAt/ca M+byAAQtOeBOW+0fvGwPzbX6I7bO3psRM5ekKUx9k5+9SryT7QMa44/P5W1QWtaXKZRagLBJ etsulf24yr83OC0ePpFBrXBWx/BPP+gynnTKyJBU6cZfD3idmkA8Dqxhql4Uj56HoWpQ3Nea Tq8Fs6ZxlJxxs1BgCscTnTgHhgKo6ahpJhiQq0ywTyOrOk+E2N/On+Fpb7vXQtdrROTHre5t QV9yWnEIN7N5ZaRZoJQ39wAvDcKSctrQOHLbFKhFxF0qfbe01sTurM0TRLfJK91DACX6Yblp algjEbenM49WdVn1zSnXRrcKK2W200JvFbK4e/vv6V1T1TRaJwIDAQABo4HcMIHZMB0GA1Ud DgQWBBStvZh6NLQm9/rEJlTvA73gJMtUGjALBgNVHQ8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB /zCBmQYDVR0jBIGRMIGOgBStvZh6NLQm9/rEJlTvA73gJMtUGqFzpHEwbzELMAkGA1UEBhMC U0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBU VFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdIIBATANBgkq hkiG9w0BAQUFAAOCAQEAsJvghSXC1iPiD5YGkp1BmJzZhHmB2R5bFAcjNmWPsNh3u6xBbEdg g1Gw+TI95/z2JhPHgBalv1r8h894eYkhmuJMBwqGNbzy3lHE0pa33H5O7nD9HDnrDAJRFC2O vRbgwd9Gdeckrez0QrSFk3AQZ7qdBjVKGNMresxRQqF6Y9Hmu6HFK8I2vhMN5r1jfnl7pwkN QKtq3Y+Kw/b2jBpCBVHURfWfp2IhaBUgQzyZ53y9JNipkRdziD9WGzE4GLRxD5rNyA6eji4b 4YyYg8sfMfFETMYEc0l2YA/H+L0XgGsu6cxMDlqaeQ8gCi7VnmMmHlWSlNiCF1p70LzHj06G BDGCAjAwggIsAgEBMIGpMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5j aGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5 MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBAhEAhv91O+XLvFe6aL7jamWK/zAJBgUrDgMCGgUAoF0wIwYJKoZIhvcNAQkEMRYEFCGr UO0RR8IHvy6VrNP13PalX3hcMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTE0MDIyMTAzNTMzM1owDQYJKoZIhvcNAQEBBQAEggEAP3tgOV35JWdDXx40wizh 1UW/lGkCR6LzEJyBNnMiqbALM8d0OzotrhBdkRQwPY0JHaoGy+0dy8CUnvLBVH/Cu46p//Q8 OcO0KE/jHv3isjKbDXkkEz3uYaxU0DuPE5XAclfJPE1UPtTsvav92PUrD5jAmkUvOWTnpQ6F q59vTvF5rfo/cSVvETpF66fTD+T/9spWQIDtmHOfGtlX0bmoQwX2JHPgG48H9lsYInsAF2Xt kcb3MVXeyLo5MsWswgOIRHMq5oYzS0ruBX/BeGOOkuwoTBOQDNOnX+Mg5G1FcOafLrET/On7 CApgM7CEZ5jpra0lhameniDse4iIaoJsWQ== --B_3475781614_981472-- From nobody Fri Feb 21 01:26:03 2014 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E42381A01B0 for ; Fri, 21 Feb 2014 01:25:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.301 X-Spam-Level: * X-Spam-Status: No, score=1.301 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, SPF_PASS=-0.001] autolearn=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 EGucOpwxwI9d for ; Fri, 21 Feb 2014 01:25:56 -0800 (PST) Received: from mail-pb0-x22c.google.com (mail-pb0-x22c.google.com [IPv6:2607:f8b0:400e:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 75E641A0502 for ; Fri, 21 Feb 2014 01:25:56 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id rq2so3211079pbb.17 for ; Fri, 21 Feb 2014 01:25:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to; bh=i1jQv2cZmpQuDczpNy5LFLIZ1vO6oH8YTHaHwwTjno4=; b=IC7N2Re6CiICou1HvdAc8e0Wwo8XachHbu0d3zAjQ/wXBN1fU+0cA4qYqG52Vu3avw 6+dTQ8k6MEhESsufFyRWt/fuc02fvr0/xwuf46vLKjZiOPV3kY/UbPzY+m+rdP69QKzg RD3oQZbrwhBBKGl4Vp2WGn6CHGgquozH4kA9Tqtfck6C/IrAg9L+tfH3aiS00Y0FIPRb 5knARLRR0bkACpLUtxLNxu/I24ZD8BFDOdVebtgaHdCVOz/BPmhtB/FsJEd6xI+tyMTw m7Rl+KP0w/8NPGOi5gnchF05IKAEr3vB/gja3qjEJtP6ZYPsHFWlCYyZDmEU6aw+wD3u gCcA== X-Received: by 10.67.22.3 with SMTP id ho3mr7999143pad.128.1392974752666; Fri, 21 Feb 2014 01:25:52 -0800 (PST) Received: from ?IPv6:2402:f000:1:4410:9284:dff:fef3:d346? ([2402:f000:1:4410:9284:dff:fef3:d346]) by mx.google.com with ESMTPSA id sx8sm45174831pab.5.2014.02.21.01.25.45 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 21 Feb 2014 01:25:52 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: multipart/alternative; boundary=Apple-Mail-64-203195463 From: Qi Sun In-Reply-To: Date: Fri, 21 Feb 2014 17:25:39 +0800 Message-Id: References: <20140211075445.17615.61208.idtracker@ietfa.amsl.com> <8A1B81989BCFAE44A22B2B86BF2B76318A2CDB8ED2@HE111643.EMEA1.CDS.T-INTERNAL.COM> To: Wojciech Dec X-Mailer: Apple Mail (2.1085) Archived-At: http://mailarchive.ietf.org/arch/msg/softwires/kF_vAZG-8HvONWNSk-w6B0kLGHg Cc: Softwires WG Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-lw4over6-06.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 09:26:00 -0000 --Apple-Mail-64-203195463 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Woj, On 2014-2-19, at =E4=B8=8B=E5=8D=884:34, Wojciech Dec wrote: >=20 > Just to be clear: I'm ok with lw46 defining a specific functional mode = as I believe it does in this draft, [Qi] The outcome of ietf88 was lw4o6 and map are two mechanisms, but = both use the Softwire DHCP for provisioning (at least according to my = memory). That is why the WG decided to remove the statement of "lw4o6 is = a subset of MAP-E" is from the Softwire DHCP Option draft. And lw4o6 can use DHCPv4 over DHCPv6 and PCP for provisioning. This is = documented in the current lw4o6 draft, and some teams are doing the = documentation work. (We have demoed in IETF85 that lw4o6 can work with = DHCPv4 over IPv6 and PCP). The point is, lw4o6 architecture is quite = flexible.=20 > also leaving "as-is" the DHCP part of it (i.e. it's a capability that = can be signalled using the lw46 container, etc).=20 > General items remain open (as commented): > - Cleanup text that does not belong to lw46 (eg 2473 fixes, or NAT44 = best practice).=20 [Qi] IMO, that text guarantees the interoperation between lwAFTRs and = lwB4s from different vendors, which bothered us a little when carrying = out the interop test. I think it doesn't hurt to make it specific. > - Clarification of WAN selection or assumptions [Qi] I think Ian has expressed cleared in previous mails. >=20 > That said, abundant technical evidence (summarized in previous mail) = indicates that this mode is in near total overlap with MAP 1:1, = certainly much more than at the outset of this work. Given this, why not = align the text and actually make MAP 1:1 and lw46 be the same? On all of = the data plane IPv6, IPv4, NAT44, tunneling and ICMP handling parts I = see there no reason for there being a difference... [Qi] I think lw4o6 is clean and simple, and flexible to work with = different provisioning mechanisms (signaling through the Softwire DHCP = as is agreed by the WG).=20 >=20 > continued inline... >=20 >=20 > On 17 February 2014 17:15, Ian Farrer wrote: > Hi Woj, >=20 > Please see inline. >=20 > Cheers, > Ian >=20 > On 16 Feb 2014, at 17:32, Wojciech Dec wrote: >=20 >> Hi Ian, >>=20 >> you haven't replied on my high level comment - would appreciate if = you introduced changes to that effect in the draft. >>=20 >> Continued inline=E2=80=A6 >=20 > [ian] The draft already contains the following text (and has for some = time): > Lightweight 4over6 provides a solution for a hub-and-spoke softwire > architecture only. It does not offer direct, meshed IPv4 > connectivity between subscribers without packets traversing the = AFTR. > If this type of meshed interconnectivity is required, > [I-D.ietf-softwire-map] provides a suitable solution. > So, are you not happy with the wording of the current reference, or = are you requesting that the draft is rewritten to be cast as a = =E2=80=98specialised' case of MAP? > What I pointed out is that the Lw46 draft has major if near total = overlap with MAP-E 1:1 mode. Stating that lw46 realizes this mode, in a = standalone way from the N:1 mesh mode, is what I propose. This would = greatly help in implementing it and "digesting" the array of solutions.=20= [Qi] I don't see any "help" here... > Additional comment Now that you mention it, the stated = characterisation of map isn't quite right; MAP does not force the use of = mesh mode, nor is mesh mode its defining characteristic. [Qi] =46rom my reading, the text doesn't characterize what MAP is. It = just says "if you want to use meshed IPv4 connectivity, then use MAP". = It doesn't prevent you from using MAP to do anything else. So I think = the text is OK. > The characterisation should be restated as " lw46 does not seek to = offer the optimization of AFTR subscriber state and the AFTR is expected = to have configuration state for each lwB4 node. If optimization of this = state is required, [id-ietf-softwire-map] provides a suitable solution = ".=20 > Alternatively, state that "lw46 describes a deployment/implementation = of MAP 1:1" [Qi] In my opinion, the current wording is clear and enough.=20 > =20 > Either way, I don=E2=80=99t really agree with your justification = points for a change: > - The PSID and the port range are algorithmically derived & related as = per the MAP algorithm (covered in Section 5.1) > [ian] The PSID usage in lw4o6 is written so that you don=E2=80=99t = have to implement the MAP algorithm to use it (hence the should = requirement for a=3D0). This makes it functionally identical to the PSID = originally described in draft-bajko-pripaddrassign. So lw4o6 does not = require you to implement the MAP algorithm, but it doesn=E2=80=99t = prevent you from using MAP to implement it (which was the reason for the = agreement on using the MAP PSID DHCP format). > I'm actually fine with the current lw46 text in section 5.1, but your = response seems to conflict with that. I'll start another thread on this = topic. >=20 > =20 > - The assigned IPv4 address and port-set form part of the IPv6 address = of a lwB4, and are included in the interface-identifier in the same = place and format as MAP (Section 5.1) > [ian] This is noted and already referenced in the lw4o6 draft. > - The lw46 CPE should be provisioned using the MAP DHCP (also Section = 5.1). > [ian] The draft which is called map-dhcp has been re-written = extensively with input from people across the WG to be a DHCP option for = provisioning map & lw4o6. It is now map-dhcp by filename alone and once = it progresses, won=E2=80=99t even be called that anymore. How does this = make lw4o6 a =E2=80=98specialisation' of MAP? > As it=E2=80=99s potentially a significant change that you are = requesting here, I=E2=80=99d appreciate the opinions of other members of = the WG on this. [Qi] I think the current lw4o6 draft is good to read and it reflects the = outcome of the last Vancouver meeting. > =20 >>=20 >> Detailed comments: >>=20 >> * Section 5.1 WAN prefix selection and address forming - as per Ole's = comment. This is indeed hand wavy in the current draft (how to select = the WAN?) >>=20 >>=20 >> [ian] I=E2=80=99ve updated with the wording that I proposed to Ole. >>=20 >> The CPE WAN interface is a fairly well used term in a number of other = RFCs. Both RFC6333 and RFC7084 use the term (and have implementations = based on them) without defining how the CPE has identified it. Why does = that need to be specifically defined here? >>=20 >>=20 >> Woj> What is the WAN interface is, and how should the CPE "find it" = not said. That other drafts fail to clarify that doesn't make it quite = right=E2=80=A6 >=20 > [ian] This is entirely implementation specific and something that = hasn=E2=80=99t stopped millions of CPEs being built and deployed that = support both RFC6333 and RFC7084 (n=C3=A9 RFC6204). What=E2=80=99s the = problem that you are trying to solve? >=20 > Woj> None of those texts attempt to create a deterministic ip = interface, and in case of 6333 that is a known operational issue. So, in = terms of the lw46 draft specifying how a CPE is to get to the IP prefix = of "the WAN interface" is an important aspect, or at least stating the = assumptions about this WAN interface. Some obvious questions apply here: > is the WAN the interface which has the default route? Is it the = interface that has a DHCPv6 client? What if there are multiple such = "WAN" interfaces? What if a single "WAN" has multiple IPv6 prefixes? = What if it has NO global IPv6 prefix? What if it doesn't have a /64 = prefix. etc. >=20 > Coincidentally, all of the latter are options allowed for by RFC7084. > =20 >=20 >> * Processing of IPv4 fragments Section 5.2. Text " The lwB4 MAY = require that the UDP, TCP, or ICMP header be completely contained within = the fragment that contains fragment offset equal to zero." >>=20 >> What does that mean? Is it trying to say that the IPv4 MTU > 40? >>=20 >> =20 >>=20 >> [ian] The text is taken directly from RFC6146. I guess that doesn=E2=80= =99t specify is as a defined MTU size of > 40 bytes (or anything else) = as the IPv4 header could feasibly be longer than 20 bytes if options = were included in it, so the fragmented L4 header problem could still = exist. >>=20 >>=20 >> Here we're talking about tunneling, and I cannot see a case whereby = the IPv4 TCP/UDP header would get fragmented, unless the MTU of the IPv6 = tunnel was <40. rfc6146 is about translation where other effects come to = apply. >=20 > [ian] No, this is related to fragmentation in respect to the RFC1858 = 'Tiny Fragment attack' which affects the IPv4 payload. The same = problems exist for the lwB4s NAT44 function as exist for a NAT64 in this = respect, which is why it was included. >=20 > Woj> Ok, but what does "MAY require" mean, and how should a device go = about requiring it?=20 [Qi] Please see page 18 of RFC6146: * The NAT64 MAY require that the UDP, TCP, or ICMP header be completely contained within the fragment that contains fragment offset equal to zero. >> =20 >>=20 >> Section 5.2: " >>=20 >> For incoming packets carrying TCP or UDP IPv4 fragments with a non- >> zero checksum, after de-capsulation, the lwB4 MAY elect to queue = the >> fragments as they arrive and perform NAPT44 on all fragments at = the >> same time" >> ?? Queue based on what? Presumably the fragment identifier field, and = if so then that is no different to 2473. >> =20 >> [ian] Updated the text to note that. >>=20 >>=20 >> Ok, but in essence, it would be actually better removing the text = since it adds nothing above 2473.=20 >=20 > [ian] The text in the current version reads: >=20 > For incoming packets carrying TCP or UDP IPv4 fragments with a non- > zero checksum, after de-capsulation, the lwB4 MAY elect to queue = the > fragments as they arrive and perform NAPT44 on all fragments at the > same time. In this case, the incoming 5-tuple is determined by > extracting the appropriate fields from the received packet, as > described in [RFC2473]. Alternatively, a lwB4 MAY translate the = de- > capsulated fragments as they arrive, by storing information that > allows it to compute the 5-tuple for fragments other than the = first. > In the context of the above, is this a problem? >=20 > Woj> Well, what strikes me is that the above text does not bring in = anything other than what's already in 2473 for IPinIP fragementation and = [RFC5508], and [RFC5382] for NAT. The text should refer to those = documents, or file errata. In other words, IPv4inIPv6 fragments and = handling of IPv4 fragments with NAT44 is not a lwB4 specific function, = and is already well documented. >=20 >=20 > =20 >=20 >> =20 >> * Section 5.2: Text: >>=20 >> For incoming de-capsulated IPv4 packets carrying UDP packets with a >> zero checksum, if the lwB4 has enough resources, the lwB4 MUST >> reassemble the packets and MUST calculate the checksum. If the = lwB4 >> does not have enough resources, then it MUST silently discard the >> packets. =20 >> Wouldn't it be easier to say that the lwb4 MAY reassemble the packet = and recalculate the checksum? It's clearly not a MUST... >>=20 >> =20 >>=20 >> [ian] Why is it not a MUST? If one condition is met you MUST do this, = if a different condition is met, you MUST do that. A MAY would make = re-assembly of the packets optional, meaning that an implementation = could not implement support for fragment reassembly at all and still say = that it is compliant with the spec. >>=20 >>=20 >> If it were a MUST then something would horribly break if it were not = done. The above clearly says that this reassembly operation is at the = discretion of the device, subject to an arbitrary "enough resources" = condition. If you'd like it to be a MUST then the condition should be = removed. >=20 > [ian] Then surely re-assembly is a SHOULD requirement, with a a MUST = to discard if cannot be re-assembled. As I said, if it was a MAY = requirement, then implementation would be completely optional.=20 >=20 > Woj> Yes, and that's what the above text reads from a test = perspective, i.e. since one has no way of determining whether there are = "enough resources", a lwB4 that discards all such packets would comply. = As I said, if one would like to tighten the spec; a) the un-testable = "enough resources" condition should be removed b) with that either a = MUST used, if this is something super important, or a SHOULD (as it = seems to me). Alternatively a MAY as "nice to have" may also do. [Qi] I prefer to use a SHOULD for re-asembly and a MUST for discarding = the packet if it cannot be reassembled. Thanks, Qi >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires --Apple-Mail-64-203195463 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi = Woj,
On 2014-2-19, at =E4=B8=8B=E5=8D=884:34, Wojciech Dec = wrote:

Just to be clear: I'm ok with lw46 defining = a specific functional=20 mode as I believe it does in this draft, =

[Qi] The outcome of ietf88 = was lw4o6 and map are two mechanisms, but both use the Softwire DHCP for = provisioning (at least according to my memory). That is why the WG = decided to remove the statement of "lw4o6 is a subset of MAP-E" is from = the Softwire DHCP Option draft.

And lw4o6 can = use DHCPv4 over DHCPv6 and PCP for provisioning. This is documented in = the current lw4o6 draft, and some teams are doing the documentation = work. (We have demoed in IETF85 that lw4o6 can work with DHCPv4 over = IPv6 and PCP). The point is, lw4o6 architecture is quite = flexible. 

also leaving "as-is" the DHCP part of=20 it (i.e. it's a capability that can be signalled using the lw46 = container, etc).

General items = remain open (as commented):
- Cleanup text that does not belong to = lw46 (eg 2473 fixes, or NAT44 best practice). =

[Qi] IMO, that text = guarantees the interoperation between lwAFTRs and lwB4s from different = vendors, which bothered us a little when carrying out the interop test. = I think it doesn't hurt to make it specific.

- Clarification of WAN selection or = assumptions

[Qi] I think = Ian has expressed cleared in previous mails.


That said, = abundant technical evidence (summarized in previous mail) indicates that = this mode is in near total overlap with MAP 1:1, certainly much more = than at the outset of this work. Given this, why not align the text and = actually make MAP 1:1 and lw46 be the same? On all of the data plane = IPv6, IPv4, NAT44, tunneling and ICMP handling parts I see there no = reason for there being a = difference...

[Qi] I = think lw4o6 is clean and simple, and flexible to work with different = provisioning mechanisms (signaling through the Softwire DHCP as is = agreed by the WG). 



continued inline...


On 17 February 2014 17:15, Ian Farrer = <ianfarrer@gmx.com> wrote:
Hi = Woj,

Please see inline.
=

Cheers,
Ian

<= div>On 16 Feb 2014, at 17:32, Wojciech Dec <wdec.ietf@gmail.com> wrote:

Hi Ian,

you haven't replied = on my high level comment - would appreciate if you introduced changes to = that effect in the draft.

Continued inline=E2=80=A6

[ian] The draft already contains the = following text (and has for some time):
   Lightweight 4over6 provides a solution =
for a hub-and-spoke softwire
   architecture only.  It does not offer direct, meshed IPv4
   connectivity between subscribers without packets traversing the AFTR.
   If this type of meshed interconnectivity is required,
   [I-D.ietf-softwire-map] provides a suitable solution.
So, are you not happy = with the wording of the current reference, or are you requesting = that the draft is rewritten to be cast as a =E2=80=98specialised' = case of MAP?
What I pointed out = is that the Lw46 draft has major if near total overlap with MAP-E 1:1 mode. Stating that lw46 realizes this mode, in a standalone = way from the N:1 mesh mode, is what I propose. This would greatly help = in implementing it and "digesting" the array of solutions. =

[Qi] = I don't see any "help" here...

Additional comment Now that you mention it, the stated = characterisation of map isn't quite right; MAP does not force the use of = mesh mode, nor is mesh mode its defining characteristic. =

[Qi] =46rom= my reading, the text doesn't characterize what MAP is. It just says "if = you want to use meshed IPv4 connectivity, then use MAP". It doesn't = prevent you from using MAP to do anything else. So I think the text is = OK.

The characterisation should be restated as " lw46 does not seek to offer=20 the optimization of AFTR subscriber state and the AFTR is expected to = have configuration state for each lwB4 node. If optimization of this = state is required, [id-ietf-softwire-map] provides a suitable solution = ".
Alternatively, state that "lw46 describes a deployment/implementation of = MAP = 1:1"

[Qi= ] In my opinion, the current wording is clear and = enough. 

 
Either way, I don=E2=80=99t really agree = with your justification points for a change:
- The PSID and the port = range are algorithmically derived & related as per the MAP algorithm = (covered in Section 5.1)
 [ian] The PSID usage in lw4o6 is written so that you = don=E2=80=99t have to implement the MAP algorithm to use it (hence the = should requirement for a=3D0). This makes it functionally identical to = the PSID originally described in draft-bajko-pripaddrassign. So lw4o6 = does not require you to implement the MAP algorithm, but it doesn=E2=80=99= t prevent you from using MAP to implement it (which was the reason for = the agreement on using the MAP PSID DHCP format).
I'm actually fine with the = current lw46 text in section 5.1, but your response seems to conflict = with that. I'll start another thread on this = topic.

 
- The assigned IPv4 = address and port-set form part of the IPv6 address of a lwB4, and are = included in the interface-identifier in the same place and format as MAP = (Section 5.1)
[ian] This is noted and = already referenced in the lw4o6 draft.
- The lw46 CPE = should be provisioned using the MAP DHCP (also Section = 5.1).
[ian] The draft which is = called map-dhcp has been re-written extensively with input from people = across the WG to be a DHCP option for provisioning map & lw4o6. It = is now map-dhcp by filename alone and once it progresses, won=E2=80=99t = even be called that anymore. How does this make lw4o6 = a =E2=80=98specialisation' of MAP?
As it=E2=80=99s = potentially a significant change that you are requesting here, I=E2=80=99d= appreciate the opinions of other members of the WG on = this.
<= /blockquote>

[Qi] I think the current lw4o6 draft is = good to read and it reflects the outcome of the last Vancouver = meeting.

 

Detailed = comments:

* Section 5.1 WAN prefix selection and address forming = - as per Ole's comment. This is indeed hand wavy in the = current draft (how to select the WAN?)

<= p class=3D"MsoNormal">[ian] I=E2=80=99ve updated with the wording that I = proposed to Ole.

The CPE WAN interface is a fairly well used term in a = number of other RFCs. Both RFC6333 and RFC7084 use the term (and have = implementations based on them) without defining how the CPE has = identified it. Why does that need to be specifically defined = here?


Woj>  What is = the WAN interface is, and how should the CPE "find it" not said. That = other drafts fail to clarify that doesn't make it quite right=E2=80=A6

[ian] This is entirely implementation specific and something that = hasn=E2=80=99t stopped millions of CPEs being built and deployed = that support both RFC6333 and RFC7084 (n=C3=A9 RFC6204). What=E2=80=99s = the problem that you are trying to solve?

Woj> None of those = texts attempt to create a deterministic ip interface, and in case of = 6333 that is a known operational issue. So, in terms of the lw46 draft = specifying how a CPE is to get to the IP prefix of  "the WAN = interface" is an important aspect, or at least stating the assumptions = about this WAN interface. Some obvious questions apply here:
is the WAN the interface which has the default route? Is it the = interface that has a DHCPv6 client? What if there are multiple such = "WAN" interfaces? What if a single "WAN" has multiple IPv6 prefixes? = What if it has NO global IPv6 prefix? What if it doesn't have a /64 = prefix. etc.

Coincidentally, all of the latter are options allowed for by = RFC7084.
 

* Processing = of IPv4 fragments Section 5.2. Text " The lwB4 = MAY require that the UDP, TCP, or ICMP header be completely contained = within the fragment that contains fragment offset equal to = zero."

What does that mean? Is it = trying to say that the IPv4 MTU > 40?

 

[ian] The text is taken directly from RFC6146. I guess = that doesn=E2=80=99t specify is as a defined MTU size of > 40 bytes = (or anything else) as the IPv4 header could feasibly be longer than 20 = bytes if options were included in it, so the fragmented L4 header = problem could still exist.


Here we're talking about = tunneling, and I cannot see a case whereby the IPv4 TCP/UDP header would = get fragmented, unless the MTU of the IPv6 tunnel was <40. rfc6146 is = about translation where other effects come to apply.

[ian] No, this is related to fragmentation in respect to the RFC1858 = 'Tiny Fragment attack' which affects  the IPv4 payload. The same = problems exist for the lwB4s NAT44 function as exist for a NAT64 in this = respect, which is why it was included.

Woj> Ok, but what = does "MAY require" mean, and how should a device go about requiring it? =

[Qi] Please = see page 18 of RFC6146:

    =   *  The NAT64 MAY require that the UDP, TCP, or ICMP header = be
         completely contained = within the fragment that contains fragment
    =      offset equal to zero.

 

Section 5.2: "

For =
incoming packets carrying TCP or UDP IPv4 fragments with a =
non-
   zero checksum, after =
de-capsulation, the lwB4 MAY elect to queue the
   fragments as they arrive and perform NAPT44 on all =
fragments at the
   same =
time"
?? Queue based on what? Presumably the =
fragment identifier field, and if so then that is no different to =
2473.
 

[ian] Updated the text to note that.


Ok, but in essence, it = would be actually better removing the text since it adds nothing above = 2473. 

[ian] The text in the current version reads:

For incoming packets carrying TCP or UDP =
IPv4 fragments with a non-
   zero checksum, after de-capsulation, the lwB4 MAY elect to queue the
   fragments as they arrive and perform NAPT44 on all fragments at the
   same time.  In this case, the incoming 5-tuple is determined by
   extracting the appropriate fields from the received packet, as
   described in [RFC2473].  Alternatively, a lwB4 MAY translate the de-
   capsulated fragments as they arrive, by storing information that
   allows it to compute the 5-tuple for fragments other than the =
first.
In the context of the above, is this a = problem?

Woj> Well, what strikes me is that the above text does not bring = in anything other than what's already in 2473 for IPinIP fragementation = and  [RFC5508], and  [RFC5382] for NAT. The text should refer = to those documents, or file errata. In other words, IPv4inIPv6 fragments = and handling of IPv4 fragments with NAT44 is not a lwB4 specific = function, and is already well documented.


 

 

* Section 5.2: Text:

For =
incoming de-capsulated IPv4 packets carrying UDP packets with =
a
   zero checksum, if the lwB4 has =
enough resources, the lwB4 MUST
   reassemble the packets and MUST calculate the =
checksum.  If the lwB4
   does =
not have enough resources, then it MUST silently discard =
the
   packets.  =

Wouldn't it be easier to say = that the lwb4 MAY reassemble the packet and recalculate the checksum? = It's clearly not a MUST...

 

[ian] Why is it not a MUST? If one condition is met you = MUST do this, if a different condition is met, you MUST do that. A MAY = would make re-assembly of the packets optional, meaning that an = implementation could not implement support for fragment reassembly at = all and still say that it is compliant with the spec.


If it were a = MUST then something would horribly break if it were not done. The above = clearly says that this reassembly operation is at the discretion of the = device,  subject to an arbitrary "enough resources" condition. If = you'd like it to be a MUST then the condition should be removed.
=

[ian]= Then surely re-assembly is a SHOULD requirement, with a a MUST to = discard if cannot be re-assembled. As I said, if it was a MAY = requirement, then implementation would be completely optional. 

Woj> Yes, and = that's what the above text reads from a test perspective, i.e. since one = has no way of determining whether there are "enough resources", a lwB4 = that discards all such packets would comply. As I said, if one would = like to tighten the spec; a) the un-testable "enough resources" = condition should be removed b) with that either a MUST used, if this is = something super important, or a SHOULD (as it seems to me). = Alternatively a MAY as "nice to have" may also = do.

[Qi] I = prefer to use a SHOULD for re-asembly and a MUST for discarding the = packet if it cannot be = reassembled.

Thanks,
Qi


_______________________________________________
Softwires mailing = list
Softwires@ietf.org
https://www.ietf.= org/mailman/listinfo/softwires

= --Apple-Mail-64-203195463-- From nobody Fri Feb 21 04:15:39 2014 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AEFD1A00B9 for ; Fri, 21 Feb 2014 04:15:38 -0800 (PST) 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 dl8J6UVBhXlX for ; Fri, 21 Feb 2014 04:15:35 -0800 (PST) Received: from mail-ve0-x229.google.com (mail-ve0-x229.google.com [IPv6:2607:f8b0:400c:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id BB0FA1A0532 for ; Fri, 21 Feb 2014 04:15:35 -0800 (PST) Received: by mail-ve0-f169.google.com with SMTP id oy12so3203396veb.0 for ; Fri, 21 Feb 2014 04:15:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Cx5pnqM1m4GPn4BYMWlzGOD9vnygALjGrfB/Wol1XRI=; b=CgPFVJPwrQyUHipNsEql9BsByGq2nGz4v+CawUeI63EUDmjV36fP1OI8cNUAyU1STn jfpdZtv7lHBn88fZqPM0CWXpqenESofIlEEpdy1PQZ2wBz+94GPGoaPR8FVS29+KEIWa WMBtuuhkGCgXvCmatSKno2TPGEW9jNTIwjGtmfq/YLCkwKiJQrP20CnRqOqC/ZyDuoKv AgT4fdrKaJvt7d5FlEssTdIGWHzAYx6HLtQLTiuJ2iqt4kA3qEYtAeJdG2CgBVKoojv0 nPig5z3vuPXGIPQVqLRvX5SV8QIcjF7NudoKxeaWOtrEQ9x+j+ylThwHfaGT6XK6gWdH Mjrw== MIME-Version: 1.0 X-Received: by 10.52.28.137 with SMTP id b9mr3854664vdh.44.1392984931658; Fri, 21 Feb 2014 04:15:31 -0800 (PST) Received: by 10.221.24.146 with HTTP; Fri, 21 Feb 2014 04:15:31 -0800 (PST) In-Reply-To: <52FDAF01.6080308@ericsson.com> References: <52FDAF01.6080308@ericsson.com> Date: Fri, 21 Feb 2014 20:15:31 +0800 Message-ID: From: Liu Dapeng To: Suresh Krishnan Content-Type: multipart/alternative; boundary=20cf307d036e07733304f2e99410 Archived-At: http://mailarchive.ietf.org/arch/msg/softwires/A_1Ixj9NJBi2CpQVKYocOqWBMVA Cc: Softwires WG , Yong Cui Subject: Re: [Softwires] Working group last call for draft-ietf-softwire-4rd-07 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 12:15:38 -0000 --20cf307d036e07733304f2e99410 Content-Type: text/plain; charset=ISO-8859-1 Support. The draft is ready to move forward. Cheers, Dapeng Liu 2014-02-14 13:52 GMT+08:00 Suresh Krishnan : > Hi all, > This message starts a two week softwire working group last call on > advancing the draft about IPv4 Residual Deployment via IPv6 - a Stateless > Solution (4rd) as an Experimental RFC. The authors believe that this > version has addressed all the issues raised on the document till date. The > latest version of the draft is available at > > http://www.ietf.org/id/draft-ietf-softwire-4rd-07.txt > http://tools.ietf.org/html/draft-ietf-softwire-4rd-07 > > Substantive comments and statements of support/opposition for advancing > this document should be directed to the mailing list. Editorial suggestions > can be sent directly to the authors. This last call will conclude on > February 28, 2014 > > Regards, > Suresh & Yong > > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > -- ------ Best Regards, Dapeng Liu --20cf307d036e07733304f2e99410 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Support. The draft is ready to move forward.

Cheers,
Dapeng Liu

2014-02-14 13:52 GMT+08:00 Suresh Krishnan= <suresh.krishnan@ericsson.com>:
Hi all,
=A0 This message starts a two week softwire working group last call on adva= ncing the draft about IPv4 Residual Deployment via IPv6 - a Stateless Solut= ion (4rd) as an Experimental RFC. The authors believe that this version has= addressed all the issues raised on the document till date. The latest vers= ion of the draft is available at

http://www.ietf.org/id/draft-ietf-softwire-4rd-07.txt http://tools.ietf.org/html/draft-ietf-softwire-4rd-07
Substantive comments and statements of support/opposition for advancing thi= s document should be directed to the mailing list. Editorial suggestions ca= n be sent directly to the authors. This last call will conclude on February= 28, 2014

Regards,
Suresh & Yong


_______________________________________________
Softwires mailing list
Softwires@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/softwires



--

------Best Regards,
Dapeng Liu
--20cf307d036e07733304f2e99410-- From nobody Sun Feb 23 17:25:57 2014 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F294F1A078C for ; Sun, 23 Feb 2014 17:25:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 EBsyHAOC80vo for ; Sun, 23 Feb 2014 17:25:54 -0800 (PST) Received: from mail-qc0-x22c.google.com (mail-qc0-x22c.google.com [IPv6:2607:f8b0:400d:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 8C9B91A0225 for ; Sun, 23 Feb 2014 17:25:54 -0800 (PST) Received: by mail-qc0-f172.google.com with SMTP id w7so6231212qcr.3 for ; Sun, 23 Feb 2014 17:25:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=605K6R7HvfuA6RXXWYhxpO/EKKm97vki389j3Pn0oh0=; b=dK05T1qkB39ovB0N34z7Ek3bko/XCtSR7yIH1EEaEFvALNTh0flXZBJ+a+ZYpeiUDh DRoSA1c7aPBeW4owCO5j4Pl7iiHXr9T/0Um9gTAVlA1LQbO9/3HQhnu3MCnvxVk/eIcj 2qEXXYD6hp5/9ECBszgfYaqgEuuneLsxmC6Ioqrk4N+V6L1paXM8FBulkWIZdb2/aqBI QyVcCeXCwSqj8OJquS+ffHmlc7VLWnMR5p6lXJfCu+YZcRLeDhE3QoX+b/JkMrtfrfqa NbR8d7b2PuOOg4ou4AWyEMJbNmtZmujhYfiNusUaG46uy5nnWKGg8Y5io/nvlhhqg5pO 8z9A== MIME-Version: 1.0 X-Received: by 10.229.172.4 with SMTP id j4mr26587180qcz.6.1393205154089; Sun, 23 Feb 2014 17:25:54 -0800 (PST) Received: by 10.96.58.106 with HTTP; Sun, 23 Feb 2014 17:25:54 -0800 (PST) In-Reply-To: <52FDAF01.6080308@ericsson.com> References: <52FDAF01.6080308@ericsson.com> Date: Mon, 24 Feb 2014 09:25:54 +0800 Message-ID: From: "Cao,Zhen" To: Suresh Krishnan Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/softwires/3ugzWFmcDR3LdXg6wrcYKwbN758 Cc: Softwires WG , Yong Cui Subject: Re: [Softwires] Working group last call for draft-ietf-softwire-4rd-07 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2014 01:25:56 -0000 Hi all, I believe 4rd is a defacto standard. I support its moving forward. best regards, zhen On Fri, Feb 14, 2014 at 1:52 PM, Suresh Krishnan wrote: > Hi all, > This message starts a two week softwire working group last call on > advancing the draft about IPv4 Residual Deployment via IPv6 - a Stateless > Solution (4rd) as an Experimental RFC. The authors believe that this version > has addressed all the issues raised on the document till date. The latest > version of the draft is available at > > http://www.ietf.org/id/draft-ietf-softwire-4rd-07.txt > http://tools.ietf.org/html/draft-ietf-softwire-4rd-07 > > Substantive comments and statements of support/opposition for advancing this > document should be directed to the mailing list. Editorial suggestions can > be sent directly to the authors. This last call will conclude on February > 28, 2014 > > Regards, > Suresh & Yong > > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From nobody Sun Feb 23 19:16:07 2014 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A011E1A026F for ; Sun, 23 Feb 2014 19:16:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 vEZTWMKQ__1k for ; Sun, 23 Feb 2014 19:16:03 -0800 (PST) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id A93E11A0269 for ; Sun, 23 Feb 2014 19:16:03 -0800 (PST) Received: by mail-pa0-f43.google.com with SMTP id rd3so5966997pab.30 for ; Sun, 23 Feb 2014 19:16:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=IqcHlZU7C84doZS3zbWLJWvWHL7SoPB3ZcC3UFcKRJI=; b=uevupDbwuhH3H82AHbHdonv61MeXldKGbMEUEaQ4gsAV+3fQBkfxUJtmKTI+SVus0W fkD5mnZWEHvHMKpNckVTOgzt/ovsE8lPY3FtQ+MdJVhTpePpCcNZ6GtZ0GimildTXwjS UtvCnXQG3tiILVLKS6nmwDEIABm8DMTjx/LRa+drfZfOE/YMdRcbgf0dG+gpokGadyHM v6diHcUyTULxf8eLBxgF/7Ys5mRDKV2/+GALmvK37ypPbWLW+Cx4o2iNq63uTyBW85rd QmL+AJyZAIzSVGmYsYEFzx+1DoBKm/RQKW0gkhbr9BR0ulQwwnfm9wTLzWxg2LNHNamz rHOA== X-Received: by 10.68.134.130 with SMTP id pk2mr10975266pbb.167.1393211763429; Sun, 23 Feb 2014 19:16:03 -0800 (PST) Received: from [192.168.11.136] ([166.111.131.15]) by mx.google.com with ESMTPSA id n6sm44833792pbj.22.2014.02.23.19.16.00 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 23 Feb 2014 19:16:02 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=utf-8 From: Qi Sun In-Reply-To: <52FDAF01.6080308@ericsson.com> Date: Mon, 24 Feb 2014 11:15:57 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <2301AE28-D721-4EF2-AD4A-0D414A0702A4@gmail.com> References: <52FDAF01.6080308@ericsson.com> To: Suresh Krishnan X-Mailer: Apple Mail (2.1085) Archived-At: http://mailarchive.ietf.org/arch/msg/softwires/Zs9D8gZms2iSg-pfrFa-awB6KKU Cc: Softwires WG , Yong Cui Subject: Re: [Softwires] Working group last call for draft-ietf-softwire-4rd-07 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2014 03:16:06 -0000 Dear Chairs, I support 4rd to move forward. Best Regards, Qi=20 On 2014-2-14, at =E4=B8=8B=E5=8D=881:52, Suresh Krishnan wrote: > Hi all, > This message starts a two week softwire working group last call on = advancing the draft about IPv4 Residual Deployment via IPv6 - a = Stateless Solution (4rd) as an Experimental RFC. The authors believe = that this version has addressed all the issues raised on the document = till date. The latest version of the draft is available at >=20 > http://www.ietf.org/id/draft-ietf-softwire-4rd-07.txt > http://tools.ietf.org/html/draft-ietf-softwire-4rd-07 >=20 > Substantive comments and statements of support/opposition for = advancing this document should be directed to the mailing list. = Editorial suggestions can be sent directly to the authors. This last = call will conclude on February 28, 2014 >=20 > Regards, > Suresh & Yong >=20 >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From nobody Sun Feb 23 19:18:20 2014 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC4181A027A for ; Sun, 23 Feb 2014 19:18:18 -0800 (PST) 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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 eQXCDczdXWJB for ; Sun, 23 Feb 2014 19:18:17 -0800 (PST) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id EC6641A026F for ; Sun, 23 Feb 2014 19:18:16 -0800 (PST) Received: by mail-pa0-f42.google.com with SMTP id kl14so5945399pab.29 for ; Sun, 23 Feb 2014 19:18:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ggmy9gOp8zdfQiigwg5KJkDaH9131ozfSj+0WAvxC4A=; b=MnwtCIVxzRFx/9whSOTxbdacfMxo9fRALpxYCHVwqk7Az0dcDrZuooZm2bhIDSZ6CZ dhC0VIZRPIZdK20HCKh6qNSCqSgTEBxIf8ciOOepEkdE3ipGICW7LGtVr4h4KrNIU8MI QqAipYCPKkwXYhbKvBYZowTJ4jdgxeZ0M1tZyiKknItDcrboaPyCV6gEg4EKNcNttiS/ fsZryAadLc2lhbtERHrK9OY+6L1p1m6KexhixYquHOlHIM00FH33BXddukKSJqq+Zlqg uNqStKuNJuTCGFCj2Ags+HEjhjDHSKHVSK1AK8HAsXdvXlkrWmsp+KEYxk26JR2Lx+rv a/Zg== X-Received: by 10.68.239.70 with SMTP id vq6mr21956840pbc.152.1393211896679; Sun, 23 Feb 2014 19:18:16 -0800 (PST) Received: from [192.168.11.136] ([166.111.131.15]) by mx.google.com with ESMTPSA id vf7sm44887348pbc.5.2014.02.23.19.18.13 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 23 Feb 2014 19:18:15 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=utf-8 From: Qi Sun In-Reply-To: <52FDAE7B.8090009@ericsson.com> Date: Mon, 24 Feb 2014 11:18:09 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <7BD9A23D-38F0-46C8-9F37-5C958D5E3FD0@gmail.com> References: <52FDAE7B.8090009@ericsson.com> To: Suresh Krishnan X-Mailer: Apple Mail (2.1085) Archived-At: http://mailarchive.ietf.org/arch/msg/softwires/fuZceawF1vE19CmImD35cgyDzXE Cc: Softwires WG , Yong Cui Subject: Re: [Softwires] Working group last call for draft-ietf-softwire-map-t-05 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2014 03:18:19 -0000 Support. Best Regards, Qi=20 On 2014-2-14, at =E4=B8=8B=E5=8D=881:49, Suresh Krishnan wrote: > Hi all, > This message starts a two week softwire working group last call on = advancing the draft about providing Mapping of Address and Port using = Translation as an Experimental RFC. The authors believe that this = version has addressed all the issues raised on the document till date. = The latest version of the draft is available at >=20 > http://www.ietf.org/id/draft-ietf-softwire-map-t-05.txt > http://tools.ietf.org/html/draft-ietf-softwire-map-t-05 >=20 > Substantive comments and statements of support/opposition for = advancing this document should be directed to the mailing list. = Editorial suggestions can be sent directly to the authors. This last = call will conclude on February 28, 2014 >=20 > Regards, > Suresh & Yong >=20 >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From nobody Tue Feb 25 02:12:41 2014 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 726781A0427 for ; Tue, 25 Feb 2014 02:12:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.301 X-Spam-Level: * X-Spam-Status: No, score=1.301 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, SPF_PASS=-0.001] autolearn=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 tkbvURKhRlWa for ; Tue, 25 Feb 2014 02:12:36 -0800 (PST) Received: from mail-pb0-x22f.google.com (mail-pb0-x22f.google.com [IPv6:2607:f8b0:400e:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 4362D1A068F for ; Tue, 25 Feb 2014 02:12:08 -0800 (PST) Received: by mail-pb0-f47.google.com with SMTP id up15so1386919pbc.20 for ; Tue, 25 Feb 2014 02:12:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=AtsGwrSKrsflHLg6jjKtEiPP1sjiC5CmBNYWHTNTMYI=; b=HYgG61nqTqB/kRAf0ZrWAKvLT3To9w9SLf+CEHPY8Y7O46dnQryN0XWhcVRCcS/YIl 4Bn9eJEmaepOPoO6N23pskqUvkeFEQ8cDDcqSA1XOoPL5bjNi2feWWMe7bHQfWZbkOCu QTCwYtu9sFPLbbPyEdn0yzlIPZdPbDj6JMPlK34KtYBWIqqkK+hzqFtalcB3a8WNlmKv WzaM8ZdcGdODOTBDNVjixkp0VzCv2L2Lb89KqpDkcMr/7ZJF4ZjfAGRxTcfB7oLc9avM BoABcPIhuJUDURbON7PbzTpxE0In67Pd3rkEiZwhCGZCVjQYDiqMzfEEsEeE4jJVCRng sMvw== MIME-Version: 1.0 X-Received: by 10.66.144.200 with SMTP id so8mr722318pab.15.1393323121286; Tue, 25 Feb 2014 02:12:01 -0800 (PST) Received: by 10.70.1.70 with HTTP; Tue, 25 Feb 2014 02:12:01 -0800 (PST) In-Reply-To: References: <20140211075445.17615.61208.idtracker@ietfa.amsl.com> <8A1B81989BCFAE44A22B2B86BF2B76318A2CDB8ED2@HE111643.EMEA1.CDS.T-INTERNAL.COM> Date: Tue, 25 Feb 2014 11:12:01 +0100 Message-ID: From: Wojciech Dec To: Qi Sun Content-Type: multipart/alternative; boundary=047d7b6d9284b3a5f704f338512a Archived-At: http://mailarchive.ietf.org/arch/msg/softwires/F75CrROdueABKG38EsdsLIdWVfA Cc: Softwires WG Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-lw4over6-06.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2014 10:12:39 -0000 --047d7b6d9284b3a5f704f338512a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Qi, your answers didn't answer the majority of the concerns raised. And some of those raised by Ole still also stand: - Clean-up text that does not belong to lw46 (eg 2473 fixes, NAT44 best practice). - Clarification of WAN selection or assumptions - Clarify questionable use of ICMPv6 error code (to report lack of v4 binding) - Text clarifying relation to MAP-E (both use MAP PSID algo, address embedding, IPv4inIPv6 and NAT44 w/ address sharing. MAP allows state to be ranged from N to 1 per CPE. lw46 focuses on the 1:1 case) I still see no reason why they cannot be addressed by edits to the draft that don't change the matter that lw46 is a standalone draft. Snipped text Inline... Woj> On 21 February 2014 10:25, Qi Sun wrote: > > Hi Woj, > > > On 2014-2-19, at =E4=B8=8B=E5=8D=884:34, Wojciech Dec wrote: > > > Just to be clear: I'm ok with lw46 defining a specific functional mode as > I believe it does in this draft, > > > [Qi] The outcome of ietf88 was lw4o6 and map are two mechanisms, but both > use the Softwire DHCP for provisioning (at least according to my memory). > That is why the WG decided to remove the statement of "lw4o6 is a subset = of > MAP-E" is from the Softwire DHCP Option draft. > > And lw4o6 can use DHCPv4 over DHCPv6 and PCP for provisioning. This is > documented in the current lw4o6 draft, and some teams are doing the > documentation work. (We have demoed in IETF85 that lw4o6 can work with > DHCPv4 over IPv6 and PCP). The point is, lw4o6 architecture is quite > flexible. > Woj>I didn't quite comment on the DHCP draft, nor on how flexible and clear *you think* the lw46 draft is, etc. I commented on the fact that that lw46 shares a lot with MAP-E and the fact that it is built on the same technology blocks as MAP-E, but realizes solely the 1:1 part should be clarified. Irrespective of this, there is overall no reason for having text in the lw46 draft that fixes 2473 or NAT44 best practices, etc. > also leaving "as-is" the DHCP part of it (i.e. it's a capability that can > be signalled using the lw46 container, etc). > > > General items remain open (as commented): > - Cleanup text that does not belong to lw46 (eg 2473 fixes, or NAT44 best > practice). > > > [Qi] IMO, that text guarantees the interoperation between lwAFTRs and > lwB4s from different vendors, which bothered us a little when carrying ou= t > the interop test. I think it doesn't hurt to make it specific. > Woj>A couple of points: Firstly: Given that the lwB4 CPE uses the MAP algorithm for the PSID and embeds the IPv4+PSID in its IPv6 address, the text is now in shape that a lwB4 would be interoperable with a MAP-E BR. This is actually good convergence/progress. What remains open in that happening is actually weeding out the possible source of differences, which appear to be in the nuances of ICMP handling. Secondly: It claims to be a standards track document (currently), and it carries text that selectively duplicates text in other standard rfcs without deferring to those RFCs. If there are any reasons why this "cherry picking" was made, while other recommendations (say re NAT44) were not adopted, they should be clarified. In general for rfc2473, there I see so far no zero reason to have some other text here, as opposed to errata. Same for NAT44 really. Then again, perhaps the draft should be interpreted as an RFP of some kind, which it actually reads a lot like. In which case it should not be a standard track document. > > - Clarification of WAN selection or assumptions > > > [Qi] I think Ian has expressed cleared in previous mails. > Woj>Please see my reply to Ian - looking forward to an answer in the draft: --snip-- So, in terms of the lw46 draft specifying how a CPE is to get to the IP prefix of "the WAN interface" is an important aspect, or at least stating the assumptions about this WAN interface. Some obvious questions apply here= : is the WAN the interface which has the default route? Is it the interface that has a DHCPv6 client? What if there are multiple such "WAN" interfaces? What if a single "WAN" has multiple IPv6 prefixes? What if it has NO global IPv6 prefix? What if it doesn't have a /64 prefix. etc. --snip-- One doesn't see the draft answering any of these at the moment. > > > That said, abundant technical evidence (summarized in previous mail) > indicates that this mode is in near total overlap with MAP 1:1, certainly > much more than at the outset of this work. Given this, why not align the > text and actually make MAP 1:1 and lw46 be the same? On all of the data > plane IPv6, IPv4, NAT44, tunneling and ICMP handling parts I see there no > reason for there being a difference... > > > [Qi] I think lw4o6 is clean and simple, and flexible to work with > different provisioning mechanisms (signaling through the Softwire DHCP as > is agreed by the WG). > > > > continued inline... > > > > >> [ian] The draft already contains the following text (and has for some >> time): >> >> Lightweight 4over6 provides a solution for a hub-and-spoke softwire >> architecture only. It does not offer direct, meshed IPv4 >> connectivity between subscribers without packets traversing the AFTR. >> If this type of meshed interconnectivity is required, >> [I-D.ietf-softwire-map] provides a suitable solution. >> >> So, are you not happy with the wording of the current reference, or are >> you requesting that the draft is rewritten to be cast as a =E2=80=98spec= ialised' >> case of MAP? >> > What I pointed out is that the Lw46 draft has major if near total overlap > with MAP-E 1:1 mode. Stating that lw46 realizes this mode, in a standalon= e > way from the N:1 mesh mode, is what I propose. This would greatly help in > implementing it and "digesting" the array of solutions. > > > [Qi] I don't see any "help" here... > Woj>To an operator and implementer, it would be very advantageous that all of IPv4 in IPv6 and NAT44 data plane aspects, as specified by Softwire drafts are the same, unless it is made clear as to why they should be different, and what does it bring. This applies especially to lw46 and MAP, since there is so much overlap between the solutions. > > Additional comment Now that you mention it, the stated characterisation o= f > map isn't quite right; MAP does not force the use of mesh mode, nor is me= sh > mode its defining characteristic. > > > [Qi] From my reading, the text doesn't characterize what MAP is. It just > says "if you want to use meshed IPv4 connectivity, then use MAP". It > doesn't prevent you from using MAP to do anything else. So I think the te= xt > is OK. > Woj> Well, that is "characterisation". From dictionary: "The act of describing the character or qualities of someone or something" And as stated, it is not quite correct, i.e. mesh-mode is not the defining feature of MAP. The state optimization (stateless) is, of which mesh mode is a by product (optional actually in the spec). The text needs to be changed. > > The characterisation should be restated as " lw46 does not seek to offer > the optimization of AFTR subscriber state and the AFTR is expected to hav= e > configuration state for each lwB4 node. If optimization of this state is > required, [id-ietf-softwire-map] provides a suitable solution ". > Alternatively, state that "lw46 describes a deployment/implementation of > MAP 1:1" > > > >> >>> Detailed comments: >>> >>> * Section 5.1 WAN prefix selection and address forming - as per Ole's >>> comment. This is indeed hand wavy in the current draft (how to select >>> the WAN?) >>> >>> [ian] I=E2=80=99ve updated with the wording that I proposed to Ole. >>> >>> The CPE WAN interface is a fairly well used term in a number of other >>> RFCs. Both RFC6333 and RFC7084 use the term (and have implementations b= ased >>> on them) without defining how the CPE has identified it. Why does that = need >>> to be specifically defined here? >>> >> >> Woj> What is the WAN interface is, and how should the CPE "find it" not >> said. That other drafts fail to clarify that doesn't make it quite right= =E2=80=A6 >> >> >> >> [ian] No, this is related to fragmentation in respect to the RFC1858 >> 'Tiny Fragment attack' which affects the IPv4 payload. The same problem= s >> exist for the lwB4s NAT44 function as exist for a NAT64 in this respect, >> which is why it was included. >> > > Woj> Ok, but what does "MAY require" mean, and how should a device go > about requiring it? > > > [Qi] Please see page 18 of RFC6146: > > * The NAT64 MAY require that the UDP, TCP, or ICMP header be > completely contained within the fragment that contains fragment > offset equal to zero. > Woj> Well, that text as you point comes from NAT64, and concerns IPv6 header chain to IPv4 header "fitting". In lwB4, unless I misunderstand, the only fragmentation there may be is that of IPv4 that would be driven by an IPv4 MTU < 40 (violation of IPv4 min MTU 68). So what exactly the draft is requiring here isn't clear. In any case the fragmentation behaviour is not something specific to lw46, so it would be best if you pointed the draft at the source. > > >>> >>> * Section 5.2: Text: >>> >>> For incoming de-capsulated IPv4 packets carrying UDP packets with a >>> >>> zero checksum, if the lwB4 has enough resources, the lwB4 MUST >>> >>> reassemble the packets and MUST calculate the checksum. If the lwB4 >>> >>> does not have enough resources, then it MUST silently discard the >>> >>> packets. >>> >>> Wouldn't it be easier to say that the lwb4 MAY reassemble the packet an= d >>> recalculate the checksum? It's clearly not a MUST... >>> >>> >>> >>> [ian] Why is it not a MUST? If one condition is met you MUST do this, i= f >>> a different condition is met, you MUST do that. A MAY would make >>> re-assembly of the packets optional, meaning that an implementation cou= ld >>> not implement support for fragment reassembly at all and still say that= it >>> is compliant with the spec. >>> >> >> If it were a MUST then something would horribly break if it were not >> done. The above clearly says that this reassembly operation is at the >> discretion of the device, subject to an arbitrary "enough resources" >> condition. If you'd like it to be a MUST then the condition should be >> removed. >> >> >> [ian] Then surely re-assembly is a SHOULD requirement, with a a MUST to >> discard if cannot be re-assembled. As I said, if it was a MAY requiremen= t, >> then implementation would be completely optional. >> > > Woj> Yes, and that's what the above text reads from a test perspective, > i.e. since one has no way of determining whether there are "enough > resources", a lwB4 that discards all such packets would comply. As I said= , > if one would like to tighten the spec; a) the un-testable "enough > resources" condition should be removed b) with that either a MUST used, i= f > this is something super important, or a SHOULD (as it seems to me). > Alternatively a MAY as "nice to have" may also do. > > > [Qi] I prefer to use a SHOULD for re-asembly and a MUST for discarding th= e > packet if it cannot be reassembled. > Woj> Well, so it's a SHOULD then. Please note: the "enough resources" condition as is, is un-testable across implementations, so adding such "dead" text is rather pointless. Cheers, Wojciech. --047d7b6d9284b3a5f704f338512a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Qi,

your answers didn't answ= er the majority of the concerns raised. And some of those raised by Ole sti= ll also stand:
- Clean-up text that does not belong to lw46 (eg 2473 fix= es, NAT44 best practice).
- Clarification of WAN selection or assumptions
- Clarify que= stionable use of ICMPv6 error code (to report lack of v4 binding)
=
- Text clarifying relation to MAP-E (both use MAP PSID algo, address e= mbedding, IPv4inIPv6 and NAT44 w/ address sharing. MAP allows state to be r= anged from N to 1 per CPE. lw46 focuses on the 1:1 case)

I still see no reason why they cannot be addressed by edits to the draft=20 that don't change the matter that lw46 is a standalone draft.


Snipped text Inline... Woj>


On 21 February 2014 10:25, Qi= Sun <sunqi.csnet.thu@gmail.com> wrote:

Hi Woj,

On 2014-2-19, at =E4=B8=8B=E5=8D=884:34, Wojc= iech Dec wrote:

Just to be clear: I'= ;m ok with lw46 defining a specific functional=20 mode as I believe it does in this draft,

=
[Qi] The outcome of ietf88 was lw4o6 and map are two mecha= nisms, but both use the Softwire DHCP for provisioning (at least according = to my memory). That is why the WG decided to remove the statement of "= lw4o6 is a subset of MAP-E" is from the Softwire DHCP Option draft.

And lw4o6 can use DHCPv4 over DHCPv6 and PCP for provis= ioning. This is documented in the current lw4o6 draft, and some teams are d= oing the documentation work. (We have demoed in IETF85 that lw4o6 can work = with DHCPv4 over IPv6 and PCP). The point is, lw4o6 architecture is quite f= lexible.=C2=A0


Woj>I didn't quite = comment on the DHCP draft, nor on how flexible and clear *you think* the lw= 46 draft is, etc. I commented on the fact that that lw46 shares a lot with = MAP-E and the fact that it is built on the same technology blocks as MAP-E,= but realizes solely the 1:1 part should be clarified.

Irrespective of this, there is overall no reason for having text in the= lw46 draft that fixes 2473 or NAT44 best practices, etc.

also leaving "= as-is" the DHCP part of=20 it (i.e. it's a capability that can be signalled using the lw46 contain= er, etc).

General items remain open (as comment= ed):
- Cleanup text that does not belong to lw46 (eg 2473 fixes, or NAT44 best p= ractice).

[Qi] IMO, = that text guarantees the interoperation between lwAFTRs and lwB4s from diff= erent vendors, which bothered us a little when carrying out the interop tes= t. I think it doesn't hurt to make it specific.

Woj>A couple of points:=C2= =A0 Firstly: Given that the lwB4 CPE uses the MAP algorithm for the PSID an= d embeds the IPv4+PSID in its IPv6 address, the text is now in shape that a= lwB4 would be interoperable with a MAP-E BR. This is actually good converg= ence/progress. What remains open in that happening is actually weeding out = the possible source of differences, which appear to be in the nuances of IC= MP handling.

Secondly: It claims to be a standards track document (c= urrently), and it carries text=20 that selectively duplicates text in other standard rfcs without=20 deferring to those RFCs. If there are any reasons why this "cherry=20 picking" was made, while other recommendations (say re NAT44) were not= adopted, they=20 should be clarified. In general for rfc2473, there I see so far no zero=20 reason to have some other text here, as opposed to errata. Same for NAT44 r= eally.

Then again, perhaps the draft should be interpreted as an RFP of some kind, which it actually reads a lot like. In which case=20 it should not be a standard track document.

- Clarification of WAN selection or assumptions

[Qi] I think Ian has expressed cleared in previo= us mails.


Woj>Please see= my reply to Ian - looking forward to an answer in the draft:
--snip--
So, in terms of the lw4= 6 draft specifying how a CPE is to get to the IP=20 prefix of=C2=A0 "the WAN interface" is an important aspect, or at= least=20 stating the assumptions about this WAN interface. Some obvious questions apply here:
is the WAN the interface which has the default route? Is it the=20 interface that has a DHCPv6 client? What if there are multiple such=20 "WAN" interfaces? What if a single "WAN" has multiple I= Pv6 prefixes?=20 What if it has NO global IPv6 prefix? What if it doesn't have a /64=20 prefix. etc.
--snip--
One doesn't see the= draft answering any of these at the moment.


That said, abun= dant technical evidence (summarized in previous mail) indicates that this m= ode is in near total overlap with MAP 1:1, certainly much more than at the = outset of this work. Given this, why not align the text and actually make M= AP 1:1 and lw46 be the same? On all of the data plane IPv6, IPv4, NAT44, tu= nneling and ICMP handling parts I see there no reason for there being a dif= ference...

[Qi] I think lw4o6 is cl= ean and simple, and flexible to work with different provisioning mechanisms= (signaling through the Softwire DHCP as is agreed by the WG).=C2=A0
<= div class=3D"">



continued inline...




=
[i= an] The draft already contains the following text (and has for some time):<= /font>
   Lightweight 4over6 provides a solutio=
n for a hub-and-spoke softwire
   architecture only.  It does not offer direct, meshed IPv4
   connectivity between subscribers without packets traversing the AFTR.
   If this type of meshed interconnectivity is required,
   [I-D.ietf-softwire-map] provides a suitable solution.
So, are you not happy with the= wording of the current reference, or are you=C2=A0requesting that the draf= t is rewritten to be cast as a=C2=A0=E2=80=98specialised' case of MAP?<= /font>
What I pointed out is = that the Lw46 draft has major if near total overlap with MAP-E 1:1 mode. Stating that lw46 realizes this mode, in a standalone way = from the N:1 mesh mode, is what I propose. This would greatly help in imple= menting it and "digesting" the array of solutions.

[Qi] I don&#= 39;t see any "help" here...
Woj>To an operator and implementer, it would be very advantageous that= all=20 of IPv4 in IPv6 and NAT44 data plane aspects, as specified by Softwire=20 drafts are the same, unless it is made clear as to why they should be=20 different, and what does it bring. This applies especially to lw46 and MAP,= since there is so much overlap between the solutions.
<= br>
Additional comment Now that you mention it, the stated character= isation of map isn't quite right; MAP does not force the use of mesh mo= de, nor is mesh mode its defining characteristic.

[Qi] From my reading, the text= doesn't characterize what MAP is. It just says "if you want to us= e meshed IPv4 connectivity, then use MAP". It doesn't prevent you = from using MAP to do anything else. So I think the text is OK.

Woj> Well, that is "characterisat= ion". From dictionary: "The act of describing the character or qu= alities of someone or something"
And as stated, it is not quite=20 correct, i.e. mesh-mode is not the defining feature of MAP. The state optim= ization (stateless) is, of which mesh mode is a by product (optional actual= ly in the spec). The text needs to be changed.

The characterisation should be restated as " lw46 does not seek to offer= =20 the optimization of AFTR subscriber state and the AFTR is expected to have = configuration state for each lwB4 node. If optimization of this state is re= quired, [id-ietf-softwire-map] provides a suitable solution ".
Alternatively, state that "lw46 describes a deployment/implementation = of MAP 1:1"
=C2=A0

Detailed comments= :

* Section 5.1 WAN prefix selection and address forming - as per Ol= e's comment.=C2=A0This is indeed hand wavy in the current draft = (how to select the WAN?)

[ian] I=E2=80=99ve updated with the wording that I pro= posed to Ole.

The CPE WAN interface is a fairly well used term= in a number of other RFCs. Both RFC6333 and RFC7084 use the term (and have= implementations based on them) without defining how the CPE has identified= it. Why does that need to be specifically defined here?


Woj>=C2=A0 What is the= WAN interface is, and how should the CPE "find it" not said. Tha= t other drafts fail to clarify that doesn't make it quite right=E2=80= =A6


[ian] No, this is re= lated to fragmentation in respect to the RFC1858 'Tiny Fragment attack&= #39; which affects =C2=A0the IPv4 payload. The same problems exist for the = lwB4s NAT44 function as exist for a NAT64 in this respect, which is why it = was included.

Woj> Ok, but what doe= s "MAY require" mean, and how should a device go about requiring = it?

[Qi] Please see page 18 of RFC614= 6:

=C2=A0 =C2=A0 =C2=A0 * =C2=A0The NAT64 MAY= require that the UDP, TCP, or ICMP header be
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0completely contained within the fragment tha= t contains fragment
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0offset equal to zero.

Woj> Well, that text as you po= int comes from NAT64, and concerns IPv6=20 header chain to IPv4 header "fitting". In lwB4, unless I misunder= stand,=20 the only fragmentation there may be is that of IPv4 that would be driven by an IPv4 MTU < 40 (violation of IPv4 min MTU 68). So what exactly=20 the draft is requiring here isn't clear.
In any case the fragmentation behaviour is not something=20 specific to lw46, so it would be best if you pointed the draft at the=20 source. 

=C2=
=A0

* Section 5.2: Text:

For incoming de-ca=
psulated IPv4 packets carrying UDP packets with a
=C2=A0=C2=A0 ze=
ro checksum, if the lwB4 has enough resources, the lwB4 MUST
=C2=A0=C2=A0 reassemble the packets and MUST calculate the checksum.=
=C2=A0 If the lwB4
=C2=A0=C2=A0 does not have enough resources, t=
hen it MUST silently discard the
=C2=A0=C2=A0 packets.=C2=A0 
Wouldn't it be easier to say that the lwb4 MAY=
 reassemble the packet and recalculate the checksum? It's clearly not a=
 MUST...

=C2=A0

[ian] Why is it not a MUST? If one condition is met you MUST do this,= if a different condition is met, you MUST do that. A MAY would make re-ass= embly of the packets optional, meaning that an implementation could not imp= lement support for fragment reassembly at all and still say that it is comp= liant with the spec.


If it were a MUST t= hen something would horribly break if it were not done. The above clearly s= ays that this reassembly operation is at the discretion of the device,=C2= =A0 subject to an arbitrary "enough resources" condition. If you&= #39;d like it to be a MUST then the condition should be removed.

[ian] = Then surely re-assembly is a SHOULD requirement, with a a MUST to discard i= f cannot be re-assembled. As I said, if it was a MAY requirement, then impl= ementation would be completely optional.=C2=A0

=
Woj> Yes, and that's what the above text reads from a tes= t perspective, i.e. since one has no way of determining whether there are &= quot;enough resources", a lwB4 that discards all such packets would co= mply. As I said, if one would like to tighten the spec; a) the un-testable = "enough resources" condition should be removed b) with that eithe= r a MUST used, if this is something super important, or a SHOULD (as it see= ms to me). Alternatively a MAY as "nice to have" may also do.

[Qi] I= prefer to use a SHOULD for re-asembly and a MUST for discarding the packet= if it cannot be reassembled.

Woj> Well, so it's a SHOULD then. Please note: the "enough=20 resources" condition as is, is un-testable across implementations, so= =20 adding such "dead" text is rather pointless.

Cheers,
Wojciech.
--047d7b6d9284b3a5f704f338512a-- From nobody Tue Feb 25 04:43:16 2014 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8215D1A0644 for ; Tue, 25 Feb 2014 04:43:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] 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 hbfJZYdAMPyX for ; Tue, 25 Feb 2014 04:43:13 -0800 (PST) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) by ietfa.amsl.com (Postfix) with ESMTP id 21D3B1A0458 for ; Tue, 25 Feb 2014 04:43:13 -0800 (PST) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 83A3D1B8244 for ; Tue, 25 Feb 2014 04:43:12 -0800 (PST) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 78D9F190052; Tue, 25 Feb 2014 04:43:12 -0800 (PST) Received: from [10.0.10.40] (192.168.1.10) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 25 Feb 2014 04:43:12 -0800 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ted Lemon In-Reply-To: Date: Tue, 25 Feb 2014 07:43:09 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20140211075445.17615.61208.idtracker@ietfa.amsl.com> <8A1B81989BCFAE44A22B2B86BF2B76318A2CDB8ED2@HE111643.EMEA1.CDS.T-INTERNAL.COM> To: Wojciech Dec X-Mailer: Apple Mail (2.1827) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/softwires/DnKYz2auf35AflbRc6FoQxDgQZE Cc: Softwires WG Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-lw4over6-06.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2014 12:43:14 -0000 On Feb 25, 2014, at 5:12 AM, Wojciech Dec wrote: > I still see no reason why they cannot be addressed by edits to the = draft that don't change the matter that lw46 is a standalone draft. Woj, please propose text if you want changes. From nobody Tue Feb 25 10:22:12 2014 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63FC21A01D1 for ; Tue, 25 Feb 2014 10:22:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.5 X-Spam-Level: *** X-Spam-Status: No, score=3.5 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, J_CHICKENPOX_31=0.6, J_CHICKENPOX_32=0.6, J_CHICKENPOX_36=0.6, SPF_PASS=-0.001] autolearn=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 WL7lcae7pnqn for ; Tue, 25 Feb 2014 10:22:04 -0800 (PST) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id EDCB71A01A9 for ; Tue, 25 Feb 2014 10:21:49 -0800 (PST) Received: by mail-ie0-f175.google.com with SMTP id at1so682014iec.34 for ; Tue, 25 Feb 2014 10:21:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=AXeF1rNeMrQ7KPHxIoqdlduKujYzJ6zwzmPKchRUshs=; b=PP6DYY1UT6mtS2MZwGY5QDq1vOynHGrS6tp9XNqLSP7Mm+fMGVbajT8FXmU1qYKTXR Iga/hJnjhFrXxeSf2wBdkzi12+l6kaTVAVXAWB9REcYlufmbeFcNtRjLxjPfjcEWE/xF Ztx5kb+dUN6IrLME8Qug77xQTeI6cJ/NVSEmsC0QnQ5JbS07220avJ8HzNtmPQfrsMBh 2/BWmf/y3EdEwUikDYesN1HF5R65Q6hJUDBvIACY/rZ94f5hVwxKsUYSCyedNlVe3ppg UhsTUopbn0hUsIFfrT8tOr5n4zmj9U0IWrQwH+TCGkaaONaHE2h8Yd4nIpW1xPiv4mgF liNg== X-Received: by 10.50.217.232 with SMTP id pb8mr5040487igc.8.1393352508969; Tue, 25 Feb 2014 10:21:48 -0800 (PST) Received: from [192.168.0.101] (dsl-173-206-150-99.tor.primus.ca. [173.206.150.99]) by mx.google.com with ESMTPSA id pn6sm39863202igb.4.2014.02.25.10.21.47 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 25 Feb 2014 10:21:48 -0800 (PST) Message-ID: <530CDF3D.3030908@gmail.com> Date: Tue, 25 Feb 2014 13:21:49 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Wojciech Dec References: <20140211075445.17615.61208.idtracker@ietfa.amsl.com> <8A1B81989BCFAE44A22B2B86BF2B76318A2CDB8ED2@HE111643.EMEA1.CDS.T-INTERNAL.COM> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/softwires/E009qsOwQBZpveBqvmGDL2wFzQk Cc: Softwires WG Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-lw4over6-06.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2014 18:22:07 -0000 I think you're being unfair on one point. 1:1 mode was an afterthought in MAP, appearing after LW4o6 had been published. It is not reasonable to say now that LW4o6 is just a subset of MAP because 1:1 mode is possible in the latter. 1:1 is certainly not MAP's main thrust. I know this is a political rather than a technical point, but one could sort of reverse the claim and suggest that if 1:1 mode is desired, LW4o6 is the better way to go. Tom Taylor On 25/02/2014 5:12 AM, Wojciech Dec wrote: > Hi Qi, > > your answers didn't answer the majority of the concerns raised. And some > of those raised by Ole still also stand: > - Clean-up text that does not belong to lw46 (eg 2473 fixes, NAT44 best > practice). > - Clarification of WAN selection or assumptions > - Clarify questionable use of ICMPv6 error code (to report lack of v4 > binding) > - Text clarifying relation to MAP-E (both use MAP PSID algo, address > embedding, IPv4inIPv6 and NAT44 w/ address sharing. MAP allows state to > be ranged from N to 1 per CPE. lw46 focuses on the 1:1 case) > > I still see no reason why they cannot be addressed by edits to the draft > that don't change the matter that lw46 is a standalone draft. > > > Snipped text Inline... Woj> > > > On 21 February 2014 10:25, Qi Sun > wrote: > > > Hi Woj, > > > On 2014-2-19, at 下åˆ4:34, Wojciech Dec wrote: >> >> Just to be clear: I'm ok with lw46 defining a specific functional >> mode as I believe it does in this draft, > > [Qi] The outcome of ietf88 was lw4o6 and map are two mechanisms, but > both use the Softwire DHCP for provisioning (at least according to > my memory). That is why the WG decided to remove the statement of > "lw4o6 is a subset of MAP-E" is from the Softwire DHCP Option draft. > > And lw4o6 can use DHCPv4 over DHCPv6 and PCP for provisioning. This > is documented in the current lw4o6 draft, and some teams are doing > the documentation work. (We have demoed in IETF85 that lw4o6 can > work with DHCPv4 over IPv6 and PCP). The point is, lw4o6 > architecture is quite flexible. > > > > Woj>I didn't quite comment on the DHCP draft, nor on how flexible and > clear *you think* the lw46 draft is, etc. I commented on the fact that > that lw46 shares a lot with MAP-E and the fact that it is built on the > same technology blocks as MAP-E, but realizes solely the 1:1 part should > be clarified. > > Irrespective of this, there is overall no reason for having text in the > lw46 draft that fixes 2473 or NAT44 best practices, etc. > > >> also leaving "as-is" the DHCP part of it (i.e. it's a capability >> that can be signalled using the lw46 container, etc). > >> General items remain open (as commented): >> - Cleanup text that does not belong to lw46 (eg 2473 fixes, or >> NAT44 best practice). > > [Qi] IMO, that text guarantees the interoperation between lwAFTRs > and lwB4s from different vendors, which bothered us a little when > carrying out the interop test. I think it doesn't hurt to make it > specific. > > > Woj>A couple of points: Firstly: Given that the lwB4 CPE uses the MAP > algorithm for the PSID and embeds the IPv4+PSID in its IPv6 address, the > text is now in shape that a lwB4 would be interoperable with a MAP-E BR. > This is actually good convergence/progress. What remains open in that > happening is actually weeding out the possible source of differences, > which appear to be in the nuances of ICMP handling. > > Secondly: It claims to be a standards track document (currently), and it > carries text that selectively duplicates text in other standard rfcs > without deferring to those RFCs. If there are any reasons why this > "cherry picking" was made, while other recommendations (say re NAT44) > were not adopted, they should be clarified. In general for rfc2473, > there I see so far no zero reason to have some other text here, as > opposed to errata. Same for NAT44 really. > > Then again, perhaps the draft should be interpreted as an RFP of some > kind, which it actually reads a lot like. In which case it should not be > a standard track document. > > >> - Clarification of WAN selection or assumptions > > [Qi] I think Ian has expressed cleared in previous mails. > > > > Woj>Please see my reply to Ian - looking forward to an answer in the draft: > --snip-- > So, in terms of the lw46 draft specifying how a CPE is to get to the IP > prefix of "the WAN interface" is an important aspect, or at least > stating the assumptions about this WAN interface. Some obvious questions > apply here: > is the WAN the interface which has the default route? Is it the > interface that has a DHCPv6 client? What if there are multiple such > "WAN" interfaces? What if a single "WAN" has multiple IPv6 prefixes? > What if it has NO global IPv6 prefix? What if it doesn't have a /64 > prefix. etc. > --snip-- > One doesn't see the draft answering any of these at the moment. > > >> >> That said, abundant technical evidence (summarized in previous >> mail) indicates that this mode is in near total overlap with MAP >> 1:1, certainly much more than at the outset of this work. Given >> this, why not align the text and actually make MAP 1:1 and lw46 be >> the same? On all of the data plane IPv6, IPv4, NAT44, tunneling >> and ICMP handling parts I see there no reason for there being a >> difference... > > [Qi] I think lw4o6 is clean and simple, and flexible to work with > different provisioning mechanisms (signaling through the Softwire > DHCP as is agreed by the WG). > > >> >> continued inline... >> >> >> >> >> [ian] The draft already contains the following text (and has >> for some time): >> >> Lightweight 4over6 provides a solution for a hub-and-spoke softwire >> architecture only. It does not offer direct, meshed IPv4 >> connectivity between subscribers without packets traversing the AFTR. >> If this type of meshed interconnectivity is required, >> [I-D.ietf-softwire-map] provides a suitable solution. >> >> So, are you not happy with the wording of the current >> reference, or are you requesting that the draft is rewritten >> to be cast as a ‘specialised' case of MAP? >> >> What I pointed out is that the Lw46 draft has major if near total >> overlap with MAP-E 1:1 mode. Stating that lw46 realizes this mode, >> in a standalone way from the N:1 mesh mode, is what I propose. >> This would greatly help in implementing it and "digesting" the >> array of solutions. > > [Qi] I don't see any "help" here... > > > Woj>To an operator and implementer, it would be very advantageous that > all of IPv4 in IPv6 and NAT44 data plane aspects, as specified by > Softwire drafts are the same, unless it is made clear as to why they > should be different, and what does it bring. This applies especially to > lw46 and MAP, since there is so much overlap between the solutions. > > >> Additional comment Now that you mention it, the stated >> characterisation of map isn't quite right; MAP does not force the >> use of mesh mode, nor is mesh mode its defining characteristic. > > [Qi] From my reading, the text doesn't characterize what MAP is. It > just says "if you want to use meshed IPv4 connectivity, then use > MAP". It doesn't prevent you from using MAP to do anything else. So > I think the text is OK. > > > Woj> Well, that is "characterisation". From dictionary: "The act of > describing the character or qualities of someone or something" > And as stated, it is not quite correct, i.e. mesh-mode is not the > defining feature of MAP. The state optimization (stateless) is, of which > mesh mode is a by product (optional actually in the spec). The text > needs to be changed. > > >> The characterisation should be restated as " lw46 does not seek to >> offer the optimization of AFTR subscriber state and the AFTR is >> expected to have configuration state for each lwB4 node. If >> optimization of this state is required, [id-ietf-softwire-map] >> provides a suitable solution ". >> Alternatively, state that "lw46 describes a >> deployment/implementation of MAP 1:1" >>> >>> >>>> >>>> Detailed comments: >>>> >>>> * Section 5.1 WAN prefix selection and address forming - >>>> as per Ole's comment. This is indeed hand wavy in the >>>> current draft (how to select the WAN?) >>>> >>>> [ian] I’ve updated with the wording that I proposed to Ole. >>>> >>>> The CPE WAN interface is a fairly well used term in a >>>> number of other RFCs. Both RFC6333 and RFC7084 use the >>>> term (and have implementations based on them) without >>>> defining how the CPE has identified it. Why does that >>>> need to be specifically defined here? >>>> >>>> >>>> Woj> What is the WAN interface is, and how should the CPE >>>> "find it" not said. That other drafts fail to clarify that >>>> doesn't make it quite right… >>> >>> >>> [ian] No, this is related to fragmentation in respect to the >>> RFC1858 'Tiny Fragment attack' which affects the IPv4 >>> payload. The same problems exist for the lwB4s NAT44 function >>> as exist for a NAT64 in this respect, which is why it was >>> included. >>> >>> >>> Woj> Ok, but what does "MAY require" mean, and how should a >>> device go about requiring it? >> > [Qi] Please see page 18 of RFC6146: > > * The NAT64 MAY require that the UDP, TCP, or ICMP header be > completely contained within the fragment that contains > fragment > offset equal to zero. > > > Woj> Well, that text as you point comes from NAT64, and concerns IPv6 > header chain to IPv4 header "fitting". In lwB4, unless I misunderstand, > the only fragmentation there may be is that of IPv4 that would be driven > by an IPv4 MTU < 40 (violation of IPv4 min MTU 68). So what exactly the > draft is requiring here isn't clear. > In any case the fragmentation behaviour is not something specific to > lw46, so it would be best if you pointed the draft at the source. > > >>> >>> >>> * Section 5.2: Text: >>> >>> For incoming de-capsulated IPv4 packets carrying UDP packets with a >>> >>> zero checksum, if the lwB4 has enough resources, the lwB4 MUST >>> >>> reassemble the packets and MUST calculate the checksum. If the lwB4 >>> >>> does not have enough resources, then it MUST silently discard the >>> >>> packets. >>> >>> Wouldn't it be easier to say that the lwb4 MAY reassemble >>> the packet and recalculate the checksum? It's clearly not >>> a MUST... >>> >>> [ian] Why is it not a MUST? If one condition is met you >>> MUST do this, if a different condition is met, you MUST >>> do that. A MAY would make re-assembly of the packets >>> optional, meaning that an implementation could not >>> implement support for fragment reassembly at all and >>> still say that it is compliant with the spec. >>> >>> >>> If it were a MUST then something would horribly break if it >>> were not done. The above clearly says that this reassembly >>> operation is at the discretion of the device, subject to an >>> arbitrary "enough resources" condition. If you'd like it to >>> be a MUST then the condition should be removed. >> >> [ian] Then surely re-assembly is a SHOULD requirement, with a >> a MUST to discard if cannot be re-assembled. As I said, if it >> was a MAY requirement, then implementation would be completely >> optional. >> >> >> Woj> Yes, and that's what the above text reads from a test >> perspective, i.e. since one has no way of determining whether >> there are "enough resources", a lwB4 that discards all such >> packets would comply. As I said, if one would like to tighten the >> spec; a) the un-testable "enough resources" condition should be >> removed b) with that either a MUST used, if this is something >> super important, or a SHOULD (as it seems to me). Alternatively a >> MAY as "nice to have" may also do. > > [Qi] I prefer to use a SHOULD for re-asembly and a MUST for > discarding the packet if it cannot be reassembled. > > > Woj> Well, so it's a SHOULD then. Please note: the "enough resources" > condition as is, is un-testable across implementations, so adding such > "dead" text is rather pointless. > > Cheers, > Wojciech. > > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > From nobody Tue Feb 25 10:29:49 2014 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78DEE1A013E for ; Tue, 25 Feb 2014 10:29:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] 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 ZBygx1kVDYMQ for ; Tue, 25 Feb 2014 10:29:42 -0800 (PST) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) by ietfa.amsl.com (Postfix) with ESMTP id 7142B1A0114 for ; Tue, 25 Feb 2014 10:29:42 -0800 (PST) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id CEB2B1B8229 for ; Tue, 25 Feb 2014 10:29:41 -0800 (PST) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id C73FE190052; Tue, 25 Feb 2014 10:29:41 -0800 (PST) Received: from [10.0.10.40] (192.168.1.10) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 25 Feb 2014 10:29:41 -0800 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ted Lemon In-Reply-To: <530CDF3D.3030908@gmail.com> Date: Tue, 25 Feb 2014 13:29:39 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20140211075445.17615.61208.idtracker@ietfa.amsl.com> <8A1B81989BCFAE44A22B2B86BF2B76318A2CDB8ED2@HE111643.EMEA1.CDS.T-INTERNAL.COM> <530CDF3D.3030908@gmail.com> To: Tom Taylor X-Mailer: Apple Mail (2.1827) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/softwires/0FgpwL10Egrxl345GM3VZAIlqkw Cc: Softwires WG Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-lw4over6-06.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2014 18:29:47 -0000 On Feb 25, 2014, at 1:21 PM, Tom Taylor = wrote: > I know this is a political rather than a technical point, but one = could sort of reverse the claim and suggest that if 1:1 mode is desired, = LW4o6 is the better way to go. Indeed, if all one needs is 1:1, one might prefer lw4over6 since it only = has the one mode. From nobody Tue Feb 25 15:11:28 2014 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3AA71A02F3 for ; Tue, 25 Feb 2014 15:11:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] 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 HhUAZtySkdtm for ; Tue, 25 Feb 2014 15:11:18 -0800 (PST) Received: from banjo.employees.org (banjo.employees.org [IPv6:2001:1868:205::19]) by ietfa.amsl.com (Postfix) with ESMTP id AAC5A1A00C2 for ; Tue, 25 Feb 2014 15:11:18 -0800 (PST) Received: from dhcp-10-61-106-63.cisco.com (173-38-208-169.cisco.com [173.38.208.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id CBE7A610F; Tue, 25 Feb 2014 15:11:14 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_BD8552EA-5E05-4B6C-A7AB-885A747CA88C"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ole Troan In-Reply-To: Date: Wed, 26 Feb 2014 00:11:06 +0100 Message-Id: References: <20140211075445.17615.61208.idtracker@ietfa.amsl.com> <8A1B81989BCFAE44A22B2B86BF2B76318A2CDB8ED2@HE111643.EMEA1.CDS.T-INTERNAL.COM> <530CDF3D.3030908@gmail.com> To: Ted Lemon X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/softwires/4XcMYSRha1D5HfD077QcIMfUiEw Cc: Softwires WG Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-lw4over6-06.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2014 23:11:25 -0000 --Apple-Mail=_BD8552EA-5E05-4B6C-A7AB-885A747CA88C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii >> I know this is a political rather than a technical point, but one = could sort of reverse the claim and suggest that if 1:1 mode is desired, = LW4o6 is the better way to go. >=20 > Indeed, if all one needs is 1:1, one might prefer lw4over6 since it = only has the one mode. I think the point he was trying to make was that it isn't optimal to = have two standards documents, specifying mechanisms where one is almost = completely encompassed by the other. I say almost, because there might = be some divergence in how tunnel endpoint addresses are used, and how = fragmentation and ICMP is dealt with. cheers, Ole --Apple-Mail=_BD8552EA-5E05-4B6C-A7AB-885A747CA88C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJTDSMKAAoJEFuJXizso86gjMUH/0AMy8H9UjBTvL1jtzBNIJ0u SXG8dZHStrAVlhE928Ht8OVQwDUY/LFbfGaGQB7IFCJzsAzYgf82R3cuyjUDg16W C0U4TmR9IYGoBSmS7DSTZT/SfDMAEAcKSO/LVs31hIa+i4f9uLOTFb3RVtHCkrki 8Lzh0Vc3SS7Z601o/SgNT/cOPX5bzZnxtB6fw7L/RcpgqGZQgp91I4UqtzSj9bvn qeZvAwgM4qAxuY9S8+TzEDW21UPbPZIWV+Vu6tvIZeGLxzLhJpsjK/+R5CG9Pl0K zW+zsOJQyDaonP15QSn06Oa17h5dlxv6R5/qBkhNSKpsMX8klnzXYE53fFbtPJs= =JCd4 -----END PGP SIGNATURE----- --Apple-Mail=_BD8552EA-5E05-4B6C-A7AB-885A747CA88C-- From nobody Tue Feb 25 15:55:54 2014 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F22E01A0311 for ; Tue, 25 Feb 2014 15:55:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] 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 nz4vJN6Tq5vv for ; Tue, 25 Feb 2014 15:55:46 -0800 (PST) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) by ietfa.amsl.com (Postfix) with ESMTP id B844A1A02CD for ; Tue, 25 Feb 2014 15:55:46 -0800 (PST) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id A41B61B8215 for ; Tue, 25 Feb 2014 15:55:45 -0800 (PST) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 96CCD190052; Tue, 25 Feb 2014 15:55:45 -0800 (PST) Received: from [10.0.1.10] (192.168.1.10) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 25 Feb 2014 15:55:45 -0800 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ted Lemon In-Reply-To: Date: Tue, 25 Feb 2014 18:55:41 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <947F3013-19D5-4EB0-82DC-1246AE9362FE@nominum.com> References: <20140211075445.17615.61208.idtracker@ietfa.amsl.com> <8A1B81989BCFAE44A22B2B86BF2B76318A2CDB8ED2@HE111643.EMEA1.CDS.T-INTERNAL.COM> <530CDF3D.3030908@gmail.com> To: Ole Troan X-Mailer: Apple Mail (2.1827) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/softwires/IHBr327EENCGoUCIeeWIjmRddWw Cc: Softwires WG Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-lw4over6-06.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2014 23:55:48 -0000 On Feb 25, 2014, at 6:11 PM, Ole Troan wrote: > I think the point he was trying to make was that it isn't optimal to = have two standards documents, specifying mechanisms where one is almost = completely encompassed by the other. I say almost, because there might = be some divergence in how tunnel endpoint addresses are used, and how = fragmentation and ICMP is dealt with. If this is indeed his point, I'm sure we're all sympathetic (I know I = am) but it's not actionable, so we should move on. From nobody Tue Feb 25 16:07:41 2014 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D16F01A031D for ; Tue, 25 Feb 2014 16:07:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] 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 i40f1gjoZHwC for ; Tue, 25 Feb 2014 16:07:35 -0800 (PST) Received: from banjo.employees.org (banjo.employees.org [198.137.202.19]) by ietfa.amsl.com (Postfix) with ESMTP id EB92C1A0311 for ; Tue, 25 Feb 2014 16:07:33 -0800 (PST) Received: from dhcp-10-61-106-63.cisco.com (173-38-208-169.cisco.com [173.38.208.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 7E89660C9; Tue, 25 Feb 2014 16:07:30 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_D3C6C3ED-5507-4A85-A4F5-E56EFE8B4773"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ole Troan In-Reply-To: <947F3013-19D5-4EB0-82DC-1246AE9362FE@nominum.com> Date: Wed, 26 Feb 2014 00:07:27 +0000 Message-Id: <1BE1620D-0AB2-4B63-ACF6-9974E53627DE@employees.org> References: <20140211075445.17615.61208.idtracker@ietfa.amsl.com> <8A1B81989BCFAE44A22B2B86BF2B76318A2CDB8ED2@HE111643.EMEA1.CDS.T-INTERNAL.COM> <530CDF3D.3030908@gmail.com> <947F3013-19D5-4EB0-82DC-1246AE9362FE@nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/softwires/o3phmFsR0b_Uf48MZdSZEWXDADk Cc: Softwires WG Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-lw4over6-06.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2014 00:07:38 -0000 --Apple-Mail=_D3C6C3ED-5507-4A85-A4F5-E56EFE8B4773 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 25 Feb 2014, at 23:55 , Ted Lemon wrote: > On Feb 25, 2014, at 6:11 PM, Ole Troan wrote: >> I think the point he was trying to make was that it isn't optimal to = have two standards documents, specifying mechanisms where one is almost = completely encompassed by the other. I say almost, because there might = be some divergence in how tunnel endpoint addresses are used, and how = fragmentation and ICMP is dealt with. >=20 > If this is indeed his point, I'm sure we're all sympathetic (I know I = am) but it's not actionable, so we should move on. au contrarie, it is clearly actionable, but I think the working group = has done the best it can, so if there are actions, those should be = elsewhere. cheers, Ole --Apple-Mail=_D3C6C3ED-5507-4A85-A4F5-E56EFE8B4773 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJTDTA/AAoJEFuJXizso86gv2EIAIbzICcF2LrIoLwdW1nhbE3y NVeJS/wYJb7+83T3kM3WFmqGYi61r8OXfTB4QdRe3tX2/2h/OlpmkXrw1wdmmuMV tgU77j1eqmKQA+BpabAt/HA4Lg5xjdsMjxgS9S7mwMqKevNkIJyndh69bh9Hz+BN d0GmI/gGgexue1vgHva9KpEMCUcIS70mQ/JXixKsMEBptJDNHo9sfkQ5hHpeKuLi 0GDXof/3QUXiSV2z7cnlfg2qVy9o21j1bszNPPQ16iXFFw8EH97PO5QkSoCl92Rq +59+e9akhubMtFfrPsEw96HaNKo5ILEU0W9MgUs/mZ8xWfUtxTpMCz09HhCdQNk= =w8s1 -----END PGP SIGNATURE----- --Apple-Mail=_D3C6C3ED-5507-4A85-A4F5-E56EFE8B4773-- From nobody Tue Feb 25 16:45:46 2014 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DDDB1A03FB for ; Sat, 22 Feb 2014 02:59:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.301 X-Spam-Level: * X-Spam-Status: No, score=1.301 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, SPF_PASS=-0.001] autolearn=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 6X5oLTl9Aoee for ; Sat, 22 Feb 2014 02:59:49 -0800 (PST) Received: from mail-pb0-x22b.google.com (mail-pb0-x22b.google.com [IPv6:2607:f8b0:400e:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 104DD1A03D3 for ; Sat, 22 Feb 2014 02:59:49 -0800 (PST) Received: by mail-pb0-f43.google.com with SMTP id ma3so1890175pbc.16 for ; Sat, 22 Feb 2014 02:59:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=j2nY6QQS8aOi8xRiGYqv8caETSl23gMjRk93aQCshWo=; b=EDYPq2b+MzMc+5FQJ4aHWPbeA2bYudo6Hgu+VPPN+15PMtIQHYA23MB70hyXTl2RHO yli9qhZYy0/KRJzb+cNncSU26SFYPy+Ml2Fua3tAvkYgh/Ll3gfWJbm/+ceRJESTOlaG HuK58h0Xo2PfUo/bOan0CvYIDBYDh5FnIHrAnQ7RhkO1CJDSYe8wG+MYantFE3SlgYbD Jm7+MbfCcmtfhQ3EMG6RA+vkk3s+e1luVmGj+uOjfyb60vbzA3SyVFH9G2mdAXI/mzQB 7/UgxhecDJXIlq4f+jW5QQpUU1RwU05DgTI5d4K8U9uijDQGKLXn/41HIjCfX+LvHNT+ ayiw== MIME-Version: 1.0 X-Received: by 10.66.217.133 with SMTP id oy5mr14761308pac.46.1393066784856; Sat, 22 Feb 2014 02:59:44 -0800 (PST) Received: by 10.70.1.70 with HTTP; Sat, 22 Feb 2014 02:59:44 -0800 (PST) In-Reply-To: References: <20140211075445.17615.61208.idtracker@ietfa.amsl.com> <8A1B81989BCFAE44A22B2B86BF2B76318A2CDB8ED2@HE111643.EMEA1.CDS.T-INTERNAL.COM> Date: Sat, 22 Feb 2014 11:59:44 +0100 Message-ID: From: Wojciech Dec To: Qi Sun Content-Type: multipart/alternative; boundary=047d7b5da891dc1d9004f2fca295 Archived-At: http://mailarchive.ietf.org/arch/msg/softwires/KJrN2rA3IekR5qtKpuTotNG7dII X-Mailman-Approved-At: Tue, 25 Feb 2014 16:45:34 -0800 Cc: Softwires WG Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-lw4over6-06.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Feb 2014 10:59:53 -0000 --047d7b5da891dc1d9004f2fca295 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Qi, afraid that your answers didn't answer the majority of the concerns raised. I still see no reason why they cannot be addressed by edits to the draft that don't change the matter that lw46 is a standalone draft. Inline... On 21 February 2014 10:25, Qi Sun wrote: > > Hi Woj, > > > On 2014-2-19, at =E4=B8=8B=E5=8D=884:34, Wojciech Dec wrote: > > > Just to be clear: I'm ok with lw46 defining a specific functional mode as > I believe it does in this draft, > > > [Qi] The outcome of ietf88 was lw4o6 and map are two mechanisms, but both > use the Softwire DHCP for provisioning (at least according to my memory). > That is why the WG decided to remove the statement of "lw4o6 is a subset = of > MAP-E" is from the Softwire DHCP Option draft. > > And lw4o6 can use DHCPv4 over DHCPv6 and PCP for provisioning. This is > documented in the current lw4o6 draft, and some teams are doing the > documentation work. (We have demoed in IETF85 that lw4o6 can work with > DHCPv4 over IPv6 and PCP). The point is, lw4o6 architecture is quite > flexible. > I didn't quite comment on the DHCP part, nor on how flexible and clear you think lw46 is is, etc... Will refrain from making replies to such points as they're not constructive. > > also leaving "as-is" the DHCP part of it (i.e. it's a capability that can > be signalled using the lw46 container, etc). > > > General items remain open (as commented): > - Cleanup text that does not belong to lw46 (eg 2473 fixes, or NAT44 best > practice). > > > [Qi] IMO, that text guarantees the interoperation between lwAFTRs and > lwB4s from different vendors, which bothered us a little when carrying ou= t > the interop test. I think it doesn't hurt to make it specific. > It is a standards track document (currently), and it carries text that selectively duplicates text in other standard rfcs without deferring to those RFCs. If there are any reasons why this "cherry picking" was made, and other recommendations (say re NAT44) not, they should be clarified. In general for rfc2473, there I see so far no zero reason to have some other text here, as opposed to errata. Then again, perhaps the draft should be interpreted as an RFP of some kind, which it actually reads a lot like being. In which case it should not be a standard track document. > > - Clarification of WAN selection or assumptions > > > [Qi] I think Ian has expressed cleared in previous mails. > Please see my reply to Ian. --snip-- So, in terms of the lw46 draft specifying how a CPE is to get to the IP prefix of "the WAN interface" is an important aspect, or at least stating the assumptions about this WAN interface. Some obvious questions apply here= : is the WAN the interface which has the default route? Is it the interface that has a DHCPv6 client? What if there are multiple such "WAN" interfaces? What if a single "WAN" has multiple IPv6 prefixes? What if it has NO global IPv6 prefix? What if it doesn't have a /64 prefix. etc. --snip-- One doesn't see the draft answering any of these. > > > That said, abundant technical evidence (summarized in previous mail) > indicates that this mode is in near total overlap with MAP 1:1, certainly > much more than at the outset of this work. Given this, why not align the > text and actually make MAP 1:1 and lw46 be the same? On all of the data > plane IPv6, IPv4, NAT44, tunneling and ICMP handling parts I see there no > reason for there being a difference... > > > [Qi] I think lw4o6 is clean and simple, and flexible to work with > different provisioning mechanisms (signaling through the Softwire DHCP as > is agreed by the WG). > > > > continued inline... > > > On 17 February 2014 17:15, Ian Farrer wrote: > >> Hi Woj, >> >> Please see inline. >> >> Cheers, >> Ian >> >> On 16 Feb 2014, at 17:32, Wojciech Dec wrote: >> >> Hi Ian, >> >> you haven't replied on my high level comment - would appreciate if you >> introduced changes to that effect in the draft. >> >> Continued inline=E2=80=A6 >> >> >> [ian] The draft already contains the following text (and has for some >> time): >> >> Lightweight 4over6 provides a solution for a hub-and-spoke softwire >> architecture only. It does not offer direct, meshed IPv4 >> connectivity between subscribers without packets traversing the AFTR. >> If this type of meshed interconnectivity is required, >> [I-D.ietf-softwire-map] provides a suitable solution. >> >> So, are you not happy with the wording of the current reference, or are >> you requesting that the draft is rewritten to be cast as a =E2=80=98spec= ialised' >> case of MAP? >> > What I pointed out is that the Lw46 draft has major if near total overlap > with MAP-E 1:1 mode. Stating that lw46 realizes this mode, in a standalon= e > way from the N:1 mesh mode, is what I propose. This would greatly help in > implementing it and "digesting" the array of solutions. > > > [Qi] I don't see any "help" here... > As an operator and implementer, it would be very advantageous that all of IPv4 in IPv6 and NAT44 data plane aspects, as specified by Softwire drafts are the same, unless it is made clear as to why they should be different. This applies especially to lw46 and MAP, since there is clear overlap. > > Additional comment Now that you mention it, the stated characterisation o= f > map isn't quite right; MAP does not force the use of mesh mode, nor is me= sh > mode its defining characteristic. > > > [Qi] From my reading, the text doesn't characterize what MAP is. It just > says "if you want to use meshed IPv4 connectivity, then use MAP". It > doesn't prevent you from using MAP to do anything else. So I think the te= xt > is OK. > Well, that is "a characterisation", and as stated, it is not quite correct, i.e. mesh-mode is not the defining feature of MAP (although you appear to think so). > > The characterisation should be restated as " lw46 does not seek to offer > the optimization of AFTR subscriber state and the AFTR is expected to hav= e > configuration state for each lwB4 node. If optimization of this state is > required, [id-ietf-softwire-map] provides a suitable solution ". > Alternatively, state that "lw46 describes a deployment/implementation of > MAP 1:1" > > > [Qi] In my opinion, the current wording is clear and enough. > > > >> Either way, I don=E2=80=99t really agree with your justification points = for a >> change: >> - The PSID and the port range are algorithmically derived & related as >> per the MAP algorithm (covered in Section 5.1) >> [ian] The PSID usage in lw4o6 is written so that you don=E2=80=99t have= to >> implement the MAP algorithm to use it (hence the should requirement for >> a=3D0). This makes it functionally identical to the PSID originally desc= ribed >> in draft-bajko-pripaddrassign. So lw4o6 does not require you to implemen= t >> the MAP algorithm, but it doesn=E2=80=99t prevent you from using MAP to = implement >> it (which was the reason for the agreement on using the MAP PSID DHCP >> format). >> > I'm actually fine with the current lw46 text in section 5.1, but your > response seems to conflict with that. I'll start another thread on this > topic. > > > >> - The assigned IPv4 address and port-set form part of the IPv6 address >> of a lwB4, and are included in the interface-identifier in the same plac= e >> and format as MAP (Section 5.1) >> [ian] This is noted and already referenced in the lw4o6 draft. >> - The lw46 CPE should be provisioned using the MAP DHCP (also Section >> 5.1). >> [ian] The draft which is called map-dhcp has been re-written extensively >> with input from people across the WG to be a DHCP option for provisionin= g >> map & lw4o6. It is now map-dhcp by filename alone and once it progresses= , >> won=E2=80=99t even be called that anymore. How does this make lw4o6 >> a =E2=80=98specialisation' of MAP? >> As it=E2=80=99s potentially a significant change that you are requesting= here, >> I=E2=80=99d appreciate the opinions of other members of the WG on this. >> > > [Qi] I think the current lw4o6 draft is good to read and it reflects the > outcome of the last Vancouver meeting. > > > >> >>> Detailed comments: >>> >>> * Section 5.1 WAN prefix selection and address forming - as per Ole's >>> comment. This is indeed hand wavy in the current draft (how to select >>> the WAN?) >>> >>> [ian] I=E2=80=99ve updated with the wording that I proposed to Ole. >>> >>> The CPE WAN interface is a fairly well used term in a number of other >>> RFCs. Both RFC6333 and RFC7084 use the term (and have implementations b= ased >>> on them) without defining how the CPE has identified it. Why does that = need >>> to be specifically defined here? >>> >> >> Woj> What is the WAN interface is, and how should the CPE "find it" not >> said. That other drafts fail to clarify that doesn't make it quite right= =E2=80=A6 >> >> >> [ian] This is entirely implementation specific and something that hasn= =E2=80=99t >> stopped millions of CPEs being built and deployed that support both RFC6= 333 >> and RFC7084 (n=C3=A9 RFC6204). What=E2=80=99s the problem that you are t= rying to solve? >> > > Woj> None of those texts attempt to create a deterministic ip interface, > and in case of 6333 that is a known operational issue. So, in terms of th= e > lw46 draft specifying how a CPE is to get to the IP prefix of "the WAN > interface" is an important aspect, or at least stating the assumptions > about this WAN interface. Some obvious questions apply here: > is the WAN the interface which has the default route? Is it the interface > that has a DHCPv6 client? What if there are multiple such "WAN" interface= s? > What if a single "WAN" has multiple IPv6 prefixes? What if it has NO glob= al > IPv6 prefix? What if it doesn't have a /64 prefix. etc. > > Coincidentally, all of the latter are options allowed for by RFC7084. > > >> >> * Processing of IPv4 fragments Section 5.2. Text " The lwB4 MAY require >>> that the UDP, TCP, or ICMP header be completely contained within the >>> fragment that contains fragment offset equal to zero." >>> >>> What does that mean? Is it trying to say that the IPv4 MTU > 40? >>> >>> >>> >>> [ian] The text is taken directly from RFC6146. I guess that doesn=E2=80= =99t >>> specify is as a defined MTU size of > 40 bytes (or anything else) as th= e >>> IPv4 header could feasibly be longer than 20 bytes if options were incl= uded >>> in it, so the fragmented L4 header problem could still exist. >>> >> >> Here we're talking about tunneling, and I cannot see a case whereby the >> IPv4 TCP/UDP header would get fragmented, unless the MTU of the IPv6 tun= nel >> was <40. rfc6146 is about translation where other effects come to apply. >> >> >> [ian] No, this is related to fragmentation in respect to the RFC1858 >> 'Tiny Fragment attack' which affects the IPv4 payload. The same problem= s >> exist for the lwB4s NAT44 function as exist for a NAT64 in this respect, >> which is why it was included. >> > > Woj> Ok, but what does "MAY require" mean, and how should a device go > about requiring it? > > > [Qi] Please see page 18 of RFC6146: > > * The NAT64 MAY require that the UDP, TCP, or ICMP header be > completely contained within the fragment that contains fragment > offset equal to zero. > Well, that text as you point comes from NAT64, and concerns IPv6 header chain to IPv4 header "fitting". In lwB4, unless I misunderstand, the only fragmentation there may be is that of IPv4 that would be driven by an IPv4 MTU < 40 (violation of IPv4 min MTU 68). So what exactly the draft is requiring here isn't clear. In any case the fragmentation behaviour is not something specific to lw46, so it would be best if you pointed the draft at the source. > > >>> >>> Section 5.2: " >>> >>> For incoming packets carrying TCP or UDP IPv4 fragments with a non- >>> >>> zero checksum, after de-capsulation, the lwB4 MAY elect to queue the >>> >>> fragments as they arrive and perform NAPT44 on all fragments at the >>> >>> same time" >>> >>> ?? Queue based on what? Presumably the fragment identifier field, and i= f so then that is no different to 2473. >>> >>> >>> >>> [ian] Updated the text to note that. >>> >> >> Ok, but in essence, it would be actually better removing the text since >> it adds nothing above 2473. >> >> >> [ian] The text in the current version reads: >> >> For incoming packets carrying TCP or UDP IPv4 fragments with a non- >> zero checksum, after de-capsulation, the lwB4 MAY elect to queue the >> fragments as they arrive and perform NAPT44 on all fragments at the >> same time. In this case, the incoming 5-tuple is determined by >> extracting the appropriate fields from the received packet, as >> described in [RFC2473]. Alternatively, a lwB4 MAY translate the de- >> capsulated fragments as they arrive, by storing information that >> allows it to compute the 5-tuple for fragments other than the first. >> >> In the context of the above, is this a problem? >> > > Woj> Well, what strikes me is that the above text does not bring in > anything other than what's already in 2473 for IPinIP fragementation and > [RFC5508], and [RFC5382] for NAT. The text should refer to those > documents, or file errata. In other words, IPv4inIPv6 fragments and > handling of IPv4 fragments with NAT44 is not a lwB4 specific function, an= d > is already well documented. > > > > >> >> >>> >>> * Section 5.2: Text: >>> >>> For incoming de-capsulated IPv4 packets carrying UDP packets with a >>> >>> zero checksum, if the lwB4 has enough resources, the lwB4 MUST >>> >>> reassemble the packets and MUST calculate the checksum. If the lwB4 >>> >>> does not have enough resources, then it MUST silently discard the >>> >>> packets. >>> >>> Wouldn't it be easier to say that the lwb4 MAY reassemble the packet an= d >>> recalculate the checksum? It's clearly not a MUST... >>> >>> >>> >>> [ian] Why is it not a MUST? If one condition is met you MUST do this, i= f >>> a different condition is met, you MUST do that. A MAY would make >>> re-assembly of the packets optional, meaning that an implementation cou= ld >>> not implement support for fragment reassembly at all and still say that= it >>> is compliant with the spec. >>> >> >> If it were a MUST then something would horribly break if it were not >> done. The above clearly says that this reassembly operation is at the >> discretion of the device, subject to an arbitrary "enough resources" >> condition. If you'd like it to be a MUST then the condition should be >> removed. >> >> >> [ian] Then surely re-assembly is a SHOULD requirement, with a a MUST to >> discard if cannot be re-assembled. As I said, if it was a MAY requiremen= t, >> then implementation would be completely optional. >> > > Woj> Yes, and that's what the above text reads from a test perspective, > i.e. since one has no way of determining whether there are "enough > resources", a lwB4 that discards all such packets would comply. As I said= , > if one would like to tighten the spec; a) the un-testable "enough > resources" condition should be removed b) with that either a MUST used, i= f > this is something super important, or a SHOULD (as it seems to me). > Alternatively a MAY as "nice to have" may also do. > > > [Qi] I prefer to use a SHOULD for re-asembly and a MUST for discarding th= e > packet if it cannot be reassembled. > Woj> Well, so it's a SHOULD then. Please note: the "enough resources" condition as is, is un-testable across implementations, so adding such "dead" text is rather pointless. Cheers, Wojciech. > > Thanks, > Qi > > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > > > --047d7b5da891dc1d9004f2fca295 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Qi,

afraid that your answers did= n't answer the majority of the concerns raised.
I still see no reaso= n why they cannot be addressed by edits to the draft that don't change = the matter that lw46 is a standalone draft.


Inline...


On 21 February 2014 10:25, Qi Sun <sunqi.= csnet.thu@gmail.com> wrote:

Hi Woj,

On 2014-2-19, at =E4=B8=8B=E5=8D=884:34, Wojc= iech Dec wrote:

Just to be clear: I'= ;m ok with lw46 defining a specific functional=20 mode as I believe it does in this draft,

=
[Qi] The outcome of ietf88 was lw4o6 and map are two mecha= nisms, but both use the Softwire DHCP for provisioning (at least according = to my memory). That is why the WG decided to remove the statement of "= lw4o6 is a subset of MAP-E" is from the Softwire DHCP Option draft.

And lw4o6 can use DHCPv4 over DHCPv6 and PCP for provis= ioning. This is documented in the current lw4o6 draft, and some teams are d= oing the documentation work. (We have demoed in IETF85 that lw4o6 can work = with DHCPv4 over IPv6 and PCP). The point is, lw4o6 architecture is quite f= lexible.=C2=A0

I didn't quite comment on = the DHCP part, nor on how flexible and clear you think lw46 is is, etc...= =C2=A0 Will refrain from making replies to such points as they're not c= onstructive.

also leaving "as-is" the DHCP part of= =20 it (i.e. it's a capability that can be signalled using the lw46 contain= er, etc).

General items remain open (as comment= ed):
- Cleanup text that does not belong to lw46 (eg 2473 fixes, or NAT44 best p= ractice).

[Qi] IMO, = that text guarantees the interoperation between lwAFTRs and lwB4s from diff= erent vendors, which bothered us a little when carrying out the interop tes= t. I think it doesn't hurt to make it specific.

It is a standards track docume= nt (currently), and it carries text that selectively duplicates text in oth= er standard rfcs without deferring to those RFCs. If there are any reasons = why this "cherry picking" was made, and other recommendations (sa= y re NAT44) not, they should be clarified. In general for rfc2473, there I = see so far no zero reason to have some other text here, as opposed to errat= a.
Then again, perhaps the draft should be interpreted as an RFP of= some kind, which it actually reads a lot like being. In which case it shou= ld not be a standard track document.

- Clarification of WAN selection or assumptions

[Qi] I think Ian has expressed cleared in previo= us mails.

Please see my reply to Ian= .
--snip--
So, in terms of the lw46 draft specifying= how a CPE is to get to the IP=20 prefix of=C2=A0 "the WAN interface" is an important aspect, or at= least=20 stating the assumptions about this WAN interface. Some obvious questions apply here:
is the WAN the interface which has the default route? Is it the=20 interface that has a DHCPv6 client? What if there are multiple such=20 "WAN" interfaces? What if a single "WAN" has multiple I= Pv6 prefixes?=20 What if it has NO global IPv6 prefix? What if it doesn't have a /64=20 prefix. etc.
--snip--
One doesn't see the = draft answering any of these.

=C2=A0


That said, abun= dant technical evidence (summarized in previous mail) indicates that this m= ode is in near total overlap with MAP 1:1, certainly much more than at the = outset of this work. Given this, why not align the text and actually make M= AP 1:1 and lw46 be the same? On all of the data plane IPv6, IPv4, NAT44, tu= nneling and ICMP handling parts I see there no reason for there being a dif= ference...

[Qi] I think lw4o6 is cl= ean and simple, and flexible to work with different provisioning mechanisms= (signaling through the Softwire DHCP as is agreed by the WG).=C2=A0
<= div class=3D"">



continued inline...


On 17 February 2014 17:15, Ian Farrer <= ianfarrer@gmx.com> wrote:
Hi Woj,

Please see inlin= e.

Cheers,
Ian

On 16 Feb 2014, at 17:32, Wojciech Dec <wdec.ietf@gmail.com> wrote:

Hi Ian,

you haven't replie= d on my high level comment - would appreciate if you introduced changes to = that effect in the draft.

Continued inline=E2=80=A6

[ian] The draft already contains = the following text (and has for some time):
   Lightweight 4over6 provides a solutio=
n for a hub-and-spoke softwire
   architecture only.  It does not offer direct, meshed IPv4
   connectivity between subscribers without packets traversing the AFTR.
   If this type of meshed interconnectivity is required,
   [I-D.ietf-softwire-map] provides a suitable solution.
So, are you not happy with the= wording of the current reference, or are you=C2=A0requesting that the draf= t is rewritten to be cast as a=C2=A0=E2=80=98specialised' case of MAP?<= /font>
What I pointed out is = that the Lw46 draft has major if near total overlap with MAP-E 1:1 mode. Stating that lw46 realizes this mode, in a standalone way = from the N:1 mesh mode, is what I propose. This would greatly help in imple= menting it and "digesting" the array of solutions.

[Qi] I don&#= 39;t see any "help" here...
As an operator and implementer, it would be very advantageous = that all of IPv4 in IPv6 and NAT44 data plane aspects, as specified by Soft= wire drafts are the same, unless it is made clear as to why they should be = different. This applies especially to lw46 and MAP, since there is clear ov= erlap.

Additional comment Now that you mention it, the stated character= isation of map isn't quite right; MAP does not force the use of mesh mo= de, nor is mesh mode its defining characteristic.

[Qi] From my reading, the text= doesn't characterize what MAP is. It just says "if you want to us= e meshed IPv4 connectivity, then use MAP". It doesn't prevent you = from using MAP to do anything else. So I think the text is OK.

Well, that is "a characte= risation", and as stated, it is not quite correct, i.e. mesh-mode is n= ot the defining feature of MAP (although you appear to think so).
=C2=A0

The characterisation should be restated as " lw46 does not seek to offer= =20 the optimization of AFTR subscriber state and the AFTR is expected to have = configuration state for each lwB4 node. If optimization of this state is re= quired, [id-ietf-softwire-map] provides a suitable solution ".
Alternatively, state that "lw46 describes a deployment/implementation = of MAP 1:1"

[Qi] In my opinion, the current wording is clear and enough.= =C2=A0

=C2=A0
Either way, I don=E2=80=99= t really agree with your justification points for a change:
- The PSID and the port range are algorithmically derived & re= lated as per the MAP algorithm (covered in Section 5.1)
=C2=A0[ian] The PSID usage in lw4o6 is written so that you don=E2= =80=99t have to implement the MAP algorithm to use it (hence the should req= uirement for a=3D0). This makes it functionally identical to the PSID origi= nally described in draft-bajko-pripaddrassign. So lw4o6 does not require yo= u to implement the MAP algorithm, but it doesn=E2=80=99t prevent you from u= sing MAP to implement it (which was the reason for the agreement on using t= he MAP PSID DHCP format).
I'm actually fine with the cu= rrent lw46 text in section 5.1, but your response seems to conflict with th= at. I'll start another thread on this topic.

=C2=A0
- The assigned IPv4 address and port-set form part of the IPv6= address of a lwB4, and are included in the interface-identifier in the sam= e place and format as MAP (Section 5.1)
[ian] This is noted and alread= y referenced in the lw4o6 draft.
- The lw46 CPE should = be provisioned using the MAP DHCP (also Section 5.1).
[ian] The draft which is called map-dhcp has been re-written = extensively with input from people across the WG to be a DHCP option for pr= ovisioning map & lw4o6. It is now map-dhcp by filename alone and once i= t progresses, won=E2=80=99t even be called that anymore. How does this make= lw4o6 a=C2=A0=E2=80=98specialisation' of MAP?
As it=E2=80=99s p= otentially a significant change that you are requesting here, I=E2=80=99d a= ppreciate the opinions of other members of the WG on this.

[Qi] = I think the current lw4o6 draft is good to read and it reflects the outcome= of the last Vancouver meeting.

=C2=A0

Detailed comments= :

* Section 5.1 WAN prefix selection and address forming - as per Ol= e's comment.=C2=A0This is indeed hand wavy in the current draft = (how to select the WAN?)

[ian] I=E2=80=99ve updated with the word= ing that I proposed to Ole.

The CPE WAN interface is a fairly well used term= in a number of other RFCs. Both RFC6333 and RFC7084 use the term (and have= implementations based on them) without defining how the CPE has identified= it. Why does that need to be specifically defined here?


Woj>=C2=A0 What is the= WAN interface is, and how should the CPE "find it" not said. Tha= t other drafts fail to clarify that doesn't make it quite right=E2=80= =A6

[ian] Thi= s is entirely implementation specific and something that hasn=E2=80=99t sto= pped millions of CPEs being built and=C2=A0deployed that support both RFC63= 33 and RFC7084 (n=C3=A9 RFC6204). What=E2=80=99s the problem that you are t= rying to solve?

Woj> None of those te= xts attempt to create a deterministic ip interface, and in case of 6333 tha= t is a known operational issue. So, in terms of the lw46 draft specifying h= ow a CPE is to get to the IP prefix of=C2=A0 "the WAN interface" = is an important aspect, or at least stating the assumptions about this WAN = interface. Some obvious questions apply here:
is the WAN the interface which has the default route? Is it the interface t= hat has a DHCPv6 client? What if there are multiple such "WAN" in= terfaces? What if a single "WAN" has multiple IPv6 prefixes? What= if it has NO global IPv6 prefix? What if it doesn't have a /64 prefix.= etc.

Coincidentally, all of the latter are options allowed for by RFC7084.
=C2=A0

* Processing of = IPv4 fragments Section 5.2.=C2=A0Text " The lwB4 M= AY require that the UDP, TCP, or ICMP header be completely contained within= the fragment that contains fragment offset equal to zero."<= /u>

What does that mean? Is it trying t= o say that the IPv4 MTU > 40?

=C2=A0<= /p>

[ian] The text is taken directly from RFC6146. I guess that doesn=E2=80= =99t specify is as a defined MTU size of > 40 bytes (or anything else) a= s the IPv4 header could feasibly be longer than 20 bytes if options were in= cluded in it, so the fragmented L4 header problem could still exist.=


Here we're talking about tunneli= ng, and I cannot see a case whereby the IPv4 TCP/UDP header would get fragm= ented, unless the MTU of the IPv6 tunnel was <40. rfc6146 is about trans= lation where other effects come to apply.

[i= an] No, this is related to fragmentation in respect to the RFC1858 'Tin= y Fragment attack' which affects =C2=A0the IPv4 payload. The same probl= ems exist for the lwB4s NAT44 function as exist for a NAT64 in this respect= , which is why it was included.

Woj> Ok, but what doe= s "MAY require" mean, and how should a device go about requiring = it?

[Qi] Please see page 18 of RFC6146:

=C2=A0 = =C2=A0 =C2=A0 * =C2=A0The NAT64 MAY require that the UDP, TCP, or ICMP head= er be
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0completel= y contained within the fragment that contains fragment
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0offset equal to zero.

Well, that text as you poin= t comes from NAT64, and concerns IPv6 header chain to IPv4 header "fit= ting". In lwB4, unless I misunderstand, the only fragmentation there m= ay be is that of IPv4 that would be driven by an IPv4 MTU < 40 (violatio= n of IPv4 min MTU 68). So what exactly the draft is requiring here isn'= t clear.
In any case the fragmentation behaviour is not something specifi= c to lw46, so it would be best if you pointed the draft at the source.
<= /div>

=C2=A0

Section 5.2: "

For incoming packets carrying TCP or UDP IPv4 fragments w=
ith a non-
=C2=A0=C2=A0 zero checksum, after de-cap=
sulation, the lwB4 MAY elect to queue the
=C2=A0=C2=A0 fragments as they arrive and perform NAPT44 on all fragme=
nts at the
=C2=A0=C2=A0 same time"
?? Queue based on what? Presumably the fragment identifier fie=
ld, and if so then that is no different to 2473.
=C2=A0
=

[ian] Updated the text to= note that.


<= /div>
Ok, but in essence, it would be actually better removing the text= since it adds nothing above 2473.=C2=A0
=

[ian] The text in the current versio= n reads:

For incoming packets carrying TCP or UDP IPv4 =
fragments with a non-
   zero checksum, after de-capsulation, the lwB4 MAY elect to queue the
   fragments as they arrive and perform NAPT44 on all fragments at the
   same time.  In this case, the incoming 5-tuple is determined by
   extracting the appropriate fields from the received packet, as
   described in [RFC2473].  Alternatively, a lwB4 MAY translate the de-
   capsulated fragments as they arrive, by storing information that
   allows it to compute the 5-tuple for fragments other than the first.
In the context of the above, is this a problem?

Woj> Well, what strikes me is that the above text does no= t bring in anything other than what's already in 2473 for IPinIP fragem= entation and=C2=A0 [RFC5508], and=C2=A0 [RFC5382] for NAT. The text should = refer to those documents, or file errata. In other words, IPv4inIPv6 fragme= nts and handling of IPv4 fragments with NAT44 is not a lwB4 specific functi= on, and is already well documented.


=C2=A0

=C2=A0

* Section 5.2: Text:

For =
incoming de-capsulated IPv4 packets carrying UDP packets with a
=C2=A0=C2=A0 zero checksum, if the lwB4 has enough resources, =
the lwB4 MUST
=C2=A0=C2=A0 reassemble the packets and MUST calculate the checksum.=
=C2=A0 If the lwB4
=C2=A0=C2=A0 does not have enoug=
h resources, then it MUST silently discard the
=C2=
=A0=C2=A0 packets.=C2=A0

Wouldn't it be easier to say that the lwb4 MAY r= eassemble the packet and recalculate the checksum? It's clearly not a M= UST...

=C2=A0

[ian] Why is it not a MUST? If one condition is met you= MUST do this, if a different condition is met, you MUST do that. A MAY wou= ld make re-assembly of the packets optional, meaning that an implementation= could not implement support for fragment reassembly at all and still say t= hat it is compliant with the spec.


If it were a MUST t= hen something would horribly break if it were not done. The above clearly s= ays that this reassembly operation is at the discretion of the device,=C2= =A0 subject to an arbitrary "enough resources" condition. If you&= #39;d like it to be a MUST then the condition should be removed.

[ian] = Then surely re-assembly is a SHOULD requirement, with a a MUST to discard i= f cannot be re-assembled. As I said, if it was a MAY requirement, then impl= ementation would be completely optional.=C2=A0

Woj> Yes, and that= 9;s what the above text reads from a test perspective, i.e. since one has n= o way of determining whether there are "enough resources", a lwB4= that discards all such packets would comply. As I said, if one would like = to tighten the spec; a) the un-testable "enough resources" condit= ion should be removed b) with that either a MUST used, if this is something= super important, or a SHOULD (as it seems to me). Alternatively a MAY as &= quot;nice to have" may also do.

[Qi] I= prefer to use a SHOULD for re-asembly and a MUST for discarding the packet= if it cannot be reassembled.

Woj> Well, so it's a SHOULD then. Please note: the "enough= resources" condition as is, is un-testable across implementations, so= adding such "dead" text is rather pointless.

Cheers,
Wojciech.

Thanks,
Qi


_______________________________________________
Softwires mailing listSoftwires@ietf.or= g
https://www.ietf.org/mailman/listinfo/softwires


--047d7b5da891dc1d9004f2fca295-- From nobody Tue Feb 25 17:10:36 2014 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D98A1A081D for ; Tue, 25 Feb 2014 17:10:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.599 X-Spam-Level: ** X-Spam-Status: No, score=2.599 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_31=0.6, J_CHICKENPOX_32=0.6, J_CHICKENPOX_36=0.6, SPF_PASS=-0.001] autolearn=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 hTVEAM0GKn79 for ; Tue, 25 Feb 2014 17:10:25 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 7A6591A0283 for ; Tue, 25 Feb 2014 17:10:25 -0800 (PST) X-AuditID: c6180641-b7f2f8e000002cdc-9c-530d3f007317 Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 5B.D2.11484.00F3D035; Wed, 26 Feb 2014 02:10:24 +0100 (CET) Received: from [164.48.125.55] (147.117.188.8) by smtps-am.internal.ericsson.com (147.117.188.93) with Microsoft SMTP Server (TLS) id 14.2.347.0; Tue, 25 Feb 2014 20:10:22 -0500 Message-ID: <530D3EEC.8040201@ericsson.com> Date: Tue, 25 Feb 2014 20:10:04 -0500 From: Suresh Krishnan User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Wojciech Dec , Qi Sun References: <20140211075445.17615.61208.idtracker@ietfa.amsl.com> <8A1B81989BCFAE44A22B2B86BF2B76318A2CDB8ED2@HE111643.EMEA1.CDS.T-INTERNAL.COM> In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [147.117.188.8] X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprOLMWRmVeSWpSXmKPExsUyuXRPrC6DPW+wwc77OhaHl21lsuibfJvR omXhLWYHZo+ds+6yeyxZ8pMpgCmKyyYlNSezLLVI3y6BK+PtsalMBcczKrY8mc7YwLjbt4uR k0NCwETi7u6rbBC2mMSFe+uBbC4OIYEjjBJ7ml5AOVsZJR7dPwvkcHDwCmhLLJvvA9LAIqAq saT3AiuIzQY0aMPOz0wgtqhAmET7hZnMIDavgKDEyZlPWEBsEQEviYkPZoMtYwbqXfr/CiOI LSzgIfFvxyEWiF0PWCQuz3gOVsQpEChxffVxZogGC4nFbw6yQ9jyEs1bZ4PFhQQ0Jbau+c4K 8YGixIvjP5kmMArNQrJ7FpL2WUjaFzAyr2LkKC1OLctNNzLcxAgM3GMSbI47GBd8sjzEKM3B oiTO++Wtc5CQQHpiSWp2ampBalF8UWlOavEhRiYOTqkGxjRDueW2FoHO+/YIHJGcbHAvU+Tn SQU+1rIfamXHua6feD117Yfjzxena/Bplc78/Fg/ZuZjE6NdOzaIa3W85qkI17rl/yH1y6Gi ySGlZ2UOGSdVVc9savu0yPb1vcf+i0Qk1RbECr1PTNggG7Vq9ZrgNYfEr5ro7Cw6sZg7REPW /couht4UdiWW4oxEQy3mouJEABkCISEqAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/softwires/AUhZKrKrXkeYuk-83T6ytJQm9xE Cc: Softwires WG Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-lw4over6-06.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2014 01:10:28 -0000 Hi Woj, On 02/25/2014 05:12 AM, Wojciech Dec wrote: > Hi Qi, > > your answers didn't answer the majority of the concerns raised. And some > of those raised by Ole still also stand: > - Clean-up text that does not belong to lw46 (eg 2473 fixes, NAT44 best > practice). > - Clarification of WAN selection or assumptions > - Clarify questionable use of ICMPv6 error code (to report lack of v4 > binding) > > I still see no reason why they cannot be addressed by edits to the draft > that don't change the matter that lw46 is a standalone draft. In all fairness, your comments came in a few hours before the draft submission deadline for this IETF. It is unreasonable to expect the issues to get addressed by draft changes, at least until the submission reopens. I do think the above points merit a response from the document editors. > - Text clarifying relation to MAP-E (both use MAP PSID algo, address > embedding, IPv4inIPv6 and NAT44 w/ address sharing. MAP allows state to > be ranged from N to 1 per CPE. lw46 focuses on the 1:1 case) Why do you think this is required here? Isn't this the goal of the unified CPE work (to clarify the commonalities between MAP and lw4over6)? Thanks Suresh > > > Snipped text Inline... Woj> > > > On 21 February 2014 10:25, Qi Sun > wrote: > > > Hi Woj, > > > On 2014-2-19, at 下åˆ4:34, Wojciech Dec wrote: >> >> Just to be clear: I'm ok with lw46 defining a specific functional >> mode as I believe it does in this draft, > > [Qi] The outcome of ietf88 was lw4o6 and map are two mechanisms, but > both use the Softwire DHCP for provisioning (at least according to > my memory). That is why the WG decided to remove the statement of > "lw4o6 is a subset of MAP-E" is from the Softwire DHCP Option draft. > > And lw4o6 can use DHCPv4 over DHCPv6 and PCP for provisioning. This > is documented in the current lw4o6 draft, and some teams are doing > the documentation work. (We have demoed in IETF85 that lw4o6 can > work with DHCPv4 over IPv6 and PCP). The point is, lw4o6 > architecture is quite flexible. > > > > Woj>I didn't quite comment on the DHCP draft, nor on how flexible and > clear *you think* the lw46 draft is, etc. I commented on the fact that > that lw46 shares a lot with MAP-E and the fact that it is built on the > same technology blocks as MAP-E, but realizes solely the 1:1 part should > be clarified. > > Irrespective of this, there is overall no reason for having text in the > lw46 draft that fixes 2473 or NAT44 best practices, etc. > > >> also leaving "as-is" the DHCP part of it (i.e. it's a capability >> that can be signalled using the lw46 container, etc). > >> General items remain open (as commented): >> - Cleanup text that does not belong to lw46 (eg 2473 fixes, or >> NAT44 best practice). > > [Qi] IMO, that text guarantees the interoperation between lwAFTRs > and lwB4s from different vendors, which bothered us a little when > carrying out the interop test. I think it doesn't hurt to make it > specific. > > > Woj>A couple of points: Firstly: Given that the lwB4 CPE uses the MAP > algorithm for the PSID and embeds the IPv4+PSID in its IPv6 address, the > text is now in shape that a lwB4 would be interoperable with a MAP-E BR. > This is actually good convergence/progress. What remains open in that > happening is actually weeding out the possible source of differences, > which appear to be in the nuances of ICMP handling. > > Secondly: It claims to be a standards track document (currently), and it > carries text that selectively duplicates text in other standard rfcs > without deferring to those RFCs. If there are any reasons why this > "cherry picking" was made, while other recommendations (say re NAT44) > were not adopted, they should be clarified. In general for rfc2473, > there I see so far no zero reason to have some other text here, as > opposed to errata. Same for NAT44 really. > > Then again, perhaps the draft should be interpreted as an RFP of some > kind, which it actually reads a lot like. In which case it should not be > a standard track document. > > >> - Clarification of WAN selection or assumptions > > [Qi] I think Ian has expressed cleared in previous mails. > > > > Woj>Please see my reply to Ian - looking forward to an answer in the draft: > --snip-- > So, in terms of the lw46 draft specifying how a CPE is to get to the IP > prefix of "the WAN interface" is an important aspect, or at least > stating the assumptions about this WAN interface. Some obvious questions > apply here: > is the WAN the interface which has the default route? Is it the > interface that has a DHCPv6 client? What if there are multiple such > "WAN" interfaces? What if a single "WAN" has multiple IPv6 prefixes? > What if it has NO global IPv6 prefix? What if it doesn't have a /64 > prefix. etc. > --snip-- > One doesn't see the draft answering any of these at the moment. > > >> >> That said, abundant technical evidence (summarized in previous >> mail) indicates that this mode is in near total overlap with MAP >> 1:1, certainly much more than at the outset of this work. Given >> this, why not align the text and actually make MAP 1:1 and lw46 be >> the same? On all of the data plane IPv6, IPv4, NAT44, tunneling >> and ICMP handling parts I see there no reason for there being a >> difference... > > [Qi] I think lw4o6 is clean and simple, and flexible to work with > different provisioning mechanisms (signaling through the Softwire > DHCP as is agreed by the WG). > > >> >> continued inline... >> >> >> >> >> [ian] The draft already contains the following text (and has >> for some time): >> >> Lightweight 4over6 provides a solution for a hub-and-spoke softwire >> architecture only. It does not offer direct, meshed IPv4 >> connectivity between subscribers without packets traversing the AFTR. >> If this type of meshed interconnectivity is required, >> [I-D.ietf-softwire-map] provides a suitable solution. >> >> So, are you not happy with the wording of the current >> reference, or are you requesting that the draft is rewritten >> to be cast as a ‘specialised' case of MAP? >> >> What I pointed out is that the Lw46 draft has major if near total >> overlap with MAP-E 1:1 mode. Stating that lw46 realizes this mode, >> in a standalone way from the N:1 mesh mode, is what I propose. >> This would greatly help in implementing it and "digesting" the >> array of solutions. > > [Qi] I don't see any "help" here... > > > Woj>To an operator and implementer, it would be very advantageous that > all of IPv4 in IPv6 and NAT44 data plane aspects, as specified by > Softwire drafts are the same, unless it is made clear as to why they > should be different, and what does it bring. This applies especially to > lw46 and MAP, since there is so much overlap between the solutions. > > >> Additional comment Now that you mention it, the stated >> characterisation of map isn't quite right; MAP does not force the >> use of mesh mode, nor is mesh mode its defining characteristic. > > [Qi] From my reading, the text doesn't characterize what MAP is. It > just says "if you want to use meshed IPv4 connectivity, then use > MAP". It doesn't prevent you from using MAP to do anything else. So > I think the text is OK. > > > Woj> Well, that is "characterisation". From dictionary: "The act of > describing the character or qualities of someone or something" > And as stated, it is not quite correct, i.e. mesh-mode is not the > defining feature of MAP. The state optimization (stateless) is, of which > mesh mode is a by product (optional actually in the spec). The text > needs to be changed. > > >> The characterisation should be restated as " lw46 does not seek to >> offer the optimization of AFTR subscriber state and the AFTR is >> expected to have configuration state for each lwB4 node. If >> optimization of this state is required, [id-ietf-softwire-map] >> provides a suitable solution ". >> Alternatively, state that "lw46 describes a >> deployment/implementation of MAP 1:1" >>> >>> >>>> >>>> Detailed comments: >>>> >>>> * Section 5.1 WAN prefix selection and address forming - >>>> as per Ole's comment. This is indeed hand wavy in the >>>> current draft (how to select the WAN?) >>>> >>>> [ian] I’ve updated with the wording that I proposed to Ole. >>>> >>>> The CPE WAN interface is a fairly well used term in a >>>> number of other RFCs. Both RFC6333 and RFC7084 use the >>>> term (and have implementations based on them) without >>>> defining how the CPE has identified it. Why does that >>>> need to be specifically defined here? >>>> >>>> >>>> Woj> What is the WAN interface is, and how should the CPE >>>> "find it" not said. That other drafts fail to clarify that >>>> doesn't make it quite right… >>> >>> >>> [ian] No, this is related to fragmentation in respect to the >>> RFC1858 'Tiny Fragment attack' which affects the IPv4 >>> payload. The same problems exist for the lwB4s NAT44 function >>> as exist for a NAT64 in this respect, which is why it was >>> included. >>> >>> >>> Woj> Ok, but what does "MAY require" mean, and how should a >>> device go about requiring it? >> > [Qi] Please see page 18 of RFC6146: > > * The NAT64 MAY require that the UDP, TCP, or ICMP header be > completely contained within the fragment that contains > fragment > offset equal to zero. > > > Woj> Well, that text as you point comes from NAT64, and concerns IPv6 > header chain to IPv4 header "fitting". In lwB4, unless I misunderstand, > the only fragmentation there may be is that of IPv4 that would be driven > by an IPv4 MTU < 40 (violation of IPv4 min MTU 68). So what exactly the > draft is requiring here isn't clear. > In any case the fragmentation behaviour is not something specific to > lw46, so it would be best if you pointed the draft at the source. > > >>> >>> >>> * Section 5.2: Text: >>> >>> For incoming de-capsulated IPv4 packets carrying UDP packets with a >>> >>> zero checksum, if the lwB4 has enough resources, the lwB4 MUST >>> >>> reassemble the packets and MUST calculate the checksum. If the lwB4 >>> >>> does not have enough resources, then it MUST silently discard the >>> >>> packets. >>> >>> Wouldn't it be easier to say that the lwb4 MAY reassemble >>> the packet and recalculate the checksum? It's clearly not >>> a MUST... >>> >>> [ian] Why is it not a MUST? If one condition is met you >>> MUST do this, if a different condition is met, you MUST >>> do that. A MAY would make re-assembly of the packets >>> optional, meaning that an implementation could not >>> implement support for fragment reassembly at all and >>> still say that it is compliant with the spec. >>> >>> >>> If it were a MUST then something would horribly break if it >>> were not done. The above clearly says that this reassembly >>> operation is at the discretion of the device, subject to an >>> arbitrary "enough resources" condition. If you'd like it to >>> be a MUST then the condition should be removed. >> >> [ian] Then surely re-assembly is a SHOULD requirement, with a >> a MUST to discard if cannot be re-assembled. As I said, if it >> was a MAY requirement, then implementation would be completely >> optional. >> >> >> Woj> Yes, and that's what the above text reads from a test >> perspective, i.e. since one has no way of determining whether >> there are "enough resources", a lwB4 that discards all such >> packets would comply. As I said, if one would like to tighten the >> spec; a) the un-testable "enough resources" condition should be >> removed b) with that either a MUST used, if this is something >> super important, or a SHOULD (as it seems to me). Alternatively a >> MAY as "nice to have" may also do. > > [Qi] I prefer to use a SHOULD for re-asembly and a MUST for > discarding the packet if it cannot be reassembled. > > > Woj> Well, so it's a SHOULD then. Please note: the "enough resources" > condition as is, is un-testable across implementations, so adding such > "dead" text is rather pointless. > > Cheers, > Wojciech. > > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > From nobody Wed Feb 26 01:32:35 2014 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C7351A017F for ; Wed, 26 Feb 2014 01:32:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.204 X-Spam-Level: * X-Spam-Status: No, score=1.204 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547] autolearn=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 Io88JIN1WZ54 for ; Wed, 26 Feb 2014 01:32:14 -0800 (PST) Received: from tcmail33.telekom.de (tcmail33.telekom.de [80.149.113.247]) by ietfa.amsl.com (Postfix) with ESMTP id 1297D1A017C for ; Wed, 26 Feb 2014 01:32:13 -0800 (PST) Received: from he113445.emea1.cds.t-internal.com ([10.134.93.105]) by tcmail31.telekom.de with ESMTP/TLS/AES128-SHA; 26 Feb 2014 10:32:03 +0100 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([169.254.3.21]) by HE113445.emea1.cds.t-internal.com ([::1]) with mapi; Wed, 26 Feb 2014 10:32:03 +0100 From: To: , Date: Wed, 26 Feb 2014 10:31:55 +0100 Thread-Topic: [Softwires] I-D Action: draft-ietf-softwire-lw4over6-06.txt Thread-Index: Ac8y1Zrutu2EjArQRsycRl1DXnO3JQ== Message-ID: References: <20140211075445.17615.61208.idtracker@ietfa.amsl.com> <8A1B81989BCFAE44A22B2B86BF2B76318A2CDB8ED2@HE111643.EMEA1.CDS.T-INTERNAL.COM> In-Reply-To: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 acceptlanguage: en-US, de-DE Content-Type: multipart/alternative; boundary="_000_CF335888AE89Dianfarrertelekomde_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/softwires/vnza82xJ5I88wRT_apXhg7q-LGk Cc: softwires@ietf.org Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-lw4over6-06.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2014 09:32:20 -0000 --_000_CF335888AE89Dianfarrertelekomde_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Woj, I=92ve been out of the office for a couple of days, so sorry for the be lat= e reply. Please see inline. Cheers, Ian From: Wojciech Dec > Date: Wednesday, 19 February 2014 09:34 To: Ian Farrer > Cc: Softwires-wg > Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-lw4over6-06.txt Hi Ian, Just to be clear: I'm ok with lw46 defining a specific functional mode as I= believe it does in this draft, also leaving "as-is" the DHCP part of it (i= .e. it's a capability that can be signalled using the lw46 container, etc). [ian] It would help if you could propose text for what you would like to se= e. The inline discussion has become quite protracted. General items remain open (as commented): - Cleanup text that does not belong to lw46 (eg 2473 fixes, or NAT44 best p= ractice). [ian] The text relating to this was specifically requested, discussed and a= greed during the WGLC. It would be better to pick up the discussion on that= thread and then document the outcome (It starts with: http://www.ietf.org/= mail-archive/web/softwires/current/msg05786.html) - Clarification of WAN selection or assumptions [ian] Again, the text was previously discussed and agreed as part of the WG= LC. Can you pick up the discussion at http://www.ietf.org/mail-archive/web/= softwires/current/msg05792.html That said, abundant technical evidence (summarized in previous mail) indica= tes that this mode is in near total overlap with MAP 1:1, certainly much mo= re than at the outset of this work. Given this, why not align the text and = actually make MAP 1:1 and lw46 be the same? On all of the data plane IPv6, = IPv4, NAT44, tunneling and ICMP handling parts I see there no reason for th= ere being a difference... [ian] Let=92s discuss this based on your proposed text changes. continued inline... Detailed comments: * Section 5.1 WAN prefix selection and address forming - as per Ole's comme= nt. This is indeed hand wavy in the current draft (how to select the WAN?) [ian] I=92ve updated with the wording that I proposed to Ole. The CPE WAN interface is a fairly well used term in a number of other RFCs.= Both RFC6333 and RFC7084 use the term (and have implementations based on t= hem) without defining how the CPE has identified it. Why does that need to = be specifically defined here? Woj> What is the WAN interface is, and how should the CPE "find it" not sa= id. That other drafts fail to clarify that doesn't make it quite right=85 [ian] This is entirely implementation specific and something that hasn=92t = stopped millions of CPEs being built and deployed that support both RFC6333= and RFC7084 (n=E9 RFC6204). What=92s the problem that you are trying to so= lve? Woj> None of those texts attempt to create a deterministic ip interface, an= d in case of 6333 that is a known operational issue. So, in terms of the lw= 46 draft specifying how a CPE is to get to the IP prefix of "the WAN inter= face" is an important aspect, or at least stating the assumptions about thi= s WAN interface. Some obvious questions apply here: is the WAN the interface which has the default route? Is it the interface t= hat has a DHCPv6 client? What if there are multiple such "WAN" interfaces? = What if a single "WAN" has multiple IPv6 prefixes? What if it has NO global= IPv6 prefix? What if it doesn't have a /64 prefix. etc. Coincidentally, all of the latter are options allowed for by RFC7084. [ian] Discussed above. * Processing of IPv4 fragments Section 5.2. Text " The lwB4 MAY require tha= t the UDP, TCP, or ICMP header be completely contained within the fragment = that contains fragment offset equal to zero." What does that mean? Is it trying to say that the IPv4 MTU > 40? [ian] The text is taken directly from RFC6146. I guess that doesn=92t speci= fy is as a defined MTU size of > 40 bytes (or anything else) as the IPv4 he= ader could feasibly be longer than 20 bytes if options were included in it,= so the fragmented L4 header problem could still exist. Here we're talking about tunneling, and I cannot see a case whereby the IPv= 4 TCP/UDP header would get fragmented, unless the MTU of the IPv6 tunnel wa= s <40. rfc6146 is about translation where other effects come to apply. [ian] No, this is related to fragmentation in respect to the RFC1858 'Tiny = Fragment attack' which affects the IPv4 payload. The same problems exist f= or the lwB4s NAT44 function as exist for a NAT64 in this respect, which is = why it was included. Woj> Ok, but what does "MAY require" mean, and how should a device go about= requiring it? [ian] 'MAY require' is a suggested possible solution which the CPE could im= plement: If there is not a complete L4 header in the first fragment, then i= t=92s discarded. Implement it if you want to, don=92t if you don=92t (I.e. = a MAY requirement). I=92m really not sure what=92s not clear here. Section 5.2: " For incoming packets carrying TCP or UDP IPv4 fragments with a non- zero checksum, after de-capsulation, the lwB4 MAY elect to queue the fragments as they arrive and perform NAPT44 on all fragments at the same time" ?? Queue based on what? Presumably the fragment identifier field, and if so= then that is no different to 2473. [ian] Updated the text to note that. Ok, but in essence, it would be actually better removing the text since it = adds nothing above 2473. [ian] The text in the current version reads: For incoming packets carrying TCP or UDP IPv4 fragments with a non- zero checksum, after de-capsulation, the lwB4 MAY elect to queue the fragments as they arrive and perform NAPT44 on all fragments at the same time. In this case, the incoming 5-tuple is determined by extracting the appropriate fields from the received packet, as described in [RFC2473]. Alternatively, a lwB4 MAY translate the de- capsulated fragments as they arrive, by storing information that allows it to compute the 5-tuple for fragments other than the first. In the context of the above, is this a problem? Woj> Well, what strikes me is that the above text does not bring in anythin= g other than what's already in 2473 for IPinIP fragementation and [RFC5508= ], and [RFC5382] for NAT. The text should refer to those documents, or fil= e errata. In other words, IPv4inIPv6 fragments and handling of IPv4 fragmen= ts with NAT44 is not a lwB4 specific function, and is already well document= ed. [ian] What=92s being added here is the translation of packets as they arriv= e, instead of queuing, re-assembing, then NATing as-per RFC2743. This is no= t documented anywhere for NAT44 (to my knowledge), only for NAT64. This is not saying that RFC2473 is incorrect, it=92s saying that there coul= d be another alternative. * Section 5.2: Text: For incoming de-capsulated IPv4 packets carrying UDP packets with a zero checksum, if the lwB4 has enough resources, the lwB4 MUST reassemble the packets and MUST calculate the checksum. If the lwB4 does not have enough resources, then it MUST silently discard the packets. Wouldn't it be easier to say that the lwb4 MAY reassemble the packet and re= calculate the checksum? It's clearly not a MUST... [ian] Why is it not a MUST? If one condition is met you MUST do this, if a = different condition is met, you MUST do that. A MAY would make re-assembly = of the packets optional, meaning that an implementation could not implement= support for fragment reassembly at all and still say that it is compliant = with the spec. If it were a MUST then something would horribly break if it were not done. = The above clearly says that this reassembly operation is at the discretion = of the device, subject to an arbitrary "enough resources" condition. If yo= u'd like it to be a MUST then the condition should be removed. [ian] Then surely re-assembly is a SHOULD requirement, with a a MUST to dis= card if cannot be re-assembled. As I said, if it was a MAY requirement, the= n implementation would be completely optional. Woj> Yes, and that's what the above text reads from a test perspective, i.e= . since one has no way of determining whether there are "enough resources",= a lwB4 that discards all such packets would comply. As I said, if one woul= d like to tighten the spec; a) the un-testable "enough resources" condition= should be removed b) with that either a MUST used, if this is something su= per important, or a SHOULD (as it seems to me). Alternatively a MAY as "nic= e to have" may also do. [ian] How is =91enough resources=92 untestable? Earlier in the section, it = already specifically states that the amount of resources allocated for frag= mented packets must be limited. The amour of a fixed fragment buffer in use= or number of fragments in a fixed sized queue are perfectly testable. >From a customers perspective, if I tested an implementation that discarded = all such fragmented packets in all conditions, then the implementation is n= ot compliant. Regardless, if we can agree that the lwB4 SHOULD re-assemble if it can and = discard if it can=92t, then I=92ll modify the paragraph to that effect. Cheers, Wojciech. --_000_CF335888AE89Dianfarrertelekomde_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hi Woj,

I=92ve been out of the office for a couple of days= , so sorry for the be late reply.

Pl= ease see inline.

Cheers,
Ian

From: Wojciech Dec <wdec.ietf@gmail.com>
Date: Wednesday, 19 February 2014 09:34
= To: Ian Farrer <ianfarrer@g= mx.com>
Cc: Softwires-wg= <softwires@ietf.org>
Subject: Re: [Softwires] I-D Action:= draft-ietf-softwire-lw4over6-06.txt

Hi Ian,

Just to be clear: I'm ok with lw46 defining a specific functional mode as I= believe it does in this draft, also leaving "as-is" the DHCP par= t of it (i.e. it's a capability that can be signalled using the lw46 contai= ner, etc).

[ian] It would help if you could propose text for what y= ou would like to see. The inline discussion has become quite protracted.&nb= sp;

General items remain open (as commented):
- Cleanup text that does not belong to lw46 (eg 2473 fixes, or NAT44 best p= ractice).

[ian] The text relating to this was specifically re= quested, discussed and agreed during the WGLC. It would be better to pick u= p the discussion on that thread and then document the outcome (It starts wi= th: http://www.ietf.org/mail-archive/web/softwires/current/msg05786.html)
<= /div>

- Clarification of WAN selection or assumptions

[ian] Again, the text was previously discussed and a= greed as part of the WGLC. Can you pick up the discussion at http://www.ietf.org/mail-archive/web/softwires/current/msg05792.html
=

That said, abundant technical evidence (summarized in previous mail) indica= tes that this mode is in near total overlap with MAP 1:1, certainly much mo= re than at the outset of this work. Given this, why not align the text and = actually make MAP 1:1 and lw46 be the same? On all of the data plane IPv6, IPv4, NAT44, tunneling and ICMP h= andling parts I see there no reason for there being a difference...

[ian] Let=92s disc= uss this based on your proposed text changes.


=
continued inline...


 
=
=

Detailed comments:

* Section 5.1 WAN prefix selection and address forming - as per Ole's comme= nt. This is indeed hand wavy in the current draft (how to selec= t the WAN?)

[ian] I=92ve updated= with the wording that I proposed to Ole.

The CPE WAN interface is a fairly well used term in= a number of other RFCs. Both RFC6333 and RFC7084 use the term (and have im= plementations based on them) without defining how the CPE has identified it. Why does that need to be specifica= lly defined here?


Woj>  What is the WAN interface is, and how should the CPE "= ;find it" not said. That other drafts fail to clarify that doesn't mak= e it quite right=85
[ian] This is entirely implementation specific and= something that hasn=92t stopped millions of CPEs being built and depl= oyed that support both RFC6333 and RFC7084 (n=E9 RFC6204). What=92s the problem that you are trying to solve?
<= /div>

Woj> None of those texts attempt t= o create a deterministic ip interface, and in case of 6333 that is a known = operational issue. So, in terms of the lw46 draft specifying how a CPE is t= o get to the IP prefix of  "the WAN interface" is an importa= nt aspect, or at least stating the assumptions about this WAN interface. Some obvious= questions apply here:
is the WAN the interface which has the default route? Is it the interface t= hat has a DHCPv6 client? What if there are multiple such "WAN" in= terfaces? What if a single "WAN" has multiple IPv6 prefixes? What= if it has NO global IPv6 prefix? What if it doesn't have a /64 prefix. etc.

Coincidentally, all of the latter are options allowed for by RFC7084.
=

[ian] Discussed above.

 <= /div>

<= span lang=3D"EN-GB">* Processing of IPv4 fragments Section 5.2. = Text " The lwB4 MAY require that the UDP, TCP, or ICMP h= eader be completely contained within the fragment that contains fragment of= fset equal to zero."

What does that mean? Is it trying to say that the IPv4 MTU > 40?=

 

[ian] The text is taken directly from RFC6146. I guess that doesn=92t sp= ecify is as a defined MTU size of > 40 bytes (or anything else) as the I= Pv4 header could feasibly be longer than 20 bytes if options were included in it, so the fragmented = L4 header problem could still exist.


=
Here we're talking about tunneling, and I cannot see a case wher= eby the IPv4 TCP/UDP header would get fragmented, unless the MTU of the IPv= 6 tunnel was <40. rfc6146 is about translation where other effects come = to apply.

[ian] No, this is related to fragmentation in respect = to the RFC1858 'Tiny Fragment attack' which affects  the IPv4 payload.= The same problems exist for the lwB4s NAT44 function as exist for a NAT64 in this respect, which is why it was included.=

Woj> Ok, but what= does "MAY require" mean, and how should a device go about requir= ing it?


 <= /p>

Section 5.2: "

Fo=
r incoming packets carrying TCP or UDP IPv4 fragments with a non-=

   zero checksum, after de-capsulation, the lwB4 M=
AY elect to queue the
   fragments as the=
y arrive and perform NAPT44 on all fragments at the
   same time"
?? Queue based on wha=
t? Presumably the fragment identifier field, and if so then that is no diff=
erent to 2473.
 

[ian] Update= d the text to note that.


<= /div>
Ok, but in essence, it would be actually better removing the text= since it adds nothing above 2473. 
=

[ian] The text in the current version reads:

For incoming packets carrying TCP or UDP IPv4 fragments with a non- zero checksum, after de-capsulation, the lwB4 MAY elect to queue the fragments as they arrive and perform NAPT44 on all fragments at the same time. In this case, the incoming 5-tuple is determined by extracting the appropriate fields from the received packet, as described in [RFC2473]. Alternatively, a lwB4 MAY translate the de- capsulated fragments as they arrive, by storing information that allows it to compute the 5-tuple for fragments other than the first.
In the context of the above, is this a problem?

Woj> Well, what str= ikes me is that the above text does not bring in anything other than what's= already in 2473 for IPinIP fragementation and  [RFC5508], and  [= RFC5382] for NAT. The text should refer to those documents, or file errata.= In other words, IPv4inIPv6 fragments and handling of IPv4 fragments with NAT44 is not a lwB4 specific= function, and is already well documented.

[= ian] What=92s being added here is the translation of packets as they arrive= , instead of queuing, re-assembing, then NATing as-per RFC2743. This is not= documented anywhere for NAT44 (to my knowledge), only for NAT64.

This is not saying that RFC2473 is incor= rect, it=92s saying that there could be another alternative.

&nbs= p;

<= pre> 

* Section 5.2: Text:

For incomi=
ng de-capsulated IPv4 packets carrying UDP packets with a
   zero checksum, if the lwB4 has enough resources, the lw=
B4 MUST
   reassemble the packets and MUS=
T calculate the checksum.  If the lwB4
 &=
nbsp; does not have enough resources, then it MUST silently discard the<=
/u>
   packets.  
Wouldn't it be easier to say that the lwb4 MAY reassemble =
the packet and recalculate the checksum? It's clearly not a MUST...<=
u>

 

[ian] Why is it not a MUST? If one condition is met you MUST do this, = if a different condition is met, you MUST do that. A MAY would make re-asse= mbly of the packets optional, meaning that an implementation could not implement support for f= ragment reassembly at all and still say that it is compliant with the spec.=


If it we= re a MUST then something would horribly break if it were not done. The abov= e clearly says that this reassembly operation is at the discretion of the d= evice,  subject to an arbitrary "enough resources" condition= . If you'd like it to be a MUST then the condition should be removed.

[ian] Then surely re-assembly is a SHOULD re= quirement, with a a MUST to discard if cannot be re-assembled. As I said, i= f it was a MAY requirement, then implementation would be completely optiona= l. 

Woj> Yes,= and that's what the above text reads from a test perspective, i.e. since o= ne has no way of determining whether there are "enough resources"= , a lwB4 that discards all such packets would comply. As I said, if one wou= ld like to tighten the spec; a) the un-testable "enough resources" condition should be remove= d b) with that either a MUST used, if this is something super important, or= a SHOULD (as it seems to me). Alternatively a MAY as "nice to have&qu= ot; may also do.

=
[ian] = How is =91enough resources=92 untestable? Earlier in the section,= it already specifically states that the amount of resources allo= cated for fragmented packets must be limited. The amour of a fixed fra= gment buffer in use or number of fragments in a fixed sized queue are perfe= ctly testable.

From a customers perspective, if I t= ested an implementation that discarded all such fragmented packets in all c= onditions, then the implementation is not compliant.

Reg= ardless, if we can agree that the lwB4 SHOULD re-assemble if it can and dis= card if it can=92t, then I=92ll modify the paragraph to that effect.&n= bsp;


Cheers,
Wojciech.

 --_000_CF335888AE89Dianfarrertelekomde_-- From nobody Wed Feb 26 02:12:40 2014 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F48D1A01CF for ; Wed, 26 Feb 2014 02:12:34 -0800 (PST) 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 L8FFf8AC1CBT for ; Wed, 26 Feb 2014 02:12:31 -0800 (PST) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id A1F301A01EC for ; Wed, 26 Feb 2014 02:12:31 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id bj1so779379pad.17 for ; Wed, 26 Feb 2014 02:12:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ltzgAHfilWHWhK4+vzqQRxojVQBrOfFxhmzWN+DbyrE=; b=tjD1sUwxuIYi/+va9O9by6u0IJUsiuLizRmXLInB+5kD5g9nA+IP0l6nC9HR02cufN DDtD8NAx8r8Ut/BehflKknrzQEThSErtyrJNALTHHoDmBSQRrcj/yU13zEqPNncEaOFH VGR87eAjZa7j/taku4LU+cz4CQ2utFtzc1ul7nrP5JhzRBT/n6as+sjNbN3l6bGt4g08 eBnmlQD2OHdXVeuelgMkbqinNNt8Feh9FJFmxEaK5KUKFoEYRdM3b3i8SMkEmfz1jxZX C8hQFheHRNSi76GbDmcJV5vgA9qddjqpxIscNviveETF1Rp/Lu2pBSXQMUPLyW3XhITB R6ig== MIME-Version: 1.0 X-Received: by 10.66.26.15 with SMTP id h15mr6814878pag.24.1393409550621; Wed, 26 Feb 2014 02:12:30 -0800 (PST) Received: by 10.70.1.70 with HTTP; Wed, 26 Feb 2014 02:12:30 -0800 (PST) In-Reply-To: References: <20140211075445.17615.61208.idtracker@ietfa.amsl.com> <8A1B81989BCFAE44A22B2B86BF2B76318A2CDB8ED2@HE111643.EMEA1.CDS.T-INTERNAL.COM> <530CDF3D.3030908@gmail.com> Date: Wed, 26 Feb 2014 11:12:30 +0100 Message-ID: From: Wojciech Dec To: Ted Lemon Content-Type: multipart/alternative; boundary=bcaec529944b4aa22104f34c716b Archived-At: http://mailarchive.ietf.org/arch/msg/softwires/v0KEKG-0uzt7zlCua-UEUPNHiQg Cc: Softwires WG Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-lw4over6-06.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2014 10:12:34 -0000 --bcaec529944b4aa22104f34c716b Content-Type: text/plain; charset=ISO-8859-1 Ted, May I kindly ask that you read my comments before starting apparently rhetorical discussions of the type that I didn't intend, and that do not progress things? In summary: I said that having a lw46 draft/solution is fine, but it is clear that there is significant technical overlap between the two (use of PSID w/ MAP algorithm, IP address embedding, NAT44 port sharing). At this stage it doesn't matter how it came to be that we have two solutions+ (personally I believe that it was a case of WG leadership gone totally wrong at the time). What matters is that it is readily apparent that any divergences in the area of IP tunneling and ICMP handling are not warranted - or if they are, then the draft doesn't clarifyr why that is so. What also matters is to make this clear to implementers. Yes, I do belive that people outside of this WG will be interested to implement devices that cover both solutions and minimize the work in doing so, which doesn't take away from them the ability to do just one. As a separate set of feedback points, a number of requirements in the lw46 draft do not appear to belong there (e.g they restate, selectively, NAT44 best practices). The WAN IP address selection appears either a) broken (e.g author's didn't answer how to configure the IPv6 address in case of multiple prefixes, or if the WAN interface doesn't have a global IPv6 prefix) or b) limited to a specific deployment. This needs to be clarified. On 25 February 2014 19:29, Ted Lemon wrote: > On Feb 25, 2014, at 1:21 PM, Tom Taylor wrote: > > I know this is a political rather than a technical point, but one could > sort of reverse the claim and suggest that if 1:1 mode is desired, LW4o6 is > the better way to go. > > Indeed, if all one needs is 1:1, one might prefer lw4over6 since it only > has the one mode. > > --bcaec529944b4aa22104f34c716b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Ted,
May I kindly ask that you read my comments be= fore starting apparently rhetorical discussions of the type that I didn'= ;t intend, and that do not progress things?

In summary: I said that= having a lw46 draft/solution is fine, but it is clear that there is signif= icant technical overlap between the two (use of PSID w/ MAP algorithm, IP a= ddress embedding, NAT44 port sharing). At this stage it doesn't matter = how it came to be that we have two solutions+ (personally I believe that it= was a case of WG leadership gone totally wrong at the time).

What matters is that it is readily apparent that any divergences in the= area of IP tunneling and ICMP handling are not warranted - or if they are,= then the draft doesn't clarifyr why that is so. What also matters is t= o make this clear to implementers. Yes, I do belive that people outside of = this WG will be interested to implement devices that cover both solutions a= nd minimize the work in doing so, which doesn't take away from them the= ability to do just one.

As a separate set of feedback points, a number of requ= irements in the lw46 draft do not appear to belong there (e.g they restate,= selectively, NAT44 best practices). The WAN IP address selection appears e= ither a) broken (e.g author's didn't answer how to configure the IP= v6 address in case of multiple prefixes, or if the WAN interface doesn'= t have a global IPv6 prefix) or b) limited to a specific deployment. This n= eeds to be clarified.


On 25 F= ebruary 2014 19:29, Ted Lemon <ted.lemon@nominum.com> wr= ote:
On Feb 25, 2014, at 1:21 PM,= Tom Taylor <tom.taylor.std= s@gmail.com> wrote:
> I know this is a political rather than a technical point, but one coul= d sort of reverse the claim and suggest that if 1:1 mode is desired, LW4o6 = is the better way to go.

Indeed, if all one needs is 1:1, one might prefer lw4over6 since it o= nly has the one mode.


--bcaec529944b4aa22104f34c716b-- From nobody Wed Feb 26 03:05:54 2014 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 333331A0244 for ; Wed, 26 Feb 2014 03:05:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.301 X-Spam-Level: * X-Spam-Status: No, score=1.301 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, SPF_PASS=-0.001] autolearn=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 k1zoE_pmG-BL for ; Wed, 26 Feb 2014 03:05:42 -0800 (PST) Received: from mail-pb0-x22e.google.com (mail-pb0-x22e.google.com [IPv6:2607:f8b0:400e:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 330AE1A0239 for ; Wed, 26 Feb 2014 03:05:42 -0800 (PST) Received: by mail-pb0-f46.google.com with SMTP id um1so850381pbc.33 for ; Wed, 26 Feb 2014 03:05:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=GGGtuAcyCbbTlUa5cNvO3ZhqS2c/esQ2PCj7dgtAtpM=; b=Kij6Mo38fZ0tLQW3YH17yaIZ3aLxTRj8MhPCKB314bRDn2UloSS03SaSgeX36NXCsB PHVAsGuLLXWh7byUmQMCMNT92EX2DmLOFDmp6t1idxkwRJO8MlmomUQQLtyicIDY+Roh l5Ox3YydwvyaBr3Khtk0ynYMqXL9258mnUieYN9deztnnRB+aJeNbycx5SP8JtmrLWZd RAn27ekR9Abv8cqkATQ6DJPTuXZds27FLPBlQPQyNLAjEgZPI6+O0a6AKYCf8btd3sg3 Bvd84RHT050JQ4Tbm/h2wqBXj3bNdWEr7R3psUwsTMKFbugSQwaz77C22MJL0ElW3rjS cQfA== MIME-Version: 1.0 X-Received: by 10.66.25.203 with SMTP id e11mr7724497pag.76.1393412741049; Wed, 26 Feb 2014 03:05:41 -0800 (PST) Received: by 10.70.1.70 with HTTP; Wed, 26 Feb 2014 03:05:40 -0800 (PST) In-Reply-To: References: <20140211075445.17615.61208.idtracker@ietfa.amsl.com> <8A1B81989BCFAE44A22B2B86BF2B76318A2CDB8ED2@HE111643.EMEA1.CDS.T-INTERNAL.COM> Date: Wed, 26 Feb 2014 12:05:40 +0100 Message-ID: From: Wojciech Dec To: "ian.farrer@telekom.de" Content-Type: multipart/alternative; boundary=bcaec5299c4d74b47804f34d2f14 Archived-At: http://mailarchive.ietf.org/arch/msg/softwires/F9UPI11F4g2ukvoW0CCLo6hxc5c Cc: Softwires-wg Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-lw4over6-06.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2014 11:05:47 -0000 --bcaec5299c4d74b47804f34d2f14 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Ian, inline.. On 26 February 2014 10:31, wrote: > Hi Woj, > > I've been out of the office for a couple of days, so sorry for the be lat= e > reply. > > Please see inline. > > Cheers, > Ian > > From: Wojciech Dec > Date: Wednesday, 19 February 2014 09:34 > To: Ian Farrer > Cc: Softwires-wg > Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-lw4over6-06.txt > > Hi Ian, > > Just to be clear: I'm ok with lw46 defining a specific functional mode as > I believe it does in this draft, also leaving "as-is" the DHCP part of it > (i.e. it's a capability that can be signalled using the lw46 container, > etc). > > [ian] It would help if you could propose text for what you would like to > see. The inline discussion has become quite protracted. > I'll follow up on that... > > General items remain open (as commented): > - Cleanup text that does not belong to lw46 (eg 2473 fixes, or NAT44 best > practice). > > [ian] The text relating to this was specifically requested, discussed and > agreed during the WGLC. It would be better to pick up the discussion on > that thread and then document the outcome (It starts with: > http://www.ietf.org/mail-archive/web/softwires/current/msg05786.html) > Please view my comments as part of the WGLC... The key point is that IP tunnel fragementation handling and NAT44 best practices have abundant and much better specificaion. Thus instead of adding text here, please remove it and defer to the authoritative drafts in that space or clarify what are the differences (and why). Suggested text: The NAT44 in the lwB4 MUST implement the behavior for ICMP message conforming to the best current practice documented in [RFC5508 ]. If a LwB4 receives an ICMP error message without the ICMP identifier field for errors that is detected inside a IPv6 tunnel, the node should relay the ICMP error message to the original source. This behavior SHOULD be implemented conforming to the section 8 of [RFC2473] . FOr TCP and UDP traffic the NAT44 implemented in the LwB4 SHOULD conform with the behavior and best current practice documented in [RFC4787 ], [RFC5508 ], and [RFC5382 ]. > - Clarification of WAN selection or assumptions > > [ian] Again, the text was previously discussed and agreed as part of the > WGLC. Can you pick up the discussion at > http://www.ietf.org/mail-archive/web/softwires/current/msg05792.html > Well, so the text from the above discussion does not appear in the draft. What more however is that the text does not describe how a case of a WAN without a global IPv6 prefix is to be handled (is that also invalid - please state so in the draft). Other cases: - What is the WAN doesn't have a /64? - What if there are multiple WAN interfaces? If these are all invalid w/ lw46 - then please state so. > That said, abundant technical evidence (summarized in previous mail) > indicates that this mode is in near total overlap with MAP 1:1, certainly > much more than at the outset of this work. Given this, why not align the > text and actually make MAP 1:1 and lw46 be the same? On all of the data > plane IPv6, IPv4, NAT44, tunneling and ICMP handling parts I see there no > reason for there being a difference... > > [ian] Let's discuss this based on your proposed text changes. > > > continued inline... > > > > >> >>> Detailed comments: >>> >>> * Section 5.1 WAN prefix selection and address forming - as per Ole's >>> comment. This is indeed hand wavy in the current draft (how to select >>> the WAN?) >>> >>> [ian] I've updated with the wording that I proposed to Ole. >>> >>> The CPE WAN interface is a fairly well used term in a number of other >>> RFCs. Both RFC6333 and RFC7084 use the term (and have implementations b= ased >>> on them) without defining how the CPE has identified it. Why does that = need >>> to be specifically defined here? >>> >> >> Woj> What is the WAN interface is, and how should the CPE "find it" not >> said. That other drafts fail to clarify that doesn't make it quite right= ... >> >> >> [ian] This is entirely implementation specific and something that hasn't >> stopped millions of CPEs being built and deployed that support both RFC6= 333 >> and RFC7084 (n=E9 RFC6204). What's the problem that you are trying to so= lve? >> > > Woj> None of those texts attempt to create a deterministic ip interface, > and in case of 6333 that is a known operational issue. So, in terms of th= e > lw46 draft specifying how a CPE is to get to the IP prefix of "the WAN > interface" is an important aspect, or at least stating the assumptions > about this WAN interface. Some obvious questions apply here: > is the WAN the interface which has the default route? Is it the interface > that has a DHCPv6 client? What if there are multiple such "WAN" interface= s? > What if a single "WAN" has multiple IPv6 prefixes? What if it has NO glob= al > IPv6 prefix? What if it doesn't have a /64 prefix. etc. > > Coincidentally, all of the latter are options allowed for by RFC7084. > > [ian] Discussed above. > > > >> >> * Processing of IPv4 fragments Section 5.2. Text " The lwB4 MAY require >>> that the UDP, TCP, or ICMP header be completely contained within the >>> fragment that contains fragment offset equal to zero." >>> >>> What does that mean? Is it trying to say that the IPv4 MTU > 40? >>> >>> >>> >>> [ian] The text is taken directly from RFC6146. I guess that doesn't >>> specify is as a defined MTU size of > 40 bytes (or anything else) as th= e >>> IPv4 header could feasibly be longer than 20 bytes if options were incl= uded >>> in it, so the fragmented L4 header problem could still exist. >>> >> >> Here we're talking about tunneling, and I cannot see a case whereby the >> IPv4 TCP/UDP header would get fragmented, unless the MTU of the IPv6 tun= nel >> was <40. rfc6146 is about translation where other effects come to apply. >> >> >> [ian] No, this is related to fragmentation in respect to the RFC1858 >> 'Tiny Fragment attack' which affects the IPv4 payload. The same problem= s >> exist for the lwB4s NAT44 function as exist for a NAT64 in this respect, >> which is why it was included. >> > > Woj> Ok, but what does "MAY require" mean, and how should a device go > about requiring it? > > [ian] 'MAY require' is a suggested possible solution which the CPE could > implement: If there is not a complete L4 header in the first fragment, th= en > it's discarded. Implement it if you want to, don't if you don't (I.e. a M= AY > requirement). I'm really not sure what's not clear here. > The lwB4 cannot require anything is the point here: Instead the draft could require the lwB4 to have some functionality. In this case, what is it? Otherwise it appears to be a dead/null requirement here (That is a tell tale characteristic of MAY requirements in general). So, the draft can either a) remove it b) state the functionality that is needed (and here I don't get it, because tiny fragments are not a lw46 specific thing, and you can readily refer to existing specs on the matter which surely also provide other valuable additions , eg 5508. If the functionality is not in that text, then file an errata, rather than re-creating some sub-text here. > > >>> >>> Section 5.2: " >>> >>> For incoming packets carrying TCP or UDP IPv4 fragments with a non- >>> >>> zero checksum, after de-capsulation, the lwB4 MAY elect to queue the >>> >>> fragments as they arrive and perform NAPT44 on all fragments at the >>> >>> same time" >>> >>> ?? Queue based on what? Presumably the fragment identifier field, and i= f so then that is no different to 2473. >>> >>> >>> >>> [ian] Updated the text to note that. >>> >> >> Ok, but in essence, it would be actually better removing the text since >> it adds nothing above 2473. >> >> >> [ian] The text in the current version reads: >> >> For incoming packets carrying TCP or UDP IPv4 fragments with a non- >> zero checksum, after de-capsulation, the lwB4 MAY elect to queue the >> fragments as they arrive and perform NAPT44 on all fragments at the >> same time. In this case, the incoming 5-tuple is determined by >> extracting the appropriate fields from the received packet, as >> described in [RFC2473]. Alternatively, a lwB4 MAY translate the de- >> capsulated fragments as they arrive, by storing information that >> allows it to compute the 5-tuple for fragments other than the first. >> >> In the context of the above, is this a problem? >> > > Woj> Well, what strikes me is that the above text does not bring in > anything other than what's already in 2473 for IPinIP fragementation and > [RFC5508], and [RFC5382] for NAT. The text should refer to those > documents, or file errata. In other words, IPv4inIPv6 fragments and > handling of IPv4 fragments with NAT44 is not a lwB4 specific function, an= d > is already well documented. > > [ian] What's being added here is the translation of packets as they > arrive, instead of queuing, re-assembing, then NATing as-per RFC2743. Thi= s > is not documented anywhere for NAT44 (to my knowledge), only for NAT64. > It is documented in RFC 4787 section 11... > This is not saying that RFC2473 is incorrect, it's saying that there coul= d > be another alternative. > > > >> >> >>> >>> * Section 5.2: Text: >>> >>> For incoming de-capsulated IPv4 packets carrying UDP packets with a >>> >>> zero checksum, if the lwB4 has enough resources, the lwB4 MUST >>> >>> reassemble the packets and MUST calculate the checksum. If the lwB4 >>> >>> does not have enough resources, then it MUST silently discard the >>> >>> packets. >>> >>> Wouldn't it be easier to say that the lwb4 MAY reassemble the packet an= d >>> recalculate the checksum? It's clearly not a MUST... >>> >>> >>> >>> [ian] Why is it not a MUST? If one condition is met you MUST do this, i= f >>> a different condition is met, you MUST do that. A MAY would make >>> re-assembly of the packets optional, meaning that an implementation cou= ld >>> not implement support for fragment reassembly at all and still say that= it >>> is compliant with the spec. >>> >> >> If it were a MUST then something would horribly break if it were not >> done. The above clearly says that this reassembly operation is at the >> discretion of the device, subject to an arbitrary "enough resources" >> condition. If you'd like it to be a MUST then the condition should be >> removed. >> >> >> [ian] Then surely re-assembly is a SHOULD requirement, with a a MUST to >> discard if cannot be re-assembled. As I said, if it was a MAY requiremen= t, >> then implementation would be completely optional. >> > > Woj> Yes, and that's what the above text reads from a test perspective, > i.e. since one has no way of determining whether there are "enough > resources", a lwB4 that discards all such packets would comply. As I said= , > if one would like to tighten the spec; a) the un-testable "enough > resources" condition should be removed b) with that either a MUST used, i= f > this is something super important, or a SHOULD (as it seems to me). > Alternatively a MAY as "nice to have" may also do. > > [ian] How is 'enough resources' untestable? Earlier in the section, it > already specifically states that the amount of resources allocated for > fragmented packets must be limited. The amour of a fixed fragment buffer = in > use or number of fragments in a fixed sized queue are perfectly testable. > > From a customers perspective, if I tested an implementation that discarde= d > all such fragmented packets in all conditions, then the implementation is > not compliant. > > Regardless, if we can agree that the lwB4 SHOULD re-assemble if it can an= d > discard if it can't, then I'll modify the paragraph to that effect. > Having done some TDD in a past life, I'll assert that this is not a testable requirement in its current form. One's "resources" are not another's "resources", which is the missing piece here. I'd say that we can agree to just state that lwB4 SHOULD resemble is cleaner. But, deferring to rfc 4878 and friends may be better. Cheers, Wojciech. > > > Cheers, > Wojciech. > > --bcaec5299c4d74b47804f34d2f14 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Ian,

inline..

On 26 February 2014 10:31, &= lt;ian.farrer@te= lekom.de> wrote:
Hi Woj,

I’ve been out of the office for a couple of days, so sorry for the be= late reply.

Please see inline.

Cheers,
Ian

<= /div>
From: Wojciech Dec <wdec.ietf@gmail.com>Date: Wednesday, 19 February 201= 4 09:34
To: Ian Farrer <ianfarrer@gmx.com>
Cc: Softwires-wg <softwires@ietf.org>
Subject: Re: [Softwires] I-D Actio= n: draft-ietf-softwire-lw4over6-06.txt

Hi Ian,

Just to be clear: I'm ok with lw46 defining a specific functional mode = as I believe it does in this draft, also leaving "as-is" the DHCP= part of it (i.e. it's a capability that can be signalled using the lw4= 6 container, etc).

[ian] It would help if you could propose text for what you would like to se= e. The inline discussion has become quite protracted. 

I'll follow up on that...
 <= br>

General items remain open (as commented):
- Cleanup text that does not belong to lw46 (eg 2473 fixes, or NAT44 best p= ractice).

[ian] The text relating to this was specifically requested, discussed and a= greed during the WGLC. It would be better to pick up the discussion on that= thread and then document the outcome (It starts with: http://www.ietf.org/mail-archive/web/softwires/current/msg05786.html)

Suggested text: 
The NAT44 in the lwB4 MU=
ST implement the behavior for ICMP message conforming to the
   best current practice documented in [RFC5=
508]. 
If a LwB4 receives an ICMP error message without the ICMP
   identifier field for errors that is detected inside a IPv6 tunnel, the
   node should relay the ICMP error message to the original source.
   This behavior SHOULD be implemented conforming to the section 8 of
   [RFC2473].
 FOr TCP and UDP traffic the NAT44 implemented in the =
LwB4 SHOULD conform with the behavior
   and best current practice documented in [RFC4787], [RFC5508], and
   [RFC5382].

- Clarification of WAN selection or assumptions

<= /div>
[ian] Again, the text was previ= ously discussed and agreed as part of the WGLC. Can you pick up the discuss= ion at http://www.ietf.org/mail-archive= /web/softwires/current/msg05792.html

Well, so the text from the above dis= cussion does not appear in the draft.
What more however is that the tex= t does not describe how a case of a WAN without a global IPv6 prefix is to = be handled (is that also invalid - please state so in the draft).
Other cases:
- What is the WAN doesn't have a /64?
<= /div>
- What if there are multiple WAN interfaces?

If= these are all invalid w/ lw46 - then please state so.


That said, abundant technical evidence (summarized in previous mail) indica= tes that this mode is in near total overlap with MAP 1:1, certainly much mo= re than at the outset of this work. Given this, why not align the text and = actually make MAP 1:1 and lw46 be the same? On all of the data plane IPv6, IPv4, NAT44, tunneling and ICMP h= andling parts I see there no reason for there being a difference...

[ian] Let’s discuss this based on your proposed text changes.
=


continued inline...


 

Detailed comments:

* Section 5.1 WAN prefix selection and address forming - as per Ole's c= omment. This is indeed hand wavy in the current draft (how to s= elect the WAN?)

<= /span>

[ian] I’ve updated with t= he wording that I proposed to Ole.

The CPE WAN interface is a fairly well used term in a number of = other RFCs. Both RFC6333 and RFC7084 use the term (and have implementations= based on them) without defining how the CPE has identified it. Why does that need to be specifica= lly defined here?


Woj>  What is the WAN interface is, and how should the CPE "= ;find it" not said. That other drafts fail to clarify that doesn't= make it quite right…

[ian] Thi= s is entirely implementation specific and something that hasn’t stopp= ed millions of CPEs being built and deployed that support both RFC6333= and RFC7084 (n=E9 RFC6204). What’s the problem that you are trying to solve?

Woj> None of those texts attem= pt to create a deterministic ip interface, and in case of 6333 that is a kn= own operational issue. So, in terms of the lw46 draft specifying how a CPE = is to get to the IP prefix of  "the WAN interface" is an imp= ortant aspect, or at least stating the assumptions about this WAN interface. Some obvious= questions apply here:
is the WAN the interface which has the default route? Is it the interface t= hat has a DHCPv6 client? What if there are multiple such "WAN" in= terfaces? What if a single "WAN" has multiple IPv6 prefixes? What= if it has NO global IPv6 prefix? What if it doesn't have a /64 prefix. etc.

Coincidentally, all of the latter are options allowed for by RFC7084.
=

[ian] Discussed above.=

 

<= div>

* Processing of = IPv4 fragments Section 5.2. Text " The lwB4 M= AY require that the UDP, TCP, or ICMP header be completely contained within= the fragment that contains fragment offset equal to zero."<= /u>

What does that mean? Is it trying t= o say that the IPv4 MTU > 40?

 <= /p>

[ian] The text is taken directly from RFC6146. I guess that doesn&rsquo= ;t specify is as a defined MTU size of > 40 bytes (or anything else) as = the IPv4 header could feasibly be longer than 20 bytes if options were included in it, so the fragmented = L4 header problem could still exist.


=
Here we're talking about tunneling, and I cannot see a case = whereby the IPv4 TCP/UDP header would get fragmented, unless the MTU of the= IPv6 tunnel was <40. rfc6146 is about translation where other effects c= ome to apply.

[i= an] No, this is related to fragmentation in respect to the RFC1858 'Tin= y Fragment attack' which affects  the IPv4 payload. The same probl= ems exist for the lwB4s NAT44 function as exist for a NAT64 in this respect, which is why it was included.=

Woj> Ok, but what= does "MAY require" mean, and how should a device go about requir= ing it?

[ian] 'MAY require' is a suggested p= ossible solution which the CPE could implement: If there is not a complete = L4 header in the first fragment, then it’s discarded. Implement it if= you want to, don’t if you don’t (I.e. a MAY requirement). &nbs= p;I’m really not sure what’s not clear here.

The lwB4 cannot require anything is = the point here: Instead the draft could require the lwB4 to have some funct= ionality. In this case, what is it?
Otherwise it appears to b= e a dead/null requirement here (That is a tell tale characteristic of MAY r= equirements in general). So, the draft can either a) remove it b) state the= functionality that is needed (and here I don't get it, because tiny fr= agments are not a lw46 specific thing, and you can readily refer to existin= g specs on the matter which surely also provide other valuable additions , = eg 5508. If the functionality is not in that text, then file an errata, rat= her than re-creating some sub-text here.
 

 

Section 5.2: "

For i=
ncoming packets carrying TCP or UDP IPv4 fragments with a non-
   zero checksum, after de-capsulation, the lwB4 MAY =
elect to queue the
   fragments as they arrive and perform NAPT44 on all fragme=
nts at the
   same time"
?? Queue based on what? Presumably the fragment identifier fie=
ld, and if so then that is no different to 2473.
 

[ian] Updated the text to note that.


Ok, but in essence, it wo= uld be actually better removing the text since it adds nothing above 2473.<= span> 

[ian] The text in the current version rea= ds:
For incoming packets carrying TCP or UDP IPv4 =
fragments with a non-
   zero checksum, after de-capsulation, the lwB4 MAY elect to queue the
   fragments as they arrive and perform NAPT44 on all fragments at the
   same time.  In this case, the incoming 5-tuple is determined by
   extracting the appropriate fields from the received packet, as
   described in [RFC2473].  Alternatively, a lwB4 MAY translate the de-
   capsulated fragments as they arrive, by storing information that
   allows it to compute the 5-tuple for fragments other than the first.
In the context of the above, is this a problem?

Woj> Well, what str= ikes me is that the above text does not bring in anything other than what&#= 39;s already in 2473 for IPinIP fragementation and  [RFC5508], and&nbs= p; [RFC5382] for NAT. The text should refer to those documents, or file err= ata. In other words, IPv4inIPv6 fragments and handling of IPv4 fragments with NAT44 is not a lwB4 specific= function, and is already well documented.

= [ian] What’s being added here is the translation of packets as they a= rrive, instead of queuing, re-assembing, then NATing as-per RFC2743. This i= s not documented anywhere for NAT44 (to my knowledge), only for NAT64.

It is docum= ented in RFC  4787 section 11...


This is not saying that RFC2473 i= s incorrect, it’s saying that there could be another alternative.

<= div>
 

 

* Section 5.2: Text:

For =
incoming de-capsulated IPv4 packets carrying UDP packets with a
   zero checksum, if the lwB4 has enough resources, =
the lwB4 MUST
   reassemble the packets and MUST calculate the checksum.&n=
bsp; If the lwB4
   does not have enough =
resources, then it MUST silently discard the
 =
  packets. 

Wouldn't it be easier to say that the lwb4 MAY r= eassemble the packet and recalculate the checksum? It's clearly not a M= UST...

 

[ian] Why is it not a MUST? If one condition is = met you MUST do this, if a different condition is met, you MUST do that. A = MAY would make re-assembly of the packets optional, meaning that an implementation could not implement support for f= ragment reassembly at all and still say that it is compliant with the spec.=


If it we= re a MUST then something would horribly break if it were not done. The abov= e clearly says that this reassembly operation is at the discretion of the d= evice,  subject to an arbitrary "enough resources" condition= . If you'd like it to be a MUST then the condition should be removed.

[ian] Then surely re-assembly is a SHOULD re= quirement, with a a MUST to discard if cannot be re-assembled. As I said, i= f it was a MAY requirement, then implementation would be completely optiona= l. 

Woj> Yes, and that= 9;s what the above text reads from a test perspective, i.e. since one has n= o way of determining whether there are "enough resources", a lwB4= that discards all such packets would comply. As I said, if one would like = to tighten the spec; a) the un-testable "enough resources" condition should be remove= d b) with that either a MUST used, if this is something super important, or= a SHOULD (as it seems to me). Alternatively a MAY as "nice to have&qu= ot; may also do.

[ian] How is ‘enough resources’ u= ntestable? Earlier in the section, it already specifically states = ;that the amount of resources allocated for fragmented packets must be= limited. The amour of a fixed fragment buffer in use or number of fra= gments in a fixed sized queue are perfectly testable.

From= a customers perspective, if I tested an implementation that discarded= all such fragmented packets in all conditions, then the implementation is = not compliant.

Rega= rdless, if we can agree that the lwB4 SHOULD re-assemble if it can and disc= ard if it can’t, then I’ll modify the paragraph to that ef= fect. 

Having done some TDD in a past life,= I'll assert that this is not a testable requirement in its current for= m. One's "resources" are not another's "resources&qu= ot;, which is the missing piece here. I'd say that we can agree to just= state that lwB4 SHOULD resemble is cleaner. But, deferring to rfc 4878 and= friends may be better.

Cheers,
Wojciech.
 

<= div>
Cheers,
Wojciech.

--bcaec5299c4d74b47804f34d2f14-- From nobody Wed Feb 26 04:59:51 2014 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC9951A0308 for ; Wed, 26 Feb 2014 04:59:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] 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 ladV-i9TbRuo for ; Wed, 26 Feb 2014 04:59:40 -0800 (PST) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) by ietfa.amsl.com (Postfix) with ESMTP id 3C1D11A0303 for ; Wed, 26 Feb 2014 04:59:40 -0800 (PST) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 39BB11B8268 for ; Wed, 26 Feb 2014 04:59:39 -0800 (PST) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 2C3A9190052; Wed, 26 Feb 2014 04:59:39 -0800 (PST) Received: from [10.0.10.40] (192.168.1.10) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 26 Feb 2014 04:59:39 -0800 Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ted Lemon In-Reply-To: Date: Wed, 26 Feb 2014 07:59:36 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <761AE0A6-41F6-478B-8AB2-8FA888765A23@nominum.com> References: <20140211075445.17615.61208.idtracker@ietfa.amsl.com> <8A1B81989BCFAE44A22B2B86BF2B76318A2CDB8ED2@HE111643.EMEA1.CDS.T-INTERNAL.COM> <530CDF3D.3030908@gmail.com> To: Wojciech Dec X-Mailer: Apple Mail (2.1827) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/softwires/WtLoz5PbtRkM_hvWUG9dG6jmYww Cc: Softwires WG Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-lw4over6-06.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2014 12:59:45 -0000 On Feb 26, 2014, at 5:12 AM, Wojciech Dec wrote: > May I kindly ask that you read my comments before starting apparently = rhetorical discussions of the type that I didn't intend, and that do not = progress things?=20 You may, I have, and I'm happy to see some forward progress happening in = the discussion. From nobody Thu Feb 27 11:06:23 2014 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA38E1A0106 for ; Thu, 27 Feb 2014 11:06:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] 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 PyIpySFawR2a for ; Thu, 27 Feb 2014 11:06:19 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id 848E21A00FD for ; Thu, 27 Feb 2014 11:06:19 -0800 (PST) Received: from ians-mbp.fritz.box ([89.0.111.113]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0M9NIY-1WO4cY02D0-00CgvO for ; Thu, 27 Feb 2014 20:06:16 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ian Farrer In-Reply-To: <52FDAE7B.8090009@ericsson.com> Date: Thu, 27 Feb 2014 20:06:13 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <52FDAE7B.8090009@ericsson.com> To: Suresh Krishnan X-Mailer: Apple Mail (2.1827) X-Provags-ID: V03:K0:ShJ/g0hIFRBHcrr4DZdXdPc01UQvG8jBKil6uyYZMXyPEtUyQr5 8x0d7kYdmF3hQs+DNdtE1alNXNJim4w6agafZ3Lgh8KlWapnA0epKV6KkYfGz1f/MUS7Z4Q JAnZcFs+ze7D/bW/ZgBvqvuyOyUMXMR3hZwYe/MMkwwP5aeqCK7c7DOoczgQoQM8lOlSbOP ET6lD0kD3H3zkZPtH9HAQ== Archived-At: http://mailarchive.ietf.org/arch/msg/softwires/PPV-U8e-oTVSw5xJCfeS072sbSw Cc: Softwires WG , Yong Cui Subject: Re: [Softwires] Working group last call for draft-ietf-softwire-map-t-05 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2014 19:06:22 -0000 I support this moving forward, with a few small comments: 1, A few instances where "packets'" should be "packet's" throughout the = doc (e.g. 8.2, 8.3) 2, Section 5.1 para 2, line 2 'as' is mis-spelt as =93s=94. 3, Section 8.1 "The source address and port of the packet obtained as a = result of the NAPT44 process MUST correspond to the source IPv4 address and source transport port = number derived to belong to the CE by means of the the MAP Basic Mapping Rule (BR)." Reads as if there is only a single transport port allocated to the = client. Wouldn=92t something like =91IPv4 address and a valid source = transport port...=92 be more accurate? Cheers, Ian On 14 Feb 2014, at 06:49, Suresh Krishnan = wrote: > Hi all, > This message starts a two week softwire working group last call on = advancing the draft about providing Mapping of Address and Port using = Translation as an Experimental RFC. The authors believe that this = version has addressed all the issues raised on the document till date. = The latest version of the draft is available at >=20 > http://www.ietf.org/id/draft-ietf-softwire-map-t-05.txt > http://tools.ietf.org/html/draft-ietf-softwire-map-t-05 >=20 > Substantive comments and statements of support/opposition for = advancing this document should be directed to the mailing list. = Editorial suggestions can be sent directly to the authors. This last = call will conclude on February 28, 2014 >=20 > Regards, > Suresh & Yong >=20 >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From nobody Fri Feb 28 02:51:19 2014 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3EEF1A0367 for ; Fri, 28 Feb 2014 02:51:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 FEeXqxMrqQ9m for ; Fri, 28 Feb 2014 02:51:17 -0800 (PST) Received: from mail-vc0-x22f.google.com (mail-vc0-x22f.google.com [IPv6:2607:f8b0:400c:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 71C461A0366 for ; Fri, 28 Feb 2014 02:51:17 -0800 (PST) Received: by mail-vc0-f175.google.com with SMTP id ij19so534286vcb.34 for ; Fri, 28 Feb 2014 02:51:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=sODEvlnNKSisoxDZGVdVZdFl04u1FiaDyrptktwQkWM=; b=RwKxX0YD5uo3eiysJ6/GbRV2TK2X3v+ODT1aY2r9IsQul26xo0Lk455sh+zcWIK149 H/sJ0cdur3QbvCsbTVDIFmtUQJ6ACMTFB+oychzMcRAoDHMAHVd1ujO1hKHQNt100e1G w6h/ykZLp2mvJpF0Uioz9861B//BcR/cwLyw42vvmvfJu91kpfn/3Ry1Nk8Oei0yhor9 /oZ9AGKUeLwZXBshoZtnR1z5jV4y0/jKxEdQ6umfYfQsHRjbtuVN/YbGsmMnx8DBRvnl bsxaYkubsF9bM35JinAH0qIEvAKGReh8la6Jlz8VPGkgY/UihMSmKdqIG/5I8f1sY35q rLFw== MIME-Version: 1.0 X-Received: by 10.58.4.138 with SMTP id k10mr1940924vek.8.1393584675258; Fri, 28 Feb 2014 02:51:15 -0800 (PST) Received: by 10.220.184.135 with HTTP; Fri, 28 Feb 2014 02:51:15 -0800 (PST) In-Reply-To: References: Date: Fri, 28 Feb 2014 18:51:15 +0800 Message-ID: From: Kevin Y To: Ida Leung Content-Type: multipart/alternative; boundary=047d7b5d2dc688c93f04f3753712 Archived-At: http://mailarchive.ietf.org/arch/msg/softwires/D0NGwk76SGaeuYHNXnlsjWI9UYc Cc: Softwires WG Subject: Re: [Softwires] reply: Working group last call for draft-ietf-softwire-map-t-05 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2014 10:51:19 -0000 --047d7b5d2dc688c93f04f3753712 Content-Type: text/plain; charset=ISO-8859-1 +1. Just read the draft. Yes, support for advance ! Thanks Kevin On Thu, Feb 20, 2014 at 10:33 PM, Ida Leung wrote: > I support to move this draft to advance to an experimental RFC. > > Thanks, > > ...Ida > > > > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > > --047d7b5d2dc688c93f04f3753712 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
+1. =A0=A0

Just read the draft. =A0Yes,= =A0support for advance !

Thanks

Kevin=A0


On Thu, Feb 20, 2014 at 10:33 PM, Ida Leung <ida@brumund.ca> = wrote:
I support to move this draft to advance to an experimental= RFC. =A0

Thanks,

...Ida



=

_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires


--047d7b5d2dc688c93f04f3753712--