1. Network Architecture (R02) #4 Location and Identity Jon Crowcroft, http://www.cl.cam.ac.uk/~jac22 http://www.cl.cam.ac.uk/teaching/1011/R02

2. IP addr v. Id+Loc IP Addr == Interface + Route Hints. TCP state = 5 tuple Src+Dst port Src+Dst Addr, IP Proto Can’t change during session If we move, have to get new addr to be reachable Need to advertise (DNS) for new people Need to tell old people to reconnect Or tunnel, or rewrite to maintain TCP Mobile IP has agents to do tunnels Mobile IPv6 can cut the triangle case out

3. Why not just leave as mobile ip Don’t like triangles for ipv4 Don’t like tunnel overhead So what about new addr trick Map/encap service or IPv6 trick (8+8, for example)

4. Re-write v. map/encap As all said, re-write has potential security problems, but low overhead/scales in router terms But map/encap has deployment simplicity, but o/h problems - both for encap and for binding service

5. -ve security for re-write? Not clear there really is a security problem Re-writer == NAT, we trust NATs now! E2D TCP/IP 5 tuple assumes IPv4 I/f+route is some sort of secure thing Never true! Correct model is TCP state should be bound to EID, and not care about last hop of path/route at all! Syn-cookie/nonce to secure state Or TSL/SSL or other

6. -ve overheads for map/encap As currently formulated… Fast moving device would cause a lot of re- binding But why not try to localize this? Movement geographically often doesn’t change provider or even topology much Separate geo/topo/provider cases and deal with seperately?

7. Alternative 1 - just ignore Today, clients move; servers fixed Move- get new IP via DHCP Break TCP connection HTTP recover Cross layer optimise recovery RTP/UDP don’t care… Or use Multipath TCP and just add subpath transparently (make before break, though)

8. What about both ends move? In a way, unusual! But if routers are also part of movement, then very “ad hoc” world - so Make hosts routers Believe their route updates… Use App level recovery, or MPTCP make before break What about new clients of re-moved servers?

9. Alt 2 - change TCP TCP shares state with routers today in Compressed header case So why not cache this info When you move, send a “SYN” packet from new addr with compressed state reset to other end (if it hasn’t moved) And copy to router where we _were_(*) If it has moved, then the router there Which should have state(*) to forward it Could generalise for all bi-dir protocols (most transport protocols have roughly symmetric packet counts)

10. DNS DNS update with TTL 0 is not that big a deal! Even the whole DNS Update rate on one large site isn’t that big a deal www.tjd.phlegethon.org/words/thesis.pdf Experimental results (see Naming for Networking byAtkinson&Bhatti http://www.cs.st-andrews.ac.uk/~saleem/publications.html http://portal.acm.org/citation.cfm?id=1298105

11. DNS Update rate Locality? In london, 10M people move over 1 hour in commute 10^7/60*60 <10000 updates per second This is trivial to run a transaction (secure DynDNS) for on a single machine…

12. New topic: Scaling == Complexity? When we ask if an architecture, system or protocol scales, what do we mean? Computer Science defines complexity In terms of incremental cost of algorithm in terms of input scale - e.g. Dijkstra is O(n^2) cpu in number of routers Link state is O(E) msgs in number of edges A FIB might be O(ln(n)) memory re: routers

13. Other types of complexity? Yes - emergent properties Synchronisation effects Routng update-resonance Phase shifts Most long flow or most short (tcp congestion control regimes) Different operating regimes Most web data cacheable, verus most dynamic Interactions - Scanning worm versus routing updates Epidemic, Pandemic, no spread Susceptibility, Infectious, Recover, Mortality? Other?

14. Complex versus Complicated? Some stuff is complicated E.g. network configuration (CLI/IOS) Important, but not really amenable to much CS But could undermine safety C.f. BGP misconfigs locally disrupt global system. Other eg.??

15. Next talk for 2/11/10 Naming in the Internet has been unchanged since Original DNS design, largely Look at Intential Names and Content Centric Names And discuss what new benefits they bring beyond The DNS!