From simon.perreault@viagenie.ca Mon Jan 6 13:57:32 2014 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C191F1AE270 for ; Mon, 6 Jan 2014 13:57:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.54 X-Spam-Level: X-Spam-Status: No, score=-0.54 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fHBrH0RtnQnj for ; Mon, 6 Jan 2014 13:57:29 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 02DF91AE1C1 for ; Mon, 6 Jan 2014 13:57:28 -0800 (PST) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:b58e:42d9:afe:377b]) by jazz.viagenie.ca (Postfix) with ESMTPSA id ACF1F403BE; Mon, 6 Jan 2014 16:57:19 -0500 (EST) Message-ID: <52CB26BF.4080209@viagenie.ca> Date: Mon, 06 Jan 2014 16:57:19 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Ole Troan References: <52A88ACF.7000207@viagenie.ca> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "softwires@ietf.org" Subject: Re: [Softwires] WGLC review of draft-ietf-softwire-map X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jan 2014 21:57:33 -0000 Le 2014-01-02 12:11, Ole Troan a écrit : >> 1. The distinction between BMR and FMR is very confusing. And it's going to get even more confusing when the reader gets to draft-ietf-softwire-map-dhcp, where there is only a single unified "rule" parameter. Suggestion: remove the concept of FMR. The text already says that the BMR is an FMR, so this means that FMR is already conceptually equal to "MAP rule". So just replace FMR with "MAP rule". Then say that one of the MAP rules is special: it is the BMR. I've provided text inline below. > > "Mapping rules are used differently depending on their function. > Every MAP node must be provisioned with a Basic mapping rule. This > is used by the node to configure its IPv4 address, IPv4 prefix or > shared IPv4 address. This same basic rule can also be used for > forwarding, where an IPv4 destination address and optionally a > destination port is mapped into an IPv6 address. Additional mapping > rules are specified to allow for multiple different IPv4 sub-nets to > exist within the domain and optimize forwarding between them." > > isn't this text clear enough? > the analogy of BMR versus FMR, is a router advertisement with two PIO's, one PIO with the A flag set > and optionally the L flag, and one PIO with the A flag off and the L flag set. > we've chosen to give those different names to be very clear on their purpose. > I would claim that it is more confusing and harder to understand the effects of the A/L flags in the PIO example. ;-) > > suggested action: keep the BMR/FMR distinction. I'm not against that suggestion, as long as the other (previously agreed) adjustments are made. That is, right now the BMR/FMR distinction doesn't make sense because the text says a BMR is an FMR. If that is fixed, then at least we can have a BMR/FMR distinction that makes sense. Not my preference, but it will work. Specifically, a BMR it not an FMR because its L flag (to reuse the PIO analogy) may be off, whereas for an FMR it is always on. >> 2. Section 5 says: >> >> 1. Basic Mapping Rule (BMR) - mandatory. [...] >> The Basic Mapping Rule is also a Forwarding Mapping Rule. [...] >> In hub and spoke mode, there are no forwarding rules [...] >> >> Contradiction? There must be at least one FMR since the BMR is an FMR and it is mandatory. > > hmm... good point. this is the equivalent of a single RA PIO with the A flag on and L flag off. > that is all traffic goes through the BR. what about: > > "In hub and spoke mode, there are no forwarding rules, apart from the default rule to the BR" Ok. >> 3. I can't make sense of this part from section 5.1: >> >> For a > 0, A MUST be larger than 0. [...] >> For smaller values of a, A still has to be greater than 0 [...] >> For larger values of a, the minimum value of A has to be higher [...] >> >> Smaller than what? Larger than what? If a is smaller than a>0, that means a=0. How can A then be greater than 0 if it is 0 bits long? >> >> Further comments inline... > > agree. I can't make sense of it either. ;-) > > OLD: > A Selects the range of the port number. For a > 0, A MUST be larger > than 0. This ensures that the algorithm excludes the system > ports. For this value of a, the system ports, but no others, are > excluded by requiring that A be greater than 0. For smaller > values of a, A still has to be greater than 0, but this excludes > ports above 1023. For larger values of a, the minimum value of A > has to be higher to exclude all the system ports. The interval > between successive contiguous ranges assigned to the same user is > 2^a. > > Proposed: > A Selects the range of the port number. For a > 0, A MUST be larger > than 0. This ensures that the algorithm excludes the system > ports. For the default value of a (6), the system ports, are > excluded by requiring that A be greater than 0. Smaller > values of a excludes a larger initial range. E.g. a = 4, will exclude ports 0 - 4095. > The interval between successive contiguous ranges assigned to the same user is > 2^a. Looks good. >>> A companion document defines a DHCPv6 option for provisioning of MAP >> >> A companion document defines DHCPv6 options for provisioning of Softwire clients > > I'm not sure that we should introduce "softwire clients" as a new term here. I see. Then keep it as is. >>> MAP node A device that implements MAP. >> >> Implementation has nothing to do with it. >> >> s/implements MAP/participates in a MAP domain/ > > implements as in "supports/uses", not implement as the act of coding. > see http://tools.ietf.org/html/rfc4861#section-2 for a node. I understand, and thanks for the reference, but I still think that this is wrong. From the point of view of the protocol spec, there is no difference between a node that does not implement MAP and a node that implements MAP but has it turned off. Both are not MAP nodes, again from the point of view of the protocol spec. Unless you want to distinguish between nodes that have the MAP function turned off and those that have it turned on, which I don't think you do in the current text. Anyhow, this is mostly a style issue, I don't care too much. >>> This architecture is illustrated in Figure 1. >>> >>> >>> User N >>> Private IPv4 >>> | Network >>> | >>> O--+---------------O >>> | | MAP CE | >>> | +-----+--------+ | >>> | NAPT44| MAP | | >>> | +-----+ | | |\ ,-------. .------. >> >> Remove this --------^ > > > >> >>> | +--------+ | \ ,-' `-. ,-' `-. >>> O------------------O / \ O---------O / Public \ >>> / IPv6 only \ | MAP | / IPv4 \ >>> ( Network --+ Border +- Network ) >>> \ (MAP Domain) / | Relay | \ / >>> O------------------O \ / O---------O \ / >>> | MAP CE | /". ,-' `-. ,-' >>> | +-----+--------+ | / `----+--' ------' >>> | NAPT44| MAP | |/ >>> | +-----+ | | >>> | | +--------+ | >>> O---.--------------O >> >> s/./+/ > > I'm not quite sure what you mean, could you give a complete figure with your suggested changes? Hehehehe, sure: OLD: User N Private IPv4 | Network | O--+---------------O | | MAP CE | | +-----+--------+ | | NAPT44| MAP | | | +-----+ | | |\ ,-------. .------. | +--------+ | \ ,-' `-. ,-' `-. O------------------O / \ O---------O / Public \ / IPv6 only \ | MAP | / IPv4 \ ( Network --+ Border +- Network ) \ (MAP Domain) / | Relay | \ / O------------------O \ / O---------O \ / | MAP CE | /". ,-' `-. ,-' | +-----+--------+ | / `----+--' ------' | NAPT44| MAP | |/ | +-----+ | | | | +--------+ | O---.--------------O | User M Private IPv4 Network NEW: User N Private IPv4 | Network | O--+---------------O | | MAP CE | | +-----+--------+ | | NAPT44| MAP | | | +-----+ | |\ ,-------. .------. | +--------+ | \ ,-' `-. ,-' `-. O------------------O / \ O---------O / Public \ / IPv6 only \ | MAP | / IPv4 \ ( Network --+ Border +- Network ) \ (MAP Domain) / | Relay | \ / O------------------O \ / O---------O \ / | MAP CE | /". ,-' `-. ,-' | +-----+--------+ | / `----+--' ------' | NAPT44| MAP | |/ | +-----+ | | | | +--------+ | O---+--------------O | User M Private IPv4 Network >>> Port-aware IPv4 entries in the Rules table are installed for all the >> >> What is a "port-aware IPv4 entry"? > > yes, that's not clear. let me wordsmith. > >>> Forwarding Mapping Rules and an default route to the MAP BR (see >> >> s/Forwarding Mapping Rules/MAP rules/ >> >> s/an/a/ > > ack. > >> >>> section Section 5.4. >> >> That paragraph was very unclear. Reword. > > any suggestion? I just spent some time trying to come up with better text but I realized all of it is repeated from elsewhere. Section 5.3: On forwarding an IPv4 packet, a best matching prefix look up is done in the Rules table and the correct FMR is chosen. Section 5: Traffic outside of the domain (i.e. When the destination IPv4 address does not match (using longest matching prefix) any Rule IPv4 prefix in the Rules database) is forwarded to the BR. So you could just delete it I guess. >>> 0 1 >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 >> >> Move the two lines above to the right by one character. > > hmm, I don't see that error? Assuming you want to number bits and not frontiers between bits, the 0 should be aligned with the first bit. And I just noticed that index 16 needs to be removed. OLD: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 +-----------+-----------+-------+ Ports in | A | PSID | M | the CE port set | > 0 | | | +-----------+-----------+-------+ | a bits | k bits |m bits | NEW: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-----------+-----------+-------+ Ports in | A | PSID | M | the CE port set | > 0 | | | +-----------+-----------+-------+ | a bits | k bits |m bits | >>> 5.2. Basic mapping rule (BMR) >>> >>> The Basic Mapping Rule is mandatory, used by the CE to provision >>> itself with an IPv4 prefix, IPv4 address or shared IPv4 address. >>> Recall from Section 5 that the BMR consists of the following >> >> s/the BMR/a MAP rule/ > > this is specifically about the BMR though. Right, but when reading this text I got confused when I reached section 5.2 on FMRs since that reference to Section 5 made me think that Section 5 only applied to BMRs. Anyhow, this is very minor. >>> 5.3. Forwarding mapping rule (FMR) >> >> Rename this section to: "Deriving IPv4 routes from MAP rules" > > see top. Well, the problem with this is that this section *does* apply to BMRs as well, unless I am mistaken... >>> | 32 bits | | 16 bits | >>> +--------------------------+ +-------------------+ >>> | IPv4 destination address | | IPv4 dest port | >>> +--------------------------+ +-------------------+ >>> : : ___/ : >>> | p bits | / q bits : >>> +----------+ +------------+ >>> |IPv4 sufx| |Port-Set ID | >>> +----------+ +------------+ >>> \ / ____/ ________/ >>> \ : __/ _____/ >>> \ : / / >>> | n bits | o bits | s bits | 128-n-o-s bits | >>> +--------------------+-----------+---------+------------+----------+ >>> | Rule IPv6 prefix | EA bits |subnet ID| interface ID | >>> +--------------------+-----------+---------+-----------------------+ >>> |<--- End-user IPv6 prefix --->| >> >> Remove the above line, because only the BMR contains the End-user IPv6 prefix. In general, MAP rules do not (unless we start referring to other user's End-user IPv6 prefix, but that would become confusing very quickly). > > the BMR doesn't contain the End-user ipv6 prefix either. Hmmm... right. So remove it from both Figure 3 and Figure 7? >>> Figure 7: Deriving of MAP IPv6 address >> >> s/MAP IPv6 address/IPv4 route/ > > where? In "Figure 7: Deriving of MAP IPv6 address". ;) >> A CE that allows >>> IPv6 configuration by DHCP SHOULD implement this option. >> >> Which one? It needs to be introduced earlier. > > with the informative references I suggest we drop this sentence. WFM. >>> A single MAP CE MAY be connected to more than one MAP domain, just as >>> any router may have more than one IPv4-enabled service provider >>> facing interface and more than one set of associated addresses >>> assigned by DHCP. Each domain a given CE operates within would >>> require its own set of MAP configuration elements and would generate >>> its own IPv4 address. >> >> But we're still limited to one MAP domain per End-user IPv6 prefix, right? > > yes. How about adding: "Note that each MAP domain requires a distinct End-User IPv6 prefix." >>> For increased reliability and load balancing, the BR IPv6 address MAY >>> be an anycast address shared across a given MAP domain. As MAP is >>> stateless, any BR may be used at any time. If the BR IPv6 address is >>> anycast the relay MUST use this anycast IPv6 address as the source >>> address in packets relayed to CEs. >> >> What about IPv4 anycast? > > what about it? Uh, nevermind, I don't remember, sorry. >>> For a shared IPv4 address, a MAP CE forwarding IPv4 packets from the >>> LAN performs NAT44 functions first and creates appropriate NAT44 >>> bindings. The resulting IPv4 packets MUST contain the source IPv4 >>> address and source transport identifiers defined by MAP. The IPv4 >> >> s/defined by/obtained with/ > > specified by? ok. >>> A MAP CE receiving an IPv6 packet to its MAP IPv6 address sends this >>> packet to the CE's MAP function where it is decapsulated. All other >>> IPv6 traffic is forwarded as per the CE's IPv6 routing rules. The >>> resulting IPv4 packet is then forwarded to the CE's NAT44 function >>> where the destination port number MUST be checked against the >>> stateful port mapping session table and the destination port number >>> MUST be mapped to its original value. >> >> The previous sentence should be reworded to allow static port forwarding. > > hmm, what do you mean by static port forwarding? For example, the user goes to the CPE's admin web interface and configures a mapping from external port 80 to internal host port 80. That's a static mapping that needs to be taken into account by the NAT function. The MUSTs above don't seem to allow the necessary wiggle room. >>> A MAP BR receiving IPv6 packets selects a best matching MAP domain >>> rule based on a longest address match of the packets' source address >>> against the BR's configured MAP BMR prefix(es), as well as a match of >> >> The BR, being a MAP node, can only have a single BMR, and therefore only one BMR prefix. The alternative would be when the BR is part of multiple MAP domains, which is not what I think you're trying to say. So I'm confused. > > I think the intention is to pick the right domain, given that it states "MAP domain rule". > does anyone else know, have suggestions for better text? I think what confused me is the phrase "the BR's configured MAP BMR prefix(es)". What are those? Maybe introducing them in section 7.2 would reduce possible confusion... >>> the packet destination address against the configured BR IPv6 address >>> or FMR prefix(es). The selected MAP rule allows the BR to determine >> >> The "FMR prefix" concept has not been defined by this point. > > I can expand that to "FMR Rule IPv6 prefix". WFM. >> It should be possible to express this using only "MAP rule". > > the BR address isn't a MAP rule, which is why it is written like that. > >>> the EA-bits from the source IPv6 address. The BR MUST perform a >>> validation of the consistency of the source IPv6 address and source >>> port number for the packet using BMR. If the packets source port >> >> "source IPv6 address and source port number" --> I don't know which port number this refers to. Especially since later text deals with port numbers... > > I'm not sure I understand your concern? isn't the "source port" a known term? e.g. RFC768? > or is this because there seems to be some redundancy between this paragraph and the next? Hehehe... I was just wondering if in the phrase "source IPv6 address and source port number", the "source port number" is the IPv6 source port or the IPv4 source port. I suppose it would be the IPv4 source port since that's what you're supposed to verify with the BMR, and there are no IPv6 port anyway with protocol 41. That would make sense to me, however the next paragraph also deals with IPv4 source port validation. So is it just a matter of redundancy between paragraphs, or is my understanding incorrect? > that was a lot! thanks a lot for very good and thorough comment! > > and if anyone else has gotten all the way down here. > Happy New Year! Likewise! Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From suresh.krishnan@ericsson.com Mon Jan 13 20:46:30 2014 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B006C1AE1BF for ; Mon, 13 Jan 2014 20:46:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r9Qr3U34oKpf for ; Mon, 13 Jan 2014 20:46:29 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 2036C1AE1BC for ; Mon, 13 Jan 2014 20:46:29 -0800 (PST) X-AuditID: c6180641-b7fbd8e0000011cc-19-52d4c1194f08 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 8C.52.04556.911C4D25; Tue, 14 Jan 2014 05:46:17 +0100 (CET) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.02.0347.000; Mon, 13 Jan 2014 23:46:16 -0500 From: Suresh Krishnan To: Softwires WG Thread-Topic: Working group last call for draft-ietf-softwire-lw4over6-03 Thread-Index: Ac8Q447AA9x4sBSRTByZtDHiECb2Nw== Date: Tue, 14 Jan 2014 04:46:16 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrMLMWRmVeSWpSXmKPExsUyuXRPiK7kwStBBsf/yVv82JJscXjZViYH Jo8lS34yeRz//JY5gCmKyyYlNSezLLVI3y6BK+PWxsVMBQ1sFS9WnGdpYGxj7WLk5JAQMJF4 v3IyC4QtJnHh3nq2LkYuDiGBI4wSh1a8YIFwljNKNO/cxghSxQbUsWHnZyYQW0RAVeLJzgds IDazgJrEzOc/geIcHMICLhL3tiVDlHhK3JpzmhkkLCKgJzH7rz9ImAWos2dzH1gnr4CvxNlX K5lBbEagG76fWsMEMVFc4taT+UwQtwlILNlznhnCFpV4+fgf1P3KEt/nPGKBqNeRWLD7E9Q1 2hLLFr5mhpgvKHFy5hOWCYwis5CMnYWkZRaSlllIWhYwsqxi5CgtTi3LTTcy3MQIDPhjEmyO OxgXfLI8xCjNwaIkzvvlrXOQkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBsYNRxvv3ku1tL7G eO6lQc2NMoVdBVc0/hdpCvkUt6/SntO7kN1QVmtfeMcv68jOqQuu8wYkHDLOLsjMmyZuuHjO jYLfnJefr5/xxslp0tKl51w6znB6fzhmfM3WNuvqW+OOHfv/Trmr96z//0K9RS021vnLv0za piL/cJPAJsHmz8xXtrWzJ7krsRRnJBpqMRcVJwIAGbqH2EYCAAA= Cc: Yong Cui Subject: [Softwires] Working group last call for draft-ietf-softwire-lw4over6-03 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 04:46:30 -0000 Hi all,=0A= This message starts a two week softwire working group last call on =0A= advancing the draft about Lightweight 4over6 as a Standards Track RFC. =0A= The authors believe that this version has addressed all the issues =0A= raised on the document till now. The latest version of the draft is =0A= available at=0A= =0A= http://www.ietf.org/id/draft-ietf-softwire-lw4over6-03.txt=0A= http://tools.ietf.org/html/draft-ietf-softwire-lw4over6-03=0A= =0A= Substantive comments and statements of support/opposition for advancing =0A= this document should be directed to the mailing list. Editorial =0A= suggestions can be sent directly to the authors. This last call will =0A= conclude on January 28, 2014.=0A= =0A= Regards,=0A= Suresh & Yong=0A= From internet-drafts@ietf.org Tue Jan 14 23:56:24 2014 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 756CB1AE335; Tue, 14 Jan 2014 23:56:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K3tzz7DC8Max; Tue, 14 Jan 2014 23:56:23 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B2C31AE050; Tue, 14 Jan 2014 23:56:23 -0800 (PST) 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.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140115075623.27117.2926.idtracker@ietfa.amsl.com> Date: Tue, 14 Jan 2014 23:56:23 -0800 Cc: softwires@ietf.org Subject: [Softwires] I-D Action: draft-ietf-softwire-mesh-multicast-06.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2014 07:56:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Softwires Working Group of the IETF. Title : Softwire Mesh Multicast Authors : Mingwei Xu Yong Cui Jianping Wu Shu Yang Chris Metz Greg Shepherd Filename : draft-ietf-softwire-mesh-multicast-06.txt Pages : 21 Date : 2014-01-14 Abstract: The Internet needs to support IPv4 and IPv6 packets. Both address families and their attendant protocol suites support multicast of the single-source and any-source varieties. As part of the transition to IPv6, there will be scenarios where a backbone network running one IP address family internally (referred to as internal IP or I-IP) will provide transit services to attached client networks running another IP address family (referred to as external IP or E-IP). It is expected that the I-IP backbone will offer unicast and multicast transit services to the client E-IP networks. Softwire Mesh is a solution to E-IP unicast and multicast support across an I-IP backbone. This document describes the mechanisms for supporting Internet-style multicast across a set of E-IP and I-IP networks supporting softwire mesh. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-softwire-mesh-multicast/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-softwire-mesh-multicast-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-softwire-mesh-multicast-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From otroan@employees.org Wed Jan 15 04:15:05 2014 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC0441AE06A for ; Wed, 15 Jan 2014 04:15:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iTlzkPZJk3gl for ; Wed, 15 Jan 2014 04:15:02 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id D22CE1AE368 for ; Wed, 15 Jan 2014 04:15:01 -0800 (PST) X-Files: signature.asc : 496 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AikFAAZ71lKQ/khN/2dsb2JhbABagws4u1OBFRZ0giUBAQEDASdSBQsLEhsZSQ4GiA8IDcQLF44vWAcKgxqBEwSQN4kXkGWDLjuBLAIeBg X-IronPort-AV: E=Sophos;i="4.95,662,1384300800"; d="asc'?scan'208";a="2988894" Received: from ams-core-4.cisco.com ([144.254.72.77]) by aer-iport-2.cisco.com with ESMTP; 15 Jan 2014 12:14:49 +0000 Received: from dhcp-lys01-vla250-10-147-113-220.cisco.com (dhcp-lys01-vla250-10-147-113-220.cisco.com [10.147.113.220]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s0FCElRi003593 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 15 Jan 2014 12:14:48 GMT Content-Type: multipart/signed; boundary="Apple-Mail=_B9E7065A-254D-41C3-90B7-70956AEFF303"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ole Troan In-Reply-To: <52CB26BF.4080209@viagenie.ca> Date: Wed, 15 Jan 2014 13:14:47 +0100 Message-Id: References: <52A88ACF.7000207@viagenie.ca> <52CB26BF.4080209@viagenie.ca> To: Simon Perreault X-Mailer: Apple Mail (2.1827) Cc: "softwires@ietf.org" Subject: Re: [Softwires] WGLC review of draft-ietf-softwire-map X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2014 12:15:06 -0000 --Apple-Mail=_B9E7065A-254D-41C3-90B7-70956AEFF303 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Simon, apologies for the late reply. day job in the way. >>> 1. The distinction between BMR and FMR is very confusing. And it's = going to get even more confusing when the reader gets to = draft-ietf-softwire-map-dhcp, where there is only a single unified = "rule" parameter. Suggestion: remove the concept of FMR. The text = already says that the BMR is an FMR, so this means that FMR is already = conceptually equal to "MAP rule". So just replace FMR with "MAP rule". = Then say that one of the MAP rules is special: it is the BMR. I've = provided text inline below. >>=20 >> "Mapping rules are used differently depending on their function. >> Every MAP node must be provisioned with a Basic mapping rule. = This >> is used by the node to configure its IPv4 address, IPv4 prefix or >> shared IPv4 address. This same basic rule can also be used for >> forwarding, where an IPv4 destination address and optionally a >> destination port is mapped into an IPv6 address. Additional = mapping >> rules are specified to allow for multiple different IPv4 sub-nets = to >> exist within the domain and optimize forwarding between them." >>=20 >> isn't this text clear enough? >> the analogy of BMR versus FMR, is a router advertisement with two = PIO's, one PIO with the A flag set >> and optionally the L flag, and one PIO with the A flag off and the L = flag set. >> we've chosen to give those different names to be very clear on their = purpose. >> I would claim that it is more confusing and harder to understand the = effects of the A/L flags in the PIO example. ;-) >>=20 >> suggested action: keep the BMR/FMR distinction. >=20 > I'm not against that suggestion, as long as the other (previously = agreed) adjustments are made. That is, right now the BMR/FMR distinction = doesn't make sense because the text says a BMR is an FMR. If that is = fixed, then at least we can have a BMR/FMR distinction that makes sense. = Not my preference, but it will work. >=20 > Specifically, a BMR it not an FMR because its L flag (to reuse the PIO = analogy) may be off, whereas for an FMR it is always on. good. the text now says the BMR may be an FMR. e.g. in mesh mode a BMR may also be used for forwarding, but in hub and = spoke mode, the BMR is not used for forwarding. >>> 2. Section 5 says: >>>=20 >>> 1. Basic Mapping Rule (BMR) - mandatory. [...] >>> The Basic Mapping Rule is also a Forwarding Mapping Rule. = [...] >>> In hub and spoke mode, there are no forwarding rules [...] >>>=20 >>> Contradiction? There must be at least one FMR since the BMR is an = FMR and it is mandatory. >>=20 >> hmm... good point. this is the equivalent of a single RA PIO with the = A flag on and L flag off. >> that is all traffic goes through the BR. what about: >>=20 >> "In hub and spoke mode, there are no forwarding rules, apart from the = default rule to the BR" >=20 > Ok. >=20 >>> 3. I can't make sense of this part from section 5.1: >>>=20 >>> For a > 0, A MUST be larger than 0. [...] >>> For smaller values of a, A still has to be greater than 0 [...] >>> For larger values of a, the minimum value of A has to be higher = [...] >>>=20 >>> Smaller than what? Larger than what? If a is smaller than a>0, that = means a=3D0. How can A then be greater than 0 if it is 0 bits long? >>>=20 >>> Further comments inline... >>=20 >> agree. I can't make sense of it either. ;-) >>=20 >> OLD: >> A Selects the range of the port number. For a > 0, A MUST be = larger >> than 0. This ensures that the algorithm excludes the system >> ports. For this value of a, the system ports, but no others, = are >> excluded by requiring that A be greater than 0. For smaller >> values of a, A still has to be greater than 0, but this = excludes >> ports above 1023. For larger values of a, the minimum value of = A >> has to be higher to exclude all the system ports. The interval >> between successive contiguous ranges assigned to the same user = is >> 2^a. >>=20 >> Proposed: >> A Selects the range of the port number. For a > 0, A MUST be = larger >> than 0. This ensures that the algorithm excludes the system >> ports. For the default value of a (6), the system ports, are >> excluded by requiring that A be greater than 0. Smaller >> values of a excludes a larger initial range. E.g. a =3D 4, will = exclude ports 0 - 4095. >> The interval between successive contiguous ranges assigned to = the same user is >> 2^a. >=20 > Looks good. >=20 >>>> A companion document defines a DHCPv6 option for provisioning of = MAP >>>=20 >>> A companion document defines DHCPv6 options for provisioning of = Softwire clients >>=20 >> I'm not sure that we should introduce "softwire clients" as a new = term here. >=20 > I see. Then keep it as is. >=20 >>>> MAP node A device that implements MAP. >>>=20 >>> Implementation has nothing to do with it. >>>=20 >>> s/implements MAP/participates in a MAP domain/ >>=20 >> implements as in "supports/uses", not implement as the act of coding. >> see http://tools.ietf.org/html/rfc4861#section-2 for a node. >=20 > I understand, and thanks for the reference, but I still think that = this is wrong. >=20 > =46rom the point of view of the protocol spec, there is no difference = between a node that does not implement MAP and a node that implements = MAP but has it turned off. Both are not MAP nodes, again from the point = of view of the protocol spec. Unless you want to distinguish between = nodes that have the MAP function turned off and those that have it = turned on, which I don't think you do in the current text. >=20 > Anyhow, this is mostly a style issue, I don't care too much. thanks. ;-) >>>> This architecture is illustrated in Figure 1. >>>>=20 >>>>=20 >>>> User N >>>> Private IPv4 >>>> | Network >>>> | >>>> O--+---------------O >>>> | | MAP CE | >>>> | +-----+--------+ | >>>> | NAPT44| MAP | | >>>> | +-----+ | | |\ ,-------. .------. >>>=20 >>> Remove this --------^ >>=20 >>=20 >>=20 >>>=20 >>>> | +--------+ | \ ,-' `-. ,-' = `-. >>>> O------------------O / \ O---------O / Public = \ >>>> / IPv6 only \ | MAP | / IPv4 = \ >>>> ( Network --+ Border +- Network = ) >>>> \ (MAP Domain) / | Relay | \ = / >>>> O------------------O \ / O---------O \ = / >>>> | MAP CE | /". ,-' `-. = ,-' >>>> | +-----+--------+ | / `----+--' ------' >>>> | NAPT44| MAP | |/ >>>> | +-----+ | | >>>> | | +--------+ | >>>> O---.--------------O >>>=20 >>> s/./+/ >>=20 >> I'm not quite sure what you mean, could you give a complete figure = with your suggested changes? >=20 > Hehehehe, sure: >=20 > OLD: > User N > Private IPv4 > | Network > | > O--+---------------O > | | MAP CE | > | +-----+--------+ | > | NAPT44| MAP | | > | +-----+ | | |\ ,-------. .------. > | +--------+ | \ ,-' `-. ,-' `-. > O------------------O / \ O---------O / Public \ > / IPv6 only \ | MAP | / IPv4 = \ > ( Network --+ Border +- Network = ) > \ (MAP Domain) / | Relay | \ = / > O------------------O \ / O---------O \ = / > | MAP CE | /". ,-' `-. ,-' > | +-----+--------+ | / `----+--' ------' > | NAPT44| MAP | |/ > | +-----+ | | > | | +--------+ | > O---.--------------O > | > User M > Private IPv4 > Network >=20 > NEW: > User N > Private IPv4 > | Network > | > O--+---------------O > | | MAP CE | > | +-----+--------+ | > | NAPT44| MAP | | > | +-----+ | |\ ,-------. .------. > | +--------+ | \ ,-' `-. ,-' `-. > O------------------O / \ O---------O / Public \ > / IPv6 only \ | MAP | / IPv4 = \ > ( Network --+ Border +- Network = ) > \ (MAP Domain) / | Relay | \ = / > O------------------O \ / O---------O \ = / > | MAP CE | /". ,-' `-. ,-' > | +-----+--------+ | / `----+--' ------' > | NAPT44| MAP | |/ > | +-----+ | | > | | +--------+ | > O---+--------------O > | > User M > Private IPv4 > Network found it! ;-) >>>> Port-aware IPv4 entries in the Rules table are installed for all = the >>>=20 >>> What is a "port-aware IPv4 entry"? >>=20 >> yes, that's not clear. let me wordsmith. >>=20 >>>> Forwarding Mapping Rules and an default route to the MAP BR (see >>>=20 >>> s/Forwarding Mapping Rules/MAP rules/ >>>=20 >>> s/an/a/ >>=20 >> ack. >>=20 >>>=20 >>>> section Section 5.4. >>>=20 >>> That paragraph was very unclear. Reword. >>=20 >> any suggestion? >=20 > I just spent some time trying to come up with better text but I = realized all of it is repeated from elsewhere. >=20 > Section 5.3: > On forwarding an IPv4 packet, a best matching prefix look up is done > in the Rules table and the correct FMR is chosen. >=20 > Section 5: > Traffic outside of the domain (i.e. When the destination IPv4 = address > does not match (using longest matching prefix) any Rule IPv4 prefix > in the Rules database) is forwarded to the BR. >=20 > So you could just delete it I guess. >=20 >>>> 0 1 >>>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 >>>=20 >>> Move the two lines above to the right by one character. >>=20 >> hmm, I don't see that error? >=20 > Assuming you want to number bits and not frontiers between bits, the 0 = should be aligned with the first bit. And I just noticed that index 16 = needs to be removed. >=20 > OLD: > 0 1 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 > +-----------+-----------+-------+ > Ports in | A | PSID | M | > the CE port set | > 0 | | | > +-----------+-----------+-------+ > | a bits | k bits |m bits | >=20 > NEW: > 0 1 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 > +-----------+-----------+-------+ > Ports in | A | PSID | M | > the CE port set | > 0 | | | > +-----------+-----------+-------+ > | a bits | k bits |m bits | thanks, fixed. >=20 >>>> 5.2. Basic mapping rule (BMR) >>>>=20 >>>> The Basic Mapping Rule is mandatory, used by the CE to provision >>>> itself with an IPv4 prefix, IPv4 address or shared IPv4 address. >>>> Recall from Section 5 that the BMR consists of the following >>>=20 >>> s/the BMR/a MAP rule/ >>=20 >> this is specifically about the BMR though. >=20 > Right, but when reading this text I got confused when I reached = section 5.2 on FMRs since that reference to Section 5 made me think that = Section 5 only applied to BMRs. >=20 > Anyhow, this is very minor. >=20 >>>> 5.3. Forwarding mapping rule (FMR) >>>=20 >>> Rename this section to: "Deriving IPv4 routes from MAP rules" >>=20 >> see top. >=20 > Well, the problem with this is that this section *does* apply to BMRs = as well, unless I am mistaken... only to the extent that it applies to it when it is also an FMR. >=20 >>>> | 32 bits | | 16 bits | >>>> +--------------------------+ +-------------------+ >>>> | IPv4 destination address | | IPv4 dest port | >>>> +--------------------------+ +-------------------+ >>>> : : ___/ : >>>> | p bits | / q bits : >>>> +----------+ +------------+ >>>> |IPv4 sufx| |Port-Set ID | >>>> +----------+ +------------+ >>>> \ / ____/ ________/ >>>> \ : __/ _____/ >>>> \ : / / >>>> | n bits | o bits | s bits | 128-n-o-s bits = | >>>> = +--------------------+-----------+---------+------------+----------+ >>>> | Rule IPv6 prefix | EA bits |subnet ID| interface ID = | >>>> = +--------------------+-----------+---------+-----------------------+ >>>> |<--- End-user IPv6 prefix --->| >>>=20 >>> Remove the above line, because only the BMR contains the End-user = IPv6 prefix. In general, MAP rules do not (unless we start referring to = other user's End-user IPv6 prefix, but that would become confusing very = quickly). >>=20 >> the BMR doesn't contain the End-user ipv6 prefix either. >=20 > Hmmm... right. So remove it from both Figure 3 and Figure 7? it is there to help understand where the bits come from. >=20 >>>> Figure 7: Deriving of MAP IPv6 address >>>=20 >>> s/MAP IPv6 address/IPv4 route/ >>=20 >> where? >=20 > In "Figure 7: Deriving of MAP IPv6 address". ;) I believe the figure title is correct. i.e. it refers to the tunnel = endpoint address that you derive from the IPv4 address and port. >=20 >>> A CE that allows >>>> IPv6 configuration by DHCP SHOULD implement this option. >>>=20 >>> Which one? It needs to be introduced earlier. >>=20 >> with the informative references I suggest we drop this sentence. >=20 > WFM. >=20 >>>> A single MAP CE MAY be connected to more than one MAP domain, = just as >>>> any router may have more than one IPv4-enabled service provider >>>> facing interface and more than one set of associated addresses >>>> assigned by DHCP. Each domain a given CE operates within would >>>> require its own set of MAP configuration elements and would = generate >>>> its own IPv4 address. >>>=20 >>> But we're still limited to one MAP domain per End-user IPv6 prefix, = right? >>=20 >> yes. >=20 > How about adding: "Note that each MAP domain requires a distinct = End-User IPv6 prefix." agree, added. >=20 >>>> For increased reliability and load balancing, the BR IPv6 address = MAY >>>> be an anycast address shared across a given MAP domain. As MAP = is >>>> stateless, any BR may be used at any time. If the BR IPv6 = address is >>>> anycast the relay MUST use this anycast IPv6 address as the = source >>>> address in packets relayed to CEs. >>>=20 >>> What about IPv4 anycast? >>=20 >> what about it? >=20 > Uh, nevermind, I don't remember, sorry. >=20 >>>> For a shared IPv4 address, a MAP CE forwarding IPv4 packets from = the >>>> LAN performs NAT44 functions first and creates appropriate NAT44 >>>> bindings. The resulting IPv4 packets MUST contain the source = IPv4 >>>> address and source transport identifiers defined by MAP. The = IPv4 >>>=20 >>> s/defined by/obtained with/ >>=20 >> specified by? >=20 > ok. >=20 >>>> A MAP CE receiving an IPv6 packet to its MAP IPv6 address sends = this >>>> packet to the CE's MAP function where it is decapsulated. All = other >>>> IPv6 traffic is forwarded as per the CE's IPv6 routing rules. = The >>>> resulting IPv4 packet is then forwarded to the CE's NAT44 = function >>>> where the destination port number MUST be checked against the >>>> stateful port mapping session table and the destination port = number >>>> MUST be mapped to its original value. >>>=20 >>> The previous sentence should be reworded to allow static port = forwarding. >>=20 >> hmm, what do you mean by static port forwarding? >=20 > For example, the user goes to the CPE's admin web interface and = configures a mapping from external port 80 to internal host port 80. = That's a static mapping that needs to be taken into account by the NAT = function. The MUSTs above don't seem to allow the necessary wiggle room. correct. you cannot do that with A+P. the user looses control of the = ports. >>>> A MAP BR receiving IPv6 packets selects a best matching MAP = domain >>>> rule based on a longest address match of the packets' source = address >>>> against the BR's configured MAP BMR prefix(es), as well as a = match of >>>=20 >>> The BR, being a MAP node, can only have a single BMR, and therefore = only one BMR prefix. The alternative would be when the BR is part of = multiple MAP domains, which is not what I think you're trying to say. So = I'm confused. >>=20 >> I think the intention is to pick the right domain, given that it = states "MAP domain rule". >> does anyone else know, have suggestions for better text? >=20 > I think what confused me is the phrase "the BR's configured MAP BMR = prefix(es)". What are those? >=20 > Maybe introducing them in section 7.2 would reduce possible = confusion... we already refer to a MAP rule earlier in the sentence, I suggest we = remove the MAP BMR part. > the packet destination address against the configured BR IPv6 = address >>>> or FMR prefix(es). The selected MAP rule allows the BR to = determine >>>=20 >>> The "FMR prefix" concept has not been defined by this point. >>=20 >> I can expand that to "FMR Rule IPv6 prefix". >=20 > WFM. >=20 >>> It should be possible to express this using only "MAP rule". >>=20 >> the BR address isn't a MAP rule, which is why it is written like = that. >>=20 >>>> the EA-bits from the source IPv6 address. The BR MUST perform a >>>> validation of the consistency of the source IPv6 address and = source >>>> port number for the packet using BMR. If the packets source port >>>=20 >>> "source IPv6 address and source port number" --> I don't know which = port number this refers to. Especially since later text deals with port = numbers... >>=20 >> I'm not sure I understand your concern? isn't the "source port" a = known term? e.g. RFC768? >> or is this because there seems to be some redundancy between this = paragraph and the next? >=20 > Hehehe... I was just wondering if in the phrase "source IPv6 address = and source port number", the "source port number" is the IPv6 source = port or the IPv4 source port. I suppose it would be the IPv4 source port = since that's what you're supposed to verify with the BMR, and there are = no IPv6 port anyway with protocol 41. That would make sense to me, = however the next paragraph also deals with IPv4 source port validation. = So is it just a matter of redundancy between paragraphs, or is my = understanding incorrect? you are right, there is a confusing redundancy there. let me try to = untangle it with the co-authors. I'll then publish an update ASAP. cheers, Ole --Apple-Mail=_B9E7065A-254D-41C3-90B7-70956AEFF303 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJS1nu3AAoJEFuJXizso86gVUMH/AloGZH4YDCCQaRv8p1haA8W tYlZz8daICsSDggIKMvizGJsB2Ciq5eBJH8hPasJFXOjcJ8RAQUT4ZFbSPqFv48e 0AAINmESku4I2PkBcm8W48F9mt7bqd2CBlTulXEHoR0ZP4ZFjzSDbRej/L/n3oAT 6MoH+QXhIN73ppTdPGfEKOtl/9nd1/UaR32WyXsCopMZYltucrneJ5XwbmhEu7Oy 6+hZF0G95lC0IwwS7SAsdcakd9FQy/5FnShIb5njF676dh8ULRkTJv7b7YBQn9Jo iiuf9VHQly8arUFjtdTZ5oFpqB1eRh5nfruWTqblpKdLcVEatfgsuVP0OoX19SQ= =vwjq -----END PGP SIGNATURE----- --Apple-Mail=_B9E7065A-254D-41C3-90B7-70956AEFF303-- From simon.perreault@viagenie.ca Wed Jan 15 05:40:06 2014 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62D881AE24B for ; Wed, 15 Jan 2014 05:40:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.439 X-Spam-Level: X-Spam-Status: No, score=-2.439 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jvtc9KqxSzHT for ; Wed, 15 Jan 2014 05:40:04 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id D8F791AE0C8 for ; Wed, 15 Jan 2014 05:40:03 -0800 (PST) Received: from porto.nomis80.org (ringo.viagenie.ca [IPv6:2620:0:230:c000:3e97:eff:fe0b:dd8a]) by jazz.viagenie.ca (Postfix) with ESMTPSA id BBDBC403C8; Wed, 15 Jan 2014 08:39:51 -0500 (EST) Message-ID: <52D68FA7.10107@viagenie.ca> Date: Wed, 15 Jan 2014 08:39:51 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Ole Troan References: <52A88ACF.7000207@viagenie.ca> <52CB26BF.4080209@viagenie.ca> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "softwires@ietf.org" Subject: Re: [Softwires] WGLC review of draft-ietf-softwire-map X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2014 13:40:06 -0000 Ole, Only replying to this part, which I think is important. The rest is fine. Le 2014-01-15 07:14, Ole Troan a écrit : >>>>> A MAP CE receiving an IPv6 packet to its MAP IPv6 address sends this >>>>> packet to the CE's MAP function where it is decapsulated. All other >>>>> IPv6 traffic is forwarded as per the CE's IPv6 routing rules. The >>>>> resulting IPv4 packet is then forwarded to the CE's NAT44 function >>>>> where the destination port number MUST be checked against the >>>>> stateful port mapping session table and the destination port number >>>>> MUST be mapped to its original value. >>>> >>>> The previous sentence should be reworded to allow static port forwarding. >>> >>> hmm, what do you mean by static port forwarding? >> >> For example, the user goes to the CPE's admin web interface and configures a mapping from external port 80 to internal host port 80. That's a static mapping that needs to be taken into account by the NAT function. The MUSTs above don't seem to allow the necessary wiggle room. > > correct. you cannot do that with A+P. the user looses control of the ports. I don't see why. Do we agree that PCP can be used with MAP to manipulate a CPE's mappings? The fact that the CPE only has access to a limited external port set is of no consequence. You still have a NAT, and we need to make sure its mappings can be manipulated by the user. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From otroan@employees.org Wed Jan 15 05:48:14 2014 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5BCA1AE0D3 for ; Wed, 15 Jan 2014 05:48:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rr74LWXa2M8D for ; Wed, 15 Jan 2014 05:48:13 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id 1418D1AE0C3 for ; Wed, 15 Jan 2014 05:48:12 -0800 (PST) X-Files: signature.asc : 496 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAFuQ1lKQ/khL/2dsb2JhbABagwu8DYEUFnSCJgEBBHkQCy0ZVwaIF8QdF44nWAcKgxqBEwSQOZl8gy47gSw X-IronPort-AV: E=Sophos;i="4.95,663,1384300800"; d="asc'?scan'208";a="2993422" Received: from ams-core-2.cisco.com ([144.254.72.75]) by aer-iport-2.cisco.com with ESMTP; 15 Jan 2014 13:48:00 +0000 Received: from dhcp-lys01-vla250-10-147-113-220.cisco.com (dhcp-lys01-vla250-10-147-113-220.cisco.com [10.147.113.220]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s0FDlxp0007382 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 15 Jan 2014 13:48:00 GMT Content-Type: multipart/signed; boundary="Apple-Mail=_7D1E9C34-AB31-4AF3-8F4D-82919936E964"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ole Troan In-Reply-To: <52D68FA7.10107@viagenie.ca> Date: Wed, 15 Jan 2014 14:47:59 +0100 Message-Id: <1A08CBF6-722F-41A6-B3CE-D885A7338C2C@employees.org> References: <52A88ACF.7000207@viagenie.ca> <52CB26BF.4080209@viagenie.ca> <52D68FA7.10107@viagenie.ca> To: Simon Perreault X-Mailer: Apple Mail (2.1827) Cc: "softwires@ietf.org" Subject: Re: [Softwires] WGLC review of draft-ietf-softwire-map X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2014 13:48:14 -0000 --Apple-Mail=_7D1E9C34-AB31-4AF3-8F4D-82919936E964 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Simon, >>>>>> A MAP CE receiving an IPv6 packet to its MAP IPv6 address sends = this >>>>>> packet to the CE's MAP function where it is decapsulated. All = other >>>>>> IPv6 traffic is forwarded as per the CE's IPv6 routing rules. = The >>>>>> resulting IPv4 packet is then forwarded to the CE's NAT44 = function >>>>>> where the destination port number MUST be checked against the >>>>>> stateful port mapping session table and the destination port = number >>>>>> MUST be mapped to its original value. >>>>>=20 >>>>> The previous sentence should be reworded to allow static port = forwarding. >>>>=20 >>>> hmm, what do you mean by static port forwarding? >>>=20 >>> For example, the user goes to the CPE's admin web interface and = configures a mapping from external port 80 to internal host port 80. = That's a static mapping that needs to be taken into account by the NAT = function. The MUSTs above don't seem to allow the necessary wiggle room. >>=20 >> correct. you cannot do that with A+P. the user looses control of the = ports. >=20 > I don't see why. >=20 > Do we agree that PCP can be used with MAP to manipulate a CPE's = mappings? >=20 > The fact that the CPE only has access to a limited external port set = is of no consequence. You still have a NAT, and we need to make sure its = mappings can be manipulated by the user. yes, apologies being sloppy there. you can use PCP. it may be of limited use, e.g. if your web server is trying to use PCP = to open port 80. cheers, Ole --Apple-Mail=_7D1E9C34-AB31-4AF3-8F4D-82919936E964 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJS1pGPAAoJEFuJXizso86g6o0H/Rl4nxd6YEIqjrWP843VfXix 2g2wisVo3ld7d8Tm06ShBuDo0d4KksLhHx4UJAXGBhgix989fJAEjj95efbeF9sZ xwWzCwvZ1G16bU2ZaqxyB885oDEuH7vLTrVdK23MgxBYq6imzCwl3sskl6qFvbog Ilmz4vX4W1ccFe6ERySpLDpMe5ObqgX6WZTVzW9FgXr7rjoPqNRo55W76tQfh5pJ iyCTbO/Z1ZmymRwvDnOCy7mqhGOlmSG2ZKXUiALs+C/KgwS0H/LzU1jdX50lVPj7 MrAyZPk3qquxy7jbge6GLCf1KZbVATG2fdD5ET62PFdZgTr4XwtFw1bX4A0nVbA= =UTTY -----END PGP SIGNATURE----- --Apple-Mail=_7D1E9C34-AB31-4AF3-8F4D-82919936E964-- From simon.perreault@viagenie.ca Wed Jan 15 05:54:52 2014 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAC6F1AE0D3 for ; Wed, 15 Jan 2014 05:54:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.439 X-Spam-Level: X-Spam-Status: No, score=-2.439 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rNTlFMWq7Kxv for ; Wed, 15 Jan 2014 05:54:51 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 6385E1AE0D2 for ; Wed, 15 Jan 2014 05:54:51 -0800 (PST) Received: from porto.nomis80.org (ringo.viagenie.ca [IPv6:2620:0:230:c000:3e97:eff:fe0b:dd8a]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 91B41403C8; Wed, 15 Jan 2014 08:54:39 -0500 (EST) Message-ID: <52D6931F.9040101@viagenie.ca> Date: Wed, 15 Jan 2014 08:54:39 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Ole Troan References: <52A88ACF.7000207@viagenie.ca> <52CB26BF.4080209@viagenie.ca> <52D68FA7.10107@viagenie.ca> <1A08CBF6-722F-41A6-B3CE-D885A7338C2C@employees.org> In-Reply-To: <1A08CBF6-722F-41A6-B3CE-D885A7338C2C@employees.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "softwires@ietf.org" Subject: Re: [Softwires] WGLC review of draft-ietf-softwire-map X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2014 13:54:53 -0000 Le 2014-01-15 08:47, Ole Troan a écrit : > Simon, >>>>>>> A MAP CE receiving an IPv6 packet to its MAP IPv6 address sends this >>>>>>> packet to the CE's MAP function where it is decapsulated. All other >>>>>>> IPv6 traffic is forwarded as per the CE's IPv6 routing rules. The >>>>>>> resulting IPv4 packet is then forwarded to the CE's NAT44 function >>>>>>> where the destination port number MUST be checked against the >>>>>>> stateful port mapping session table and the destination port number >>>>>>> MUST be mapped to its original value. >>>>>> >>>>>> The previous sentence should be reworded to allow static port forwarding. >>>>> >>>>> hmm, what do you mean by static port forwarding? >>>> >>>> For example, the user goes to the CPE's admin web interface and configures a mapping from external port 80 to internal host port 80. That's a static mapping that needs to be taken into account by the NAT function. The MUSTs above don't seem to allow the necessary wiggle room. >>> >>> correct. you cannot do that with A+P. the user looses control of the ports. >> >> I don't see why. >> >> Do we agree that PCP can be used with MAP to manipulate a CPE's mappings? >> >> The fact that the CPE only has access to a limited external port set is of no consequence. You still have a NAT, and we need to make sure its mappings can be manipulated by the user. > > yes, apologies being sloppy there. you can use PCP. > it may be of limited use, e.g. if your web server is trying to use PCP to open port 80. Yes of course. I'm more concerned about modern apps that don't rely on well-known ports. My point, concretely, is that the MUSTs above seem to preclude user manipulation of the NAT mappings. I would suggest instead: A MAP CE receiving an IPv6 packet to its MAP IPv6 address sends this packet to the CE's MAP function where it is decapsulated. All other IPv6 traffic is forwarded as per the CE's IPv6 routing rules. The resulting IPv4 packet is then forwarded to the CE's NAT44 function, where it is handled according to the NAT's state. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From otroan@employees.org Wed Jan 15 06:01:35 2014 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 548321AE373 for ; Wed, 15 Jan 2014 06:01:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hhBPWEYTC9sJ for ; Wed, 15 Jan 2014 06:01:34 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id 279811AE364 for ; Wed, 15 Jan 2014 06:01:34 -0800 (PST) X-Files: signature.asc : 496 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFANyT1lKQ/khM/2dsb2JhbABZgwu8DYEVFnSCJQEBAQMBeRALRlcGiA8IxBMXjidYB4MkgRMEkDmZfIMuO4Es X-IronPort-AV: E=Sophos;i="4.95,663,1384300800"; d="asc'?scan'208";a="2994062" Received: from ams-core-3.cisco.com ([144.254.72.76]) by aer-iport-2.cisco.com with ESMTP; 15 Jan 2014 14:01:21 +0000 Received: from dhcp-lys01-vla250-10-147-113-220.cisco.com (dhcp-lys01-vla250-10-147-113-220.cisco.com [10.147.113.220]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s0FE1Kj8004577 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 15 Jan 2014 14:01:21 GMT Content-Type: multipart/signed; boundary="Apple-Mail=_461D5D2F-3140-4A59-9EA1-0E21D29CA5F5"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ole Troan In-Reply-To: <52D6931F.9040101@viagenie.ca> Date: Wed, 15 Jan 2014 15:01:20 +0100 Message-Id: References: <52A88ACF.7000207@viagenie.ca> <52CB26BF.4080209@viagenie.ca> <52D68FA7.10107@viagenie.ca> <1A08CBF6-722F-41A6-B3CE-D885A7338C2C@employees.org> <52D6931F.9040101@viagenie.ca> To: Simon Perreault X-Mailer: Apple Mail (2.1827) Cc: "softwires@ietf.org" Subject: Re: [Softwires] WGLC review of draft-ietf-softwire-map X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2014 14:01:35 -0000 --Apple-Mail=_461D5D2F-3140-4A59-9EA1-0E21D29CA5F5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Simon, >> yes, apologies being sloppy there. you can use PCP. >> it may be of limited use, e.g. if your web server is trying to use = PCP to open port 80. >=20 > Yes of course. I'm more concerned about modern apps that don't rely on = well-known ports. >=20 > My point, concretely, is that the MUSTs above seem to preclude user = manipulation of the NAT mappings. I would suggest instead: >=20 > A MAP CE receiving an IPv6 packet to its MAP IPv6 address sends this > packet to the CE's MAP function where it is decapsulated. All other > IPv6 traffic is forwarded as per the CE's IPv6 routing rules. The > resulting IPv4 packet is then forwarded to the CE's NAT44 function, > where it is handled according to the NAT's state. agree, MAP should treat the NAT as a black box. apart from that it must = be port range aware. cheers, Ole --Apple-Mail=_461D5D2F-3140-4A59-9EA1-0E21D29CA5F5 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJS1pSwAAoJEFuJXizso86grdwH/05XKcSm8fCSh0n0s5CQClWc gIkoqgMDxaJwDJ8e5/N7kOEV5/Y4zO6/HE9kmDQJaTlKzVU8kS5/NeBOcOLAUdHj iBmCyCxg5j5ZurhENEOoLuoYAi62e22SSSlaGO3aWdSz0Qzf7dms4iPHekIGQN3y YRH2vVcxh13hJXQCktJ3z+dcT7ovTJnOZS+dY+orV6NsVimRDfY7BqmQZqJ2Fm1U rk/EU4HNVkjuenxrlJae7yFfYBR4AoBA1VG22FiqBT7kVj/EzxAWDCObIYbifHD9 Ryj5hnMEoubBxJHEqWvOfgDasEFthdy6VOdYvobd0HqjgOzSGxTYSGDpfycSQ+g= =JOGb -----END PGP SIGNATURE----- --Apple-Mail=_461D5D2F-3140-4A59-9EA1-0E21D29CA5F5-- From swmike@swm.pp.se Wed Jan 15 23:19:28 2014 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB6241AE1EA for ; Wed, 15 Jan 2014 23:19:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.089 X-Spam-Level: X-Spam-Status: No, score=-2.089 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S4nDpf-Pg8TO for ; Wed, 15 Jan 2014 23:19:26 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 01EB21ADBCD for ; Wed, 15 Jan 2014 23:19:25 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 5B3609C; Thu, 16 Jan 2014 08:19:12 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 5457C9A for ; Thu, 16 Jan 2014 08:19:12 +0100 (CET) Date: Thu, 16 Jan 2014 08:19:12 +0100 (CET) From: Mikael Abrahamsson To: Softwires WG In-Reply-To: Message-ID: References: User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Subject: Re: [Softwires] Working group last call for draft-ietf-softwire-lw4over6-03 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2014 07:19:29 -0000 On Tue, 14 Jan 2014, Suresh Krishnan wrote: > Hi all, > This message starts a two week softwire working group last call on > advancing the draft about Lightweight 4over6 as a Standards Track RFC. > The authors believe that this version has addressed all the issues > raised on the document till now. The latest version of the draft is > available at > > http://www.ietf.org/id/draft-ietf-softwire-lw4over6-03.txt > http://tools.ietf.org/html/draft-ietf-softwire-lw4over6-03 > > Substantive comments and statements of support/opposition for advancing > this document should be directed to the mailing list. Editorial > suggestions can be sent directly to the authors. This last call will > conclude on January 28, 2014. I have re-read this document in its entirety, and found two things I would like to have discussed. The fragmentation handling needs more guidance. 5.2.1. says: "On receiving an encapsulated packet containing an IPv4 fragment, the lwB4 MUST wait until all other fragments have been received and de- capsulated." What happens if one of the fragments are lost? I would believe there is work to be referenced when it comes to handling fragmentation, and the document would be better guidance if that was referenced. Also: "When an lwB4 receives an IPv4 packet from its connected host that is larger than the MTU size after encapsulation, the lwB4 MUST fragment the IPv4 packet before encapsulation." If the DF flag is set, the packet shouldn't be fragmented, instead PMTUD mechanism should be honored. Right? Fragmenting an IPv4 packet with DF bit set sounds like a bad thing. Now, going on to ICMP handling. The wording in section 8 at least to me could read like an implementor could implement "drop all ICMP on the outside interface" and say they've complied to the SHOULD in the second paragraph. I think the logic in section 8 should be that an implementor SHOULD implement 1, 2 and 3, and if they don't, then they SHOULD drop all ICMP. Right now it's SHOULD for (1-3 OR drop). I don't think the "drop" option should be in the initial SHOULD. So wrapping 1-3 in the initial SHOULD, and then say alternative to this is to drop. Also, the RFC6269 reference, RFC6269 is an informational issues document, it doesn't give guidance to implementors on how to solve the problem (right?). In the next-to-last paragraph there is guidance to how to solve the problem. I think the better way would be to bring up the second-to-last paragraph of section 8 to between paragraph 1 and 2, and then look at what the 3 bullet points says and if they're mentioned in RFC5508 and if they are, just point to RFC5508 instead. So the flow would be RFC6269 points out the problem, to solve it, implementor SHOULD implement 5508, and then have the current "either/or" sections say what's specific to lw4o6, and have a last entry to say that if proper ICMP handling isn't implemented at all, SHOULD drop the packet. So to sum up above, section 8 seems to me to contain enough information, I would just like to see it structured in a different way/order and the logic checked so implementors do the right thing. Right now I find it a bit hard to understand. -- Mikael Abrahamsson email: swmike@swm.pp.se From simon.perreault@viagenie.ca Thu Jan 16 06:17:50 2014 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F3291AE0C8 for ; Thu, 16 Jan 2014 06:17:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.439 X-Spam-Level: X-Spam-Status: No, score=-2.439 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jRkyisyiEU4d for ; Thu, 16 Jan 2014 06:17:49 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0285B1AE2C3 for ; Thu, 16 Jan 2014 06:17:49 -0800 (PST) Received: from porto.nomis80.org (ringo.viagenie.ca [IPv6:2620:0:230:c000:3e97:eff:fe0b:dd8a]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 93B0540393 for ; Thu, 16 Jan 2014 09:17:36 -0500 (EST) Message-ID: <52D7EA00.9070802@viagenie.ca> Date: Thu, 16 Jan 2014 09:17:36 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: softwires@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Softwires] Working group last call for draft-ietf-softwire-lw4over6-03 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2014 14:17:50 -0000 Le 2014-01-16 02:19, Mikael Abrahamsson a écrit : > The fragmentation handling needs more guidance. 5.2.1. says: > > "On receiving an encapsulated packet containing an IPv4 fragment, the > lwB4 MUST wait until all other fragments have been received and de- > capsulated." > > What happens if one of the fragments are lost? I would believe there is > work to be referenced when it comes to handling fragmentation, and the > document would be better guidance if that was referenced. You're right, the advice in the text is wrong, if only because it's possible to do it correctly without waiting for all fragments (e.g., what Cisco calls "virtual reassembly"). We need to keep in mind that fragmentation and reassembly issues 1) are very complex, 2) apply to a ton of protocols in addition to lw4o6, 3) there's more than one way to do it, and 4) there's no one true way to do it, they all suck a little in different ways. My suggestion would be to steal the very carefully written text from RFC 6146, page 19. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From Branimir.Rajtar@t.ht.hr Thu Jan 16 07:47:01 2014 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E45CC1ADED7 for ; Thu, 16 Jan 2014 07:47:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.262 X-Spam-Level: X-Spam-Status: No, score=0.262 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uwATP1owVfaO for ; Thu, 16 Jan 2014 07:46:59 -0800 (PST) Received: from mx01.t.ht.hr (mx01.t.ht.hr [195.29.161.88]) by ietfa.amsl.com (Postfix) with ESMTP id 061981AE37E for ; Thu, 16 Jan 2014 07:46:58 -0800 (PST) Received: from mailgw.ad.local (unknown [172.17.66.76]) by mx01.t.ht.hr with smtp id 3f38_77c4_7a0eddae_8d46_40e3_83b6_984db9158662; Thu, 16 Jan 2014 16:46; Received: from S2010EXCHCA1.ad.local ([10.240.132.138]) by mailgw.ad.local with Microsoft SMTPSVC(6.0.3790.4675); Thu, 16 Jan 2014 16:46; Received: from S2010EXCH1.ad.local ([fe80::2d7b:39dd:876e:f277]) by S2010EXCHCA1.ad.local ([::1]) with mapi id 14.03.0174.001; Thu, 16 Jan 2014 16:46; From: Branimir Rajtar To: Mikael Abrahamsson , Softwires WG Thread-Topic: [Softwires] Working group last call for draft-ietf-softwire-lw4over6-03 Thread-Index: AQHPEotMNbpYMy9igEWnG6xiysVX8pqHe3Hw Date: Thu, 16 Jan 2014 15:46:44 +0000 Message-ID: <786F13AA11E69F4DB2CCA23F7400C2FB566B5BE6@S2010EXCH1.ad.local> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.10.22] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 16 Jan 2014 15:46:44.0900 (UTC) FILETIME=[2880DE40:01CF12D2] X-NAIMIME-Disclaimer: 1 X-NAIMIME-Modified: 1 Subject: Re: [Softwires] Working group last call for draft-ietf-softwire-lw4over6-03 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2014 15:47:02 -0000 PiAiV2hlbiBhbiBsd0I0IHJlY2VpdmVzIGFuIElQdjQgcGFja2V0IGZyb20gaXRzIGNvbm5lY3Rl ZCBob3N0IHRoYXQgaXMKPiAgICAgbGFyZ2VyIHRoYW4gdGhlIE1UVSBzaXplIGFmdGVyIGVuY2Fw c3VsYXRpb24sIHRoZSBsd0I0IE1VU1QgZnJhZ21lbnQKPiAgICAgdGhlIElQdjQgcGFja2V0IGJl Zm9yZSBlbmNhcHN1bGF0aW9uLiIKPiAKPiBJZiB0aGUgREYgZmxhZyBpcyBzZXQsIHRoZSBwYWNr ZXQgc2hvdWxkbid0IGJlIGZyYWdtZW50ZWQsIGluc3RlYWQgUE1UVUQKPiBtZWNoYW5pc20gc2hv dWxkIGJlIGhvbm9yZWQuIFJpZ2h0PyBGcmFnbWVudGluZyBhbiBJUHY0IHBhY2tldCB3aXRoIERG IGJpdAo+IHNldCBzb3VuZHMgbGlrZSBhIGJhZCB0aGluZy4KCk9uZSBtb3JlIHRoaW5nIEkgZmlu ZCBwdXp6bGluZyAtIFJGQ3MgMjQ3MyBhbmQgNjMzMyBzdGF0ZSB0aGF0IHlvdSBoYXZlIHRvIGVu Y2Fwc3VsYXRlIHRoZSBwYWNrZXQgZmlyc3QgaW50byBJUHY2IGFuZCBpZiBpdCBleGNlZWRzIHRo ZSBJUHY0LWluLUlQdjYgdHVubmVsIE1UVSwgZnJhZ21lbnQgdGhlIElQdjYgcGFja2V0LiBUaGlz IGRyYWZ0IHN0YXRlcyB0aGUgb3Bwb3NpdGUgdGhpbmcsIGlmIHRoZSBlbmNhcHN1bGF0ZWQgcGFj a2V0IGlzIGxhcmdlciB0aGFuIHRoZSB0dW5uZWwgTVRVLCB5b3UgaGF2ZSB0byBmcmFnbWVudCBJ UHY0IGFuZCB0aGVuIGVuY2Fwc3VsYXRlIGl0IGludG8gSVB2Ni4gSW4gbXkgb3BpbmlvbiwgdGhl IHNpbXBsZXIgdGhpbmcgdG8gZG8gd291bGQgYmUgdG8gZW5jYXBzdWxhdGUgZmlyc3QgYW5kIGZy YWdtZW50IGFmdGVyd2FyZHMuCgpJIHRoaW5rIHRoaXMgaXMgYWxzbyBhIHByb2JsZW0gYmVjYXVz ZSBSRkMgNjMzMyBkZXNjcmliZXMgZnJhZ21lbnRhdGlvbiBvbmx5IGZyb20gdGhlIEFGVFIncyB2 aWV3cG9pbnQgYW5kIHRoaXMgZHJhZnQgZGVzY3JpYmVzIGl0IGZyb20gdGhlIEI0J3Mgdmlld3Bv aW50LiBTaW5jZSB0aGlzIGRyYWZ0IHJlZmVycyB0byBSRkM2MzMzIGZvciBmcmFnbWVudGF0aW9u LCBpdCB3b3VsZCBtZWFuIHRoYXQgdGhlIGx3QUZUUiBhbmQgbHdCNCB3b3VsZCBoYXZlIGRpZmZl cmVudCBmcmFnbWVudGF0aW9uIGxvZ2ljLgoKQnJhbmltaXIKCgo8SFRNTD48UD48Rk9OVCBmYWNl PUFyaWFsIGNvbG9yPSM5OTk5OTkgc2l6ZT0xPg0KDQpJWkpBVkEgTyBPRFJJQ0FOSlUgT0RHT1ZP Uk5PU1RJOiBTYWRyxb5haiBvdmUgcG9ydWtlIGkgZXZlbnR1YWxubyBwcmlsb8W+ZW5paCBkYXRv dGVrYSBqZSBwb3ZqZXJsaml2IGkgbmFtaWplbmplbiBqZSBzYW1vIG9zb2JhbWEgaWxpIHN1Ympl a3RpbWEga29qaSBzdSBuYXZlZGVuaSB1IGFkcmVzaS4gVWtvbGlrbyBzdGUgcHJpbWlsaSBvdnUg cG9ydWt1IGdyZcWha29tLCBtb2xpbW8gVmFzLCBvYmF2aWplc3RpdGUgcG/FoWlsamF0ZWxqYSwg YSBwb3J1a3UgaSBzdmUgbmplbmUgcHJpdml0a2Ugb2RtYWgsIGJleiDEjWl0YW5qYSwgdHJham5v IHVrbG9uaXRlIHMgcmHEjXVuYWxhLiBCaWxvIGtha3ZvIHByZW5vxaFlbmplLCBrb3BpcmFuamUg aWxpIGRpc3RyaWJ1Y2lqYSBpbmZvcm1hY2lqYSBzYWRyxb5hbmloIHUgcG9ydWNpIHRyZcSHaW0g b3NvYmFtYSBqZSB6YWJyYW5qZW5vIGkgbW/FvmUgYml0aSB6YWtvbnNraSBrYcW+bmppdm8uIFNh ZHLFvmFqLCBzdGF2b3ZpIGkgbWnFoWxqZW5qYSBpem5lc2VuaSB1IHBvcnVjaSBzdSBhdXRvcm92 aSBpIG5lIHByZWRzdGF2bGphanUgbnXFvm5vIHN0YXZvdmUgSFQgLSBIcnZhdHNraWggdGVsZWtv bXVuaWthY2lqYSBkLmQuIEhUIG5lIHByaWh2YcSHYSBuaWtha3Z1IG9kZ292b3Jub3N0IHphIGV2 ZW50dWFsbnUgxaF0ZXR1IG5hc3RhbHUgcHJpbWl0a29tIG92ZSBwb3J1a2UgaSBwcmlsb2dhIHNh ZHLFvmFuaWggdSBwb3J1Y2kuDQoNCjwvRk9OVD48L1A+PFA+PEZPTlQgZmFjZT1BcmlhbCBjb2xv cj0jOTk5OTk5IHNpemU9MT4NCg0KIERJU0NMQUlNRVI6VGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1h aWwgYXMgd2VsbCBhcyBhbnkgZmlsZXMgYXR0YWNoZWQgdG8gaXQgYXJlIGNvbmZpZGVudGlhbCBh bmQgaW50ZW5kZWQgc29sZWx5IGZvciBpbmRpdmlkdWFscyBvciBlbnRpdGllcyB3aGljaCB0aGV5 IGFyZSBhZGRyZXNzZWQgdG8uIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgbWVzc2Fn ZSBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBwZXJtYW5lbnRseSByZW1v dmUgdGhlIG1lc3NhZ2UgYW5kIGFsbCBhdHRhY2hlZCBmaWxlcyBmcm9tIHRoZSBjb21wdXRlci4g QW55IGRpc2Nsb3N1cmUsIGNvcHlpbmcgb3IgZGlzdHJpYnV0aW9uIG9mIGFsbCBvciBhIHBhcnQg b2YgaW5mb3JtYXRpb24gY29udGFpbmVkIGhlcmVpbiB0byBvciBieSB0aGlyZCBwYXJ0aWVzIGlz IHByb2hpYml0ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4gUGxlYXNlIG5vdGUgdGhhdCBhbnkgdmll d3Mgb3Igb3BpbmlvbnMgcHJlc2VudGVkIGluIHRoaXMgbWVzc2FnZSBhcmUgc29sZWx5IHRob3Nl IG9mIHRoZSBhdXRob3IgYW5kIGRvIG5vdCBuZWNlc3NhcmlseSByZXByZXNlbnQgdGhlIHZpZXdz IGFuZCBvcGluaW9ucyBvZiBDcm9hdGlhbiBUZWxlY29tIEluYy4gQ3JvYXRpYW4gVGVsZWNvbSBJ bmMuIGFjY2VwdHMgbm8gbGlhYmlsaXR5IGZvciBhbnkgcG90ZW50aWFsIGRhbWFnZSBjYXVzZWQg YnkgdGhpcyBtZXNzYWdlIGFuZCBmaWxlcyBhdHRhY2hlZCB0byBpdC4NCg0KPC9GT05UPjwvUD48 L0hUTUw+Cg== From swmike@swm.pp.se Thu Jan 16 09:59:44 2014 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 492431A1DFA for ; Thu, 16 Jan 2014 09:59:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.089 X-Spam-Level: X-Spam-Status: No, score=-2.089 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qBgP5I4hP9Mg for ; Thu, 16 Jan 2014 09:59:42 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 40DDE1A16F0 for ; Thu, 16 Jan 2014 09:59:42 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 7789E9C; Thu, 16 Jan 2014 18:59:29 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 706F39A; Thu, 16 Jan 2014 18:59:29 +0100 (CET) Date: Thu, 16 Jan 2014 18:59:29 +0100 (CET) From: Mikael Abrahamsson To: Branimir Rajtar In-Reply-To: <786F13AA11E69F4DB2CCA23F7400C2FB566B5BE6@S2010EXCH1.ad.local> Message-ID: References: <786F13AA11E69F4DB2CCA23F7400C2FB566B5BE6@S2010EXCH1.ad.local> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Softwires WG Subject: Re: [Softwires] Working group last call for draft-ietf-softwire-lw4over6-03 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2014 17:59:44 -0000 On Thu, 16 Jan 2014, Branimir Rajtar wrote: > One more thing I find puzzling - RFCs 2473 and 6333 state that you have > to encapsulate the packet first into IPv6 and if it exceeds the > IPv4-in-IPv6 tunnel MTU, fragment the IPv6 packet. This draft states the > opposite thing, if the encapsulated packet is larger than the tunnel > MTU, you have to fragment IPv4 and then encapsulate it into IPv6. In my > opinion, the simpler thing to do would be to encapsulate first and > fragment afterwards. You really really want to avoid having fragmented IPv6 packets on the wire if you can. Yes, I guess this might be ok since this is in within the provider network so they can control forwarding performance of fragmented IPv6 packets, but having the lwAFTR do re-assembly for most traffic is just bad for performance. We really really want to give guidance that avoids fragmentation regardless of where it happens. > I think this is also a problem because RFC 6333 describes fragmentation > only from the AFTR's viewpoint and this draft describes it from the B4's > viewpoint. Since this draft refers to RFC6333 for fragmentation, it > would mean that the lwAFTR and lwB4 would have different fragmentation > logic. It would be good if there was clarification on both aspects I believe. -- Mikael Abrahamsson email: swmike@swm.pp.se From otroan@employees.org Thu Jan 16 12:27:20 2014 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D1B61ABBB1 for ; Thu, 16 Jan 2014 12:27:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K40Sit_Yt5mg for ; Thu, 16 Jan 2014 12:27:19 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id 445AA1A16F0 for ; Thu, 16 Jan 2014 12:27:19 -0800 (PST) X-Files: signature.asc : 496 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai0FAHU/2FKQ/khR/2dsb2JhbABZgwu8IIEPFnSCJQEBAQMBHVwFCwtGVwaIDwjFNxeOfweDJIEUBJA6mX6DLjs X-IronPort-AV: E=Sophos;i="4.95,669,1384300800"; d="asc'?scan'208";a="3734179" Received: from ams-core-1.cisco.com ([144.254.72.81]) by aer-iport-1.cisco.com with ESMTP; 16 Jan 2014 20:27:06 +0000 Received: from dhcp-10-61-100-229.cisco.com (dhcp-10-61-100-229.cisco.com [10.61.100.229]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s0GKR5MQ015747 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 16 Jan 2014 20:27:05 GMT Content-Type: multipart/signed; boundary="Apple-Mail=_43708684-FD28-4964-A194-E6C6B324AC87"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ole Troan In-Reply-To: <786F13AA11E69F4DB2CCA23F7400C2FB566B5BE6@S2010EXCH1.ad.local> Date: Thu, 16 Jan 2014 21:27:04 +0100 Message-Id: <0FD1287D-E98A-4D2C-9682-8838E2D225DA@employees.org> References: <786F13AA11E69F4DB2CCA23F7400C2FB566B5BE6@S2010EXCH1.ad.local> To: Branimir Rajtar X-Mailer: Apple Mail (2.1827) Cc: Softwires WG Subject: Re: [Softwires] Working group last call for draft-ietf-softwire-lw4over6-03 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2014 20:27:20 -0000 --Apple-Mail=_43708684-FD28-4964-A194-E6C6B324AC87 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Branimir, >> "When an lwB4 receives an IPv4 packet from its connected host that is >> larger than the MTU size after encapsulation, the lwB4 MUST = fragment >> the IPv4 packet before encapsulation." >>=20 >> If the DF flag is set, the packet shouldn't be fragmented, instead = PMTUD >> mechanism should be honored. Right? Fragmenting an IPv4 packet with = DF bit >> set sounds like a bad thing. >=20 > One more thing I find puzzling - RFCs 2473 and 6333 state that you = have to encapsulate the packet first into IPv6 and if it exceeds the = IPv4-in-IPv6 tunnel MTU, fragment the IPv6 packet. This draft states the = opposite thing, if the encapsulated packet is larger than the tunnel = MTU, you have to fragment IPv4 and then encapsulate it into IPv6. In my = opinion, the simpler thing to do would be to encapsulate first and = fragment afterwards. RFC4459 gives a good analysis of the problem. > I think this is also a problem because RFC 6333 describes = fragmentation only from the AFTR's viewpoint and this draft describes it = from the B4's viewpoint. Since this draft refers to RFC6333 for = fragmentation, it would mean that the lwAFTR and lwB4 would have = different fragmentation logic. cheers, Ole --Apple-Mail=_43708684-FD28-4964-A194-E6C6B324AC87 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJS2ECZAAoJEFuJXizso86gItAIAJo8Pqf6ZO+5g4EJaHRj0Xnd OpNolRZIMp75PjpKAQHVn9l/wo8GDY+UmxQYMgye1JXzkGvnUzfwDOz1OSqW+L8l tIpDU2YEJXyxqQbw3S/CV7ujTZnf1itKUx6CdIsM83Bnh7+hVqNvgC2872H58aq8 PgNxhNJgYtULZO5gdFW4jMwsNYQSwsAzLZwZRg8H03O1D1FArZwNUKQCjnQ5urLu kfcwbpc+RPx/hXCjpHOeBeqUJixTUFHpEZr8s0PmVcXufcC5besFtPoXBu11FwAN IHCzikJZJzKKa7tC/bQb5x+RvUYHE4rChM2+e7dd8gYZFphe4xOughI6pl+lRWM= =UgCY -----END PGP SIGNATURE----- --Apple-Mail=_43708684-FD28-4964-A194-E6C6B324AC87-- From wwwrun@rfc-editor.org Mon Jan 20 02:23:40 2014 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20CB41A00E1 for ; Mon, 20 Jan 2014 02:23:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.263 X-Spam-Level: X-Spam-Status: No, score=0.263 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.535, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qkLSfFyNc4f5 for ; Mon, 20 Jan 2014 02:23:38 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2607:f170:8000:1500::d3]) by ietfa.amsl.com (Postfix) with ESMTP id A94141A00DE for ; Mon, 20 Jan 2014 02:23:38 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 063317FC3A3; Mon, 20 Jan 2014 02:23:39 -0800 (PST) To: mark@townsley.net, ot@cisco.com, brian@innovationslab.net, ted.lemon@nominum.com, suresh.krishnan@ericsson.com, cuiyong@tsinghua.edu.cn From: RFC Errata System Message-Id: <20140120102339.063317FC3A3@rfc-editor.org> Date: Mon, 20 Jan 2014 02:23:39 -0800 (PST) Cc: softwires@ietf.org, fernando@gont.com.ar, rfc-editor@rfc-editor.org Subject: [Softwires] [Technical Errata Reported] RFC5969 (3869) X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2014 10:23:40 -0000 The following errata report has been submitted for RFC5969, "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5969&eid=3869 -------------------------------------- Type: Technical Reported by: Fernando Gont Section: 9.2 Original Text ------------- In order to prevent spoofing of IPv6 addresses, the 6rd BR and CE MUST validate the embedded IPv4 source address of the encapsulated IPv6 packet with the IPv4 source address it is encapsulated by according to the configured parameters of the 6rd domain. Corrected Text -------------- In order to prevent spoofing of IPv6 addresses, the 6rd BR and CE MUST validate the embedded IPv6 source address of the encapsulated IPv6 packet with the IPv4 source address it is encapsulated by according to the configured parameters of the 6rd domain. Notes ----- Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5969 (draft-ietf-softwire-ipv6-6rd-10) -------------------------------------- Title : IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification Publication Date : August 2010 Author(s) : W. Townsley, O. Troan Category : PROPOSED STANDARD Source : Softwires Area : Internet Stream : IETF Verifying Party : IESG From simon.perreault@viagenie.ca Mon Jan 20 13:10:20 2014 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 238201A0229 for ; Mon, 20 Jan 2014 13:10:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.537 X-Spam-Level: X-Spam-Status: No, score=-0.537 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ms8LOYzaU7cJ for ; Mon, 20 Jan 2014 13:10:17 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 77D161A0215 for ; Mon, 20 Jan 2014 13:10:17 -0800 (PST) Received: from porto.nomis80.org (ringo.viagenie.ca [IPv6:2620:0:230:c000:3e97:eff:fe0b:dd8a]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 1C4CE40382 for ; Mon, 20 Jan 2014 16:10:17 -0500 (EST) Message-ID: <52DD90B8.1060204@viagenie.ca> Date: Mon, 20 Jan 2014 16:10:16 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "softwires@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Softwires] Working group last call for draft-ietf-softwire-lw4over6-03 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2014 21:10:20 -0000 All, I re-read the draft carefully. I noticed two issues: 1. Section 5.1: > An IPv6 address from an assigned prefix is also required for the lwB4 > to use as the encapsulation source address for the softwire. In > order to enable end-to-end provisioning, the IPv6 address is > constructed by taking the /64 prefix assigned to the WAN interface What happens if there is more than one prefixes assigned to the WAN interface? If that case results in undefined behaviour (fine by me), it needs to be stated in the text. 2. See other mails about section 5.2.1. And a minor suggestion: > The DNS considerations described in Section 5.5 and Section 6.4 of > [RFC6333] SHOULD be followed. This SHOULD is suspicious. Suggestion: s/SHOULD be followed/also apply/ Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From Ted.Lemon@nominum.com Mon Jan 20 15:33:57 2014 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C722D1A022B for ; Mon, 20 Jan 2014 15:33:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vij_1-RFEBlz for ; Mon, 20 Jan 2014 15:33:56 -0800 (PST) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by ietfa.amsl.com (Postfix) with ESMTP id D01251A0218 for ; Mon, 20 Jan 2014 15:33:56 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKUt2yZau0BS3iRHw9DmtTzPfVBEy/FZk6@postini.com; Mon, 20 Jan 2014 15:33:57 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id BFE121B82DF for ; Mon, 20 Jan 2014 15:33:56 -0800 (PST) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 9879A19005C; Mon, 20 Jan 2014 15:33:56 -0800 (PST) Received: from [10.0.10.40] (192.168.1.10) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 20 Jan 2014 15:33:56 -0800 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ted Lemon In-Reply-To: <20140120102339.063317FC3A3@rfc-editor.org> Date: Mon, 20 Jan 2014 18:33:53 -0500 Content-Transfer-Encoding: 7bit Message-ID: <4E6B5575-FFEA-4908-B94E-D5F6F8E885E6@nominum.com> References: <20140120102339.063317FC3A3@rfc-editor.org> To: RFC Errata System X-Mailer: Apple Mail (2.1827) X-Originating-IP: [192.168.1.10] Cc: Ole Troan , Brian Haberman , Yong Cui , Fernando Gont , Softwires Subject: Re: [Softwires] [Technical Errata Reported] RFC5969 (3869) X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2014 23:33:58 -0000 Mark, Ole, can you take a look at this erratum? From suresh.krishnan@ericsson.com Mon Jan 20 18:59:41 2014 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE9CA1A000F for ; Mon, 20 Jan 2014 18:59:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lP7KplUpBpL4 for ; Mon, 20 Jan 2014 18:59:39 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 25AE01A000E for ; Mon, 20 Jan 2014 18:59:39 -0800 (PST) X-AuditID: c6180641-b7fbd8e0000011cc-3c-52dde29b9fa1 Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 27.68.04556.B92EDD25; Tue, 21 Jan 2014 03:59:39 +0100 (CET) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.02.0387.000; Mon, 20 Jan 2014 21:59:38 -0500 From: Suresh Krishnan To: RFC Errata System , "mark@townsley.net" , "ot@cisco.com" , "brian@innovationslab.net" , "ted.lemon@nominum.com" , "cuiyong@tsinghua.edu.cn" Thread-Topic: [Technical Errata Reported] RFC5969 (3869) Thread-Index: AQHPFcmyxrHUkNbqp0WMdSoUFf7yypqOSNhw Date: Tue, 21 Jan 2014 02:59:38 +0000 Message-ID: References: <20140120102339.063317FC3A3@rfc-editor.org> In-Reply-To: <20140120102339.063317FC3A3@rfc-editor.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupkkeLIzCtJLcpLzFFi42KZXLrHT3f2o7tBBnOfaVvM7PnHaPFjS7LF jw0H2S2mHXjAZLFi13pWi6b9X9ksDi/bymSxtTvWgcNjyu+NrB5rty9g8Viy5CeTx8zjX1g8 Xh+Yz+rR0HaM1eP+tIlMHsc/v2UO4IjisklJzcksSy3St0vgymjadYC54KtYxZGHzSwNjP1C XYycHBICJhKXF8xkgrDFJC7cW8/WxcjFISRwhFGiad8VdghnOaNE/92FYFVsQB0bdn5mAkmI CMxjkrjzehojSIJZIE7i4P31rCC2sIC5ROOmDjBbRMBCYsutn+wQtpHEuf/XmEFsFgFViUV/ 94DZvAK+EsuXPQCrFwLqnX3mKNgyTqDePTMbwOKMQOd9P7WGCWKXuMStJ/OhzhaQWLLnPDOE LSrx8vE/VghbSWLS0nOsEPU6Egt2f2KDsLUlli18DbVXUOLkzCcsExjFZiEZOwtJyywkLbOQ tCxgZFnFyFFanFqWm25kuIkRGJ3HJNgcdzAu+GR5iFGag0VJnPfLW+cgIYH0xJLU7NTUgtSi +KLSnNTiQ4xMHJxSDYyWb91lz+8WfxNW/riY7RI/w+K6wxXN7+17vY6se2Mnpj7FqernVtcG 69u6qtufFVfyv7PK0PpXI31RyX8za5jMpi/cz0T8rTt9+7WYjrUL/J4k8Cjo0N27kzTZvc0F NANNK7+83cJfonJt79xs9Qg70/U5TgoHfmSbrtS3e7Hy1p+n9ksSjyixFGckGmoxFxUnAgCq WMxTnAIAAA== Cc: "softwires@ietf.org" , "fernando@gont.com.ar" Subject: Re: [Softwires] [Technical Errata Reported] RFC5969 (3869) X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 02:59:41 -0000 Hi Ted/Brian, I will let Ole and Mark answer authoritatively but my call is that the ex= isting text is correct and should be left alone. The embedded IPv4 address = is a field in the IPv6 address (see format below) that is being compared to= the IPv4 address in the encapsulating IPv4 datagram. | n bits | o bits | m bits | 128-n-o-m bits | +---------------+--------------+-----------+------------------------+ | 6rd prefix | IPv4 address | subnet ID | interface ID | +---------------+--------------+-----------+------------------------+ Thanks Suresh > -----Original Message----- > From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] > Sent: January-20-14 5:24 AM > To: mark@townsley.net; ot@cisco.com; brian@innovationslab.net; > ted.lemon@nominum.com; Suresh Krishnan; cuiyong@tsinghua.edu.cn > Cc: fernando@gont.com.ar; softwires@ietf.org; rfc-editor@rfc-editor.org > Subject: [Technical Errata Reported] RFC5969 (3869) >=20 > The following errata report has been submitted for RFC5969, > "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol > Specification". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D5969&eid=3D3869 >=20 > -------------------------------------- > Type: Technical > Reported by: Fernando Gont >=20 > Section: 9.2 >=20 > Original Text > ------------- > In order to prevent spoofing of IPv6 addresses, the 6rd BR and CEMUST > validate the embedded IPv4 source address of the encapsulatedIPv6 packet > with the IPv4 source address it is encapsulated byaccording to the config= ured > parameters of the 6rd domain. >=20 > Corrected Text > -------------- > In order to prevent spoofing of IPv6 addresses, the 6rd BR and CEMUST > validate the embedded IPv6 source address of the encapsulatedIPv6 packet > with the IPv4 source address it is encapsulated byaccording to the config= ured > parameters of the 6rd domain. >=20 > Notes > ----- >=20 >=20 > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please use "= Reply > All" to discuss whether it should be verified or rejected. When a decisio= n is > reached, the verifying party (IESG) can log in to change the status and e= dit > the report, if necessary. >=20 > -------------------------------------- > RFC5969 (draft-ietf-softwire-ipv6-6rd-10) > -------------------------------------- > Title : IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)= -- Protocol > Specification > Publication Date : August 2010 > Author(s) : W. Townsley, O. Troan > Category : PROPOSED STANDARD > Source : Softwires > Area : Internet > Stream : IETF > Verifying Party : IESG From ian.farrer@telekom.de Tue Jan 21 01:19:35 2014 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3013E1A00A1 for ; Tue, 21 Jan 2014 01:19:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.085 X-Spam-Level: X-Spam-Status: No, score=-2.085 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2u0C0hfU4pnL for ; Tue, 21 Jan 2014 01:19:33 -0800 (PST) Received: from tcmail33.telekom.de (tcmail33.telekom.de [80.149.113.247]) by ietfa.amsl.com (Postfix) with ESMTP id D96091A0090 for ; Tue, 21 Jan 2014 01:19:32 -0800 (PST) Received: from he113443.emea1.cds.t-internal.com ([10.134.93.103]) by tcmail31.telekom.de with ESMTP/TLS/AES128-SHA; 21 Jan 2014 10:19:30 +0100 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE113443.emea1.cds.t-internal.com ([::1]) with mapi; Tue, 21 Jan 2014 10:19:30 +0100 From: To: , Date: Tue, 21 Jan 2014 10:19:29 +0100 Thread-Topic: [Softwires] Working group last call for draft-ietf-softwire-lw4over6-03 Thread-Index: Ac8WieKeR3d6j8VLRGuLDzTDtJXF1Q== Message-ID: References: <52DD90B8.1060204@viagenie.ca> In-Reply-To: <52DD90B8.1060204@viagenie.ca> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Softwires] Working group last call for draft-ietf-softwire-lw4over6-03 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 09:19:35 -0000 Hi Simon, Thanks for the comments. Please see inline. Cheers, Ian On 20/01/2014 22:10, "Simon Perreault" wrote: >All, > >I re-read the draft carefully. I noticed two issues: > >1. Section 5.1: > >> An IPv6 address from an assigned prefix is also required for the lwB4 >> to use as the encapsulation source address for the softwire. In >> order to enable end-to-end provisioning, the IPv6 address is >> constructed by taking the /64 prefix assigned to the WAN interface > >What happens if there is more than one prefixes assigned to the WAN >interface? > >If that case results in undefined behaviour (fine by me), it needs to be >stated in the text. [ian] More than one prefix (of the same scope) is a pretty likely case here. Behaviour does need to be defined, as if the wrong prefix is selected for the source v6 encapsulation address, then it=B9s going to be discarded by the lwAFTR, for some provisioning methods at least.. Suggest that we update to make this clear. > > >2. See other mails about section 5.2.1. > > >And a minor suggestion: > >> The DNS considerations described in Section 5.5 and Section 6.4 of >> [RFC6333] SHOULD be followed. > >This SHOULD is suspicious. Suggestion: s/SHOULD be followed/also apply/ [ian] Will update. From otroan@employees.org Tue Jan 21 03:23:45 2014 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BA911A00B1 for ; Tue, 21 Jan 2014 03:23:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n1njNFtgkv3o for ; Tue, 21 Jan 2014 03:23:43 -0800 (PST) Received: from banjo.employees.org (banjo.employees.org [198.137.202.19]) by ietfa.amsl.com (Postfix) with ESMTP id 153CA1A00AE for ; Tue, 21 Jan 2014 03:23:43 -0800 (PST) Received: from [192.168.10.84] (unknown [195.159.143.154]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 90A746048; Tue, 21 Jan 2014 03:18:38 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_5ED5CB8A-7E97-43BF-8A1F-583075804CE9"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ole Troan In-Reply-To: Date: Tue, 21 Jan 2014 12:18:35 +0100 Message-Id: <52630C6F-F987-4923-A1A4-047E3EF3EF89@employees.org> References: <20140120102339.063317FC3A3@rfc-editor.org> To: Suresh Krishnan X-Mailer: Apple Mail (2.1827) Cc: "brian@innovationslab.net" , "fernando@gont.com.ar" , "cuiyong@tsinghua.edu.cn" , "softwires@ietf.org" , RFC Errata System Subject: Re: [Softwires] [Technical Errata Reported] RFC5969 (3869) X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 11:23:45 -0000 --Apple-Mail=_5ED5CB8A-7E97-43BF-8A1F-583075804CE9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > I will let Ole and Mark answer authoritatively but my call is that = the existing text is correct and should be left alone. The embedded IPv4 = address is a field in the IPv6 address (see format below) that is being = compared to the IPv4 address in the encapsulating IPv4 datagram. >=20 >=20 > | n bits | o bits | m bits | 128-n-o-m bits = | > = +---------------+--------------+-----------+------------------------+ > | 6rd prefix | IPv4 address | subnet ID | interface ID = | > = +---------------+--------------+-----------+------------------------+ >=20 absolutely. the text says to verify that the embedded IPv4 address and the IPv4 = source address are the same. Fernando, feel free to contact me directly if this is still unclear. cheers, Ole >=20 >> -----Original Message----- >> From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] >> Sent: January-20-14 5:24 AM >> To: mark@townsley.net; ot@cisco.com; brian@innovationslab.net; >> ted.lemon@nominum.com; Suresh Krishnan; cuiyong@tsinghua.edu.cn >> Cc: fernando@gont.com.ar; softwires@ietf.org; = rfc-editor@rfc-editor.org >> Subject: [Technical Errata Reported] RFC5969 (3869) >>=20 >> The following errata report has been submitted for RFC5969, >> "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol >> Specification". >>=20 >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=3D5969&eid=3D3869 >>=20 >> -------------------------------------- >> Type: Technical >> Reported by: Fernando Gont >>=20 >> Section: 9.2 >>=20 >> Original Text >> ------------- >> In order to prevent spoofing of IPv6 addresses, the 6rd BR and CEMUST >> validate the embedded IPv4 source address of the encapsulatedIPv6 = packet >> with the IPv4 source address it is encapsulated byaccording to the = configured >> parameters of the 6rd domain. >>=20 >> Corrected Text >> -------------- >> In order to prevent spoofing of IPv6 addresses, the 6rd BR and CEMUST >> validate the embedded IPv6 source address of the encapsulatedIPv6 = packet >> with the IPv4 source address it is encapsulated byaccording to the = configured >> parameters of the 6rd domain. >>=20 >> Notes >> ----- >>=20 >>=20 >> Instructions: >> ------------- >> This errata is currently posted as "Reported". If necessary, please = use "Reply >> All" to discuss whether it should be verified or rejected. When a = decision is >> reached, the verifying party (IESG) can log in to change the status = and edit >> the report, if necessary. >>=20 >> -------------------------------------- >> RFC5969 (draft-ietf-softwire-ipv6-6rd-10) >> -------------------------------------- >> Title : IPv6 Rapid Deployment on IPv4 Infrastructures = (6rd) -- Protocol >> Specification >> Publication Date : August 2010 >> Author(s) : W. Townsley, O. Troan >> Category : PROPOSED STANDARD >> Source : Softwires >> Area : Internet >> Stream : IETF >> Verifying Party : IESG > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires --Apple-Mail=_5ED5CB8A-7E97-43BF-8A1F-583075804CE9 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJS3leLAAoJEFuJXizso86g94wH/2YA/WNx+FwqEUjjw/sSGRMH 0W/qc7nCKrArbncidgdmha7mNZltD8904Hs84gN5geukAWHCKBb43g13iKgU3ZQZ b6PZyIvyoL4O3IMEst4pImyLNkbPjpYuO3/mPrEculVaFiF9fotTyIqd1Nr7AeKI CUKlMGl70hvDfJ9RA9UVNg90CUatRkNFGWwAKntA0MVBFVjf74yVKqBR5HMXJeI8 Qyex6bkpmZCe+NCnxlTJQPJQNAWFNdQbbxF8VMxjGYR1zpg8J8mzeH32AqWpZHqf 20i+cJLE+qRYAB2j490rxxZZAG1637Uen83kZnXJqY64d1jY252oFubna34ynTs= =6aEM -----END PGP SIGNATURE----- --Apple-Mail=_5ED5CB8A-7E97-43BF-8A1F-583075804CE9-- From simon.perreault@viagenie.ca Tue Jan 21 06:11:38 2014 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AC3C1A00D2 for ; Tue, 21 Jan 2014 06:11:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8E4QE390xAfV for ; Tue, 21 Jan 2014 06:11:36 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 260731A00DB for ; Tue, 21 Jan 2014 06:11:36 -0800 (PST) Received: from porto.nomis80.org (ringo.viagenie.ca [IPv6:2620:0:230:c000:3e97:eff:fe0b:dd8a]) by jazz.viagenie.ca (Postfix) with ESMTPSA id CB1A840367; Tue, 21 Jan 2014 09:11:35 -0500 (EST) Message-ID: <52DE8017.6030208@viagenie.ca> Date: Tue, 21 Jan 2014 09:11:35 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: ian.farrer@telekom.de, softwires@ietf.org References: <52DD90B8.1060204@viagenie.ca> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Softwires] Working group last call for draft-ietf-softwire-lw4over6-03 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 14:11:38 -0000 Le 2014-01-21 04:19, ian.farrer@telekom.de a écrit : >> 1. Section 5.1: >> >>> An IPv6 address from an assigned prefix is also required for the lwB4 >>> to use as the encapsulation source address for the softwire. In >>> order to enable end-to-end provisioning, the IPv6 address is >>> constructed by taking the /64 prefix assigned to the WAN interface >> >> What happens if there is more than one prefixes assigned to the WAN >> interface? >> >> If that case results in undefined behaviour (fine by me), it needs to be >> stated in the text. > > [ian] More than one prefix (of the same scope) is a pretty likely case What do you mean by "scope"? > here. Behaviour does need to be defined, as if the wrong prefix is > selected for the source v6 encapsulation address, then it¹s going to be > discarded by the lwAFTR, for some provisioning methods at least.. Suggest > that we update to make this clear. I'm not following you. If the CPE picks the "wrong" prefix, sets up its tunnel interface, then sends packets on it, they will get discarded by the lwAFTR. How does the CPE handle this? How does it figure out which one is the "right" prefix? How do we go from "the Internet doesn't work" to "the Internet works"? Thanks, Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From ian.farrer@telekom.de Tue Jan 21 07:25:37 2014 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45FDA1A0188 for ; Tue, 21 Jan 2014 07:25:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.085 X-Spam-Level: X-Spam-Status: No, score=-2.085 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GCzFawHTguC1 for ; Tue, 21 Jan 2014 07:25:35 -0800 (PST) Received: from tcmail33.telekom.de (tcmail33.telekom.de [80.149.113.247]) by ietfa.amsl.com (Postfix) with ESMTP id 2D8871A0150 for ; Tue, 21 Jan 2014 07:25:33 -0800 (PST) Received: from he110890.emea1.cds.t-internal.com ([10.134.92.131]) by tcmail31.telekom.de with ESMTP/TLS/AES128-SHA; 21 Jan 2014 16:25:32 +0100 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by he110890 ([10.134.92.131]) with mapi; Tue, 21 Jan 2014 16:25:31 +0100 From: To: , Date: Tue, 21 Jan 2014 16:25:26 +0100 Thread-Topic: [Softwires] Working group last call for draft-ietf-softwire-lw4over6-03 Thread-Index: Ac8WvQXTEkLY/z7fTEylZL3zSyGy+Q== Message-ID: References: <52DD90B8.1060204@viagenie.ca> <52DE8017.6030208@viagenie.ca> In-Reply-To: <52DE8017.6030208@viagenie.ca> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="euc-kr" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [Softwires] Working group last call for draft-ietf-softwire-lw4over6-03 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 15:25:37 -0000 SGkgU2ltb24sDQoNCg0KDQo+Pg0KPj4gW2lhbl0gTW9yZSB0aGFuIG9uZSBwcmVmaXggKG9mIHRo ZSBzYW1lIHNjb3BlKSBpcyBhIHByZXR0eSBsaWtlbHkgY2FzZQ0KPg0KPldoYXQgZG8geW91IG1l YW4gYnkgInNjb3BlIj8NCg0KW2lhbl0gUkZDNDAwNyBzY29wZS4NCg0KPg0KPj4gaGVyZS4gQmVo YXZpb3VyIGRvZXMgbmVlZCB0byBiZSBkZWZpbmVkLCBhcyBpZiB0aGUgd3JvbmcgcHJlZml4IGlz DQo+PiBzZWxlY3RlZCBmb3IgdGhlIHNvdXJjZSB2NiBlbmNhcHN1bGF0aW9uIGFkZHJlc3MsIHRo ZW4gaXSp9nMgZ29pbmcgdG8gYmUNCj4+IGRpc2NhcmRlZCBieSB0aGUgbHdBRlRSLCBmb3Igc29t ZSBwcm92aXNpb25pbmcgbWV0aG9kcyBhdCBsZWFzdC4uDQo+PlN1Z2dlc3QNCj4+IHRoYXQgd2Ug dXBkYXRlIHRvIG1ha2UgdGhpcyBjbGVhci4NCj4NCj5JJ20gbm90IGZvbGxvd2luZyB5b3UuIElm IHRoZSBDUEUgcGlja3MgdGhlICJ3cm9uZyIgcHJlZml4LCBzZXRzIHVwIGl0cw0KPnR1bm5lbCBp bnRlcmZhY2UsIHRoZW4gc2VuZHMgcGFja2V0cyBvbiBpdCwgdGhleSB3aWxsIGdldCBkaXNjYXJk ZWQgYnkNCj50aGUgbHdBRlRSLiBIb3cgZG9lcyB0aGUgQ1BFIGhhbmRsZSB0aGlzPyBIb3cgZG9l cyBpdCBmaWd1cmUgb3V0IHdoaWNoDQo+b25lIGlzIHRoZSAicmlnaHQiIHByZWZpeD8gSG93IGRv IHdlIGdvIGZyb20gInRoZSBJbnRlcm5ldCBkb2Vzbid0IHdvcmsiDQo+dG8gInRoZSBJbnRlcm5l dCB3b3JrcyI/DQoNCltpYW5dIFRoZSBjdXJyZW50IHRleHQgZGVzY3JpYmVzIGhvdyB0aGUgQ1BF IGNyZWF0ZXMgdGhlIC8xMjggcHJlZml4IHRvDQp1c2UgYXMgaXRzIHR1bm5lbCBlbmRwb2ludCAo d2hlbiBpdHMgcHJvdmlzaW9uZWQgd2l0aCBESENQdjYpLiBUaGlzIHByZWZpeA0KaGFzIGJlZW4g Y29uc3RydWN0ZWQgdXNpbmcgYW4gZXhpc3RpbmcgLzY0IHByZWZpeCBhbmQgYSBzdWZmaXggdGhh dCBoYXMNCmJlZW4gbGVhcm50IHRocm91Z2ggdGhlIHY0IGNvbmZpZ3VyYXRpb24gaW5mb3JtYXRp b24gaW4gT1BUSU9OX1M0Nl9MVzRvNi4NClRoZSBDUEUgY2Fuoa90IHRyeSBhbmQgYnVpbGQgYSB0 dW5uZWwgdW50aWwgaXQgaGFzIHJlY2VpdmVkIGFsbCBvZiB0aGVzZQ0KcGFyYW1ldGVycywgYXMg aXQgd291bGRuoa90IGhhdmUgYSB0dW5uZWwgZW5kcG9pbnQgYWRkcmVzcyBmb3IgdGhlIGx3QUZU Ug0KZWl0aGVyLg0KDQpTbywgaXQgbGVhcm5zIHRoZSBwYXJhbWV0ZXJzIG92ZXIgREhDUHY2LCBj cmVhdGVzIHRoZSB0dW5uZWwgc291cmNlIC8xMjgNCmJhc2VkIG9uIHRoZXNlIHBhcmFtZXRlcnMg YW5kIGJ1aWxkcyB0aGUgdHVubmVsIGZyb20gdGhlcmUuIEluIGFsbA0KbGlrZWxpaG9vZCwgdGhl cmUgaXMgYWxzbyBhIFNMQUFDIG9yIElBX05BIGFkZHJlc3Mgb24gYWxzbyB0aGF0IGludGVyZmFj ZSwNCmJ1dCBhcyB0aGUgbHc0bzYgY2xpZW50IGlzIGNvbmZpZ3VyaW5nIHRoZSBzb3VyY2UgcHJl Zml4IGFzIHdlbGwgYXMNCmJ1aWxkaW5nIHRoZSB0dW5uZWwsIHRoZSByaWdodCBwcmVmaXggaXMg dGhlIG9uZSB0aGF0IGl0cyBqdXN0IGNvbmZpZ3VyZWQuDQoNCklzIHRoZSBjdXJyZW50IHRleHQg bm90IGNvbnZleWluZyB0aGlzLCBvciBkbyB5b3UgdGhpbmsgdGhhdCB0aGVyZaGvcw0Kc29tZXRo aW5nIHdyb25nIHdpdGggdGhlIG1ldGhvZD8NCg0KQ2hlZXJzLA0KSWFuDQoNCg== From simon.perreault@viagenie.ca Tue Jan 21 07:42:48 2014 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 341601A018C for ; Tue, 21 Jan 2014 07:42:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id swE0Zi8U1K2t for ; Tue, 21 Jan 2014 07:42:46 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 21E481A034E for ; Tue, 21 Jan 2014 07:42:46 -0800 (PST) Received: from porto.nomis80.org (ringo.viagenie.ca [IPv6:2620:0:230:c000:3e97:eff:fe0b:dd8a]) by jazz.viagenie.ca (Postfix) with ESMTPSA id D8BE240367; Tue, 21 Jan 2014 10:42:45 -0500 (EST) Message-ID: <52DE9575.4010504@viagenie.ca> Date: Tue, 21 Jan 2014 10:42:45 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: ian.farrer@telekom.de, softwires@ietf.org References: <52DD90B8.1060204@viagenie.ca> <52DE8017.6030208@viagenie.ca> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Softwires] Working group last call for draft-ietf-softwire-lw4over6-03 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 15:42:48 -0000 Le 2014-01-21 10:25, ian.farrer@telekom.de a écrit : > [ian] The current text describes how the CPE creates the /128 prefix to > use as its tunnel endpoint (when its provisioned with DHCPv6). This prefix > has been constructed using an existing /64 prefix and a suffix that has > been learnt through the v4 configuration information in OPTION_S46_LW4o6. > The CPE can’t try and build a tunnel until it has received all of these > parameters, as it wouldn’t have a tunnel endpoint address for the lwAFTR > either. Ok, good, this is as I expected. > So, it learns the parameters over DHCPv6, creates the tunnel source /128 > based on these parameters and builds the tunnel from there. In all > likelihood, there is also a SLAAC or IA_NA address on also that interface, > but as the lw4o6 client is configuring the source prefix as well as > building the tunnel, the right prefix is the one that its just configured. > > Is the current text not conveying this, or do you think that there’s > something wrong with the method? As I read it, the current text is not conveying this. I would suggest: OLD: An IPv6 address from an assigned prefix is also required for the lwB4 to use as the encapsulation source address for the softwire. In order to enable end-to-end provisioning, the IPv6 address is constructed by taking the /64 prefix assigned to the WAN interface (learned via SLAAC, DHCPv6 or manual configuration) and suffixing 64-bits for the interface identifier. The /128 prefix is constructed as follows: NEW: An IPv6 address from an assigned prefix is also required for the lwB4 to use as the encapsulation source address for the softwire. In order to enable end-to-end provisioning, the IPv6 address is constructed by taking a /64 prefix assigned to the WAN interface and suffixing 64-bits for the interface identifier. As there may be multiple WAN prefixes, of which only one can be used for lw4o6, the CPE is provisioned with the knowledge of which one to take. The /128 prefix is then constructed as follows: Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From wwwrun@rfc-editor.org Tue Jan 21 10:59:27 2014 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 498271A01B9; Tue, 21 Jan 2014 10:59:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sWXRYkmxAx7S; Tue, 21 Jan 2014 10:59:25 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2607:f170:8000:1500::d3]) by ietfa.amsl.com (Postfix) with ESMTP id CBBEB1A0190; Tue, 21 Jan 2014 10:59:25 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id B18EE7FC2C7; Tue, 21 Jan 2014 10:59:22 -0800 (PST) To: fernando@gont.com.ar, mark@townsley.net, ot@cisco.com From: RFC Errata System Message-Id: <20140121185925.B18EE7FC2C7@rfc-editor.org> Date: Tue, 21 Jan 2014 10:59:22 -0800 (PST) Cc: softwires@ietf.org, rfc-editor@rfc-editor.org, iesg@ietf.org Subject: [Softwires] [Errata Rejected] RFC5969 (3869) X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 18:59:27 -0000 The following errata report has been rejected for RFC5969, "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5969&eid=3869 -------------------------------------- Status: Rejected Type: Technical Reported by: Fernando Gont Date Reported: 2014-01-20 Rejected by: Ted Lemon (IESG) Section: 9.2 Original Text ------------- In order to prevent spoofing of IPv6 addresses, the 6rd BR and CE MUST validate the embedded IPv4 source address of the encapsulated IPv6 packet with the IPv4 source address it is encapsulated by according to the configured parameters of the 6rd domain. Corrected Text -------------- In order to prevent spoofing of IPv6 addresses, the 6rd BR and CE MUST validate the embedded IPv6 source address of the encapsulated IPv6 packet with the IPv4 source address it is encapsulated by according to the configured parameters of the 6rd domain. Notes ----- Authors have verified that the text as written in the RFC is correct, and the proposed change is incorrect. --VERIFIER NOTES-- Authors have verified that the text as written in the RFC is correct, and the proposed change is incorrect. -------------------------------------- RFC5969 (draft-ietf-softwire-ipv6-6rd-10) -------------------------------------- Title : IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification Publication Date : August 2010 Author(s) : W. Townsley, O. Troan Category : PROPOSED STANDARD Source : Softwires Area : Internet Stream : IETF Verifying Party : IESG From ian.farrer@telekom.de Fri Jan 24 00:10:22 2014 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 084AF1A01D1 for ; Fri, 24 Jan 2014 00:10:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.785 X-Spam-Level: X-Spam-Status: No, score=-2.785 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uHATLlmAn3yQ for ; Fri, 24 Jan 2014 00:10:19 -0800 (PST) Received: from tcmail23.telekom.de (tcmail23.telekom.de [80.149.113.243]) by ietfa.amsl.com (Postfix) with ESMTP id 8FB1E1A01C7 for ; Fri, 24 Jan 2014 00:10:15 -0800 (PST) Received: from he113472.emea1.cds.t-internal.com ([10.134.93.130]) by tcmail21.telekom.de with ESMTP/TLS/AES128-SHA; 24 Jan 2014 09:10:13 +0100 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE113472.emea1.cds.t-internal.com ([::1]) with mapi; Fri, 24 Jan 2014 09:10:13 +0100 From: To: , Date: Fri, 24 Jan 2014 09:10:12 +0100 Thread-Topic: [Softwires] Working group last call for draft-ietf-softwire-lw4over6-03 Thread-Index: Ac8Y27W/ABjXrjsbSdKF2xclkpw8BQ== Message-ID: References: <52DD90B8.1060204@viagenie.ca> <52DE8017.6030208@viagenie.ca> <52DE9575.4010504@viagenie.ca> In-Reply-To: <52DE9575.4010504@viagenie.ca> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Softwires] Working group last call for draft-ietf-softwire-lw4over6-03 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 08:10:22 -0000 > >NEW: > An IPv6 address from an assigned prefix is also required for the lwB4 > to use as the encapsulation source address for the softwire. In > order to enable end-to-end provisioning, the IPv6 address is > constructed by taking a /64 prefix assigned to the WAN interface > and suffixing 64-bits for the interface identifier. As there may be > multiple WAN prefixes, of which only one can be used for lw4o6, the > CPE is provisioned with the knowledge of which one to take. The /128 > prefix is then constructed as follows: [ian] I think that reads better. Can I suggest a slight wording tweak?: s/knowledge of which one to take/logic to select the correct one Cheers, Ian From internet-drafts@ietf.org Fri Jan 24 10:25:13 2014 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D28D1A00B8; Fri, 24 Jan 2014 10:25:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B-tSFOM0Qpq5; Fri, 24 Jan 2014 10:25:11 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 65DF01A0046; Fri, 24 Jan 2014 10:25:11 -0800 (PST) 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.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140124182511.27816.24934.idtracker@ietfa.amsl.com> Date: Fri, 24 Jan 2014 10:25:11 -0800 Cc: softwires@ietf.org Subject: [Softwires] I-D Action: draft-ietf-softwire-map-10.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 18:25:13 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Softwires Working Group of the IETF. Title : Mapping of Address and Port with Encapsulation (M= AP) Authors : Ole Troan Wojciech Dec Xing Li Congxiao Bao Satoru Matsushima Tetsuya Murakami Tom Taylor Filename : draft-ietf-softwire-map-10.txt Pages : 32 Date : 2014-01-24 Abstract: This document describes a mechanism for transporting IPv4 packets across an IPv6 network using IP encapsulation, and a generic mechanism for mapping between IPv6 addresses and IPv4 addresses and transport layer ports. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-softwire-map/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-softwire-map-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-softwire-map-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From sunqi.csnet.thu@gmail.com Sun Jan 26 18:44:40 2014 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0EF51A0180 for ; Sun, 26 Jan 2014 18:44:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rqAMlIEi3x-6 for ; Sun, 26 Jan 2014 18:44:38 -0800 (PST) Received: from mail-pd0-x22e.google.com (mail-pd0-x22e.google.com [IPv6:2607:f8b0:400e:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 46C531A0177 for ; Sun, 26 Jan 2014 18:44:38 -0800 (PST) Received: by mail-pd0-f174.google.com with SMTP id z10so5189343pdj.33 for ; Sun, 26 Jan 2014 18:44:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=+TnIlVVcicXRXkUn7jM9MCFRd5MM+2+DrIZyAEJ0r9Q=; b=fEogTldqhiFm0f4Ymrdv17CFhH6ak6OxwNmFwCCh9Qw9Lq/jYjBEqN6M5jZjsiWJqi 9i24DiEzyqBeO/QzALyji5C2HcMnM2oo9/e0BIZE5g/vy/q+RAOcswUsN5vEAo6DKRjX rSXz6btj6cycNY7+PElKOB/pVAMTQiywJrhuKTyJCpM+GfJTtjwynJmtc3BwveOoGuDj bjpaAXwTDerTvJ7TAMYtkWhJbyoN4FDUrePwu2R9XCKPZItRP25OBPviOYoDQrW7oAay PT601Wy3vaQ+vDTxA/yhGB4XDATutxEL7VDQlhnfgxnVIUxYVSVCYDiMV90qKTOUuCwI 9zpg== X-Received: by 10.68.37.42 with SMTP id v10mr27593341pbj.127.1390790676165; Sun, 26 Jan 2014 18:44:36 -0800 (PST) Received: from [192.168.0.109] ([27.213.251.185]) by mx.google.com with ESMTPSA id c7sm26783119pbt.0.2014.01.26.18.44.33 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 26 Jan 2014 18:44:35 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=utf-8 From: Qi Sun In-Reply-To: Date: Mon, 27 Jan 2014 10:44:28 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <7740D665-913B-476A-88C3-918DCE4D777F@gmail.com> References: To: Suresh Krishnan X-Mailer: Apple Mail (2.1085) Cc: Softwires WG , Yong Cui Subject: Re: [Softwires] Working group last call for draft-ietf-softwire-lw4over6-03 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2014 02:44:40 -0000 I support this document to move forward. //Some nits: 1) Page 9 The working flow of the lwB4 is illustrated in figure 3. =3D> The working ... in figure 4. 2) It would be better if all Captions could be centered. Best Regards, Qi On 2014-1-14, at =E4=B8=8B=E5=8D=8812:46, Suresh Krishnan wrote: > Hi all, > This message starts a two week softwire working group last call on=20= > advancing the draft about Lightweight 4over6 as a Standards Track RFC.=20= > The authors believe that this version has addressed all the issues=20 > raised on the document till now. The latest version of the draft is=20 > available at >=20 > http://www.ietf.org/id/draft-ietf-softwire-lw4over6-03.txt > http://tools.ietf.org/html/draft-ietf-softwire-lw4over6-03 >=20 > Substantive comments and statements of support/opposition for = advancing=20 > this document should be directed to the mailing list. Editorial=20 > suggestions can be sent directly to the authors. This last call will=20= > conclude on January 28, 2014. >=20 > Regards, > Suresh & Yong > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From gnocuil@gmail.com Mon Jan 27 11:02:38 2014 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D3A71A03A2 for ; Mon, 27 Jan 2014 11:02:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fdruYqHHkU9K for ; Mon, 27 Jan 2014 11:02:36 -0800 (PST) Received: from mail-qa0-x235.google.com (mail-qa0-x235.google.com [IPv6:2607:f8b0:400d:c00::235]) by ietfa.amsl.com (Postfix) with ESMTP id 5D56E1A03A1 for ; Mon, 27 Jan 2014 11:02:36 -0800 (PST) Received: by mail-qa0-f53.google.com with SMTP id cm18so7717012qab.26 for ; Mon, 27 Jan 2014 11:02:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=CxtAEWJC0BH6YNLuhlZo4xJnNflyBl+BHBKecGEN80g=; b=V5QZIU28t6cZQjpG2czupEOZ2pOQeN9RNuZfkKpSh98fPiFTDxaYbtFTZqhN1YVnWU Cegjn5r+9jYeyAuhgaYdlRmf7M1q94ff5ErmkuOwksUpWrAEZcnCD1hd3nbKIAxyn6mV dqetqWau+XD6rLII6FjTO3jpJzUaxXrr/hJ546tpbIhaG0vjTtflzroOeED5B1aB7Q5B sej7CDUlUMM4D5abVKpUYKvT32fQmIFhb9Va91V5IywEe/BLRbH5Y5rGYG8a0gSJa6F+ 4q+1CtNl3BiN4QfLFJkQ4tTgC8AhAC/7KGbFGIG3txPuAGYERLWMp7DQa/eRRAoG+VA1 UbcQ== X-Received: by 10.224.129.138 with SMTP id o10mr45614765qas.13.1390849353834; Mon, 27 Jan 2014 11:02:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.96.218.104 with HTTP; Mon, 27 Jan 2014 11:02:13 -0800 (PST) In-Reply-To: References: From: Cong Liu Date: Tue, 28 Jan 2014 03:02:13 +0800 Message-ID: To: Suresh Krishnan Content-Type: multipart/alternative; boundary=001a11c2bd9eabe78004f0f85919 Cc: Softwires WG , Yong Cui Subject: Re: [Softwires] Working group last call for draft-ietf-softwire-lw4over6-03 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2014 19:02:38 -0000 --001a11c2bd9eabe78004f0f85919 Content-Type: text/plain; charset=ISO-8859-1 Hi all, I support advancing this document. Best Regards, Cong 2014-01-14 Suresh Krishnan > Hi all, > This message starts a two week softwire working group last call on > advancing the draft about Lightweight 4over6 as a Standards Track RFC. > The authors believe that this version has addressed all the issues > raised on the document till now. The latest version of the draft is > available at > > http://www.ietf.org/id/draft-ietf-softwire-lw4over6-03.txt > http://tools.ietf.org/html/draft-ietf-softwire-lw4over6-03 > > Substantive comments and statements of support/opposition for advancing > this document should be directed to the mailing list. Editorial > suggestions can be sent directly to the authors. This last call will > conclude on January 28, 2014. > > Regards, > Suresh & Yong > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > --001a11c2bd9eabe78004f0f85919 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi all,

