IPv6 Operations WG Meeting minutes - IETF 79 Please register opines on Drafts presented during the meetings using the Survey Monkey: Wednesday's Agenda: http://www.surveymonkey.com/s/KJY9WNS Friday's Agenda: http://www.surveymonkey.com/s/2PRZB9B Survey closes Friday the 19th of Novmeber and the results will be sent to the list. Note takers Ed Jankiewicz (scribbing) Joel Jaeggli (jabber) -------------------- Wednesday Nov 10 9:00-11:30 -------------------- Agenda bashing Straw Poll regarding Wednesday drafts:
http://www.surveymonkey.com/s/KJY9WNS Note Well Agenda bash Packed schedule, please move along 1 Happy Eyeballs: Trending Towards Success with Dual-Stack Hosts 2 Opening TCP Sessions in Complex Environments 3 IPv6 Multihoming without Network Address Translation 4 Advanced Requirements for IPv6 Customer Edge Routers 5 CPE Considerations in IPv6 Deployments 6 Network signaling for IPv4/IPv6 protocol selection for end-systems 7 Non-Managed IPv6 Tunnels considered Harmful 8 6to4 Provider Managed Tunnels 9 IPv6 AAAA DNS Whitelisting Implications 10 DHCPv6 Prefix Delegation as IPv6 Migration Tool in Mobile Networks 11 IPv6 in 3GPP Evolved Packet System * Happy Eyeballs: Trending Towards Success with Dual-Stack Hosts 25-Oct-10, Goal is to keep users happy with IPv6 so they do not abandon. First hits on IPv6 search is how to turn it off. Easy to break things, tunnels, peering, IPv4 responsiveness better, islands Proposal: probe, learn, quick fallback Current behavior leads to 20 sec delays when things break. Probing: dual thread, simultaneous attempts Learn: which works first will be preferred in the future Fallback: quickly and reset on new attachment Experimental in links browser Delays multiply with rich content from multiple sources Remi Despres – fully support Ted Lemon – extra complexity to eliminate extra SYNs, premature Sheng Jiang – don’t like title – go to apps area, Dan – moving from v4 to v6 without harming user, SCTP and TCP separated Brian Carpenter – referrals in Apps area, they would love us to solve it. Dan Mohsen - internet=web for users; this improves user experience. Keep going Colin Perkins – support, avoid too many connections at once, pacing important Fred Baker – TSV area randy stewart – SCTP implementation, zero delay for multiple attempts H? – multiple probes through stateful devices? Studies? Dan – not yet. TCP does this all the time. Problem may be overblown by transport people, reality is
H? – change over has a delay too? Dan – encourage it to be shorter and tighter, not full TCP timeout. Encourage apps to run a timer and tighten. H? – oscillation? Dan – further study. Fred – rather than polling on each draft, see surveymonkey polls and give your opinion and guidance. Any emerging consensus will be discussed on list. * Opening TCP Sessions in Complex Environments 18-Oct-10, Last night in TSV area RFC 5461 – response to soft errors; maybe they will go away, but ingress filtering, probably not How would you test the start time in Happy Eyeballs? Draft test plan V6ops – better ideas in TSV? Otherwise let’s adopt Dan’s draft * IPv6 Multihoming without Network Address Translation 26-Jul-10, Presented before, reporting activity in other WGs Also applies to v4/v6 multihoming 6man adopted 3484 update and DHCP option, addr-select MIF working group route info distrib and server selection drafts; added to MIF charter Pre-populate host, or feedback from the network. Questions? Comments? Joel Jaeggli – any specific drafts we should review? Address selection Fujisaki – main challenge * Advanced Requirements for IPv6 Customer Edge Routers 25-Oct-10, Ole Troan – follow on work CPE requirements for smart power, following this Draft changes, added 6rd and dslite. Device profile, non-innovative referencing existing work. What is the home topology to generalize the simple CPE work? Chained IPv6 CEs, in v4 it is a multi-level NAT, in basic IPv6 it doesn’t work unless you do NAT66 Strong use case for this topology. Either say don’t do it or try to solve Use case 2 – add a sensor network in the home, separate connection to power grid Use case 3 – loop topology, multiple ISPs – self configuring? “routed” home problems Solve problems, optimize, one use case over the others? Self-configuring Firewall by default, but need to discover role (BR vs internal router) How to configure ULAs Several problems do not have currently documented solutions, so nothing to reference, does this limit the scope * CPE Considerations in IPv6 Deployments 18-Oct-10, Tom Herbst 802.15.4 zigbee Moving to IPv6 California – multiple million+ network deployments Also Australia IP on 802.15.4 – small MTU, fragmentation, mesh Routing everywhere, breaks subnet model Neighbor discovery is very different Requires L3 forwarding – have to be a router Consumer access to Utility Co data Results in multiple routers, from ISP and Utility ULA in the home area network; intrahome focus. Connectivity within the HAN without ISP Link-local is useless, can’t route through mesh – must use ULA The two routers create their own ULA sets, how to deal with? Need a routing protocol on by default Firewall config – many security issues, not sure of solution yet Multicast DNS for discovery; only defined for link-local. Need a larger scope, site-local multicast and ULA scoped responses Like to see this get integrated into other work in progress Ole – what does the room think ? did you consider rfc 5006 instead of mDNS? Tom – not a consensus Jari Arkko – connectivity – only access to power sensors within the home, not remotely? Tom – initially. If it is to be globally available, should be configured with global addresses. Jari – more considerations later. Dave Thaler – preference for limited scope, close to single router network. Homes work best with a single subnet today. Lots of consumer stuff assumes single subnet. What about ND proxy? Get the existing protocols to work. I want the topology to work, avoiding multiple routers, i.e. reduce complexity. Tom – the ND is very different in mesh network. Not really the same thing. How to proxy between them? Dave – still what I would prefer Mark Townsley – option three. Solve “routed home” rather than hacking to maintain a faked out single subnet model. Reality is multi-segment home, different media, home/guest network with routing between. Home network needs to evolve. Can’t work just sometimes – it has to work no matter how connected. Focused serious effort. Lee Howard – current CPE router draft is getting there, for this scope we need to solve the whole problem – this is getting more complex, and we need a problem statement to define the set to solve Tony Hain – disagree with Dave – need to go to 3. Ad hoc collection of today kind of works, vendor assumptions, we need an architecture, set of tools; avoid vendor conflicts Eric Kline on Jabber – what is the admin boundary? How does it know? Mark T – requires protocol mod; that is the problem Remi – support. Need a solution for item 3. I have a proposal. Third option applies to the simpler case. Maybe we provide a short term solution for the simpler case Kurtis Lindqvist – 1 and 3 are not in opposition, could do both, despite text in the draft Ole – two tracks can be done together Fred Templin – provider independent prefix. Stable, multihoming. IF we could get this Don Sturek - support for item 3. Liaison with Wifi this should be happening Ole – maybe a bar BoF, to explore solution space Mark – need a real protocol design effort beyond 3. Fred Baker – first need requirements to determine what to solve. Mark – number three actually just defines not solves the problem Dave T – homegate discussion led to “homenet” including both v4/v6 Jari – not just a requirements doc, need a solution. Requirements doc, how-to using existing tools, not clear we need a new protocol. Other places to do the work. Intarea, we should not create an effort here to redo DNS, routing, etc. they should look at. What can we do with current stuff? Most of what we need. Fred Baker – we are chartered to do requirements, but should Don S – should not solve the problem in v4. Too many devices Tony Hain – scope charter, historically v6 in existing networks. This is looking at structures in new topologies. Requirements in scope, solutions out. Treading on defining an architecture Fred – wait for homenet? Or prep in case it ever gets started Ole – we could do something on 1 to finish it off, in parallel on 3. Meet sometime to start work. Fred – general feeling (hum) this is the way to go * Network signaling for IPv4/IPv6 protocol selection for end-systems 16-Aug-10, Gunter Van de Velde Awareness of a particular need to have from a network operator perspective. Problem statement 4 vs 6 preference, such a tool would help A way for the network manager to prepare the network for full IPv6, disrupt the chicken/egg problem May not want to immediately start using IPv6 just because there is a AAAA End-system configuration RFC 3484 impact, application impact. How to signal preference or preconfig, network dictate, etc. Overlap with fujisaki, addr-select-considerations Do we want to do this? Brian Carpenter – not just a problem statement, starts into requirements as well. Not a bad thing. A host should be able to ignore this, to permit experimenting with IPv6. Real issue, good idea to address Dave T – yes, good idea. Overlap with 6man doc, does it make more sense to keep a separate doc? Gunther – different angle. Eliminate overlap and refer to the other doc. Dave – things that 3484 didn’t solve, and why you want to do something else. Colin Perkins – yes, good idea. A lot of equipment that will ignore this, how long to upgrade and deploy to make this useful. Real problem – needs significant penetration to be useful Fred Baker – how does this relate to Happy Eyeballs? Would that approach work? Gunter – Happy Eyeballs is one possible solution Dave T – this defines some problems that Happy Eyeballs doesn’t solve. Stig Venaas – there are cases where a manager might want to disable IPv6 entirely, could negatively impact user experience Joel J – in managed environments, these things happen today. Solutions exist, although not captured in protocol/draft form Fred Baker – should adopt as a WG doc – answer in surveymonkey poll. * Non-Managed IPv6 Tunnels considered Harmful 31-Aug-10, Controverse-o-meter What is a managed tunnel? Definition in draft End user has a contact to complain when connectivity not working. Security, performance and integrity are managed User experience should be like real native connectivity. Differential viewpoints of end user, enterprise and service provider. Noble goal of IPv6 Internet – as good or better than IPv4. Do non-managed tunnels do this? If not, why do they exist Early adopters, decouple readiness between infrastructure and application Not scalable Early adopters are happy with non-managed tunnels, but will not work for the mainstream Hard to provide managed service on an unmanaged infrastructure Content providers can’t offer universal IPv6. Complex white-listing to get around Wes George – should cover more recent events, multiple ISPs acknowledge 6to4 now. Better off the solution is to make the reality less harmful. If you are an ISP, drop in a couple boxes to make it work better, manage locally (at least in one direction) the content provider can do it in their networks (for the opposite direction). Saying “don’t use” makes it second class. Brian Carpenter – 6to4 plus anycast heresy is here to stay. More important to explain to ISP with Content Provider how to advertise good routes for 2002/16. Similarly for teredo. Yiu Lee – no control as operator, already in OS and home gateway. No way to avoid. Need a recommendation John Brzozowski – not expensive, not difficult to deploy 6to4 relays. Even with IPv6 content, the 6to4 path is not preferred. It would be dramatic to alter this behavior. 6to4 helps when IPv6 is triggered. Even the return path is not so bad. Broken home networks are problematic. The traffic is out there, even if you don’t do anything. Dave T – improved a lot over the last time. Controverse-o-meter is accurate, reduced the controversy. The observations are valuable, still controversy about what to do. Analysis is valuable, more discussion about what to do about it. Positioned to content providers, but non-managed tunnels can be used where no IPv4 is available. Need to keep that in mind Remi – problems are explained. 6to4 uses a global address, and is reachable. Don’t break this with translation. E2e transparency should be preserved by all means. Consider in solutions Mark T – less painful with happy eyeballs. If this is a WG item, we can work on it Fred T – opinion – considered harmful has negative connotations. Overworked and jaundiced term. Fragmentation is still with us. 6to4 Provider Managed Tunnels 22-Sep-10, Red box on every slide probably Some controlled CPE to include dual stack, ds-lite, 6rd. and uncontrolled CPE 6to4-PMT for the unmanaged IPv4-only endpoints. Can we use NAT66 prefix translation, just one tool. Pulling v4 routing into v6 not a popular option 6to4 relay is easy to turn on. Challenges, harms e2e transparency, common NAT problems. CGN non-rfc1918 can break 6to4. Real problem, last resort IPv6 connection. Not an option to ignore these customers. Wes George – corner case, CGN with routable space, breaks 6to4. One application where this makes sense to intercept the brokenness. I don’t support this as a general solution, but to target at that issue it is a good thing. Useful in that perspective Brian Carpenter – don’t like this, ditto Wes. Get the operators to deploy 6to4 relays. Keep content providers happy. But focus this only on the corner case this is the only solution Remi – does not meet the criteria of maintaining the current operation of 6to4. NATs and cascade of NATs kills IPv6. Solution includes stateless NAT66, still under study. Restrictions on subnets. Consequences of checksum neutral approach still under study. Ole Troan – apologies, I work for a vendor with 6to4 on by default, cannot be turned off. Can we characterize this as a way to make 6to4 work better. Return path. Victor K– use case for CGN environment. Last resort v6 Fred T – prefix translation – is it advertised by broker? Victor – real provider prefix. Provider aggregate Joel – Eric Kline – OSes depref 6to4. Is this last resort for IPv6 only? Victor – yes. Not a lot of work. Less support cost Mark Townsley – if you ask us to do this and give us enough money, we will do this. Don’t ask. This would be a distraction from more important problems. More 6to4 relays would be better than this. Hosts may be abandoning 6to4, so should be declining. Victor – v6 only endpoints may increase it Mohsen – don’t like, wrong signal to providers. Unserious approach to IPv6. You should tell operators they will face some pain Victor – hard to get v6 capable CPE, not an option to break things. Operators have real issues here Tim Shepard – slowly realizing how incredibly harmful this is. I have 6to4 addresses at home, in DNS. Customer opt out is good, but the ISP doing this would break my setup. Victor – easier to work with the clueful IPv6 users, rather than the majority with no idea on IPv6. If you go behind CGN you’d stop work anyway Lee Howard – this signals ISPs poorly. ISPs are already deploying IPv6. Fred – Dlink Joel – netgear. Look for the v6 ready logo. Way better than 2005. Victor – success rate of off-the-shelf IPv6 is low Tony Hain – this buys into a problem space that is not helpful. Creates a new set of problems due to NAT66, avoiding the most helpful thing, putting content on 6to4 as well. Hack that doesn’t quite really work. Wrong step Victor – experiments with real customers and endpoints, we will come back with those results. Report back in Prague. * IPv6 AAAA DNS Whitelisting Implications 22-Oct-10, Jason Livingood How dns whitelisting works, and why sites are considering. Implications, solutions, alternatives Access control list on the authoritative DNS server, determines whether you get AAAA back Doc lists a lot of downsides/risks. Primarily management burdens. Opaque and administratively challenging Advise users and help them solve Appropriate venue to house this document, and looking for feedback and comments Detailed reviewers needed Mohsen happy with this, clear explaination of implications. Continue here and/or DNSOPS. One possible conclusion is “don’t do it” it balkanizes the internet Wes George – advise users of IPv6 impairments, see another draft on how users report problems. More on the ISP side. Results in confusing messages, don’t blame us it’s the ISP problem. IPv6 test sites that might be helpful. Jason – 2011 awareness events Ron Bonica (via Jabber) – should be in v6ops Danny McPherson – belongs here, share with dnsops. Fragmenting the namespace, problematic. Important issue to highlight. Mark Townsley – Happy Eyeballs would help here. “google please do IPv6” Eric Kline, did it, whitelisting allowed them to do it. Good thing (now) but should go away. Kurtis – draft should ref happy eyeballs, de-pref on 6to4. Over time this will become better Joel – balkanization harmful, but something you just might do. Fred – surveymonkey WG item means the work should stay here * DHCPv6 Prefix Delegation as IPv6 Migration Tool in Mobile Networks 12-Oct-10, Not obvious how to do in a Mobile Network. Intended BCP for such applications SLAAC with a relay Prefix delegation per RFC3633 Stateful – MN starts, AR sends IA_PD Comments on the list, issues resolved, stable. Journi K. – SDO 3GPP; does the RA contain multiple prefixes? Bechet – one prefix is ok, but more than one should be supplied Journi – tied to one /64. Next slide, does the MN configure its own address based on the delegation? In 3GPP this is not the approach. Fix the text. (take to the list) F? agree with Journi concerns. Overall specification of PD in 3GPP is still developing. Postpone until that resolved Jonne - trying to document what is done or trying to make recommendations. Bechet – useful to make recommendations on how to use PD, regardless of customer Jonne- either late or early, depends on use of the document. * IPv6 in 3GPP Evolved Packet System 21-Oct-10, Developments since Anaheim. Access Point Name Bearer types include v4 only, v6 only and v4v6 (new in r8) Dual stack in a mobile device, before r8 needed two bearers, now a dual stack bearer R10 will include prefix delegation based on 3633 Fred – what should this WG do? Journi – AD track individual submission Fred – Jari is carrying it Jonne – burden on AD Fred – the WG can take on Please update SurveyMonkey. Continue Friday. meeting closed 11:35 ------------------ Friday Nov 12 13:00-15:30 ------------------ 12 Welcome and Introduction from the China Network Operators Group Dong Yan, CNNOG and CNISP 13 Framework for IP Version Transition Scenarios 12.5 Call the question: Shared IPv4 Prefix for Carrier Grade NAT deployments 14 IPv6 Transition Cable Access Network Use Cases 15 IPv6 Transition Use Case For a Large Mobile Network 16 IPv6 Transition Guide For A Large Mobile Operator 17 Use Case For IPv6 Transition For a Large-Scale Broadband network 18 IPv6 Transition Guide For A Large-scale Broadband Network 19 Naming IPv6 address parts 20 An Annotated Bibliography for IPv4-IPv6 Transition and Coexistence 21 NAT64-CPE Mode Operation for Opening Residential Service 22 Considerations for Stateless Translation (IVI/dIVI) in Large SP Network * Welcome and Introduction from the China Network Operators Group
 Dong Yan, CNNOG and CNISP Representative of CNISP and CNNOG
