IETF 85 V6ops thursday 1300 4 hour session, 10 minute break at hour 2 - Note Well - Document status three in Ron's queue three in rfc editor queue - agenda bash 11 documents on our agenda one doc from dhc that will be discussed here 1. Sharing /64 3GPP Mobile Interface Subnet to a LAN http://tools.ietf.org/agenda/85/slides/slides-85-v6ops-3.pdf cameron b - presented Lorenzo C - support, this work because the upstream is point-to-point Cameron B - specifically scope to 3gpp? Alex B - question of interoperability Jonne S - we think is is good document Keith M - this is way batter than nat. Eric K - what happens when the 3gpp context goes away. should be tightly coupled with ra timingi Bechet S - is this a standard tethering case? Joel J - Be careful around prefix size discussion Fred B - taking a quick hum. Several people want this as a working group draft. hum in favor (substantial) hum opposed (none) 2. NAT64 Operational Experiences 8-Aug-12 , http://tools.ietf.org/agenda/85/slides/slides-85-v6ops-8.pdf gang c - presented Philip M - change title consistent with other documents change to deployment considerations rather than operational consideration Fred B - you have another version coming - we'll take comments on that and if it looks resvolved perahps take it to WGLC 3. Enterprise IPv6 Deployment Guidelines 15-Sep-12 , http://tools.ietf.org/agenda/85/slides/slides-85-v6ops-9.pdf Lee h - presented -questions for the working group MTU size recomendations? Bechet S - 1500 Fred T - can't necessarily if there are two tunnels Fred B - would hesitant to set the mtu to low 2460 says minimum is 1280 Eric K - tests with large operators have more to do with avoiding fragments and less to do with available mtu Enterprise interest in deploying native? Lorenzo C - If you take out native the statement is meaningless. Keith M - Try to think of a reason why an enterprise would not deploy v6. Dual stack, where you can tunnel when you must? Alain D - Disagree with that statement. Fred B - Be careful with the arguement, I can never turn off v4. Keith M - Native support for v 6 is better than any transition. Brian C - It's important not to frighten network operators. Prefix size for a site? you may want to allocate less than a 48 Lorenzo C- Structure of rir assignment allows reader to reach this own conclusions. PI vs PA Philip M - do you want to multihome? Dan Y - +1 to these comments about including something about PI more in the context of multihoming Eric V - A firm with a network team? Victor K - these are considerations about routing implications Bob Hinden - not so bothered by the size issue Slide us NPT66 Fred B - provides no security whatsoever. if you're going to say that you have to address that you need to address ilnp Lorenzo C- my sense is that it's not widely deployed so you may have breakage Lee H - I think I have my answer of no consensus Tim C - do we consider SeND dead? 4. Internet Protocol Version 6 (IPv6) for Cellular Hosts 5-Oct-12, http://www.ietf.org/proceedings/85/slides/slides-85-v6ops-4.pdf Fred B - we're going to discuss both documents and what we should do with them Eric K - requirement 17. Don't do DAD. 5. IPv6 for 3GPP Cellular Hosts 14-Oct-12, http://www.ietf.org/proceedings/85/slides/slides-85-v6ops-7.pptx ? - will this conform to 3gpp specs? Jouni K - Uses non-normative language. Fred B - Let me have a little different discussion - try to figure out what v6ops wants to do in this area. Two sets of authors that belive this needs to be updated. Bob H − 6man updated the node requirements. Fred B - Hum do we agree that 3316 needs to be updated? Fred B - Do we want to have a working group document Lorenzo C - Doc 1 is a shopping list document 2 is a treatis on how you implment ipv6 on 3316. they're not covering the same domain Jouni K - Agree with Lorenzo - different objectives so they need to be treated differently Fred B - Thinking on my feet, lets talk about the first document. It's coming from a set of operators, do you find it useful in your environment? Eric K - How much of the first document would be left after the second document? Jonne S - The first one is operator requirments - 2nds one says this is how it should work . there is some confusion in the industry. Jouni K - With most of comments. first one goes beyond whats required from the current ietf or 3gpp specifications. Jari A - My motivation, we need to keep our specifications up to date. On the first doc, questions as to where it should be done? 3gpp transition mechnanisms where should that work be done. Bechet S - both of them are called 3316 update Gang C - At first I agreed they're complementary, I guess 3gpp they produced a technical report not a standard. Lorenzo C - Need to harmonize with new host requirements lets make a decision on the second one as a natural update of 3316. If we come to consensus on that as update, then we take the first document and add the chrome wheels and the spoiler. Fred B - Calling the question, we wanted to update 3316 is this document (2nd) 3316 update? hum(some) none opposed. Yes, we'll take you up on the offer for the resubmission of the 1st document with a new title 6. A Larger Loopback Prefix for IPv6 17-Aug-12 , http://tools.ietf.org/agenda/85/slides/slides-85-v6ops-11.pdf Presented by chairs. Brian C - 1:: is virgin space Fred B - Do we fell that a large loopback is useful? Hum - some in favor some opposed 7. Design Guidelines for IPv6 Networks 22-Oct-12 , http://www.ietf.org/proceedings/85/slides/slides-85-v6ops-6.ppt slide mix ipv6 and ipv4 Tony H - option a is braindead slide mix ipv6 and ipv4 Fred B - assume you've read michale behringers lla only draft? Philip M - I have slide - one or two ebgp sessions Rudiger V - less fate sharing in option b. ? - amsix considering option a new topic - seperate rrs for v4 and v6 Gunter V - As a pro for seperate is avoid v4 breaking v6 stuff Lorenzo C - Pption a has the advantage that the ops guys know where to look. Fred B - We're pretty close. K K C - I like the document Philip M - Would like to look at vpns, opsf vs isis Tim C - Will try again on address plan after this. Fred B - wg yes or no? (hum) some in favor none opposed resubmitt as draft ietf. 8. IPv6 Operational Guidelines for Datacenters 20-Oct-12 , http://www.ietf.org/proceedings/85/slides/slides-85-v6ops-5.pptx Fred B - comments ? let me ask this working group a question? do you like the direction? Dan Y - Yes Fred B - Hum: yes? none in room for take it up bake for longer. Philip Mathews - align DC and Enterprise message? 9. IPv6 Transition Technologies Selection using DHCP/DHCPv6 15-Oct-12 , http://www.ietf.org/proceedings/85/slides/slides-85-v6ops-1.pptx Wes G - wearing my sunset4 co-chair hat - this is a bigger issue than just around which IPv6 transition technology to choose. We've been discussing in sunset4 the need for a means to signal preference between IPv4 and IPv6 under the assumption that there will be multiple permutations of networks: some that offer IPv4 with or without NAT, IPv6, IPv6 with NAT64 and DNS64, DNS servers that only listen on IPv4, only on IPv6, or both such that happy eyeballs by itself may not make the right decision. I'd rather see us solve this problem of conveying preference based on the network's capabilities and offered translation services once, rather than multiple times for multiple use cases. Tony H - The focus has been completely myopic and biased toward lethargic network operators that want to tell the device what to do. there needs to be input from the applications side as well that balances the reality so that networks don't preclude deployment of applications that people actually use. As for the topic of focusing on dhcp, the problem statement appears to be broken in that it requires adding a new option to resolve the problem of inconsistency in current implementations. Philip M - we've identified that there is a gap. Fred B - it is fair to say there's limited support for this? 10. Why Operators Filter Fragments and What It Implies 15-Oct-12 , Why Operators Filter Fragments and What It Implies Joel J - fragment dropping is a different issue than breaking PMTU, goal is to document practice not define rational Ron B - document practice, maybe the why, maybe if the why's are valid documenting this tells folks that fragments are less reliable Brian C - no data in document, having that would be good RIPE study is quoted - 10% of paths drop fragments could use more specific/granular data Tony H - This is a time sensitive issue in that 15 years from now what constitutes a fragment is likely to be different. There is no justification for dropping them in IPv6. In IPv4 overlaps were valid, so there was an attack vector to protect against. THat is no longer true, so we shoudl document why the concept needs to go away. Lorenzo C - we filter fragments and have good reasons / we can; document problem, document reasons, document advice / advice won't work because we won't agree / reasons is out / as an ops group we have a duty to report what happens to others. Ron B: more information would be good DNS impacts? documenting the problem is good but looking for consensus on recomendations is better / can we solve the ops issues Joel J - educational problem Igor G - we fragment, we have reasons / lets document this with basic recomendations to break less Philip M: can those that filter tell us why? Igor G - this is a security issue, details would open attack. 11. Operational Issues with Tunnel Maximum Transmission Unit (MTU) 18-Oct-12 , http://www.ietf.org/proceedings/85/slides/slides-85-v6ops-0.pptx Ron B - If you had a signaling mechanism you could use it to just send smaller packets. Philip M - need a sense of how common this problem is. Fred B - We know a number of firewalls that does this intentionly or inadvertantly filter path mtu. Fred T - we don't control the wholE path so we can't wire up the mtu. 12. next presentation from dhc wg. http://www.ietf.org/proceedings/85/slides/slides-85-v6ops-12.pdf Eric K - I think this is a good idea Eric V - good thing to do, dhcp is not the right thing. Sheng J - It's frustrsting we bring up this issue in 6man -we have dhcp as a choice, 6man preffered it. Tony H - In general I agree with Eric Kline, but I would prefer to allow the host to at least inform about its preference as to what gets registered in DNS and with the firewall config, because it may only want to allow inbound on one address, which the network can't figure out. Lorenzo C - as a matter of advice, it's in your interest to have consensus. I agree with eric that doing this for security purposes is silly Tim C - you can also use savi Fred B - me speaking as an individual - wheter therre should be registration the protocol to do that is (i asume syslog) etiher dhcpv6 or ipfix Eric K - creating an auditable process Lee H - draft-ietf-dhc-addr-registration Tim C - we use snmp Lorenzo C - there is a use case you can scrape neighbor table - wouldn't be nice that we had a way to do that that was more reliable Meeting is adjurned.