Note taker: Chris Grundemann Jabber: Jason Weil تIPv6 Operations - IETF 92تتتتتتتتتتتتتت Wednesday 25 March, 13:00 Agenda Bashing ت- No bashes Chairs Mea Culpa, draft-ietf-v6ops-cidr-prefix needs to go to WG Last Call IPv4 as a service: Fred B - We're going to look into this Joel J - Number of possible topics, some may require re-chartering, work in other groups etc. draft-ietf-v6ops-design-choices: *Philip Mathews (Victor K is remote) Changes -03 to -06 (Honolulu to Dallas) Narrowed scope to routing-related design choices for dual-stack and IPv6-only networks Added security considerations, contains pointers (nothing new) Many document design changes (not substantive) Fred B - Who has read the draft? [several hands up] Who has issues? [no hands] Philip M - Use of "unnumbered" was objected to Possible terms offered on mailing list, 6 options on slide Let's discuss Mike ? - Not unnumbered, anything else, I like #2 PM - what would the inverse of link-local-only be? FB - The converse would be around the "only" bit Mike - The interface doesn't have a number, it has an address At least six people said link-local-only Lorenzo Colletti - why are we talking about this? I propose sheepskin. Using english only is exclusive FB - sounds like convergence on #2 link-local-only yes - hum no - almost no hum draft-ietf-v6ops-pmtud-ecmp-problem *Joel Jaeggli is now a wg doc we went through the entire document we had some useful commentary like looking for planets, the more we look the more we see folks working around this issue (multiple solutions) CloudFlare is one, they've been asked for text - will rev doc, looking for more inputs from different networks with unique challenges some problems are not specific to IPv6, may produce work - possibly in this doc but likely elsewhere FB - mic open no discussion JJ - there will be one more revision soon, then we can go to last call FB - is this doc ready for last call after that rev? hum not ready? almost no hum IPv6 deployment in a developing country, with MAP-T Trials *Suprita Sah http://tools.ietf.org/agenda/92/slides/slides-92-v6ops-1.pdf FB - I invited some talks, Suprita is involved in a deployment in India they asked APNIC for a large amount of IPv4 to address a billion people, got 1024 addresses she is dealing with a problem that many of us may soon face Interesting to see what happens in a developing country also specific to IPv4 as a service she is an ISOC fellow to this IETF SS - overview of IPv6 deployment in India (slides) FB - clarification, what does "IPv6 is Enterprise ready" mean? SS - the backbone / transit network, not towards the edge [continues slides] Operational considerations http redirection (with an address literal), MAP-T better than MAP-E. Redirect should happen at SP entry point, not edge. Ian F - can you clarify the problem, I haven't seen the same, what architecture? SS - early stages, we're trying many too much content on IPv4 home gateway support a problem, low cost units with IPv6 not in production MAP-T was not a standard when we started, no longer an issue Mat J - can you provide a link to more info? SS - in person JPNE MAP-E deployment *Akira Nakagawa http://tools.ietf.org/agenda/92/slides/slides-92-v6ops-2.pdf Japanese solution is different than other countries, we are not really an ISP but basically the same IPv6 history in Japan: 2000-2001 leading companies started but not deployed 2011 NTT East & West started IPv6 on access network (they don't have a backbone), that's the start for businesses in Japan Many ISPs use the NTT East/West access network to provide IPv6 (coupled with their IPv6 backbone) Japan is now at about 5% IPv6 as measured by Akamai Many Japanese companies are high on the IPv6 measurements list from ISOC Four groups of network providers in Japan (see slide) NTT E/W with ISPs are majority, others include telco, cable, and power companies IPv6 deployment rate of NGN (NTT E/W) - close to 7% rate of second group - KDDI 99% / CTC 64% FB/LH - Do these customers all use IPv6? AN - yes FB - they have IPv6 CPE at the customer? AN - yes LC - yes, they do use it, see Akamai and ISOC numbers AN - reading status from slides FB - are you saying you have to use DPI to do traffic engineering on a tunnel? AN - yes continues slides Ian F - what protocol are you using for CPE provisioning? AN - not disclosed Michael ? - Have you had any complaints about poeple not being able to use protocols other than TCP/UDP AN - no complaints SS - how do you identify subscribers without logging? LC - mapping is deterministic with MAP-E can I use ping? FB - can you use protocols without port numbers? LC - I only care about ping Ole Troan - yes you can, outbound ping and reply works ?? - so you have two classes of customers, some that are not behind MAP-E? AN - yes, all new customers are on MAP-E and we have had no complaints slides continue LC - how many ports do you give? AN - confidential LC - do you disclose to your customers that they are not being provided with an IPv4 address? AN - we tell them we provide both we don't tell anyone about the number of portsت FB - most folks wouldn't understand the description of an IP address and ports anyway AN - continues slides ?? - Are you working with Japanese content providers to provide AAAAs? AN - we hope more will soon LC - there are complaints from customers on their support page OT - any time of address sharing you will have problems MAP can provide plain/legacy IPv4 service AN - continues slides (summary) FB - your last point could be summarized as "if you plan to transition, transition helps"? AN - yes MAP-T and MAP-E deployment in CERNET and China Telecom *Xing Li http://tools.ietf.org/agenda/92/slides/slides-92-v6ops-3.pdf we're using all three MAPs (MAP-E, MAP-T, and MAP-DHCP) two backbones, CERNET is IPv4 (20years old), CERNET2 is IPv6 (10 years old) more recently we added translation between the networks, origin of MAP-T somewhat modified implementation of MAP-T, less CPEs than users [CERNET deployment slide] Ian F - do you require logging to have traceability for users behind the multi-user CPE? XL - continues slides (question taken off line) multiplexing; ratio is number of users per IP, graphs are UDP and TCP lots of UDP traffic because students are using Google DNS to avoid the Great Firewall Traffic; about 1k users per IPv4 address China Telecom; joint project, using DHCPv6 exactly as in draft mentioned in early slide we are using a very cheap CPE, about $16 openWRT based Use MAP-T by default, but if you see IPv4 options DF=1 and MF=1, switched automatically to MAP-E. Detected at CPE based on traffic (DPI) If all users in China are put behind 1000:1 MAP, we can get to 90% penetration with existing IPv4 address space LH - have you done comparison studies (between T & E) XL - not yet SS - do you need special CPE support to do the T/E switch? XL - yes SS - was it easy to implement? XL - we wrote our own code FB - sounds like an experience draft XL - yes a standard is not needed SS - even at that ratio we can not support enough users ?? - did you have any experience with heavy data over UDP? XL - yes, we've seen UDP video work no problem Mukom T - you do checks per-packet, do you have data on the capapbility/scalability of that check? XL - less than 1% of the packets are switched to encapsylation there is no performance impact because with translation we are already looking at every field in the header FB - we can move short talks forward or talk about IPv4 as a service conversation LH - were these non I-D talks helpful? hum Meh? almost no hum Matt ? - I think we'll see dual-stack clients will see better service than IPv4 only LH - we did a panel with measurement results recently, 15% lower latency on IPv6 vs. IPv4 M? - I meant port exhaustion more than performance LH - IPv6 is a pressure valve for CGN GH - there is an overhead in setting up a binding in a NAT, that can cause the initial SYN packet to get delayed once a binding is in place it's faster the hard part is finding that time delay remotely (affected by too many variables) LH - I'm not convinced its just first SYN GH - the first SYN is much longer, for me the others are kind of OK LC - Google has a lot of data on IPv6 performance and all of this is dwarfed by other variables (peering congestion, etc.) I expect a CGN to work well until it fails, reliability issue rather than performance perhaps there is bad load balancing going on, because IPv6 is only 5% of traffic M? - still worried about another problem; random subsets of things don't load, on reload other things don't load Dan Lambert? - the delay is coming from software NAT and is milliseconds for CPE devices ?? - we've done performance studies, IPv6 is worse than IPv4 due to missing IPv6 content caches JJ - my port overload NAT can overload your port overload NAT, making lots of API calls can show this LC - how do you see IPv4 port exhaustion; you force... // or you can factor... there's always a spike, look at the difference in the height of that spike to know how many sessions are failing IPv4 as a service LH - what do you think? ?? - there is already an RFC for ops guidance on DS-Lite LC - great idea as long as we have authors giving deployment experience have real deployments (not test, large, etc.) we need more than 100k users on the tech before we can provide real guidance ?? - will we also give selection guidance? FB - I don't know that we can gain consensus ?? - there are documents like this in progress in softwires Eric Cisco - I would like to see the same topics/structure in each guide FB - I'm going to send an email to the list to ask what we want covered in that document