Welcome and introduce the orgs
China Internet Service Provider Union, national industry alliance
6-link IPv6 implementation program, conferences, promotion, magazine
IPv6 training with APNIC
CNNOG China Nework Operators’ group
annual meetings starting 2005
more technical than CNISP
6-link earlier this year, promotion and implementation
growing from one demo node to phase 2 – 6 nodes in major cities, 10 ISPs 20 Content
Baidu and others 
* Framework for IP Version Transition Scenarios
 18-Aug-10, 
 Brian Carpenter time to look at transition scenarios again, series of BCP or info docs
not protocol specifications but technical and general advice
not promotional or IPv6 for dummies, for ISPs ready to move on IPv6
definition of what these docs should contain, topics including transition and coexistence, legacy operations
not a deployment plan but
Is this useful
Jonne – went through this several years ago, not very pleasant. Hard to be detailed and still please everyone. All the work that has come after is despite that effort. This is advice for operators, but with our knowledge and granularity, leads to argument, lots of pages with limited utility.
Brian – lot of ISPs that don’t attend IETF and NOG, but they read RFCs. We have knowledge that they will soon need
Jonne – not necessarily the right place.
Mohsen Souissi – useful especially now. IETF is the reference and they look to IETF to do this job or they will be lost. Not intended to be standardized but a way to move forward.
Kurtis – talking past each other. Operators are pushing for various things, at opposition
Basaraj Patel – not all operators, but many are here. And do understand the IETF, options and specification. Toolbox is defined, they can pick and choose.
Marla – a little disgusted at the personal attacks. Service providers are at least doing it, it’s not going to be perfect. Trying to get everyone on the net. I support this, where do people go to get documentation, instead of creating new orgs do it here
Jonne – how to use and tradeoffs would be good. Long docs without knowledge of access systems, and redundant. Document the current transition mechanisms and how to make the tradeoffs
Randy Bush – if the docs describing the mechanism is insufficient, fix the doc. This group should not waste time discussing this is not 
Victor K – support this doc, a book would not vet through this group, operators are here and willing to put this work together. Mutual interest in getting everyone to IPv6. Complex multidimensional problem.
Fred – comment on survey-monkey * IPv6 Transition Cable Access Network Use Cases
 11-Oct-10, 
 Victor Kuarsingh Several use cases applying to cable access
