Softwire WG IETF 87 Tuesday, July 30, 2013 0900-1130 Morning Session Minute takers: QI Sun and Simon Perreault --- Administrative and WG document status Chairs DS-Lite multicast : Submit to IESG Multicast prefix option: Submit to IESG Mesh multicast: Issue WGLC very soon DS-Lite MIB: Wait for MIB doctor review before submit to IESG Mesh MIB: Wait for MIB doctor review before submit to IESG About MAP-E: Suresh: One of the big questions to answer is how do MAP relate to Unified-CPE It's probabaily the last pending issue to resolve. When this is done, we expect MAP go to IESG About 6rd MIB: Volunteers to read: Ted, Mikael Abrahamson, Shwetha, Edwin Cordeiro --- 01. Unified CPE Simon Perreault https://datatracker.ietf.org/doc/draft-ietf-softwire-Unified-CPE/ Future expansion: absence or presence of options Woj: It's not very unified. In title is unified, but talks about different modes Devices just do NATs with restrict port ranges. It's a question how to configure them. Su: Do you think there's some technical issue in the draft or ? Woj: If the intent of this draft is to help implement such CPE, it's not meeting the goal. Actually none of those reference very helpful Suresh: Would you like to help? Text? Woj: Willing to help but also expecting partitioning (teches) ... Suresh: We need something more concrete to make changes --- 02. Lightweight 4over6 Ian Farrer http://datatracker.ietf.org/doc/draft-ietf-softwire-lw4over6/ Ian: Draft is stable, ready for WGLC No issue --- 03. 4rd update Sheng Jiang https://datatracker.ietf.org/doc/draft-ietf-softwire-4rd Sheng: Authors deem the doc ready for WGLC Lorenzo: (go back 1 slide)Why SHOULD and not MUST? (about the CE using DAD to defend the tag space) Implementers will not do it if it's a SHOULD. Sheng: MUST is better Mark: What we are doing with 4rd V.S. MAP-T V.S. MAP-E Suresh: MAP-E is standard track, MAP-T and 4rd are experimental. MAP-E going first. after MAP-E any order. Andrew: How do you defend addresses on the network that do snooping Suresh: This's something discuss a bit in 6man --- 04. Unified IPv4-in-IPv6 Softwire CPE: Focus on DHCP Ian Farrer Suresh: Good idea: having one set of DHCP options for all solutions (chair hat off) QI Sun: (slide 6)In the last bullet, is DHCPv6 used for the dynamic ipv4 address? Ian: DHCPv6 to tell the client that it should use DHCPv4oDHCPv6, not entirely DHCPv6 Qi: In dynamic addressing, use DHCPv4oDHCPv6 to get both IPv4 address and port sets? Ian: Yes. You still need to receive flags Suresh: We decided to do v4 off, you need to have DHCP option to do this Qi: OPTION_MAP_BIND for IPv4 address, then OPTION_MAP_BIND_DYN to use DHCPv4oDHCPv6...? Ian: In the next slides Woj: 1:1 full address may use BRule and FRule Ian: When configuring 1:1 MAP and lw4o6, use OPTION_MAP_BIND Suresh: Unified CPE use a set of options to figure out what to do. If you get OPTION_MAP_BIND, you're going to 1:1 mode Woj: OPTION_MAP_BIND to use DHCPv4oDHCPv6 Ian: There's no need to do DHCPv4oDHCPv6 in the static config case (DHCPv6 only) Woj: So what does this OPTION_MAP_BIND option do? Ian: Two things are contained in OPTION_MAP_BIND. it should go in the MAP-DHCP draft. it tells the IPv4 /32 and optionally PSID Woj: That's what BRule does Mark: MAP 1:1 is subset of MAP-E. You should be able to communicate MAP 1:1 through MAP-E configuration Suresh: Is it difficult to implement OPTION_MAP_BIND? Mark: Unified-CPE vendors don't have to do 5 different things. CPEs just do one thing. Suresh: It's not about processing, just DHCP option. Mark: We will have different CPEs Ian: There'are also people who need unified model Simon: Unified-CPE doesn't mean unify everything. compromise will be very ugly Suresh: (to Mark)Do you concern that some people won't implement some options? Mark: Some will only implement some of the options. fragment of CPE. Mark: Problem is that there will be two kinds of CPE, not a unified CPE Suresh: I don't see how the IETF can prevent this (implement a subset of options) from happening. Suggestion? Mark: We start to diverge when we start talking in "modes" Ian: We very carefully picked the word "mode". we can change it if you want. Suresh: Not sure Mark's input is actionable Ted: There are two options. not clear: why OPTION_MAP_BIND is subset of s46_BRule. Ian: It could be expressed as subset but you need to build full implementation Ted: it doesn't cost much to a lw4o6 implementer to look at a subset of bits in BRule option. It's better to use another option to carry v4 address (other than BRule option) Suresh: We are using options for 2 things: values and presence/absence Woj: There is a mode where you can't provision all of this stuff using only DHCPv6. That's the only mode that needs signaling. Suresh: Yes, and DHCPv4 over DHCPv6 is new so maybe there is refactoring to be done in Unified-CPE Ted: The "if" parent hese is more complicated with BRule than with OPTION_MAP_BIND Andrew: A DHCPv6 provisioning MAP CPE in 500 lines of C code is in my hand. With DHCPv4 over DHCPv6 it will be much more complicated Suresh: That's another discussion Mark: Need 3 options: 1. MAP option includes 1:1, from this CPE knows IPv4 address and port range 2. override MAP option with another option conveying ipv4 address and port set manually 3. DHCPinform type information stateless, after you have IP address and need other stuff Ian: Before we try to unify, we had these 3 thing Suresh: Everybody's unhappy, but that's the definition of rough consensus. There's time. Proposal #3 (slide 12) QI Sun: is OPTION_DHCP4_O_DHCP6_ENABLE a DHCPv6 option? Ian: Yes QI Sun: Option or sub-option? Ian: It could be done as a global option I suppose Ted: Is there a real use case for two s46 options within a single CPE? the only reason to have an s46 option is to group things together. If you don't need to do that, you shouldn't. Ian: Only case is softwire over different bear Ted: That would be separate DHCP request Ted: Get rid of the container then. much simpler. Especially for the ORO option. Woj: In MAP-DHCP, they're all global. including PSID Woj: FRule and BRule are global. PSID doesn't make sense, just for ports Ted: Is there a case you want to send two S46 options Ole: When provisioning with two MAP domains Ted: Making PSID a sub-option doesn't ensure that it always go with a BRule. You have to change DHCP protocol to support this, client to be able to request. take it offline (Very interesting discussion. Take offline) Issue #4 (slide 13) So far, MAP-T hasn't been included within provisioning Proposed solution: create a new option using the OPTION_S46_FRule format specifically to configure MAP-T Mark: No! This is not unified! The only difference is that there is header compression before sending the packet. Suresh: How to tell Unified-CPE to do translation. Provisioning together. Issue #5 (skipped) Simon: I don't know what to write in the next revision of the draft Suresh: That's not a problem Simon: Let me know when you think we have consensus Suresh: Ok --- 05. DHCPv6 Options for Mapping of Address and Port Wojciech Dec http://datatracker.ietf.org/doc/draft-ietf-softwire-MAP-DHCP/ S46 is a term invented to try to be protocol-agnostic (description of how things work) QI Sun: There's a problem in the example, it should be /56 instead of /40 Woj: It could be zero, it could be anything, you don't fill up anything, it's a scope selector Suresh: It's just a bug. fill it up with nothing. let's move on. Ian: There's no change in the proposal based on the conversation so far. Woj: What is it that doesn't work with this? Ian: We've been through this discussion, take unified approach. Everyone agrees except you. We still get the same stuff back. How can we move forward? Woj: We disagree about the conclusion. Suresh: I don't think we ever wrote down this. Ian: We had topic around MAP base draft, it's ea=0 removed, will move to MAP-DHCP draft Suresh: The agreement is that the MAP draft will describe it (ea-len = 0) Suresh: Missing from lw4o6 is assigning port range. Ian: With this, on the server end, you've got no way of knowing if a CPE is MAP-capable or lw4o6-capable. No way to support both MAP and lw4o6. If you have a separate option to note that, DHCP server can push configure accordingly Suresh: Ian wants a flag that says "I can only do zero" Woj: The answer is already in the draft, it's port_params option. port_params only makes sense with ea-len = 0. Ian: If you already allocate address to client, that would not ... Where's public 4over6? Suresh: IESG Ted: Unified-CPE has to support public 4over6 style deployment. Suresh: Ian is talking map_bind. Use as a flag? Ian: Further about possible failure cases are ... Gang Chen: Remove consideration for 4rd. 4rd uses this draft. this draft should support 4rd. Mark: This is separated from MAP-E Suresh: It could be informational reference Suresh: Send text to the list Mark: This representation is for Unified-CPE. ea-bit can be any value. Suresh: That's compromise. Mark: vendor does one thing. not OPTION_MAP_BIND Ian: We developed CPE code ... Ted: Ian, you're asking them to do the same ting Suresh: Unified-CPE does different things. IETF does one thing for both Ian and Satoru's network, not two things. Woj: This draft complete addresses the MAP configuration. This does for MAP case Simon: port set option is flag? Woj: I take that back Suresh: why not make an explicit flag? Qi: posted some comments on the mailing list Suresh: add an issue tracker Suresh: do people in this room think this draft only cover MAP-E? (hands) Mark: Maybe. It depends on how much. Suresh: ask in the mailing list Ted: let the DHCP server thinking is bad idea. using map_bind is simple Suresh: empty option map_bind? Simon: the value of the BRule option shouldn't depend on what the client asks for Ed Lopez (Fortinet): there's a need for simplicity in DHCP operations Suresh: should go to dhc for review lw4over6 to signal it supports ea=0. we don't want multiple DHCP option draft --- 06. Mapping of Address and Port using Translation (MAP-T) Wojciech Dec http://datatracker.ietf.org/doc/draft-ietf-softwire-MAP-T/ Request last call (no comments) --- 07. Use cases for MAP-T Roberta Maglione http://datatracker.ietf.org/doc/draft-maglione-softwire-MAP-T-scenarios/ Two new operators as co-authors: Rogers and Brighthouse Ask for adoption Suresh: How many people have read this draft? Need more feedback Gang: Not clear about OLT. Not sure the audience for the draft. Guideline on how to use MAP-T is already there. overlap between deployment draft and this draft Suresh: Do you think this is useful? Roberta: ... Jan: Need operators' feedback to the IETF. Would like to see more Sheng: Should in v6ops. Ted: v6ops is overloaded. Sending it to v6ops is killing it. Do it here. ----> How many people think documenting the senario is important: (MINOR OPPOSITION) ----> How many people think this draft is the best for documenting: (CONSENSUS IS TO ADOPT) --- 08. Lightweight 4over6 Failover QI Sun http://datatracker.ietf.org/doc/draft-lee-softwire-lw4over6-failover/ Mark: ICMPv6 is a very bad message to rely upon. Subject to rate limiting and filtering. Coupling core of IPv6 stack - ICMPv6 to restart IPv4 provisioning, very bad idea. Where's ICMPv6 message coming from? Primary lwAFTR? Qi: Backup Mark: How to detect primary failed? Qi: Primary and backup have communication. Mark: That's not the answer. It's anycast. Simon: When Primary fails, the Backup receives, and it sends an ICMPv6 back to lwB4 saying "I don't know you" - The orginial state is missing. Mark: You are walking down the path that point-to-point tunnel went before. This really gonna have problems. --- 09. DHCPv6 option for Lightweight 4over6 Yuchi Chen http://datatracker.ietf.org/doc/draft-sun-softwire-lw4over6-DHCPv6/ (no comments, take to the list) Radius Extension for Lightweight 4over6 Cathy Zhou http://datatracker.ietf.org/doc/draft-sun-softwire-lw4over6-radext/ Roberta: draft is related to DHCPv6 option draft. wait until the discussion is finished. --- 10. Provisioning Lightweight 4over6 with PCP Simon Perreault http://datatracker.ietf.org/doc/draft-perreault-softwire-lw4over6-pcp/ (to the list) --- 11. Lightweight 4over6 deployment with DHCPv4 over DHCPv6 QI Sun http://datatracker.ietf.org/doc/draft-liu-softwire-lw4over6-DHCP-deployment/ (to the list) --- 12. Lightweight 4over6 Deployment Chongfeng Xie http://datatracker.ietf.org/doc/draft-sun-softwire-lightweigh-4over6-deployment/ (to the list) --- 13. Experience from MAP-T Testing Edwin Cordeiro http://datatracker.ietf.org/doc/draft-cordeiro-softwire-experience-mapt/ (to the list)