I support advancing this docume= nt.=A0

Best Regards,
Cong


2014-01-14 S= uresh Krishnan <suresh.krishnan@ericsson.com>
Hi all,
=A0 =A0This message starts a two week softwire working group last call on advancing the draft about Lightweight 4over6 as a Standards Track RFC.
The authors believe that this version has addressed all the issues
raised on the document till now. The latest version of the draft is
available at

http://www.ietf.org/id/draft-ietf-softwire-lw4over6-03.txt
http://tools.ietf.org/html/draft-ietf-softwire-lw4over6-03

Substantive comments and statements of support/opposition for advancing
this document should be directed to the mailing list. Editorial
suggestions can be sent directly to the authors. This last call will
conclude on January 28, 2014.

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

--001a11c2bd9eabe78004f0f85919-- From ianfarrer@gmx.com Mon Jan 27 11:03:52 2014 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 658661A027B for ; Mon, 27 Jan 2014 11:03:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DHXnmL69eDL6 for ; Mon, 27 Jan 2014 11:03:50 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id 1A8E01A0256 for ; Mon, 27 Jan 2014 11:03:50 -0800 (PST) Received: from ians-mbp.fritz.box ([89.0.70.192]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0LyEUz-1VBkTk3r0v-015VVa for ; Mon, 27 Jan 2014 20:03:47 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_2598834D-6AE2-4896-98C5-FA4F9B345F14" Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ian Farrer In-Reply-To: Date: Mon, 27 Jan 2014 20:03:44 +0100 Message-Id: <8ACEA0FC-6C75-4247-88F6-6812C8538878@gmx.com> References: To: Cong Liu X-Mailer: Apple Mail (2.1827) X-Provags-ID: V03:K0:+DujFFlr/Yfb3j25HL0yLmiN0I88V0vbnGiK7UznfypAFDVW3ec xCNXlXKAmXSUINeetrvvkWCxtNoUHlQ5fsrWcOBXxzgGGMNTlSp7P6Si/AO93mn4ryMUo/8 R2wsnKphYSNKPMa0gupq2gu/ez2UIsdUJ+0zRT4alrc/6Lpmg7wfsef0w+A/iaBCWk56B0p 5DP0j6zPR4H1PvFZGTMvg== Cc: Softwires WG , Yong Cui Subject: Re: [Softwires] Working group last call for draft-ietf-softwire-lw4over6-03 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2014 19:03:52 -0000 --Apple-Mail=_2598834D-6AE2-4896-98C5-FA4F9B345F14 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=iso-8859-1 I also support it advancing, with the requested updates (as a co-author) Ian On 27 Jan 2014, at 20:02, Cong Liu wrote: > Hi all, > > I support advancing this document. > > Best Regards, > Cong > > > 2014-01-14 Suresh Krishnan > Hi all, > This message starts a two week softwire working group last call on > advancing the draft about Lightweight 4over6 as a Standards Track RFC. > The authors believe that this version has addressed all the issues > raised on the document till now. The latest version of the draft is > available at > > http://www.ietf.org/id/draft-ietf-softwire-lw4over6-03.txt > http://tools.ietf.org/html/draft-ietf-softwire-lw4over6-03 > > Substantive comments and statements of support/opposition for advancing > this document should be directed to the mailing list. Editorial > suggestions can be sent directly to the authors. This last call will > conclude on January 28, 2014. > > Regards, > Suresh & Yong > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires --Apple-Mail=_2598834D-6AE2-4896-98C5-FA4F9B345F14 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1 I also support it advancing, with the requested updates (as a co-author)

Ian

On 27 Jan 2014, at 20:02, Cong Liu <gnocuil@gmail.com> wrote:

Hi all,

I support advancing this document. 

Best Regards,
Cong


2014-01-14 Suresh Krishnan <suresh.krishnan@ericsson.com>
Hi all,
   This message starts a two week softwire working group last call on
advancing the draft about Lightweight 4over6 as a Standards Track RFC.
The authors believe that this version has addressed all the issues
raised on the document till now. The latest version of the draft is
available at

http://www.ietf.org/id/draft-ietf-softwire-lw4over6-03.txt
http://tools.ietf.org/html/draft-ietf-softwire-lw4over6-03

Substantive comments and statements of support/opposition for advancing
this document should be directed to the mailing list. Editorial
suggestions can be sent directly to the authors. This last call will
conclude on January 28, 2014.

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

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

--Apple-Mail=_2598834D-6AE2-4896-98C5-FA4F9B345F14-- From sureshk@juniper.net Mon Jan 27 15:31:37 2014 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E51061A027C for ; Mon, 27 Jan 2014 15:31:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zgMybwZVdukS for ; Mon, 27 Jan 2014 15:31:35 -0800 (PST) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe004.messaging.microsoft.com [216.32.180.187]) by ietfa.amsl.com (Postfix) with ESMTP id 77DCE1A008F for ; Mon, 27 Jan 2014 15:31:35 -0800 (PST) Received: from mail8-co1-R.bigfish.com (10.243.78.229) by CO1EHSOBE026.bigfish.com (10.243.66.89) with Microsoft SMTP Server id 14.1.225.22; Mon, 27 Jan 2014 23:31:33 +0000 Received: from mail8-co1 (localhost [127.0.0.1]) by mail8-co1-R.bigfish.com (Postfix) with ESMTP id 0380D900101; Mon, 27 Jan 2014 23:31:33 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT005.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -25 X-BigFish: VPS-25(z579ehzbb2dI98dI9371I936eI1432Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz1de098h1033IL17326ah8275dh1de097h186068hz2fh109h2a8h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1fe8h1ff5h209eh2216h22d0h2336h2438h2461h2487h24d7h1155h) Received-SPF: pass (mail8-co1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=sureshk@juniper.net; helo=BL2PRD0510HT005.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(6009001)(51704005)(24454002)(189002)(199002)(377424004)(377454003)(479174003)(83322001)(19580405001)(56816005)(19580395003)(92566001)(85852003)(80976001)(79102001)(59766001)(53806001)(87936001)(74876001)(76176001)(4396001)(77982001)(83072002)(51856001)(93136001)(36756003)(83506001)(76796001)(76786001)(93516002)(66066001)(46102001)(90146001)(54356001)(80022001)(65816001)(76482001)(56776001)(94316002)(81342001)(49866001)(74662001)(47736001)(47446002)(74706001)(74502001)(31966008)(47976001)(50986001)(81686001)(63696002)(81542001)(54316002)(85306002)(74366001)(86362001)(92726001)(87266001)(2656002)(81816001)(69226001); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR05MB285; H:DM2PR05MB288.namprd05.prod.outlook.com; CLIP:66.129.239.10; FPR:; InfoNoRecordsMX:1; A:1; LANG:en; Received: from mail8-co1 (localhost.localdomain [127.0.0.1]) by mail8-co1 (MessageSwitch) id 1390865491308316_14621; Mon, 27 Jan 2014 23:31:31 +0000 (UTC) Received: from CO1EHSMHS016.bigfish.com (unknown [10.243.78.231]) by mail8-co1.bigfish.com (Postfix) with ESMTP id 3C298A00046; Mon, 27 Jan 2014 23:31:31 +0000 (UTC) Received: from BL2PRD0510HT005.namprd05.prod.outlook.com (157.56.240.101) by CO1EHSMHS016.bigfish.com (10.243.66.26) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 27 Jan 2014 23:31:31 +0000 Received: from DM2PR05MB285.namprd05.prod.outlook.com (10.141.101.21) by BL2PRD0510HT005.namprd05.prod.outlook.com (10.255.100.40) with Microsoft SMTP Server (TLS) id 14.16.395.1; Mon, 27 Jan 2014 23:31:21 +0000 Received: from DM2PR05MB288.namprd05.prod.outlook.com (10.141.101.11) by DM2PR05MB285.namprd05.prod.outlook.com (10.141.101.21) with Microsoft SMTP Server (TLS) id 15.0.859.15; Mon, 27 Jan 2014 23:31:19 +0000 Received: from DM2PR05MB288.namprd05.prod.outlook.com ([10.141.101.11]) by DM2PR05MB288.namprd05.prod.outlook.com ([10.141.101.11]) with mapi id 15.00.0859.020; Mon, 27 Jan 2014 23:31:19 +0000 From: Suresh Kumar Vinapamula Venkata To: "softwires@ietf.org" Thread-Topic: New Version Notification for draft-vinapamula-softwire-dslite-prefix-binding-01.txt Thread-Index: AQHPG4+VkeG0pPjvkUKeaSTEk3ye25qYsoCA Date: Mon, 27 Jan 2014 23:31:19 +0000 Message-ID: In-Reply-To: <20140127184232.32526.3564.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [66.129.239.10] x-forefront-prvs: 0104247462 Content-Type: text/plain; charset="us-ascii" Content-ID: <4464AE3CDD26DA40AF84C8C5FC816BB3@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: [Softwires] FW: New Version Notification for draft-vinapamula-softwire-dslite-prefix-binding-01.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2014 23:31:38 -0000 Hello,=20 A revised IETF draft has been published. Please provide your comments. Thanks Suresh On 1/27/14 10:42 AM, "internet-drafts@ietf.org" wrote: > >A new version of I-D, >draft-vinapamula-softwire-dslite-prefix-binding-01.txt >has been successfully submitted by Suresh Vinapamula and posted to the >IETF repository. > >Name: draft-vinapamula-softwire-dslite-prefix-binding >Revision: 01 >Title: Recommendation for Prefix Binding in the Softwire DS-Lite Context >Document date: 2014-01-27 >Group: Individual Submission >Pages: 6 >URL: =20 >http://www.ietf.org/internet-drafts/draft-vinapamula-softwire-dslite-prefi >x-binding-01.txt >Status: =20 >https://datatracker.ietf.org/doc/draft-vinapamula-softwire-dslite-prefix-b >inding/ >Htmlized: =20 >http://tools.ietf.org/html/draft-vinapamula-softwire-dslite-prefix-binding >-01 >Diff: =20 >http://www.ietf.org/rfcdiff?url2=3Ddraft-vinapamula-softwire-dslite-prefix= -b >inding-01 > >Abstract: > This document describes possible issues induced by the change of the > B4 IPv6 address and sketches a set of recommendations. > > =20 > =20 > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >The IETF Secretariat > > > From chenycmx@gmail.com Mon Jan 27 18:23:53 2014 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 988D01A008F for ; Mon, 27 Jan 2014 18:23:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xn0gDuv2qDDs for ; Mon, 27 Jan 2014 18:23:51 -0800 (PST) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 912E91A0176 for ; Mon, 27 Jan 2014 18:23:50 -0800 (PST) Received: by mail-pa0-f43.google.com with SMTP id rd3so6705184pab.16 for ; Mon, 27 Jan 2014 18:23:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:reply-to:subject:references:mime-version:message-id :content-type; bh=1Atv0Nx6Eakn5WtmROt0Tt9NhWmgeGZZC/T6sDGFLJM=; b=F78J8MuhrBLDGzwK6VsbsY+T3UxS9AurXS6+kddLL3g3wvViPsl4frvUiye0IXtpB0 j71hgVrGNHVElNSwNrHjp1z9dMGS782aFCnqGogKDdaw9KZgxzFn6ysbroQUEQ7sXRfe ir/xgL/pJX67OH/AafnhwP9ydHNE0nGXtZ6KNbM4U1u1IEB0WS+/WaKYmpPrBqbTyF3p fEfvZwAtBEiSl0Fw63LPLMSF9Zs4OnZ1ggl8ObHrz3vmxMHg4dH0W9aa9rbjG8bax7vW CuS/UDxiOoTJI2iQgMVVIS9eNQtCJHYTSjk9Ltb6eglogVI/7u79/oTrm550dBSRgA2D cxwQ== X-Received: by 10.66.136.71 with SMTP id py7mr34188939pab.2.1390875827183; Mon, 27 Jan 2014 18:23:47 -0800 (PST) Received: from netlab-PC ([61.157.126.5]) by mx.google.com with ESMTPSA id j3sm36416385pbh.38.2014.01.27.18.23.41 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 27 Jan 2014 18:23:45 -0800 (PST) Date: Tue, 28 Jan 2014 10:23:42 +0800 From: "Yuchi Chen" To: "Suresh Krishnan" , "softwires WG" References: X-Priority: 3 X-GUID: 4DF77587-6236-41DD-8621-E484CA75CC30 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.92[cn] Mime-Version: 1.0 Message-ID: <2014012810233839495222@gmail.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart626634322105_=----" Cc: Yong Cui Subject: Re: [Softwires] Working group last call for draft-ietf-softwire-lw4over6-03 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: chenycmx List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 02:23:53 -0000 This is a multi-part message in MIME format. ------=_001_NextPart626634322105_=---- Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpJIHN1cHBvcnQgdG8gbW92ZSBmb3J3YXJkIHRoZSBkb2N1bWVudC4NCg0KQmVz dCByZWdhcmRzIQ0KDQoNCg0KWXVjaGkgQ2hlbg0KDQpGcm9tOiBTdXJlc2ggS3Jpc2huYW4NCkRh dGU6IDIwMTQtMDEtMTQgMTI6NDYNClRvOiBTb2Z0d2lyZXMgV0cNCkNDOiBZb25nIEN1aQ0KU3Vi amVjdDogW1NvZnR3aXJlc10gV29ya2luZyBncm91cCBsYXN0IGNhbGwgZm9yIGRyYWZ0LWlldGYt c29mdHdpcmUtbHc0b3ZlcjYtMDMNCkhpIGFsbCwNCiAgIFRoaXMgbWVzc2FnZSBzdGFydHMgYSB0 d28gd2VlayBzb2Z0d2lyZSB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBvbiANCmFkdmFuY2luZyB0 aGUgZHJhZnQgYWJvdXQgTGlnaHR3ZWlnaHQgNG92ZXI2IGFzIGEgU3RhbmRhcmRzIFRyYWNrIFJG Qy4gDQpUaGUgYXV0aG9ycyBiZWxpZXZlIHRoYXQgdGhpcyB2ZXJzaW9uIGhhcyBhZGRyZXNzZWQg YWxsIHRoZSBpc3N1ZXMgDQpyYWlzZWQgb24gdGhlIGRvY3VtZW50IHRpbGwgbm93LiBUaGUgbGF0 ZXN0IHZlcnNpb24gb2YgdGhlIGRyYWZ0IGlzIA0KYXZhaWxhYmxlIGF0DQoNCmh0dHA6Ly93d3cu aWV0Zi5vcmcvaWQvZHJhZnQtaWV0Zi1zb2Z0d2lyZS1sdzRvdmVyNi0wMy50eHQNCmh0dHA6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtc29mdHdpcmUtbHc0b3ZlcjYtMDMNCg0KU3Vi c3RhbnRpdmUgY29tbWVudHMgYW5kIHN0YXRlbWVudHMgb2Ygc3VwcG9ydC9vcHBvc2l0aW9uIGZv ciBhZHZhbmNpbmcgDQp0aGlzIGRvY3VtZW50IHNob3VsZCBiZSBkaXJlY3RlZCB0byB0aGUgbWFp bGluZyBsaXN0LiBFZGl0b3JpYWwgDQpzdWdnZXN0aW9ucyBjYW4gYmUgc2VudCBkaXJlY3RseSB0 byB0aGUgYXV0aG9ycy4gVGhpcyBsYXN0IGNhbGwgd2lsbCANCmNvbmNsdWRlIG9uIEphbnVhcnkg MjgsIDIwMTQuDQoNClJlZ2FyZHMsDQpTdXJlc2ggJiBZb25nDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KU29mdHdpcmVzIG1haWxpbmcgbGlzdA0KU29m dHdpcmVzQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Nv ZnR3aXJlcw== ------=_001_NextPart626634322105_=---- Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Hi all,
 
I support to move forward the document.
 
Best regards!
Yuc= hi=20 Chen
 
Date: 2014-01-14 12:46
Subject: [Softwires] Working group last call for=20 draft-ietf-softwire-lw4over6-03
Hi all,
   This message starts a two = week softwire working group last call on&nbs= p;
advancing the draft about Lightweight 4over6=  as a Standards Track RFC. 
The authors believe that this version h= as addressed all the issues 
raised on the document till now. The&nb= sp;latest version of the draft is 
available at
 
http://www.ietf.org/id/draft-ietf-softwire-lw4over6-03.txt
http://tools.ietf.org/html/draft-ietf-softwire-lw4over6-03
 
Substantive comments and statements of suppo= rt/opposition for advancing 
this document should be directed to the=  mailing list. Editorial 
suggestions can be sent directly to the=  authors. This last call will 
conclude on January 28, 2014.
 
Regards,
Suresh & Yong
_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires
------=_001_NextPart626634322105_=------ From Olaf.Bonness@telekom.de Mon Jan 27 23:16:58 2014 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B6911A01C9 for ; Mon, 27 Jan 2014 23:16:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.785 X-Spam-Level: X-Spam-Status: No, score=-2.785 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p9JCQCuFwIUs for ; Mon, 27 Jan 2014 23:16:54 -0800 (PST) Received: from tcmail43.telekom.de (tcmail43.telekom.de [80.149.113.173]) by ietfa.amsl.com (Postfix) with ESMTP id 8F2591A0161 for ; Mon, 27 Jan 2014 23:16:53 -0800 (PST) Received: from he101250.emea1.cds.t-internal.com ([10.125.92.153]) by tcmail41.telekom.de with ESMTP/TLS/AES128-SHA; 28 Jan 2014 08:16:49 +0100 Received: from HE113605.emea1.cds.t-internal.com ([169.254.1.99]) by HE101250.emea1.cds.t-internal.com ([fe80::e439:4046:12e2:e37%14]) with mapi; Tue, 28 Jan 2014 08:16:49 +0100 From: To: Date: Tue, 28 Jan 2014 08:16:48 +0100 Thread-Topic: [Softwires] Working group last call for draft-ietf-softwire-lw4over6-03 Thread-Index: Ac8Q447AA9x4sBSRTByZtDHiECb2NwLFSATw Message-ID: References: In-Reply-To: Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: softwires@ietf.org, cuiyong@tsinghua.edu.cn Subject: Re: [Softwires] Working group last call for draft-ietf-softwire-lw4over6-03 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 07:16:58 -0000 I support the doc to move forward. Olaf -----Urspr=FCngliche Nachricht----- Von: Softwires [mailto:softwires-bounces@ietf.org] Im Auftrag von Suresh Kr= ishnan Gesendet: Dienstag, 14. Januar 2014 05:46 An: Softwires WG Cc: Yong Cui Betreff: [Softwires] Working group last call for draft-ietf-softwire-lw4ove= r6-03 Hi all, This message starts a two week softwire working group last call on advan= cing the draft about Lightweight 4over6 as a Standards Track RFC.=20 The authors believe that this version has addressed all the issues raised o= n the document till now. The latest version of the draft is available at http://www.ietf.org/id/draft-ietf-softwire-lw4over6-03.txt http://tools.ietf.org/html/draft-ietf-softwire-lw4over6-03 Substantive comments and statements of support/opposition for advancing thi= s document should be directed to the mailing list. Editorial suggestions ca= n be sent directly to the authors. This last call will conclude on January = 28, 2014. Regards, Suresh & Yong _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires From Tina.Tsou.Zouting@huawei.com Tue Jan 28 00:11:18 2014 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2C621A025B for ; Tue, 28 Jan 2014 00:11:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.553 X-Spam-Level: * X-Spam-Status: No, score=1.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c0PA6tgQ4WlW for ; Tue, 28 Jan 2014 00:11:10 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6633F1A022D for ; Tue, 28 Jan 2014 00:11:10 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAN08474; Tue, 28 Jan 2014 08:11:05 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 28 Jan 2014 08:10:13 +0000 Received: from SZXEML451-HUB.china.huawei.com (10.82.67.194) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 28 Jan 2014 08:10:44 +0000 Received: from szxeml557-mbs.china.huawei.com ([169.254.6.63]) by szxeml451-hub.china.huawei.com ([10.82.67.194]) with mapi id 14.03.0158.001; Tue, 28 Jan 2014 16:10:38 +0800 From: Tina TSOU To: "ian.farrer@telekom.de" , "simon.perreault@viagenie.ca" , "softwires@ietf.org" Thread-Topic: [Softwires] Working group last call for draft-ietf-softwire-lw4over6-03 Thread-Index: AQHPGNvCCAY1lkRw/U2SWLkvmuG3Q5qZztJA Date: Tue, 28 Jan 2014 08:10:38 +0000 Message-ID: References: <52DD90B8.1060204@viagenie.ca> <52DE8017.6030208@viagenie.ca> <52DE9575.4010504@viagenie.ca> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.87.91] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [Softwires] =?gb2312?b?tPC4tDogIFdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxs?= =?gb2312?b?IGZvciBkcmFmdC1pZXRmLXNvZnR3aXJlLWx3NG92ZXI2LTAz?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 08:11:19 -0000 RGVhciBhbGwsDQpJIHN1cHBvcnQgYWR2YW5jaW5nIHRoaXMgZG9jdW1lbnQuIEl0IGlzIGJlaW5n IGRlcGxveWVkIGluIHNvbWUgbmV0d29ya3MuDQoNClRoYW5rIHlvdSwNClRpbmENCg0KDQotLS0t LdPKvP7Urbz+LS0tLS0NCreivP7IyzogU29mdHdpcmVzIFttYWlsdG86c29mdHdpcmVzLWJvdW5j ZXNAaWV0Zi5vcmddILT6se0gaWFuLmZhcnJlckB0ZWxla29tLmRlDQq3osvNyrG85DogMjAxNMTq MdTCMjTI1SAxNjoxMA0KytW8/sjLOiBzaW1vbi5wZXJyZWF1bHRAdmlhZ2VuaWUuY2E7IHNvZnR3 aXJlc0BpZXRmLm9yZw0K1vfM4jogUmU6IFtTb2Z0d2lyZXNdIFdvcmtpbmcgZ3JvdXAgbGFzdCBj YWxsIGZvciBkcmFmdC1pZXRmLXNvZnR3aXJlLWx3NG92ZXI2LTAzDQoNCg0KPg0KPk5FVzoNCj4g ICAgQW4gSVB2NiBhZGRyZXNzIGZyb20gYW4gYXNzaWduZWQgcHJlZml4IGlzIGFsc28gcmVxdWly ZWQgZm9yIHRoZSBsd0I0DQo+ICAgIHRvIHVzZSBhcyB0aGUgZW5jYXBzdWxhdGlvbiBzb3VyY2Ug YWRkcmVzcyBmb3IgdGhlIHNvZnR3aXJlLiAgSW4NCj4gICAgb3JkZXIgdG8gZW5hYmxlIGVuZC10 by1lbmQgcHJvdmlzaW9uaW5nLCB0aGUgSVB2NiBhZGRyZXNzIGlzDQo+ICAgIGNvbnN0cnVjdGVk IGJ5IHRha2luZyBhIC82NCBwcmVmaXggYXNzaWduZWQgdG8gdGhlIFdBTiBpbnRlcmZhY2UNCj4g ICAgYW5kIHN1ZmZpeGluZyA2NC1iaXRzIGZvciB0aGUgaW50ZXJmYWNlIGlkZW50aWZpZXIuICBB cyB0aGVyZSBtYXkgYmUNCj4gICAgbXVsdGlwbGUgV0FOIHByZWZpeGVzLCBvZiB3aGljaCBvbmx5 IG9uZSBjYW4gYmUgdXNlZCBmb3IgbHc0bzYsIHRoZQ0KPiAgICBDUEUgaXMgcHJvdmlzaW9uZWQg d2l0aCB0aGUga25vd2xlZGdlIG9mIHdoaWNoIG9uZSB0byB0YWtlLiAgVGhlIC8xMjgNCj4gICAg cHJlZml4IGlzIHRoZW4gY29uc3RydWN0ZWQgYXMgZm9sbG93czoNCg0KW2lhbl0gSSB0aGluayB0 aGF0IHJlYWRzIGJldHRlci4gQ2FuIEkgc3VnZ2VzdCBhIHNsaWdodCB3b3JkaW5nIHR3ZWFrPzoN Cg0Kcy9rbm93bGVkZ2Ugb2Ygd2hpY2ggb25lIHRvIHRha2UvbG9naWMgdG8gc2VsZWN0IHRoZSBj b3JyZWN0IG9uZQ0KDQpDaGVlcnMsDQpJYW4NCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KU29mdHdpcmVzIG1haWxpbmcgbGlzdA0KU29mdHdpcmVz QGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NvZnR3aXJl cw0K From jiangsheng@huawei.com Tue Jan 28 00:42:54 2014 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 313351A019D for ; Tue, 28 Jan 2014 00:42:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.736 X-Spam-Level: X-Spam-Status: No, score=-4.736 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3JV9AQARfvzU for ; Tue, 28 Jan 2014 00:42:52 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id E27E61A008A for ; Tue, 28 Jan 2014 00:42:51 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BCZ95267; Tue, 28 Jan 2014 08:42:47 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 28 Jan 2014 08:41:50 +0000 Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 28 Jan 2014 08:42:20 +0000 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.51]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0158.001; Tue, 28 Jan 2014 16:42:13 +0800 From: Sheng Jiang To: Suresh Krishnan , Softwires WG Thread-Topic: [Softwires] Working group last call for draft-ietf-softwire-lw4over6-03 Thread-Index: Ac8Q447AA9x4sBSRTByZtDHiECb2NwLIStoA Date: Tue, 28 Jan 2014 08:42:12 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923ADD981D@nkgeml512-mbx.china.huawei.com> References: In-Reply-To: Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.145] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Yong Cui Subject: Re: [Softwires] Working group last call for draft-ietf-softwire-lw4over6-03 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 08:42:54 -0000 SSBhbHNvIHN1cHBvcnQgYWR2YW5jaW5nIHRoaXMgZG9jdW1lbnQuIEl0IGlzIG1hdHVyZSBub3cu DQoNCkJlc3QgcmVnYXJkcywNCg0KU2hlbmcNCg0KPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+RnJvbTogU29mdHdpcmVzIFttYWlsdG86c29mdHdpcmVzLWJvdW5jZXNAaWV0Zi5vcmddIE9u IEJlaGFsZiBPZiBTdXJlc2gNCj5LcmlzaG5hbg0KPlNlbnQ6IFR1ZXNkYXksIEphbnVhcnkgMTQs IDIwMTQgMTI6NDYgUE0NCj5UbzogU29mdHdpcmVzIFdHDQo+Q2M6IFlvbmcgQ3VpDQo+U3ViamVj dDogW1NvZnR3aXJlc10gV29ya2luZyBncm91cCBsYXN0IGNhbGwgZm9yDQo+ZHJhZnQtaWV0Zi1z b2Z0d2lyZS1sdzRvdmVyNi0wMw0KPg0KPkhpIGFsbCwNCj4gICBUaGlzIG1lc3NhZ2Ugc3RhcnRz IGEgdHdvIHdlZWsgc29mdHdpcmUgd29ya2luZyBncm91cCBsYXN0IGNhbGwgb24NCj5hZHZhbmNp bmcgdGhlIGRyYWZ0IGFib3V0IExpZ2h0d2VpZ2h0IDRvdmVyNiBhcyBhIFN0YW5kYXJkcyBUcmFj ayBSRkMuDQo+VGhlIGF1dGhvcnMgYmVsaWV2ZSB0aGF0IHRoaXMgdmVyc2lvbiBoYXMgYWRkcmVz c2VkIGFsbCB0aGUgaXNzdWVzDQo+cmFpc2VkIG9uIHRoZSBkb2N1bWVudCB0aWxsIG5vdy4gVGhl IGxhdGVzdCB2ZXJzaW9uIG9mIHRoZSBkcmFmdCBpcw0KPmF2YWlsYWJsZSBhdA0KPg0KPmh0dHA6 Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtaWV0Zi1zb2Z0d2lyZS1sdzRvdmVyNi0wMy50eHQNCj5o dHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXNvZnR3aXJlLWx3NG92ZXI2LTAz DQo+DQo+U3Vic3RhbnRpdmUgY29tbWVudHMgYW5kIHN0YXRlbWVudHMgb2Ygc3VwcG9ydC9vcHBv c2l0aW9uIGZvciBhZHZhbmNpbmcNCj50aGlzIGRvY3VtZW50IHNob3VsZCBiZSBkaXJlY3RlZCB0 byB0aGUgbWFpbGluZyBsaXN0LiBFZGl0b3JpYWwNCj5zdWdnZXN0aW9ucyBjYW4gYmUgc2VudCBk aXJlY3RseSB0byB0aGUgYXV0aG9ycy4gVGhpcyBsYXN0IGNhbGwgd2lsbA0KPmNvbmNsdWRlIG9u IEphbnVhcnkgMjgsIDIwMTQuDQo+DQo+UmVnYXJkcywNCj5TdXJlc2ggJiBZb25nDQo+X19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5Tb2Z0d2lyZXMgbWFp bGluZyBsaXN0DQo+U29mdHdpcmVzQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9zb2Z0d2lyZXMNCg== From meng.wei2@zte.com.cn Tue Jan 28 00:48:00 2014 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAFDE1A018F; Tue, 28 Jan 2014 00:48:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.434 X-Spam-Level: X-Spam-Status: No, score=-102.434 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.535, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S5ADGqDi_Q5q; Tue, 28 Jan 2014 00:47:58 -0800 (PST) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id AB7911A008A; Tue, 28 Jan 2014 00:47:57 -0800 (PST) Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Websense Email Security Gateway with ESMTPS id 0A8711254ACF; Tue, 28 Jan 2014 16:47:41 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id s0S8lk3E083734; Tue, 28 Jan 2014 16:47:46 +0800 (GMT-8) (envelope-from meng.wei2@zte.com.cn) In-Reply-To: To: Suresh Krishnan MIME-Version: 1.0 X-KeepSent: 64A17F8D:F68A447F-48257C6E:00302D58; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: meng.wei2@zte.com.cn Date: Tue, 28 Jan 2014 16:47:37 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2014-01-28 16:47:33, Serialize complete at 2014-01-28 16:47:33 Content-Type: multipart/alternative; boundary="=_alternative 00307D1348257C6E_=" X-MAIL: mse02.zte.com.cn s0S8lk3E083734 Cc: Softwires WG , Softwires , Yong Cui Subject: Re: [Softwires] Working group last call for draft-ietf-softwire-lw4over6-03 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 08:48:01 -0000 This is a multipart message in MIME format. --=_alternative 00307D1348257C6E_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 U3VwcG9ydCArMQ0KDQpCUnOjrA0KV2VpDQoNCg0KIlNvZnR3aXJlcyIgPHNvZnR3aXJlcy1ib3Vu Y2VzQGlldGYub3JnPiAgMjAxNC0wMS0xNCAxMjo0NjoxNjoNCg0KPiBIaSBhbGwsDQo+ICAgIFRo aXMgbWVzc2FnZSBzdGFydHMgYSB0d28gd2VlayBzb2Z0d2lyZSB3b3JraW5nIGdyb3VwIGxhc3Qg Y2FsbCBvbiANCj4gYWR2YW5jaW5nIHRoZSBkcmFmdCBhYm91dCBMaWdodHdlaWdodCA0b3ZlcjYg YXMgYSBTdGFuZGFyZHMgVHJhY2sgUkZDLiANCj4gVGhlIGF1dGhvcnMgYmVsaWV2ZSB0aGF0IHRo aXMgdmVyc2lvbiBoYXMgYWRkcmVzc2VkIGFsbCB0aGUgaXNzdWVzIA0KPiByYWlzZWQgb24gdGhl IGRvY3VtZW50IHRpbGwgbm93LiBUaGUgbGF0ZXN0IHZlcnNpb24gb2YgdGhlIGRyYWZ0IGlzIA0K PiBhdmFpbGFibGUgYXQNCj4gDQo+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtaWV0Zi1z b2Z0d2lyZS1sdzRvdmVyNi0wMy50eHQNCj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtaWV0Zi1zb2Z0d2lyZS1sdzRvdmVyNi0wMw0KPiANCj4gU3Vic3RhbnRpdmUgY29tbWVudHMg YW5kIHN0YXRlbWVudHMgb2Ygc3VwcG9ydC9vcHBvc2l0aW9uIGZvciBhZHZhbmNpbmcgDQo+IHRo aXMgZG9jdW1lbnQgc2hvdWxkIGJlIGRpcmVjdGVkIHRvIHRoZSBtYWlsaW5nIGxpc3QuIEVkaXRv cmlhbCANCj4gc3VnZ2VzdGlvbnMgY2FuIGJlIHNlbnQgZGlyZWN0bHkgdG8gdGhlIGF1dGhvcnMu IFRoaXMgbGFzdCBjYWxsIHdpbGwgDQo+IGNvbmNsdWRlIG9uIEphbnVhcnkgMjgsIDIwMTQuDQo+ IA0KPiBSZWdhcmRzLA0KPiBTdXJlc2ggJiBZb25nDQo+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+IFNvZnR3aXJlcyBtYWlsaW5nIGxpc3QNCj4gU29m dHdpcmVzQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v c29mdHdpcmVzDQoNCg== --=_alternative 00307D1348257C6E_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlN1cHBvcnQgKzE8L2ZvbnQ+DQo8 YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkJSc6OsPC9mb250Pg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5XZWk8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8 YnI+PHR0Pjxmb250IHNpemU9Mj4mcXVvdDtTb2Z0d2lyZXMmcXVvdDsgJmx0O3NvZnR3aXJlcy1i b3VuY2VzQGlldGYub3JnJmd0Ow0KJm5ic3A7MjAxNC0wMS0xNCAxMjo0NjoxNjo8YnI+DQo8YnI+ DQomZ3Q7IEhpIGFsbCw8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDtUaGlzIG1lc3NhZ2Ugc3RhcnRz IGEgdHdvIHdlZWsgc29mdHdpcmUgd29ya2luZyBncm91cA0KbGFzdCBjYWxsIG9uIDxicj4NCiZn dDsgYWR2YW5jaW5nIHRoZSBkcmFmdCBhYm91dCBMaWdodHdlaWdodCA0b3ZlcjYgYXMgYSBTdGFu ZGFyZHMgVHJhY2sNClJGQy4gPGJyPg0KJmd0OyBUaGUgYXV0aG9ycyBiZWxpZXZlIHRoYXQgdGhp cyB2ZXJzaW9uIGhhcyBhZGRyZXNzZWQgYWxsIHRoZSBpc3N1ZXMNCjxicj4NCiZndDsgcmFpc2Vk IG9uIHRoZSBkb2N1bWVudCB0aWxsIG5vdy4gVGhlIGxhdGVzdCB2ZXJzaW9uIG9mIHRoZSBkcmFm dCBpcw0KPGJyPg0KJmd0OyBhdmFpbGFibGUgYXQ8YnI+DQomZ3Q7IDxicj4NCiZndDsgaHR0cDov L3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1pZXRmLXNvZnR3aXJlLWx3NG92ZXI2LTAzLnR4dDxicj4N CiZndDsgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1zb2Z0d2lyZS1sdzRv dmVyNi0wMzxicj4NCiZndDsgPGJyPg0KJmd0OyBTdWJzdGFudGl2ZSBjb21tZW50cyBhbmQgc3Rh dGVtZW50cyBvZiBzdXBwb3J0L29wcG9zaXRpb24gZm9yIGFkdmFuY2luZw0KPGJyPg0KJmd0OyB0 aGlzIGRvY3VtZW50IHNob3VsZCBiZSBkaXJlY3RlZCB0byB0aGUgbWFpbGluZyBsaXN0LiBFZGl0 b3JpYWwgPGJyPg0KJmd0OyBzdWdnZXN0aW9ucyBjYW4gYmUgc2VudCBkaXJlY3RseSB0byB0aGUg YXV0aG9ycy4gVGhpcyBsYXN0IGNhbGwgd2lsbA0KPGJyPg0KJmd0OyBjb25jbHVkZSBvbiBKYW51 YXJ5IDI4LCAyMDE0Ljxicj4NCiZndDsgPGJyPg0KJmd0OyBSZWdhcmRzLDxicj4NCiZndDsgU3Vy ZXNoICZhbXA7IFlvbmc8YnI+DQomZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPGJyPg0KJmd0OyBTb2Z0d2lyZXMgbWFpbGluZyBsaXN0PGJyPg0KJmd0 OyBTb2Z0d2lyZXNAaWV0Zi5vcmc8YnI+DQomZ3Q7IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vc29mdHdpcmVzPGJyPg0KPC9mb250PjwvdHQ+DQo= --=_alternative 00307D1348257C6E_=-- From branimir.rajtar.ietf@gmail.com Tue Jan 28 01:04:55 2014 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 930EF1A02D9; Tue, 28 Jan 2014 01:04:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MQhVwZ44XrJy; Tue, 28 Jan 2014 01:04:53 -0800 (PST) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id 651641A026A; Tue, 28 Jan 2014 01:04:53 -0800 (PST) Received: by mail-wg0-f48.google.com with SMTP id x13so216037wgg.27 for ; Tue, 28 Jan 2014 01:04:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7UqA5Ljo4/BN/7YcIMTAcwwQwoAVz0jMsk1hsBtbviY=; b=p3BAejGnsqntthGODqVb6VyoJ8P6CU521f6zprzFIR9H5f0eAXOTo8l7DzT0WDJlLJ MrtSonXYIvZa8FEM0P9nIEbtE2FmRhBR0N/HW1yaAKIfXCOuztMaASPVN9BImYGxzo0u lRBXhqefRvTGhIV0OeTI+K9jWeG+il/qP3lSDM2dFRB+yXPUDdmz/uBDmulDklepuTiZ sjlDHXkyQG4E3Guf1u04e70IaqsP2mI4FDPub3XYmDsrbZFJG326aVCddfrdKxonE6BO eK+HZTPZoTp9HMyIPZXOcE5FUea1auHslXIn4UmJbP5rV+M4RH1+hkm9jh9gkPwfm4N2 YIxg== MIME-Version: 1.0 X-Received: by 10.180.188.230 with SMTP id gd6mr1265399wic.15.1390899890352; Tue, 28 Jan 2014 01:04:50 -0800 (PST) Received: by 10.194.137.206 with HTTP; Tue, 28 Jan 2014 01:04:50 -0800 (PST) In-Reply-To: References: Date: Tue, 28 Jan 2014 10:04:50 +0100 Message-ID: From: Branimir Rajtar To: meng.wei2@zte.com.cn Content-Type: multipart/alternative; boundary=001a11c383c6e1f6ab04f1041d2c Cc: Softwires WG , Softwires , Yong Cui Subject: Re: [Softwires] Working group last call for draft-ietf-softwire-lw4over6-03 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 09:04:55 -0000 --001a11c383c6e1f6ab04f1041d2c Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable +1 for support Branimir On Tue, Jan 28, 2014 at 9:47 AM, wrote: > > Support +1 > > BRs=A3=AC > Wei > > > "Softwires" 2014-01-14 12:46:16: > > > > Hi all, > > This message starts a two week softwire working group last call on > > advancing the draft about Lightweight 4over6 as a Standards Track RFC. > > The authors believe that this version has addressed all the issues > > raised on the document till now. The latest version of the draft is > > available at > > > > http://www.ietf.org/id/draft-ietf-softwire-lw4over6-03.txt > > http://tools.ietf.org/html/draft-ietf-softwire-lw4over6-03 > > > > Substantive comments and statements of support/opposition for advancing > > this document should be directed to the mailing list. Editorial > > suggestions can be sent directly to the authors. This last call will > > conclude on January 28, 2014. > > > > Regards, > > Suresh & Yong > > _______________________________________________ > > Softwires mailing list > > Softwires@ietf.org > > https://www.ietf.org/mailman/listinfo/softwires > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > > --001a11c383c6e1f6ab04f1041d2c Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable
+1 for support

Branimir


On Tue, Jan 28, 2= 014 at 9:47 AM, <meng.wei2@zte.com.cn> wrote:

Support +1

BRs=A3=AC
Wei


"Softwires" <softwires-bounces@ietf.org>  2014-01-14 12:46:16:


> Hi all,
>    This message starts a two week softwire working group last call on
> advancing the draft about Lightweight 4over6 as a Standards Track RFC.
> The authors believe that this version has addressed all the issues
> raised on the document till now. The latest version of the draft is
> available at
>
> http://www.ietf.org/id/draft-ietf-softwire-lw4over6-03.t= xt
> http://tools.ietf.org/html/draft-ietf-softwire-lw4over6-= 03
>
> Substantive comments and statements of support/opposition for advancin= g
> this document should be directed to the mailing list. Editorial
> suggestions can be sent directly to the authors. This last call will
> conclude on January 28, 2014.
>
> Regards,
> Suresh & Yong
> _______________________________________________
> Softwires mailing list
> Softwires@ietf= .org
> https://www.ietf.org/mailman/listinfo/softwires
_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires


--001a11c383c6e1f6ab04f1041d2c-- From hermin.anggawijaya@gmail.com Tue Jan 28 01:59:24 2014 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A74A91A02BA for ; Tue, 28 Jan 2014 01:59:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U1Ht4neYfhnv for ; Tue, 28 Jan 2014 01:59:23 -0800 (PST) Received: from mail-vc0-x234.google.com (mail-vc0-x234.google.com [IPv6:2607:f8b0:400c:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id DB5711A0229 for ; Tue, 28 Jan 2014 01:59:22 -0800 (PST) Received: by mail-vc0-f180.google.com with SMTP id ks9so93908vcb.25 for ; Tue, 28 Jan 2014 01:59:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=StetcnGxMH8XO/osha14xyTtg3Z0A6Bk4+UIrDl+a3Q=; b=df/LTG2sOudXMpP9n0TIUeJWcfZNl6KT8EtcME0fluTD12hbaIsMx6uVMcswCIbtVF mXLuJC93xEEO3zCChtCGQ9ZL2mUvzjmN2KbmDl3HseWaqxPUZx540OGilAY/SOWIZPSX v7eoBzc6eL1E1ByWlH2/u4xXtK/UA1wWsU+2GMhNR1A2Sg1f+0vR5iQ/4yzp5Nscwv2h BfKP7YgtNCKcsfd1//JU0gTBg5z2SSdAuRQC478H9iVU8ajYczkNCQ15uYCPnC/b8uUq adIFLauXVAj5bfdmqNaC2pH6Hht6V8yze12DSerrfQCLNZjbrPEy72vEWAT9VZ+bEXs7 exYg== MIME-Version: 1.0 X-Received: by 10.221.55.8 with SMTP id vw8mr288998vcb.8.1390903160059; Tue, 28 Jan 2014 01:59:20 -0800 (PST) Received: by 10.58.107.180 with HTTP; Tue, 28 Jan 2014 01:59:19 -0800 (PST) Date: Tue, 28 Jan 2014 22:59:19 +1300 Message-ID: From: Hermin Anggawijaya To: Suresh Krishnan Content-Type: multipart/alternative; boundary=001a11338a6ac6b03f04f104e02b Cc: softwires@ietf.org, Yong Cui Subject: Re: [Softwires] Working group last call for draft-ietf-softwire-lw4over6-03 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 09:59:24 -0000 --001a11338a6ac6b03f04f104e02b Content-Type: text/plain; charset=ISO-8859-1 I support for advancing the draft. H. Anggawijaya On 2014-1-14, at ??12:46, Suresh Krishnan wrote: > > > Hi all, > > This message starts a two week softwire working group last call on > > advancing the draft about Lightweight 4over6 as a Standards Track RFC. > > The authors believe that this version has addressed all the issues > > raised on the document till now. The latest version of the draft is > > available at > > > > http://www.ietf.org/id/draft-ietf-softwire-lw4over6-03.txt > > http://tools.ietf.org/html/draft-ietf-softwire-lw4over6-03 > > > > Substantive comments and statements of support/opposition for advancing > > this document should be directed to the mailing list. Editorial > > suggestions can be sent directly to the authors. This last call will > > conclude on January 28, 2014. > > > > Regards, > > Suresh & Yong > > _______________________________________________ > > Softwires mailing list > > Softwires@ietf.org > > https://www.ietf.org/mailman/listinfo/softwires > --001a11338a6ac6b03f04f104e02b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

I support for advancing the draft.

H. Anggawijaya


On 2014-1-14, at ??12:46, Suresh Krishnan wrote:

> Hi all,
> =A0 This message starts a two week softwire working group last call on=
> advancing the draft about Lightweight 4over6 as a Standards Track RFC.=
> The authors believe that this version has addressed all the issues
> raised on the document till now. The latest version of the draft is > available at
>
> http://www.ietf.org/id/draft-ietf-softwire-lw4over6-03.t= xt
> http://tools.ietf.org/html/draft-ietf-softwire-lw4over6-= 03
>
> Substantive comments and statements of support/opposition for advancin= g
> this document should be directed to the mailing list. Editorial
> suggestions can be sent directly to the authors. This last call will > conclude on January 28, 2014.
>
> Regards,
> Suresh & Yong
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires
--001a11338a6ac6b03f04f104e02b-- From yiu_lee@cable.comcast.com Tue Jan 28 04:47:22 2014 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C15681A039F for ; Tue, 28 Jan 2014 04:47:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.733 X-Spam-Level: X-Spam-Status: No, score=-0.733 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=0.001, RP_MATCHES_RCVD=-0.535, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lC__bSToOODL for ; Tue, 28 Jan 2014 04:47:21 -0800 (PST) Received: from cable.comcast.com (pacdcavout01.cable.comcast.com [69.241.43.119]) by ietfa.amsl.com (Postfix) with ESMTP id DB8221A02DF for ; Tue, 28 Jan 2014 04:47:20 -0800 (PST) Received: from ([24.40.56.121]) by pacdcavout01.cable.comcast.com with ESMTP id 97wm3m1.81117408; Tue, 28 Jan 2014 07:47:13 -0500 Received: from PACDCEXMB05.cable.comcast.com ([169.254.7.5]) by pacdcexhub04.cable.comcast.com ([fe80::1532:d330:f9a5:c8a1%18]) with mapi id 14.03.0158.001; Tue, 28 Jan 2014 07:47:13 -0500 From: "Lee, Yiu" To: Suresh Krishnan , Softwires WG Thread-Topic: [Softwires] Working group last call for draft-ietf-softwire-lw4over6-03 Thread-Index: AQHPHCcQd8DgPnyS1EG7+Q6RU49EFA== Date: Tue, 28 Jan 2014 12:47:19 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [68.87.16.246] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3473740032_1313027" MIME-Version: 1.0 Subject: Re: [Softwires] Working group last call for draft-ietf-softwire-lw4over6-03 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 12:47:23 -0000 --B_3473740032_1313027 Content-type: multipart/alternative; boundary="B_3473740030_1289228" --B_3473740030_1289228 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit I also support moving forward. BR, Yiu From: Cong Liu Date: Monday, January 27, 2014 at 2:02 PM To: Suresh Krishnan Cc: Softwires WG , Yong Cui Subject: Re: [Softwires] Working group last call for draft-ietf-softwire-lw4over6-03 Hi all, I support advancing this document. Best Regards, Cong 2014-01-14 Suresh Krishnan > Hi all, > This message starts a two week softwire working group last call on > advancing the draft about Lightweight 4over6 as a Standards Track RFC. > The authors believe that this version has addressed all the issues > raised on the document till now. The latest version of the draft is > available at > > http://www.ietf.org/id/draft-ietf-softwire-lw4over6-03.txt > http://tools.ietf.org/html/draft-ietf-softwire-lw4over6-03 > > Substantive comments and statements of support/opposition for advancing > this document should be directed to the mailing list. Editorial > suggestions can be sent directly to the authors. This last call will > conclude on January 28, 2014. > > Regards, > Suresh & Yong > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires --B_3473740030_1289228 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
I also support moving forward= .

BR,
Yiu

From: Cong Liu <gnocuil@gmail.com>
Date: = Monday, January 27, 2014 at 2:02 PM
To: <= /span> Suresh Krishnan <sur= esh.krishnan@ericsson.com>
Cc: Softwires WG <softwires@ietf.org<= /a>>, Yong Cui <cuiyong@tsing= hua.edu.cn>
Subject: Re: [S= oftwires] Working group last call for draft-ietf-softwire-lw4over6-03

Hi all,

I support advancing this document. 
=
Best Regards,
Cong


2014-01-14 Suresh Krishnan <suresh= .krishnan@ericsson.com>
Hi all,
   This message starts a two week softwire working group last cal= l on
advancing the draft about Lightweight 4over6 as a Standards Track RFC.
The authors believe that this version has addressed all the issues
raised on the document till now. The latest version of the draft is
available at

http://www.ietf.org/id/draft-ietf-softwire-lw4= over6-03.txt
http://tools.ietf.org/html/draft-ietf-softwire-= lw4over6-03

Substantive comments and statements of support/opposition for advancing
= this document should be directed to the mailing list. Editorial
suggestions can be sent directly to the authors. This last call will
conclude on January 28, 2014.

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

 --B_3473740030_1289228-- --B_3473740032_1313027 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIVmQYJKoZIhvcNAQcCoIIVijCCFYYCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EzEwggU0MIIEHKADAgECAhEAhv91O+XLvFe6aL7jamWK/zANBgkqhkiG9w0BAQUFADCBkzEL MAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGll bnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xMzEwMjkwMDAwMDBa Fw0xNDEwMjkyMzU5NTlaMCoxKDAmBgkqhkiG9w0BCQEWGXlpdV9sZWVAY2FibGUuY29tY2Fz dC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC68JKaZEJ0LViFfKWqzK16 nmjp8sC/1jA2TzrY2At4mju7v3WF1auk6Vqu2eTNoOIrkAvmseseON8/1jekEzEcDejhGAIf WypQyVw0Dxi+0FVdUi59simiUcP3S4bU9sCIUbJl9Pbl83gtzqZ6rg20K0OHgHWCJ/Yk47qd y8aHN8iOX88YFKzvYM5tbDp2La6c1cO5aXujFL5/31Ua6Q+YB/C/vqRtUxGgqU/akpem+mUl sVlmJEyeBcS8M4goFFWeHidg17gjtMFEdZOwmueJ8+mlVpo+LFlE9Mm8Kk+qEwLLbdht8vDX hpmnpT/ZQBGFhI2lF9x5Cy6nw50PpIEvAgMBAAGjggHpMIIB5TAfBgNVHSMEGDAWgBR6E04A dFvGeGNkJ8Ev4qBbvHnFezAdBgNVHQ4EFgQUoLfLQmNdcYV5HlfkXY4zHV0EjpQwDgYDVR0P AQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0lBBkwFwYIKwYBBQUHAwQGCysGAQQBsjEB AwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEBATArMCkG CCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBXBgNVHR8EUDBOMEyg SqBIhkZodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlv bmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGIBggrBgEFBQcBAQR8MHowUgYIKwYBBQUHMAKGRmh0 dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2Vj dXJlRW1haWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAk BgNVHREEHTAbgRl5aXVfbGVlQGNhYmxlLmNvbWNhc3QuY29tMA0GCSqGSIb3DQEBBQUAA4IB AQBRECrUaqaZ9idV79Ty+gKD3ikFYrD/oXOAYQUeccSscBzy8DlahjhnDM8NXaA2ny5vI85/ vMJl3WUWD5J7Ft9L8uw9k0EfsUCIqZQp+9mZcXtqynCeKcAL/p2Ys0p//aqf00wyWooUwhPW aniWqP1+VqoTHVrIOQ1xrbBeLbm3f3F4DXVxO9wRlFndeyqStECo9jamYsLnHOFeCfxtmXE/ czOemMA3ZFWeycKD688z2vrDK5RS54fyTUZBpDR+xZJ0tQIDZu4cwoVd0tD+3yjgDpxCdSw7 zkWyqCZ/MmhTlMx0Jc7b2X3QcHNud5lDyYgy8tvaUjlQTrW3Hx2XbeFXMIIFGjCCBAKgAwIB AgIQbRnqpxlPajMi5iIyeqpx3jANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJU UlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNV BAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0x MTA0MjgwMDAwMDBaFw0yMDA1MzAxMDQ4MzhaMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMS R3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8g Q0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg U2VjdXJlIEVtYWlsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoSEW0tX mNReL4uk4UDIo1NYX2Zl8TJO958yfVXQeExVt0KU4PkncQfFxmmkuTLE8UAakMwnVmJ/F7Vx aa7lIBvky2NeYMqiQfZq4aP/uN8fSG1lQ4wqLitjOHffsReswtqCAtbUMmrUZ28gE49cNfrl VICv2HEKHTcKAlBTbJUdqRAUtJmVWRIx/wmi0kzcUtve4kABW0ho3cVKtODtJB86r3FfB+Os vxQ7sCVxaD30D9YXWEYVgTxoi4uDD216IVfmNLDbMn7jSuGlUnJkJpFOpZIP/+CxYP0ab2hR mWONGoulzEKbm30iY9OpoPzOnpDfRBn0XFs1uhbzp5v/wQIDAQABo4IBSzCCAUcwHwYDVR0j BBgwFoAUiYJnfcSdJnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFHoTTgB0W8Z4Y2QnwS/ioFu8 ecV7MA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEAMBEGA1UdIAQKMAgwBgYE VR0gADBYBgNVHR8EUTBPME2gS6BJhkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVROLVVT RVJGaXJzdC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDB0BggrBgEFBQcBAQRo MGYwPQYIKwYBBQUHMAKGMWh0dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BZGRUcnVzdENs aWVudF9DQS5jcnQwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJ KoZIhvcNAQEFBQADggEBAIXWvnhXVW0zf0RS/kLVBqgBA4CK+w2y/Uq/9q9BSfUbWsXSrRtz bj7pJnzmTJjBMCjfy/tCPKElPgp11tA9OYZm0aGbtU2bb68obB2v5ep0WqjascDxdXovnrqT ecr+4pEeVnSy+I3T4ENyG+2P/WA5IEf7i686ZUg8mD2lJb+972DgSeUWyOs/Q4Pw4O4NwdPN M1+b0L1garM7/vrUyTo8H+2b/5tJM75CKTmD7jNpLoKdRU2oadqAGx490hpdfEeZpZsIbRKZ htZdVwcbpzC+S0lEuJB+ytF5OOu0M/qgOl0mWJ5hVRi0IdWZ1eBDQEIwvuql55TSsP7zdfl/ bucwggSdMIIDhaADAgECAhA0PekrrCc0/4/LNJT7zHBUMA0GCSqGSIb3DQEBBQUAMG8xCzAJ BgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0 ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3Qw HhcNMDUwNjA3MDgwOTEwWhcNMjAwNTMwMTA0ODM4WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNV BAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVT VCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMT LVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjM apjVTTUZuaRC5c5J4oovHnzSMQfHTrSDZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKT zMmkMpW7DE8wvZigC4vlbhuiRvp4vKJvq1lepS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZG zaCl6r4LznY6eg6b6vzaJ1s9cx8i5khhxkzzabGoLhu21DEgLLyCio6kDqXXiUP8FlqvHXHX EVnauocNr/rz4cLwpMVnjNbWVDreCqS6A3ezZcj9HtN0YqoYymiTHqGFfvVHZcv4TVcodNI0 /zC27vZiMBSMLOsCAwEAAaOB9DCB8TAfBgNVHSMEGDAWgBStvZh6NLQm9/rEJlTvA73gJMtU GjAdBgNVHQ4EFgQUiYJnfcSdJnAAS7RQSHzePa4Ebn0wDgYDVR0PAQH/BAQDAgEGMA8GA1Ud EwEB/wQFMAMBAf8wEQYDVR0gBAowCDAGBgRVHSAAMEQGA1UdHwQ9MDswOaA3oDWGM2h0dHA6 Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFsQ0FSb290LmNybDA1BggrBgEF BQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZI hvcNAQEFBQADggEBAAG8nONjKLDzMQHC33vdYqABnSMxD5ySc1NR6h9M+tafxMovZ354Mw90 FrmRh5H1iib6ZHAA2B75CwRiUIeTgdTa9SPbNLuFVrRwNG54gzcehRzFERWSX4cXvaxq/fHC 0cyJX7F88D5R8jXzfOxgmGs6K+Dv37N9huu1G/Vb7KJ8mBPXAFC50S1z3gN4dOEFhTFey5q5 nZTGuZQ3dXLcRPtn6PD6JR5Sp9ol6UfgoMc8oE6xCjb7d0if75eK+7T+45QUqIO8XC0/0mBx YO7CcYIM6Yg249ogtKOgbKqWS7iAjnXKSQf2OxS639wF2Z/b4LLmTaB4JufnLW5/X8YeiBUw ggQ2MIIDHqADAgECAgEBMA0GCSqGSIb3DQEBBQUAMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQK EwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsx IjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMDAwNTMwMTA0ODM4WhcN MjAwNTMwMTA0ODM4WjBvMQswCQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAk BgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVz dCBFeHRlcm5hbCBDQSBSb290MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAt/ca M+byAAQtOeBOW+0fvGwPzbX6I7bO3psRM5ekKUx9k5+9SryT7QMa44/P5W1QWtaXKZRagLBJ etsulf24yr83OC0ePpFBrXBWx/BPP+gynnTKyJBU6cZfD3idmkA8Dqxhql4Uj56HoWpQ3Nea Tq8Fs6ZxlJxxs1BgCscTnTgHhgKo6ahpJhiQq0ywTyOrOk+E2N/On+Fpb7vXQtdrROTHre5t QV9yWnEIN7N5ZaRZoJQ39wAvDcKSctrQOHLbFKhFxF0qfbe01sTurM0TRLfJK91DACX6Yblp algjEbenM49WdVn1zSnXRrcKK2W200JvFbK4e/vv6V1T1TRaJwIDAQABo4HcMIHZMB0GA1Ud DgQWBBStvZh6NLQm9/rEJlTvA73gJMtUGjALBgNVHQ8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB /zCBmQYDVR0jBIGRMIGOgBStvZh6NLQm9/rEJlTvA73gJMtUGqFzpHEwbzELMAkGA1UEBhMC U0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBU VFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdIIBATANBgkq hkiG9w0BAQUFAAOCAQEAsJvghSXC1iPiD5YGkp1BmJzZhHmB2R5bFAcjNmWPsNh3u6xBbEdg g1Gw+TI95/z2JhPHgBalv1r8h894eYkhmuJMBwqGNbzy3lHE0pa33H5O7nD9HDnrDAJRFC2O vRbgwd9Gdeckrez0QrSFk3AQZ7qdBjVKGNMresxRQqF6Y9Hmu6HFK8I2vhMN5r1jfnl7pwkN QKtq3Y+Kw/b2jBpCBVHURfWfp2IhaBUgQzyZ53y9JNipkRdziD9WGzE4GLRxD5rNyA6eji4b 4YyYg8sfMfFETMYEc0l2YA/H+L0XgGsu6cxMDlqaeQ8gCi7VnmMmHlWSlNiCF1p70LzHj06G BDGCAjAwggIsAgEBMIGpMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5j aGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5 MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBAhEAhv91O+XLvFe6aL7jamWK/zAJBgUrDgMCGgUAoF0wIwYJKoZIhvcNAQkEMRYEFG7K Pcx6XzblC52V1QM9iJjKaAyYMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTE0MDEyODEyNDcxMFowDQYJKoZIhvcNAQEBBQAEggEAUtsPl7t5nxrHvRfnSvwn /Yl+mzrZcEjbzVsYWmV6sHtqGJMgzrZWEUjcRi7tJEqVEifu+67c2TeBqpvH9eJFKIRyvIOb o0Umj/rApiUk9sBuZiUjszxxcvYG48RrhMkSQiTSCyUOzRdo9ulhz9EZi1dKFsg8zdZSf8mh lQZ35Y0CX116ORMVpss3czV6Jf5R1RhFt8Ddj0gYnckIGPtSjpmT5WgYI8CHFQkC5VINf2cR mwYrQKfD57QWUU0z1I3C9E3P4MYAJmFArheL4ocw2ypysVGd6kz6zJ0oZfHg9Uf6Zo6vDfHE +5XPzl8JkYxEBnpNWH8ug/Wza10W7nmVwg== --B_3473740032_1313027-- From ales.vizdal@t-mobile.cz Tue Jan 28 08:06:28 2014 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF7901A0437 for ; Tue, 28 Jan 2014 08:06:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.786 X-Spam-Level: X-Spam-Status: No, score=-0.786 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10eIzHE3jh0n for ; Tue, 28 Jan 2014 08:06:26 -0800 (PST) Received: from ctxmailhub.t-mobile.cz (ctxmailhub.t-mobile.cz [93.153.104.87]) by ietfa.amsl.com (Postfix) with ESMTP id 6BBE41A0435 for ; Tue, 28 Jan 2014 08:06:26 -0800 (PST) From: =?iso-8859-2?Q?V=EDzdal_Ale=B9?= To: "softwires@ietf.org" Date: Tue, 28 Jan 2014 17:06:21 +0100 Thread-Topic: [Softwires] Working group last call for draft-ietf-softwire-lw4over6-03 Thread-Index: Ac8cD7FcMdbLJpl+R1mFVC1K9HZ5nAAMomMQ Message-ID: <1808340F7EC362469DDFFB112B37E2FCDA3249DB99@SRVHKE02.rdm.cz> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-loop: 2 Content-Type: multipart/alternative; boundary="_000_1808340F7EC362469DDFFB112B37E2FCDA3249DB99SRVHKE02rdmcz_" MIME-Version: 1.0 X-CFilter-Loop: Forwarded Cc: Yong Cui Subject: Re: [Softwires] Working group last call for draft-ietf-softwire-lw4over6-03 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 16:06:29 -0000 --_000_1808340F7EC362469DDFFB112B37E2FCDA3249DB99SRVHKE02rdmcz_ Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable +1 to support advancing this document (with the respective comments incorpo= rated) Ales From: Softwires [mailto:softwires-bounces@ietf.org] On Behalf Of Hermin Ang= gawijaya Sent: Tuesday, January 28, 2014 10:59 AM To: Suresh Krishnan Cc: softwires@ietf.org; Yong Cui Subject: Re: [Softwires] Working group last call for draft-ietf-softwire-lw= 4over6-03 I support for advancing the draft. H. Anggawijaya On 2014-1-14, at ??12:46, Suresh Krishnan wrote: > Hi all, > This message starts a two week softwire working group last call on > advancing the draft about Lightweight 4over6 as a Standards Track RFC. > The authors believe that this version has addressed all the issues > raised on the document till now. The latest version of the draft is > available at > > http://www.ietf.org/id/draft-ietf-softwire-lw4over6-03.txt > http://tools.ietf.org/html/draft-ietf-softwire-lw4over6-03 > > Substantive comments and statements of support/opposition for advancing > this document should be directed to the mailing list. Editorial > suggestions can be sent directly to the authors. This last call will > conclude on January 28, 2014. > > Regards, > Suresh & Yong > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires --_000_1808340F7EC362469DDFFB112B37E2FCDA3249DB99SRVHKE02rdmcz_ Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable

+1 to support advancing thi= s document (with the respective comments incorporated)

 

Ales

=

 

From: Softwires [mailto:softwires-bounces@ietf= .org] On Behalf Of Hermin Anggawijaya
Sent: Tuesday, Janua= ry 28, 2014 10:59 AM
To: Suresh Krishnan
Cc: softwires@= ietf.org; Yong Cui
Subject: Re: [Softwires] Working group last ca= ll for draft-ietf-softwire-lw4over6-03

 

=  

I support for advancing the draft.

H. Anggawijaya



On= 2014-1-14, at ??12:46, Suresh Krishnan wrote:


&g= t; Hi all,
>   This message starts a two week softwire working g= roup last call on
> advancing the draft about Lightweight 4over6 as a= Standards Track RFC.
> The authors believe that this version has add= ressed all the issues
> raised on the document till now. The latest v= ersion of the draft is
> available at
>
> h= ttp://www.ietf.org/id/draft-ietf-softwire-lw4over6-03.txt
> http://tools.ietf.org/html/draft-ietf-softwire-lw4over6-03
= >
> Substantive comments and statements of support/opposition for = advancing
> this document should be directed to the mailing list. Edi= torial
> suggestions can be sent directly to the authors. This last c= all will
> conclude on January 28, 2014.
>
> Regards,
= > Suresh & Yong
> ____________________________________________= ___
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listin= fo/softwires

<= /div>
= --_000_1808340F7EC362469DDFFB112B37E2FCDA3249DB99SRVHKE02rdmcz_-- From swmike@swm.pp.se Tue Jan 28 09:02:24 2014 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CBF51A03F6 for ; Tue, 28 Jan 2014 09:02:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.386 X-Spam-Level: X-Spam-Status: No, score=-4.386 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ghBZphGKGr6c for ; Tue, 28 Jan 2014 09:02:22 -0800 (PST) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) by ietfa.amsl.com (Postfix) with ESMTP id C1CD81A029D for ; Tue, 28 Jan 2014 09:02:21 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 8BA589C; Tue, 28 Jan 2014 18:02:18 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 8514C9A for ; Tue, 28 Jan 2014 18:02:18 +0100 (CET) Date: Tue, 28 Jan 2014 18:02:18 +0100 (CET) From: Mikael Abrahamsson To: "softwires@ietf.org" In-Reply-To: <1808340F7EC362469DDFFB112B37E2FCDA3249DB99@SRVHKE02.rdm.cz> Message-ID: References: <1808340F7EC362469DDFFB112B37E2FCDA3249DB99@SRVHKE02.rdm.cz> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-137064504-147677215-1390928538=:11807" Subject: Re: [Softwires] Working group last call for draft-ietf-softwire-lw4over6-03 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 17:02:24 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---137064504-147677215-1390928538=:11807 Content-Type: TEXT/PLAIN; charset=iso-8859-2; format=flowed Content-Transfer-Encoding: 8BIT Support from me too, if the earlier proposed changes are implemented in a new version. On Tue, 28 Jan 2014, Vízdal Ale¹ wrote: > +1 to support advancing this document (with the respective comments incorporated) > > Ales > > From: Softwires [mailto:softwires-bounces@ietf.org] On Behalf Of Hermin Anggawijaya > Sent: Tuesday, January 28, 2014 10:59 AM > To: Suresh Krishnan > Cc: softwires@ietf.org; Yong Cui > Subject: Re: [Softwires] Working group last call for draft-ietf-softwire-lw4over6-03 > > > I support for advancing the draft. > H. Anggawijaya > > > On 2014-1-14, at ??12:46, Suresh Krishnan wrote: > >> Hi all, >> This message starts a two week softwire working group last call on >> advancing the draft about Lightweight 4over6 as a Standards Track RFC. >> The authors believe that this version has addressed all the issues >> raised on the document till now. The latest version of the draft is >> available at >> >> http://www.ietf.org/id/draft-ietf-softwire-lw4over6-03.txt >> http://tools.ietf.org/html/draft-ietf-softwire-lw4over6-03 >> >> Substantive comments and statements of support/opposition for advancing >> this document should be directed to the mailing list. Editorial >> suggestions can be sent directly to the authors. This last call will >> conclude on January 28, 2014. >> >> Regards, >> Suresh & Yong >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires > -- Mikael Abrahamsson email: swmike@swm.pp.se ---137064504-147677215-1390928538=:11807-- From bingxuere@gmail.com Tue Jan 28 15:20:28 2014 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44C861A029E; Tue, 28 Jan 2014 15:20:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.452 X-Spam-Level: X-Spam-Status: No, score=0.452 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6e8KEWZ1tE9I; Tue, 28 Jan 2014 15:20:25 -0800 (PST) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 932521A028B; Tue, 28 Jan 2014 15:20:25 -0800 (PST) Received: by mail-pa0-f45.google.com with SMTP id lf10so988138pab.18 for ; Tue, 28 Jan 2014 15:20:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=GlwfEveRPwELHyVGHu6W/Mr+5N5yNb4IfgsP8/X+/0g=; b=JH801PF9OZGFHTjgXj0JNNbCHmgnWMNZLtjZYmAHVbfcnMNerkAoNpV2Vp0vzDU8fj yilUYS/pD6ulF1nEmLgLcbBogEg4fNecNOLKZeY9bJjvzgc0I97BZ1MyesrHrzXq1bO7 ask6QlZ6wPtReEY2RpkybrMEs6GdrNv/opui+UPF/GAMi80K6pz21O4kTboaKakP5UDa U8Z+to+ZFBGy/Sg0f0TijY3y0FN+1bpt8IEEJEAKOzJ+mTfzg8CGRVTGYYlOV/LAqwEN VlY8naJmJsAlZPGHUlhWVyD0QlXa0ibTI+Zb8ISsv13UqfS0mpSLVKrb6gYbUh/2EeuC ztng== X-Received: by 10.67.3.97 with SMTP id bv1mr4450914pad.54.1390951223084; Tue, 28 Jan 2014 15:20:23 -0800 (PST) Received: from [10.28.75.168] ([114.242.248.121]) by mx.google.com with ESMTPSA id bz4sm488017pbb.12.2014.01.28.15.20.18 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 28 Jan 2014 15:20:22 -0800 (PST) References: Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-ED7AA5AD-E1B6-412C-8183-15B21CA3C3DF Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPad Mail (10A8500) From: "bingxuere@gmail.com" Date: Wed, 29 Jan 2014 07:20:14 +0800 To: Branimir Rajtar Cc: Softwires WG , Yong Cui , Softwires Subject: Re: [Softwires] Working group last call for draft-ietf-softwire-lw4over6-03 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 23:20:28 -0000 --Apple-Mail-ED7AA5AD-E1B6-412C-8183-15B21CA3C3DF Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Hi all, Support to move forward.=20 Best wishes Qiong =D4=DA 2014-1-28=A3=AC17:04=A3=ACBranimir Rajtar =D0=B4=B5=C0=A3=BA > +1 for support >=20 > Branimir >=20 >=20 > On Tue, Jan 28, 2014 at 9:47 AM, wrote: >>=20 >> Support +1=20 >>=20 >> BRs=A3=AC=20 >> Wei=20 >>=20 >>=20 >> "Softwires" 2014-01-14 12:46:16: >>=20 >>=20 >> > Hi all, >> > This message starts a two week softwire working group last call on=20= >> > advancing the draft about Lightweight 4over6 as a Standards Track RFC.=20= >> > The authors believe that this version has addressed all the issues=20 >> > raised on the document till now. The latest version of the draft is=20 >> > available at >> >=20 >> > http://www.ietf.org/id/draft-ietf-softwire-lw4over6-03.txt >> > http://tools.ietf.org/html/draft-ietf-softwire-lw4over6-03 >> >=20 >> > Substantive comments and statements of support/opposition for advancing= =20 >> > this document should be directed to the mailing list. Editorial=20 >> > suggestions can be sent directly to the authors. This last call will=20= >> > conclude on January 28, 2014. >> >=20 >> > Regards, >> > Suresh & Yong >> > _______________________________________________ >> > 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 >>=20 >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires --Apple-Mail-ED7AA5AD-E1B6-412C-8183-15B21CA3C3DF Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi all,

Suppo= rt to move forward. 

Best wishes
Qio= ng


=E5=9C=A8 2014-1-28=EF=BC=8C17:04=EF=BC=8CBranimir R= ajtar <branimir.rajtar.= ietf@gmail.com> =E5=86=99=E9=81=93=EF=BC=9A

+1 for support

Branimi= r


O= n Tue, Jan 28, 2014 at 9:47 AM, <meng.wei2@zte.com.cn> wro= te:

Support +1

BRs=EF=BC=8C
Wei


"Softwires" <softwires-bounces@ietf.org>  2014-01-14 12:46:16:


> Hi all,
>    This message starts a two week softwire working group last call on
> advancing the draft about Lightweight 4over6 as a Standards Track RFC.
> The authors believe that this version has addressed all the issues
> raised on the document till now. The latest version of the draft is
> available at
>
> http://www.ietf.org/id/draft-ietf-softwire-lw4over6-03.txt<= /a>
> http://tools.ietf.org/html/draft-ietf-softwire-lw4over6-03<= /a>
>
> Substantive comments and statements of support/opposition for advancing=
> this document should be directed to the mailing list. Editorial
> suggestions can be sent directly to the authors. This last call will
> conclude on January 28, 2014.
>
> Regards,
> Suresh & Yong
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.= org
> https://www.ietf.org/mailman/listinfo/softwires
_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires


____________________= ___________________________
Softwires mailing listSoftwires@ietf.orghttps://= www.ietf.org/mailman/listinfo/softwires
= --Apple-Mail-ED7AA5AD-E1B6-412C-8183-15B21CA3C3DF-- From xiechf01@gmail.com Tue Jan 28 22:09:21 2014 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A6F81A0371; Tue, 28 Jan 2014 22:09:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.449 X-Spam-Level: X-Spam-Status: No, score=-0.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zEdoSzb--bjd; Tue, 28 Jan 2014 22:09:20 -0800 (PST) Received: from mail-pd0-x22c.google.com (mail-pd0-x22c.google.com [IPv6:2607:f8b0:400e:c02::22c]) by ietfa.amsl.com (Postfix) with ESMTP id D9BA11A036D; Tue, 28 Jan 2014 22:09:19 -0800 (PST) Received: by mail-pd0-f172.google.com with SMTP id p10so1289110pdj.17 for ; Tue, 28 Jan 2014 22:09:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:subject:message-id:importance:from:to:cc:mime-version :content-type; bh=/LpldbfDJI4iFlCYckVhcvSYrbyzNlEXvCYFHig5daQ=; b=Tgf+GoTieUKdd+WsUJbXbSC7NIxFMR5b1Bg9yeLBZDt7ay4kb1m7Fq79910msB48Gh CfGlHDwetyBxSfVHmBlmcECcaNEc8yQbcwaH5MZFhidTlbIZaPULDPjVgT0e8++3bjaE RBVxSEBwGG4UUoQbSET8BGdyfNiDDo7Q+UeyZFy9J2Tlxo3nO7EirMPE0uee6aX5qUdU V8IJ2fJTh4rHBXvQWH6lXkz50mYA0iX58JaoVB9ARn4UhfcfEgo+SUQ4hzMZaxVHnDRC EpCLNPaNSu4iZCpvqMXfIMh+r9xSCCAFJ+pOUL9zOXl+dtJUupSvUTIZlQtXHZYXZB1N 2qwQ== X-Received: by 10.66.159.233 with SMTP id xf9mr6004535pab.139.1390975757261; Tue, 28 Jan 2014 22:09:17 -0800 (PST) Received: from [117.37.233.142] ([117.37.233.142]) by mx.google.com with ESMTPSA id qq5sm3118413pbb.24.2014.01.28.22.09.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 28 Jan 2014 22:09:16 -0800 (PST) Date: Wed, 29 Jan 2014 12:19:20 +0800 Message-ID: <69jai6bjoqx1lyr90eeb8ok8.1390969160518@email.android.com> Importance: normal From: xiechf01 To: "bingxuere@gmail.com" , Branimir Rajtar MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.android.email_594681040858660" Cc: Softwires WG , Softwires , Yong Cui Subject: [Softwires] =?utf-8?b?5Zue5aSN77yaIFJlOiAgV29ya2luZyBncm91cCBs?= =?utf-8?q?ast_call_for=09draft-ietf-softwire-lw4over6-03?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 06:09:21 -0000 ----_com.android.email_594681040858660 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 U3VwcG9ydCAsICsxCgpDaG9uZ2ZlbmfCoAoKCuS7juS4ieaYn+enu+WKqOiuvuWkh+WPkemAgQoK LS0tLS0tLS0g5Y6f5aeL6YKu5Lu2IC0tLS0tLS0tCuWPkeS7tuS6uu+8miBiaW5neHVlcmVAZ21h aWwuY29tIArml6XmnJ86MjAxNC0wMS0yOSAgMDc6MjAgIChHTVQrMDg6MDApIArmlLbku7bkurrv vJogQnJhbmltaXIgUmFqdGFyIDxicmFuaW1pci5yYWp0YXIuaWV0ZkBnbWFpbC5jb20+IArmioTp gIHvvJogU29mdHdpcmVzIFdHIDxzb2Z0d2lyZXNAaWV0Zi5vcmc+LFlvbmcgQ3VpIDxjdWl5b25n QHRzaW5naHVhLmVkdS5jbj4sU29mdHdpcmVzIDxzb2Z0d2lyZXMtYm91bmNlc0BpZXRmLm9yZz4g CuS4u+mimO+8miBSZTogW1NvZnR3aXJlc10gV29ya2luZyBncm91cCBsYXN0IGNhbGwgZm9yCWRy YWZ0LWlldGYtc29mdHdpcmUtbHc0b3ZlcjYtMDMgCgpIaSBhbGwsCgpTdXBwb3J0IHRvIG1vdmUg Zm9yd2FyZC7CoAoKQmVzdCB3aXNoZXMKUWlvbmcKCgrlnKggMjAxNC0xLTI477yMMTc6MDTvvIxC cmFuaW1pciBSYWp0YXIgPGJyYW5pbWlyLnJhanRhci5pZXRmQGdtYWlsLmNvbT4g5YaZ6YGT77ya CgorMSBmb3Igc3VwcG9ydAoKQnJhbmltaXIKCgpPbiBUdWUsIEphbiAyOCwgMjAxNCBhdCA5OjQ3 IEFNLCA8bWVuZy53ZWkyQHp0ZS5jb20uY24+IHdyb3RlOgoKU3VwcG9ydCArMSAKCkJSc++8jCAK V2VpIAoKCiJTb2Z0d2lyZXMiIDxzb2Z0d2lyZXMtYm91bmNlc0BpZXRmLm9yZz4gwqAyMDE0LTAx LTE0IDEyOjQ2OjE2OgoKCj4gSGkgYWxsLAo+IMKgIMKgVGhpcyBtZXNzYWdlIHN0YXJ0cyBhIHR3 byB3ZWVrIHNvZnR3aXJlIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIG9uIAo+IGFkdmFuY2luZyB0 aGUgZHJhZnQgYWJvdXQgTGlnaHR3ZWlnaHQgNG92ZXI2IGFzIGEgU3RhbmRhcmRzIFRyYWNrIFJG Qy4gCj4gVGhlIGF1dGhvcnMgYmVsaWV2ZSB0aGF0IHRoaXMgdmVyc2lvbiBoYXMgYWRkcmVzc2Vk IGFsbCB0aGUgaXNzdWVzIAo+IHJhaXNlZCBvbiB0aGUgZG9jdW1lbnQgdGlsbCBub3cuIFRoZSBs YXRlc3QgdmVyc2lvbiBvZiB0aGUgZHJhZnQgaXMgCj4gYXZhaWxhYmxlIGF0Cj4gCj4gaHR0cDov L3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1pZXRmLXNvZnR3aXJlLWx3NG92ZXI2LTAzLnR4dAo+IGh0 dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtc29mdHdpcmUtbHc0b3ZlcjYtMDMK PiAKPiBTdWJzdGFudGl2ZSBjb21tZW50cyBhbmQgc3RhdGVtZW50cyBvZiBzdXBwb3J0L29wcG9z aXRpb24gZm9yIGFkdmFuY2luZyAKPiB0aGlzIGRvY3VtZW50IHNob3VsZCBiZSBkaXJlY3RlZCB0 byB0aGUgbWFpbGluZyBsaXN0LiBFZGl0b3JpYWwgCj4gc3VnZ2VzdGlvbnMgY2FuIGJlIHNlbnQg ZGlyZWN0bHkgdG8gdGhlIGF1dGhvcnMuIFRoaXMgbGFzdCBjYWxsIHdpbGwgCj4gY29uY2x1ZGUg b24gSmFudWFyeSAyOCwgMjAxNC4KPiAKPiBSZWdhcmRzLAo+IFN1cmVzaCAmIFlvbmcKPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+IFNvZnR3aXJlcyBt YWlsaW5nIGxpc3QKPiBTb2Z0d2lyZXNAaWV0Zi5vcmcKPiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3NvZnR3aXJlcwoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18KU29mdHdpcmVzIG1haWxpbmcgbGlzdApTb2Z0d2lyZXNAaWV0Zi5v cmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zb2Z0d2lyZXMKCgpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpTb2Z0d2lyZXMgbWFp bGluZyBsaXN0ClNvZnR3aXJlc0BpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3NvZnR3aXJlcwo= ----_com.android.email_594681040858660 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keSA+PGRpdj5TdXBwb3J0ICwgKzE8L2Rp dj48ZGl2Pjxicj48L2Rpdj48ZGl2PkNob25nZmVuZyZuYnNwOzwvZGl2PjxkaXY+PGJyPjwvZGl2 PjxkaXY+PGJyPjwvZGl2PjxkaXY+PGRpdiBzdHlsZT0iZm9udC1zaXplOjc1JTtjb2xvcjojNTc1 NzU3Ij7ku47kuInmmJ/np7vliqjorr7lpIflj5HpgIE8L2Rpdj48L2Rpdj48YnI+PGJyPi0tLS0t LS0tIOWOn+Wni+mCruS7tiAtLS0tLS0tLTxicj7lj5Hku7bkurrvvJogYmluZ3h1ZXJlQGdtYWls LmNvbSA8YnI+5pel5pyfOjIwMTQtMDEtMjkgIDA3OjIwICAoR01UKzA4OjAwKSA8YnI+5pS25Lu2 5Lq677yaIEJyYW5pbWlyIFJhanRhciA8YnJhbmltaXIucmFqdGFyLmlldGZAZ21haWwuY29tPiA8 YnI+5oqE6YCB77yaIFNvZnR3aXJlcyBXRyA8c29mdHdpcmVzQGlldGYub3JnPixZb25nIEN1aSA8 Y3VpeW9uZ0B0c2luZ2h1YS5lZHUuY24+LFNvZnR3aXJlcyA8c29mdHdpcmVzLWJvdW5jZXNAaWV0 Zi5vcmc+IDxicj7kuLvpopjvvJogUmU6IFtTb2Z0d2lyZXNdIFdvcmtpbmcgZ3JvdXAgbGFzdCBj YWxsIGZvcglkcmFmdC1pZXRmLXNvZnR3aXJlLWx3NG92ZXI2LTAzIDxicj48YnI+PGRpdj5IaSBh bGwsPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5TdXBwb3J0IHRvIG1vdmUgZm9yd2FyZC4mbmJz cDs8L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PkJlc3Qgd2lzaGVzPC9kaXY+PGRpdj5RaW9uZzxi cj48YnI+PC9kaXY+PGRpdj48YnI+5ZyoIDIwMTQtMS0yOO+8jDE3OjA077yMQnJhbmltaXIgUmFq dGFyICZsdDs8YSBocmVmPSJtYWlsdG86YnJhbmltaXIucmFqdGFyLmlldGZAZ21haWwuY29tIj5i cmFuaW1pci5yYWp0YXIuaWV0ZkBnbWFpbC5jb208L2E+Jmd0OyDlhpnpgZPvvJo8YnI+PGJyPjwv ZGl2PjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxkaXY+PGRpdiBkaXI9Imx0ciI+KzEgZm9yIHN1 cHBvcnQ8ZGl2Pjxicj48L2Rpdj48ZGl2PkJyYW5pbWlyPC9kaXY+PC9kaXY+PGRpdiBjbGFzcz0i Z21haWxfZXh0cmEiPjxicj48YnI+PGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPk9uIFR1ZSwgSmFu IDI4LCAyMDE0IGF0IDk6NDcgQU0sICA8c3BhbiBkaXI9Imx0ciI+Jmx0OzxhIGhyZWY9Im1haWx0 bzptZW5nLndlaTJAenRlLmNvbS5jbiIgdGFyZ2V0PSJfYmxhbmsiPm1lbmcud2VpMkB6dGUuY29t LmNuPC9hPiZndDs8L3NwYW4+IHdyb3RlOjxicj4KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1 b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7 cGFkZGluZy1sZWZ0OjFleCI+Cjxicj48Zm9udCBmYWNlPSJzYW5zLXNlcmlmIj5TdXBwb3J0ICsx PC9mb250Pgo8YnI+Cjxicj48Zm9udCBmYWNlPSJzYW5zLXNlcmlmIj5CUnPvvIw8L2ZvbnQ+Cjxi cj48Zm9udCBmYWNlPSJzYW5zLXNlcmlmIj5XZWk8L2ZvbnQ+Cjxicj4KPGJyPgo8YnI+PHR0Pjxm b250PiJTb2Z0d2lyZXMiICZsdDs8YSBocmVmPSJtYWlsdG86c29mdHdpcmVzLWJvdW5jZXNAaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zb2Z0d2lyZXMtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7 CiZuYnNwOzIwMTQtMDEtMTQgMTI6NDY6MTY6PGRpdiBjbGFzcz0iaW0iPjxicj4KPGJyPgomZ3Q7 IEhpIGFsbCw8YnI+CiZndDsgJm5ic3A7ICZuYnNwO1RoaXMgbWVzc2FnZSBzdGFydHMgYSB0d28g d2VlayBzb2Z0d2lyZSB3b3JraW5nIGdyb3VwCmxhc3QgY2FsbCBvbiA8YnI+CiZndDsgYWR2YW5j aW5nIHRoZSBkcmFmdCBhYm91dCBMaWdodHdlaWdodCA0b3ZlcjYgYXMgYSBTdGFuZGFyZHMgVHJh Y2sKUkZDLiA8YnI+CiZndDsgVGhlIGF1dGhvcnMgYmVsaWV2ZSB0aGF0IHRoaXMgdmVyc2lvbiBo YXMgYWRkcmVzc2VkIGFsbCB0aGUgaXNzdWVzCjxicj4KJmd0OyByYWlzZWQgb24gdGhlIGRvY3Vt ZW50IHRpbGwgbm93LiBUaGUgbGF0ZXN0IHZlcnNpb24gb2YgdGhlIGRyYWZ0IGlzCjxicj4KJmd0 OyBhdmFpbGFibGUgYXQ8YnI+CiZndDsgPGJyPgomZ3Q7IDxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0 Zi5vcmcvaWQvZHJhZnQtaWV0Zi1zb2Z0d2lyZS1sdzRvdmVyNi0wMy50eHQiIHRhcmdldD0iX2Js YW5rIj5odHRwOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LWlldGYtc29mdHdpcmUtbHc0b3ZlcjYt MDMudHh0PC9hPjxicj4KJmd0OyA8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1pZXRmLXNvZnR3aXJlLWx3NG92ZXI2LTAzIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1zb2Z0d2lyZS1sdzRvdmVyNi0wMzwvYT48YnI+ CiZndDsgPGJyPgomZ3Q7IFN1YnN0YW50aXZlIGNvbW1lbnRzIGFuZCBzdGF0ZW1lbnRzIG9mIHN1 cHBvcnQvb3Bwb3NpdGlvbiBmb3IgYWR2YW5jaW5nCjxicj4KJmd0OyB0aGlzIGRvY3VtZW50IHNo b3VsZCBiZSBkaXJlY3RlZCB0byB0aGUgbWFpbGluZyBsaXN0LiBFZGl0b3JpYWwgPGJyPgomZ3Q7 IHN1Z2dlc3Rpb25zIGNhbiBiZSBzZW50IGRpcmVjdGx5IHRvIHRoZSBhdXRob3JzLiBUaGlzIGxh c3QgY2FsbCB3aWxsCjxicj4KJmd0OyBjb25jbHVkZSBvbiBKYW51YXJ5IDI4LCAyMDE0Ljxicj4K Jmd0OyA8YnI+CiZndDsgUmVnYXJkcyw8YnI+CiZndDsgU3VyZXNoICZhbXA7IFlvbmc8YnI+CiZn dDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+CiZn dDsgU29mdHdpcmVzIG1haWxpbmcgbGlzdDxicj4KJmd0OyA8YSBocmVmPSJtYWlsdG86U29mdHdp cmVzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+U29mdHdpcmVzQGlldGYub3JnPC9hPjxicj4K Jmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NvZnR3 aXJlcyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vc29mdHdpcmVzPC9hPjxicj4KPC9kaXY+PC9mb250PjwvdHQ+Cjxicj5fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4KU29mdHdpcmVzIG1haWxpbmcg bGlzdDxicj4KPGEgaHJlZj0ibWFpbHRvOlNvZnR3aXJlc0BpZXRmLm9yZyI+U29mdHdpcmVzQGll dGYub3JnPC9hPjxicj4KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9zb2Z0d2lyZXMiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3NvZnR3aXJlczwvYT48YnI+Cjxicj48L2Jsb2NrcXVvdGU+PC9kaXY+PGJy PjwvZGl2Pgo8L2Rpdj48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGRpdj48 c3Bhbj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzwvc3Bh bj48YnI+PHNwYW4+U29mdHdpcmVzIG1haWxpbmcgbGlzdDwvc3Bhbj48YnI+PHNwYW4+PGEgaHJl Zj0ibWFpbHRvOlNvZnR3aXJlc0BpZXRmLm9yZyI+U29mdHdpcmVzQGlldGYub3JnPC9hPjwvc3Bh bj48YnI+PHNwYW4+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9zb2Z0d2lyZXMiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc29mdHdp cmVzPC9hPjwvc3Bhbj48YnI+PC9kaXY+PC9ibG9ja3F1b3RlPjwvYm9keT4= ----_com.android.email_594681040858660-- From liushucheng@huawei.com Tue Jan 28 22:41:35 2014 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BE951A0371; Tue, 28 Jan 2014 22:41:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.435 X-Spam-Level: X-Spam-Status: No, score=-4.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NWH2WXw7Xomx; Tue, 28 Jan 2014 22:41:33 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 230841A0418; Tue, 28 Jan 2014 22:41:31 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BDA83959; Wed, 29 Jan 2014 06:41:28 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 29 Jan 2014 06:40:50 +0000 Received: from SZXEMA403-HUB.china.huawei.com (10.82.72.35) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 29 Jan 2014 06:41:22 +0000 Received: from SZXEMA509-MBS.china.huawei.com ([169.254.2.102]) by SZXEMA403-HUB.china.huawei.com ([10.82.72.35]) with mapi id 14.03.0158.001; Wed, 29 Jan 2014 14:41:15 +0800 From: "Liushucheng (Will)" To: xiechf01 , "bingxuere@gmail.com" , Branimir Rajtar Thread-Topic: =?utf-8?B?W1NvZnR3aXJlc10g5Zue5aSN77yaIFJlOiAgV29ya2luZyBncm91cCBsYXN0?= =?utf-8?Q?_call_for=09draft-ietf-softwire-lw4over6-03?= Thread-Index: AQHPHLiqMTbREa6YCkOff/gX3wzmT5qbQKWA Date: Wed, 29 Jan 2014 06:41:14 +0000 Message-ID: References: <69jai6bjoqx1lyr90eeb8ok8.1390969160518@email.android.com> In-Reply-To: <69jai6bjoqx1lyr90eeb8ok8.1390969160518@email.android.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.78.79] Content-Type: multipart/alternative; boundary="_000_C9B5F12337F6F841B35C404CF0554ACB5FE6B69DSZXEMA509MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Softwires WG , Softwires , Yong Cui Subject: Re: [Softwires] =?utf-8?b?5Zue5aSN77yaIFJlOiAgV29ya2luZyBncm91cCBs?= =?utf-8?q?ast_call_for=09draft-ietf-softwire-lw4over6-03?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 06:41:35 -0000 --_000_C9B5F12337F6F841B35C404CF0554ACB5FE6B69DSZXEMA509MBSchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U3VwcG9ydCArMQ0KDQpDaGVlcnMsDQpTaHVjaGVuZyAoV2lsbCkNCg0KRnJvbTogU29mdHdpcmVz IFttYWlsdG86c29mdHdpcmVzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiB4aWVjaGYw MQ0KU2VudDogV2VkbmVzZGF5LCBKYW51YXJ5IDI5LCAyMDE0IDEyOjE5IFBNDQpUbzogYmluZ3h1 ZXJlQGdtYWlsLmNvbTsgQnJhbmltaXIgUmFqdGFyDQpDYzogU29mdHdpcmVzIFdHOyBTb2Z0d2ly ZXM7IFlvbmcgQ3VpDQpTdWJqZWN0OiBbU29mdHdpcmVzXSDlm57lpI3vvJogUmU6IFdvcmtpbmcg Z3JvdXAgbGFzdCBjYWxsIGZvciBkcmFmdC1pZXRmLXNvZnR3aXJlLWx3NG92ZXI2LTAzDQoNClN1 cHBvcnQgLCArMQ0KDQpDaG9uZ2ZlbmcNCg0KDQrku47kuInmmJ/np7vliqjorr7lpIflj5HpgIEN Cg0KDQotLS0tLS0tLSDljp/lp4vpgq7ku7YgLS0tLS0tLS0NCuWPkeS7tuS6uu+8miBiaW5neHVl cmVAZ21haWwuY29tPG1haWx0bzpiaW5neHVlcmVAZ21haWwuY29tPg0K5pel5pyfOjIwMTQtMDEt MjkgMDc6MjAgKEdNVCswODowMCkNCuaUtuS7tuS6uu+8miBCcmFuaW1pciBSYWp0YXINCuaKhOmA ge+8miBTb2Z0d2lyZXMgV0cgLFlvbmcgQ3VpICxTb2Z0d2lyZXMNCuS4u+mimO+8miBSZTogW1Nv ZnR3aXJlc10gV29ya2luZyBncm91cCBsYXN0IGNhbGwgZm9yIGRyYWZ0LWlldGYtc29mdHdpcmUt bHc0b3ZlcjYtMDMNCkhpIGFsbCwNCg0KU3VwcG9ydCB0byBtb3ZlIGZvcndhcmQuDQoNCkJlc3Qg d2lzaGVzDQpRaW9uZw0KDQrlnKggMjAxNC0xLTI477yMMTc6MDTvvIxCcmFuaW1pciBSYWp0YXIg PGJyYW5pbWlyLnJhanRhci5pZXRmQGdtYWlsLmNvbTxtYWlsdG86YnJhbmltaXIucmFqdGFyLmll dGZAZ21haWwuY29tPj4g5YaZ6YGT77yaDQorMSBmb3Igc3VwcG9ydA0KDQpCcmFuaW1pcg0KDQpP biBUdWUsIEphbiAyOCwgMjAxNCBhdCA5OjQ3IEFNLCA8bWVuZy53ZWkyQHp0ZS5jb20uY248bWFp bHRvOm1lbmcud2VpMkB6dGUuY29tLmNuPj4gd3JvdGU6DQoNClN1cHBvcnQgKzENCg0KQlJz77yM DQpXZWkNCg0KDQoiU29mdHdpcmVzIiA8c29mdHdpcmVzLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRv OnNvZnR3aXJlcy1ib3VuY2VzQGlldGYub3JnPj4gIDIwMTQtMDEtMTQgMTI6NDY6MTY6DQoNCg0K PiBIaSBhbGwsDQo+ICAgIFRoaXMgbWVzc2FnZSBzdGFydHMgYSB0d28gd2VlayBzb2Z0d2lyZSB3 b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBvbg0KPiBhZHZhbmNpbmcgdGhlIGRyYWZ0IGFib3V0IExp Z2h0d2VpZ2h0IDRvdmVyNiBhcyBhIFN0YW5kYXJkcyBUcmFjayBSRkMuDQo+IFRoZSBhdXRob3Jz IGJlbGlldmUgdGhhdCB0aGlzIHZlcnNpb24gaGFzIGFkZHJlc3NlZCBhbGwgdGhlIGlzc3Vlcw0K PiByYWlzZWQgb24gdGhlIGRvY3VtZW50IHRpbGwgbm93LiBUaGUgbGF0ZXN0IHZlcnNpb24gb2Yg dGhlIGRyYWZ0IGlzDQo+IGF2YWlsYWJsZSBhdA0KPg0KPiBodHRwOi8vd3d3LmlldGYub3JnL2lk L2RyYWZ0LWlldGYtc29mdHdpcmUtbHc0b3ZlcjYtMDMudHh0DQo+IGh0dHA6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWlldGYtc29mdHdpcmUtbHc0b3ZlcjYtMDMNCj4NCj4gU3Vic3RhbnRp dmUgY29tbWVudHMgYW5kIHN0YXRlbWVudHMgb2Ygc3VwcG9ydC9vcHBvc2l0aW9uIGZvciBhZHZh bmNpbmcNCj4gdGhpcyBkb2N1bWVudCBzaG91bGQgYmUgZGlyZWN0ZWQgdG8gdGhlIG1haWxpbmcg bGlzdC4gRWRpdG9yaWFsDQo+IHN1Z2dlc3Rpb25zIGNhbiBiZSBzZW50IGRpcmVjdGx5IHRvIHRo ZSBhdXRob3JzLiBUaGlzIGxhc3QgY2FsbCB3aWxsDQo+IGNvbmNsdWRlIG9uIEphbnVhcnkgMjgs IDIwMTQuDQo+DQo+IFJlZ2FyZHMsDQo+IFN1cmVzaCAmIFlvbmcNCj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gU29mdHdpcmVzIG1haWxpbmcgbGlz dA0KPiBTb2Z0d2lyZXNAaWV0Zi5vcmc8bWFpbHRvOlNvZnR3aXJlc0BpZXRmLm9yZz4NCj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zb2Z0d2lyZXMNCg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClNvZnR3aXJlcyBtYWlsaW5n IGxpc3QNClNvZnR3aXJlc0BpZXRmLm9yZzxtYWlsdG86U29mdHdpcmVzQGlldGYub3JnPg0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zb2Z0d2lyZXMNCg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClNvZnR3aXJlcyBtYWlsaW5n IGxpc3QNClNvZnR3aXJlc0BpZXRmLm9yZzxtYWlsdG86U29mdHdpcmVzQGlldGYub3JnPg0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zb2Z0d2lyZXMNCg== --_000_C9B5F12337F6F841B35C404CF0554ACB5FE6B69DSZXEMA509MBSchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJc QOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQp0dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJZm9udC1mYW1pbHk65a6L5L2TO30NCnNw YW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hw RGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0 O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46 NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpX b3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRp Zl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0 Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0Pjwv eG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iWkgtQ04iIGxpbms9ImJsdWUi IHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+U3VwcG9ydCAmIzQzOzE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hbGlnbjpqdXN0aWZ5O3RleHQtanVzdGlmeTppbnRlci1p ZGVvZ3JhcGgiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+Q2hlZXJzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJ0ZXh0LWFsaWduOmp1c3RpZnk7dGV4dC1qdXN0aWZ5OmludGVyLWlkZW9ncmFw aCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5TaHVjaGVuZyAoV2lsbCk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNt IDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk ICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206 PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBTb2Z0 d2lyZXMgW21haWx0bzpzb2Z0d2lyZXMtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBP ZiA8L2I+eGllY2hmMDE8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBKYW51YXJ5IDI5LCAy MDE0IDEyOjE5IFBNPGJyPg0KPGI+VG86PC9iPiBiaW5neHVlcmVAZ21haWwuY29tOyBCcmFuaW1p ciBSYWp0YXI8YnI+DQo8Yj5DYzo8L2I+IFNvZnR3aXJlcyBXRzsgU29mdHdpcmVzOyBZb25nIEN1 aTxicj4NCjxiPlN1YmplY3Q6PC9iPiBbU29mdHdpcmVzXSA8L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQiPuWbnuWkje+8mjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPiBSZTogV29ya2luZyBncm91cCBsYXN0IGNhbGwgZm9yIGRyYWZ0LWll dGYtc29mdHdpcmUtbHc0b3ZlcjYtMDM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+U3VwcG9ydCAsICYjNDM7MTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+Q2hvbmdmZW5nJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo5LjBwdDtjb2xvcjojNTc1NzU3Ij7ku47kuInmmJ/np7vliqjorr7lpIflj5HpgIE8 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQi PjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQo8YnI+DQotLS0tLS0tLSA8L3NwYW4+5Y6f5aeL6YKu 5Lu2PHNwYW4gbGFuZz0iRU4tVVMiPiAtLS0tLS0tLTxicj4NCjwvc3Bhbj7lj5Hku7bkurrvvJog PHNwYW4gbGFuZz0iRU4tVVMiPjxhIGhyZWY9Im1haWx0bzpiaW5neHVlcmVAZ21haWwuY29tIj5i aW5neHVlcmVAZ21haWwuY29tPC9hPg0KPGJyPg0KPC9zcGFuPuaXpeacnzxzcGFuIGxhbmc9IkVO LVVTIj46MjAxNC0wMS0yOSAwNzoyMCAoR01UJiM0MzswODowMCkgPGJyPg0KPC9zcGFuPuaUtuS7 tuS6uu+8mjxzcGFuIGxhbmc9IkVOLVVTIj4gQnJhbmltaXIgUmFqdGFyIDxicj4NCjwvc3Bhbj7m ioTpgIHvvJo8c3BhbiBsYW5nPSJFTi1VUyI+IFNvZnR3aXJlcyBXRyAsWW9uZyBDdWkgLFNvZnR3 aXJlcyA8YnI+DQo8L3NwYW4+5Li76aKY77yaPHNwYW4gbGFuZz0iRU4tVVMiPiBSZTogW1NvZnR3 aXJlc10gV29ya2luZyBncm91cCBsYXN0IGNhbGwgZm9yIGRyYWZ0LWlldGYtc29mdHdpcmUtbHc0 b3ZlcjYtMDMNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+SGkgYWxsLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+U3VwcG9ydCB0byBtb3ZlIGZvcndhcmQuJm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5CZXN0IHdpc2hl czxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPlFpb25n PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0K PC9zcGFuPuWcqDxzcGFuIGxhbmc9IkVOLVVTIj4gMjAxNC0xLTI4PC9zcGFuPu+8jDxzcGFuIGxh bmc9IkVOLVVTIj4xNzowNDwvc3Bhbj7vvIw8c3BhbiBsYW5nPSJFTi1VUyI+QnJhbmltaXIgUmFq dGFyICZsdDs8YSBocmVmPSJtYWlsdG86YnJhbmltaXIucmFqdGFyLmlldGZAZ21haWwuY29tIj5i cmFuaW1pci5yYWp0YXIuaWV0ZkBnbWFpbC5jb208L2E+Jmd0Ow0KPC9zcGFuPuWGmemBk++8mjxz cGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+JiM0MzsxIGZv ciBzdXBwb3J0PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+QnJhbmlt aXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+T24gVHVlLCBKYW4gMjgsIDIwMTQgYXQgOTo0NyBBTSwg Jmx0OzxhIGhyZWY9Im1haWx0bzptZW5nLndlaTJAenRlLmNvbS5jbiIgdGFyZ2V0PSJfYmxhbmsi Pm1lbmcud2VpMkB6dGUuY29tLmNuPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxicj4NCjwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPlN1cHBvcnQgJiM0MzsxPC9zcGFuPjxzcGFuIGxhbmc9IkVO LVVTIj4NCjxicj4NCjxicj4NCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkJSczwvc3Bh bj7vvIw8c3BhbiBsYW5nPSJFTi1VUyI+DQo8YnI+DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5XZWk8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPg0KPGJyPg0KPGJyPg0KPGJyPg0KPHR0 PiZxdW90O1NvZnR3aXJlcyZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNvZnR3aXJlcy1ib3Vu Y2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c29mdHdpcmVzLWJvdW5jZXNAaWV0Zi5vcmc8 L2E+Jmd0OyAmbmJzcDsyMDE0LTAxLTE0IDEyOjQ2OjE2OjxvOnA+PC9vOnA+PC90dD48L3NwYW4+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+ DQo8YnI+DQomZ3Q7IEhpIGFsbCw8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDtUaGlzIG1lc3NhZ2Ug c3RhcnRzIGEgdHdvIHdlZWsgc29mdHdpcmUgd29ya2luZyBncm91cCBsYXN0IGNhbGwgb24gPGJy Pg0KJmd0OyBhZHZhbmNpbmcgdGhlIGRyYWZ0IGFib3V0IExpZ2h0d2VpZ2h0IDRvdmVyNiBhcyBh IFN0YW5kYXJkcyBUcmFjayBSRkMuIDxicj4NCiZndDsgVGhlIGF1dGhvcnMgYmVsaWV2ZSB0aGF0 IHRoaXMgdmVyc2lvbiBoYXMgYWRkcmVzc2VkIGFsbCB0aGUgaXNzdWVzIDxicj4NCiZndDsgcmFp c2VkIG9uIHRoZSBkb2N1bWVudCB0aWxsIG5vdy4gVGhlIGxhdGVzdCB2ZXJzaW9uIG9mIHRoZSBk cmFmdCBpcyA8YnI+DQomZ3Q7IGF2YWlsYWJsZSBhdDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YSBo cmVmPSJodHRwOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LWlldGYtc29mdHdpcmUtbHc0b3ZlcjYt MDMudHh0IiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LWll dGYtc29mdHdpcmUtbHc0b3ZlcjYtMDMudHh0PC9hPjxicj4NCiZndDsgPGEgaHJlZj0iaHR0cDov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1zb2Z0d2lyZS1sdzRvdmVyNi0wMyIgdGFy Z2V0PSJfYmxhbmsiPg0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1zb2Z0 d2lyZS1sdzRvdmVyNi0wMzwvYT48YnI+DQomZ3Q7IDxicj4NCiZndDsgU3Vic3RhbnRpdmUgY29t bWVudHMgYW5kIHN0YXRlbWVudHMgb2Ygc3VwcG9ydC9vcHBvc2l0aW9uIGZvciBhZHZhbmNpbmcg PGJyPg0KJmd0OyB0aGlzIGRvY3VtZW50IHNob3VsZCBiZSBkaXJlY3RlZCB0byB0aGUgbWFpbGlu ZyBsaXN0LiBFZGl0b3JpYWwgPGJyPg0KJmd0OyBzdWdnZXN0aW9ucyBjYW4gYmUgc2VudCBkaXJl Y3RseSB0byB0aGUgYXV0aG9ycy4gVGhpcyBsYXN0IGNhbGwgd2lsbCA8YnI+DQomZ3Q7IGNvbmNs dWRlIG9uIEphbnVhcnkgMjgsIDIwMTQuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFJlZ2FyZHMsPGJy Pg0KJmd0OyBTdXJlc2ggJmFtcDsgWW9uZzxicj4NCiZndDsgX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7IFNvZnR3aXJlcyBtYWlsaW5nIGxp c3Q8YnI+DQomZ3Q7IDxhIGhyZWY9Im1haWx0bzpTb2Z0d2lyZXNAaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj5Tb2Z0d2lyZXNAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyA8YSBocmVmPSJodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NvZnR3aXJlcyIgdGFyZ2V0PSJfYmxhbmsi Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc29mdHdpcmVzPC9hPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpTb2Z0d2lyZXMgbWFpbGlu ZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOlNvZnR3aXJlc0BpZXRmLm9yZyI+U29mdHdpcmVz QGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vc29mdHdpcmVzIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9zb2Z0d2lyZXM8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NClNvZnR3aXJlcyBtYWlsaW5nIGxp c3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86U29mdHdpcmVzQGlldGYub3JnIj5Tb2Z0d2lyZXNAaWV0 Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9zb2Z0d2lyZXMiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc29m dHdpcmVzPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_C9B5F12337F6F841B35C404CF0554ACB5FE6B69DSZXEMA509MBSchi_--