Jumpstart IPv6 with IPv4 only use case – 6rd 
combinations of access network, hosts, pub/priv IPv4 address space leading to different choices of technology.
Is this useful?
Ed Jankiewicz – support this, it will provide a good example of the analysis and comparative evaluation of the Transition Mechanisms. And should be useful to other similar operators. Cannot provide comprehensive instructions to all, but some helpful advice on how to apply the tools. I appreciate what Randy said – but these use case/transition guides and Brian’s draft could be very good information about how to fix the fundamental specs

* IPv6 Transition Use Case For a Large Mobile Network
 18-Oct-10, 
* IPv6 Transition Guide For A Large Mobile Operator
 18-Oct-10, 
 Tom Taylor RFC 4215 started this use case analysis; several other drafts advance the analysis
LTE architecture
“IMS” multimedia service, applies to other distributed applications as well
for each use case, look at the prior and more recent work, and derive a proposal
IMS – media path is separate from the signaling (missing on slide)
RFC 4215 looked at several IMS scenarios, and it will be difficult to bring applications up to date.
Use of private addresses, NAT will get expensive with scale.
rewrite the doc to reflect the slide
Jari – comments to be on the list; any work here should also include the signaling plane, user traffic, IMS different drivers and difficulties. 6rd without IPv6 access network, easy to use without extra tunnels. 
Jari – how does this relate to work going on in 3GPP? Not to repeat the effort, but value-add
Frank – closer linkage to 3GPP docs would help. ICE is controversial, ref to 3GPP needed. On technical, stateless NAT64 doesn’t work in mobile networks due to SLAAC. NAT behavioral issues. Not the same issues in DSlite with DNS. Cleanup, would love one doc on this
Stephano – three related drafts on v6 in mobile, makes sense to combine. Two Tsou docs and v6 mobile.
Jonne – good example of the problem I brought up. Some of this is already done elsewhere, and 3GPP is already working on this. Joint meeting and progressing, no need to repeat here. If we don’t understand everything, guidance can be harmful. Leave it to the guys who know how to do this.
Jari – AD hat – cooperation with 3GPP on this, needs to interface with that effort, not stepping on the toes. Expertise should be put to the right effort.
Fred – please converse among the authors of the 3 drafts mentioned * Use Case For IPv6 Transition For a Large-Scale Broadband network 
 20-Oct-10, 
