wrote: > Hi, > > I have one comment about the current version: It is using an IPv4 default > route as the method for sending traffic out of the MAP domain. This is > likely to cause provisioning complexity and conflicts with two other > related drafts: > > 1, The unified CPE draft is looking for the presence of a configured > BR/AFTR v6 address as the mechanism for whether to configure 'binding mod= e' > (i.e. MAP 1:1 in this case). A v4 default route isn't easily compatible > with this. > Could you elaborate on what incompatibility you see? This is a case of an implicit default route (much as is also the norm in say PPP connections). > > 2, For DHCP based provisioning, the updated OPTION_MAP (described in the > unified CPE draft) + RFC6334 give a method for configuring basic softwire > functionality using just a DHCPv6 server. This doesn't provide any way of > distributing IPv4 default routes. Therefore, to provision a MAP 1:1 clien= t, > you would need to deploy the DHCPv4 over DHCPv6 infrastructure just for > this single DCHPv4 option. This is, of course assuming that the DHCPv4 ov= er > DHCPv6 method (draft-scskf-dhc-dhcpv4-over-dhcpv6) is the agreed mechanis= m > for v4 over v6 provisioning. > This appears back to front. RFC6334 is naturally the DS-lite AFTR option, and an AFTR does not equal a BR, (nor a Lw46 gateway). I believe that that the use of rfc6334 is unnecessary, and the unified CPE does not need to depend on it, esp given that it will need additional options anyway. In short, it makes little sense for a unified CPE to use both rfc6334 + some new option. > I raised this point in Orlando (See Ole's comment on using RFC6334 as the > DMR in the minutes). I think that this change would fix the two points > above. > IMO The unified CPE notion needs to be fixed (and it is something I have commented on previously): It's not unification by dumping all the existing stuff together, but a) a functional rationalization (all solution share the same functions) and b) a unified configuration method (which likely excludes things like rfc6334, given its applicability to only one solution= ) Regards, Woj. > > Thanks, > Ian > > > > > -----Original Message----- > From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On > Behalf Of Suresh Krishnan > Sent: Dienstag, 26. M=E4rz 2013 05:23 > To: Softwires WG > Cc: Yong Cui; Ralph Droms > Subject: [Softwires] Working group last call for draft-ietf-softwire-map-= 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 with > Encapsulation as a Standards Track RFC. The authors believe that this > version has addressed all the issues raised on the document. The latest > version of the draft is available at > > http://www.ietf.org/id/draft-ietf-softwire-map-05.txt > http://tools.ietf.org/html/draft-ietf-softwire-map-05 > > 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. The chairs will send in their commen= ts > as well during the last call period. This last call will conclude on Apri= l > 9, 2013. > > 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 > --20cf302ef9d8e15dd704d9eb9679 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi Ian,

a default route appears to be by= far the best way to model the reachability of destinations outside of the = MAP domain, and actually *any* IP domain (i.e. this is not a MAP specific a= spect).

On 5 April 20= 13 21:03, <ian.farrer@telekom.de> wrote:
Hi,

I have one comment about the current version: It is using an IPv4 default r= oute as the method for sending traffic out of the MAP domain. This is likel= y to cause provisioning complexity and conflicts with two other related dra= fts:

1, The unified CPE draft is looking for the presence of a configured BR/AFT= R v6 address as the mechanism for whether to configure 'binding mode= 9; (i.e. MAP 1:1 in this case). A v4 default route isn't easily compati= ble with this.

Could you elaborate on what incompatibilit= y you see?
This is a case of an implicit default route (much as is also = the norm in say PPP connections).

=A0

2, For DHCP based provisioning, the updated OPTION_MAP (described in the un= ified CPE draft) + RFC6334 give a method for configuring basic softwire fun= ctionality using just a DHCPv6 server. This doesn't provide any way of = distributing IPv4 default routes. Therefore, to provision a MAP 1:1 client,= you would need to deploy the DHCPv4 over DHCPv6 infrastructure just for th= is single DCHPv4 option. This is, of course assuming that the DHCPv4 over D= HCPv6 method (draft-scskf-dhc-dhcpv4-over-dhcpv6) is the agreed mechanism f= or v4 over v6 provisioning.

This appears back to front. RFC6334 is nat= urally the DS-lite AFTR option, and an AFTR does not equal a BR, (nor a Lw4= 6 gateway). I believe that that the use of rfc6334 is unnecessary, and the = unified CPE does not need to depend on it, esp given that it will need addi= tional options anyway. In short, it makes little sense for a unified CPE to= use both rfc6334 + some new option.

