[ipv6-hackathon] an IPv6 testing platform for education / "Internet in a Bottle" / Internet illustrator / Pocket Internet
Vesna Manojlovic BECHA at ripe.net
Tue Oct 31 10:53:25 CET 2017
Hi all, (hackathon participants - I am adding 4 more people to this topic) Niels, Shane, Arnd & Sebastian have ween talking about a similar project == I have included the last stage of their discussion here == so maybe you can use some of their ideas. And so that you know that there is even more need for this project to succeed! Guys, scroll down a lot to see what Samer & Cristian have suggested -- or check here the list archives; and give your feedback /requirements... https://www.ripe.net/ripe/mail/archives/ipv6-hackathon/2017-October/000041.html https://www.ripe.net/ripe/mail/archives/ipv6-hackathon/2017-October/000045.html I hope that there will be more useful results to share after the hackathon... Here is also some mesh-networking SW that might help: https://wiki.techinc.nl/index.php/MeshNet#Software Vesna > Hi all, > > This sounds really good! Maybe it would be good to map the > different use cases we want to show, which would help us to > understand what technical approach (as suggested by Arnd) would be > most effective. > > Different concepts / issues I wanted to bring about is: > > 0. Concept of Packet Switching > 1. TCP IP > 2. DNS > 3. IPv4 > 4. IPv6 > 5. BGP > 6. BGP hijacking (adverserial route announcement) > 7. DNS > 8. DNSSEC > 9. DANE > 10 Censorship > 11. TLS/SSL > 12. Peering > 13. DDoS > 14. Censorship > Application Layer > - HTTP Request Header Identification > - Server > Transport Layer > - TCP/IP Header Identification > - Protocol Identification > Dechnical Interferece > - Packet dropping > - Performance degradation > > The question after this would be: > > What hosts would be represented? > > I had in my mind three different autonomous systems on a board, > linked through BGP, and an IXP, where two AS's have peering > agreements and with one AS we can show the role of the IXP in > peering. > > I am also cc-ing Shane, who might also be interested in this nice > little project (and with whom I worked on refugeehotspot.net). > > Looking forward to discuss! > > Best, > > Niels > > PS Sorry for the short mail, am doing ICANN + IETF these weeks, so > everything a bit rushed (but very enthusiastic!) > > > On Fri, Nov 04, 2016 at 03:29:48PM +0100, A.P. Marijnissen wrote: >> Hello >> >> <SNIP> >> >>>> >>>> Whether we do this in software (virtualization) or in hardware format, I >>>> think it would be hugely beneficial to be able to simulate the Internet >>>> for policy people and (relative) technical newbies. The idea is to have >>>> a board on which hosts, routers, ASs, BGP, and potential other devices >>>> are reflected and people are able to implement different policies and >>>> see how this impact the (LED colored) packet flow. >>>> >> >> </SNIP> >> >> This is the part Vesna and me have been talking about . >> >> Our premise when discussing this was to have a hardware version that >> consists of a board/sheet/panel with actual physical >> objects/machines/raspberry-pi's on it that'd allow you to set up >> internet-infrastructure and have it be a way to 'show what happens', >> preferably with visualization of packet-flow. >> >> >> >> One of the things that'd really be *good* visualization, after all, is >> to indicate a packet being SENT from one side; but also then the OTHER >> side showing that it RECEIVED something. That kind of thing requires >> direction; either static (an arrow) or motion (a procession of leds >> lighting up in direction of traffic-flow). To be able to do that, you >> need to give the observer the opportunity to understand what he/she is >> seeing, and what it means, before having the next event happen. I think >> that's the main challenge in this project. >> >> >> The visualization of packet-flow/direction is the hard part there. Some >> thoughts on 'Doing This Right' below (my favorite is Attempt 4 a,b or c, >> below) >> >> Attempt one: Simple! >> >> The obvious engineering approach is to simply hook up led-strings to the >> RX/TX leds of the interface in question and light up a string of LEDS >> that lead from one node's interface to another node's interface. >> >> That'd work fine; of course.. and is a super-simple hack to 'make things >> blink'; but that's about all it'll do. Remember that interfaces are >> 100mBit nowadays; so a full BGP-conversation will last less than a >> couple of miliseconds or so. >> >> Attempt two: wait.. what if.. >> >> So, let's imagine we 'slow things down' a bit by simply having the RX/TX >> blinks be trigger-events for turning the led-string on for a longer >> period; let's say anything up to 2 seconds or so. >> >> What'd be the result ? Well; if a route propagation floods through the >> network; the whole board'd light up for a moment or two and that'd show >> exactly the right kinda thing. But a next update of any protocol coming >> within that time-frame would keep the board lighted up; resulting in it >> being just 'on all the time'... hmmm >> >> >> But... wait it's worse: are those the only kinds of packets going over >> an ethernet-network ? >> No, we'll have ARP and stuff like that ..They'd have the board flash >> right up on regular intervals right through trying to display the actual >> conversation of stuff we're interested in showing... That's going to get >> in the way. >> >> Attempt three: We'll fix it in software! >> >> Okay.. so, simply pinning a bit of hardware onto things isnt optimal. So >> what if: >> 1: Take internet software (bgp, ospf, whatever) >> 2: patch it to run slower >> 3: patch it to control leds do 'smoke and mirror' flashing in a pattern >> we want to have people see >> 4:... >> 5:.profit ? >> >> >> This approach'd basically involve taking all the tools you'd ever want >> to show off and patch 'm in a way that they contain delays and slowdowns >> so that people can 'see what's going on' and then add some way of >> controlling LED-strings to show off the right kind of pattern for what's >> going on. >> >> Do-able; but the approach is burdened by having to know which things >> you'll ever want to show off and to be able to actually patch these >> things to include the required changes.. Not-so-great. Next to >> hardware-work, you add a lot of software-work to the project. >> Ontop of this, if anyone asks 'Oh, but.. what'd it look like if we ran >> X/Y/Z on this.. Or have you tried doing it with Q..' , you have no way >> of satisfying the audience (and your own) curiosity. >> >> >> Attempt four: There is no spoon...back to 1980 speeds! >> >> Here's my favorite approach, so far. >> What if we found a way to provide *unpatched, normal internet tools* >> access to a network-device that we could control the operational >> parameters of in such a way that we can: >> >> - Slow them down to speeds less than tens-of-bytes/s >> - Simulate connection-failures >> - Simulate packet-loss and packet-mangling (crc-errors) >> >> >> That'd solve the problem of things happening faster than you can follow >> with the human eye. It'd provide ways of adding buttons/knobs/whatever >> to simulate flapping connections and all kinds of other cool things. >> >> Then, let's see; what if we: >> a) Use ethernet connections and use a tcpdump and have it trigger a LED >> for incoming packets of the right type; indicating incoming traffic. >> >> OR >> >> b) Use ethernet connections and simply use the RX-leds of either side >> (this'll also show ARP traffic; but perhaps that's a good tradeoff vs. >> the much simpler engineering required) >> >> c) use not Ethernet but Serial Line connections between the devices. >> This has a couple of other advantages: most small computer-boards dont >> have many Ethernet ports available. For routers, it's kinda useful to >> have at LEAST two on each board; after all. Serial-lines, however, are >> easily added via USB or even just 'broken out' from some onboard >> pinheader. You can then also stick extra hooks into the serial-line >> handler or PPP or whatever, to handle control of the LEDS. >> >> >> >> I think that Attempt Four, either B or C really hits the most nails in >> the most flexible and interesting ways possible. >> >> As for 'running it all in VM's.... well.. 'If it aint hardware, it aint >> much.' is all i'll reply to that. Yes, you can make an overview of >> virtual network-streams and make 'm blink the proper lines/etc on a >> display, projected onto a wall. The issue there is with having people >> really 'feel that it's real'; which is kinda the thing this was/is >> supposed to achieve. >> >> That, and I'm better with a soldering-iron than with an IDE >> -- >> Arnd > > -- > > Niels ten Oever > Head of Digital > > Article 19 > www.article19.org > > PGP fingerprint 8D9F C567 BEE4 A431 56C4 > 678B 08B5 A0F2 636D 68E9 > On 30/10/2017 20:28, Cristian Sirbu wrote: > Hi Samer, all, > > I love the teaching angle of this project and it's quite similar to an > idea I came up with for a previous hack. This got me thinking that maybe > we can create some modules that would be used by both at the hackathon. > > The idea I'm talking about is called Pocket Internet > (https://github.com/inognet/pocketinternet) and what it aims to do is > bring up an infinitely scalable topology that interconnects small pods > (ISPs) into an organically grown network (the Internet). Each pod design > would be based on a blueprint inspired from real life SPs and be as > lightweight as possible while still allowing for enough > policy/complexity to be built in. The goal of it is to provide labs for > teaching BGP and Automation tools, but it could also be a test-bed for > new BGP features or anycast type applications. > > I didn't propose this idea for this hackathon because I thought it was > more focused on BGP and routing (both v4 and v6 of course) than on IPv6 > itself, but your project description actually opened my eyes: the > Internet is not only about routing, at a minimum the pocket would need > some clients + DNS and Web servers (e.g. simple websites with CDN > content)! And being able to also simulate some delay/loss in transit > would be great for showcasing what happens in browsers with dual-stack > connectivity for example. > > My initial experiments have been with Docker containers running BIRD and > a predefined layout... you mentioned Mininet and it may be just the > thing for interconnecting them and simulating traffic conditions (or > perhaps https://github.com/thombashi/tcconfig). After a bit of searching > it seems there's a fork called https://containernet.github.io/ that > allows Docker containers to run inside mininet, which would be an > interesting way to deploy various services in addition to routing: DNS, WWW. > > The project would need some way to visualize the topology as it > grows/shrinks - one of the ideas was that by using templated pods you > could scale it to any number of participants (students or trainees) or > complexity in a dynamic way as long as you had the resources to run > additional containers (or money in the case of IaaS :) ). > > I'll stop here for now, would love to hear everyone's thoughts + is it > interesting, what could we achieve in the two days of frantic coding we > have ahead of us etc. ? > > Cheers, > Cristian > > > On Sun, Oct 29, 2017 at 1:27 PM, Samer Lahoud <samer.lahoud at usj.edu.lb > <mailto:samer.lahoud at usj.edu.lb>> wrote: > > Dear all, > > I would like to propose a project that consists of rapidly deploying > an IPv6 testing platform that can be used in student labs (or also > in professional training). > > The description below is a first draft, I will be glad to receive > any comments and modifications if you feel interested in the project > outcome. > > ==== > In a typical student lab, we would like to analyse the transition > from IPv4 to IPv6, the coexistence of the two versions, and also the > interaction with different applications. Let us take for example an > IPv4/IPv6 dual stack HTTP server, a dual stack DNS server, an IPv4 > only HTTP server, and an IPv6 only HTTP server. Playing with such > servers will enable students to understand different challenges > related to the transition from IPv4 to IPv6. For instance, when I > type www.example.com <http://www.example.com> in my browser, what > will be the formulated DNS queries? When my PC receives two DNS > replies, what HTTP/TCP connection will it try first? etc. > > My proposed idea is to use Mininet to automatically deploy the IPv4 > and/or IPv6 servers (Mininet http://mininet.org creates a realistic > virtual network, running real kernel, switch and application code, > on a single machine). Then, this (virtual) server platform can be > bridged with any hardware platform (for example student PCs, quagga > routers, etc.) to obtain a full Lab workbench. > > Some additional outcomes of the proposed project can consist of > writing a basic lab (with questions and answers) to promote the > platform, and also exploring some SDN functionalities enabled by the > use of Mininet. > ==== > > If my proposed project is not retained, I will be glad to join > efforts in designing an automatic tool that computes the AS-path > inflation between IPv4 and IPv6 paths in the current DFZ routing > table or maybe computing for each country the percentage of IPv6 > AS-paths originating and terminating in the country but crossing > ASes from other countries. > > Best regards, > Samer Lahoud. > ---- > Samer Lahoud > Professeur associé > Université Saint-Joseph de Beyrouth > ESIB - Laboratoire CIMTI > Tel: (+961) 1 421 339 <tel:%28%2B961%29%201%20421%20339> > > _______________________________________________ > ipv6-hackathon mailing list > ipv6-hackathon at ripe.net <mailto:ipv6-hackathon at ripe.net> > https://lists.ripe.net/mailman/listinfo/ipv6-hackathon > <https://lists.ripe.net/mailman/listinfo/ipv6-hackathon> > > > > > -- > Cristian Sirbu > www.trueneutral.eu <http://www.trueneutral.eu> > twitter.com/cmsirbu <http://twitter.com/cmsirbu> > > PGP 2C94 0C28 08F2 378F 45C7 4E11 8AFA 4E29 710D 0D66 > > > _______________________________________________ > ipv6-hackathon mailing list > ipv6-hackathon at ripe.net > https://lists.ripe.net/mailman/listinfo/ipv6-hackathon >