2.2.1 Internet Architecture Board (iab)

Current Meeting Report

IAB Open Meeting
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. 


Leslie Daigle: Are you proposing that we move beyond 
layer-isolated name/identifiers?

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. 

Slides

IAB Open Architecture Meeting
Site Local - um, what’s a "site"
Local Scope Address Requirements
Multi--Homing and Mobility: Baseline Tidbits
ZEROCONF INSIGHTS INTO SCOPING PROBLEMS
Tussle in address space: conflicting requirements, partial solutions (quick, dirty, incomplete talk)
Addresses, Names, Routes, ....
IAB Open Meeting: IP Address Architectures Setting the scene