I raised this point in Orlando (See Ole's comment on using RFC6334 as t= he DMR in the minutes). I think that this change would fix the two points a= bove.

IMO The unified CPE notion needs = to be fixed (and it is something I have commented on previously): It's = not unification by dumping all the existing stuff together, but a) a functi= onal rationalization (all solution share the same functions) and b) a unifi= ed configuration method (which likely excludes things like rfc6334, given i= ts=A0 applicability to only one solution)

Regards,
Woj.

Thanks,
Ian

-----Original Message-----
From: softwires-bounces@ietf.= org [mailto:softwires-bou= nces@ietf.org] On Behalf Of Suresh Krishnan
Sent: Dienstag, 26. M=E4rz 2013 05:23
To: Softwires WG
Cc: Yong Cui; Ralph Droms
Subject: [Softwires] Working group last call for draft-ietf-softwire-map-05=

Hi all,
=A0 This message starts a two week softwire working group last call on adva= ncing the draft about providing Mapping of Address and Port with Encapsulat= ion as a Standards Track RFC. The authors believe that this version has add= ressed all the issues raised on the document. The latest version of the dra= ft is available at

http://www.ietf.org/id/draft-ietf-softwire-map-05.txt
http://tools.ietf.org/html/draft-ietf-softwire-map-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. The chairs will send in their comments a= s well during the last call period. This last call will conclude on April 9= , 2013.

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

--20cf302ef9d8e15dd704d9eb9679-- From tom.taylor.stds@gmail.com Tue Apr 9 04:12:00 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5632321F8E7C for ; Tue, 9 Apr 2013 04:12:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.28 X-Spam-Level: X-Spam-Status: No, score=0.28 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NNYcsoFdi-IZ for ; Tue, 9 Apr 2013 04:12:00 -0700 (PDT) Received: from mail-ia0-x236.google.com (mail-ia0-x236.google.com [IPv6:2607:f8b0:4001:c02::236]) by ietfa.amsl.com (Postfix) with ESMTP id D4DAD21F89DE for ; Tue, 9 Apr 2013 04:11:59 -0700 (PDT) Received: by mail-ia0-f182.google.com with SMTP id u20so1550959iag.13 for ; Tue, 09 Apr 2013 04:11:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-antivirus:x-antivirus-status; bh=GW8qGwT3gpWD0BafuD4qfRPkabbIIg5gpRyjmOLivvg=; b=ZAe3U4/rAgtQryfkOTj9gO1NTf1SKCcwL91NV3i55JHOkHAn0bBrbQt1STZk3hRP11 W9g03vUYpTV5zxSIL43m5ZXGtwCJCCwdOvy8YBGIWi9FNAaQlxWzVybW8vO/bYx6cm+Z sWO92iEqpY205QdrZH7FuJ5x3OsdeGvT6muZLLnsiiw+wCrUUOl8bM82l+SHqHbFyDBA QRgId4GMQXdY3+QKL3U5YHi557/yZ3Z7MhqY9HRPmc06CHbVuD+WjSyCJ3C9xjs92VXD zK0wN7a04Lm1JgysiF7YR0ZoxpXVZbCDQY4WDCDv6cZDufYr65y9yhQ12e0ZpuM60v/h 8GCA== X-Received: by 10.50.192.201 with SMTP id hi9mr9733936igc.48.1365505919362; Tue, 09 Apr 2013 04:11:59 -0700 (PDT) Received: from [127.0.0.1] (dsl-173-206-2-115.tor.primus.ca. [173.206.2.115]) by mx.google.com with ESMTPS id wn10sm22134437igb.2.2013.04.09.04.11.58 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Apr 2013 04:11:58 -0700 (PDT) Message-ID: <5163F77D.6020605@gmail.com> Date: Tue, 09 Apr 2013 07:11:57 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Ole Troan References: <51633F76.8080405@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 130409-0, 09/04/2013), Outbound message X-Antivirus-Status: Clean Cc: Softwires Subject: Re: [Softwires] MAP-E question -- provisioning of Rule IPv4 prefix X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 11:12:00 -0000 I'd suggest adding the condition at the start of the second sentence to be sure it is read correctly: "If r is non-zero but only a part ..." The other thing bothering me about that sentence is that it is talking about provisioning of the Rule IPv4 index in isolation, when it is actually part of the BMR. Why not simply say, for the complete sentence: "If r is non-zero but only a part of the IPv4 address/prefix is encoded in the EA bits, the missing initial portion is provided by the Rule IPv4 prefix from the BMR." On 09/04/2013 6:52 AM, Ole Troan wrote: > Tom, > >> In the previous note, I meant the BMR used as FMR, to be technical. >> But here's another point from the same section: >> >> The length of r MAY be zero, in which case the complete IPv4 >> address or prefix is encoded in the EA bits. If only a part of the >> IPv4 address/prefix is encoded in the EA bits, the Rule IPv4 prefix >> is provisioned to the CE by other means (e.g. a DHCPv6 option). >> >> Question: does that second sentence also assume r = 0? If so, I >> think you've moved beyond what makes sense to document as part of >> MAP-E. Given that you have the MAP-E BMR mechanism, why wouldn't >> you use it? > > no, the second sentence assumes r > 0. "If only a part of the IPv4 > address is encoded...", implies that the other part comes via the > BMR. > > cheers, Ole > From tom.taylor.stds@gmail.com Tue Apr 9 04:30:14 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFA7E21F8F39 for ; Tue, 9 Apr 2013 04:30:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.234 X-Spam-Level: X-Spam-Status: No, score=0.234 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UwN+sXmIVwHU for ; Tue, 9 Apr 2013 04:30:14 -0700 (PDT) Received: from mail-ia0-x235.google.com (mail-ia0-x235.google.com [IPv6:2607:f8b0:4001:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id 6899D21F8A52 for ; Tue, 9 Apr 2013 04:30:14 -0700 (PDT) Received: by mail-ia0-f181.google.com with SMTP id o25so6241465iad.12 for ; Tue, 09 Apr 2013 04:30:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-antivirus:x-antivirus-status; bh=daXkEdluJdOTpoW78e3fIw+2Mr7t5n69IFEWI79tGM8=; b=g0ojHOzsUb8mhcYsvLTznxNMY7QRflJ+vQsxjVSMonhI8cV8kWKSAgyiWKUW9MCXFe SJGImY4FkR0Qi1x2V8L4GkHSlj3QqH79AtVIJqFQFlhkyu628hSuv3VGMoQ1mE4vhNWN gY54O8HfDhVR1HLALg4NlzR1PTqOYBQfuuKuF0xGEy/kO9FR7LpztTl8qL8MEwO648mc D5IVF0cxYXP00sS5nfLmi8Qnu3/4DMahrm3nGteamSR+qvp2wSW4vK1U90Su0y278iz8 Y6zrR0hWzchpL3iedfh7r7XLxyalfHrC1mlTPx8l4udysGUBooaQFYsATiabExzHasW4 Bpsw== X-Received: by 10.50.6.202 with SMTP id d10mr9803522iga.28.1365507013995; Tue, 09 Apr 2013 04:30:13 -0700 (PDT) Received: from [127.0.0.1] (dsl-173-206-2-115.tor.primus.ca. [173.206.2.115]) by mx.google.com with ESMTPS id wx2sm24593142igb.4.2013.04.09.04.30.12 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Apr 2013 04:30:13 -0700 (PDT) Message-ID: <5163FBC3.3040602@gmail.com> Date: Tue, 09 Apr 2013 07:30:11 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Ole Troan References: <51633480.8070209@gmail.com> <28533DEA-0DD3-43DD-9CA4-929B0DBA9BDD@employees.org> In-Reply-To: <28533DEA-0DD3-43DD-9CA4-929B0DBA9BDD@employees.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 130409-0, 09/04/2013), Outbound message X-Antivirus-Status: Clean Cc: Softwires Subject: Re: [Softwires] MAP-E question -- first prefix X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 11:30:15 -0000 OK, how about this for the complete paragraph: "By default, the MAP subnetwork identifier is the first subnetwork within the End-user IPv6 prefix (all bits set to zero). An alternative subnetwork value MAY be configured. All nodes within a MAP domain MUST be configured to use the same value of the subnetwork identifier." I think that captures the intent. However, I see a possible difficulty: differing lengths of the End-user IPv6 prefix for different CEs. We have to add two conditions: -- the configured subnetwork identifier is at least 64 - min (n + o) bits long, where the minimization is taken over all FMRs in the domain -- the subnetwork identifier used with a given calculated End-user IPv6 prefix uses the right-most (64 - (n + o)) bits of the configured subnetwork identifier, where (n + o) is taken from the FMR used for the calculation. Seems simpler just to restrict to the all-zeros value, but please comment. Tom On 09/04/2013 6:51 AM, Ole Troan wrote: > Tom, > >> In Section 5.2 of -map-05, there is the paragraph: >> >> The MAP subnet ID is defined to be the first subnet (all bits set to >> zero). Unless configured differently, a MAP node MUST reserve the >> first IPv6 prefix in an End-user IPv6 prefix for the purpose of MAP. >> >> Question: does the second sentence say anything different from the first one? >> >> Question: if the MAP node is configured differently, how will other nodes be able to synthesize its MAP IPv6 address from the FMR? > > all nodes within the domain must use the same subnet-id. perhaps we could make that clearer. > > cheers, > Ole > From despres.remi@laposte.net Tue Apr 9 08:58:47 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5927D21F9428; Tue, 9 Apr 2013 08:58:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.949 X-Spam-Level: X-Spam-Status: No, score=-2.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VIMUXPJ0QywA; Tue, 9 Apr 2013 08:58:46 -0700 (PDT) Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr [93.17.128.3]) by ietfa.amsl.com (Postfix) with ESMTP id 5ED7521F9057; Tue, 9 Apr 2013 08:58:46 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2111.sfr.fr (SMTP Server) with ESMTP id CB8FC7000E59; Tue, 9 Apr 2013 17:58:44 +0200 (CEST) Received: from [192.168.0.21] (unknown [78.193.136.169]) by msfrf2111.sfr.fr (SMTP Server) with ESMTP id B34027000E52; Tue, 9 Apr 2013 17:58:44 +0200 (CEST) X-SFR-UUID: 20130409155844734.B34027000E52@msfrf2111.sfr.fr Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: =?iso-8859-1?q?R=E9mi_Despr=E9s?= In-Reply-To: <20130405175307.17053.57704.idtracker@ietfa.amsl.com> Date: Tue, 9 Apr 2013 17:58:44 +0200 Message-Id: <86BE1CED-B837-4BC5-B7DD-CEFF338845BC@laposte.net> References: <20130405175307.17053.57704.idtracker@ietfa.amsl.com> To: Softwires WG , Mohamed Boucadair X-Mailer: Apple Mail (2.1503) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: IETF Secretariat , ipr-announce@ietf.org Subject: [Softwires] France Telecom's IPR Statement about 4rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 15:58:47 -0000 Dear Med, dear all, I carefully checked France Telecom's IPR statement we just received = about 4rd. For reasons detailed below, I found that none of the three listed = patents applies to 4rd. Could you please, Med, check the technical analysis and, if we reach = common understanding, see to it that the IPR statement be either deleted = or appropriately updated.=20 Thanks, RD __________________ TECHNICAL ANALYSIS 1. 4rd isn't concerned with patent EP 2294798 because uses of for port = numbers for address sharing are radically different. =20 - In EP 2294798, deriving a destination "identifier" from an original = address + port must include these two steps: (1) find which PORT RANGE = is matched by the destination port among those that are recorded as = relevant to this destination address; (2) take as destination identifier = that which is recorded as associated with this address/port-range = couple. =20 - In 4rd, deriving a destination IPv6 address from an IPv4 A+P includes = these two steps: (1) find which IPV4 PREFIX is matched by the IPv4 = address, among recorded Rule IPv4 prefixes; (2) take as prefix of the = IPv6 destination the concatenation of three parts: the Rule IPv6 prefix = of the mapping rule that has the found IPv4 prefix; all bits that, in = the IPv4 address, follow this IPv4 prefix; some bits of the destination = port.=20 Looking for a match between an IPv4 address and an IPv4 PREFIX is = radically different from looking for a PORT RANGE that contains a given = port. (Incidentally, the same analysis applies AFAIK to MAP-E and MAP-T.)=20 2. 4rd isn't concerned with patents EP 2297927 and/or EP 2297927 because = address formats are beyond doubt incompatible.=20 - In both EP 2297927 and EP 2297928, each IPv6 address constructed from = an IPv4 A+P MUST CONTAIN the FULL IPv4 address FOLLOWED BY the port = number. =20 - In 4rd, an IPv6 address derived from an IPv4 A+P NEVER contains the = FULL IPv4 address FOLLOWED by a port number: . The full IPv4 address is always embedded in bits 80-111 of IPv6 = addresses, but always followed by a CNP field which has no relation to = the port number (Figure 5). . With a CE mapping rule, the first 64 bits of the IPv6 address may = contain part of the IPv4 address but NEVER the full address. (A CE = mapping rule has a Rule-IPv4-prefix length k > 0 because with k =3D 0 = it couldn't be distinguished, by address longest match, from the BR = mapping rule whose k must be 0. With k > 0, at most 32 - k bits of IPv4 = addresses can be embedded in 4rd IPv6 prefixes.)=20 =20 . With the BR mapping rule, no IPv4-address bit is embedded in the = first 80 bits of IPv6 addresses (Figure 5). (Incidentally, the same reasoning doesn't apply to MAP-E and MAP-T = because their PSIDs are repeated after embedded IPv4 addresses. Where = PSID lengths are 16 bits, which is permitted, IPv6 addresses do contain = IPv4 addresses followed by port numbers.) __________________ 2013-04-05 19:53, IETF Secretariat : >=20 > Dear Remi Despres, Reinaldo Penno, Yiu Lee, Gang Chen, Sheng Jiang, = Maoke Chen: >=20 > An IPR disclosure that pertains to your Internet-Draft entitled "IPv4 = Residual > Deployment via IPv6 - a Stateless Solution (4rd)" = (draft-ietf-softwire-4rd) was > submitted to the IETF Secretariat on 2013-03-20 and has been posted on = the "IETF > Page of Intellectual Property Rights Disclosures" > (https://datatracker.ietf.org/ipr/2050/). The title of the IPR = disclosure is > "France Telecom's Statement about IPR related to = draft-ietf-softwire-4rd-04.""); >=20 > The IETF Secretariat >=20 From ian.farrer@telekom.de Tue Apr 9 08:59:51 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A34621F972E for ; Tue, 9 Apr 2013 08:59:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8rstqRducbKq for ; Tue, 9 Apr 2013 08:59:50 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [80.149.113.247]) by ietfa.amsl.com (Postfix) with ESMTP id 8193C21F9734 for ; Tue, 9 Apr 2013 08:59:20 -0700 (PDT) Received: from he113675.emea1.cds.t-internal.com ([10.134.99.28]) by tcmail31.telekom.de with ESMTP/TLS/AES128-SHA; 09 Apr 2013 17:59:11 +0200 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE113675.emea1.cds.t-internal.com ([::1]) with mapi; Tue, 9 Apr 2013 17:59:11 +0200 From: To: Date: Tue, 9 Apr 2013 17:59:26 +0200 Thread-Topic: [Softwires] Working group last call for draft-ietf-softwire-map-05 Thread-Index: Ac41Oyy/RA+sYWqiQQWsW52oRKiJ0g== Message-ID: 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.2.130206 acceptlanguage: en-US, de-DE Content-Type: multipart/alternative; boundary="_000_CD8A04C061ECAianfarrertelekomde_" MIME-Version: 1.0 Cc: softwires@ietf.org, cuiyong@tsinghua.edu.cn, rdroms@cisco.com Subject: Re: [Softwires] Working group last call for draft-ietf-softwire-map-05 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 15:59:51 -0000 --_000_CD8A04C061ECAianfarrertelekomde_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Woj, To (hopefully) prevent a long, cross purpose discussion, could you describe= how you see that the BR address should be configured for MAP 1:1? It's des= cribed as a possible use case in the appendix, but it only covers how to pr= ovision the client, not how it learns the BR. Thanks, Ian From: Wojciech Dec > Date: Tuesday, 9 April 2013 13:09 To: Ian Farrer > Cc: Suresh Krishnan >, Softwires-wg >,= Yong Cui >, Ralph = Droms > Subject: Re: [Softwires] Working group last call for draft-ietf-softwire-ma= p-05 Hi Ian, a default route appears to be by far the best way to model the reachability= of destinations outside of the MAP domain, and actually *any* IP domain (i= .e. this is not a MAP specific aspect). On 5 April 2013 21:03, = > wrote: Hi, I have one comment about the current version: It is using an IPv4 default r= oute as the method for sending traffic out of the MAP domain. This is likel= y to cause provisioning complexity and conflicts with two other related dra= fts: 1, The unified CPE draft is looking for the presence of a configured BR/AFT= R v6 address as the mechanism for whether to configure 'binding mode' (i.e.= MAP 1:1 in this case). A v4 default route isn't easily compatible with thi= s. Could you elaborate on what incompatibility you see? This is a case of an implicit default route (much as is also the norm in sa= y PPP connections). 2, For DHCP based provisioning, the updated OPTION_MAP (described in the un= ified CPE draft) + RFC6334 give a method for configuring basic softwire fun= ctionality using just a DHCPv6 server. This doesn't provide any way of dist= ributing IPv4 default routes. Therefore, to provision a MAP 1:1 client, you= would need to deploy the DHCPv4 over DHCPv6 infrastructure just for this s= ingle DCHPv4 option. This is, of course assuming that the DHCPv4 over DHCPv= 6 method (draft-scskf-dhc-dhcpv4-over-dhcpv6) is the agreed mechanism for v= 4 over v6 provisioning. This appears back to front. RFC6334 is naturally the DS-lite AFTR option, a= nd an AFTR does not equal a BR, (nor a Lw46 gateway). I believe that that t= he use of rfc6334 is unnecessary, and the unified CPE does not need to depe= nd on it, esp given that it will need additional options anyway. In short, = it makes little sense for a unified CPE to use both rfc6334 + some new opti= on. I raised this point in Orlando (See Ole's comment on using RFC6334 as the D= MR in the minutes). I think that this change would fix the two points above= . IMO The unified CPE notion needs to be fixed (and it is something I have co= mmented on previously): It's not unification by dumping all the existing st= uff together, but a) a functional rationalization (all solution share the s= ame functions) and b) a unified configuration method (which likely excludes= things like rfc6334, given its applicability to only one solution) Regards, Woj. Thanks, Ian -----Original Message----- From: softwires-bounces@ietf.org [mailto= :softwires-bounces@ietf.org] On Behalf O= f Suresh Krishnan Sent: Dienstag, 26. M=E4rz 2013 05:23 To: Softwires WG Cc: Yong Cui; Ralph Droms Subject: [Softwires] Working group last call for draft-ietf-softwire-map-05 Hi all, This message starts a two week softwire working group last call on advanc= ing the draft about providing Mapping of Address and Port with Encapsulatio= n as a Standards Track RFC. The authors believe that this version has addre= ssed all the issues raised on the document. The latest version of the draft= is available at http://www.ietf.org/id/draft-ietf-softwire-map-05.txt http://tools.ietf.org/html/draft-ietf-softwire-map-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. The chairs will send in their comments a= s well during the last call period. This last call will conclude on April 9= , 2013. 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 --_000_CD8A04C061ECAianfarrertelekomde_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Woj,

<= br>

To (hopefully) prevent a long, cross purpose discussion, coul= d you describe how you see that the BR address should be configured for MAP= 1:1? It's described as a possible use case in the appendix, but it only co= vers how to provision the client, not how it learns the BR.

<= /div>

Thanks,

Ian

<= span style=3D"font-weight:bold">From: Wojciech Dec <wdec.ietf@gmail.com>
Date: Tuesday, 9 April 2013 13:09
To: Ian Farrer <ian.farrer@telekom.de>
Cc: Suresh Krishnan <suresh.krishnan@ericsson.com>, Softwires-wg <softwires@ietf.org>, Yong Cui <cuiyong@tsinghua.edu.cn>, Ralph = Droms <rdroms@cisco.com>
<= span style=3D"font-weight:bold">Subject: Re: [Softwires] Working gr= oup last call for draft-ietf-softwire-map-05

<= meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf-8">

Hi Ian,

a default route appears to be by far the best way to model the reachability= of destinations outside of the MAP domain, and actually *any* IP domain (i= .e. this is not a MAP specific aspect).

On 5 Apri= l 2013 21:03, <ian.farrer@telekom.de> wrote:
Hi,

I have one comment about the current version: It is using an IPv4 default r= oute as the method for sending traffic out of the MAP domain. This is likel= y to cause provisioning complexity and conflicts with two other related dra= fts:

1, The unified CPE draft is looking for the presence of a configured BR/AFT= R v6 address as the mechanism for whether to configure 'binding mode' (i.e.= MAP 1:1 in this case). A v4 default route isn't easily compatible with thi= s.

Could you elaborate on what incompat= ibility you see?
This is a case of an implicit default route (much as is also the norm in sa= y PPP connections).

I raised this point in Orlando (See Ole's comment on using RFC6334 as the D= MR in the minutes). I think that this change would fix the two points above= .

IMO The unified CPE notion needs to b= e fixed (and it is something I have commented on previously): It's not unif= ication by dumping all the existing stuff together, but a) a functional rat= ionalization (all solution share the same functions) and b) a unified configuration method (which likely excludes things like rfc6334, given its= applicability to only one solution)

Regards,
Woj.

Thanks,
Ian

-----Original Message-----
From: softwires-bounces@ietf.= org [mailto:softwires-bou= nces@ietf.org] On Behalf Of Suresh Krishnan
Sent: Dienstag, 26. M=E4rz 2013 05:23
To: Softwires WG
Cc: Yong Cui; Ralph Droms
Subject: [Softwires] Working group last call for draft-ietf-softwire-map-05=

Hi all,
This message starts a two week softwire working group last call on a= dvancing the draft about providing Mapping of Address and Port with Encapsu= lation as a Standards Track RFC. The authors believe that this version has = addressed all the issues raised on the document. The latest version of the draft is available at

http://www.ietf.org/id/draft-ietf-softwire-map-05.txt
htt= p://tools.ietf.org/html/draft-ietf-softwire-map-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. The chairs will send in their comments a= s well during the last call period. This last call will conclude on April 9, 2013.

Regards,
Suresh & Yong
_______________________________________________
Softwires mailing list
Softwires@i= etf.org
https://www.ietf.org/mailman/listinfo/softwires
_______________________________________________
Softwires mailing list
Softwires@i= etf.org
https://www.ietf.org/mailman/listinfo/softwires

--_000_CD8A04C061ECAianfarrertelekomde_-- From wdec.ietf@gmail.com Tue Apr 9 09:46:36 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCC9C21F90A9 for ; Tue, 9 Apr 2013 09:46:36 -0700 (PDT) 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_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DTsD0eqefs05 for ; Tue, 9 Apr 2013 09:46:35 -0700 (PDT) Received: from mail-qc0-x236.google.com (mail-qc0-x236.google.com [IPv6:2607:f8b0:400d:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 8561A21F903B for ; Tue, 9 Apr 2013 09:46:35 -0700 (PDT) Received: by mail-qc0-f182.google.com with SMTP id k19so3150288qcs.27 for ; Tue, 09 Apr 2013 09:46:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=V0a5bPnV3rP7Qv84ssBcOl+lgVd5HWuF3fSPptBCo0o=; b=WH0jJVPeFCrVI3GxXyL9e61PUEdS/8GV+WRB5UxmEMRVpdXxL1W+OXMCR7PE4bvjFb 5dNAFUnDsbqPvoT3BDWeE3B2M21cWiEDiDXUSk6srkyZBFCXknJcXyYbdQva6GAiJVma ZVyBOv/kBByUFGpEPbxa4bs47XIO03+/1Mpnw++f7Z/CVA9ePHrt+FdBxu7EjHDzS5m3 SMW6RBfLuLFj8V+GqDp87jKi9auO8kxI7g4Cy+8IYds+6vIc/dP9x6g0EupZDHJRaNUa P/B9kt/fAkq9sZi4jIaBR0orHrZux3/tmFDpQZXIJB4LAf6G1J6I4TyLGeWgWHHMeEhG v9mg== MIME-Version: 1.0 X-Received: by 10.49.11.178 with SMTP id r18mr24061155qeb.56.1365525994964; Tue, 09 Apr 2013 09:46:34 -0700 (PDT) Received: by 10.49.12.84 with HTTP; Tue, 9 Apr 2013 09:46:34 -0700 (PDT) In-Reply-To: References: Date: Tue, 9 Apr 2013 18:46:34 +0200 Message-ID: From: Wojciech Dec To: "ian.farrer@telekom.de" Content-Type: multipart/alternative; boundary=047d7b2e7ad2dc8e9d04d9f04b57 Cc: Softwires-wg , Yong Cui , Ralph Droms Subject: Re: [Softwires] Working group last call for draft-ietf-softwire-map-05 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 16:46:36 -0000 --047d7b2e7ad2dc8e9d04d9f04b57 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Ian, sure. In the current MAP the BR gets configured via the DMR (as an IP address) - http://tools.ietf.org/html/draft-ietf-softwire-map-dhcp-01#section-4.3 That's not set in stone, but it's a reasonable way of doing things. A name could be another equivalent way. Note: The working of this, incl DHCPv6, has been verified in trials also with the 1:1 mode and hooking up to a DS-lite AFTR, and an issue of compatibility, which you're voicing a concern about, hasn't come up. Regards, Woj. On 9 April 2013 17:59, wrote: > Hi Woj, > > To (hopefully) prevent a long, cross purpose discussion, could you > describe how you see that the BR address should be configured for MAP 1:1= ? > It's described as a possible use case in the appendix, but it only covers > how to provision the client, not how it learns the BR. > > Thanks, > Ian > > From: Wojciech Dec > Date: Tuesday, 9 April 2013 13:09 > To: Ian Farrer > Cc: Suresh Krishnan , Softwires-wg < > softwires@ietf.org>, Yong Cui , Ralph Droms < > rdroms@cisco.com> > Subject: Re: [Softwires] Working group last call for > draft-ietf-softwire-map-05 > > Hi Ian, > > a default route appears to be by far the best way to model the > reachability of destinations outside of the MAP domain, and actually *any= * > IP domain (i.e. this is not a MAP specific aspect). > > > On 5 April 2013 21:03, wrote: > >> Hi, >> >> I have one comment about the current version: It is using an IPv4 defaul= t >> route as the method for sending traffic out of the MAP domain. This is >> likely to cause provisioning complexity and conflicts with two other >> related drafts: >> >> 1, The unified CPE draft is looking for the presence of a configured >> BR/AFTR v6 address as the mechanism for whether to configure 'binding mo= de' >> (i.e. MAP 1:1 in this case). A v4 default route isn't easily compatible >> with this. >> > > Could you elaborate on what incompatibility you see? > This is a case of an implicit default route (much as is also the norm in > say PPP connections). > > >> >> 2, For DHCP based provisioning, the updated OPTION_MAP (described in the >> unified CPE draft) + RFC6334 give a method for configuring basic softwir= e >> functionality using just a DHCPv6 server. This doesn't provide any way o= f >> distributing IPv4 default routes. Therefore, to provision a MAP 1:1 clie= nt, >> you would need to deploy the DHCPv4 over DHCPv6 infrastructure just for >> this single DCHPv4 option. This is, of course assuming that the DHCPv4 o= ver >> DHCPv6 method (draft-scskf-dhc-dhcpv4-over-dhcpv6) is the agreed mechani= sm >> for v4 over v6 provisioning. >> > > This appears back to front. RFC6334 is naturally the DS-lite AFTR option, > and an AFTR does not equal a BR, (nor a Lw46 gateway). I believe that tha= t > the use of rfc6334 is unnecessary, and the unified CPE does not need to > depend on it, esp given that it will need additional options anyway. In > short, it makes little sense for a unified CPE to use both rfc6334 + some > new option. > > >> I raised this point in Orlando (See Ole's comment on using RFC6334 as th= e >> DMR in the minutes). I think that this change would fix the two points >> above. >> > > IMO The unified CPE notion needs to be fixed (and it is something I have > commented on previously): It's not unification by dumping all the existin= g > stuff together, but a) a functional rationalization (all solution share t= he > same functions) and b) a unified configuration method (which likely > excludes things like rfc6334, given its applicability to only one soluti= on) > > Regards, > Woj. > >> >> Thanks, >> Ian >> >> >> >> >> -----Original Message----- >> From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On >> Behalf Of Suresh Krishnan >> Sent: Dienstag, 26. M=E4rz 2013 05:23 >> To: Softwires WG >> Cc: Yong Cui; Ralph Droms >> Subject: [Softwires] Working group last call for >> draft-ietf-softwire-map-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 with >> Encapsulation as a Standards Track RFC. The authors believe that this >> version has addressed all the issues raised on the document. The latest >> version of the draft is available at >> >> http://www.ietf.org/id/draft-ietf-softwire-map-05.txt >> http://tools.ietf.org/html/draft-ietf-softwire-map-05 >> >> Substantive comments and statements of support/opposition for advancing >> this document should be directed to the mailing list. Editorial suggesti= ons >> can be sent directly to the authors. The chairs will send in their comme= nts >> as well during the last call period. This last call will conclude on Apr= il >> 9, 2013. >> >> 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 >> > > --047d7b2e7ad2dc8e9d04d9f04b57 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi Ian,

sure. In the current MAP th= e BR gets configured via the DMR (as an IP address) - http://tools.= ietf.org/html/draft-ietf-softwire-map-dhcp-01#section-4.3
That's not set in stone, but it's a reasonable way of doing things.= A name could be another equivalent way.

Note: The workin= g of this, incl DHCPv6, has been verified in trials also with the 1:1 mode = and hooking up to a DS-lite AFTR, and an issue of compatibility, which you&= #39;re voicing a concern about, hasn't come up.

Regards,
Woj.

<= br>

On 9 April 2013 17:59, <ian.farrer@= telekom.de> wrote:

Hi Woj,

To (hopefully) prevent a long, cross purpose discussion, could you describe= how you see that the BR address should be configured for MAP 1:1? It's= described as a possible use case in the appendix, but it only covers how t= o provision the client, not how it learns the BR.

Thanks,
Ian

From: Wojciech Dec <wdec.ietf@gmail.com>Date: Tuesday, 9 April 2013 13:0= 9
To: Ian Farrer <ian.farrer@telekom.de>Cc: Suresh Krishnan <suresh.krishnan@= ericsson.com>, Softwires-wg <softwires@ietf.org>, Yong Cui <cuiyong@tsinghua.edu.cn&= gt;, Ralph Droms <= rdroms@cisco.com>
Subject: Re: [Softwires] Working g= roup last call for draft-ietf-softwire-map-05

Hi Ian,

a default route appears to be by far the best way to model the reachability= of destinations outside of the MAP domain, and actually *any* IP domain (i= .e. this is not a MAP specific aspect).

On 5 Apri= l 2013 21:03, <ian.farrer@telekom.de> wrote:
Hi,

I have one comment about the current version: It is using an IPv4 default r= oute as the method for sending traffic out of the MAP domain. This is likel= y to cause provisioning complexity and conflicts with two other related dra= fts:

1, The unified CPE draft is looking for the presence of a configured BR/AFT= R v6 address as the mechanism for whether to configure 'binding mode= 9; (i.e. MAP 1:1 in this case). A v4 default route isn't easily compati= ble with this.

Could you elaborate on what incompatibilit= y you see?
This is a case of an implicit default route (much as is also the norm in sa= y PPP connections).

=A0

<= br> 2, For DHCP based provisioning, the updated OPTION_MAP (described in the un= ified CPE draft) + RFC6334 give a method for configuring basic softwire fun= ctionality using just a DHCPv6 server. This doesn't provide any way of = distributing IPv4 default routes. Therefore, to provision a MAP 1:1 client, you would need to deploy the DHCPv4 over DH= CPv6 infrastructure just for this single DCHPv4 option. This is, of course = assuming that the DHCPv4 over DHCPv6 method (draft-scskf-dhc-dhcpv4-over-dh= cpv6) is the agreed mechanism for v4 over v6 provisioning.

This appears = back to front. RFC6334 is naturally the DS-lite AFTR option, and an AFTR do= es not equal a BR, (nor a Lw46 gateway). I believe that that the use of rfc= 6334 is unnecessary, and the unified CPE does not need to depend on it, esp= given that it will need additional options anyway. In short, it makes little sense for a= unified CPE to use both rfc6334 + some new option.

I raised this point in Orlando (See Ole's comment on using RFC6334 as t= he DMR in the minutes). I think that this change would fix the two points a= bove.

Regards,
Woj.

Thanks,
Ian

-----Original Message-----
From: softw= ires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On Behalf Of Suresh = Krishnan
Sent: Dienstag, 26. M=E4rz 2013 05:23
To: Softwires WG
Cc: Yong Cui; Ralph Droms
Subject: [Softwires] Working group last call for draft-ietf-softwire-map-05=

Hi all,
=A0 This message starts a two week softwire working group last call on adva= ncing the draft about providing Mapping of Address and Port with Encapsulat= ion as a Standards Track RFC. The authors believe that this version has add= ressed all the issues raised on the document. The latest version of the draft is available at

http://www.ietf.org/id/draft-ietf-softwire-map-05.txt
htt= p://tools.ietf.org/html/draft-ietf-softwire-map-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. The chairs will send in their comments a= s well during the last call period. This last call will conclude on April 9, 2013.

Regards,
Suresh & Yong
_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/s= oftwires
_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/s= oftwires

--047d7b2e7ad2dc8e9d04d9f04b57-- From otroan@employees.org Tue Apr 9 12:14:57 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43CFD21F97D8 for ; Tue, 9 Apr 2013 12:14:56 -0700 (PDT) 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_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dWi7gXaUek2M for ; Tue, 9 Apr 2013 12:14:55 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [198.137.202.19]) by ietfa.amsl.com (Postfix) with ESMTP id 636F421F97D3 for ; Tue, 9 Apr 2013 12:14:51 -0700 (PDT) Received: from banjo.employees.org (localhost [127.0.0.1]) by banjo.employees.org (Postfix) with ESMTP id 3F1D45F5E; Tue, 9 Apr 2013 12:14:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s= selector1; bh=IP5dzKsn8Jsa++pqkMKT36jCRis=; b=asRWKCU5ZOKLWOOF1F 4qf4aiUb1MEuqeSEwM/eXjFCy2wz3aDbFWDZADErsb/39Q5WeF89PlJsZfZZwBmJ shKjVntemF5fPd37sKtMnkHa9dSv7de3QklWBavI5MOELpqgS86VqodyT+YD+jEH SLHXO8nq7X7rerzkKTJJIz73w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; q=dns; s= selector1; b=BnZRxEW4a7umClKvsVKuqDBDIzlKI4whL01gYxGZ3Ks804aHb82 ivALpAr9hwHig9MnuIvCp+3+9lRgX4si/TbEuRrGqpBFoFJnXiDC3ou1hH+a3n8K +WQ3DptHn+9Npz/j7slQG2O083UNo1jDnTUMeE3NOgx4/dLbqVzT4gKU= Received: from dhcp-10-61-98-157.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 6CE025F5A; Tue, 9 Apr 2013 12:14:48 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Ole Troan In-Reply-To: <5163FBC3.3040602@gmail.com> Date: Tue, 9 Apr 2013 21:14:45 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <409980DC-2EDB-464F-9E12-E69CBF81268D@employees.org> References: <51633480.8070209@gmail.com> <28533DEA-0DD3-43DD-9CA4-929B0DBA9BDD@employees.org> <5163FBC3.3040602@gmail.com> To: Tom Taylor X-Mailer: Apple Mail (2.1503) Cc: Softwires Subject: Re: [Softwires] MAP-E question -- first prefix X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 19:14:57 -0000 Tom, > OK, how about this for the complete paragraph: >=20 > "By default, the MAP subnetwork identifier is the first subnetwork = within the End-user IPv6 prefix (all bits set to zero). An alternative = subnetwork value MAY be configured. All nodes within a MAP domain MUST = be configured to use the same value of the subnetwork identifier." I like that text. > I think that captures the intent. However, I see a possible = difficulty: differing lengths of the End-user IPv6 prefix for different = CEs. We have to add two conditions: >=20 > -- the configured subnetwork identifier is at least > 64 - min (n + o) > bits long, where the minimization is taken over all FMRs in the domain >=20 > -- the subnetwork identifier used with a given calculated End-user = IPv6 prefix uses the right-most (64 - (n + o)) bits of the configured = subnetwork identifier, where (n + o) is taken from the FMR used for the = calculation. >=20 > Seems simpler just to restrict to the all-zeros value, but please = comment. I can't see how different End-user IPv6 prefix lengths within a domain = can work. cheers, Ole= From otroan@employees.org Tue Apr 9 12:41:42 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 552AA21F98FB for ; Tue, 9 Apr 2013 12:41:42 -0700 (PDT) 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_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JuuLzsm1oQS6 for ; Tue, 9 Apr 2013 12:41:41 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [198.137.202.19]) by ietfa.amsl.com (Postfix) with ESMTP id 7F36E21F98F9 for ; Tue, 9 Apr 2013 12:41:41 -0700 (PDT) Received: from banjo.employees.org (localhost [127.0.0.1]) by banjo.employees.org (Postfix) with ESMTP id 3730C5EAD; Tue, 9 Apr 2013 12:41:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s= selector1; bh=+vwjW71tqJV8ZMUSQR8RY0FXnxM=; b=DRqK2rtpu1L1rVsbvE wWm5FsD8nySVbteaVtAVQFYl3O2xBefncD9TnIGA2hZySXnM8rS8tDS8vR3evvE1 WdNvMEKDaEPhNniaipbhiCndt9PC1nI10UK9wpdo94XjYXVCjY2r3v2xbZSXv2eo gT+eFq6QpVzPgyPvg4UKrTiPI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; q=dns; s= selector1; b=oKBLjx7zQioJx4QEIi0e5SgxS09N9f+AdDo/XvS1vgdpPvQtc7h /z6G8K5pe3J/yB0lrk2l42+bA7NNAwu5Z3FVNcxg/GeXj00ac0Wgd2YisOfGkMbm OhonVl6On7RqwwXnkAZFzt9Ajwu0t7PLi/wUFRicoo4XgOx6ZLefvIxY= Received: from [192.168.10.3] (77.18.157.233.tmi.telenormobil.no [77.18.157.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 00E795E9C; Tue, 9 Apr 2013 12:41:38 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Ole Troan In-Reply-To: Date: Tue, 9 Apr 2013 21:41:35 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <01D0211C-657F-42F5-B221-459B05106719@employees.org> References: To: ian.farrer@telekom.de X-Mailer: Apple Mail (2.1503) Cc: softwires@ietf.org, cuiyong@tsinghua.edu.cn, rdroms@cisco.com Subject: Re: [Softwires] Working group last call for draft-ietf-softwire-map-05 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 19:41:42 -0000 Ian, > To (hopefully) prevent a long, cross purpose discussion, could you = describe how you see that the BR address should be configured for MAP = 1:1? It's described as a possible use case in the appendix, but it only = covers how to provision the client, not how it learns the BR. what I meant by an IPv4 default route was something like: 0.0.0.0/0, Tunnel0, 2001:db8::1 i.e. the BR IPv6 address as next-hop. is that OK? (the alternative would be an IPV4 address, which would force the BR to = have an address within the MAP domain). cheers, Ole > From: Wojciech Dec > Date: Tuesday, 9 April 2013 13:09 > To: Ian Farrer > Cc: Suresh Krishnan , Softwires-wg = , Yong Cui , Ralph Droms = > Subject: Re: [Softwires] Working group last call for = draft-ietf-softwire-map-05 >=20 > Hi Ian, >=20 > a default route appears to be by far the best way to model the = reachability of destinations outside of the MAP domain, and actually = *any* IP domain (i.e. this is not a MAP specific aspect).=20 >=20 >=20 > On 5 April 2013 21:03, wrote: >> Hi, >>=20 >> I have one comment about the current version: It is using an IPv4 = default route as the method for sending traffic out of the MAP domain. = This is likely to cause provisioning complexity and conflicts with two = other related drafts: >>=20 >> 1, The unified CPE draft is looking for the presence of a configured = BR/AFTR v6 address as the mechanism for whether to configure 'binding = mode' (i.e. MAP 1:1 in this case). A v4 default route isn't easily = compatible with this. >=20 > Could you elaborate on what incompatibility you see? > This is a case of an implicit default route (much as is also the norm = in say PPP connections).=20 > =20 >>=20 >> 2, For DHCP based provisioning, the updated OPTION_MAP (described in = the unified CPE draft) + RFC6334 give a method for configuring basic = softwire functionality using just a DHCPv6 server. This doesn't provide = any way of distributing IPv4 default routes. Therefore, to provision a = MAP 1:1 client, you would need to deploy the DHCPv4 over DHCPv6 = infrastructure just for this single DCHPv4 option. This is, of course = assuming that the DHCPv4 over DHCPv6 method = (draft-scskf-dhc-dhcpv4-over-dhcpv6) is the agreed mechanism for v4 over = v6 provisioning. >=20 > This appears back to front. RFC6334 is naturally the DS-lite AFTR = option, and an AFTR does not equal a BR, (nor a Lw46 gateway). I believe = that that the use of rfc6334 is unnecessary, and the unified CPE does = not need to depend on it, esp given that it will need additional options = anyway. In short, it makes little sense for a unified CPE to use both = rfc6334 + some new option.=20 >=20 >>=20 >> I raised this point in Orlando (See Ole's comment on using RFC6334 as = the DMR in the minutes). I think that this change would fix the two = points above. >=20 > IMO The unified CPE notion needs to be fixed (and it is something I = have commented on previously): It's not unification by dumping all the = existing stuff together, but a) a functional rationalization (all = solution share the same functions) and b) a unified configuration method = (which likely excludes things like rfc6334, given its applicability to = only one solution) >=20 > Regards, > Woj. >>=20 >> Thanks, >> Ian >>=20 >>=20 >>=20 >>=20 >> -----Original Message----- >> From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] = On Behalf Of Suresh Krishnan >> Sent: Dienstag, 26. M=E4rz 2013 05:23 >> To: Softwires WG >> Cc: Yong Cui; Ralph Droms >> Subject: [Softwires] Working group last call for = draft-ietf-softwire-map-05 >>=20 >> Hi all, >> This message starts a two week softwire working group last call on = advancing the draft about providing Mapping of Address and Port with = Encapsulation as a Standards Track RFC. The authors believe that this = version has addressed all the issues raised on the document. The latest = version of the draft is available at >>=20 >> http://www.ietf.org/id/draft-ietf-softwire-map-05.txt >> http://tools.ietf.org/html/draft-ietf-softwire-map-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. The chairs = will send in their comments as well during the last call period. This = last call will conclude on April 9, 2013. >>=20 >> 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 >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From tom.taylor.stds@gmail.com Tue Apr 9 15:13:28 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EE1321F99BA for ; Tue, 9 Apr 2013 15:13:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.048 X-Spam-Level: X-Spam-Status: No, score=0.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rJ5rn9mjYTvt for ; Tue, 9 Apr 2013 15:13:28 -0700 (PDT) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id EAC7521F99B9 for ; Tue, 9 Apr 2013 15:13:27 -0700 (PDT) Received: by mail-ie0-f181.google.com with SMTP id 17so9114896iea.26 for ; Tue, 09 Apr 2013 15:13:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=l3gj2AbeWsSgLPuddQcQau3N/JPmHp3aAiAMOvP1A9E=; b=so6XjtUpu1G+jWOgEr4mBgjuqTMHKMfiTedLLeQtuNLnDVPNjH+rCFn80WhNhZdNmN rpbxl+AhjxepQCWfjoUU9aqRUq1577qrvQfb0Q2r7A6oGqIH+uUNjCZhYUffIEYWwK/f 4gaEZzNYCGpu595qlMtrf3pheh4SHvtzQMd1nYqL81G31tbkvsbhTHMKRR5MulZ+OEIq BcvRSA1SYKAXSRlR1D+6dTDbf6JCvDjC/EaEHy56qkN7kuOoO7y4iWX03Gvs7tr2SjIb SfDfRRlanoqXVQZg51IU8HUUFsqoRfRETMAOxECMsxDqh7hUvxuwYPscuUIfjozlmPzZ 6heg== X-Received: by 10.42.159.194 with SMTP id m2mr15901236icx.13.1365545607634; Tue, 09 Apr 2013 15:13:27 -0700 (PDT) Received: from [192.168.1.65] (dsl-173-206-2-115.tor.primus.ca. [173.206.2.115]) by mx.google.com with ESMTPS id xc3sm24678670igb.10.2013.04.09.15.13.25 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Apr 2013 15:13:26 -0700 (PDT) Message-ID: <51649285.7050302@gmail.com> Date: Tue, 09 Apr 2013 18:13:25 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Ole Troan References: <51633480.8070209@gmail.com> <28533DEA-0DD3-43DD-9CA4-929B0DBA9BDD@employees.org> <5163FBC3.3040602@gmail.com> <409980DC-2EDB-464F-9E12-E69CBF81268D@employees.org> In-Reply-To: <409980DC-2EDB-464F-9E12-E69CBF81268D@employees.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Softwires Subject: Re: [Softwires] MAP-E question -- first prefix X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 22:13:28 -0000 On 09/04/2013 3:14 PM, Ole Troan wrote: > Tom, > ...> >> I think that captures the intent. However, I see a possible difficulty: differing lengths of the End-user IPv6 prefix for different CEs. We have to add two conditions: >> >> -- the configured subnetwork identifier is at least >> 64 - min (n + o) >> bits long, where the minimization is taken over all FMRs in the domain >> >> -- the subnetwork identifier used with a given calculated End-user IPv6 prefix uses the right-most (64 - (n + o)) bits of the configured subnetwork identifier, where (n + o) is taken from the FMR used for the calculation. >> >> Seems simpler just to restrict to the all-zeros value, but please comment. > > I can't see how different End-user IPv6 prefix lengths within a domain can work. > The End-user IPv6 prefix length obviously has to be the same for all nodes using the same BMR, but couldn't, for example, the PSID width (i.e., the sharing ratio) vary from one BMR to another? From suresh.krishnan@ericsson.com Tue Apr 9 22:18:16 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4310421F9138; Tue, 9 Apr 2013 22:18:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FSG9A3XpQO8v; Tue, 9 Apr 2013 22:18:15 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 685B321F9130; Tue, 9 Apr 2013 22:18:15 -0700 (PDT) X-AuditID: c618062d-b7f0d6d00000097e-ac-5164f6169be4 Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 25.0B.02430.616F4615; Wed, 10 Apr 2013 07:18:14 +0200 (CEST) Received: from eusaamw0712.eamcs.ericsson.se (147.117.20.181) by EUSAAHC007.ericsson.se (147.117.188.93) with Microsoft SMTP Server (TLS) id 14.2.318.4; Wed, 10 Apr 2013 01:18:14 -0400 Received: from [164.48.125.41] (147.117.20.214) by smtps-am.internal.ericsson.com (147.117.20.181) with Microsoft SMTP Server (TLS) id 8.3.279.1; Wed, 10 Apr 2013 01:18:13 -0400 Message-ID: <5164F579.4060404@ericsson.com> Date: Wed, 10 Apr 2013 01:15:37 -0400 From: Suresh Krishnan User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= References: <20130405175307.17053.57704.idtracker@ietfa.amsl.com> <86BE1CED-B837-4BC5-B7DD-CEFF338845BC@laposte.net> In-Reply-To: <86BE1CED-B837-4BC5-B7DD-CEFF338845BC@laposte.net> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrMLMWRmVeSWpSXmKPExsUyuXRPrK7Yt5RAgzdTrSxO3nrIZNG+7T6L xdnuGewWh98+BRLLtjI5sHosWfKTyePc+8lMHi3PTrIFMEdx2aSk5mSWpRbp2yVwZcw585G1 4LBixeIzfYwNjJ+kuhg5OSQETCT+3djEDmGLSVy4t56ti5GLQ0jgKKPE87bnLBDOHkaJq3u/ soBUCQlsZZSYt9UXxOYV0Jb482gfI4jNIqAq8XfpfFYQmw1o6oadn5lAbFGBMIm9F6axQdQL Spyc+QRsjoiAg8Tjq5uZQBYwC8xilJjx5hbYIGEBR4nWRUuhlpVIbNgzBWwQp4C9xPEbO9gg TpWU2PKiHexsZgE9iSlXWxghbHmJ5q2zmSF6NSW2rvnOOoFReBaS3bOQtMxC0rKAkXkVI0dp cWpZbrqRwSZGYMAfk2DT3cG456XlIUZpDhYlcd4g1wsBQgLpiSWp2ampBalF8UWlOanFhxiZ ODilGhgX7pG/VHJxxatVPxQ9L03uSDq2/88aDbFwnjPP3D6dfyCTpsF613DlpYyaEyHtWn2F LifOylg5/ytm+nRjdumTvpd/Ch9eE/VOdNv2w8N9R8aXTeVOHxsSOHd3LPH/lrXY98idG3Nr 1p1qbIo+eEH/5be8zjtrpzjIzuaQ/rWnWNNV9VvcjCglJZbijERDLeai4kQAO/badEYCAAA= Cc: Softwires WG , IETF Secretariat , ipr-announce@ietf.org Subject: Re: [Softwires] France Telecom's IPR Statement about 4rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 05:18:16 -0000 Hi Remi, I just wanted to point out that the IETF will make no determination about the validity of any particular IPR claim as specified in RFC3979 and derived from the principles established in Section 10 of RFC2026. Any RFC listed in an ipr disclosure will have a notice added (described in Section 5 of RFC3979) that will contain a disclaimer of validity. Thanks Suresh On 04/09/2013 11:58 AM, R�mi Despr�s wrote: > Dear Med, dear all, > > I carefully checked France Telecom's IPR statement we just received about 4rd. > For reasons detailed below, I found that none of the three listed patents applies to 4rd. > > Could you please, Med, check the technical analysis and, if we reach common understanding, see to it that the IPR statement be either deleted or appropriately updated. > > Thanks, > RD > > > __________________ > TECHNICAL ANALYSIS > > 1. 4rd isn't concerned with patent EP 2294798 because uses of for port numbers for address sharing are radically different. > > - In EP 2294798, deriving a destination "identifier" from an original address + port must include these two steps: (1) find which PORT RANGE is matched by the destination port among those that are recorded as relevant to this destination address; (2) take as destination identifier that which is recorded as associated with this address/port-range couple. > > - In 4rd, deriving a destination IPv6 address from an IPv4 A+P includes these two steps: (1) find which IPV4 PREFIX is matched by the IPv4 address, among recorded Rule IPv4 prefixes; (2) take as prefix of the IPv6 destination the concatenation of three parts: the Rule IPv6 prefix of the mapping rule that has the found IPv4 prefix; all bits that, in the IPv4 address, follow this IPv4 prefix; some bits of the destination port. > > Looking for a match between an IPv4 address and an IPv4 PREFIX is radically different from looking for a PORT RANGE that contains a given port. > > > (Incidentally, the same analysis applies AFAIK to MAP-E and MAP-T.) > > > > 2. 4rd isn't concerned with patents EP 2297927 and/or EP 2297927 because address formats are beyond doubt incompatible. > > - In both EP 2297927 and EP 2297928, each IPv6 address constructed from an IPv4 A+P MUST CONTAIN the FULL IPv4 address FOLLOWED BY the port number. > > - In 4rd, an IPv6 address derived from an IPv4 A+P NEVER contains the FULL IPv4 address FOLLOWED by a port number: > > . The full IPv4 address is always embedded in bits 80-111 of IPv6 addresses, but always followed by a CNP field which has no relation to the port number (Figure 5). > > . With a CE mapping rule, the first 64 bits of the IPv6 address may contain part of the IPv4 address but NEVER the full address. (A CE mapping rule has a Rule-IPv4-prefix length k > 0 because with k = 0 it couldn't be distinguished, by address longest match, from the BR mapping rule whose k must be 0. With k > 0, at most 32 - k bits of IPv4 addresses can be embedded in 4rd IPv6 prefixes.) > > . With the BR mapping rule, no IPv4-address bit is embedded in the first 80 bits of IPv6 addresses (Figure 5). > > > (Incidentally, the same reasoning doesn't apply to MAP-E and MAP-T because their PSIDs are repeated after embedded IPv4 addresses. Where PSID lengths are 16 bits, which is permitted, IPv6 addresses do contain IPv4 addresses followed by port numbers.) > __________________ > > > > > > > > 2013-04-05 19:53, IETF Secretariat : > >> >> Dear Remi Despres, Reinaldo Penno, Yiu Lee, Gang Chen, Sheng Jiang, Maoke Chen: >> >> An IPR disclosure that pertains to your Internet-Draft entitled "IPv4 Residual >> Deployment via IPv6 - a Stateless Solution (4rd)" (draft-ietf-softwire-4rd) was >> submitted to the IETF Secretariat on 2013-03-20 and has been posted on the "IETF >> Page of Intellectual Property Rights Disclosures" >> (https://datatracker.ietf.org/ipr/2050/). The title of the IPR disclosure is >> "France Telecom's Statement about IPR related to draft-ietf-softwire-4rd-04.""); >> >> The IETF Secretariat >> > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > From despres.remi@laposte.net Wed Apr 10 00:23:11 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 522F821F8AF8; Wed, 10 Apr 2013 00:23:10 -0700 (PDT) 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=[AWL=-0.500, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cr+M8w3eBrle; Wed, 10 Apr 2013 00:23:09 -0700 (PDT) Received: from smtp24.services.sfr.fr (smtp24.services.sfr.fr [93.17.128.83]) by ietfa.amsl.com (Postfix) with ESMTP id 0361B21F845E; Wed, 10 Apr 2013 00:23:07 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2412.sfr.fr (SMTP Server) with ESMTP id C89DD70000E8; Wed, 10 Apr 2013 09:23:06 +0200 (CEST) Received: from [192.168.0.21] (unknown [78.193.136.169]) by msfrf2412.sfr.fr (SMTP Server) with ESMTP id 7A703700007F; Wed, 10 Apr 2013 09:23:06 +0200 (CEST) X-SFR-UUID: 20130410072306501.7A703700007F@msfrf2412.sfr.fr Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: =?iso-8859-1?q?R=E9mi_Despr=E9s?= In-Reply-To: <5164F579.4060404@ericsson.com> Date: Wed, 10 Apr 2013 09:23:06 +0200 Message-Id: <1B297169-99E4-4763-A653-4C2E44F9EDE5@laposte.net> References: <20130405175307.17053.57704.idtracker@ietfa.amsl.com> <86BE1CED-B837-4BC5-B7DD-CEFF338845BC@laposte.net> <5164F579.4060404@ericsson.com> To: Suresh Krishnan X-Mailer: Apple Mail (2.1503) Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Softwires WG , IETF Secretariat , ipr-announce@ietf.org Subject: Re: [Softwires] France Telecom's IPR Statement about 4rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 07:23:11 -0000 2013-04-10 =E0 07:15, Suresh Krishnan : > Hi Remi, > I just wanted to point out that the IETF will make no determination > about the validity of any particular IPR claim as specified in RFC3979 > and derived from the principles established in Section 10 of RFC2026. > Any RFC listed in an ipr disclosure will have a notice added = (described > in Section 5 of RFC3979) that will contain a disclaimer of validity. Thanks, Suresh, Actually, I am well aware of this. In my understanding, this justifies that an IPR statement that doesn't = concern an RFC (with due understanding of initiators of the statement), = should be deleted by its initiators, in good faith, rather than = inappropriately listed in the RFC itself. In this context, whether a 4rd IPv6 address can contain, or not, an IPv4 = address followed by a port number is, for example, a simple technical = matter on which the WG, and in particular a knowledgeable contributor = like Med, is well placed to conclude . Regards, RD > Thanks > Suresh >=20 > On 04/09/2013 11:58 AM, R=E9mi Despr=E9s wrote: >> Dear Med, dear all, >>=20 >> I carefully checked France Telecom's IPR statement we just received = about 4rd. >> For reasons detailed below, I found that none of the three listed = patents applies to 4rd. >>=20 >> Could you please, Med, check the technical analysis and, if we reach = common understanding, see to it that the IPR statement be either deleted = or appropriately updated.=20 >>=20 >> Thanks, >> RD >>=20 >>=20 >> __________________ >> TECHNICAL ANALYSIS >>=20 >> 1. 4rd isn't concerned with patent EP 2294798 because uses of for = port numbers for address sharing are radically different. >>=20 >> - In EP 2294798, deriving a destination "identifier" from an original = address + port must include these two steps: (1) find which PORT RANGE = is matched by the destination port among those that are recorded as = relevant to this destination address; (2) take as destination identifier = that which is recorded as associated with this address/port-range = couple. >>=20 >> - In 4rd, deriving a destination IPv6 address from an IPv4 A+P = includes these two steps: (1) find which IPV4 PREFIX is matched by the = IPv4 address, among recorded Rule IPv4 prefixes; (2) take as prefix of = the IPv6 destination the concatenation of three parts: the Rule IPv6 = prefix of the mapping rule that has the found IPv4 prefix; all bits = that, in the IPv4 address, follow this IPv4 prefix; some bits of the = destination port.=20 >>=20 >> Looking for a match between an IPv4 address and an IPv4 PREFIX is = radically different from looking for a PORT RANGE that contains a given = port. >>=20 >>=20 >> (Incidentally, the same analysis applies AFAIK to MAP-E and MAP-T.)=20= >>=20 >>=20 >>=20 >> 2. 4rd isn't concerned with patents EP 2297927 and/or EP 2297927 = because address formats are beyond doubt incompatible.=20 >>=20 >> - In both EP 2297927 and EP 2297928, each IPv6 address constructed = from an IPv4 A+P MUST CONTAIN the FULL IPv4 address FOLLOWED BY the port = number. >>=20 >> - In 4rd, an IPv6 address derived from an IPv4 A+P NEVER contains the = FULL IPv4 address FOLLOWED by a port number: >>=20 >> . The full IPv4 address is always embedded in bits 80-111 of IPv6 = addresses, but always followed by a CNP field which has no relation to = the port number (Figure 5). >>=20 >> . With a CE mapping rule, the first 64 bits of the IPv6 address may = contain part of the IPv4 address but NEVER the full address. (A CE = mapping rule has a Rule-IPv4-prefix length k > 0 because with k =3D 0 = it couldn't be distinguished, by address longest match, from the BR = mapping rule whose k must be 0. With k > 0, at most 32 - k bits of IPv4 = addresses can be embedded in 4rd IPv6 prefixes.)=20 >>=20 >> . With the BR mapping rule, no IPv4-address bit is embedded in the = first 80 bits of IPv6 addresses (Figure 5). >>=20 >>=20 >> (Incidentally, the same reasoning doesn't apply to MAP-E and MAP-T = because their PSIDs are repeated after embedded IPv4 addresses. Where = PSID lengths are 16 bits, which is permitted, IPv6 addresses do contain = IPv4 addresses followed by port numbers.) >> __________________ >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> 2013-04-05 19:53, IETF Secretariat : >>=20 >>>=20 >>> Dear Remi Despres, Reinaldo Penno, Yiu Lee, Gang Chen, Sheng Jiang, = Maoke Chen: >>>=20 >>> An IPR disclosure that pertains to your Internet-Draft entitled = "IPv4 Residual >>> Deployment via IPv6 - a Stateless Solution (4rd)" = (draft-ietf-softwire-4rd) was >>> submitted to the IETF Secretariat on 2013-03-20 and has been posted = on the "IETF >>> Page of Intellectual Property Rights Disclosures" >>> (https://datatracker.ietf.org/ipr/2050/). The title of the IPR = disclosure is >>> "France Telecom's Statement about IPR related to = draft-ietf-softwire-4rd-04.""); >>>=20 >>> The IETF Secretariat >>>=20 >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >>=20 >=20 From simon.perreault@viagenie.ca Wed Apr 10 02:50:15 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F80A21F92EC for ; Wed, 10 Apr 2013 02:50:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10C+12kcFsbZ for ; Wed, 10 Apr 2013 02:50:14 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id CCFAB21F92E9 for ; Wed, 10 Apr 2013 02:50:13 -0700 (PDT) Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:8453:e5d:d9a5:1f86]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 513DE4043C for ; Wed, 10 Apr 2013 05:50:07 -0400 (EDT) Message-ID: <5165361C.3040600@viagenie.ca> Date: Wed, 10 Apr 2013 11:51:24 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: softwires@ietf.org References: <20130405175307.17053.57704.idtracker@ietfa.amsl.com> <86BE1CED-B837-4BC5-B7DD-CEFF338845BC@laposte.net> <5164F579.4060404@ericsson.com> <1B297169-99E4-4763-A653-4C2E44F9EDE5@laposte.net> In-Reply-To: <1B297169-99E4-4763-A653-4C2E44F9EDE5@laposte.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Softwires] France Telecom's IPR Statement about 4rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 09:50:15 -0000 Le 2013-04-10 09:23, R�mi Despr�s a �crit : > In my understanding, this justifies that an IPR statement that doesn't concern an RFC (with due understanding of initiators of the statement), should be deleted by its initiators, in good faith, rather than inappropriately listed in the RFC itself. Just keep in mind that the entity you're trying to convince is France Telecom, not this working group. If France Telecom doesn't find your arguments convincing, there's nothing we can do. Simon From simon.perreault@viagenie.ca Wed Apr 10 02:52:27 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E68621F9104 for ; Wed, 10 Apr 2013 02:52:27 -0700 (PDT) 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=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q8bDoxdBdcAD for ; Wed, 10 Apr 2013 02:52:27 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by ietfa.amsl.com (Postfix) with ESMTP id E118D21F90A9 for ; Wed, 10 Apr 2013 02:52:26 -0700 (PDT) Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:8453:e5d:d9a5:1f86]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 30D234043C for ; Wed, 10 Apr 2013 05:51:56 -0400 (EDT) Message-ID: <5165368A.7070508@viagenie.ca> Date: Wed, 10 Apr 2013 11:53:14 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: softwires@ietf.org References: <20130405175307.17053.57704.idtracker@ietfa.amsl.com> <86BE1CED-B837-4BC5-B7DD-CEFF338845BC@laposte.net> <5164F579.4060404@ericsson.com> In-Reply-To: <5164F579.4060404@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Softwires] France Telecom's IPR Statement about 4rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 09:52:27 -0000 Le 2013-04-10 07:15, Suresh Krishnan a �crit : > Any RFC listed in an ipr disclosure will have a notice added (described > in Section 5 of RFC3979) that will contain a disclaimer of validity. According to that section, the notice will be added to any IETF RFC, whether there is any IPR declaration or not. So the content of the future 4rd RFC will be unaffected by this. Simon From despres.remi@laposte.net Wed Apr 10 03:14:57 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68CD521F9382 for ; Wed, 10 Apr 2013 03:14:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4H-NiKahloTJ for ; Wed, 10 Apr 2013 03:14:57 -0700 (PDT) Received: from smtp23.services.sfr.fr (smtp23.services.sfr.fr [93.17.128.21]) by ietfa.amsl.com (Postfix) with ESMTP id D104821F937E for ; Wed, 10 Apr 2013 03:14:56 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2312.sfr.fr (SMTP Server) with ESMTP id 6AD91700016C; Wed, 10 Apr 2013 12:14:55 +0200 (CEST) Received: from [192.168.0.21] (unknown [78.193.136.169]) by msfrf2312.sfr.fr (SMTP Server) with ESMTP id 1E4917000159; Wed, 10 Apr 2013 12:14:55 +0200 (CEST) X-SFR-UUID: 20130410101455124.1E4917000159@msfrf2312.sfr.fr Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: =?iso-8859-1?q?R=E9mi_Despr=E9s?= In-Reply-To: <5165361C.3040600@viagenie.ca> Date: Wed, 10 Apr 2013 12:14:54 +0200 Message-Id: <23A3721E-11A3-4747-9BE0-2964F1954BCB@laposte.net> References: <20130405175307.17053.57704.idtracker@ietfa.amsl.com> <86BE1CED-B837-4BC5-B7DD-CEFF338845BC@laposte.net> <5164F579.4060404@ericsson.com> <1B297169-99E4-4763-A653-4C2E44F9EDE5@laposte.net> <5165361C.3040600@viagenie.ca> To: Simon Perreault X-Mailer: Apple Mail (2.1503) Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Softwires WG Subject: Re: [Softwires] France Telecom's IPR Statement about 4rd X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 10:14:57 -0000 Le 2013-04-10 =E0 11:51, Simon Perreault a = =E9crit : > Le 2013-04-10 09:23, R=E9mi Despr=E9s a =E9crit : >> In my understanding, this justifies that an IPR statement that = doesn't concern an RFC (with due understanding of initiators of the = statement), should be deleted by its initiators, in good faith, rather = than inappropriately listed in the RFC itself. >=20 > Just keep in mind that the entity you're trying to convince is France = Telecom, not this working group. If France Telecom doesn't find your = arguments convincing, there's nothing we can do. Well understood. That's why my analysis is directly addressed to Med, the "Contact = Information for the IETF Participant Whose Personal Belief Triggered = this Disclosure". I have confidence in his good faith, well known in the WG, to correct = this mistake (or to explain in what my analysis would be wrong). Cheers, RD >=20 > Simon > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From otroan@employees.org Wed Apr 10 03:54:21 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CD8621F8FA2 for ; Wed, 10 Apr 2013 03:54:21 -0700 (PDT) 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_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0J0rDMeCgAJh for ; Wed, 10 Apr 2013 03:54:20 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [198.137.202.19]) by ietfa.amsl.com (Postfix) with ESMTP id 952A121F9104 for ; Wed, 10 Apr 2013 03:54:20 -0700 (PDT) Received: from banjo.employees.org (localhost [127.0.0.1]) by banjo.employees.org (Postfix) with ESMTP id 988CA5EB6; Wed, 10 Apr 2013 03:54:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s= selector1; bh=LwXh2kqW2ny9j9ZJWnwCxb+zEVQ=; b=KD2QbvdJsALloN/qRU OjT55rtM9PQ54OsqC5fFYB/RXc5i41enkjGZseNuRubEn9Iaqloj0mCfdaCba1Qn 7ubo5EXyHjbPmWCFo9ANk4tv5C53hNnMKoaMaik2TIekBISHz0WynKjdBrwRoV0v EFPac+HRvRtHl1OBKbSg1H+Ko= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; q=dns; s= selector1; b=ffh+BVEYutZTX6UzkTw0rStMCqqn+lhQyGhiTWgNq3E4fGrlSQJ JexYpoUo4LSOnHexHiaKKAj7elhrCNR7KkMinQj0kcsQkjEhnXAdYY15UHUqSCjR fCMqbcs5/TDRSVjDRCTk+sojxBz5yQ5oAPHJ/5ucAP7r17rs3WY4SYhc= Received: from dhcp-10-61-98-189.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id F0DDC5EB5; Wed, 10 Apr 2013 03:54:12 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Ole Troan In-Reply-To: <51649285.7050302@gmail.com> Date: Wed, 10 Apr 2013 12:54:13 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <35D6D53C-464D-476E-BF6C-97614F24259A@employees.org> References: <51633480.8070209@gmail.com> <28533DEA-0DD3-43DD-9CA4-929B0DBA9BDD@employees.org> <5163FBC3.3040602@gmail.com> <409980DC-2EDB-464F-9E12-E69CBF81268D@employees.org> <51649285.7050302@gmail.com> To: Tom Taylor X-Mailer: Apple Mail (2.1503) Cc: Softwires Subject: Re: [Softwires] MAP-E question -- first prefix X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 10:54:21 -0000 Tom, >>> I think that captures the intent. However, I see a possible = difficulty: differing lengths of the End-user IPv6 prefix for different = CEs. We have to add two conditions: >>>=20 >>> -- the configured subnetwork identifier is at least >>> 64 - min (n + o) >>> bits long, where the minimization is taken over all FMRs in the = domain >>>=20 >>> -- the subnetwork identifier used with a given calculated End-user = IPv6 prefix uses the right-most (64 - (n + o)) bits of the configured = subnetwork identifier, where (n + o) is taken from the FMR used for the = calculation. >>>=20 >>> Seems simpler just to restrict to the all-zeros value, but please = comment. >>=20 >> I can't see how different End-user IPv6 prefix lengths within a = domain can work. >>=20 >=20 > The End-user IPv6 prefix length obviously has to be the same for all = nodes using the same BMR, but couldn't, for example, the PSID width = (i.e., the sharing ratio) vary from one BMR to another? absolutely. 'everything' can be different between different BMRs within = the same domain. cheers, Ole From tom.taylor.stds@gmail.com Wed Apr 10 05:57:38 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 970EC21F974A for ; Wed, 10 Apr 2013 05:57:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.048 X-Spam-Level: X-Spam-Status: No, score=0.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lVZ-xs6q+jEA for ; Wed, 10 Apr 2013 05:57:38 -0700 (PDT) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 23A2321F9747 for ; Wed, 10 Apr 2013 05:57:38 -0700 (PDT) Received: by mail-ie0-f174.google.com with SMTP id aq17so445614iec.19 for ; Wed, 10 Apr 2013 05:57:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=bsf2KDn/z/XaWE4bUMWtf+JTZ5KN2wvUDARW3bk66kk=; b=yKrAhzPjoJx0szXXWn4cNxKYigA/iLgUz85gBCGKHylpoIMw5DItyuFCxcDgGZ7Ush AfS7AeOIQ4udrgI+euFh8KzmEFbc9qMzN60Wdcuo6w1YNkP8kUgsuwBkz9K++0VgBwE+ 2/P29RDHvYKqGIMpSXqQaDBkhjFb+NB0CFrj839428MB6Ok2Wdjz8ABxAIcG3YINAOXa 61FUlVYxFC8Xz/KA2b9F8vXudw4rGjk+NeUpYvTtyNVtlgEgtv+SThpjtIO914gOT5FX EMNonDm+pL2+sX0plQ6dlaiMdOaLCSPBKfy3GyKEl0vGjNcw0btKEgYDu3oq8AtXqMXF RS0Q== X-Received: by 10.42.192.12 with SMTP id do12mr1148513icb.53.1365598657602; Wed, 10 Apr 2013 05:57:37 -0700 (PDT) Received: from [192.168.1.65] (dsl-173-206-2-115.tor.primus.ca. [173.206.2.115]) by mx.google.com with ESMTPS id xe9sm27098413igb.7.2013.04.10.05.57.36 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 10 Apr 2013 05:57:36 -0700 (PDT) Message-ID: <516561BF.5080308@gmail.com> Date: Wed, 10 Apr 2013 08:57:35 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Ole Troan References: <51633480.8070209@gmail.com> <28533DEA-0DD3-43DD-9CA4-929B0DBA9BDD@employees.org> <5163FBC3.3040602@gmail.com> <409980DC-2EDB-464F-9E12-E69CBF81268D@employees.org> <51649285.7050302@gmail.com> <35D6D53C-464D-476E-BF6C-97614F24259A@employees.org> In-Reply-To: <35D6D53C-464D-476E-BF6C-97614F24259A@employees.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Softwires Subject: Re: [Softwires] MAP-E question -- first prefix X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 12:57:38 -0000 Looks like we had a misunderstanding. Did the authors think of the configured subnetwork identifier of the existing text as being configured for a particular rule, in effect another rule parameter? I took it to be configured as a single value used in conjunction with all FMRs to calculate the target MAP IPv6 addresses. On 10/04/2013 6:54 AM, Ole Troan wrote: > Tom, > >>>> I think that captures the intent. However, I see a possible difficulty: differing lengths of the End-user IPv6 prefix for different CEs. We have to add two conditions: >>>> >>>> -- the configured subnetwork identifier is at least >>>> 64 - min (n + o) >>>> bits long, where the minimization is taken over all FMRs in the domain >>>> >>>> -- the subnetwork identifier used with a given calculated End-user IPv6 prefix uses the right-most (64 - (n + o)) bits of the configured subnetwork identifier, where (n + o) is taken from the FMR used for the calculation. >>>> >>>> Seems simpler just to restrict to the all-zeros value, but please comment. >>> >>> I can't see how different End-user IPv6 prefix lengths within a domain can work. >>> >> >> The End-user IPv6 prefix length obviously has to be the same for all nodes using the same BMR, but couldn't, for example, the PSID width (i.e., the sharing ratio) vary from one BMR to another? > > absolutely. 'everything' can be different between different BMRs within the same domain. > > cheers, > Ole > > From wdec.ietf@gmail.com Wed Apr 10 06:12:26 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DF1321F8E6E for ; Wed, 10 Apr 2013 06:12:26 -0700 (PDT) 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_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FAahJFMXP3qj for ; Wed, 10 Apr 2013 06:12:25 -0700 (PDT) Received: from mail-qc0-x22d.google.com (mail-qc0-x22d.google.com [IPv6:2607:f8b0:400d:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id C507521F8EC1 for ; Wed, 10 Apr 2013 06:12:23 -0700 (PDT) Received: by mail-qc0-f173.google.com with SMTP id b12so179706qca.18 for ; Wed, 10 Apr 2013 06:12:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=7WlnGyn/ycUwYLIlYRDai9uBtEAmKT/MhrtCIS0AbTc=; b=GziMfd+tvczZYYQ7cwmNFSAOhdIRWtcUM7P3DAH+Vt3qX865HWWBXYrZFJT6dhkxRL 2IPppIjTdUPd74mtd6r8TCPgL9NTk1mRN8lQ1NnwD3bOxJ0JEK4KdPZb5WHqJoLsMKjS NGMy+tntkt7a2dMt0IrVmGRlTYfE1aEFdNQ/AB2RCB/Yw9urpexx8VEP9npwyd6qteCp b1QunduajwZnCnjqx1xsYvchzgARstYQzKuy+nzow7qSrQy+g5d7BeqQLfu4cTcqLK1v Hs8bV9BAJMxqv0qBmMltAhvjQ7i06GZtq7jB/9/vfImulduUkU86KfEXiC1GPWp9zsmg r8Ag== MIME-Version: 1.0 X-Received: by 10.49.11.178 with SMTP id r18mr2175686qeb.56.1365599536692; Wed, 10 Apr 2013 06:12:16 -0700 (PDT) Received: by 10.49.12.84 with HTTP; Wed, 10 Apr 2013 06:12:16 -0700 (PDT) In-Reply-To: References:

Date: Wed, 10 Apr 2013 15:12:16 +0200 Message-ID: From: Wojciech Dec To: Qi Sun Content-Type: multipart/alternative; boundary=047d7b2e7ad24aa56604da016b0f Cc: Softwires-wg , Yong Cui , Ralph Droms Subject: Re: [Softwires] Working group last call for draft-ietf-softwire-map-05 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 13:12:26 -0000 --047d7b2e7ad24aa56604da016b0f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Qi, the name doesn't matter. It's an IP address, it can be a name, of the BR. MAP-E talks about that. In the dhcpv6 draft it has been codified as a DMR and is actually much more flexible than 6334. (feel free to use a name you feel comfortable with). That said 6334, is an orthogonal discussion - topic for comments on the dhcp draft. MAP-E requires the address of a BR to operate and implicitly points a default route to it, and as much is said in the draft. How it gets that address is clearly part of provisioning. The original claim was of some incompatibilities, I'm still wondering what these are. Cheers, Woj. On 10 April 2013 09:48, Qi Sun wrote: > > Hi Woj , > > AFAIK, there is no DMR defined in draft-map-05. And for map-e, what a > 'DMR' DHCPv6 option does is the same as that of RFC6334, both for > configuring the IPv6 address of the tunnel concentrator. It is convenient > for the unified CPE to leverage RFC6334 for this configuration, IMHO. > > > Best Regards, > Qi Sun > > > On 2013-4-10, at =E4=B8=8A=E5=8D=8812:46, Wojciech Dec wrote: > > Hi Ian, > > sure. In the current MAP the BR gets configured via the DMR (as an IP > address) - > http://tools.ietf.org/html/draft-ietf-softwire-map-dhcp-01#section-4.3 > That's not set in stone, but it's a reasonable way of doing things. A nam= e > could be another equivalent way. > > Note: The working of this, incl DHCPv6, has been verified in trials also > with the 1:1 mode and hooking up to a DS-lite AFTR, and an issue of > compatibility, which you're voicing a concern about, hasn't come up. > > Regards, > Woj. > > > On 9 April 2013 17:59, wrote: > >> Hi Woj, >> >> To (hopefully) prevent a long, cross purpose discussion, could you >> describe how you see that the BR address should be configured for MAP 1:= 1? >> It's described as a possible use case in the appendix, but it only cover= s >> how to provision the client, not how it learns the BR. >> >> Thanks, >> Ian >> >> From: Wojciech Dec >> Date: Tuesday, 9 April 2013 13:09 >> To: Ian Farrer >> Cc: Suresh Krishnan , Softwires-wg < >> softwires@ietf.org>, Yong Cui , Ralph Droms < >> rdroms@cisco.com> >> Subject: Re: [Softwires] Working group last call for >> draft-ietf-softwire-map-05 >> >> Hi Ian, >> >> a default route appears to be by far the best way to model the >> reachability of destinations outside of the MAP domain, and actually *an= y* >> IP domain (i.e. this is not a MAP specific aspect). >> >> >> On 5 April 2013 21:03, wrote: >> >>> Hi, >>> >>> I have one comment about the current version: It is using an IPv4 >>> default route as the method for sending traffic out of the MAP domain. = This >>> is likely to cause provisioning complexity and conflicts with two other >>> related drafts: >>> >>> 1, The unified CPE draft is looking for the presence of a configured >>> BR/AFTR v6 address as the mechanism for whether to configure 'binding m= ode' >>> (i.e. MAP 1:1 in this case). A v4 default route isn't easily compatible >>> with this. >>> >> >> Could you elaborate on what incompatibility you see? >> This is a case of an implicit default route (much as is also the norm in >> say PPP connections). >> >> >>> >>> 2, For DHCP based provisioning, the updated OPTION_MAP (described in th= e >>> unified CPE draft) + RFC6334 give a method for configuring basic softwi= re >>> functionality using just a DHCPv6 server. This doesn't provide any way = of >>> distributing IPv4 default routes. Therefore, to provision a MAP 1:1 cli= ent, >>> you would need to deploy the DHCPv4 over DHCPv6 infrastructure just for >>> this single DCHPv4 option. This is, of course assuming that the DHCPv4 = over >>> DHCPv6 method (draft-scskf-dhc-dhcpv4-over-dhcpv6) is the agreed mechan= ism >>> for v4 over v6 provisioning. >>> >> >> This appears back to front. RFC6334 is naturally the DS-lite AFTR option= , >> and an AFTR does not equal a BR, (nor a Lw46 gateway). I believe that th= at >> the use of rfc6334 is unnecessary, and the unified CPE does not need to >> depend on it, esp given that it will need additional options anyway. In >> short, it makes little sense for a unified CPE to use both rfc6334 + som= e >> new option. >> >> >>> I raised this point in Orlando (See Ole's comment on using RFC6334 as >>> the DMR in the minutes). I think that this change would fix the two poi= nts >>> above. >>> >> >> IMO The unified CPE notion needs to be fixed (and it is something I have >> commented on previously): It's not unification by dumping all the existi= ng >> stuff together, but a) a functional rationalization (all solution share = the >> same functions) and b) a unified configuration method (which likely >> excludes things like rfc6334, given its applicability to only one solut= ion) >> >> Regards, >> Woj. >> >>> >>> Thanks, >>> Ian >>> >>> >>> >>> >>> -----Original Message----- >>> From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On >>> Behalf Of Suresh Krishnan >>> Sent: Dienstag, 26. M=C3=A4rz 2013 05:23 >>> To: Softwires WG >>> Cc: Yong Cui; Ralph Droms >>> Subject: [Softwires] Working group last call for >>> draft-ietf-softwire-map-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 with >>> Encapsulation as a Standards Track RFC. The authors believe that this >>> version has addressed all the issues raised on the document. The latest >>> version of the draft is available at >>> >>> http://www.ietf.org/id/draft-ietf-softwire-map-05.txt >>> http://tools.ietf.org/html/draft-ietf-softwire-map-05 >>> >>> Substantive comments and statements of support/opposition for advancing >>> this document should be directed to the mailing list. Editorial suggest= ions >>> can be sent directly to the authors. The chairs will send in their comm= ents >>> as well during the last call period. This last call will conclude on Ap= ril >>> 9, 2013. >>> >>> 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 >>> >> >> > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > > > --047d7b2e7ad24aa56604da016b0f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Qi,

the name doesn't matter. It's an I= P address, it can be a name, of the BR. MAP-E talks about that. In the dhcp= v6 draft it has been codified as a DMR and is actually much more flexible t= han 6334. (feel free to use a name you feel comfortable with). That said 63= 34, is an orthogonal discussion - topic for comments on the dhcp draft.

MAP-E requires the address of a BR to operate and implicitly= points a default route to it, and as much is said in the draft. How it get= s that address is clearly part of provisioning.

The origi= nal claim was of some incompatibilities, I'm still wondering what these= are.

Cheers,
Woj.

On 10 April 2013 09:48,= Qi Sun <sunqi.thu@gmail.com> wrote:

Hi Woj ,

AFAIK, there is no DMR defined in dr= aft-map-05. And for map-e, what a 'DMR' DHCPv6 option does is the s= ame as that of RFC6334, both for configuring the IPv6 address of the tunnel= concentrator. It is convenient for the unified CPE to leverage RFC6334 for= this configuration, IMHO.

Best Regards,
Qi Sun

<= /span>

On 2013-4-10, at =E4=B8=8A=E5=8D=8812:46, Wojciech Dec wrote:=

Hi Ian,
<= br>
sure. In the current MAP the BR gets configured via the DMR (as an= IP address) - http://tools.ietf.org/html/draft-i= etf-softwire-map-dhcp-01#section-4.3
That's not set in stone, but it's a reasonable way of doing things.= A name could be another equivalent way.

Note: The workin= g of this, incl DHCPv6, has been verified in trials also with the 1:1 mode = and hooking up to a DS-lite AFTR, and an issue of compatibility, which you&= #39;re voicing a concern about, hasn't come up.

Regards,
Woj.
<= br>
On 9 April 2013 17:59, <ian.farrer@= telekom.de> wrote:

Hi Woj,

To (hopefully) prevent a long, cross purpose discussion, could you describe= how you see that the BR address should be configured for MAP 1:1? It's= described as a possible use case in the appendix, but it only covers how t= o provision the client, not how it learns the BR.

Thanks,
Ian

From: Wojciech Dec <wdec.ietf@gmail.com>Date: Tuesday, 9 April 2013 13:0= 9
To: Ian Farrer <ian.farrer@telekom.de>Cc: Suresh Krishnan <suresh.krishnan@= ericsson.com>, Softwires-wg <softwires@ietf.org>, Yong Cui <cuiyong@tsinghua.edu.cn&= gt;, Ralph Droms <= rdroms@cisco.com>
Subject: Re: [Softwires] Working g= roup last call for draft-ietf-softwire-map-05

<= /div>
Hi Ian,

a default route appears to be by far the best way to model the reachability= of destinations outside of the MAP domain, and actually *any* IP domain (i= .e. this is not a MAP specific aspect).

On 5 Apri= l 2013 21:03, <ian.farrer@telekom.de> wrote:
Hi,

I have one comment about the current version: It is using an IPv4 default r= oute as the method for sending traffic out of the MAP domain. This is likel= y to cause provisioning complexity and conflicts with two other related dra= fts:

1, The unified CPE draft is looking for the presence of a configured BR/AFT= R v6 address as the mechanism for whether to configure 'binding mode= 9; (i.e. MAP 1:1 in this case). A v4 default route isn't easily compati= ble with this.

Could you elaborate on what incompatibilit= y you see?
This is a case of an implicit default route (much as is also the norm in sa= y PPP connections).
=C2=A0

I raised this point in Orlando (See Ole's comment on using RFC6334 as t= he DMR in the minutes). I think that this change would fix the two points a= bove.

IMO The unified CPE notion needs = to be fixed (and it is something I have commented on previously): It's = not unification by dumping all the existing stuff together, but a) a functi= onal rationalization (all solution share the same functions) and b) a unifi= ed configuration method (which likely excludes things like rfc6334, given its= =C2=A0 applicability to only one solution)

Regards,
Woj.

Thanks,
Ian

-----Original Message-----
From: softw= ires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On Behalf Of Suresh = Krishnan
Sent: Dienstag, 26. M=C3=A4rz 2013 05:23
To: Softwires WG
Cc: Yong Cui; Ralph Droms
Subject: [Softwires] Working group last call for draft-ietf-softwire-map-05=

Hi all,
=C2=A0 This message starts a two week softwire working group last call on a= dvancing the draft about providing Mapping of Address and Port with Encapsu= lation as a Standards Track RFC. The authors believe that this version has = addressed all the issues raised on the document. The latest version of the draft is available at

http://www.ietf.org/id/draft-ietf-softwire-map-05.txt
htt= p://tools.ietf.org/html/draft-ietf-softwire-map-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. The chairs will send in their comments a= s well during the last call period. This last call will conclude on April 9, 2013.

Regards,
Suresh & Yong
_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/s= oftwires
_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/s= oftwires

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

--047d7b2e7ad24aa56604da016b0f-- From ian.farrer@telekom.de Wed Apr 10 06:12:34 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D239121F8E6E for ; Wed, 10 Apr 2013 06:12:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.748 X-Spam-Level: X-Spam-Status: No, score=-2.748 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wjt+wFY85NVp for ; Wed, 10 Apr 2013 06:12:33 -0700 (PDT) Received: from tcmail23.telekom.de (tcmail23.telekom.de [80.149.113.243]) by ietfa.amsl.com (Postfix) with ESMTP id 6A09F21F977B for ; Wed, 10 Apr 2013 06:12:32 -0700 (PDT) Received: from he111631.emea1.cds.t-internal.com ([10.134.93.23]) by tcmail21.telekom.de with ESMTP/TLS/AES128-SHA; 10 Apr 2013 15:12:30 +0200 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE111631.emea1.cds.t-internal.com ([::1]) with mapi; Wed, 10 Apr 2013 15:12:30 +0200 From: To: Date: Wed, 10 Apr 2013 15:12:48 +0200 Thread-Topic: [Softwires] Working group last call for draft-ietf-softwire-map-05 Thread-Index: Ac417Q27D9aFeGQWR9iDl0+r0FDXoA== Message-ID: 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.2.130206 acceptlanguage: en-US, de-DE Content-Type: multipart/alternative; boundary="_000_CD8AE0F962247ianfarrertelekomde_" MIME-Version: 1.0 Cc: softwires@ietf.org, cuiyong@tsinghua.edu.cn, rdroms@cisco.com Subject: Re: [Softwires] Working group last call for draft-ietf-softwire-map-05 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 13:12:34 -0000 --_000_CD8AE0F962247ianfarrertelekomde_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable HI Woj, Thanks for that. So we actually aren't too far apart. There needs to be a D= MR (or equivalent) that has the IPv6 address of the BR. But, this is one thing that's been confusing me since the publication of (I= think v03), where the DMR is no longer described, or mentioned anywhere in= the MAP base draft. However it does still exist in the MAP DHCP option dra= ft. But neither of the drafts actually describes what it is and how to use = it. The current map 05 draft only discusses the use of an IPv4 route, which= I think is misleading =96 the IPv6 address of the BR is also needed (as Ol= e's pointed out in his mail). A DMR, or something functionally equivalent is necessary, but this is not j= ust an IPv4 route. It has to have the v6 address of the BR, used to build a= tunnel. The v4 route points then to that tunnel. So, the reason that I said it's incompatible is that the current text in th= e MAP base draft doesn't describe any way of getting the v6 address of the = BR other than those that can be provided with a BMR and FMRs. I.e. An IPv4 = default route with an IPv4 next hop which is in a map domain which the CPE = has an FMR for. lw4o6, which doesn't use mapping rules cannot calculate the= v6 address of the concentrator from a v4 next hop address. I realise that this is not how it is meant to work (and you've confirmed th= at), but this is the only way that you could make it work given the text th= at is actually in the draft and that's what I think needs to be changed. Th= is would bring the MAP/lw4o6 & unified CPE drafts back in line=85 =85 then we can have the discussion about what the best DHCP mechanism to p= rovision the client with the v6 address of the concentrator is :-) Cheers, Ian From: Wojciech Dec > Date: Tuesday, 9 April 2013 18:46 To: Ian Farrer > Cc: Suresh Krishnan >, Softwires-wg >,= Yong Cui >, Ralph = Droms > Subject: Re: [Softwires] Working group last call for draft-ietf-softwire-ma= p-05 Hi Ian, sure. In the current MAP the BR gets configured via the DMR (as an IP addre= ss) - http://tools.ietf.org/html/draft-ietf-softwire-map-dhcp-01#section-4.= 3 That's not set in stone, but it's a reasonable way of doing things. A name = could be another equivalent way. Note: The working of this, incl DHCPv6, has been verified in trials also wi= th the 1:1 mode and hooking up to a DS-lite AFTR, and an issue of compatibi= lity, which you're voicing a concern about, hasn't come up. Regards, Woj. On 9 April 2013 17:59, = > wrote: Hi Woj, To (hopefully) prevent a long, cross purpose discussion, could you describe= how you see that the BR address should be configured for MAP 1:1? It's des= cribed as a possible use case in the appendix, but it only covers how to pr= ovision the client, not how it learns the BR. Thanks, Ian From: Wojciech Dec > Date: Tuesday, 9 April 2013 13:09 To: Ian Farrer > Cc: Suresh Krishnan >, Softwires-wg >,= Yong Cui >, Ralph = Droms > Subject: Re: [Softwires] Working group last call for draft-ietf-softwire-ma= p-05 Hi Ian, a default route appears to be by far the best way to model the reachability= of destinations outside of the MAP domain, and actually *any* IP domain (i= .e. this is not a MAP specific aspect). On 5 April 2013 21:03, = > wrote: Hi, I have one comment about the current version: It is using an IPv4 default r= oute as the method for sending traffic out of the MAP domain. This is likel= y to cause provisioning complexity and conflicts with two other related dra= fts: 1, The unified CPE draft is looking for the presence of a configured BR/AFT= R v6 address as the mechanism for whether to configure 'binding mode' (i.e.= MAP 1:1 in this case). A v4 default route isn't easily compatible with thi= s. Could you elaborate on what incompatibility you see? This is a case of an implicit default route (much as is also the norm in sa= y PPP connections). 2, For DHCP based provisioning, the updated OPTION_MAP (described in the un= ified CPE draft) + RFC6334 give a method for configuring basic softwire fun= ctionality using just a DHCPv6 server. This doesn't provide any way of dist= ributing IPv4 default routes. Therefore, to provision a MAP 1:1 client, you= would need to deploy the DHCPv4 over DHCPv6 infrastructure just for this s= ingle DCHPv4 option. This is, of course assuming that the DHCPv4 over DHCPv= 6 method (draft-scskf-dhc-dhcpv4-over-dhcpv6) is the agreed mechanism for v= 4 over v6 provisioning. This appears back to front. RFC6334 is naturally the DS-lite AFTR option, a= nd an AFTR does not equal a BR, (nor a Lw46 gateway). I believe that that t= he use of rfc6334 is unnecessary, and the unified CPE does not need to depe= nd on it, esp given that it will need additional options anyway. In short, = it makes little sense for a unified CPE to use both rfc6334 + some new opti= on. I raised this point in Orlando (See Ole's comment on using RFC6334 as the D= MR in the minutes). I think that this change would fix the two points above= . IMO The unified CPE notion needs to be fixed (and it is something I have co= mmented on previously): It's not unification by dumping all the existing st= uff together, but a) a functional rationalization (all solution share the s= ame functions) and b) a unified configuration method (which likely excludes= things like rfc6334, given its applicability to only one solution) Regards, Woj. Thanks, Ian -----Original Message----- From: softwires-bounces@ietf.org [mailto= :softwires-bounces@ietf.org] On Behalf O= f Suresh Krishnan Sent: Dienstag, 26. M=E4rz 2013 05:23 To: Softwires WG Cc: Yong Cui; Ralph Droms Subject: [Softwires] Working group last call for draft-ietf-softwire-map-05 Hi all, This message starts a two week softwire working group last call on advanc= ing the draft about providing Mapping of Address and Port with Encapsulatio= n as a Standards Track RFC. The authors believe that this version has addre= ssed all the issues raised on the document. The latest version of the draft= is available at http://www.ietf.org/id/draft-ietf-softwire-map-05.txt http://tools.ietf.org/html/draft-ietf-softwire-map-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. The chairs will send in their comments a= s well during the last call period. This last call will conclude on April 9= , 2013. 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 --_000_CD8AE0F962247ianfarrertelekomde_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

HI Woj,

Thanks for that. So we actually aren't too far apart. There needs to= be a DMR (or equivalent) that has the IPv6 address of the BR.

But, this is one thing that's been confusing me since the publ= ication of (I think v03), where the DMR is no longer described, or mentione= d anywhere in the MAP base draft. However it does still exist in the MAP DH= CP option draft. But neither of the drafts actually describes what it is an= d how to use it. The current map 05 draft only discusses the use of an IPv4= route, which I think is misleading =96 the IPv6 address of the BR is also = needed (as Ole's pointed out in his mail).

A= DMR, or something functionally equivalent is necessary, but this is not ju= st an IPv4 route. It has to have the v6 address of the BR, used to build a = tunnel. The v4 route points then to that tunnel.

S= o, the reason that I said it's incompatible is that the current text in the= MAP base draft doesn't describe any way of getting the v6 address of the B= R other than those that can be provided with a BMR and FMRs. I.e. An IPv4 d= efault route with an IPv4 next hop which is in a map domain which the CPE h= as an FMR for. lw4o6, which doesn't use mapping rules cannot calculate the = v6 address of the concentrator from a v4 next hop address.

I realise that this is not how it is meant to work (and you've con= firmed that), but this is the only way that you could make it work given th= e text that is actually in the draft and that's what I think needs to be ch= anged. This would bring the MAP/lw4o6 & unified CPE drafts back in line= =85

=85 then we can have the discussion about what= the best DHCP mechanism to provision the client with the v6 address of the= concentrator is :-)

Cheers,

Ian

Fro= m: Wojciech Dec <wdec.iet= f@gmail.com>
Date: Tuesd= ay, 9 April 2013 18:46
To: Ian = Farrer <ian.farrer@telekom.de>
Cc: Suresh Krishnan <= suresh.krishnan@ericsson.co= m>, Softwires-wg <softwires= @ietf.org>, Yong Cui <= cuiyong@tsinghua.edu.cn>, Ralph Droms <rdroms@cisco.com>
Subj= ect: Re: [Softwires] Working group last call for draft-ietf-softwir= e-map-05

Hi Ia= n,

sure. In the current MAP the BR gets configured via the DMR (as an IP addre= ss) - http://tools.ietf.org/html/draft-ietf-softwire-map-dhcp-01#section-4.3<= br> That's not set in stone, but it's a reasonable way of doing things. A name = could be another equivalent way.

Note: The working of thi= s, incl DHCPv6, has been verified in trials also with the 1:1 mode and hook= ing up to a DS-lite AFTR, and an issue of compatibility, which you're voici= ng a concern about, hasn't come up.

Regards,
Woj.

On 9 April 2013 17:59, <ian.farrer@telekom.de> wr= ote:

Hi Woj,
<= br>
To (hopefully) prevent a long, cross purpose discussion, coul= d you describe how you see that the BR address should be configured for MAP= 1:1? It's described as a possible use case in the appendix, but it only co= vers how to provision the client, not how it learns the BR.

Thanks,
Ian

From: Wojciech Dec <wdec.ietf@gmail.com>
Date: Tuesday, 9 April 2013 13:09
To: Ian Farrer <ian.farrer@telekom.de>
Cc: Suresh Krishnan <suresh.krishnan@ericsson.com>, Soft= wires-wg <softwi= res@ietf.org>, Yong Cui <cuiyong@tsinghua.edu.cn>, Ralph Droms <rdro= ms@cisco.com>
Subject: Re= : [Softwires] Working group last call for draft-ietf-softwire-map-05

Hi= Ian,

a default route appears to be by far the best way to model the reachability= of destinations outside of the MAP domain, and actually *any* IP domain (i= .e. this is not a MAP specific aspect).

On 5 Apri= l 2013 21:03, <ian.farrer@telekom.de> wrote:
Hi,

I have one comment about the current version: It is using an IPv4 default r= oute as the method for sending traffic out of the MAP domain. This is likel= y to cause provisioning complexity and conflicts with two other related dra= fts:

1, The unified CPE draft is looking for the presence of a configured BR/AFT= R v6 address as the mechanism for whether to configure 'binding mode' (i.e.= MAP 1:1 in this case). A v4 default route isn't easily compatible with thi= s.

Could you elaborate on what incompat= ibility you see?
This is a case of an implicit default route (much as is also the norm in sa= y PPP connections).

I raised this point in Orlando (See Ole's comment on using RFC6334 as the D= MR in the minutes). I think that this change would fix the two points above= .

Regards,
Woj.

Thanks,
Ian

-----Original Message-----
From: softw= ires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On Behalf Of Suresh = Krishnan
Sent: Dienstag, 26. M=E4rz 2013 05:23
To: Softwires WG
Cc: Yong Cui; Ralph Droms
Subject: [Softwires] Working group last call for draft-ietf-softwire-map-05=

Hi all,
This message starts a two week softwire working group last call on a= dvancing the draft about providing Mapping of Address and Port with Encapsu= lation as a Standards Track RFC. The authors believe that this version has = addressed all the issues raised on the document. The latest version of the draft is available at

http://www.ietf.org/id/draft-ietf-softwire-map-05.txt
htt= p://tools.ietf.org/html/draft-ietf-softwire-map-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. The chairs will send in their comments a= s well during the last call period. This last call will conclude on April 9, 2013.

Regards,
Suresh & Yong
_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/s= oftwires
_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/s= oftwires

=
--_000_CD8AE0F962247ianfarrertelekomde_-- From otroan@employees.org Wed Apr 10 06:20:45 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 882A321F9779 for ; Wed, 10 Apr 2013 06:20:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QT0bXi5qEzgG for ; Wed, 10 Apr 2013 06:20:44 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 24D3821F9607 for ; Wed, 10 Apr 2013 06:20:43 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,447,1363132800"; d="scan'208";a="81889724" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 10 Apr 2013 13:20:43 +0000 Received: from dhcp-lys02-vla252-10-147-116-14.cisco.com (dhcp-lys02-vla252-10-147-116-14.cisco.com [10.147.116.14]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r3ADKeQ9021069 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 10 Apr 2013 13:20:41 GMT Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Ole Troan In-Reply-To: Date: Wed, 10 Apr 2013 15:20:40 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: X-Mailer: Apple Mail (2.1503) Cc: softwires@ietf.org, cuiyong@tsinghua.edu.cn, rdroms@cisco.com Subject: Re: [Softwires] Working group last call for draft-ietf-softwire-map-05 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 13:20:45 -0000 Ian, > Thanks for that. So we actually aren't too far apart. There needs to = be a DMR (or equivalent) that has the IPv6 address of the BR. >=20 > But, this is one thing that's been confusing me since the publication = of (I think v03), where the DMR is no longer described, or mentioned = anywhere in the MAP base draft. However it does still exist in the MAP = DHCP option draft. But neither of the drafts actually describes what it = is and how to use it. The current map 05 draft only discusses the use of = an IPv4 route, which I think is misleading =96 the IPv6 address of the = BR is also needed (as Ole's pointed out in his mail).=20 >=20 > A DMR, or something functionally equivalent is necessary, but this is = not just an IPv4 route. It has to have the v6 address of the BR, used to = build a tunnel. The v4 route points then to that tunnel. >=20 > So, the reason that I said it's incompatible is that the current text = in the MAP base draft doesn't describe any way of getting the v6 address = of the BR other than those that can be provided with a BMR and FMRs. = I.e. An IPv4 default route with an IPv4 next hop which is in a map = domain which the CPE has an FMR for. lw4o6, which doesn't use mapping = rules cannot calculate the v6 address of the concentrator from a v4 next = hop address. >=20 > I realise that this is not how it is meant to work (and you've = confirmed that), but this is the only way that you could make it work = given the text that is actually in the draft and that's what I think = needs to be changed. This would bring the MAP/lw4o6 & unified CPE drafts = back in line=85 >=20 > =85 then we can have the discussion about what the best DHCP mechanism = to provision the client with the v6 address of the concentrator is :-) please propose text. the MAP base document does not specify the provisioning mechanism = itself. but it does specify which parameters need to be provisioned. section 7 states: For a given MAP domain, the BR and CE MUST be configured with the following MAP elements. The configured values for these elements are identical for all CEs and BRs within a given MAP domain. o The Basic Mapping Rule and optionally the Forwarding Mapping Rules, including the Rule IPv6 prefix, Rule IPv4 prefix, and Length of EA bits o The IPv6 address of the MAP BR. o Hub and spoke mode or Mesh mode. (If all traffic should be sent to the BR, or if direct CE to CE traffic should be supported). section 5.4 states: To reach IPv4 destinations outside of the MAP domain, traffic is sent to the configured address of the MAP BR. On the CE, the default can be represented as a point to point IPv4 over IPv6 tunnel [RFC2473] = to.. would it help you if section 5.4 states the "configured IPv6 address of = the MAP BR"? cheers, Ole From otroan@employees.org Wed Apr 10 06:22:44 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99FF821F905C for ; Wed, 10 Apr 2013 06:22:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EnKMFC5AHy52 for ; Wed, 10 Apr 2013 06:22:44 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id D5B2921F9030 for ; Wed, 10 Apr 2013 06:22:43 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlQJADZnZVGQ/khM/2dsb2JhbABQgwbBVQQEAYESFnSCHwEBBAF5BQsLRlcGiCEGvi2OYTMHgmBhA6gIgw06 X-IronPort-AV: E=Sophos;i="4.87,447,1363132800"; d="scan'208";a="152735566" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 10 Apr 2013 13:22:23 +0000 Received: from dhcp-lys02-vla252-10-147-116-14.cisco.com (dhcp-lys02-vla252-10-147-116-14.cisco.com [10.147.116.14]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r3ADMMoF002955 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 10 Apr 2013 13:22:22 GMT Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Ole Troan In-Reply-To: <516561BF.5080308@gmail.com> Date: Wed, 10 Apr 2013 15:22:22 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51633480.8070209@gmail.com> <28533DEA-0DD3-43DD-9CA4-929B0DBA9BDD@employees.org> <5163FBC3.3040602@gmail.com> <409980DC-2EDB-464F-9E12-E69CBF81268D@employees.org> <51649285.7050302@gmail.com> <35D6D53C-464D-476E-BF6C-97614F24259A@employees.org> <516561BF.5080308@gmail.com> To: Tom Taylor X-Mailer: Apple Mail (2.1503) Cc: Softwires Subject: Re: [Softwires] MAP-E question -- first prefix X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 13:22:44 -0000 Tom, > Looks like we had a misunderstanding. Did the authors think of the = configured subnetwork identifier of the existing text as being = configured for a particular rule, in effect another rule parameter? I = took it to be configured as a single value used in conjunction with all = FMRs to calculate the target MAP IPv6 addresses. apologies, I think I confused myself as well. if we were to support a configurable subnet-id, it would have to be a = per BMR/FMR property. the base document really just leaves the 'hook' for a provisioning = mechanism to use. cheers, Ole From tom.taylor.stds@gmail.com Wed Apr 10 06:29:46 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED43E21F97B0 for ; Wed, 10 Apr 2013 06:29:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.048 X-Spam-Level: X-Spam-Status: No, score=0.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5jmk-9n9y068 for ; Wed, 10 Apr 2013 06:29:46 -0700 (PDT) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 5922C21F9097 for ; Wed, 10 Apr 2013 06:29:46 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id c10so496476ieb.17 for ; Wed, 10 Apr 2013 06:29:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=CqvXyg9R/J4r4tSxmEaizumyETUsF9ixoxYepFWQZWo=; b=mc/1uvoZOE9rHUeft/0tryD3/+eTqldJDPXhFnwUAy8Uers+gZm57uEuyqXOFFoQtz bAR/VTWZQ/2MMhzNgLHbyfYU9bofDMrqdgzJIiHryS4W4RLJZYqKKmHPLiSWlBwemyUL KJotSCHDA50CxNy4aERT3VkijsPj+5ue1h4cSBbYtEH2zulCzcYZPtY18F3xMf6dcTUL coLLJ4OxmkZxmcfnw25cuuu3PJs5FCZlWSHQpM8XZePnFMK3F29jvBr84ulQUHZGTqSV 5aeruLnyC9aA+m6Goj8fBwIhBwjIlzJyBZV+zB9xxU93VnsmWxZGYn3QWyUIaAPUl9D1 NN5w== X-Received: by 10.50.73.133 with SMTP id l5mr1453603igv.108.1365600582742; Wed, 10 Apr 2013 06:29:42 -0700 (PDT) Received: from [192.168.1.65] (dsl-173-206-2-115.tor.primus.ca. [173.206.2.115]) by mx.google.com with ESMTPS id ie7sm27209687igb.1.2013.04.10.06.29.41 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 10 Apr 2013 06:29:42 -0700 (PDT) Message-ID: <51656944.9000906@gmail.com> Date: Wed, 10 Apr 2013 09:29:40 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Ole Troan References: <51633480.8070209@gmail.com> <28533DEA-0DD3-43DD-9CA4-929B0DBA9BDD@employees.org> <5163FBC3.3040602@gmail.com> <409980DC-2EDB-464F-9E12-E69CBF81268D@employees.org> <51649285.7050302@gmail.com> <35D6D53C-464D-476E-BF6C-97614F24259A@employees.org> <516561BF.5080308@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Softwires Subject: Re: [Softwires] MAP-E question -- first prefix X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 13:29:47 -0000 I'm happy to propose more text, but if that hook is going to be there, I think it should be shown explicitly as an optional part of what is provisioned for a MAP rule. On 10/04/2013 9:22 AM, Ole Troan wrote: > Tom, > >> Looks like we had a misunderstanding. Did the authors think of the configured subnetwork identifier of the existing text as being configured for a particular rule, in effect another rule parameter? I took it to be configured as a single value used in conjunction with all FMRs to calculate the target MAP IPv6 addresses. > > apologies, I think I confused myself as well. > if we were to support a configurable subnet-id, it would have to be a per BMR/FMR property. > > the base document really just leaves the 'hook' for a provisioning mechanism to use. > > cheers, > Ole > > From ian.farrer@telekom.de Wed Apr 10 06:38:16 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E57621F88BF for ; Wed, 10 Apr 2013 06:38:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oqWbxNvICbU0 for ; Wed, 10 Apr 2013 06:38:15 -0700 (PDT) Received: from tcmail43.telekom.de (tcmail43.telekom.de [80.149.113.173]) by ietfa.amsl.com (Postfix) with ESMTP id 274CA21F9609 for ; Wed, 10 Apr 2013 06:38:14 -0700 (PDT) Received: from he111628.emea1.cds.t-internal.com ([10.134.93.20]) by tcmail41.telekom.de with ESMTP/TLS/AES128-SHA; 10 Apr 2013 15:38:08 +0200 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE111628.emea1.cds.t-internal.com ([::1]) with mapi; Wed, 10 Apr 2013 15:37:47 +0200 From: To: Date: Wed, 10 Apr 2013 15:38:03 +0200 Thread-Topic: [Softwires] Working group last call for draft-ietf-softwire-map-05 Thread-Index: Ac418JX60F3sPyJvS42+wIeTgWU41Q== Message-ID: 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.2.130206 acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: softwires@ietf.org, cuiyong@tsinghua.edu.cn, rdroms@cisco.com Subject: Re: [Softwires] Working group last call for draft-ietf-softwire-map-05 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 13:38:16 -0000 Hi Ole, I think that the change that you've proposed would help. But actually the worst offender is in section 5: Port-aware IPv4 entries in the Rules table are installed for all the Forwarding Mapping Rules and an IPv4 default route to the MAP BR. What about if this read?: Port-aware IPv4 entries in the Rules table are installed for all the Forwarding Mapping Rules and an IPv4 default route via a tunnel to the MAP BR. Cheers, Ian On 10/04/2013 15:20, "Ole Troan" wrote: >Ian, > >> Thanks for that. So we actually aren't too far apart. There needs to be >>a DMR (or equivalent) that has the IPv6 address of the BR. >>=20 >> But, this is one thing that's been confusing me since the publication >>of (I think v03), where the DMR is no longer described, or mentioned >>anywhere in the MAP base draft. However it does still exist in the MAP >>DHCP option draft. But neither of the drafts actually describes what it >>is and how to use it. The current map 05 draft only discusses the use of >>an IPv4 route, which I think is misleading =AD the IPv6 address of the BR >>is also needed (as Ole's pointed out in his mail). >>=20 >> A DMR, or something functionally equivalent is necessary, but this is >>not just an IPv4 route. It has to have the v6 address of the BR, used to >>build a tunnel. The v4 route points then to that tunnel. >>=20 >> So, the reason that I said it's incompatible is that the current text >>in the MAP base draft doesn't describe any way of getting the v6 address >>of the BR other than those that can be provided with a BMR and FMRs. >>I.e. An IPv4 default route with an IPv4 next hop which is in a map >>domain which the CPE has an FMR for. lw4o6, which doesn't use mapping >>rules cannot calculate the v6 address of the concentrator from a v4 next >>hop address. >>=20 >> I realise that this is not how it is meant to work (and you've >>confirmed that), but this is the only way that you could make it work >>given the text that is actually in the draft and that's what I think >>needs to be changed. This would bring the MAP/lw4o6 & unified CPE drafts >>back in line=8A >>=20 >> =8A then we can have the discussion about what the best DHCP mechanism t= o >>provision the client with the v6 address of the concentrator is :-) > >please propose text. >the MAP base document does not specify the provisioning mechanism itself. >but it does specify which parameters need to be provisioned. > >section 7 states: > >For a given MAP domain, the BR and CE MUST be configured with the > following MAP elements. The configured values for these elements are > identical for all CEs and BRs within a given MAP domain. > > o The Basic Mapping Rule and optionally the Forwarding Mapping > Rules, including the Rule IPv6 prefix, Rule IPv4 prefix, and > Length of EA bits > > o The IPv6 address of the MAP BR. > > o Hub and spoke mode or Mesh mode. (If all traffic should be sent > to the BR, or if direct CE to CE traffic should be supported). > > >section 5.4 states: > To reach IPv4 destinations outside of the MAP domain, traffic is sent > to the configured address of the MAP BR. On the CE, the default can > be represented as a point to point IPv4 over IPv6 tunnel [RFC2473] to.. > > >would it help you if section 5.4 states the "configured IPv6 address of >the MAP BR"? > >cheers, >Ole > > > > From internet-drafts@ietf.org Wed Apr 10 07:30:17 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E1EF21F9745; Wed, 10 Apr 2013 07:30:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.305 X-Spam-Level: X-Spam-Status: No, score=-102.305 tagged_above=-999 required=5 tests=[AWL=0.295, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KGH3ZldQzsZB; Wed, 10 Apr 2013 07:30:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F028121F9382; Wed, 10 Apr 2013 07:30:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.43.p4 Message-ID: <20130410143016.475.74165.idtracker@ietfa.amsl.com> Date: Wed, 10 Apr 2013 07:30:16 -0700 Cc: softwires@ietf.org Subject: [Softwires] I-D Action: draft-ietf-softwire-lw4over6-00.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: