http://blog.gmane.org/gmane.ietf.softwires hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.ietf.softwires/4771 <pre>I read the latest draft. I think this is good.:-) The mapTunnel Subtree which information of CE statics was removed. -------- Original Message -------- Subject: I-D Action: draft-fu-softwire-map-mib-05.txt Date: Tue, 14 May 2013 02:28:23 -0700 From: &lt;internet-drafts-EgrivxUAwEY&lt; at &gt;public.gmane.org&gt; Reply-To: &lt;internet-drafts-EgrivxUAwEY&lt; at &gt;public.gmane.org&gt; To: &lt;i-d-announce-EgrivxUAwEY&lt; at &gt;public.gmane.org&gt; A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Definitions of Managed Objects for MAP-E Author(s) : Yu Fu Sheng Jiang Bing Liu Jiang Dong Peng Wu Filename : draft-fu-softwire-map-mib-05.txt Pages : 13 Date : 2013-05-14 Abstract: This memo defines a portion of the Management Information Base (MIB) for using with network management protocols in the Internet community. In particular, it defines managed objects for MAP encapsulation mode. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-fu-softwire-map-mib There's also a htmlized version available at: http://tools.ietf.org/html/draft-fu-softwire-map-mib-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-fu-softwire-map-mib-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce-EgrivxUAwEY&lt; at &gt;public.gmane.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt . </pre> Shishio Tsuchiya 2013-05-17T08:59:48 http://permalink.gmane.org/gmane.ietf.softwires/4770 <pre>I update 6rd MIB. Add sixRdSecurityCheck object. http://tools.ietf.org/html/draft-cai-softwire-6rd-mib-05#section-4.3 The MIB counts drop packets by 6rd receiving rule. http://tools.ietf.org/html/rfc5969#section-9.2 Regards, -Shishio -------- Original Message -------- Subject: I-D Action: draft-cai-softwire-6rd-mib-05.txt Date: Thu, 16 May 2013 08:51:43 -0700 From: &lt;internet-drafts-EgrivxUAwEY&lt; at &gt;public.gmane.org&gt; Reply-To: &lt;internet-drafts-EgrivxUAwEY&lt; at &gt;public.gmane.org&gt; To: &lt;i-d-announce-EgrivxUAwEY&lt; at &gt;public.gmane.org&gt; A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Definitions of Managed Objects for 6rd Author(s) : Lei Cai Jacni Qin Shishio Tsuchiya Filename : draft-cai-softwire-6rd-mib-05.txt Pages : 10 Date : 2013-05-16 Abstract: This document defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular, it defines objects for managing 6rd devices. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-cai-softwire-6rd-mib There's also a htmlized version available at: http://tools.ietf.org/html/draft-cai-softwire-6rd-mib-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-cai-softwire-6rd-mib-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce-EgrivxUAwEY&lt; at &gt;public.gmane.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt . </pre> Shishio Tsuchiya 2013-05-17T08:46:27 http://permalink.gmane.org/gmane.ietf.softwires/4769 <pre>I have a number of trivial editorial comments, which I will share privately with the authors. However, I also have a few points for broader review. Section 4.1, Figure 3 ===================== The introductory text to this figure reads: "Figure 3 illustrate a typical case, where the home network have multiple connections to multiple providers or multiple logical connections to the same provider." It seems to me that Figure 2 illustrates this case but Figure 3 does not. Was this a mistake in labelling? Is Figure 3 even necessary given that the point is made with Figure 2? Section 4.2 first paragraph =========================== In the middle of the paragraph there is the statement: "All CEs in the MAP domain are provisioned with the same set of MAP rules by MAP DHCPv6 server [I-D.ietf-softwire-map-dhcp]." Wouldn't that be true only in mesh mode? In Hub-and-spoke mode, each CE needs just its own BMR and the address of the BR. It seems to me there should be a statement somewhere (probably in the MAP document, but also here) that the only difference between a BMR and an FMR is the point of view. Every FMR is also a BMR for the destination CE. Then the difference between hub-and-spoke and mesh is a matter of whether CEs outside of a given sub-domain get provisioned with the BMR shared by the members of that sub-domain. Section 4.2.2 last sentence =========================== The sentence reads: "But all CEs within the same MAP sub- domain would have the same Rule IPv4 prefix, Rule IPv6 prefix and PSID parameters." The PSID value will be unique to a specific CE within a given sub-domain. Using the phrase: "PSID parameters" suggests it will not. Perhaps you should replace PSID parameters by "number of Embedded Address (EA) bits". Section 4.2.3.3 last paragraph ============================== The paragraph in question reads: "There is also a suggestion that an implementation may allow the CE sends packet with destination address and port pointing to itself. The hairpinning supported by the BR for the Hub/Spokes mode delivers the packet back to the sender CE itself. Through this the probe on the connection between CE and BR is enabled." This paragraph is talking about CE and BR capabilities rather than operator planning. I think it belongs in the MAP document rather than here. I note that the topic comes back in point 4 of Section 4.3. Section 4.2.4 ============= Again the first sentence says that all the CEs in the same MAP domain get the same set of MAP rules. Please see the comments for Section 4.2. Further along in the first paragraph there is a reference to rule port parameters. These are no longer mentioned in the MAP document. However, Section 5.1 of that document has the following: "a-bits The number of offset bits. The default Offset bits (a) are 6, this excludes the system ports (0-1023)." The use of the term "default" suggests that the value of 'a' is provisionable. I recently generated results showing that, depending on the intended number of ports per user, it is possible that a lower value of 'a' would give a higher sharing ratio even though more than 1024 ports are excluded as a result. This is due to the effects of rounding. Bottom line: it may be that the value of 'a' should be made explicitly provisionable, and it may be that my results would be useful in the deployment document. I can send them along if the authors are interested. Section 4.2.5 ============= The offset is discussed here, so my remarks on the value of 'a' in the previous section also apply. Note that this section currently says the default is 4 rather than 6. The statement that PSID cannot be zero is incorrect unless 'a' is set to zero (port set consists of a single contiguous range). The correct statement is that the initial part of the port number (the a-bits) cannot be zero. There should be a reference to Appendix B of the MAP document when discussing this. Section 5.1 step B1 =================== The example uses working addresses. It should use addresses from the documentation ranges in the IANA IPv4 Special Purpose Address Registry: 192.0.2.0/24, 198.51.100.0/24, and/or 203.0.113.0/24. Section 5.1 step B2 =================== Do I misunderstand, or was the 3-bit PSID length chosen arbitrarily as part of the example? Actually, I would expect the sharing ratio (or more likely the number of ports per subscriber) to be the starting point, so you might say instead (following the first sentence): "Suppose the intended sharing ratio is 8 subscribers per address, resulting in (65536 - 1024)/8 = 8064 ports per subscriber assuming that the well-known ports are excluded. Then the PSID length to achieve this will be log2(8) = 3 bits. Bearing in mind the IPv4 16 bit prefix length for each of our two prefixes, the EA-bit length is (32 - 16) + 3 = 19 bits." Section 5.1 step B3 =================== I found this step rather mysterious until I got to step C3. Presumably the purpose is to generate a unique IPv6 prefix per MAP rule. I suggest you start by stating that as a requirement. Instead of the term "index", which to me suggests consecutive values, how about "prefix extension"? A couple of minor points: -- in the second paragraph, s/contiguous block/contiguous address block/ I have ports on the brain from recent work. Others may also be confused. -- Is there a more usual notation for a binary value x, instead of bin(x)? I'll read the rest of the document, so there may be more comments, but this is a start. Tom Taylor </pre> Tom Taylor 2013-05-15T18:11:07 http://permalink.gmane.org/gmane.ietf.softwires/4768 <pre>Hi, Remi, Thanks for your email and contribution. As I have confirmed privately, I agree with your comment and have recorded your suggested modification for next update. They will be addressed with other comments we received. Best regards, Sheng _______________________________________________ Softwires mailing list Softwires&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/softwires </pre> Sheng Jiang 2013-05-15T09:21:00 http://permalink.gmane.org/gmane.ietf.softwires/4767 <pre>Ian, would think so. many functions in MAP are based on the BMR/FMR those cannot be removed from the specification. the mapping rules imply what needs to be provisioned, but it doesn't force a particular layout. perhaps we should circle back and look at the provisioning options again, and see if that will resolve this. if we end up with two provisioning options for the same thing, then there is no unification at that level. of course a MAP implementation might take something like an OPTION_MAP_BIND and "map" it into a BMR. btw, with LW46/OPTION_MAP_BIND, how would an AFTR know which IPv6 source address the B4 uses? cheers, Ole </pre> Ole Troan 2013-05-15T09:17:05 http://permalink.gmane.org/gmane.ietf.softwires/4766 <pre> On 13/05/2013 15:36, "Ole Troan" &lt;otroan-MColLcDMxcggsBAKwltoeQ&lt; at &gt;public.gmane.org&gt; wrote: [ian] It could be one way of doing it, but having just looked at what a 'composite' set of sub-options would look like for this, it's going to get pretty ugly. [ian] I agree, but the way that the draft is at the moment, there is a direct line between v4 provisioning with BMR/FMR, the parameters that BMRs/FMRs contain and then (in the MAP DHCP draft) the format and interpretation of the BMR/FMR. If you remove the BMR/FMR provisioning in Ex. 4 and also sec 5.2 para 3, then you've opened it up so that you don't force (or strongly imply) a particular layout of the provisioning information. </pre> ian.farrer-+tb+GG71Y8CELgA04lAiVw< at >public.gmane.org 2013-05-15T07:21:42 http://permalink.gmane.org/gmane.ietf.softwires/4765 <pre>Dear Sheng, This is to confirm on the WG list what I discussed with you concerning 4rd and NAT64+. 1. Adaptation of the 4rd draft to 6man precluding IID-range reservations, appears to have been incomplete: - Without a 4rd IID-range reservation, a NAT64+ can no longer distinguish 4rd-capable CEs from other hosts or CEs on the sole basis that their IPv6 addresses contain the 4rd tag. (A host behind a non-4rd CPE MAY be configured with such an address, e.g. by manual configuration ignoring the u/g bit meaning of RFC4291.) - The following sentence of R-11 is therefore no longer applicable: "The NAT64+, being NAT64 conforming [RFC6146], uses (b) as source addresses that depend on IPv4 sources. It finds in its binding information base addresses conforming to (a). Finding the 4rd tag in them, it uses 4rd tunneling rather than IPv4 to IPv6 translation." 2. The following is an example of how to restore full consistency of the specification: (1) Delete the above sentence. (2) Add a new R-xx saying: "Each NAT64+ MUST accept IPv6 packets whose destination addresses contain its NAT64+ prefix, necessarily a /64, followed by the 4rd tag. It MUST note, e.g. in its Binding Information Base, which IPv6/IPv4 bindings have been created with such 4rd destination addresses (as opposed to destination addresses containing the "u" octet of [RFC6052]). In the IPv4 to IPv6 direction, it MUST use IPv6 source addresses containing the 4rd tag, and conforming to of Figure 6 (b), for all bindings noted as created with 4rd destination addresses. 3. This contribution is intended to be limited to its technical substance, without view on how to best handle the issue at this point (before or after WGLC? With which precise text? ...). What will be decided in the WG should be fine AFAIAC. Thank you and best regards, RD </pre> Rémi Després 2013-05-14T14:03:55 http://permalink.gmane.org/gmane.ietf.softwires/4764 <pre>Ian, a BMR consists of 3 elements, a Rule IPv6 prefix, a Rule IPv4 prefix and the EA bits length. only the Rule IPv6 prefix isn't relevant for 1:1. if _that_ is a problem then each element could be suboptions in DHCP, but I'm not sure that's worth the complexity either. creating another corner case that an implementation must take into regard. a MAP node provisioned with no BMR and only OPTION_MAP_BIND could just map (sic) the information in the OPTION_MAP_BIND into a BMR. my argument is that this is a detail that can be taken care of in the MAP DHCP draft, and that MAP base can still make the assumption that all its functions are done based on the specified BMR/FMRs. there shouldn't be anything in MAP base that forces a particular layout of the provisioning information. yes, the MAP DHCP draft must be updated no matter what. cheers, Ole </pre> Ole Troan 2013-05-13T13:36:54 http://permalink.gmane.org/gmane.ietf.softwires/4763 <pre>Hi Ole, Comments in line. Cheers, Ian On 13/05/2013 12:21, "Ole Troan" &lt;otroan-MColLcDMxcggsBAKwltoeQ&lt; at &gt;public.gmane.org&gt; wrote: [ian] I recall:-) As I said, I'm OK with what it says and the ambiguity is not really a problem in it's own right. It'sl Ex 4 in the appendix where it states that you provision v4 using BMR/FMR. [ian] App. A ex 4 does state that the IPv4 config is taken from the BMR/FMR and 5.2/5.3 state the parameters for constructing BMRs/FMRs. Although it doesn't state how (as in the configuration method / protocol) this is configured, the parameters are stated, even though many of them are not required for 1:1. [ian] I think that the simplest way to make all this work is together is to separate out the BMR for mesh mode and the 1:1 mapping rule. As long as the BMR is described as the mechanism for provisioning 1:1 mode, then the additional configuration parameters of the BMR must also be conveyed (I.e. all of the things that are detailed in section 5.2), even though many of them are only relevant for mesh. So, the change in the MAP base draft would be: if EA=0, then the IPv4 configuration / port set is not provisioned within the BMR and is conveyed through another means (static, OPTION_MAP_BIND, DHCPv4 over DHCPv6 or whatever). This gives us the single method of configuring MAP 1:1/lw4o6. The MAP DHCP option draft then needs to be brought in line with this. </pre> ian.farrer-+tb+GG71Y8CELgA04lAiVw< at >public.gmane.org 2013-05-13T12:45:42 http://permalink.gmane.org/gmane.ietf.softwires/4762 <pre>Ian, there was a lot of pushback from describing 1:1 mode in more detail in the MAP base document. see section 7. EA=0 and a configured Rule IPv4 prefix of /32 results in 1:1/binding mode. _how_ that Rule IPv4 prefix is configured is out of scope of the base MAP document. my previous comment was to the provisioning document, where I think it would be ambiguous to have two options to do the same thing. do you have any proposed changes to MAP base, or is this for the provisioning document? cheers, Ole </pre> Ole Troan 2013-05-13T10:21:30 http://permalink.gmane.org/gmane.ietf.softwires/4761 <pre>Hi Ole, [ian] The description says what it doesn't do without saying what it does do. That's why I would say it's ambiguous. [ian] As I proposed in Orlando (second to last slide): http://www.ietf.org/proceedings/86/slides/slides-86-softwire-3.pdf No objections were raised to this. Cheers, Ian </pre> ian.farrer-+tb+GG71Y8CELgA04lAiVw< at >public.gmane.org 2013-05-13T09:56:38 http://permalink.gmane.org/gmane.ietf.softwires/4760 <pre>Ian, yes. that's is the meaning of EA=0. how so? the MAP BMR isn't only a 'provisioning construct' it is also used for forwarding. the MAP document doesn't say anything about how the BMR is provisioned. if you created a separate DHCP option for the corner case of EA=0, how should a Rule IPv4 prefix length of 32 with EA=0, be handled? seems like we then create more ambiguity... cheers, Ole </pre> Ole Troan 2013-05-13T09:18:36 http://permalink.gmane.org/gmane.ietf.softwires/4759 <pre>Hi Ole, Thanks for incorporating my comments into this version. Having re-read this version, there's one thing that I'd like to clarify: Is the BMR still being proposed as the method for configuring all IPv4 information, even with the EA=0 case? Section 5.2 states: A length of 0 means that no part of the IPv4 address or port is embedded in the address. Which is OK, if a little ambiguous. Then in example 4 in the Appendix, the BMR is provisioning the /32 IPv4 prefix for the client, i.e 1:! mode or 'Binding Mode' to use the Unified CPE terminology. I thought that we were going to use the OPTION_MAP_BIND proposed in softwire-unified-cpe to tell a lw4o6 CPE, or a MAP CPE to provision the Binding Mode. Cheers, Ian -----Original Message----- From: softwires-bounces-EgrivxUAwEY&lt; at &gt;public.gmane.org [mailto:softwires-bounces-EgrivxUAwEY&lt; at &gt;public.gmane.org] On Behalf Of Ole Troan Sent: Freitag, 10. Mai 2013 10:14 To: Suresh Krishnan Cc: Softwires WG; Yong Cui; Ralph Droms Subject: Re: [Softwires] Working group last call for draft-ietf-softwire-map-05 all, apologies for the delay in dealing with the WGLC comments. Tom has joined in on the editor team, and we have just posted a revision 06 that should address the comments received. see: http://tools.ietf.org/html/draft-ietf-softwire-map-06 http://www.ietf.org/rfcdiff?url2=draft-ietf-softwire-map-06 a summary of the WGLC below. ------------------------------------- WGLC: March 26 - April 9 Cameron Byrne: "Source Address / Port spoofing should be explicitly denied" Action: Clarified spoofing rules. s/SHOULD/MUST: &lt;t&gt;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&amp;rsquo;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.&lt;/t&gt; &lt;t&gt;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 packet destination address against the configured BR IPv6 address or FMR prefix(es). The selected MAP rule allows the BR to determine 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 number is found to be outside the range allowed for this CE and the BMR, the BR MUST drop the packet and respond with an ICMPv6 "Destination Unreachable, Source address failed ingress/egress policy" (Type 1, Code 5).&lt;/t&gt; &lt;t&gt;In order to prevent spoofing of IPv4 addresses, the MAP node MUST validate the embedded IPv4 source address of the encapsulated IPv6 packet with the IPv4 source address it is encapsulated by according to the parameters of the matching mapping rule. If the two source addresses do not match, the packet MUST be dropped and a counter incremented to indicate that a potential spoofing attack may be underway. Additionally, a CE MUST allow forwarding of packets sourced by the configured BR IPv6 address.&lt;/t&gt; &lt;t&gt;By default, the CE router MUST drop packets received on the MAP virtual interface (i.e., after decapsulation of IPv6) for IPv4 destinations not for its own IPv4 shared address, full IPv4 address or IPv4 prefix.&lt;/t&gt; Nejc Škoberne &lt;nejc-3KDCldthLPzk1uMJSBkQmQ&lt; at &gt;public.gmane.org&gt; "Validity of the 5th example." Action: While example is correct, clarified example by being explicit about PSID being provisioned by DHCP. Changed PSID to another value than the examples using EA bits. "formula for calculating PSID (K) using a port P, ratio R, and M. It is very non-obvious" Action: None. Tom Taylor &lt;tom.taylor.stds-Re5JQEeQqe8AvxtiuMwx3w&lt; at &gt;public.gmane.org&gt; In Section 5.2 of -map-05, there is the paragraph: "The MAP subnet ID is defined to be the first subnet (all bits set to zero). Unless configured differently, a MAP node MUST reserve the first IPv6 prefix in an End-user IPv6 prefix for the purpose of MAP." Action: Rewritten to: "The MAP subnet identifier is defined to be the first subnet (all bits set to zero)." Section 5, bullet 1, Basic Mapping Rule: I wonder if you might make it clear that the relationship between the BMR and End-User MAP IPv6 Prefix is N:1, like this: "There can only be one Basic Mapping Rule per End-user IPv6 prefix (although multiple End-User IPv6 Prefixes may share the same Basic Mapping Rule, leading to provisioning efficiencies at the MAP BR)." Action, added: &lt;t&gt;Basic Mapping Rule (BMR) - mandatory. A CE can be provisioned with multiple End-user IPv6 prefixes. There can only be one Basic Mapping Rule per End-user IPv6 prefix. Although all CE's having End-user IPv6 prefixes within (aggregated by) the same Rule IPv6 prefix may share the same Basic Mapping Rule. In combination with the End-user IPv6 prefix, the Basic Mapping Rule is used to derive the IPv4 prefix, address, or shared address and the PSID assigned to the CE.&lt;/t&gt; Section 5.1, Port mapping algorithm: Relabel Figure 2 as follows: "Figure 2: Structure of a Port-Restricted Port Number" Action: Accepted. Put the definition of a before the definition of A. This makes the logic flow better. Definition of A: add before what is there now: "Selects which range the port number lies in." Definition of PSID: Add a third sentence: "This is guaranteed by the algorithm described here." Definition of k-bits: typo s/k^2/2^k/ Action: Accepted. Definition of M, replace present text with: "Selects the specific port within the particular range specified by the concatenation of A and the PSID." Action: Accepted. At the end, delete the duplicate sentence: "This algorithm ...contiguous ranges." Action: Done. Ian Farrer "I have one comment about the current version: It is using an IPv4 default route as the method for sending traffic out of the MAP domain. This is likely to cause provisioning complexity and conflicts with two other related drafts:" Action, rewrite section to: &lt;section anchor="outside-domain" title="Destinations outside the MAP domain"&gt; &lt;t&gt;IPv4 traffic between MAP nodes that are all within one MAP domain is encapsulated in IPv6, with the senders MAP IPv6 address as the IPv6 source address and the receiving MAP node's MAP IPv6 address as the IPv6 destination address. To reach IPv4 destinations outside of the MAP domain, traffic is also encapsulated in IPv6, but the destination IPv6 address is set to the configured IPv6 address of the MAP BR.&lt;/t&gt; &lt;t&gt;On the CE, the path to the BR can be represented as a point to point IPv4 over IPv6 tunnel &lt;xref target="RFC2473"/&gt; with the source address of the tunnel being the CE's MAP IPv6 address and the BR IPv6 address as the remote tunnel address. When MAP is enabled, a typical CE router will install a default route to the BR.&lt;/t&gt; &lt;t&gt;The BR forwards traffic received from the outside to CE's using the normal MAP forwarding rules.&lt;/t&gt; &lt;/section&gt; _______________________________________________ Softwires mailing list Softwires-EgrivxUAwEY&lt; at &gt;public.gmane.org https://www.ietf.org/mailman/listinfo/softwires </pre> ian.farrer-+tb+GG71Y8CELgA04lAiVw< at >public.gmane.org 2013-05-11T19:57:11 http://permalink.gmane.org/gmane.ietf.softwires/4757 <pre> Hi all, A new version of draft-ietf-softwire-public-4over6 is available now, addressing the results of first-round AD review. The authors would like to thank Ted and Suresh for their detailed, valuable comments and suggestions when reviewing the draft. The major changes from -08 version are: 1) Adjust the language to make it more suitable as an informational document 2) Reword some descriptions to make it more precise and explicit. Best Regards, ---------- Forwarded message ---------- From: &lt;internet-drafts-EgrivxUAwEY&lt; at &gt;public.gmane.org&gt; Date: Fri, May 10, 2013 at 11:04 AM Subject: New Version Notification for draft-ietf-softwire-public-4over6-09.txt To: Jianping Wu &lt;jianping-/fz2FxKtlwICalJqGWEchg&lt; at &gt;public.gmane.org&gt;, Peng Wu &lt;pengwu.thu-Re5JQEeQqe8AvxtiuMwx3w&lt; at &gt;public.gmane.org&gt;, Yong Cui &lt;yong-tZZ/WSnqlezU5ZeN3jqtGL6l2zLzw9E3/z7RTEddyNg&lt; at &gt;public.gmane.org&gt;, Olivier Vautrin &lt; olivier-3r7Miqu9kMnR7s880joybQ&lt; at &gt;public.gmane.org&gt;, "Yiu L. Lee" &lt;yiu_lee-aUJzA63xOnoL9wKPcNvCOAC/G2K4zDHf&lt; at &gt;public.gmane.org&gt;, Olivier Vautrin &lt;Olivier-3r7Miqu9kMnR7s880joybQ&lt; at &gt;public.gmane.org&gt; A new version of I-D, draft-ietf-softwire-public-4over6-09.txt has been successfully submitted by Yong Cui and posted to the IETF repository. Filename: draft-ietf-softwire-public-4over6 Revision: 09 Title: Public IPv4 over IPv6 Access Network Creation date: 2013-05-10 Group: softwire Number of pages: 13 URL: http://www.ietf.org/internet-drafts/draft-ietf-softwire-public-4over6-09.txt Status: http://datatracker.ietf.org/doc/draft-ietf-softwire-public-4over6 Htmlized: http://tools.ietf.org/html/draft-ietf-softwire-public-4over6-09 Diff: http://www.ietf.org/rfcdiff?url2=draft-ietf-softwire-public-4over6-09 Abstract: When the service provider networks are upgraded to IPv6, end users will continue to demand IPv4 connectivity. This document describes a mechanism for hosts or customer networks in IPv6 access network to build bidirectional IPv4 communication with the IPv4 Internet. The mechanism follows the hub and spokes softwire model, and uses IPv4- over-IPv6 tunnel as basic method to traverse IPv6 network. The bi- directionality of this IPv4 communication is achieved by explicitly allocating public IPv4 addresses to end users, as well as maintaining IPv4-IPv6 address binding on the border relay. This mechanism features the allocation of full IPv4 address over IPv6 network, and has been used in production for high-end IPv4 users, IPv6 transition of ICPs, etc. The IETF Secretariat </pre> Peng Wu 2013-05-10T08:37:44 http://permalink.gmane.org/gmane.ietf.softwires/4756 <pre> all, apologies for the delay in dealing with the WGLC comments. Tom has joined in on the editor team, and we have just posted a revision 06 that should address the comments received. see: http://tools.ietf.org/html/draft-ietf-softwire-map-06 http://www.ietf.org/rfcdiff?url2=draft-ietf-softwire-map-06 a summary of the WGLC below. ------------------------------------- WGLC: March 26 - April 9 Cameron Byrne: "Source Address / Port spoofing should be explicitly denied" Action: Clarified spoofing rules. s/SHOULD/MUST: &lt;t&gt;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&amp;rsquo;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.&lt;/t&gt; &lt;t&gt;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 packet destination address against the configured BR IPv6 address or FMR prefix(es). The selected MAP rule allows the BR to determine 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 number is found to be outside the range allowed for this CE and the BMR, the BR MUST drop the packet and respond with an ICMPv6 "Destination Unreachable, Source address failed ingress/egress policy" (Type 1, Code 5).&lt;/t&gt; &lt;t&gt;In order to prevent spoofing of IPv4 addresses, the MAP node MUST validate the embedded IPv4 source address of the encapsulated IPv6 packet with the IPv4 source address it is encapsulated by according to the parameters of the matching mapping rule. If the two source addresses do not match, the packet MUST be dropped and a counter incremented to indicate that a potential spoofing attack may be underway. Additionally, a CE MUST allow forwarding of packets sourced by the configured BR IPv6 address.&lt;/t&gt; &lt;t&gt;By default, the CE router MUST drop packets received on the MAP virtual interface (i.e., after decapsulation of IPv6) for IPv4 destinations not for its own IPv4 shared address, full IPv4 address or IPv4 prefix.&lt;/t&gt; Nejc Škoberne &lt;nejc-3KDCldthLPzk1uMJSBkQmQ&lt; at &gt;public.gmane.org&gt; "Validity of the 5th example." Action: While example is correct, clarified example by being explicit about PSID being provisioned by DHCP. Changed PSID to another value than the examples using EA bits. "formula for calculating PSID (K) using a port P, ratio R, and M. It is very non-obvious" Action: None. Tom Taylor &lt;tom.taylor.stds-Re5JQEeQqe8AvxtiuMwx3w&lt; at &gt;public.gmane.org&gt; In Section 5.2 of -map-05, there is the paragraph: "The MAP subnet ID is defined to be the first subnet (all bits set to zero). Unless configured differently, a MAP node MUST reserve the first IPv6 prefix in an End-user IPv6 prefix for the purpose of MAP." Action: Rewritten to: "The MAP subnet identifier is defined to be the first subnet (all bits set to zero)." Section 5, bullet 1, Basic Mapping Rule: I wonder if you might make it clear that the relationship between the BMR and End-User MAP IPv6 Prefix is N:1, like this: "There can only be one Basic Mapping Rule per End-user IPv6 prefix (although multiple End-User IPv6 Prefixes may share the same Basic Mapping Rule, leading to provisioning efficiencies at the MAP BR)." Action, added: &lt;t&gt;Basic Mapping Rule (BMR) - mandatory. A CE can be provisioned with multiple End-user IPv6 prefixes. There can only be one Basic Mapping Rule per End-user IPv6 prefix. Although all CE's having End-user IPv6 prefixes within (aggregated by) the same Rule IPv6 prefix may share the same Basic Mapping Rule. In combination with the End-user IPv6 prefix, the Basic Mapping Rule is used to derive the IPv4 prefix, address, or shared address and the PSID assigned to the CE.&lt;/t&gt; Section 5.1, Port mapping algorithm: Relabel Figure 2 as follows: "Figure 2: Structure of a Port-Restricted Port Number" Action: Accepted. Put the definition of a before the definition of A. This makes the logic flow better. Definition of A: add before what is there now: "Selects which range the port number lies in." Definition of PSID: Add a third sentence: "This is guaranteed by the algorithm described here." Definition of k-bits: typo s/k^2/2^k/ Action: Accepted. Definition of M, replace present text with: "Selects the specific port within the particular range specified by the concatenation of A and the PSID." Action: Accepted. At the end, delete the duplicate sentence: "This algorithm ...contiguous ranges." Action: Done. Ian Farrer "I have one comment about the current version: It is using an IPv4 default route as the method for sending traffic out of the MAP domain. This is likely to cause provisioning complexity and conflicts with two other related drafts:" Action, rewrite section to: &lt;section anchor="outside-domain" title="Destinations outside the MAP domain"&gt; &lt;t&gt;IPv4 traffic between MAP nodes that are all within one MAP domain is encapsulated in IPv6, with the senders MAP IPv6 address as the IPv6 source address and the receiving MAP node's MAP IPv6 address as the IPv6 destination address. To reach IPv4 destinations outside of the MAP domain, traffic is also encapsulated in IPv6, but the destination IPv6 address is set to the configured IPv6 address of the MAP BR.&lt;/t&gt; &lt;t&gt;On the CE, the path to the BR can be represented as a point to point IPv4 over IPv6 tunnel &lt;xref target="RFC2473"/&gt; with the source address of the tunnel being the CE's MAP IPv6 address and the BR IPv6 address as the remote tunnel address. When MAP is enabled, a typical CE router will install a default route to the BR.&lt;/t&gt; &lt;t&gt;The BR forwards traffic received from the outside to CE's using the normal MAP forwarding rules.&lt;/t&gt; &lt;/section&gt; </pre> Ole Troan 2013-05-10T08:14:08 http://permalink.gmane.org/gmane.ietf.softwires/4754 <pre> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Softwires Working Group of the IETF. Title : Public IPv4 over IPv6 Access Network Author(s) : Yong Cui Jianping Wu Peng Wu Olivier Vautrin Yiu L. Lee Filename : draft-ietf-softwire-public-4over6-09.txt Pages : 13 Date : 2013-05-09 Abstract: When the service provider networks are upgraded to IPv6, end users will continue to demand IPv4 connectivity. This document describes a mechanism for hosts or customer networks in IPv6 access network to build bidirectional IPv4 communication with the IPv4 Internet. The mechanism follows the hub and spokes softwire model, and uses IPv4- over-IPv6 tunnel as basic method to traverse IPv6 network. The bi- directionality of this IPv4 communication is achieved by explicitly allocating public IPv4 addresses to end users, as well as maintaining IPv4-IPv6 address binding on the border relay. This mechanism features the allocation of full IPv4 address over IPv6 network, and has been used in production for high-end IPv4 users, IPv6 transition of ICPs, etc. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-softwire-public-4over6 There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-softwire-public-4over6-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-softwire-public-4over6-09 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ </pre> internet-drafts-EgrivxUAwEY< at >public.gmane.org 2013-05-10T03:04:56 http://permalink.gmane.org/gmane.ietf.softwires/4753 <pre>Hi, Ian and All, Thanks for your mail. I believe the DMR should contain the prefix and prefix-length (the CIDR style), then the encapsulation mode MAP-E, lw4o6 and DS-lite will have /128; the translation mode MAP-T will have /64, the 464xlat will have /96. This is also fully compatible with RFC6052 with prefix lengths of /32, /40,/48, /56, /64 and /96. The MAP-DHCP specification is using this method and it works in our testing environment. Regards, xing ian.farrer&lt; at &gt;telekom.de 写道: _______________________________________________ Softwires mailing list Softwires&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/softwires </pre> Xing Li 2013-05-06T14:36:32 http://permalink.gmane.org/gmane.ietf.softwires/4752 <pre>Hi Ole, See inline. Cheers, Ian [ian] Checking 6334 section 5 - "If any DNS response contains more than one IPv6 address, the B4 system picks only one IPv6 address and uses it as a remote tunnel endpoint for the interface being configured in the current message exchange." So you could use Option 64/DNS to provision multiple endpoints. You'd need another mechanism (e.g. The bfd model) to detect failure and take advantage of it, though. [ian] You can. But then, why do you need the list of addresses suggested below? [ian] I think it's simpler just to use outside as a single approach. [ian] As long as this is done as a separate option to the DMR, then I think this would work. </pre> ian.farrer-+tb+GG71Y8CELgA04lAiVw< at >public.gmane.org 2013-05-03T15:23:32 http://permalink.gmane.org/gmane.ietf.softwires/4750 <pre>Hi Rajiv, Please see inline. Cheers, Ian On 26/04/2013 18:13, "Rajiv Asati (rajiva)" &lt;rajiva&lt; at &gt;cisco.com&gt; wrote: [ian] It would be great if some other operators would share! [ian] Certainly it works. My problem here is how we can align all of the different softwire approaches with the Unified CPE model of using the presence or absence of the options to define which sw mode to configure? MAP (E&amp;T) use the DMR + an 8 bit flags field. A single DMR sub-option, with the flag telling the CPE how to interpret it. What would be more in line with the unified CPE model (and in line with what's in http://tools.ietf.org/html/draft-ietf-dhc-option-guidelines-11#section-5.2) would be to break out the MAP-T DMR and the MAP-E/lw4o6 DMR into different sub-options and use their presence or absence to tell the CPE which softwire mode use, rather than the current flags field that only has a single option. I don’t really like this mixed approach of 'option presence' for some softwire modes and flags for others. I really think that we need to align on a single approach here (the one in the Unified CPE draft). _______________________________________________ Softwires mailing list Softwires&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/softwires </pre> ian.farrer-+tb+GG71Y8CELgA04lAiVw< at >public.gmane.org 2013-05-02T08:35:46 http://permalink.gmane.org/gmane.ietf.softwires/4749 <pre>Hi all, Thanks to everyone who volunteered to edit this document. We have chosen Simon Perreault and Senthil Sivakumar to be the editors of this document going forward. We would like to thank Med and Ian for putting the initial document together and getting several of the contentious issues resolved. We have requested them to stay on as co-authors. Regards Suresh &amp; Yong </pre> Suresh Krishnan 2013-05-02T04:18:55 http://permalink.gmane.org/gmane.ietf.softwires/4745 <pre> On Apr 26, 2013, at 5:22 PM, Simon Perreault wrote: MAP is checking the mapping between the IP overlay and underlay. No more, no less. It is not doing, and thus is not a replacement for, BCP38. BCP 38 should still be done, for IPv4 and IPv6, at appropriate locations, independently of MAP. Just be sure to identify that which is general best practice for any IPv6 or IPv4 network edge, and that which is MAP-specific. We don't want feature creep into MAP that which is generally applicable to any single or dual-stack network. - Mark </pre> Mark Townsley 2013-04-30T12:19:48 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.ietf.softwires