--------------------------------------------------- IETF83 - Softwire session I - Wednesday 1510 - 1610 --------------------------------------------------- Chairs: Alain Durand, Yong Cui Minute takers: Ole Troan Jabber scribe: N/A 1 Chair slides Welcome notes, agenda bashing (Motivations for Stateless IPv4 over IPv6 Migration Solutions) (Deployment Considerations for Dual-Stack Lite) Document status: Chair discussing IPR issues in other language on softwire-gateway-init-ds-lite. Ralph, Alain, Wouter discussion. Alain: For the record there is no opposition in the WG to keep progressing the document regardless of the language in the patent. Dapeng Liu: Comment on the stateless motivation being confusing, being stateless or stateful. Boucadair: Been followed upon on the mailing list. There is no confusion on the use of state. And there was no clarification needed. Consider it as a comment for the WGLC. *Discussion ensues* Yong: Please write to the mailing list on further comments. Boucadair: I propose to ensue WGLC. And consider the comment during WGLC. Yong: Discuss stateless/stateful terminology on mailing list. Boucadair: On dslite-multicast. The document has advanced to IESG. multicast-prefix-option: Ready for WG adoption. No comments. Francis: Shows new innovative power extension socket design to scribe for recording in minutes. ;-) 2 Peng Wu - Public IPv4 over IPv6 Access Network http://datatracker.ietf.org/doc/draft-ietf-softwire-public-4over6/ Chairs: Comments? Peng: Is it OK to do WGLC? Chairs: So there are no objections? OK 3 Peng Wu / Ian Farrer - Lightweight 4over6: An Extension to DS-Lite Architecture http://datatracker.ietf.org/doc/draft-cui-softwire-b4-translated-ds-lite/ Francis: *stopped by chairs* Jan Zorz: This looks suspiciously like stateful A+P. Did you read it? We went through the same ideas and dumped it as useless at the end. Ian: What was the conclusion? Jan: In the end we ended up on DHCP. I'm convinced that stateless solutions is the way to go. I wrote the signaling part of the A+P RFC. Went through hell. And randomization of ports. Because of this we needed state. You are reinventing the wheel. Francis: I share your concern on ICMP. For PCP, it means you need to put the PCP server on the CGN. I prefer something like DHCPv6. It doesn't work if the solution only applies for IPv4. For DS-lite you use it over IPv6. Bocudair: Agree with Francis. Alain: Please explain the details. Alain/Boucadair/Francis discussion on "ICMP port restricted message". icmp as a config tool. Francis: icmp filtered by firewall. Ole: making the point that this is just MAP with per subscriber rules/domains. Francis: This isn't in the scope of DS-lite. Supports also NAT444/CGN Wojciech Dec: The motivation for these solutions, coupled with IPv6 addressing. The tradeoff is that you are introducing per subscriber state. With the MAP solution you can do exactly the same. It doesn't make sense to make keep this as a separate effort. Alex Clauberg: It turns out to be complicated with MAP mapping. Woj: The tradeoff is per subscriber configuration on the AFTR. Alex: I need a solution soon. Woj: This can also be solved with MAP. Just do a rule/domain per subscriber. Mark: Where are we on the agenda? Ralph: Where does this fit on the agenda published? 4 Qiong Sun - Deployment Considerations for Lightweight 4over6 http://datatracker.ietf.org/doc/draft-sun-softwire-lightweigh-4over6-deployment/ No comments 5 Mark Townsley - Basic Requirements for Customer Edge Routers - multihoming and transition https://datatracker.ietf.org/doc/draft-townsley-troan-ipv6-ce-transitioning/ Chairs: We're over time. Mark: 2 more slides... Francis: Slide 4. I think IPv4 and IPv6 is not about the same thing. It is totally different. On IPv4 the address is private, for IPv6 it is public. *Discussion between Mark/Francis ensues.* Mark: The handling of policy is handled in the mechanism. Francis: If you have an IPv4 prefix the policy table is different. Mark: You've added one more level of complexity. Chris Donley: Give the user the best possible experience "metric". Mark: I'm talking about an IETF transitioning policy. Move to IPv6 and so on. Chris: Why is DS-lite preferred over native IPv4? Mark: The advice if you want to move to IPv6, then DS-lite is better than native IPv4. Jan Zorz: Can we call transition mechanisms to IPv6. And regression mechanisms for IPv4 exit mechanisms. ----------------------------------------------------- IETF83 - Softwire session II - 0900-1130 Fri. @ 252B ----------------------------------------------------- Chairs: Alain Durand, Yong Cui Note takers: Simon Perreault / Ole Troan 1. MAP?Design team report?- Ole Troan - Three documents - MAP (address and port mapping) - MAP-T (translation) - MAP-E (encapsulation) - MAP-D (deployment) - MAP-DHCP - Ole has a cool "tree" of similar technologies (divi, divi-pd, xlat464, public 4over6, lightweight 4over6, a+p, stateless ds-lite, sam, isatap, etc.) - Key point is MAP has two flavours: translation and encapsulation. Operators need to pick one. - Mapping algorithm embeds L4 port in address. - "Feature buffet" between MAP and 4rd-U. WG needs to choose. - Ready for WG adoption. - Actual number of documents is up for discussion. Remi Despres: - No universal agreement within MAP team that MAP is to be preferred over 4rd-U. - In the tree of similar technologies: - divi-pd was influenced by SAM. - 4rd was influenced by divi. - Table of feature comparison: - 4rd-U supports perfect transparency - 4rd-U supports well known ports - Configurable port range algorithm is not desirable - 4rd-U supports interoperability with BIH - 4rd-U does not need reassembly, which is good, while MAP needs reassembly. Zhen Cao: How do you support home-side web servers using MAP? Ole: Buy the service where you get full v4 address. Can only give port 80 to one person. Zhen Cao: What we did in CERNET is virtual hosting so everybody can have their own host. -------- 2. MAP-T, Xing Li http://datatracker.ietf.org/doc/draft-mdt-softwire-map-translation/ - MAP-E uses RFC2473 for data forwarding. - MAP-T uses RFC6145 for data forwarding. - Same address format for basic and forwarding mapping rules. - MAP-T is stateless double translation. - Compatible with single translation. Remi Despres: RFC6145 allows a choice: do you recompute the UDP checksum? Xing Li: This will work. Remi Despres: RFC6145 allows to recompute or not. What do you choose? Xing: We recompute. Remi Despres: There are performance issues. Rajiv Asati: Performance is specific to implementation. Xing Li continuing: - MAP-T supports mesh - MAP-T keeps end-to-end transparency except corner cases - fragmentation - DF=1 & MF=1 - ICMP/ICMPv6 (In production we don't see any traffic in these corner cases.) - MAP-T uses existing operations and management tools. - Running code. Remi Despres: Assuming you have deployed MAP-T, why do you need MAP-E? Xing Li: IPv4 options, 100% transparency. We believe the data path processing is different and if the ISP is conservative then MAP-E may be the choice. With configuration function you need both requirements. Remi Despres: (didn't understand) Remi Despres: You have 2 years experience but we know there is one piece of design that is missing from -T which is that same fragmentation ID from two CEs with shared address will conflict. Xing Li: (didn't understand) Judy:?Do we have to obsolete RFC6180 which prohibits double translation? Xing: Li There are new understandings of the problem. 3. MAP-E - Tetsuya Murakami http://datatracker.ietf.org/doc/draft-mdt-softwire-map-encapsulation/ - Transparent IPv4 tunneling. - Default mapping rule is a little different, containing simply the address of the BR. - MAP-E allows mesh communication (like MAP-T). - Implementation on Linux uses tunnel interfaces, very similar to what exists now. - MAP-E enables existing operational techniques. - Only difference with MAP-T: - DMR - Data path - Next step: working group adoption Remi Despres: About packet reassembly in the BR, is it required that v4 packets are reassembled? Tetsuya Murakami: Reassembly is required. I don't think there are big benefits from forwarding fragments without reassembly. Tetsuya: Maybe memory usage might be a difference. Remi Despres: If one has deployed MAP-E, why do you need MAP-T? Why two standards? Tetsuya: Transparency is good. Remi Despres: Why do you need a second standard that doesn't have transparency? Tetsuya: If you need full transparency, MAP-E can be applicable. Jan Zorz: I want to clarify Remi 's question. Why do you need two standards? I see this as a very polarized world. We need a solution that people can choose when implementing: turn on encapsulation or translation. Rajiv Asati: Next steps? Chairs: we'll discuss Hui Deng: (didn't understand?(working group consensus)) 3. 4rd-U - Remi Despres http://datatracker.ietf.org/doc/draft-despres-softwire-4rd-u/ - Authors include MAP team members and come from operators, vendors, etc. - Scope common with MAP - Only difference: ISPs don't need to choose between T/E. - It's possible to have a header format that covers all the needs. - This was rejected by the MAP team. - Main feature is IPv4 full transparency (except IPv4 options) - like MAP-E - Second feature: IPv6-only compatibility - like MAP-T - With 4rd-U there is a single document. - v4-in-v6 allows reversible mapping between v4 and v6 headers. - Key point is that in the fragment header there is a 32-bit identifier, while in v4 it's 16 bits, so we have 16 bits free. - Extensive technical discussion with Maoke. - New feature: TTL preservation - We call this "reversible header mapping". Nothing is done with the payload. - Features of U that are not in T nor E: - No constraint on subnet id in customer sites - ...(skipped)... - Features of MAP-T/E not in 4rd-U: - MAP-T supports communication between v4-only and v6-only hosts - BIH deal with this problem, so it's not needed. - 4rd-U is easily implementable. - We lose nothing compared with MAP-E. - We lose nothing compared with MAP-T, and it improves transparency. - Spec is self-contained, complete, ready to use. - One standard is better than two. - Running code will come very soon. - 4rd-U is the ultimate synthesis of MAP-T/E and A+P. - Vendors care about a clear stable standard. Jan Zorz: Agree, we need one solution to be published or set of solutions to be published as soon as possible. We needed this two years ago in order to keep CGN away. Wojciech?Dec: There was not much interest in the MAP design team. There is a certain polarization in the solution space. It's admirable that you're trying to unify this but this looks like IPv6.1. We could do IPv8 to solve all problems. We just need to make a call. MAP solves problems that people want to be solved. Do you have running code for this? Remi Despres: No, it will be very soon. People who co-sign this spec say this is easily implementable. Wojciech: Lots of people can write code. Can you run this in single-translation mode? Remi Despres: I asked many times on the list, it would be debatable. This use case is covered by another RFC. Wojciech: This solution needs to be combined with something else to solve single-translation. Remi Despres: Yes, an existing RFC. Zhen Cao: I like this proposal, especially the fact that ISPs don't need to choose when deploying encryption. Xing Li: This proposal modifies IPv6 address architecture. We need proof from 6man. We need to see if this kind of modification is not harmful. Some packets look like IPv6 packets but they are not really. Firewalls will be confused. Remi Despres: Reference to the V-octet? Xing: If DF=1, no fragmentation header. Your proposal is trying to address a corner case. For the corner case you are changing all packets. Satoru Matsushima:?Do you plan to propose 4rd-u packet format to DS-Lite stuff? Remi Despres: The answer is no. 4. DISCUSS Gang Chen: Having just one solution is important for operators. MAP-T/E is two different solutions. We can't ask vendors to implement both in the same box. Jan Zorz: Can a vendor say if we can deploy E+T in a single product? Xing Li: It can be done, it's very easy. Only difference is data path. Also it's very interesting because if it's encapsulation you can see the next header. This allows you to determine. Mark Townsley: Both our BRs and CPEs will be able to do both. Complexity lies in "when do you use T vs E?" This is relegated to SP configuration. Remi Despres: It's not a real problem for implementers. The central issue is for operators that have to decide. Ole Troan: Operators have to decide between many more than just two choices. 4rd-U provides better translation than RFC6145. If we go with 4rd-U, we have better translation. The MAP design team has found the T and E communities are polarized. It's a pipe dream. We have to do both. Hui Deng: If I move my CPE to another place I cannot use that. It?s bad for the internet. Alain Durand: Vendors adopt "wait and see" attitude. In any case we can do some testing. We will be able to support anything. Wojciech Dec: 4rd-U does not address the same set of problems because it needs to be combined with BIH to address single-translation problem. Remi Despres: One solution for v4-v6 (BIH) and one solution for v4-v4 (4rd-U). Wijciech Dec: In all cases you will need to run BIH with 4rd-U. Rajiv Asati: It's impossible that we will have 100% consensus on one solution. We need to respect the output of the design team. Alain Durand: A design team is just a group of people. We are not forced to respect their output. Rajiv Asati: We need to start into implementation and testing/deploying. Sheng Jiang: We need a single standard. (didn't understand) Remi Despres: This is not a key part of 4rd-U. Alain Durand (as chair): I want to ask questions to the working group. a) MAP is a package. 4rd-U is another package. Do we agree that we cannot have both? b) Which one do you want? Please only vote once. (laughs) (One will become working group item, the other can go as informational.) outcome of a): 40 hands for, 7 hands against outcome of b): 18 hands for 4rd-U, 30 hands for MAP Ralph Droms: Show of hands to know if we have consensus on consensus. (laughs) Calling this consensus is a stretch. This is closer to "no decision". Go to mailing list for additional input on the vote. We can't call this consensus. Alain: We'll go to the mailing list. If there's no consensus on the mailing list we'll talk again next time. Jordi Palet: Going to informational for the second one is not a good idea. Remi Despres: I support. If we make a choice, we make a choice. Jan Zorz: This is taking way too long. Ralph Droms: If we need to decide today, people need to change their mind. Alain: We don't have consensus. It would be better if we had consensus. Think again for 2 minutes then vote again. Rajiv Asati: 30 vs 18 should be rough consensus. Congxiao Bao: (didn't understand) Joel Halpern: Counting the room was a mistake. We don't have consensus. It's not going to change in the next 10 minutes. It needs to be determined on the list. A similar case went with both as experimental. The count is irrelevant. Ralph Droms: We could accept that there's no consensus and do nothing. Or accept and go forward and publish both as experimental. Remi Despres: Two experimentals seems a good way out today. One could become standard if it is preferred by the market. Wojciech Dec: MAP is ready to deploy, it's mature. 4rd-U is experimental. If during the publishing process consensus changes, we change one to standard track. Alain: We could adopt both without choosing document status outcome now. Jan Zorz: How is this helping vendors choose what to implement? Alain: As a vendor I would like to see a clear outcome today. I would like to have rough consensus. Second round of voting (we do vote at the IETF it seems): MAP: 25 hands 4rd-U: 13 hands Ralph Droms: I still would not judge this as rough consensus. Take this to the mailing list. Wojciech Dec: What is expected time-wise? Ralph: As quickly as possible. Well before the next meeting. Alain: One week mailing list discussion. 6 Xiaohong Deng Multicast Extensions to DS-Lite Technique in Broadband Deployments http://datatracker.ietf.org/doc/draft-ietf-softwire-dslite-multicast/ *Not enough time* 7 Xiaohong Deng DHCPv6 Options for IPv6 DS-Lite Multicast Prefix http://datatracker.ietf.org/doc/draft-qin-softwire-multicast-prefix-option/ *Not enough time* 8 Tom Taylor IPv6 Multicast Using Native IPv4 Capabilities in a 6rd Deployment http://datatracker.ietf.org/doc/draft-tsou-softwire-6rd-multicast/ *Not enough time* 9 Behcet Sarikaya Multicast Support for 6rd http://datatracker.ietf.org/doc/draft-sarikaya-softwire-6rdmulticast/ *Not enough time* 10 Peng Wu Softwire Mesh Management Information Base (MIB) http://datatracker.ietf.org/doc/draft-cui-softwire-mesh-mib/ - MIB for RFC5565 - Builds on IP Tunnel MIB [RFC4087] and BGP MIB [RFC4273] Yong Cui: We'll confirm adoption on the mailing list. 11 Shishio Tsuchiya Definitions of Managed Objects for 6rd http://datatracker.ietf.org/doc/draft-cai-softwire-6rd-mib/ - MIB for 6rd. - IP-MIB, IP-FORWARD-MIB, and TUNNEL-MIB apply to 6rd. - Define new values and semantics for some tunnel mib OIDs. - Two possible approaches: - A separate 6rd mib - Extended tunnelIfXTable Sheng Jiang: Which approach did you pick? It's terrible to say you have two approaches. Pick one. I don't care. That's not mature enough for adoption. Come back next time with one approach. Shishio Tsuchia: We want to ask the WG members. Peng Wu: The first approach is infeasible. Sheng Jiang: Obsoleting IP tunnel MIB is impossible. Yong Cui: Update your draft, discuss on the list. 12 Sheng Jiang DS-lite mib http://datatracker.ietf.org/doc/draft-fu-softwire-dslite-mib/ - Two drafts: unicast ds-lite mib, multicast ds-lite mib - This is ready for WG adoption. Peng Wu: We should leverage the tunnel MIB. 13 Tina TSOU BFD Support DS-Lite http://datatracker.ietf.org/doc/draft-tsou-softwire-bfd-ds-lite/ *Not enough time*