v6ops Notes - Itojun IETF-55 Atlanta 19 Nov 2001 === intro/agenda report from interim 18-19 sep launch new working group charter/goals scenarios work, breakwort sessions accepted several work items accepted work items transition mechanisms survey of ipv4 addr 3gpp scenarios unmanaged scnearios === deployment scenario/analysis unmanaged no rename of the draft yet scenario draft document cleanup open questions what to do with privacy requirement (1) privacy is important, people using ipv6 has no less privacy than ipv4 - difficult to track down host in home network (2) NAT does not really privacy. cookies are there. we don't need to think about privacy erik: privacy concern is not black and white just list consequences erik: address changes in IPv4 - whats' the difference in IPv6? we can assign multiple address at the same time, so the situation varies moore: privacy is a tradeoff, depends on application question needs to be asked differently per-applications, not per-host/site careful about wording "network privacy" ?: privacy problem is not just for unmanaged. kemp: involving social/legal things as well, hard to pin-down specific technical requirement. mrw: make sense to analyze implications and tell readers huitema: (1) list implications, let people choose (2) then, who decides? alain: two issues mixed up - tracking the usage of machine, and not exposing your address. huitema: if there's strong opinion, send to the list. haberman: duplicate avoid or allow? consistency? mrw: each draft should state to some extent huitema: if we are to study consequences, it could be different between scenarios huitema: list consequences in scenarios, if there's common thing, then make a standalone document rdroms: see if there's any inconsistencies in multiple scneario documents rough consensus - list consequences. how much ipv4/v6 interop shall we require during the transition need local interoperability - v4 printer in home, v6 pc in home backward compatibility - use existing ipv4 services how much do we want to allow v4 station to acceses v6 world (left to debate) (1) local is mandatory, other things are optional (2) go for a full thing ?: ipv6 only device is far away, so (1) mrw: clarify "ipv6 only" moore: ipv6 only device is server, or client moore: differences between generic device vs appliance alain: need cost analysis. we don't know. 4 cases of deployment solution documents lot of text added during interim recommendations 4 cases of deployment DNS-ALG issue you want to reserve mapping for ipv6 you want to reserve address pool for ipv6-to-ipv4 mapping we specify this kind of thing in src/dst select rule prefer direct communication than mapped addresses we should avoid translation as much as possible want revise of nat-pt erik: assumptions? nat vs nat-pt? huitema: what amount of service should be provided for v6-v4 interworking? erik: if you want to speak with v4 host, bulid a v4 host. erik: if you decide to build v6 only host, don't try to talk with v4 host. pekka: need stuff simpler than teredo. 6to4 at home gateway rja: cut the complexity. complexity is operational nightmare for deployment. otherwise it won't deploy before my end of my lifetime. mrw: should nat traversal be solved? nat traversal should be solved? - half and half alain: nat box is fact of life. (!= teredo) moore: don't solve it. erik: teredo constraint = there's someone helping you. we could do stuff like ppp-over-tcp. mrw: take it to mailing list recommendations scenario document - mostly ready minimal edit, privacy, support it v6-only host, then last call solution document - less advanced need revisions suggested (wanted) actions we need to have place to teredo narten: problem or solution? big difference should find editor for nat-pt === isp interim how much info should be put into? multihoming, managed access - need text, please input dialup public access wireless exchange point *please help on sections* looks that there are too much content alain: pointer to multihoming? pekka: multihoming is not an isp problem hain: don't go there ?: don't go there, multi6 is enough pekka: do we need to put pointer in other team document too? discuss more on the list === enterprise scenario we cannot define all possible solutions solution aspect of enterprise will be next draft what kind of network tools requirement scope of discussion - what is the enterprise? connected to isp actively mangaed large, or small alain: need more content/detail. yanick: it's new draft. it could be rathole. how you will introduce ipv6 into the enterprise enterprise will be faced with different hardship different ipv4 address availability variables - help readers to decide which part to read influenced by business requirement of enterprise transition methods we can't come up with one set of scenario, there will be many 6 different scenarios this won't cover every enterprise, but would like to cover typical ones please drop team a note if you have "typical enterprise" picture inventory configuration, address allocations, alain: lots of acronym - too difficult to read alain: it was unclear where you are going? transition issues? administrative issues? backwards bound: guidance on acronyms? too many acronyms? - more hands than "appropriate amount of acronyms" huitema: we need to contact people actually deployed ipv6 network. separate draft? some presentation? mrw: looks good pekka: yanick: please input narten: need input from REAL ipv6 enterprise operators huitema: two different document - (1) single person, how we did it (2) consensus document, how should it be handled. we only have (2). erik: different - this is what i think deployment should be, and this is how actually did it bound: applies to all document bound: cannot reach consensus because cannot agree on assumption - please read document, read the assumption part. hinden: real deployment carries more weight than "one might do" hinden: why not use vendor's networks as real deployment example bound: GM, DoD, ... (cut off) ?: "IPv6 NAT" is mentineod in document, don't. === cellular scenario wg document editorial changes still to be done - like references seems to be stable analysis mostly editorial clarify the use of static/dynamic tunnels document nat-pt use error in IMS-1 case major change - name of the document issues would like to see scenario where IMS is dual stack IMS is v6 only, we can't change it some errors another solutions document (private submission) - confusion talk with the author directory editorial input - thanks need protocol translation in network scenarios nat-pt doesn't simply cut it something else/revision of it, would be needed way forward scenario document -> wg last call, sort-of consensus analysis document -> right approach? yup. accept as wg item mrw: nat64/nat-pt revision needed? brian: there's no viable nat-pt scenarios. before we put that question we need to analyze architecture mrw: we can't work on nat64/nat-pt based on charter, what should we do? moore: box deal with specific applcation cases alain: too many difference between nat-pt and nat in ipv4. nat-pt: just a patch to enable operation of ipv6 patch, will disappear. ipv4 nat: will stay forever alain: nat-pt design is worse than ipv4 nat design. design nat which is no better/worse than ipv4 nat is needed bound: we have to be flexible. on existing mechanisms bound: not many of testing on transition tools. stick with existing mechanism, let's use it and analyze before doing something new sra: nat-pt is last-resort thing. it is not ok to build v6-only machine and expect it to interoperate with v4-only machine does not make sense (and that is the only case nat-pt makes sense). huitema: eventually we want to move to ipv6-only internet. how can we move from dual-stack internet? ?: carrier pov - want to see accelerated ipv6 cellular devices deployment bound: v6only will deploy, but communiate with v6only. they are going to v6only now. narten: (1) note broken, update, fix it (2) re-classify as experimental itojun: need nat-pt brokenness analysis - alain has one ?: nat-pt is not a magic box. document nat-pt pitfalls and move on. erik: we should do that moore: v6only may be more realistic than people think huitema: for nat-pt, revise it mrw: rewrite it with big applicability statement alain: keep the title narten: we'd like to fix it, but we're not sure ?: restrict applicability of nat-pt george: before revise, exactly identify what is the problem, and what problem is feasible to tackle ?: 3gpp scenario uses nat-pt in very special cases only should we request our AD to allow nat-pt to the charter majority should we not request our AD to allow nat-pt to the charter minority, but there are current work items transition mechanisms remove auto tunnel remove default configure tunnelling anycast text about source address selection -> default-addr-select better ref for diffserv/ecn change A6 to AAAA MTU issues optional dynamic tunnel interface MTU discovery small fixed tunnel interfacde MTU allow encapsulatros and decapsulatros to configure larger MTU decapsulatros must support reass of ipv4 MTU implication decapsulator must reass ipv4 packet 1280+20 max(interface MTU) for dynamic discovery case 4k comes to play only if you have interface MTU > 4k open issues should we drop the mention of unidir tunnel? is 1280 a reasonable mtu for encapsulators without dynamic tunnel mtu discovery? is 4400 a reasonable mru? are there other concerns about reassembly buffer size? ipv6 native address include ipv4-mapped as currently defined is this an issue that needs to be dealt with? the term "ipv6-native" is only used once in the document email comment about ingress filtering need to see if this is just a clarification about the assumptions in the document next steps edit on the mailing list re-issue under v6ops name implementation report? proposals application aspects how to implement ipv4/v6-capable applications go through list of addresses moore: too much generalization of application. there are set of applications that cannot be dual. hain: need broad perspective from implementer's community. tickle app area. -> chairs tickle app area ad 6to4 security issues 6to4 spec is weak in security consideration. original motive: try to describe operational issues try to give some example ingress filter/address sanity check difficult changes anyone can spoof address abusing 6to4 relay router use anycast ipv4 source for packets from relay (slightly difficult to spoof) authenticated relay - EBGP session among relay and 6to4 router ?: anycast ipv4 source questionable sra: ipsec? huitema: teredo solves it by relay discovery procedure 3 way handshake - more state alain: problem is unsolvable - assymmetry (1) model is flawed, don't use it (2) what is the impact. anonymized DoS. traceback? moore: unsolvable. sra: solvable, but hard to solve. problem is in decapsulator. packet from somewhere to relay is the problem. firewall consideration (skipped) ipv4 mapped harmful (skipped) ngtrans -> v6ops transition