* IPv6 Transition Guide For A Large-scale Broadband Network
 19-Oct-10, Large scale broadband network. 
> 60M subscribers, fast growth, unmanaged CPE
IP and MPLS backbones
scenarios with new or legacy BRAS
Solutions evolve over time – dual stack backbone, to 6PE to v6-only
regional area broadband, DSlite, NAT64
does not yet consider issues of L2 access network
comments and contributions welcome!
Brian – looking at these two and the previous two docs, what do we gain from separating the scenarios from the transition guide? May be more user friendly to combine.
adding experiences 
Joel J – if ISP is growing so quickly the legacy is shrinking, maybe transition technologies are less important. Applicability, there are maybe 100 ISPs that meet the criteria, and these have much of their own capabilities
In developing countries, the knowledge and experience base is less. 

* An Annotated Bibliography for IPv4-IPv6 Transition and Coexistence
 25-Oct-10, 
 Ed Jankiewicz While Fear, Uncertainty and Doubt about IPv6 are still prevalent, it appears Ignorance, Denial and Blame are gaining on them. No reason to panic, but time to get working on IPv6. As long as we have IPv6 widely deployed before IPv4 addresses start to run out everything will be just fine…Oh. There seems to be a daily weather report about when IPv4 will run out. Maybe it is time to panic. See http://www.youtube.com/watch?v=eYffYT2y-Iw from Cisco Growth will be impeded by the need for coping mechanisms, some of which are not universally beloved. Lots of work in several working groups, we’ve gone from virtually no solutions to too many. At IETF 71 in Dublin, Oct 2008 in Montreal, lots of drafts emerge, so I pulled together a list to prepare. It seemed to be helpful at the time, then dropped. At IETF 78 there was another explosion of interest in transition, driven by some folks in the ops community, seemed that the bibliography might be necessary at this time. There are lots of ideas circulating, some overlapping and even redundant, and work going on in several groups so it is easy to lose track of what has already been discussed. See the draft for the “3 laws of coexistence mechanism” a way to evaluate and contrast the mechanisms. What is harm? Anything someone might write a “considered harmful” draft about. Do what you need to do within your network, but don’t negatively impact others’ net experience. Have an exit strategy – keep moving towards, promoting, enabling IPv6. Especially do not impede early adopters. And don’t reinvent the wheel. So what to do with this draft? Lee Howard – appreciate the draft. I’ve said “how can IETF help? Help less.” This draft indicates the problem we have – too many ideas, too much help.
