minutes of BEHAVE Working Group, IETF74, San Francisco Chairs: Dave Thaler, Dan Wing minutes: Ed Jankiewicz ------------------------------------------ Session 1, Tuesday 9:00 ----- Agenda Several presentations on coexistence Milestone discussion Presentations and choices on NAT64 IP reminder ----- Existing Milestones SCTP – little review and comment; does not work over today’s NATs, but useful and want to make it work over NAT64. Anyone interested? One hand up. Jabber comment: one person gave feedback, Dan will follow-up Behavior-discovery, TURN in IESG processing New author for TURN-TCP and TURN-v6 NAT-ICMP in editor queue Chair requests review of draft-ietf-behave-turn-uri ----- Framework for IPv4/IPv6 Translation Fred Baker http://tools.ietf.org/html/draft-baker-behave-v4v6-framework-02 This framework, includes SIIT Update 3 other docs Scenario discussion has been going on, some revisions and more depth Service model: as transition proceeds, in v4 networks while turning up IPv6 increasingly difficult to get more IPv4 addresses. Building out v6-only, but need access to the v4 internet. Solution space is a stateful NAT64 – v6 initiated Only gets you so far – v6 servers generally available to the v4 world too Small number of v4 mapped addresses, using stateless SIIT variant, IVI NAT64 type 2 – IPv6 initiated between IPv4 and IPv6 network Scenarios and Solutions: Think of them as parallel networks DNS ALG separated from the translator box Translation Model: Embedded Address Format – prefix defined by network admin, /32../63 or /96 plus embedded 32 IPv4 address, perhaps between prefix and suffix, or even the low-order part Discussion later: LIR prefix vs well-known prefix Framework recommends LIR prefix Components: DNS Translator Stateless Translation (IVI) Stateful (NAT64) Translation gateway technologies Questions on Framework Alain D – may apply to the home, please clarify that this does not help v4 legacy home devices; yes, this deals with v6-only extensions of your network; Alain – how does a v4 device in the home talk to a v4 server outside the home? Fred – not address at this time. Alain – Complementary to DS-lite? (Fred shrugs…) Abstract Update to SIIT plus a description of the stateful mode Translation Model – v6 on one side, v4 on the other, separate DNS Stateless mode: within the v6 routing domain, the mapped addresses can be normally routed. In v4 domain, advertise a set of prefixes that attract the traffic Dave Thaler: SIIT over-constrained the address prefix; as long as there is an algorithmic method and essential constraints; keep it generic. Several agreements at mic. Terminology – tighten up. - IPv4 embedded IPv6 Address - IPv4 related IPv6 Address Specific issues - UDP checksum optional, for IPv6 MUST calculate checksum; this should be under configuration control, i.e. some tunneling paradigms allow a net admin to permit UDP with zero checksum Comparing stateless/stateful - Stateless 4 to 6 algorithmic assignment of IPv4-embedded - Stateful destination is based on the state to derive IPv4-related - Stateless 6 to 4 – algorithmic - Stateful table lookup or creation for src address; session cannot be initiated from the v4 Christian Vogt – Charlie Perkins leveraging DNS entries to allow v4 initiated; to be discussed tomorrow. Fred – next step perhaps, but that was one of the weeknesses of NAT-PT Philip Matthews – preserve the independence of this solution; too early to go down that path ----- NAT64 Marcelo http://tools.ietf.org/html/draft-bagnulo-behave-nat64-03 Stateful Translation Update, recent decisions, next steps IPv6-only host initiate to IPv4 server Request AAAA from DNS64, if none, try A record and synthesize AAAA With synthetic AAAA goes through NAT64 translation to the v4 server Some content but a lot of work to do; timeline is the rest of the year Need decision on Prefix64, One basic spec to progress quickly - UDP - TCP - Fragmentation - ICMP - Endpoint independence Next steps; other features in other docs - SCTP - DCCP - IPsec - FTP ALG - Alternatives to endpoint independence Alain – FTP ALG issues come up all the time – want this moved up to mainline Dan Wing – about 30% of FTP servers don’t handle EPSV, need to handle Iljitsch – Alain, what do you need passive or active? Alain – the end-user should not care, it should just work Brian Carpenter – both. Picky point – the draft should explicitly refer forward to future doc for the other features TBD; also need to clarify what is/not handled with respect to NAT-PT issues Dave: decouple some features (like SCTP) and address priorities. E.g. FTP could be added to this doc vs a new doc with high priority. Consensus for different doc, but high priority. Greg Leibovitz - other things need to be added, good reason to create separate docs, ? endpoint independence – is there consensus to make this a core requiment? Marcelo – established requirements in Behave, maintain current state of endpoint independence, don’t wait for the alternatives to be resolved ? is endpoint independence a core requirement? Philip Matthews – already a core requirement in Behave Stuart Cheshire – danger in wanting everything; FTP passive mode is probably sufficient; people will find other ways Magnus – endpoint independence necessary or break NAT traversal Dave – maybe alternatives to endpoint independence is not required Philip – no need to debate it as part of the NAT64 discussion Magnus – can take on work later Dave – soften will to might... ----- DNS64 Marcelo http://tools.ietf.org/html/draft-bagnulo-behave-dns64-02 draft is more advanced than NAT64 app scenario 1: IPv6 network client to IPv4 internet server DNSSEC – how to support? In the draft as suggestion. Will work except in the case of a validating and translation oblivious stub resolver. If the stub cannot translate, DNSSEC will break. Not many validating stub resolvers out there yet Alain – run this by DNS. Marcelo – did last time, seemed conclusive Andrew Sullivan – practically no deployment, but things may be happen. Specify this ASAP while still in development How does the validating sever set the AD bit with a AAAA Mark Andrews – trust that the validating server policy is proper Andrew Sullivan – synthesis should carry signature data – may be OK, not proven yet Mark Andrews – if the stub resolver is going to validate, it may/not set the CD bit. I know I’m going to validate, just give me the answer. DO means you are willing to accept the DNSSEC records; resolver should set the AD bit in the query if they want it in the response. Dave Thaler – implementation in Windows includes a security-aware, non-validating stub resolver that will not break if the AD bit is set. If not set, it depends on which API is used Andrew S. – want the query with DO and the application may act differently based on the AD bit. If the application tries to validate, it may break. Dave T. only return me data or tell me if it is secure Marcelo – local policy to set the AD bit? Andrew S. take back to DNS Do we include the original A RR in the DNS response? Hint that it is a synthetic AAAA Eric Klein – why not? Andrew – EDNS0 may truncate the additional info, can’t promise that it will be there. Don’t rely on it. Eric – document it as a risk; Andrew – like to know that someone has fiddled Eric – useful in diagnosis Mark – maybe in the authority section rather? Keith Moore – consequence of disappearing may make applications fail mysteriously. Hints are useful but create failure anomalies Marcelo – don’t make applications fail if missing. Should we include, noting that risk, or don’t include. Keith – would like to know when the data has be altered Wes Hardecker – if DO bit is set, validating stub resolver, if we get data that does not include the A record, cannot accept the AAAA as authentic. Must have the A record to validate that the AAAA is plausible. Mark Andrews – need to prove the prefix is valid; define option to allow the app to get the information. Wes is looking at case where CD=1. if the app wants to know that the AAAA is synthesized, it just wants to know the original A record. Dave – the application may find it useful, but it may not be via DNS. Decouple from the DNS discussion. Marcelo – go to the apps area Andrew Sullivan – we’ll do what is necessary to get this evil kludge working, not to make it perfect. Go for least suckage. Wes Hardecker – language should say it SHOULD return the AAAA Keith Moore – what I really want is consistent results no matter who asks; synthesis violates this. The app could know someone is lying and can get the real answer if it wants it. SHOULD does it Brian Carpenter – client stub resolver makes AAAA request and there is no AAAA or A, then the translator returns the error reply. No AAAA or no A reply? Mark Andrews – the error should match the query App scenario 2 IPv6 internet to and IPv4 server inside the IPv4-only No need to synthesize AAAA for your own network. Publish AAAA containing the IPv6 representation of the IPv4 address What about DynDNS? With DNS update, generate the synthetic AAAA RR What about DNSSEC? Same problems generic to DynDNS/DNSSEC interaction Another approach: Synthesize the AAAA when queried, i.e. DNS64 Less boxes to update. Leverage DNS64 How to handle NSEC RR generation? This is a major hack, but may be useful. Include these three approaches, in order presented, and leave option 3 as a last resort Mark Andrews – when you remove A record, also remove the AAAA; synthesizing DNSSEC on the fly not recommended, especially signed zone Stuart Cheshire – DNSSEC conflict when data is altered. Incentives are not aligned – the beneficiary is the IPv6 network, but the IPv4 network has to do the work. Marcelo – no, the incentives are aligned – I am an IPv4 network and want to be available to IPv6 ----- Prioritize Behave Milestones Dave Thaler Proposed doc organization (see slide) Framework – roadmap to remaining standards track documents, informational Doc A – SIIT update Doc B – DNS “ALG” Scenarios currently in charter, plus suggestions in Doodle poll 1. IPv6 network to IPv4 Internet (hi) 2. IPv6 internet to IPv4 network (hi) 3. IPv4 network to IPv6 Internet (some) 4. IPv4 internet to IPv6 network (hi) 5. IPv6 to IPv4 in same org (some) 6. IPv4 to IPv6 in same org (some) All are important, urgency is on 1, 2 and 5 maybe 5 and 6 next All are being presented today or tomorrow Define new charter, and decide which docs to be WG items Fred – instead of IVI it is in the Framework doc Philip – is the framework defining the solution for stateless translation? Fred – need framework, need SIIT update Dave – does there need to be a standards track doc to define stateless translation? Fred – SIIT update covers it Magnus – can the framework be informational? How do we make a normative statement about prefixes etc.? Dave – fixable Philip – like keeping the framework informational and separate standards track docs Kevin Yin – consistent terminology definition in the framework? Dave – All the other docs refer for definitions (Fred nods) All the scenarios are important, can’t WGLC at the same time, so let’s schedule 1, 2 and 4 should push to meet Sept WGLC Philip – discuss this with the authors We agree to address 1, 2 and 4 first, also FTP-ALG Should FTP-ALG be in the same milestone set (Sept)? more support to decouple. Chairs will talk to the authors and set dates in charter. Document adoption Is this a reasonable starting point for a working group document? Framework – unanimous hum for Translation – SIIT update, stateless translation – unanimous hum for NAT64 – near unanimous for DNS64 – unanimous for Confirm on the list, sounds like they are ready to move forward ----- Prefix 64 discussion Marcelo – well-known vs Fred – LIR prefix Scenario 2 and 3 definitely need LIR prefix, discuss what to do for the others Kevin Yin – IVI folks not here; Fred is co-author, representing ----- Marcelo – PREFIX64 Way to represent IPv4 address in the IPv6 space Ask IANA for a well-known prefix Or each site deploying a translator use a prefix from their space (LIR) Well-known prefix In the v6 internet to v4 network scenario, the WK prefix does not work Imports entire v4 routing table Reasonable consensus that it wouldn’t work In the v6 network to v4 internet case, the conclusion is not so clear, but WK would work Prefix length could be short, e.g. /24. prepending IPv4 gets to /48 Can route towards different subprefixes within high 64 – routers don’t do well with longer than /80 prefixes Fred – blanket statement; some routers do have 64 bit paths, but chips are fast enough Configuration – DNS64 needs to know; 3484 policy table so app can prefer native connectivity; apps that want to pass addresses; WK prefix can be hardcoded Multiple translators – both NAT64 announce the WK prefix, a change in intrasite routing may break communication. Add some bits between WK prefix and IPv4 address to announce more specific routes. "context change" two sites with different translators; a referral may not work for many reasons. SIP in particular. Keith – as long as inserted bits are constant, this would work with more specific routes Strong conclusion – WK not suitable for v6 internet to v4 network case. Weak conclusion – WK has some advantages in the v6 network to the v4 internet Iljitsch – extra bits? Terminology – strong WK prefix – all bits specified; weak WK – some bits left configurable. ----- Fred – representing CERNET – LIR prefix Stateless – CERNET has multiple translators using LIR prefix; can aggregate and use more specific routes. More easily manage the route tables (without importing all IPv4) Referral support – refer it to specific translator, can’t do if there is a common prefix Native connectivity preference – with a WK prefix the host knows when non-native; in CERNET, RFC 3484 rules work DNS ALG – the IVI6 hosts know the prefix, no additional information needed Stateful – some things are a bit easier with WK prefix DNS ALG – LIR prefix requires more tools, not obvious Recommendations: use LIR prefix, except a WK prefix may be used in stateful translator. Some cases Require LIR, WK is convenient but LIR would work, so simplest solution is to use LIR Dave Thaler – WK much simpler for scenarios 1 and 4, LIR needed for other scenarios. Make it simple for me or simpler for all. No reason that stateless HAS TO use LIR. Do we want to say everyone uses the same method? Or make each solution simplest ? DNS64 may pre-publish AAAA, can it do that with LIR prefix? How does it know the prefix? Marcelo – IPv6 internet to IPv4 network recommending LIR prefix. Keith Moore – divide the world differently. Applications and hosts, I want things consistent everywhere. WK prefix won’t work everywhere, applications cannot depend on the WK prefix. WK prefix can be filtered, but no reachability. Suresh – different scenarios – IPv4 only network IPv6 internet how are you reachable? Dave Thaler – implementation using prefix policy table, if the WK prefix is the default, others are configurable, large portion can work without manual configuration, additional stuff requires config Iljitsch – discussing this more than a year; considering all the discussion, ask for a WK prefix but do not preclude use of LIR where appropriate. Keith Moore – provide an alternative to manual configuration as a priority; Iljitsch – NAT-PT worked most of the time without anyone knowing prefixes; IPv6 may ask using DHCPv6; Keith – identified a big hole; piecemeal approach; when things don’t work consistently. Dan Wing – how to learn the prefix – I have a draft, maybe using RA Tony Hain – follow up on Keith, desire to make it work as well as possible, but no need to make it so good that people don’t move the IPv6 native Do we have enough information to make a decision? For scenario 1 and 4: Prefer LIR everywhere? Hum (strong) hands (8) Just WK prefix? (little or none) Default to WK, allow LIR (strong) hands (20) Gregory Leibovitz – WK can’t be routed ------------------------------------------ Session 2, Wednesday ----- TURN-TCP Simon Perreault (new editor) http://tools.ietf.org/html/draft-ietf-behave-turn-tcp-02 Open issues: Comments that use case not compelling Feedback is requested – interest in TURN-TCP? Jonathan Rosenberg – SOCKS doesn’t quite work, no need to revisit. Are there sufficient use cases? What does the community want to do? Replace MSRP relay ? potential replacement for MSRP Keith Moore – specific use cases not enough to justify/drop. Based on variety of applications seems to be good reason Philip Matthews - for peer to peer Remi – skype has a very different model, force use of relays Simon – tunneling issue, UDP does not go through firewalls, TCP helps Dave T. – Firewalls block TCP sometimes too, so people use HTTP Rory – arms race with DPI Remi – general use case Keith Moore – firewall blocking is a policy decision Dan Wing – seems valid to go on even without compelling use case Technical issues: Multiplex like SSH vs separate TCP connections, tradoffs Remi – multiplexing not that simple; Dan – next presentation on TCP over TCP Keep-alive of data connection; define a sequence, TCP keep-alive, mandate app Remi – client? Yes client keep-alive. Prefer app layer Philip – also in favor of app protocol; solves several problems at once Keith Moore – disagree, more broadly applicable to existing applications as a shim, mandating app protocol change dissuades use Jonathan – most apps have appl k-a; probably already solved. ICE-TCP with STUN already would keep the connections alive Remi – TCP k-a not useful in some OS, too slow, no option to turn on; apps needing long-term connections probably already have a solution Simon – make the app protocol a SHOULD? Keith – not appropriate to impose requirements on the application Philip – Jonathan had a good suggestion; not meant to be used in isolation, use it with ICE. At the ICE level there are already keep-alives. If you do it without ICE, there needs to be another way to k-a Keith – expectation that all use ICE is out of line. Don’t burden applications; Jonathan – statement is ICE solves the problem, otherwise you have to keep the connection alive. Keith – do need a provision for k-a in the protocol Chris – separate the NAT binding and e2e k-a Dan – MUST be a way for each app to keep the NAT binding open with the TURN server. Keith’s point that the shim might need a mechanism to backstop application timeout, does not need to be sent if app is talkative enough Chris – implementation issue. Security mech may also have k-a. give a list of options, potentially many different use cases. Simon – changes to the protocol to build in a k-a Remi – not just a passthrough anymore Adam Roach – that would impact performance; not just juggling bytes, adding protocol overhead. Not scalable Keith – I see the point Jonathan – any k-a here only impacts the client-TURN server; also need to keep the NAT binding alive; if the lifetime in the TURN server is the same, the k-a at TURN level adds no value Jonathan Lennox - Define an app protocol that allows an app to select a TURN k-a because it is not doing it itself Philip – not using ICE, there has to be something else (app) Dan – consensus that the app should take care of it Gregory Leibovitz – why is this not like a layering violation? Distinct separation of a layer providing something transparently Keith – point out that TURN does not provide this service Dave – app may not care for short-lived connections; recommend doing it if it needs it ----- TURN TCP Variant Marc Petit-Huguenin http://tools.ietf.org/html/draft-petithuguenin-turn-tcp-variant-01 UDP allocation Why two mechanisms? Let’s rewrite TURN UDP! (jk) Reuse the mechanism Inspired by OpenSSH multiplexing; add an adjust-window Pros – unified mechanism, only one TCP connection thru NAT, faster than multiple connections; ICE TCP opens multiple TCP at startup, then close down to one – fits well with multiplex, Cons – head of blocking; some optimizations not possible; complexity Remi – overhead is another con. On pros – TCP and UDP have very different semantics at app, unified mechanism is an exaggeration. Sometimes it is faster, but not always true. Against this proposal Keith – what does TURN want to be? Like SOCKS? Which are we trying to define? Remi – once the connection is set up, it is a normal TCP connection. Jonathan – like the current model better, long debate on windowing, etc. what do we really need it for? Make it simple as possible. Annoying that it is not the same as UDP, but we looked at many alternatives. TCP and UDP are different, so a transport layer intermediary ends up different. Simplicity over optimization. In ICE, UDP has no connection status, TCP already is not super real-time. Unnecessary optimization. Philip – get it done, if it proves popular then need to optimize ----- TURN Philip Matthews http://tools.ietf.org/html/draft-ietf-behave-turn-13 "last presentation" on TURN in IESG eval, Apr 9 publication many drafts are citing Recent tech changes Added error code 403: forbidden; server rejects createPermission or ChannelBind Clarified nonce usage; new on each Allocate attempt, change hourly Not changed – lack of consensus Return ICMP error if outgoing packet > MTU; no comments in support Make Channel lifetime = permission lifetime; not much support During Auth48, clarify attribute length and padding, add thanks to implementers ----- Large Scale NAT Akira Nakagawa http://tools.ietf.org/html/draft-nishitani-cgn-01 NAT444 network model two NATs, this is about the LSN Basic – sharing global address High transparency and high connectivity RFC 4787 etc. Fairness – limit the number of ports, allocating dynamic ports. Preserve always-available services ports, pass-thru specific CPE ports Logging the translations – address and port mapping and timestamps Dan – value in this draft? Does it address malicious attempts to use up all ports? Spamming? Does this help? DSlite can use this, and ... David Miles – value having this in Behave so Softwires and others can follow. Avoid profusion of network models. Advise and maintain control of the definition Remi – other documents touch on this, like the SHARA BOF. Consider implications. Keith – yes. Brian Carpenter – it’s useful to define list of functions, could be a requirements doc eventually. Does not give a sense of the engineering issues – scaling in particular. Really big NAT with many simultaneous connections, reliability, fail-over etc. DaveT – no one so far is saying don’t do this, we should consider adding this as a milestone James Woodyatt – Behave should describe functional requirements for LSN; like the name better than CGN. No requirement for dynamic port forwarding and there should be. Responding to some protocol that small scale NATs already are doing, Mark Townsley – we need to coordinate with Softwires, avoid scope overlap. Now is the time to get the interfaces nailed down soon. Philip Matthews – collection of details defined elsewhere, not really defining new technical requirements. Shin – Yes, authors’ intention. NAT traversal details, etc. are covered elsewhere. More an operational document. Important for double NAT. Gregory L – in light of Townsley/Arkko scenarios document, can we scope down to a subset? ? - security practice should be included? Shin – yes, not mature yet and that would be added. Mark – the scenarios doc never moved ahead Gregory – important framework, should have a home Dan – chairs asked authors about update Mark – might be coming along… Magnus – similar docs for 6to4 NAT as well Philip – also a framework draft for 6to4 overlaps with the Townsley/Arkko Shin – should be WG doc? Dan – people interested in having a milestone to define requirements, but remains to be seen which draft(s) continue Philip – is this an overview doc for all NATs or only LSN? DaveT – multiple subscribers ? not a lot of overlap home/LSN ----- Layer 2 Aware NAT David Miles http://tools.ietf.org/html/draft-miles-behave-l2nat-00 delineate and indentify subscribers at layer 2 looking at a layer 2 access network, unique subscriber connections, IP address doesn’t matter NAT44 function at the first routing point – LSN; CPE is bridges, NAT44 Make the CPE route to achieve NAT44 state Existing operational models, addressing, topology; CPE that can’t be changed Support existing CPE with minimal change; borrows from DSlite Implications of double NAT Variety of CPE not in control of the ISP; provides options to coexist with legacy CPE All subs have the same address, VLAN for NAT. Each layer 2 instance has its own virtual NAT table. Supports a variety of link-layers Network address and port translation on all IPv4 traffic; first routing hop. No tunneling, IPv6 not a prereq – uses IPv4 datagrams; important if there are intervening devices Use cases NAT444 scenario, double NAT Eliminate the home NAT, use a router; no need for a routing protocol in the NAT44 L2TP access concentrator Options for IPv4 Overloading (comparison table in presentation) Shin – where the NAT is located is not important Mark Townsley – not totally happy with this chart; the approaches are not completely disjoint Jonathan – can multiple devices talk to each other; yes, hairpinning Stuart Cheshire – how are addresses assigned? Mark – some sort of layer 2 mechanism to demux, at the edge we translate. Use any address assignment you like ? is this a subset of LSN? David – not necessarily a stand-alone doc, stimulating draft may ber Rory – in the NAT444 setup, no dynamic port forwarding; CPE router has to forward out to LSN David – CPE could be a bridge; Pierre – valuable for other solutions not just CGN; put this work in the same place as other approaches to v4 shortage ----- Diameter NAT Control Application (DNCA) Wojciech Dec http://tools.ietf.org/html/draft-brockners-diameter-nat-control-00 LSN has impact on service provide 1. customization of NAT per subscriber 2. Accounting 3. Regulatory – subscriber tracability Given to the DIME working group – common interest Define requirements for control protocol 2 types of NAT control – per flow NAT-binding or per endpoint NAT-parameter control Accounting for bindings at LSN Integrate with AAA and control infrastructure, Diameter based Operation within the service provider trust domain, no direct interaction with home user History of NAT control – why a new Diameter Application for NAT control? Some existing protocols have parts of NAT control needed for LSN DNCA manager and agent Well-received in DIME WG, Remi – what happens with an end-point does not support this? Woj – no host impact Peter – existing protocols do not meet all requirements? Really should understand what is missing before defining a new protocol Philip – this group might specify high-level requirements for NAT control, not to spec out the protocol. Diameter perhaps or maybe more appropriately SNMP Dan – during LSN discussion mentioned port forwarding, restriction of port allocations, this meets those needs. We should analyze the existing/new protocols and select down what might meet the need. ----- NAT with Explicit Control NAT-XC Keith Moore http://tools.ietf.org/html/draft-moore-nat-xc-02 motivations a world where IPv6 is everywhere – easy as possible to migrate accept translation necessary provide a predicable programming model for apps, independent of IPvX and NAT make the internet safe for applications separate control point from the translator, mediate between the app and translator case 0: collocation with the control router/translator case 1,2 : ISP or customer case 3: stack case 4: shim case 5: app itself case 6: multiple control points closer to the app the better Protocol based on STUN – well-known “anycast” control address Includes authentication (list of primitives and usage from slides) Applicable to different kinds of NATs, stateful or stateless (or hybrid) translation, several translator configurations – NAT/CPE, CGN, 3rd party Generalizable to 44 and 66 NAT Deployment – ISP could supply for free for v6-only or to lure customers away from v4 Control Point could be variously deployed Tries to be zero config Allows all parties to arrange for dual stack Costs borne by those who benefit Brian Carpenter – very interesting; referrals just work? If your app is dual-stack the app has a view as if outside the translator, referral between v4 only and v6 only of course doesn’t Gregory – there is probably IPR related to this; validate the idea. What about filtering? The NAT is usually collocated with filtering? The apps can do on their own, NAT boundary at the perimeter? Keith – explicit protocol with yes/no on binding, the app then knows that the traffic would be blocked. James W. – disagree with cost/benefit statement. Extra cost above case 0, with separating it and allowing the control point to be variously deployed. It benefits the translator folks, not those deploying the control point; need interop testing and compliance testing Keith – fair point, but moving it closer to the app is advantageous to the app Philip – surprised no mention of all the previous efforts Dan – let’s step back and ? - nice solution, eliminates ALGs, considerably more complex to separate control point ----- IPv6 destination header options for IPv4 translator mapping Remi Denis-Courmont http://tools.ietf.org/html/draft-denis-behave-v4v6exthdr-01 Changes since 00 Move forward? Change scope to Standard? DaveT – this learns the address assigned by the innermost NAT. don’t know if we need yet another mechanism for the innermost NAT assignment, lean toward experimental Dan – more discussion on the list; few people have read (5) DaveT – read and comment please Jeff – we have other mechanisms, and having to support another IPv6 routing option is not something I want to do as a vendor ----- Source IP NAT Charlie Perkins http://tools.ietf.org/html/draft-perkins-sourceipnat-00 translating IPv6 based on source IPv4 address moving to IPv6-only lose access from IPv4 customer base need a way to encourage IPv6, allow them to service everyone, maybe with some advantages to IPv6 clients DNS-based setup to assign a flow and IPv4 address allocation No change to IPv6-only host or IPv4-only hosts, does not require dual stack Confident this is scalable – based on other flow management tools From v4 DNS query, the IPv4 source address is not carried; first use of the flow completes the bind. For a timeout interval, wait for the establishment of flow binding Failure modes Too many new flow requests at the same time, due to temporary block of NATv4 address One source trying to access too many destinations Stuart – small pool of v4 addresses shared with a large pool of servers; all use port 80 Charlie – compatible with outgoing mechanisms Stuart – not sure Jeff – confused whether this is 2-tuple or 5-tuple flow? Charlie – not strictly required for 5-tuple flow – port independent Jeff – could be located anywhere, potential for maximal use of a small pool of v4 addresses. Should extend to 5-tuple where available, could work both ways Dave T – thanks. For the scenario IPv4 internet to IPv6 networks, this provides an alternate solution to consider that doesn't have the limitation of only allowing a small number of IPv6 destinations Mark Andrews – visible to a large number of potential clients could query DNS at the same time. The binding has to stay open thru the DNS TTL. Charlie – valid point. But failure rate drops rapidly as more v4 addresses available to map. Mark – reality is one DNS request gets a number of flows Charlie – number of flows is not the problem, but number at the same time Mark – restart the binding Jeff – a lot of work to be done, but support the proposal, what about IPR? Charlie – probably not an issue Magnus – similar scalability issues to NAT-PT; analyze Marc Blanchet – TTL of DNS entry should be low Charlie – 1 sec, 15 min modeled Marc – DoS using a script with 1000s of DNS requests, how to avoid Charlie – not a new threat; ----- IPv4-IPv6 Multicast Translator Stig Venaas http://tools.ietf.org/html/draft-venaas-behave-mcast46-00 how to extract multicast traffic stateless translation for multicast can’t have all the IPv6 groups available in IPv4. Static allocation prefix? Well known? Looking for input, solutions, additional contribution DaveT – which of the 6 scenarios does this apply to? Jeff – may need to revise after the unicast issues are revised? Stig – back burner, but keep cross reviewing ? code is there, works, various issues to look for Suresh – prefix selection has different implications for unicast, multicast Remi – could you hide this in the IPv6 OS? Garry – transport issues like checksums DaveT – keep talking.