1. Routing integrity in a world of Bandwidth on Demand Dave Wilson DW238-RIPE dave.wilson@heanet.ie

2. Agenda The quick introduction The 60 second JRA3 summary The 90 second campus networking guide The problem statement The run-down of the solutions –(and their own problems)

3. Introduction There's no thrilling new technology here –Afrodite's in another room describing JRA3 –I'm speaking for myself, not any other project Some fairly simple IP routing –Emphasis on observed use over best practice Users might not see this coming, however

4. 60 second guide to the JRA3 project

5. 60 second JRA3 summary NRENs everywhere are working on providing layer 2 services These meet up with GEANT2, which provides its own JRA3 plans to tie these all together

7. 60 second JRA3 summary So the NREN will be able to create layer 2 paths between arbitrary locations JRA3's system will process requests and arrage setup of end-to-end paths Users will have the possibility to connect to "anywhere" in Europe - on layer 2...

8. 60 second JRA3 summary Benefits? Gets the high-demand users off the routed IP network... Tune the IP network toward less conflicting goals.... Gives the user more control...

9. 90 second guide to campus networking

10. 90 second campus networking Every campus is different – Security needs – Regular web/email needs – Research networking needs –"Home" user (campus accommodation) These are conflicting requirements – Ask any CERT Each IT dept reaches its own conclusions

11. 90 second campus networking Then there's the link to "the internet" Often in the past been a single link, with routing policy specified by the NREN –e.g. static routing, BGP, OSPF, RIP,...? Depends on the requirements of the IT dept, and the service spec of the NREN

12. 90 second campus networking Routing policy consists of –list of IP prefixes assigned –info on how those prefixes are routed Some hierarchy is assumed –RIR gives addresses to LIR, LIR to customer Network is built around that hierarchy

13. Hierarchy is assumed

14. 90 second campus networking Not been the case before that users create arbitrary layer 2 connections Successful Bandwidth on Demand service would change this assumption

15. These two worlds meet

16. Conflict of interest The technology exists to connect arbitrary LANs across Europe. Great! The addressing assumes the old hierarchy Addressing isn't as flexible as GE circuits

17. Fragmentation -> Hierarchy We tried fragmented address allocation – Class A, Class B, Class C,... Doesn't work on a grand scale – Led to setting up of RIPE and the other RIRs You can still get fragmented space – Provider Independent vs. Provider Allocated

18. Fragmentation -> Hierarchy ISPs (NRENs included) become LIRs Take stewardship of a block of addr space Connectivity for those PA addresses is dependent upon the NREN "All assignments are valid as long as the original criteria on which the assignment was based are still valid" -- RIPE-368

19. Who is working on this? BoD people are working on the BoD service –Not just in Dante/JRA3, in NREN as well Customers may not have routing expertise –Multidomain routing is a specialist subject RIPE policies are already in place –Not clear if any change there could help That leaves the service providers...

20. The solutions

21. The tradeoffs Follows the rules Easy for user to deploy Easy for operator to support Flexible to existing networks

22. Solution #1 Get an AS number and PI space –Renumber the networks –Run BGP within the campus, and to the NREN

23. Solution #1 Get an AS number and PI space –Doesn't fit with the on-demand idea –Requires complex IP and BGP expertise –Doesn't exist for IPv6 (at the moment anyway, interesting implications from RIPE meetings) –Everyone hates renumbering  Follows rules  Easy deploy  Easy support  Flexible

24. Solution #2 Use RFC1918 space –Renumber the networks –Proxies/NATs for outside access

25. Solution #2 Use RFC1918 space –Networks might not be fully connected –Removes any hope of connecting directly to rest of the internet –Everyone hates renumbering  Follows rules  Easy deploy  Easy support  Flexible

26. Solution #3 Use existing numbers and hope it works –Directly connect the networks –Static more-specific route on the hosts toward the remote site

27. Solution #3 Use existing numbers and hope it works –May bridge campus networks, and all the security hilarity that that entails –Difficult to manage, traffic could go the "wrong" way and be blocked or cause trouble –Breaks conditions for IP allocation, so there may be unexpected side effects  Follows rules  Easy deploy  Easy support  Flexible

28. Solution #4 Subnet, route the subnet –Renumber networks if necessary –Configure routing (not necessarily dynamic) within the campus –Route the more-specific subnet to the remote site over the BoD connection

29. Solution #4 Subnet, route the subnet – Breaks conditions for IP allocation, so there may be unexpected side effects – Still requires some routing knowledge – Difficult to enforce backup via regular IP network  Follows rules  Easy deploy  Easy support  Flexible

30. Other possibilities IPv6 gives us a much freer hand –Multiple addresses per interface –Source Address Selection based on application Combine with.1q VLANs –Host chooses which LAN to send traffic one –Requires host to have intelligent routing –Could in principle work for IPv4

31. To try to reach a common solution... Is this really how we expect BoD to be used? –or is it ok to expect that some routing complexity will have to be dealt with? Tools are there to handle this, but have not been necessary at this scale before For the first time, the network will be more dynamic than the addressing

32. Thank you! dave.wilson@heanet.ie DW238-RIPE