IETF78 Intarea meeting minutes Monday, July 26, 17:40 - 19:40, Auditorium 1 ---------------------------------------------------------------------- Based on notes taken by Ed Jankiewicz. 17:40 Introduction and Administrativa ........................ 10 min Julien Laganier, Christian Vogt Two more topics that didn’t fit the agenda Multi-MTU proposal from Iljitch Two hosts on a link to use larger MTU than what is set on the link Least common denominator -- although some larger pair-wise negotiation is possible. Iljitch -- no plans to present, maybe IETF in near future. Start publication as experimental. Review on list Jari -- please read and review Geert -- suggested at the time of ND design, shot down at that time. Excited to see it finally happen Using CGA for Secure Access Control Use CGA in an extension header to allow data packets to be validated to the CGA owner Discussion on cgasec@ietf.org 17:50 Issues with IP Address Sharing ......................... 15 min draft-ietf-intarea-shared-addressing-issues-01 http://tools.ietf.org/html/draft-ietf-intarea-shared-addressing-issues-01 Mat Ford Purpose is stable -- capture issues common to many address sharing approaches. Not specific solution details. Do issues apply to existing CPE NAT or more centralized CGN or such Issues that apply to 3rd party -- like content providers Basically stable, is this ready for WGLC? Christian -- polled for readers, enough to say WGLC. Please review and comment on list 18:05 Updated Specification of the IPv4 ID Field ............. 30 min http://tools.ietf.org/html/draft-ietf-intarea-ipv4-id-update-00 Joe Touch Everyone should honor DF, that’s another story. If you have a host that reuses ID faster than the network allows, slow down Margaret -- list of statements about what hosts should change. Hosts that ignore DF bit, and hosts should change these things. Should everyone out there unify on this behavior? What happens when some things don’t change? Joe -- if you don’t actually fragment, doesn’t matter. Joe -- NATs mess this up too, if IDs get reused. Relying on other layers to notice and drop, already a problem today. Makes it worse if zeros are used and folks ignoring DF bit. Margaret -- setting DF without MTU discovery won’t work at all Joe -- start with smaller packets; No good statistics on breakage Margaret -- support the documentation and recommendation, but suggest forbidding setting DF bit without MTU discovery. Joe -- mobile phones already doing this Margaret -- no idea if this is causing problems Jari -- lots of discussions, huge impact if not done right. Joe -- this has been presented multiple time with WGs and this group has been charted to complete this doc Jari -- not to criticize, but we need to be very careful Mark Andrews -- I write name servers. Deliberately turn OFF DF for UDP. Avoid black holes. NATs don’t do MTU discovery well for UDP. Joe -- do you throttle DNS? You don’t keep ID for each client Joe -- why not use TCP as spec’d Thomas Narten -- no way DNS operators will take the risk of wholesale conversion to TCP, and reality that PMTUD doesn’t work well with UDP ? firewalls block PMTUD in some cases, can’t rely on it Joe -- not a single mechanism to solve the problem. ? when you send a packet, you don’t know if it may be fragmented Joe -- unless someone ignores DF bit Behaving like IPv6 doesn’t necessarily solve all these problems. Joe -- can’t say not my problem, but must ensure that IDs don’t wrap too fast Bob Briscoe -- if you set the DF bit should you cycle the ID field accordingly? Given there are already hosts that don’t, will nodes that break the spec break those who are? Stuart Cheshire -- flaw in logic -- after a 4 minute delay mis-ordered fragmented, theoretical thing not noticed. 6 Megabit is not a real world problem Joe -- if you are fragmenting -- don’t reuse within the reordering interval Stuart -- not convinced that it would be safe Mark Andrews -- do not set DF on every packet, only where upper protocols understand path MTU discovery. Rescinds advice that is there for a very good reason. Joe -- when you don’t have your upper layer aware, you MUST NOT reuse ID field. Mark -- turning DF on or off when the upper layer is aware, is a really bad thing Eric Nordmark -- if the host has/not set, the NAT should not change. The fix to the NAT box is to observe the throttling behavior. Margaret -- take out the recommendation to always set DF, don’t just set IP ID field unless the DF bit is on. The useful thing is a more realistic (shorter) time that uniqueness is required, and why. Christian -- please follow up on the list, and perhaps another last call 18:50 Name-Based Sockets ..................................... 15 min http://tools.ietf.org/html/draft-ubillos-name-based-sockets-01 Javier Ubillos And Zhongxing Ming In applications, the app is mapping domain name to IP, app needs to deal with mobility, multihoming etc. Should be in the OS Socket abstractions -- also seems broken as well. Little network-related functionality Surrogate addresses -- shim etc, extra namespaces, indirections What do we want? Avoid indirections, delays, find a lightweight and explicit interface Follow standard TCP semantics, extend to name Piggy-back name exchange in the first couple packets of a conversation. OS can do the name resolution Working TCP prototype under Linux Ubuntu and Android (client) Ongoing work with Ericsson, Tsinghua University and Swedish CS Zhongxing Ming Shim6 provides basic mobility; network layer transparent solution. Mobility is a special case of multihoming. Avoid triangular routing. Shim6 is not sufficient for concurrent moving problem. Need a “stationary infrastructure” Why not DNS? Already resolves by name Concurrent move -- shim6 can construct new address pair, transparent to upper layer protocol Initially the Name based socket bypasses Shim6 to do the name exchange, later the 4 way handshake is triggered. Christian -- is this valuable IETF work? If so where to standardize? Came up in Routing Research Group. Joe Touch -- should float Transport area -- TCP AUTH issues, needs a stable identifier Yuri -- many questions, will talk afterwards Daipeng -- locator ID separation. Much related work and alternative solutions. Javier -- this seems better because it is explicit in the application. Dan Wing -- need a BOF at next IETF -- similar to referral BOF. Need a comparison of how things are done in various alternatives Jari -- agree, need a BOF Journi -- DNS names don’t always name just one host. Devil is in the details Dave Thaler -- second the BOF idea. Do you have to change the apps? There are two classes -- socket writers and those that don’t. Socket writers are diminishing; middleware problem Alan Ford -- what is the meaning of a name? spiraling impact on namespace and ownership. Javier -- session ID vs some verified name ? China Mobile -- solve the mobility issue, but what is the relations to PMIP etc. DNS impact for dynamic update Christian -- continue discussion, organize BOF for next meeting 18:35 Security Assessment of IP version 4 .................... 15 min http://tools.ietf.org/html/draft-ietf-opsec-ip-security-03 Joel Jaeggli 19:05 IPv6 Multihoming without Network Address Translation ... 15 min http://tools.ietf.org/html/draft-troan-multihoming-without-nat66-00 Dan Wing Christian (abbreviated) Identify steps to take to avoid the use of NAT66 1. Source address selection (6man group) 2. Route selection 3. DNS server selection (both in MIF group) With these in place, eliminates these three reasons for NAT66 Jari -- MIF is only working on problem statements, but rechartering for solutions Margaret -- chair MIF and author of NAT66 -- do not have a norm ref to NAT66. Agree that it would be great to eliminate some need for NAT66, but still leaves the renumbering issue. Christian -- how to avoid NAT66 for these specific changes, there are still other problems Margaret -- have to solve the renumbering problem. 19:20 Source Routing for Hosts with Multiple IP Addresses .... 15 min http://tools.ietf.org/html/draft-handley-mptcp-routing-00 Marcelo Bagnulo A host with multiple addresses, several protocols assume this. Host selects different paths based on selecting different address. Assumed by shim6, SCTP, HIP, MPTCP Ingress filtering -- two different PA prefixes assigned by two ISPs. Doesn’t work with normal routing. Source address does not necessarily determine path. Somehow make source address affect route Single exit router to multiple ISP or host with multiple routers Can the host be modified to differentiate next hop? General case, need wide support for source address routing Host behavior? Assume it works? Dan Wing -- NAT66 is the answer (ironic) Erik Nordmark -- general case is hard, source sensitive routing, non-starter. Just solve the single subnet case, one or multiple routers, no more layers of routers. Does this solve 80% of the problem? Thomas Narten -- this is an old problem, not clear there is an easy answer. Carve out some simple scenario solutions rather than trying to solve the entire problem space. Pessimistic, because it is hard, but encourage looking at case by case scenario solving. ? proposed solution -- use the source address when forwarding on the default route Scott Brim -- NAT66 is most of the solution, still need host changes. Hard to update routers. Path of least resistance is to change the end nodes to use multiple addresses, and NAT66. Remi Despres -- good news, solution to general problem -- draft in softwire http://tools.ietf.org/html/draft-despres-softwire-sam-01 Dave Thaler -- Tony working on approach to use ICMP to learn which pairs work. Specific scenario 2 with two routers -- that’s easier to solve, just changing the host -- the host picks which router. Christian -- suggesting downscoping? Yes Margaret -- what is the point of doing this in so many places? The avoid NAT66 draft gets into the same problem, and MIF is chartered to do this Christian -- examine the scope, problem space Margaret -- decide if we need to solve this here Jari -- focus, what is the scope, let MIF do the work. Illytch -- NAT66 doesn’t solve much, non-updated hosts may change the host, proxy shim6. Christian -- update to ID and second last call, BOF for name based socket. 19:35 End of working group meeting