BEHAVE minutes, IETF78 (Maastricht), Monday, July 26, 2010, 0900-1130 Chairs: Dave Thaler dthaler@microsoft.com, Dan Wing dwing@cisco.com Jabber room: behave@jabber.ietf.org 9:00 Dave Thaler presented status update slides Working group document status http://datatracker.ietf.org/doc/draft-ietf-behave-v6v4-framework/ http://datatracker.ietf.org/doc/draft-ietf-behave-v6v4-xlate/ http://datatracker.ietf.org/doc/draft-ietf-behave-v6v4-xlate-stateful/ http://tools.ietf.org/html/draft-ietf-behave-turn-ipv6-11 http://datatracker.ietf.org/doc/draft-ietf-behave-address-format/ http://datatracker.ietf.org/doc/draft-ietf-behave-dns64/ http://datatracker.ietf.org/doc/draft-ietf-behave-ftp64/ several in IESG evaluation dns64 waiting on AD ftp64 finished WGLC, later in the week IPR on FTP64, Cisco, RAND type Doodle poll on new work recharter Focus on implementers and deployment per RFC 5218 14 responses, only 7 affiliations -- smaller than feb 2009, may mean we've addressed the priorities 9 months to one year of work for new charter; poll is one factor in the recharter Proposed charter resultant from the poll. in scope for discussion: milestones allowed for IPv4 app on an IPv6-only host to IPv6 internet in scope, without milestones: * multicast * how do current solutions deal with NAT-PT considerations? * Avoiding NAT64 -- presentations today * Load balancing (high response on poll) * Host-based translation, scoped to updating BIS and BIH solutions Discussed but not in charter: NAT MIB? Any interest (for monitoring)? No. Port control protocol (PCP) -- separate WG is proposed to continue IPv4 address range for stateless traceroute may move to ops Dave Harrington -- PCP in discussion for WG, no decision made Alain -- lunch on Wednesday -- informal Jari -- no decision, proposal to create a group, to be reviewed on list very soon Discuss charter item: presentation Simon - multicast -- in scope for discussion, insufficient interest for milestone Chairs -- discuss on the list if interested ---------- Shin Miyakawa, Large Scale NAT draft-nishitani-cgn-05 draft-shirasaki-nat444-02 draft-shirasaki-nat444-isp-shared-addr-04 CGN - asking to make WG doc Modify to chair recommendation on revising requirements format, avoid duplication with requirements draft NAT444 - separate from original draft, descriptive Open to joining with other efforts, need feedback Shared-addr - what is happening, controversial. See azinger NAT444 not best solution, but implementations are out there Alain - highlights are good, but define terminology: CGN, LSN, multi-user NAT. Customers are confused. Prefer Multi-User NAT. Second, shared address - there are technical issues that have not been addressed - still opposed. Shin - people came to us with this question. Alain - value in explaining how to choose the address space, do not support dedicating address space in the doc. Jari -- agree. On shared addressing, discussed and dismissed at a prior IETF. Plan to write in OPS area to dis-recommend. Shin -- let OPS do this. Jari -- I would like to have a doc to document the issues Dan -- there is consensus to adopt the LSN doc; need to poll on the second. Adopt nishitani? Any objections? None. Shin -- will rename to WG doc. ---------- Simon -- TURN IPv6 9:30 TURN-IPv6 review feedback (Simon Perreault, 15) draft-ietf-behave-turn-ipv6 Issue from SEC-DIR review Amplification attack with chained headers, looping. Does the TURN server need to filter? On client or peer source address? Well-known tunnels -- like 6to4 or Teredo. Question to working group. Dave -- why specific address ranges help? Is tunnel in a tunnel the real problem? Just singling out 6to4 does ? Is this possible in v4? Simon -- similar issue in the TURN RFC, many things can become relays. What is being attacked? The TURN relay? Dave -- yes, and the tunnel endpoint more so. Tentative response is the behavior sounds like TURNv4 issue, if there is still a problem, it should be addressed in a way that applies to both v4 and v6. On Dont Fragment, current text ignores. Alternative behavior would be to follow TURNv4. Preferred behavior is to follow the xlate draft. No input on the mailing list, but the issue has come back and should be added to the draft. ---------- Victor Kuarsingh NAT44/LSN 9:45 NAT44/LSN Deployment Options and Experiences (Victor Kuarsingh, 15) draft-kuarsingh-lsn-deployment-00 ways of integrating LSN, experience motivation -- how-to in case it becomes necessary; combining NAT44 with IPv6 a lot of inferred requirements. Avoid if possible, flexibility as needs change over time, logging important, cost and complexity issues. Address overlap issues RFC 4364 leverage -- VPN instances map to translation realms Allow v6 to mature and evolve Lars Eggert -- in draft complicated way to extend IPv4, may impede transition due to all the effort in place -- incentive to maintain. How it aids transition -- allows the average person to ignore IPv6 issues. The ISP can allow flows to move to IPv6 while allowing IPv4 to continue. Lars -- this complex stitching seems more complicated than IPv6 rollout. Victor -- mature technologies, VPN, but stitched together in complex ways. Stuff that already works repurposed. Andrew Sullivan -- how does this interact with actual v6 customer work. What happens to a native v6? Victor -- so far, v6 flows seems to work. Andrew -- if v6 coexists it really is transitional. Philip Matthews -- is this for new/existing customers? Victor -- new. No impact on existing v4 customers. Philip -- is this a one-off, or a future for this draft? Informational? Victor -- revise to fill out experience. Alain -- good to have feedback, no answer on issues around shared addresses, logging etc. What do you do on these issues? Victor -- need more experience to flesh out. Alain -- key point is that the draft documents real customer impact. Chris Metz -- operators not yet deploying CGN, etc. we need to hear these ---------- Jari -- Ipv6 only network experience draft-arkko-ipv6-only-experience-00 We've been in dual stack for years, so had to try something new Many issues in general environments Application problems -- skype not compatible; secondlife; chat and games NAT64 connectivity -- brings IPv6 close to parity with IPv4. Most things don't work with IPv6-only. Measurements based on Alexa top 1000. Results confirm that dual-stack is the preferred mode for general users, IPv6-only for controlled environments. Not far from making it work for everyone. Issues -- DNS discovery, bugs, IPv4 literals Iljitch -- did you test FTP? Jari -- don't recall. Alain -- what is the breakage with double NAT? interesting to compare. Jari -- surprising at the level of breakage in vanilla IPv4. Alain -- are the same apps breaking in IPv6 that would break with double NAT? Alain -- would be great to measure delay as well. Some experiments show significant delay. Stuart -- v4 literals -- the OS could have hooks to catch this. Dan -- presentation on BIH proposes a solution. Jari -- search engine to locate IPv4 literals Tina -- Scalability? Jari -- no specific reports. Tina -- NAT session logging performance? Jari -- no specific numbers, adequate for testing so far. Hui -- China Mobile -- very informative, please publish. Separate DNS64? Jari -- same box, but not a requirement. Philip Matthews -- if the foreign site was IPv6 do you go native? Jari -- 2 out of the 3 networks took IPv6 path by default. Third favored translation. Philip -- explore heuristics for choosing method Experience with Home Gateways -- Nokia Device collection -- see slide. Simulated testbed -- one computer simulates the Internet including DNS etc. and another the client side. "n" NAT boxes providing alternate VPNs UDP binding timeouts well below IETF recommendation TCP throughput DCCP -- none worked DNS over UDP worked in general, over TCP not so well. Still looking for more gateways, ideas, etc. Please contact. ---------- Teemu Savolien -- Bump in the host, based on RFC 2767 BIS and RFC 3338 BIA draft-huang-behave-bih-00 Not general purpose tools, BIA avoids some of the problems in BIS Still many IPv4 applications BIA and BIS are partially obsolete -- addresses already used for other purposes. Alain -- do not use RFC 1918 -- ask IANA to reserve a small block Teemu -- multihomed hosts have a risk Dave T -- difficult to reserve a range Alain -- DS-lite had the same problem and we did get a small range Common element is a bump in the host (BIH) so rather than update both RFCs, unite and provide an option for different implementations. Alain -- sounds like a 464 translation. Teemu -- will favor IPv6 through; Dan -- private v4 is not in DNS Alain -- need a strong caveat to discourage this, or make experiment Julian -- not a good idea; Philip Matthews -- what changes from the earlier RFCs -- merge, fix ambiguities and corrections. Dave -- short scope milestone in charter ? coauthor BIA -- no big changes. ? chen? Useful. Existing running code on different platforms, maybe mature enough for standards track. Philip -- experimental RFCs should have a timeline ? standards track is reasonable. Dan -- hallway and mailing list ? ericsson -- bump in host -- should consider other transport protocols that might handle better. Get around UPD/TCP. Pure dual stack might be better. ---------- Journi Kohonen 10:50 Analysis: hosts knowing AAAA is synthesized (Jouni Korhonen, 20) versus hosts creating their own synthesized IPv6 address Section 4.1 of draft-wing-behave-learn-prefix-04 Section 4.2 of draft-wing-behave-learn-prefix-04 Section 3.3 of draft-wing-behave-learn-prefix-03 draft-korhonen-edns0-synthesis-flag-00 Section 3 of draft-korhonen-edns0-synthesis-flag-00 Section 4 of draft-korhonen-edns0-synthesis-flag-00 draft-boucadair-behave-dns64-discovery-00 sometimes knowing NAT64 prefix is useful references identify 7 different approaches that may work. 1. EDNS0 flags; needs support in the resolver. Lack of API support 2. New EDNS0 Option Code Andrew Sullivan -- flag bits are scarce 3. Known FQDN 4. Registered names no host stack change; more DNS queries 5. DHCPv6 for NAT64 prefix synch issues; API enhancements 6. RA conveys 7. New RRTYPE Philip -- what problem are you trying to solve? Learn the prefix, discover NAT64 box, find out whether a particular DNS response had been synthesized? Journi -- some options address the synthesis issue, others the NAT64 routability, or both Peter Koch -- proposals 3, 4 and 5 -- well known predefined names? Service name Andrew Sullivan -- who cares about whether a address is synthetic? All the approaches have some issues. Eric Resorcola -- I could rule out 5 of these. Dave -- is this interesting, solvable? Remi Despres -- very important, end-to-end transparency is impeded by the synthetic address Simon P. -- another row -- multiple prefixes with redundant NAT. Round robin prefix use. Iljitch -- 3484 choices may be impacted by avoiding synthesized addresses. Dave -- theoretically should favor native addresses, but shouldn't have both Dan -- no real scenario where this matters. Iljitch -- if we can do it right without much effort, we should Dan -- is issue 1 interesting, should work on? Weak hum, some objections. Issue 2 -- stronger agreement, no objections ---------- 11:10 NAT64 and mobile IPv6 (Behcet Sarikaya, 15) draft-sarikaya-behave-netext-nat64-pmip-00 draft-sarikaya-behave-mext-nat64-dsmip-00 Bechet Sarikaya Proxy and DSMIP. Multicast proposed solution; looking for ideas and improvement Is there interest in the WG on this? Are the SDOs interested in this? Dave -- is this presented to mobility WG? Bechet -- not so much over there. Sri -- MEXT discussed in roaming scenarios. Might be appropriate to present there Dave -- problem statement. "continues to use same synthetic" seems to be a generic roaming issue.