BEHAVE Working Group Minutes IETF 77, Anaheim, March 2010 Chairs: Dave Thaler, dthaler@microsoft.com Dan Wing, dwing@cisco.com audio archive: http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf77/ietf77-ch3-thur-afnoon.mp3 http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf77/ietf77-ch2-fri-afnoon.mp3 Minutes by Ed Jankiewicz and Stuart Cheshire ----- THURSDAY 1300 Behavior Engineering for Hindrance Avoidance ----- Document status updates Dan Wing gave document status updates ----- 13:10 Area Director review of five documents draft-ietf-behave-address-format-04 draft-ietf-behave-dns64-07 draft-ietf-behave-v6v4-framework-07 draft-ietf-behave-v6v4-xlate-stateful-09 draft-ietf-behave-v6v4-xlate-10 Magnus Westerlund Magnus asked if we should say stateless translator MUST forward unknown transport protocols instead of dropping them. Marcelo Bagnulo: Document only specified for TCP, UDP and ICMP. Is silent about other protocols. Consensus seemed to be that stateless translator should forward unknown transport protocols, stateful translator should drop and return ICMP error. What do NAT44 boxes do? Some make a mapping for { IP Src, IP Dst, Prot number } which means they can support one outgoing flow for that protocol per external destination, but two internal clients can't simultaneously have flows using that protocol to the same external destination. IPv4 IP ID synthesis Needed when DF = 0 and packet size > 68 bytes. Will this require "stateless" translators to keep state? Reference draft-touch-intarea-ipv4-unique-id which reminds to not repeat ID field within 3-tuple State required if the translator will not receive frag headers in re pkt too big, but managed network can ensure against this situation. In behave scenarios the "IPv6 network" is a managed network. Applicability - avoid state Dave Thaler: stateless is only applicable to scenarios where this is true (no network firewalls, etc.) applicability text needs to be revised Hand over to Dave Harrington; some updates needed, then IETF last call will be ok Dave Thaler: only change to stateful is as discussed ----- Intro to Presentations Dan Wing stated guidelines for evaluating presentations: 1. Is there are real-world problem? 2. Does the proposal solve the problem? 3. Is there WG energy to work on it? ----- 13:30 Stateless/Partial-state 1:N Network Address and Protocol Translation between IPv4 and IPv6 nodes draft-xli-behave-xlate-partial-state-01 Xing Li concepts and scenarios why "partial state" in behave defined stateful and stateless translation; stateless cannot use IPv4 address effectively; stateful can, but only supports IPv6 initiated a way to combine features of both - in between less state, less complexity still use IPv4 addresses, allow bidirectional initiation conventional NAT uses port number in addition to address; in 1:N translation each IPv6 host uses a different port number. Single IPv4 with 65K port numbers shared among hosts using modulus operation to assign portions of port range Port 80 - follow 46-relay draft 1:N xlate - stateless/partial state Public IPv4 can be shared by several predefined IPv6 hosts - less efficient but not bad Marcelo Bagnulo: NAT64 stateful - does this already Xing Li: yes it is the same Philip Matthews: Hosts have to know what their port range is. Similar to A+P. Claims to support connections from IPv4 to IPv6, but only to fixed host depending on which host got that chunk of ports. Alain Durand: Preallocation of chunks of ports to each host is inefficient. Remi Despres: More sophisticated port range mapping functions are more useful. Simon Perreault: There is no such thing as partial state. State is state. Mohamed Boucadair: Supports the proposal. Lars Eggert: How does this fit into Dan's guidelines? What problem does it solve? Dan Wing: Can you summarize the problem that caused you to come up with this solution? Dave Thaler: Current stateful xlate does not support connections from IPv4 to IPv6 Dan Wing: Also stateless xlate consumes one IPv4 address per IPv6. This proposal gives some address sharing. Gregory Lebovitz: This would be interesting if it were fully stateless Philip Matthews: Is the focus connecting to entire IPv4 Internet, or to a small IPv4 network? Xing Li: Both Alain Durand: This shares the same problems of A+P. Dan Wing: When host picks a source port in its assigned range it's stateless, otherwise it's stateful, per slide 13. Simon Perreault: Host's choice of port determines when it's stateful Alain Durand: How does host know its "preferred" port range? ----- 13:45 Stateless Source Address Mapping Algorithm for ICMPv6 draft-xli-behave-icmp-address-00 Xing Li tool for stateless translation source address in ICMPv6 may not be IPv4-translatable MTU exceeded, pkt too big The router may not be configured to handle Configure IPv6 routers to use IPv4-translatable Or perform stateful source address mapping - not worth the cost to a stateless translator Stateless source address mapping Content of ICMP is more important than who generated IPv4 addresses SHOULD NOT be wasted Reserve a /24 for a well-known prefix Last octet - random, hop count, hash Dave Thaler: This is only useful for stateless translators, right? Xing Li: Yes ----- 14:00 NAT46 considerations draft-liu-behave-nat46-02 Dapeng Liu Scenario is little IPv4 island connected to worldwide IPv6 Internet. introduction of the problem and scenario workable solutions IPv4-only network to IPv6 Internet, dual stack server with private IPv4 address during some early deployment modules DNS handling - IPv6 server does not have type A record Address mapping - should be a mapping written Translation - between IPv4 and IPv6 These building blocks can be put together in the network NAT46 solution Is this a valid problem and needs to be solved? Philip Matthews: Is there anything new in this that wasn't already in NAT-PT, which was abandoned? Dapeng Liu: There are many different ways to solve a problem. We have ENR in translation box. Philip Matthews: Stateful NAT64 replaced NAT-PT. Stateful NAT64 only tries to solve this in one direction. Dapeng Liu: IPv4 is insufficient to map IPv6 addresses. Philip Matthews: I don't think we need to worry about this scenario for a long time. Shin Miyakawa: IPv4 initiated - do we have enough understanding of the issues? It is important to work on understanding the issues before working on solutions Andrew Sullivan: Is the solution worth doing for the side-effects it causes. Charlie Perkins: NAT46 will also work for IPv6-only hosts. Would like to see this developed because it makes IPv6-only hosts viable. Alain Durand: This may be something that would work, but do we want to spend our time on it? Marcelo Bagnulo: something weird here - define a technology, ops group deprecates, now we reinvent it again. ----- 14:30 NAT State Synchronization Using SCSP draft-xu-behave-nat-state-sync-01 Dean Cheng presented last time; use SCSP to sync NAT NAT state refreshment Can be a single point of failure if only one NAT has state Do we need to standardize NAT sync? Already proprietary solutions; for coexistence a standards based solution would be helpful Should this draft address NAT44? Already handled proprietary - but some feel it should be standardized DS-lite includes a NAT44 - may make sense to address it in this standardization Has SCSP really been deployed? Not many apps, but proprietary methods have been used Uses the same link-state algorithm as in routing (OSPF, IS-IS) very widely deployed Next steps Dave Thaler: Do carriers want NAT boxes from different vendors to interoperate, or do they want NAT boxes from the same vendor to interoperate, but using a standardized protocol? Dean Cheng: The world has proprietary routing protocols as well as standardized routing protocols. Lars Eggert: This is an optimization to do fast failover. Today when a NAT box crashes connections break, and applications already handle that. similar to firewall state - but that is mostly hard state; failover to a clean NAT would work, apps are prepared Philip Matthews: I don't work for an operator. I work for a vendor. I think that fast failover without losing connections would be useful. Mohamed Boucadair: I am from France Telecom, and I would like to use this to synchronize state between NAT boxes from different vendors. Gregory Lebovitz: I do not think this is needed. Getting this right is very hard. It has been achieved (just) with single-vendor solutions. It would be near-impossible to do with multiple vendors. In reality no customer would try to use this with multiple vendors. Hadriel Kaplan: These problems may sound easy, but in reality they are much harder than people realize. We've been doing high availability NAT. any level of state synch is hard. Nuances of the implementations have to comply to share state. Bob Hinden: This kind of protocol is so closely tied to implementation that it's futile to try to standardize it. Gregory Lebovitz: Data point: Many customers ask for inter-vendor VRRP, but few actually use it. ----- 14:40 Redundancy and Load Balancing Framework draft-xu-behave-stateful-nat-standby-03 Xiaohu Xu CGNs are coming; to scale better, need a way to share load Stateful NAT redundancy and load-balancing Hot or cold standby Load balancing in addition to redundancy Dave Thaler: Is this proposal addressing the same underlying problem as the previous proposal? Xiaohu Xu: This is a framework for redundancy and load balancing. Hadriel Kaplan: Without something like this, we'll never have hot standby for large-scale NATs. Gregory Lebovitz: Can't we do this using VRRP? Hadriel Kaplan: Yes, we can do this using VRRP Shin Miyakawa: Sometimes return packet may not come back on same path as outgoing packet Xiaohu Xu: That shouldn't happen Shin Miyakawa: But it does Xiaohu Xu: need to separate redundancy and load balancing Shane Amante: Trying to get boxes to talk using proprietary mechanisms is hard enough already. A standard protocol would work better. ----- 14:45 Avoiding hairpinning NAT64: a handful of approaches draft-wing-behave-dns64-config-02 Dan Wing pushed off dealing with dual-stack hosts DNS64 and NAT64 with dual-stack hosts, they path through DNS64, but could go native Dns64-config - about 10 proposals to handle Mixture of what changes/not Dual-stack to IPv4 content, goes thru NAT64, wastes a nice IPv4 path If you are going to the IPv4 internet, take the IPv4 path In reality, the "nice" IPv4 path already goes through a NAT44. Only gain is NAPT44 instead of NAT64 Brian Carpenter: In reality diagram should be NAT64 followed by NAPT44 in series. Hadriel Kaplan: The NAPT44 path is much more mature and well tested Fred Baker: There are different approaches appropriate for different places. Seems like the user would like to bias according to the policy. DNS64 could direct Alain Durand: Not changing address family is better. Alain Durand: Why is there NAT64 on the network at all? Dan Wing: Because some other hosts on the network might be IPv6-only Alain Durand: Well then they shouldn't all be configured the same way Erik Nordmark: I don't think this is hard. We don't need ten solutions, but we might need two. Alain Durand: This is harder than you think. Not only a host, depends on the application. A single host may have v6only or dual-stack behavior ----- 15:00 IPv6 host learning its NAT64's prefix draft-wing-behave-learn-prefix-04 draft-wing-v6ops-v6app-v4server-01 Dan Wing briefly recap: What does an IPv6-only host do with a URL like http://192.168.1.2/ ? some applications always use IPv4 addresses. Some applications sometimes hard code WKP? But large networks don't use WKP. Slapping 96 bits doesn't solve the problem Currently DNS in draft will be dropped, add back RA to learn, along with DHCPv6 Applications that cannot work, this is a real problem. It is solvable Embed fixed well-known IPv6 prefix? What if no translator is available? Put data in DNS NAPTR records? DHCPv6? RA? Phil Matthews: yes, problem. DNSSEC validation also a problem. Pedro: what about no translator? In general this a real problem. ----- 15:15 Hybrid Type Prefix for IPv4-Embedded IPv6 Addresses draft-xu-behave-hybrid-type-prefix-00 Xu Xiaohu Distinguish synthesized IPv6 addresses from "real" IPv6 addresses by using a recognizable prefix for synthesized IPv6 addresses. Dan Wing: This I-D appears to have two goals: 1. Load balancing between internal NAT64 boxes. 2. Avoid external users unnecessarily using NAT64 box. Problem with this proposal is that it discourages incremental operational experience with IPv6 and NAT64. If all dual-stack hosts avoid using NAT64 addresses, then no one will use NAT64 boxes until someone actually has an IPv6-only device. Tony Hain: This causes harm. Preferring IPv4 just perpetuates use of IPv4. Xu Xiaohu: Native is better than translation. Andrew Sullivan: What's wrong with paying the cost of putting traffic through the NAT64 box? That's just part of the transition cost. Xu Xiaohu: Native is better than translation. Andrew Sullivan: If NAT64 is broken then that's a problem, but otherwise what's the problem? Xu Xiaohu: Native is better than translation. Alain Durand: Using a crappy service is not good business model. Mark Andrews: Most IPv4 traffic goes through NAT today, and it's okay, so why do we assume NAT64 will be crappy? Does the NAT64 attract a swarm of traffic? Put it in early and get some small amount of traffic now. If you do it late it gets slammed. Remi Depres: either the host has a private/public IP address. If it has a public address, it should go through the IPv4 way. If private, the choice is NAT64 vs NAT44. NAT44 prefered over NAT64 ----- 14:10 Unique IPv4-Mapped Addresses draft-thaler-6man-unique-v4mapped-00 Dave Thaler IPv6 syntax at the top, applications with single listener communication with both address families in the same socket WKP ::ffff:0:0/96 IPv4-Mapped Address - goes to v4 stack Problem - non-global IPv4 addresses are ambiguous when multihomed Better behavior is an incentive. Site-locals deprecated to disambiguate using ULA Take a global ID inside the address rather than using a WKP Need to add impact on APIs Where does Global ID come from? If using ULA, from the ULA; but if ULAs not used, how does the host generate? Provide incentive for applications to move to IPv6 API summary - IPv4-Mapped IP addressed are used in OS APIs to tell API to hand packet (or other connection data) to local IPv4 stack instead of using IPv6 stack. Philip Matthews: Point of API is to encourage adoption of IPv6-capable API. Is this new API going to be out in time to make any difference? Won't this take years? Won't real IPv6 be ubiquitous anyway by then? Dave: any apps already calling AF_INET6 get better behavior when talking to IPv4 applications. What is the incentive to change my app? Over time multihoming becomes more of a problem, as will IPv6. This gives one more reason. Philip Matthews: too late to be an incentive. Questioning the motivation Teemu Savolainen: multiple IPv4 networks - look to MIF working group ----- 15:25 Bump in the Stack / Bump in the API draft-huang-behave-rfc2767bis-01 draft-huang-behave-rfc2767bis Hui Deng bump in the stack stateful translation below the Transport Layer, using RFC 1918 addresses bump in the API stateful translation above the Transport Layer with WKP v6/4 already common in host legacy apps BIAbis - mod to use private address pool BISbis - consistent with DNS64/DNS46 Bump in API and Bump in Stack have lots of text in common. Unify them into one? Alain Durand: The reason RFC 2767 and RFC 3338 are Informational and Experimental (not standards track) is because we wanted to promote application vendors to convert apps to IPv6 rather than relying on the stack. Hui: if you have dual stack this is a benefit, and we should revisit the decision. Fred Templin: even today in large enterprises, apps are still the majority, so techniques like this are very useful. Dave Thaler (floor mic): Making IPv4 apps transparently work on IPv6 helps provide an incentive for operators to deploy IPv6. Brian Carpenter: Many years ago I thought these were a great idea, but reality has been disappointing. Alain Durand: Who is going to certify that this works? Adding a shim layer, need to revalidate the applications against the modified OS. Dave Thaler: In many scenarios, like a business using its own custom business apps, that business confirms that they work acceptably with Bump in the Stack / Bump in the API. ----- 15:40 ICMPv6 echo replies for Teredo clients draft-denis-icmpv6-generation-for-teredo-01 Teemu Savolainen Problems when NAT64 causes ICMP echo replies to not make it back to Teredo clients, thereby preventing tunnel creation. (Teredo server cannot forward packet, only Teredo relay can do that.) some update since Stockholm, looking at problem in particular Teredo client with NAT64, translation of ICMPv6-ICMPv4 Likelihood - found in the lab, not in real network Little energy from room to worry about this problem. Dave Thaler: shelve it for now, wait for need Teemu Savolainen: agreed ----- 15:45 LSN and NAT444 update draft-nishitani-cgn-04 draft-shirasaki-nat444-01 Shin Miyakawa split up drafts one on CGN transparency, not nat444, dslite, etc. one defining nat444 model without looking at problem areas one defining nat444-isp-shared address draft-nishitani-cgn - make a WG doc and fast track added some reasons and justification for requirements nat444 - short description of nat444 - make a WG doc and move quickly isp-shared-addr may take time. Looking at size of ISP shared address See draft-azinger-additional-private-ipv4-space-issues We need standard docs to describe NAT444 as quickly as possible. No comments from the room. ----- FRIDAY 1300-1515 Behavior Engineering for Hindrance Avoidance ----- 13:05 IETF - 3GPP workshop on IPv6 migration: Summary and Conclusions, Fred Baker Joint workshop in March, co-chaired Hosted by China Mobile 3GPP Technical Report 23.975 scenarios Validated that scenarios 1-3 were OK, dropped scenario 4 Conclusion - enough solutions on the table; asked networks what they are running - dual-stack, and some IPv6-only Gateway Initiated DSlite, stateful/less translation 3GPP has some more thinking on it Nice if IETF stateful/less translation went to IESG (now has happened) Per-interface NAT44 to address IPv4 shortage/multiplexing, ports to extend Jari Arkko: Slide should say IETF is encouraged to continue working on stateful translation, not stateless translation Fred Baker: Yes, 3GPP are primarily concerned with stateful translation ----- 13:10 IETF77 NAT64 Experiment Report Simon Perreault PowerPC Linux running Unbound or Bind About 34 people tried the ssid - not a lot of traffic 18 IPv6 packets with null source 25 IPv6 packets with source outside the subnet Strange behavior on Snow Leopard, CNAMEs don't work in IPv6, not specific to NAT64 Alexander Mayrhofer: Windows machines had problems with HTTPS Stuart Cheshire: The slides state that Mac OS X 10.6 has problems with CNAME records on IPv6-only networks. Actually it's nothing to do with CNAME records, it's caused be AAAA responses that take far too long to arrive, and Mac gives up waiting for them. It's a bug that should be fixed, but it's a timing issue, not a CNAME issue. Network Managers think you are offline, tries another SSID IPv4-only apps don't work No XMPP client on Windows Found 2 actual bugs in our stuff Simon Perreault: Should we repeat this experiment at Maastricht? Philip Matthews: Yes Stuart Cheshire: Also, thanks for running this valuable experiment. We found a bug, but now the bug will get fixed, and that's how progress is made. Maybe we should do an experiment where this is the only available SSID during the Maastricht plenary sessions? Dave Thaler: If we want to do this at Maastricht, we need to solve the DNS configuration issue. Requiring everyone to manually configure the DNS server address is not reasonable. Wes George: We could solve this by having an IPv4 DNS helper just to work around the DNS configuration problem. ----- 13:20 Scenario 2 and 4: Solutions and Comparisons draft-perkins-sourceipnat Charles Perkins Supporting IPv4-initiated communication is crucial Motivational for the chartering discussion With the IVI authors comparing and contrasting the methods for adapting to IPv4 Internet Scenario 2 (and 4) Solutions and comparisons Given at recent BGPv6 meeting Correspondence between a set of IPv4 and IPv6 addresses IVI - Stateless, does not require DNS-ALG IVI+DHCPv6 - uses DHCP to allocate the IPv4 addresses 1:N-IVI increase the re-use of IPv4 address by port extension Loses application transparency SIPNAT (source-IP NAT) take each IPv4 address use for multiple destinations at the same time by keeping state on source address association to IPv6 destination. DNS caching gets in the way - the DNS request triggers the association so stale cache interferes How much expansion can you get? Perhaps 1000s. Modeled as a flow translation, feasible to implement Comparisons - see how the different schemes support each other, based on: Complexity, conservation, transparency, continuous/dynamic assignment (see chart in slides) DHCPv6 conserves IPv4 better Port expansion works well but not application transparent SIPNAT - good for portless applications Conclusion - these approaches are different but compatible Some apps require continuous connection, some don't care about port assignment, these can be integrated to provide comprehensive support For a lot of websites with low hit rate, don't need continuous mapping Andrew Sullivan: SIPNAT has issues with how it interacts with DNS caches. This needs to be discussed in the draft. Charles Perkins: SIPNAT keys off DNS request, so if DNS cache gives same answer, then translator will never get query that triggers Andrew Sullivan: Set the TTLs low Charles Perkins: Some caches don't respect low TTL values Andrew Sullivan: I don't see any evidence of this Dave Thaler: Some home gateways enforce a minimum TTL of 30 seconds Andrew Sullivan: Then they're just broken and it's not our fault Magnus Westerlund: Have all the issues that were brought up before been addressed in the draft? Simon Perreault: If this is to become a working group item, we should have a single document that describes both use cases, instead of two. Charles Perkins: I am in favor of that also. Chris Liljenstolpe: Agree with the last comments regarding having a single RFC ----- 13:30 Analysis of 64 Translation, draft-penno-behave-64-analysis Dan Wing for Reinaldo Penno How well did we handle the NAT-PT issues? 64 covers all the methods Response to 4966 - decide what problems remain to be solved We get requests internally and from customers "what's wrong with NAT-PT" How to explain why this is better, why we went through the exercise Problems still outstanding: 64 still breaks some stuff Scalability concerns Dual-stack hosts tend to use NAT64 Improved, but not perfect Is this something we want to have as a WG milestone? Gregory Lebovitz, on behalf of IAB: It is important to publish this as working group document. Two messages: 1. This is better, but not perfect. 2. Even though we focus on NATs that doesn't mean we love them. This is not really solving the problem, just easing the pain. Real solution remains IPv6. Philip Matthews: Agree that this is a good document. ----- 13:40 Re-charter, milestone discussion Dave Thaler Dan Wing Three questions about 6 scenarios Are you already using NAT-PT to solve this? Are you planning to implement something? Are you planning to deploy something? Previously Doodle polled to determine which scenarios were urgent/important Scenario 3 - IPv6 Internet - considered deferrable Scenario 6 - not important but solvable with other scenarios -- Work in scope, late -- Work in scope, with milestones (but missed delivery date) Dan Wing: Anyone here tracking SCTP NAT work? Was due Dec 2009. Need new milestone date. No one responded. Andrew Sullivan: Is there any mechanism in this discussion for removing things from the charter? Magnus Westerlund: People are working on this. We should continue to get this work done. Dan: FTP64 was due Dec-2009 - need a new milestone date Philip Matthews: I think we still need this. Dan: not going forward with the group, needs update and WGLC2 -- Chartered work items, without explicit milestones Behave Scenario 3 (IPv4 network to IPv6 Internet) Philip Matthews: 2 related scenarios for v4 to v6 direction, one net to net and one net to Internet, little interest now. Not urgent now. We should wait and work on this later. Wait until we see a particular real pain point and then it will be more clear what to do about it. Dapeng Liu: We can make unifying document Andrew Sullivan: Just because you can solve a problem doesn't mean you should. Many of the solutions here create problems elsewhere. Sometimes we should just say, "This is a bad problem and we're not going to solve it." Jari Arkko: Thank you to working group. We don't have to solve every theoretical problem if no one actually has that theoretical problem. Attempts to measure the real problems in deployment, what is happening in the real world. Specifically referring back to Fred's presentation on mobility, we need to take that seriously. We polled mobile phone community, and we should pay attention to what they told us. Xiaohu Xu: 2767 and 3338 scenarios are not new. Scenario is real and has been for 10 years. Hobung(?) Xo: many are interested in these scenarios. Hard to say which scenario is the best/worst case. Support charter to included these Magnus Westerlund: We know from NAT-PT that this is hard to do in a complete way. Lars Eggert: engineering means you are solving practical problems. We need to send the message that we understand the problems and the solutions and people should now start implementing them. We should wait until people come back and tell us they have tried the solutions, and have found problems, and then solve those problems. When people have deployment experience we can then work out what we need to do next. Dave Thaler: in Feb 2009, we asked whether NAT-PT was being used, try it and identify the problem. Sheng Jiang: We may not understand the issues. We should not use NAT-PT because that's already deprecated. We need something for people to try. Julien Laganier: There are very few services on IPv6 network today. Focus on providing connectivity from IPv6 clients to IPv4 services. Philip Matthews: We need to document why the new solutions are better than NAT-PT. Every document should have a mandatory "How is this better than or different from NAT-PT?" section. Arifumi Matsumoto: It's okay if we don't do all solutions, but if so we need an overview document which explains (for example) why there's a NAT64 but no NAT46. Simon Perreault: if people start using this in the reverse direction that would not be good. Issues with NAT-PT are well known. Tony Hain: The deprecation of NAT-PT created a public nuisance. Everyone wants to solve this at a different place in the network: CPE, middle of network, near content source? A 46aft of some flavor needs to exist somewhere. "Not hard" depending where you put it in the network. The mangling of the header is not a big deal; deployment and network architecture is critical. Hui Deng: People don't understand how these solutions differ from NAT-PT. Sheng Jiang: A lot have people have said, "Is this better than NAT-PT. How is this different to NAT-PT?" Stop talking about NAT-PT. NAT-PT is not active. Dave Thaler: Summary: This is important; Spend time on analysis; Report on real problems in real deployements; Require ID authors to compare with NAT-PT. There are three categories: addressing the NAT-PT space, the Bump-in-API space, and the Bump-on-Stack space. Host based ones are more urgent, NAT-PT not as much so. Will discuss with the ADs. A lot of the same arguments apply to the next topic. -- Dave Thaler: BEHAVE Scenario 4: IPv4 Internet to an IPv6 network Brian Carpenter: We should be firm that content and service providers should deploy PUBLIC IPv4 addresses for the foreseeable future. We're not running out so fast that providers won't be able to get public IPv4 addresses. Marc Blanchet: Until they run out Philip Matthews: Agree with Brian Carpenter. Bob Hinden: Agree with Brian Carpenter. Xing Li: There may be IPv6-only networks (i.e. disagree with Brian Carpenter). And anyway this is an easy problem. Wes George: including private IPv4 addresses initiating; (the IPv6 side could include IPv4 addresses but only reacahable via IPv6.) Situations where the initiator would not be dual stack Mark Andrews: You just need an IPv4 address *somewhere*. If you're on an IPv6-only network then you can tunnel to somewhere that does have IPv4 addresses. Simon Perrault: vast quantities of servers behind NAT44, static. In the poll, this use case is rated as more important than the previous. With static translation this can be addressed. Xing Li: can encourage transition, if IPv4 Internet can get to your servers, removes disincentive to IPv6 -- Multicast Translation Two documents, not sure how to scope this Brian Carpenter: Very few ISPs have deployed multicast. We should proceed with this, but no need to rush. Alan: Some ISPs are using IPv4 multicast for triple-play services Philip Matthews: Typically scenarios will be small number of servers and large number of clients, so common scenario will be IPv4 server and IPv6 client Stig Venaas: There's not much multicast on the public Internet. Arifumi Matsumoto: Some carriers are deploying DS-Lite. Stig Venaas: Can leave this to vendors to solve themselves, or can give guidance to limit the amount of damage that is done. Stig Venaas: When translating unicast we translate the source addresses, and will probably want to do the same with multicast -- Unchartered work items draft-wing-behave-http-ip-address-literals draft-wing-v6ops-v6app-v4server draft-wing-behave-learn-prefix IPv6-only hosts encountering IPv4 address literals Philip Matthews: I think this is important work. We need to solve the little problems related to the main solutions. draft-wing-behave-learn-prefix clearly needs to be done. I support this work. This is useful, and urgent. Xing: important. Even webserver can embed Stig Venaas: This is really useful. Dave Thaler: definitely useful, not necessarily urgent Philip Matthews: urgent. The first one before the demo in Maastricht -- Problem: Avoiding NAT64 with dual-stack host for local networks At least 10 possible ways to solve this. Does the WG need to develop a set of solutions Simon Perrault: harmful, encourage the traffic to go through NAT64. a better behaving NAT, increases IPv6 traffic, more scalable after switch Andrew Sullivan: Agree. Trying to solve this problem is harmful. Jari Arkko: It doesn't make a lot of sense. Should not use NAT64 on a network that might have dual-stack hosts. All hosts today do IPv4. Should only use NAT64 on networks that have *only* IPv6-only hosts on them. Simon Perreault: Only problem is confusion. An informational document could clarify. Marc Blanchet: This is provisioning problem. Do it in DHC working group. Tina (Ting) TSOU (ZOU): I think NAT44 is urgent right now. Gregory Lebovitz: General comment: Instead of just saying you think something is important, say how it rates in importance compared to alternatives. Lars Eggert: If WG can't rank priorities, ADs will have to do it, and would rather WG does it. -- Avoiding NAT64 with dual-stack hosts for remote networks Gregory Lebovitz: always somebody who wants each scenario. We need to evaluate relative urgency. Ed Jankiewicz: multidimensional, doodle poll Lars Eggert: looking to prioritize, either via WG input or ADs will decide -- High availability stateful NAT Gregory Lebovitz: This is not practically useful. Brian Carpenter: If there's a problem here, the solution should be more generic, not NAT-specific. -- NAT load balancing Hui Deng: This is really useful. Andrew Sullivan: Like many things we've heard today, this adds a tremendous amount of complexity. It sounds useful, but can we build something that works usefully. Dan Wing: Brian Carpenter reported that 20% of ISPs give subscribers NATed addresses already, implying need for guidance on balancing those NATs? Brian Carpenter: Yes, or the people answering the question misunderstood the question. Simon Perreault: NAT44 was never specified. NAT64 is very precise, so it's easier to do this for NAT64. Gregory Lebovitz: what I've seen, when giving a v4 address, it is coming from the modem-ish device inside. In OSS networks and data centers, that stuff is behind IPv4 NATs and load balancing -- Analysis against NAT-PT Philip Matthews: We will need to do this anyway to go to draft standard. -- Improved traceroute across a translator No comments at mic -- Large scale NAT Dan Wing: Yes, this is important Dave Thaler: I think I would hear a lot of ISPs saying yes Philip Matthews: should provide guidance Shin Miyakawa: let us do this Jabber: plus 1 -- Problems with shared IP addresses Dave Thaler: Already adopted by INTAREA group -- Improving Teredo's peer reachability Dave Thaler: Already dropped by BEHAVE -- IPsec across an IPv6/IPv4 translator Dave Thaler: Minor update to handle NAT64; the same as IPsec across NAT44 Gregory Lebovitz: Yes, we care about security, but in reality IPsec is encapsulated in UDP, so it will work anyway Brian Carpenter: If we're not certain it will work, should hold up document. Gregory Lebovitz: Don't need to hold up every document until it's perfect. -- IP Address Referrals BoF at last IETF - GROBJ No BoF this time. May belong in this WG. Jari Arkko: need something in charter for maintenance and erratas for the docs RFC or soon going RFC -- SCTP across NAT64 Philip Matthews: Should we work on SCTP across NAT64? Dan Wing: do we want to rescope to include this Magnus Westerlund: hope if it works for NAT44 it should work for NAT64 - like TCP/UDP/ICMP