Ed – it is a symptom.
Brian – please include a disclaimer that appearance in this draft does not constitute any official endorsement of the approach
Ed – as editor, I will make it clear that it is just my opinion, nothing official
Joel – this is more than just a bibliography, it is a curatorial effort, your editorial voice comes through, humorous at times. Several suggestions that it might be better to set this out as a web page or wiki. Discussion on the mailing list as to where the right home would be. * NAT64-CPE Mode Operation for Opening Residential Service 
 18-Oct-10, Destination server on private IPv4 network, with NAT64 Jari – interesting use case, not sure what is changed in the application. Any protocol, behavior changes? Only operational. 
Jari – within the scope of Behave docs, maybe a good applicability statement on it
 * Considerations for Stateless Translation (IVI/dIVI) in Large SP Network 
 25-Oct-10, Sun Qiang China Telecom Focus on how to deployment of translation in large ISP network.
dIVI – extension sharing public IPv4 addresses.
no need for ALG or DNS64 Lab implementation, dual stack host, global IPv6 address space and IVI address space Manual config in the lab Looking at real SP network deployment. Fred – what comments are you looking for? Randy – management of and by IPv6. This is the important point. What I want is feature parity, the rest is all noise and days worth of presentations
Lee Howard – please state your correct name
Fred – China Telecom – aggressively deploying IPv6, but keeping their business operational
Kurtis – most applications work? Specifics or classes of apps, per Jari talk
Fred – in China some specific enterprise applications (banks eg.) busily working with them to fix and accommodate
Tony Hain – is this really an informational document about an experiment, or is it saying the WG should do something else? Sun – both experimental results, and deployment considerations. Information for other ISPs Tony – maybe looking for the WG to validate the recommendations
 * Draft-weil-shared-transition-space-request-01
 Chris Liljenstolpe
 suggested in opsarea to bring this to v6ops, primarily a vehicle to support v4-only end devices on run out until v4 over v6 infrastructure in places We don’t like blowing stuff up on purpose NAT444 least disruptive, not ideal. Period of time Need a re-useable address block that will not conflict with 1918 space. /10 or adding up to /10 to be requested from IANA Not global private, don’t use in device configuration, most users will not see this Pragmatic, not pretty Tim Shepard – looking at old draft Suresh – all CPE use 192.168, some use 10.0.0/24 Telstra – plurality use standard addresses, small numbers use other ranges CanCan – why do you need to register a range? Why not cut off from your own allocation, CPE using net 10 is limited to US and Canada – China does not have the net 10 problem Chris – need some number of addresses to address CPE, need more addresses. We can make one request and reuse it, or make lots of individual requests CanCan – this is unfair, to take this space to solve your own problem
