IETF 57,Vienna, Austria
Monday 14 July, 3:30 - 5:30 pm
Meeting Notes
Leslie Daigle - Welcome and Introduction
Geoff Huston - Introduction to the Scoped Address Topic
Jon Crowcroft - "What's a Site?"
Wireless multi-homing becoming commonplace. Different kinds of wireless networks have different modes of building networks, and users may want to switch from one to another. What is link? What is scope? in the wireless context this is very fuzzy indeed. How do you manage switching between networks while preserving flows and endpoints? There is no single size to fit all - different layers may infer different decisions. Its very hard to undertake cross-layer architecture. Site- local or Link local appear to reflect a misconception. We assumed that there was 'containment' by wires, and wireless breaks these assumptions.
Jon Crowcroft: Yes - there are context implications that do appear to pass across layers. Role-based address meaning is probably too early but it may be the direction.
David Black: There is a whole role of scope and context here
James Kempf: Layers give you abstraction where layers have a defined role without consideration of upper or lower. This is a useful complexity limiter. I'm concerned with how you deal with this. DO you have any ideas on how to limit complexity when you break down the layering.
Jon Crowcroft: the code does not have to be congruent to the abstractions. I don't have a clear answer but it may lead to further complexity.
James Kempf:Tthere are such things a reflective APIs, but this is an area of interest.
Tony Hain - Local Scope Address Requirements
Scoping is a filtering functions and filtering functions will exist no matter what prefix may be used.
Filter boundaries are an operational decision, and inappropriate for rigid definition.
Scoping is a local administrative management decision by the operator. It may be through routing filtering or explicit directed advertisements in the network. The operator sets the location and bounds of filtering. A local scoped address space is simple, without registration or approval. There is consumer simplicity to allow device embedding without default exposure profile. This is a buy the box and turn on local address connectivity. Its stable, and local connectivity persists across external connectivity events. Its private space, allowing the edge to filter to reduce unintended exposure.
Multiple addressing is an expectation in IPv6. Multiple scopes may exist concurrently in a device and this is new to V6. Some examples are printers, file mounts, light switches, etc which do not require or need global scope - appliance plug and play if you will. Intermittently connected networks can operate stably locally in the local context. Ships or planes, etc. Banks or other private interconnects are another example. There is an asserted need commercially for 'private space'.
Dave Crocker - "Multi-Homing and Mobility"
Dave has been working on a solution, but he's not ready yet with this work as a presentable solution.
Shoch et al: Name (what), Address (where), Route (how)
Addressing is usually done in the infrastructure and is there for for reasons that are highly well-established, well-understood, and resistant to change. Third party services are infrastructure. Creating and deploying infrastructure takes time and creates fragile dependencies. 30 years of routing, management, etc works really well, but there is more to do in terms of performance adaptability. We don't want to throw all this out and start over.
Changing addressing at a very fundamental level is perhaps best avoided IPv4 == IPv6 in terms of paradigms about routing and addressing. Multi- homing and routing are the same. Even multi-addressing per interface does not translate up the stack to applications. An IP addr is a network interface topology location. Mobility and multi-homing express more than one location and may change. Degrees of mobility and multi-homing (rate of scale and change) need some standard form of reference. There do not appear to be standard terms to describe this. TIPAs works pretty well is the assertion. This is a point of entrance and departure relative to the network, not relative to the host. The interfaces don't move, but hosts do. Addresses are not mobile, hosts are. The real problem is hat the transport set layers are tied to particular addresses, and the problem is a transport problem rather than an IP problem. SCTP is close to this. The way of looking at this is end- system vs infrastructure. SCTP is intended to be the right idea. The point about this approach is that it moves it to end systems rather than infrastructure, allowing rapid adoption. The issues include security, connectivity interrupts without address overlap, dynamics of choosing between alternatives and retrofit to existing transport usage.
James Kempf: SEAMOBY has terminology in a draft
Jon Crowcroft: You said pretty much what I said, but more clearly. There are apps that are peer-to-peer and endpoint so that transport is one solution and not the general case.
Dave Crocker: My intuition is that if we could move this to the transport space than all this could be easier
Lixia Zhang: I like the approach of endpoint deployment. Its probably not easy. The gain is a community gain, not an immediate self-benefit.
Eric Guttman - "ZEROCONF insights"
We assumed that addresses are relatively stable, names and addresses are unique and datagrams are routable. We break these with zeroconf. We have solutions, but these themselves are broken. URL in presentation identified. The ideal scenario is a two host network. The more typical zeroconf scenario is a richer connectivity environment. This is non- trivial because there is no guarantee of uniqueness, Forwarding is also an issue here. This is not just a problem with link-local, but a scoped address problem. The problem is not just isolated to layer 3, but that we expose a lot of information about the network to applications, but applications have little idea how to deal with it. Applications talk about locators, but not scope of the locator. When the locator leaves the scope it is now a failure. Name resolution is even harder, with a scoped locator forwarding. LLMR uses a technique where each interface only responds to its own name. Solutions and their problems: link local address is a problem because they get propagated by applications and you can't turn it off. Link Local can;t talk to global. The transition is complicated and leads to instability, with more complex forwarding rules. Round Robin across addresses and interfaces is not a good and secure solution. Higher Level ID-based forwarding, and control forwarding policy with applications, sounds good but we don't know how to do this today.
Dave Thaler: The problem of link local is also a multi-homing problem, and the use of a global address may not necessarily be globally reachable, but its completely different from the local address problem.
Eric Guttman: Expose more complexity of the network to higher level apps appears to be the solution, but this gets complex.
Brian Carpenter - "Tussle in Address Space"
Conflicting requirements and inadequate solutions RFC2101 Requirements: routing: minimize the number of routing table entries, minimize the convergence times, want high speed packet switching with qos and te, and want to support mobility and site multi-homing. enterprise: want independent address admin without ISP capture, with host and site MH, server virtualization, and server load balancing, with traffic isolation at security domain boundaries,and network mergers and splits should be seamless (or close) applications: valid e2e identifiers that guarantee reachability, minimize spend, be agile, support address agile transport sessions, third party references to "addresses" (address, identifier or "thingie", to use a Noel Chiappa terminology). Don't care whether its V4, V6 or anything else. Some solutions don't meet all requirements simultaneously (full list!)
We still need new thinking on this, as we simply have not got there with this. We are lacking some clear think as to how to resolve these problems and has been the case for at least the past 6 years.
Pekka Nikkander: How does HIP miss the full set of targets?
Brian Carpenter: location / identifier separation is key to some of these problems. Its a complicated analysis. multi6 does not have all requirements on its table, and again its a broader problem.
Tony Hain: you are getting to one of the points I was trying to hint at, but maybe its not a single solution - we may need to look at a number of mechanisms simply because a single unified solution is not tractable to the issue. Perhaps we should break this up a bit
Brian: The list should be longer, but maybe 1 solution is not the entire answer
Dave Crocker: Is there a table of requirements and potential responses with comments? It might help lead down the path to find somewhere to cut it up. Brian Carpenter: Yes fill out the table
Bob Hinden - "Addresses, Names, Routers,..."
Not presented, due to concurrent commitment in another WG
Open Mic
Pekka Nikkander: Security has not been mentioned clearly enough yet. If we are going to pull who and where apart then we we need to understand security. The routing system is intended to assure you that the packet goes to the right host. The security problem ins the secondary problem that may be caused by a solution to the primary problem
Erik Nordmark: Maybe all we've been doing is to try and punt the core problem from room to room without actually facing it. Whether its applications would handle it, hosts should, network should, etc is not helpful unless we grapple with it. The details are hard but its probably time to do it.
Leslie Daigle: there is a certain consciousness raising in this exercise here to try and address this.
Iljitsch van Beijnum: How bad is the situation?
Leslie Daigle: remember Jon's presentation - we are being pushed out of our comfort zone with technology
Christian Huitema: The one thing that has emerged in site local and link local, if you create ambiguous addresses that is going to hurt you badly. Site local is an example here. In order to use it you need to stick a site-id to the site local, and without such identifiers to attach to the site local you loose the application - it has no idea of which scope is applicability. If you don't have ambiguity then the class of solutions is a lot simpler. Ambiguity in the system looses a lot. Applications then have no idea because of this ambiguity.
Leslie Daigle: 1st plan of attack - what are the retain at all cost principles and what is negotiable
Christian Huitema: common misconception that all addresses are always reachable is false.
Kurtis Lindqvist: how much do you want to change and when? If you look at the time taken for IOPv6 we are at only 457 routes. It takes time to change time. We should think about when we need to do this.
Eric Guttman: we should have the courage to say 'no'. The thing about link local is that its in the marketplace and standardization was the minimal harm path. But there are blind alleys that are just plain wrong, and we need to be clear to warn the community that some solutions are just plan wrong!
Margaret Wasserman: balance the real world (that we wish would go away) vs what the world should be like. We may not want to standardize everything that is out there today, and judgment is called for from folk like the the IAB. We should be able to make some value judgments here
Charlie Kaufman: theory is that there is a real nice elegant solution but we can;t get there from here. IP addresses have duality and if we had designed everything with clean separation (e.g. MAC and IP level addresses) and if we'd designed out protocols such that apps never saw IP addrs would all this go away? And if so then given that the world has been built the other way then what can we do?
Leslie Daigle: its not just enough to separate out the spaces, but you need to define relationships and mapping that needs to be worked out anyway.
Charlie Kaufman: if you used DNS names would they have suitable properties
Christian Huitema: no wide agreement that we should split this and no wide agreement to hide addresses from apps. One arg is carrying the unique id in the packet is a privacy issue. It is a nice feature of IP is that identity is not visible in the network. Applications 'like' choice of service if this is an outcome of choice of address.
Jon Crowcroft: Some of these emerging networks have no natural constituency - they are not established vendor or established operator
Erik Nordmark: One computer could have lots of identifiers. Dave Crocker commented that about avoiding changing infrastructure. Look at peer-to-peer shows that ad hoc measures can work. We may be able to look at identifiers this way.
Michael Richardson: separation of IP from MAC has been useful. Wireless has broken this model, apparently. We ignored all security issues when we pulled apart L2 from L3. This split may not have been so successful. A lot of home networks.
Lixia Zhang: Identify the first important requirement. I've heard security too many time - please define it!
Dave Crocker: My comment was that changing infrastructure is very expensive and we should only do this deliberately. One of the difficulties in this set of topics is that there are bits of compelling religion, but we are not clear as to why this is particularly necessary. But we have this systems now and we need to understand that rather then simply define desirable end points.
David Black: DNS has an interested property of resolution in a global hierarchy. The storage world has parallels here.