IPv6 Operations - IETF 77 Monday 22 March, 9:00 AM PDT Agenda bashing No changes Ê Discussion of RFC 5006 implementation and deployment September 2007, IPv6 Router Advertisement Option for DNS Configuration Recommended to move to Standards track Remi Despres Ð DHCP container; any stateless option relies on RA. Prefer a general scheme but donÕt object to making this a standard Jari Ð this specific RFC Ð should this move to proposed standard? Notwithstanding undertaking new work Dan Wing Ð agree Brian Carpenter Ð but it must be a revised RFC to move ahead Jari Ð new RFC number is required, but not any changes Work should be done in 6man Ê Recommended Simple Security Capabilities in Customer Premises Equipment for Providing Residential IPv6 Internet Service 18-Feb-10, James Woodyatt 3 years in progress Consensus for filtering like IPv4 NAT in IPv6 residential gateways Òallow outbound connections, deny unsolicited inbound by defaultÓ NATs call this firewall, although unmanaged What should the default configuration be? All the same NAT traversal techniques still needed Ð due to filtering e.g. STUN, TURN Special IPv6 considerations, e.g. block Teredo, allow IPsec -10 rev with some additional editorial changes and tweaks coming 4890 language on ICMP filtering Multicasting group boundaries Major discussion center on: Is it a good idea to have a default deny policy? This will be construed as standardization of IETF default Dave Thaler Ð inconsistent statements: not solving STUN/TURN issues, points out that the trust model requires a simple security box in the middle, and the host is required to do the hole punching. But Teredo blocked by default Ð prevents some kind of hole-punching bypass. James Ð Teredo is being sunsetted, so this is an exception to the hole-punching rule Dave Ð transitional Ð if IPv6 is available, incentive to drop Teredo. Not a security issue James Ð yes, the draft makes this clear, it is just a good idea Dave Ð host-specific relay, donÕt break connectivity for other hosts that rely on Teredo. James Ð if youÕre both an IPv4 NAT, and an IPv6 gateway blocking Teredo, there should be a Teredo relay in the gateway; either remove the recommendation to block or if you block Sam Hartman Ð block Teredo? Traffic to Teredo addresses? Or 3544 packets? James Ð Teredo formatted traffic as well Fred Ð distinguish between this and security Brian Carpenter Ð remove the requirement to block Teredo seems to be the consensus; per Mark Townsley Ð like to have transparency and the ability to turn off inbound filtering; need normative preamble Ð if you want simple security, do the recommendations of this doc Ð donÕt settle the debate Lorenzo Coletti Ð blocking Teredo will break applications that rely; are there increasing attacks in IPv6 deployments with default allow? Are they happy with that? Hate to make IPv6 less useful today, predicating inbound connectivity on protocols that donÕt exist yet. Remi Despres Ð millions of customers, no complaint on security, 2 years of availability. Default allow. Protections in the host. CPE doc would be most appropriate for hosts to observe. Should full-transparency be the default or a mandatory choice? Please do not regress to a world where we block transparency. Lee Howard Ð TW cable Ð default deny is good, donÕt trust hosts to protect themselves. Support the draft as is Ole Troan Ð cite this doc in our drafts Ð on by default is an operational issue; Bob Hinden Ð attackers go for volume, not looking at IPv6 yet. But as IPv6 becomes ubiquitous there will be more interest. Doug ? Ð IPv6 is appearing in malware at least in a small way Eric Ð does default deny help this Remi Ð at least in a small way Lorenzo Ð who are we trying to help? The user or the ISP? The ISP has the hammer to filter however they like. Users do not have a voice. James Ð important distinction between unmanaged and managed approaches Lee Hartley Ð not scalable to have the ISP manage the filtering Fred Ð rather than have 27 options and implementor choice, have two choices that describe default deny requirements and a second to define default allow James Ð modify the draft to remove Teredo statements, as well as forcing default deny Advanced Security for IPv6 CPE 8-Mar-10, Eric Vynke Open or not? Inbound traffic allowed, rely on IPS to filter inbound traffic to prevent attack. Signature based, reputation ratings, both from central service We all want open IPv6 Ð and the techniques are available Paranoid openness adjusted to meet the threats Ð do not break e2e model Positive feedback here and in security area Not much progress since IETF 76; Mark is a new papa, Eric not active Design team, aiming to make progress towards IETF 78 Ð maybe BOF. Bob Hinden Ð defining something like a Òreputation serviceÓ business model. Hard to do, tricky economics. What does this kind of definition mean to IETF? Eric Ð there are IPS systems that have some IPv6 reputation data Bob Ð maybe should be experimental Lee Ð need constraints on what reputation/signature providers can do. James W Ð echo Bob. Skeptical on rate-limiting; some apps are pass/fail on bandwidth, rate-limit is effectively blocking. May cause more interop problems that solving security Sam Hartman Ð not a detailed review yet, but have been following. Concerned that we are not ready on either front. The advanced security path is fruitful, not settled on simple security. If progress on advanced security, there should be a delay in publishing simple security Doug Ð hard to keep up in IPv4 already Ð IPv6 significantly more difficult. Bad guys move faster than we can track. By the time you analyze, publish and defend, they moved on. Some entity that can afford to publish. Eric Ð doable technically, there is a viable business model. There is always a window of vulnerability for day one attack ? Ð not solvable by the IETF Ð users and developers donÕt know how to be secure. IPv6 allows every attack to come from a different source address. Both drafts create breakage without real solution. May make things worse. Security Concerns With IP Tunneling 8-Mar-10, Suresh Ð started as Teredo only, now generalizing, move to intarea See slides for doc details Draft is paranoid and has strong language. Should this be softened? No position on whether/not to use protective methods Arms race Ð IPsec could be used to bypass policy, hard choice Recommendations for secure operation of tunnels Comments on v6ops list, can we get a thorough review? Eric Vynke and Fred Templin Ê IPv6 in 3GPP Evolved Packet System 24-Feb-10, Basic Evolved Packet System architecture Ð PtP link between UE and PDN Gateway. Access Point Name concept Ð piggyback on DNS admin Requesting adoption as a V6ops draft Fred Ð ? Ð informational would be good, but what is its status in 3GPP; has it had an official review in 3GPP? Could you add info about release 9, 10? Dave T Ð which doc defines gateway discovery, standards track? Already a proposed standard in 3GPP Jonne Ð not an official liaison with 3GPP Ð old draft about 3GPP architecture in IPv6 wg, seemed like a good idea to document the current state of the art. Fred Ð yes, it is an obvious value, but the question is whether it should be a WG doc Jonne Ð not necessarily a WG doc Thomas Narten Ð valuable, but not clear if appropriate for WG doc. Not necessarily requiring a formal liaison Spencer Dawkins Ð do we have the expertise? Does it make sense to do it here? Rajeev Koodli Ð valuable to have in some form Thomas N Ð the previous doc was advice to 3GPP Ð not clear Jonne Ð sounds like the consensus is useful, but not need to be WG doc Ron Bonica Ð AD sponsorship is OK, as long as there is v6ops imprimatur Raj Patil Ð there is certainly interest and knowledge here Mobile Networks Considerations for IPv6 Deployment 8-Mar-10, Rajeev KoodliÊ Mobile networks is a prime driver for IPv6 Looking at specific issues in deployment Focus on a couple concepts Ð Access Point Name (APN) sort of like a SSID End to end link is dual stack; LTE requires Òalways onÓ connection, accelerating IPv4 address consumptions Buy time with translation; promote/introduce IPv6 for provider own services and applications Jabber Ð smart phones already always-on in 3G. Rajeev Ð not a network requirement in 3G, but will be in LTE NAT placement issues, centralized vs distributed IPv6 transition points (see graph on slide) Ð v6 only network, v6 capable host, v4 only apps. If you can do this at home, may not be supported in roaming; all apps on v6 only mobile networks must use IPv6 Long tail challenge Draft updated based on list comments Is it possible to enable IPv6 in existing Mobile Nodes? Some may have IPv6 stack, but unlikely that providers have tested. More expected in newer devices Can pre-release 8 nodes provide IPv6 support? Experiments verify this Some input still to address Is this useful to document? Brian C Ð very useful doc, but not clear who the target audience is. Not directed to IETF. Clarify. ? donÕt see the difference between centralized and distributed NAT Ð common function Rajeev Ð it does matter to the network, particularly AAA. It matters where you place the NAT. Where the NAT is placed is the deployment model Ð centralized introduces single-point. Pros and cons. ? cable operators had this discussion Ð is there anything new here? 50 million people NAT scalably. Dave T Ð referring back to the previous discussion, what is particular to mobile networks, and how does this relating to the 3GPP architecture? Some common considerations, maybe should be merged. They are complementary, but things in common. Rajeev Ð this is more about deployment consideration, not standards; aimed at mobile operators Jonne Ð the other doc surveys what 3GPP says; this is more advisory. Not good to merge the two Ð different audience and use case for the docs Stateless IPv6 Prefix Delegation for IPv6 enabled networks 26-Feb-10, Teemu Savolainen Some delegation (6to4 and 6rd) depends on IPv4; do this in IPv6 Does not affect SLAAC or replace DHCPv6 Good feedback on list. Next steps Ð can a lightweight DHCPv6 server Tony Hain Ð possible benefits Ð network does not need to explicitly allocate prefixes Ð this is incorrect, there will need to be state, but still a good thing to do. Prefix length is implicit, need a mechanism to inform. Teemu Ð learn prefix through stateless DHCPv6 option Fred Ð this relates to 6rd and should be taken up by Softwires Routing Loops using ISATAP and 6to4: Problem Statement and Proposed Solutions 1-Feb-10, Fred Templin Two ISATAP routers on different links in the same IPv6 routing system can unwittingly loop; A does not know that B is a host or router. Attack on the prefix. Various solutions to detect the routers, check addresses, known prefix/address checks Future work: generalize to other automatic tunneling methods, Dave T Ð neighbor cache check Ð core issue is whether the destination is a router or host, explicit host tracking; in ISATAP RFC do initial reachability check on demand Ð more scalable. It is a MAY, should be strengthened. Friday 26 March, 9:00 AM PDT Jari Arkko IPv6 Deployment Guidelines Draft-arkko-ipv6-transition-guidelines Numerous deployment models, lots of new work on charters, confusion in the community on what tools are needed, how to deploy What are the most recommended/successful deployment models from IETF perspective Goals Ð deploy IPv6, retire transition mechanisms (after coexistence) Native dual stack Connecting IPv6 Islands IPv6-only core Unilateral IPv6 Benefits/challenges Points to standards track RFCs Dismissed/discouraged mechanisms Need a story like this Read through Alain Ð Ed J Ð support, willing to help, would like to see some success stories ? useful to point out difference for environments Tony Hain Ð all in one is challenging Ð success stories should be informational standalone documents Ð get them out asap Jari Ð big picture document Kurtis Ð what you can do, why choices are made is also useful Remi Ð 6rd (to be added in next draft) Marla Ð stay away from story time; references rather than in this doc Fred Ð high level presentation to the 3GPP forum, examples of ways that work Marla Ð give intelligence rather than the solution Ðhighlight choice Alain Ð list is too long and confusing, first apply sanity filter; also success stories might better be on a wiki or other references Emerging Service Provider Scenarios for IPv6 Deployment 23-Feb-10, Brian Carpenter Progress since last meeting Motivation Ð several years since IETF worked on deployment scenarios, many changes in requirements, softwire, behave, operator experience Skeleton draft in Oct, questionnaire in Jan/Feb, analyze and issue conclusions Allowed confidentiality, general questions on service, plans, technology choices 30 replies, enough for some valid analysis Self-selected and small group 66% European, remaining N America and asian/pacific Very largest did not indicate customer numbers Most offer stub and transit All access technologies represented Most supply CPE Ð IPv6 support is missing or partial Ralph Droms Ð just modem? Modem plus router? Brian Ð a range from aDSL box to full routers IPv4 lifetime Ð answers range from now to never 40% use RFC1918 internally, 20% offer to customers When are/will customers be asking? Planned date for IPv6: latest answer was 2013 Predict 2015 to be 50% IPv6 traffic 40% have IPv6 as a regular service 47% plan beta test in 2010 Dual stack routing is the overwhelming choice Dave Thaler Ð Teredo server or relay? Brian Ð asked about Teredo Server specifically, but the ? 1918 Ð still 80% are giving customer global IPv4 address? Apparently Little expectation that a lot of new equipment dedicated to IPv6, most do not see IPv6 as an opportunity to refresh Unable to support IPv6: CPE, Handsets, DSLAMs, routers (specific models), traffic mgt/load balances, VPN, firewalls Can it be field upgraded? Mostly unknown, little positive Prefixes - /19 to /48 Half offer more than one range; one 3GPP would like to be able to offer /126 or /128 Sri Ð they canÉ Lorenzo Ð it is not allowed in the specs Ralph Ð comparing apples to oranges Ð offering /64 is different than /56 30% have IPv6 customers preferring a PI prefix 50% plan dual-stack internal services IPv4 applications Ð a long time 90% say interworking is needed, but many donÕt understand the issues Hui Ð donÕt interwork with dual-stack Many donÕt grasp Suresh Ð still considering NAT-PT? worrisome Plans for Mobile IPv6? About 20% Frank Ð the mobility question? (just as written on the slide) Next steps Discussion point Ð can we extract specific scenarios from all this information Tony Hain Ð 50% by 2015 is a SWAG Ð is the question in terms of traffic, or number of customers covered? (question was worded in terms of traffic) this can be misinterpreted and mis-answered. (in reality it is quite unpredictable) Alain Ð what can we extract Ð not much. Small, self-selected, uninformed. Perhaps a survey under the ISOC umbrella would get a better response. Most surveys have asked the wrong questions. WeÕve learned quite a bit from those with deployment experience. Large providers have quite different problems. Lee Ð how might I use this data? I donÕt see a lot about why they made their choices, may not help me. Seems like every mechanism defined is being usedÉ Most productive way to move forward, the report on the questionnaire as quickly as possible. Separate out from scenario work raised by Jari. Alain Ð object to publishing as an RFC Fred Ð would like this to be made available Jean-Francois Ð concerned how valid, valuable to publish Gregory L Ð tried to do a survey on routing security. 30 is a large number Alain Ð not represented Eric Klein Ð number of customers represented is important Gregory Ð percentage of transit traffic Alain Ð could lead to bad decisions based on limited experience Fred Ð question: should the draft be restructured as a report on the survey? Seems to lean towards a factual survey report Unicast Transmission of IPv6 Multicast Messages on Link-layer 15-Feb-10, Sri Gundavelli Clarification on how to handle certain link layers 802.11 need to selectively advertise hosted IPv6 on a per-node basis Is it mandatory to multicast on layer 2? No requirement for receiving node to check. In 2464 (Ethernet) is it OK to transmit unicast? None of the implementations appear to drop RA as layer 2 multicast. This doc proposes clarifying that this mode is explicitly permitted Alain Ð does this help on a point to point where a middlebox might filter layer 2 multicast? Fred Ð in IPv4 in ARP, always sent to a broadcast MAC address. But in practices, only done if the specific MAC address is not known. Alain Ð this will help Dave T Ð no objection to this, but have trouble understanding the problem, seems to be allowed in the specs (unicast RA) anyway. Sri Ð combination of L3 multicast/L2 unicast Woj Ð just clarifies, make explicit Fred Ð review on the mailing list (4 volunteers) Asynchronous request: Dan Wing Ð can folks use the IPv6 NAT64? We would like to collect stats Neighbor Cache Protection in Neighbor Discover Protocol 2-Mar-10, Sheng Jiang Threats to neighbor cache Ð fill up with faked entries to DoS 90 byte minimal NS packet on 100Mbps link can build up 145k bogus entries in 1 sec Recovery can be minutes after attack Ð timeouts SeND is feasible but too heavy. No uptake Need a lightweight secure mechanism Ð NC protection only Minimize changes to existing ND protocol, no host changes on initiator Òreverse detectionÓ Raj Ð 4861 section 5.3 has some approaches that help to purge and take care of this problem. I donÕt think this is a pressing problem Alper Ð can the attacker fill the cache before the timer expires? Fred Ð treat like a SYN attack Alper Ð but the high speed cache would fill ? why do you say SeND is too heavy? DonÕt need certificates for NS, only CGA, donÕt need trust infrastructure Sheng Ð CGA is itself heavy, key exchange, size of key, PKI; so far little use ? Ð ways to generate CGA in advance Sheng Ð theoretically, SeND could work, but show me who is using it? Suresh Ð what can you protect against? Pinging non-existing addresses (ping flood) would create NC entries Sheng Ð protects the router Suresh Ð not clear that this protects against ping flood from off-link attacker Fred Ð looking at the whole set of SYN-like attacks? Suresh Ð not enough to be worthwhile Mohsen Ð intention is good, concerned that a bunch of lightweight mechanisms for parts of ND might be less scalable and manageable than SeND Sheng Ð no changes on host; protects against hosts that donÕt do SeND; Albert Ð mechanism achieves same thing in the ND RFC Ð reachability determination before ND is complete. Seems this addresses an implementation bug rather than a bug in the spec. Implementation should protect against DoS. Sheng Ð another interaction between the router and host Albert Ð NS/NA before complete; state machine needs hints that the NS sender is a live Kurtis Ð encourage input/text on the list to expand the scope Bob Hinden Ð one of many bad actor attacks Ð there are many more, easy, if you are on the LAN doing bad stuff. Too many things you can do if you are on link. Better to secure the LAN. Fred Ð SAVI working group Dave T Ð assumes you can prevent MAC address spoofingÉ DHCPv6 Prefix Delegation as IPv6 Migration Tool in Cellular Networks 16-Feb-10, Bechet Sarikaya 3GPP/IETF workshop Ð beneficial to employ prefix delegation, but not part on todayÕs 3GPP standards Devil is in the details Ð this draft intends to do that Ð how DHCPv6 PD can assign prefixes longer (correction - shorter) than /64 and multiple prefixes Most MN need /64, new cases require shorter prefixes, can be done with DHCPv6 PD Intended status in BCP helpful to operators Ralph Droms Ð good to get DHC WG review; based on the presentation confusion on how to use DHCPv6 PD. Joinen Ð seems you are trying to fix 29.061, IETF not the right place, do that in 3GPP. Bechet Ð allow them to reference this document Joinen Ð duplicate effort Bechet Ð we should encourage proper use of this Fred Ð review with DHC, discuss with 3GPP Ole Troan Ð how does this compare with Suresh draft? Suresh Ð ditto. Also what is the Òbest practiceÓ you are trying to define? Fred Ð prefix redelegation should be discussed in 6man as well Tony Hain Ð if the mobile node is a router, there is nothing unique about this. A mobile node is a router, PD to router is defined. Bechet Ð NEMO PD draft Joinen Ð some confusion in this draft Stateless Automatic IPv4 over IPv6 Tunneling: Specification 31-Jan-10, Naoki Matsuhira IPv6 backbone, IPv4-only stub network, dual-stack stub, IPv6 only stub SA46T embeds /24 of IPv4 address in the low order part of a /120 IPv6 Dynamic routing protocol without modification SA46T /64 includes the IPv4 ÒplaneÓ Alain Ð this would be covered by Softwires Randy Ð no limit to what Softwires believes it covers SA46T prefix + IPv4 Network Plane ID\ Several advantages Applicability Ð IPv6-only Campus Ð transitional scenario IPv4 VPN over IPv6 backbone IPv4 address reuse Alain Ð issue multiplies the routing table size by 4; only local to enterprise, ok. To bail out VPNs will be expensive Randy Bush Ð no protocol change here, IANA prefix. This is an operational practice. Dave T Ð Kind of like 6rd. inject a /120 as a routable? Brian C Ð interesting notion: a way to identify an IPv4 addressing realm by an ID, referrals etc. globally unique Kurtis Ð AlainÕs point Ð operators often inject lots more routes Fred Ð seems like this makes some interesting assumptions like IPv6-only backbone. Theoretical and important somewhere down the road, not a current problem. Responsive to a service provider issue having a large number of IPv4 domains around their network Alain Ð Softwires mesh considers this problem; bring this to Softwires to explain how this is different, in IS-IS, non-BGP space Fred Ð suggest continuing in Softwires Stateless Address Mapping (SAM) for Softwire-Lite Solutions 1-Mar-10, Native IPv6 over IPv4-only CPEs Softwires Extension to 6rd to allow unmodified CPE to provide IPv6 service Host support for 6rdE No relay like Teredo; native IPv6 vs Teredo address NAT does port forwarding The host knows the port mapping Intra-site and extra-site tunnels Goes further than 6rd. stateless, constructs address to use shortest path How the host obtains the parameters? Well-known server, DNS, etc.? Experiment involving SAM Presenting this in Softwires at IETF 78 Dave T Ð static port forwarding? Or dynamic? Remi Ð both. Dave Ð not what a NAT would normally do, some kind of static port forwarding Remi Ð yes, permanent Dave Ð end-point independent mapping. Site-to-site. Assuming an open case. This is the static port forwarding Shane Amonte Ð who owns/operates the SAM, NAT, the remote SAM? Remi Ð the ISP configures the border relay (remote SAM). Host implements the local SAM; unchanged CPE Alain Ð tradeoff between the host change, CPE change. Issue Ð manual configuration is required, unlike 6rd. in some cases this is a show-stopper. Remi Ð the NAT could include some port configuration support already Advanced Requirements for IPv6 Customer Edge Routers 8-Mar-10, Ole Troan Punted on any contentious issue on the base spec Phase 2 Ð nothing innovative, but clean up the issues left unresolved in base by documenting solutions Some requiring some substantial work Either basic requirements enough (declare success) or move forward Alain Ð what does NAT64 mean? Ole Ð if the gateway supports IPv6 should it support NAT64 Alain Ð donÕt see the use case Lee Howard Ð support further work Woj Ð who is the target audience for this (additional) work?\ Fred Ð same Ð CPE router vendors Woj Ð has it reached that target audience? Fred Ð some have read it Ole Ð access layer specific SDOs are specifying how CPE should work, retail CPE vendors, etc. Alain Ð if the first one was useful, then this would be. Reasonable to go back to pick up the residual work Woj Ð this goes beyond the basics, to new hard problems, delegation Jabber Ð support Fred Ð if we continue this effort, identify the areas that need work, direct to the appropriate working group. Work with them to develop a set of solutions. Ralph Droms Ð curious whether interactions between this doc and homegate effort has been considered? How to work through? Has it been discussed? Ole Ð interim meeting in Parish Fred Ð tried to send this to Dave Oran homegate Ð but he would like to see v6ops continue this Mark Townsley Ð if it leaves Òhard stuffÓ out it should make this more clear. Fred Ð hum indicates interest in continuing; discuss with Homegate, contribute to design team Ranger, VET, SEAL and IRON Fred Templin Ranger architecture for IPv6 routing Border router discovery Only border routers are modified Route optimized path where routing overlay is not possible Extra encapsulation SEAL helps MTU discovery accommodate this encapsulation Internet Routing Overlay Network (IRON) routing research group Started with ISATAP Ranger RFC 5720 and other RFCs ? how does this scaling; similar to flow-based routing, which does not scale to internet Fred Ð IRON prevents the more-specifics from going into the RIB. Redirect. Like NUD, only in the FIBs of the router that needs Tina Ð use SEAL how can the ISP trace the user? Fred Ð 48 bit sequence numbers prevent attackers from injecting; secret shared between routers at the endpoints. Sort of like SSH. Fred Ð with that we are done.