Chris – doing this separately will more quickly exhaust the pool Tim Shepard - /10 instead of /8 10.192/10 Chris – interesting to know how much of a problem that would be, test would be interesting Wes George – contradict your own justification, any use outside of this would be “off-the-reservation” there is a small number of SOHO router manufacturers, why not tell them they are currently off the res? Chris – they are not – you would be asking people to renumber Wes – need some real data to back up the assertion. It’s a big enough deal that we need clear data, proof why. Don’t understand the threat to ask for more space, you already have enough space for current customers, if you request IP space right now, if you could justify it why don’t you Dan Romanescu - IESG has a draft on the table, pending a couple discusses, that says don’t do this, straw poll in IESG. Soon to be an RFC. The IESG would object to this. Frank – different behavior with public/private address space Chris – Jari – how fast is not relevant. What does matter, impact afterwards. One area of concern is software with built in knowledge of 1918 space Chris – only between the CPE and CGN; other software shouldn’t see this Jari – potential for leakage. That area is more of a concern Fred – any specific products? Cisco has products with martian filtering Suzanne Wolfe – hope the IESG members are in these discussions now. This is a bad idea, but like so many ideas in the transition space, may have to live with this Mohsen – more than ten years we’ve been telling you to act on this; how do we know you will really go to IPv6 if you get this Chris – waiting for kit from vendors, we are moving ahead Lee Howard, operator. Well documented in donley nat444, why we really don’t want to do NAT444. Consumer electronics do not support IPv6, no way to get them out there. Getting from one home to another when IPv4, will not work. This is needed
Marla – author of the draft in IESG. Not really a recommendation, just documents the consequences. As to going to IANA, the whole world changed when transfer proposals were advanced. Transfer proposals exist, allowing commoditization of address space. RIR allocation was not justified before, and have not done that because of trying to be ethical. Instead of having all these folks go for their own /8, get one /10 that they can share. We are trying to get this moving, the writing on the wall has been there, but it is not easy. It is a human environment not purely technical. This is more kind to the whole community. ? echo, there are operators thinking about this that are not here today. We are where we are, it is a fair request, consider it on its merits and practicality. Dave Thaler – in a provider network, might have CPE management, others don’t. If the CPE has 6to4, the connectivity would break. Net PMP. Application SDK have macros with the private address space, so there is a danger of something bad happening. Chris – these are NAT444 issues to. Joel – these new addresses are not private use scope, so some apps might make the wrong assumption about these apps. Chris – NAT444 breaks all these things regardless of the address space. Joel – but they will assume they can us NAT64 Dave – danger that IPv6 experience will get worse. Running out of IPv4 should improve the IPv6 experience (hasten the day). With your own space it would be globally routable. The next group, VPN vendors have the same problem Chris – we know this will break things. Joel – breaks different things Wes – homegateway with 6o4 will see this Chris Donley – three things, shared /10, individual assignments >/10, squat on others all break Joel – individual assignments would work Wes – if you could meet the RIR requirements to justify more space you would have. Squatting won’t work due to transfer. Also holders will not yield space. Randy Bush – IIJ. Point that Dave made is germaine. As soon as this gets set aside, VPN users will grab it too. Zero sympathy from me. It was possible to deploy, laziness and greed. You are here because APNIC told you to stuff it. Tim Shepard – NAT444 is going to happen. As much as I dislike it. Sad. Can’t change history. Choice is NAT444 with in the middle with the address being the /10 shared space vs 10.192 space in the middle. My gut is that 10.192/10 in the middle would do less harm in the long run. Both of these are better than depleting the IPv4 faster. If you can use 10.192/10 instead, it will be less harmful. 1918 is compiled in; globally routable used as a 1918 is potentially very harmful. We really need to know this ? speaking as a private network citizen. Don’t want to go into how ugly, unfair, etc. but take another look at how address space is administered, 2500 or 200 or 50 Service Providers, can any SP justify this use to the RIR. If just one SP got this block of space, and decided to share it, this could be done Chris – then one RIR provides the space for everyone to use, may be an problem Jari – interesting politically, but not so significant. Per Tim’s proposal, subscriber should default to this set of net 10 addresses. How many break against that. Could compare with how things break with new space. If we had that it would be simple to decide. Can’t wait a year. Fred – netizen, map showing distribution of IP address space, looks like the night light map. The addresses are concentrated. The rest of the world uses NAT444. How? Joel – what is the frequency of 1918 usage? You can find this out from large providers SIP registration, and could be mined. Fred – can we call the question? Clear consensus, actually two, in opposition. Not an IETF consensus Chris – in ops, about 2 to 1 for, with strong objections. Jari – for myself, with the data discussed, use all means possible to answer the question of which would be less harmful. Without that data, big battle. Lee Howard – one of every gateway and see if it breaks Randy - Lars’ gateway work Chris – what is the distribution of 1918 space Randy – some bellovin work a couple years back Kurtis – India has less address space than being discussed, yet they are able to multiple NAT it Chris – bellovin data, SIP registrations Lee Howard, start with major CPE gateway vendors. Chris – some data within a month, but how/where to discuss Lee – once a major case that shows it breaks, that would probably end the research Randy – confused on IETF process, seems to be no consensus to do this here, how much more time Wes – please go through the entire space. Willing to accept smaller blocks that add up, if there are gaps, this is a long tail problem or not. Maybe some at the edge would break Chris – technically non-contiguous is ok, but a support nightmare. Fred – primary objective is to produce consensus where none exists. Getting objective data upon which a rational argument can be made Consensus call: if the data shows that this is the only option, would the group support having the operators do this Wes – there are other considerations besides the 1918 breakage, maybe we can extricate that out. We will look at a follow-up draft Tim Shepard – can you use 10.192 or some other block within RFC 1918. You as a provider may feel less pain with a block outside 1918, but will cause pain for others Chairs Request for hum showing support for (first) or against (second) this proposal were to to arrive as a draft? Not strong support for either position. given discussion so far would conclude that there is definitely no consensus. topic closed meeting adjourned 15:51:20 nov 12