IPv6 Operations - IETF 80 Thursday 31 March, 9:00-11:30 0) Agenda bashing Fred Baker – Presents, comments on working group process We're bothered by the amount of time we have available to devote each presentation. Drafts will de considered not because they have made the deadlines but rather because that have archived traction on the mailing list. Chairs will engage in editorial discretion. Presentations without a draft behind them, will continue to be brought to the wg on the basis of relevance. Hum requested to demonstrate consensus around sentiment. (hum) More postive than negative volume. 1) Some experiences of common hosts' behavior in broken IPv6 networks http://tools.ietf.org/agenda/80/slides/v6ops-12.pdf Teemu Savolainen - presenting going to share experiences with host behavior Tim Chown - presents rogue ra interaction with happy eyeballs (2nd to last slide) Bad ipv6 behabior due to rogue RAs With no counter-measures, there would have been 250,000 of these rogue Ras. Mostly related to connection sharing. Sample period of 376 days. Dmitri Anipko - With the most recent proposal RFC 3484 bis, 6to4 would be deprioritized compared to IPv4, so if most rogue RAs are 6to4, no other solution may be needed? Simon Perreault – not that simple SwedeMike (jabber) - removing rogue RA is something any service provider should do, it's basic stuff. Don't let customers talk L2 to each other. 2) Happy Eyeballs Implementation Report http://tools.ietf.org/agenda/80/slides/v6ops-17.pdf Simon Perreault - presenting Implmentation of happyballs in draft in Erlang findings: global P mechanism in current drafti is broken P is dominated by single stack ipv4 solutions: only update P for dual stack hosts, update P asyncronously, do per destination P or do away with P findings: do away with useless delays solutions: spec says wait lookup collect but if lookup for ipvX returns no result, ipvY should start connecting immmediately. Janos Mohacsi (jabber)- questions to happy-eyeballs: what about DNS based round-round load-balancing? It is very widely used. Dan Wing – happy eyeballs works fine with dns load balancing. Andri Yurshenko – we do parallel attempts with different address families Jan ker - I don't disagree - why is dns spamming considered out of scope. think it's out of scope. Fred Baker – by the way, we do do api's Janos Mohacsi - Agree with Fred, We should work on API to help proper behaviour - like happy-eyeball. 3) Experimental Observations on Dual Stack Service Performance http://tools.ietf.org/agenda/80/slides/v6ops-1.pdf Geoff Huston - looking at the problem from the side of the server When you look at the world from that vantage point of how much does a server see, you see a huge amount of capability. You have new experiment every time it runs. V6-only test is using ipv6 lteral e.g. no dns full blown tcpdump along with typical server logs Dual stack failures are interesting (e.g. Hosts that deal fine with v6 or v4 only resources but not dual stack) The internet is remarking heterogeneous not homogenious, apnic site users about 5% will prefer v6 on a more popular site it's more like .02%. V6only is 4% why are there 20x more folks that could use v6 but don't use it SwedeMike (jabber) - 6to4 is enabled by default if you have a GUA on windows vista/7 but they don't prefer it geoff - If you prefer v6 in autotunneling things get pretty rough folk coming in on v6 unicast seem to do so at about the same rate (speed) as ipv4 The penatly for 6to4 is around 1.2 seconds, teredo setup is at least 1rtt As part of the experiment tried to mitigate 6to4 variability by putting v6 relay in the server Measure the tcp-3way tunnel setup penalty at 150ms average If you think that's bad lets look at teredo if the only interface you have is teredo it will not retrieve a AAAA , therefore only exercised for literal 30% of clients can pull down the object using terredo, an imense capacity for v6 distribution of setup time, seems to take around 2/3 of a second to setup peaks at 2 seconds and 3 seonds tunnel rtt cost is about 300ms some clients get away with almost no added cost. If you're on unicast v6 be happy and smile, if you're on tunneled v6 turn it off it's dual stack failure .6%, we're not sure why. number is high but unreliable. Connections failure How many folk can send me a syn but not an ack Failure rates for unicast v6 are 2-4% terredo failures = 35% 12-24% of 6to4 failure due to protocol 41 filtering 38% of terredo fail due to icmp filtering, you also don't like outgoing udp so ice/stun/turn probably don't work either. If you want to run v6 tunneling today don't. help us, see url labs.apnic.net tore anderson (jabber) - Regarding 6to4 relay congestion being unlikely due to the low levels of 6to4 traffic: I understand that most of the relayed 6to4 traffic is actually BitTorrent traffic that is rendezvousing with Teredo. This is of course invisible from the web server vantage point, but it might anyway cause congestion on the same 6to4 (and Teredo) relays that also handle the web server traffic that are actually observed in the experiments. Simon Leinen (jabber) - Tore: We have more than 100 Mb/s on our 6to4 relay right now; looks like most of this is indeed BitTorrent. Dave Thaler (jabber) - p2p works much better than non-native to native (which is actually related to why Windows doesn't do AAAA queries if it just has Teredo, as Fred said... by design) Simon P - should it be depricated geoff - killed simon p: would it be better to turn it (relays) off? Igor Gashinsky - killing relay isn't effective kill os. igor G - Counting dns failure rate is atrocious Geoff H - this is tcp failure counting so the dns failures don't show up Rajev - If we look at the data from the weekend do we draw different concusions about tunnel performance? Geoff H - We don't consider 12% failure as drammatically better than 20% it's just bad. Lorenzo C - The results match what we see, we've been looking at the network, we have certain large isps with peaks around 3-4% Geoff - would that we had more data, we seem to have tiny aperatures. badness clumps. the time for automatic tunneling has really passed some operating systems and home routers should turn it on by default we'll discuss this later but I think that a statement from this body supported by this data would be helpful. Dmitry Anipko (jabber) - Comment to Lorentzo: connection from automatic tunneling to native IPv6 is not preferred by default per RFC 3484 geoff h- we can't hop over brokeness in the isps netowrk lorenzo - don't try and make pigs fly Tony Hain - it is insane to insist on deploying a transition technology half-ass, then blame it for failures.. Mark T - qualify statement, in a controlled environment we can hop over v4 netowrks Tony Hain - if the content providers deployed 6to4 on their end the path would be exactly the same as IPv4 door-to-door. 4) Happy Eyeballs: Trending Towards Success with Dual-Stack Hosts http://tools.ietf.org/agenda/80/slides/v6ops-21.pptx 14-Mar-11, Andrew Yourtchenko - changes add srv records section added mif reference added debugstrawman todo need more implmentations address hysteris problem need pluggable name based connect api... write a seperate draft for that? Where to take it? Fred B- The INT area. Jari Arko - yes Dave Thaler - Microsoft's pm's went to content providers, there is level of concern about multiple simulatnious connections and pontetially large number of resets. major agreement that problem needs to be solved. Can we do a better job about which one to try first? Maybe p could actually be fairly large if you had a good guess. Mark Andrews - happy eyeballs is a really generic problem with multihomed machines Janos Mohacsi - Agree with Dave Thaler: Some providers blacklisting clients with high syn and rst rates Fred B - some sort of memory about specifc addresses or prefixes Igor - I'm going to disagree with that sorry, as on operator I'll take the pain from happy eyeballs over the pain from not having happy eyeballs. Andrew - Feedback needs to be incorporated into the list Janos Mohacsi (jabber) - Agree with Simon Leinen. That is the correct solution as I have written earlier on v6ops mailing lists: RFC 3484(bis) can be used as a hint what makes sense and what is not. Dave Thaler - @simon: be careful, you need to it converge fast. starting with 0 knowledge for every s*d would be bad. That was my point about sharing knowledge so you guess right the first time almost always danwing - I disagree with Thaler, because a Happy Eyeballs user will _not_ be sending a lot of SYNs and RSTs. "P" prevents them from doing that. It's only the first connection that would be in parallel. Subsequent connections will continue to trend towards IPv6 (if it's working) or towards IPv4 (if it's working). And content providers have one, and only one primary job in life: deliver content. Happy Eyeballs is aligned with that goal. Which Igor re-inforced at the mic. 5) IPv6 Multihoming without Network Address Translation http://tools.ietf.org/agenda/80/slides/v6ops-10.ppt 6-Dec-10, presenter Satoru Matsushima - next steps? Fred B - Need feedback 6) Routing Loop Attack using IPv6 Automatic Tunnels: Problem Statement and Proposed Mitigations http://tools.ietf.org/agenda/80/slides/v6ops-4.ppt 14-Mar-11, Fred Templin- problem mitigations For zeroconf dynmic routing, we've come up with proposal that meets these requirements - out of scope for this group. Fred B - Ron asked us to do another parallel last call on WG (on the revised draft) while an ietf last call is carried out. adrew yourtchenko - Well, on approach keep decrimenting the hopcount if it gets below a certain threshold, then throw it out. 7) IPv6 in 3GPP Evolved Packet System http://tools.ietf.org/html/draft-korhonen-v6ops-3gpp-eps 9-Feb-11, j korhonen - updates since ietf79 work to make the draft more opinion neutral add operational aspects of v6only networks added ipv6 address configuration clarifications add ipv6 roaming conisderations adder inter-rat handovers Guillaume Leclanche (jabber) - Problem with v6 in the mobile world is that implementations are way behind the 3gpp releases. Which are themselves way behind IETF specs. J korhonen - needs 3316 recommendations Tina Tsou - about EPC, is it addressed here? Fred - Call the question, hum (is this a working group document) Joel J - hum in affirmative not noted opposition. Fred - Hum (in favor of wglc) Joel J - hum in affirmative of WGLC 8) NAT64-CPE Mode Operation for Opening Residential Service http://tools.ietf.org/html/draft-chen-v6ops-nat64-cpe 14-Mar-11, Gang Chen - uses requirements changes since 79 pcp upnp and nant-pmp are recomended with nat64cpe Fred B - we'd work on the requirements, the solution would be behave Gang C - we're generating requirepments Fred B- we'll have to take the adoption question to the list. dan wing - First half is a draft for v6ops, second half is a scenario in behave. Hui Deng - ? 9) Experience from NAT64 applications http://tools.ietf.org/agenda/80/slides/v6ops-18.ppt 7-Mar-11, Cathy - test enviroment description scenarios results dan wing - thanks for reasearch. It's easy to draw the wrong conclusion e.g. everyone has breathed air has died Some other examples are caused by ipv4 address sharing I realize this is the first generation of this analysis. in behave we have cgnat in nat444 analysis. We need to uplevel this to the spefic problems in nat65 that make this harder and or which can be addressed. Fred B - feedback and testing on the algorithm that behave has just produced Dan Wing - Failure needs to be traced back to a root cause, where can we help. jari arko - thank you this is important work Also want to emphasis on finding the root cause - different failure modes, some are in application there are some problems with the content, third class where there's something wrong with the nat64 or natpt device. Simon Perreault (jabber) - FYI: We're running a NAT64 experiment right now (SSID: ietf-nat64) with a survey to gather your experiences. Please try it. hui deng - We do need to analyis the issues that those applciations really have jari - it's going ot be a long task tina tsou? - two comments, mainly affected by the p2p applications? who supports nat64 couldn't find it on the market jari - there are vendors with this product already so do nat64 testing Janos Mohacsi (jabber) - to testers: http://ecdysis.viagenie.ca/ 10) Comcast IPv6 Experiences (no slides on agenda) 7-Mar-11, JOHN Brzozowski - trials starting in jan 2010 making determination of need based on volume Deployed 6rdbr performance base on proximity geolocation potentially impacted limited support/manual configuartion native dual stack l2 delivery geographically liimited trial backoffice support project started 4-5 years ago wes george - 6to4 world ipv6 day, 6to4 relays what will happen, we'll shut it off? or there are some relay out there that make it ok. John B - it's (6to4 traffic) gonna go somehwere Fred - could nullroute the anycast address Wes G - assuming the client behaves well in that case John B - trying to suck less, 6to4 relays fred t – use of isatap? John B- we use it internally, our focus is on the native aspect. dave thaler - In 6to4 trials did you run into issues casued by broken relays John B - Return path is still the problem 11) World IPv6 Day Call to Arms http://tools.ietf.org/agenda/80/slides/v6ops-9.pdf 14-Mar-11, tim chown - world ipv6 day call to arms aims issues unmanaged tunnels pmtu connection timeouts next steps do we influence the experiement? Janos M (jabber) - I support tims draft Mark A - we should harden this in advance of june wes george - we need to stop looking at htis as an experiment it's testing for primetime not influencing it is wrong headed Janos Mohacsi (jabber) - about 6to4: discourage for this experiment - 6to4 should be used as a interim solution - not what IPv6 should be used. Tim C - change Fred B - value is 2 fold it's y2k, it's also marketing dave thaler - yes we want to influence the experiment Igor G - I hate to say this but the expierment is to break the users and see how many get fixed the meaningfully data is what happens Lorenzo C- lets not try to demonstrate that we can do this well but rather recognize what problems we have and make them better Somebody may decide to leave this stuff on Igor G- Whatever hacks you deploy please leave them in place 2:36:55 AM jhf: in case they have proven to work well Mark T - deployment on v6 day as though it were more than one day capture that as prime directive Dave Thaler - mark said what I meant... we want people to think and do what they would do if this were longer term, and learn what happens and get experience Lorenzo - More relay won't help or hinder them and if you call that influencing the experiment, then we should. --- done Thursday 31 March, 17:40-19:40 12) Advisory Guidelines for 6to4 Deployment http://tools.ietf.org/agenda/80/slides/v6ops-6.pdf 11-Mar-11, brian capenter - Not going to try to put toothpaste back in the tube. People having been complaining about these mechanisms, this is an attempt to do something. Was not designed as an unmanaged solution. Filtering of protocol 41 is the main reason for these failures. Summary of issues Advice to vendors: * Do not enable 6to4 by default. * Do not do it from rfc1918 addresses (bug). * Return destination unreachable if you can't do v6. * Don't break protocol 41. Advice to transit ISPs: * Even if you hate 6to4 you can only make things better if you run a router * As a content provider running a local relay will definitely help if you plan to support ipv6 Randy B - 7th of june is too late. Tore (jabber)- The "defend against rogue RA" advice is equally important for ISPs that do not support IPV6 Tim Chown - Recommendation, internet connection sharing should use a lower default router preference. SwedeMike (jabber) - Tore: yes. if you don't support ipv6, just block all RA between your customers. Brian - Consider running them(relays) Wes George - Let me respond to that, end hosts are going to do whatever. 13) 6to4 Provider Managed Tunnels 13-Mar-11, http://tools.ietf.org/agenda/80/slides/v6ops-13.pptx Victor K - Level set, we still belive native v6 is the best solution. 6to4 is is challanging especially when covered by carrier grade nat. CG nat is already out there. There are legitimate uses of non-rfc1918 addresses behind CGnat. As noted it's low cost and can run on existing relays. Has been tested since Beijing. P2P with another 6to4 device doesn't work. Referrals to the address are challanging When behind the CGN it's(6TO4) is either broken, or it's not. Works for the use case we defined. Ole Troan - Still a symetric nat. 14) Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status 9-Mar-11, http://tools.ietf.org/agenda/80/slides/v6ops-5.pptx ole troan - Summary, makes 3056 and and 3068 historic. What is historic? If it is superceeded or made obsolete by another specification or no longer used. We are pretty sure that protocol 42 is not going through a lot firewalls. We are saying that this is a technology that the ietf will not evolve further. Wes george – we have to struggle with the definition of historic it's good to differentiate beween turning it off in the hosts vs turning it off in the relays fred b – precent for a widely used protocol being taken to historic, ripv1. Every cpe supported ripv1. Ripv1 had no context for cidr. That was not to say don't use it. Brian C - we should do both e.g. you can consider victor's and ole's draft at the same time. Ole t - I need this document for our linksys people Mark Handley - you stole my anecdote another certification body says do this ietf thing dave t - same thing as brian second point I likened it to two issues try to depricate different rfcs is less jsutification for 6to4 bc's presentations covered potential jsutification regarding 3484, if it changes that as well then the title needs to reflect it. Primary problem is for relays, what is fairly easy to do without code changes is to tell it not to use the relay. Tom chown - what do we use behind a host instead of 6to4 for connection sharing Igor G – guidance as to how to make it better, and oh by the way don't use it. because it's protocol 41 and it's everywhere p2p and relay are both broken Mikael A (jabber) - for me, 6to4 should go away asap, both the relay and the direct version jordi M - question of making the protocol historic vs the question of making anycast histoic. Ole T - have list of drafts for other protocols this draft says depricate the whole thing Lorenzo C - I hate to think of anything else going through it if it's this hard for us. Igor g – depricate 3068 geoff h - there are many ways that 6to4 can fail in the mehtodology I used, failures due to relays are not tested. The only failure I was seeing was really narrowed down to protocol 41 I can't measure the failures that don't get to me. Brian c - I don't believe that 3056 is broken, nobody deployed it. It's true that what microsoft did is that when folks use dns to rendezvous then you don't see much teredo. Tore A (jabber) - you will get 3056 between two end sites when the end users both have CPEs that implement it by default and send out RAs by default. and what happens then? the end hosts have 1) an IPv6 address - the 6to4 one, and 2) a default router - the CPE. this is a recipe for end-user brokenness. Geoff – whatver is going on in terredo the failure rate is right up there. Mark H - if we do something less than depricate everything we leave the door open, then disabled by default needs to also be in there. Igor G - in that spirit optional should be considered harmful and ill advised. James Woodyatt (jabber) - that would be going to far erik kline - +1 for depricating 3068 consider whether we want to save 2002 in global scope dave t (jabber)- without a relay 2002 is the same as ula erik kline - what is the status of ipv6 nat, 6pt is what I would be thinking of fred b - calling the question, this is my summary is this the recommedation we want to make? Do you believe that in general this is the way that we want to go. Hum, generally in favor, some opposition noted... for brian's draft yes for ole's draft yes for victors draft no fred - victors draft could proceed as an indivual submission lorenzo c - ipv6 day is not about deployment, we can't deploy it in two months it's about fiding problems igor g – if the drafts come out first it's useful ammunition mark handley – the bullets are nice and should be captured in one of the documents tony hain (jabber) - this decision should not be driven by intentional deployment in way that breaks it (6to4) 15) IPv6 anycast based feedback data aggregation 7-Mar-11, (not presented) 16) Scalability issues in CGN Address Sharing LAFT6: Lightweight address family transition for IPv6 14-Mar-11, Considerations for Stateless Translation (IVI/dIVI) in Large SP Network 6-Mar-11, http://tools.ietf.org/agenda/80/slides/v6ops-15.ppt ? - experience developed on recommendations from softwire. Communications scenarios, two major first ipv4-ipv4 for most current applications and ipv6 – ipv4 for p2p cgn brings a lot of cost enumeration of changes required by solution address consumption by solution punchline ipv4 address sharing is complex roberta Maglione - need a more scalable address sharing mechanism Randy b - shes correct dslite can easily go that path Basaraj P - where do you se stateless getting mediated Shin Miazawa – pros and cons of stateless divi it is still dificult to identify behavior nat 444 can do static mappings mark h – I'm a big fan of the stateless mechanisms, when they're possible, they're not always possible. Fred - would be nice to capture all this information in an internet draft-carpenter-v6ops Jari arko - in the int area we discussed stateless and aggreed to work on stateless (in softwire) Roberta M – motivation document in softwire is called stateless solutions mark h - not supposed to specify the actual bits, architeturaly both solutions are a tunnel divi or 4rd jari a - what mark said tina t - reduce the burden fo stateful translation fred - softwire is the a place to have the future discussion. 17) Multicast Transition to IPv6 Only in Broadband Deployments 14-Mar-11, http://tools.ietf.org/agenda/80/slides/v6ops-2.pdf tina tsuo - presentation end comments? thanks 18) Solution Model of Source Address Tracing for Carrier Grade NAT (CGN) 16-Feb-11, http://tools.ietf.org/agenda/80/slides/v6ops-20.ppt Dong zang - problem is the identification of end user through nat translation hostid is another potential example. Shin M - this is a cgn requirement and we are working that. Fred B- It can't be done here it's a protocol James W (jabber) – ietf policy wiretapping (28040 is relevant to this draft). Fred B - At a minimum if people do find this useful the question is where to do it. Chris M - we have lots of methodoigies to address this. Tina T - in the cgn enviroment this one connection may belong to different users as to the question fo whether this work is useful, I think it is useful and needed. In the case of a cgn it identifies thousands of subscribers. There are other use cases roberta m - this is a useful we need traceback, other use cases in the internet area. Shin M - this is a useful but not here, we have discussed it in softwire Randy B - you know who the you who wants to know who I am is (leo) Dan wing (jabber) - the draft is inaedquate to meet the needs of law enforcement Joel j – (channeling james w at the mic) 2804 applies in that it is out of scope to consider the law enforcement requirements igor g - while I'm not advocating this randy it does provide a more fine grained method. 19) Advanced Requirements for IPv6 Customer Edge Routers 5-Mar-11, http://tools.ietf.org/agenda/80/slides/v6ops-3.pdf lee Howard - state mechanisms for variosu technologies in which order they should be usd do we need to support multihoming? Requirements for the smart grid. Alain durand - pcp? Lee howard - didn't want to include things that are incomplete wess g (jabber)- pcp? Joel j (jabber) - port control protocol stuart cheshire - concerned that this leaves us with one layer deep routing randy b - not cheered by the topology contraint also 1812 in the router fred b - ipv4 should be a off the table I don't have a problem with ospf randy b - is worried about rip Tony H(jabber) - +1 to that comment Tom Herbst - One case is ula scoped addresses. Lee H - We want requirements as appropriate Lorenzo C - I kind of despise ULA in general but if we solve the topology problem with OSPF, then there's a boundary, once we've figured out how to given /64s to everyone, the ula works. Lee H - Take it to the list. Ole T - This document is supposed to be non-innovative Lorenzo please write the draft. Fred B - We're finished done