1. Router Advertisements for Routing between Moving Networks draft-petrescu-autoconf-ra-based-routing-00.txt Presenter: Alexandru Petrescu IETF 78 Maastricht 26 July 2010, MEXT Working Group Slide 1

2. Outline Problems: MIP6 Route Optimization, and Vehicular-to-Vehicular communications in the absence of infrastructure ICMPv6 extension Topology and Message Exchange Diagrams Conceptual Algorithm on MR3; scalability Differences from draft-jhlee-mext-mnpp-00 Other recent remarks (from AUTOCONF, MEXT and private). Implementation Slide 2

3. Problems MR1 LFN MR2 LFN Internet HA2HA1 MR1 LFN MR2 LFN Route Optimization between Moving Networks (typical): Moving to Network to Moving Network when infrastructure is absent (e.g. vehicular formings: cars, wagons, convoy, tow) ? Slide 3

4. ICMPv6 Extension Router Advertisement is a message format defined in [RFC4861] as an ICMPv6 message. The document [RFC5175] proposes an option for RA extensibility: IPv6 Router Advetisement Flags Option. We propose to reserve bit 16 for Mobile Network Prefixes. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length |M| Bit fields available... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... for assignment | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 'M' - Mobile Network Prefix present. Set to 1 if this Router Advertisement contains a Mobile Network Prefix. If the RA Flags Option contais the flag M, and set to 1, then the Router Advertisement MUST contain a Route Information Option [RFC4191] followed optionally by a Source-Link Layer Address Option [RFC4861]. (If this SLLAO option is used then it avoids the necessity of doing NS/NA exchange for the link-local address of the Gateway entry in the data structure mentioned earlier.) Slide 4

5. Topology and Message Exchange Diagrams 2001:db8:3::/64 egress MR1 Net1 LFN11 MR3 Net3 LFN31 WiFi essid: “V3” channel: 9 mode: managed fe80::MR1_egress 2001:db8:1::/64 fe80::MR3_egress fe80::MR1_ingressfe80::MR3_ingress eth0 2001:db8:2::/64 egress MR2 Net2 LFN21 WiFi essid: “V2” channel: 9 mode: managed fe80::MR2_egress fe80::MR2_ingress eth0 WiFi essid: “V1” channel: 9 mode: managed Simultaneous MLD “JOIN” MR1MR2MR3 RA1: RA3: RA2: Phase 1 Phase 2 Simultaneous power-up of 3 MRs. Slide 5 WiFi essid: “V2V” channel: 3 mode: ad-hoc

6. More Message Exchange Diagrams MR1MR2MR3 MLD “JOIN” RA1: RA3: RA2: RS MR1MR2MR3 RA1 used for deletion MNP1, flag ‘D’, or lifetime ‘0’ Upon receipt of this RA, MR2 and 3 delete their routes for MNP1 from their routing tables. MR1MR2MR3 RA1: RA2: RS Timeout Deletion Renewal, eventually Arrival of MR3 in a setting of MR1 and MR2. Timed out expiration and deletion. Explicit deletion. Slide 6

7. Conceptually – an Algorithm on MR3 (1)Send an RA containing the prefix(es) allocated to its subnets to which the ingress interfaces are connected (2) "Join" the all-routers multicast address with link-scope, on its egress interface (3) Send a Router Solicitation (RS) on its egress interface requesting RAs from MR1 and MR2 (4) Receive their special RAs: RA1 and RA2 (5) For each received RA, extract the source address and the prefixes and insert the corresponding number of routing table entries; these entries will help reach the LFNs in the moving networks of MR1 and MR2. Slide 7

8. Scalability Dst prefixGatewayDev 2001:db8:2::/64fe80::MR2_egressegress 2001:db8:3::/64fe80::MR3_egressegress 2001:db8:n::/64fe80::MRn_egressegress 2001:db8:1::/64« connected »ingress Routing table on MR1 MR1 LFN11 MR2 LFN12 LFN1n LFN21 LFN22 LFN2m MR3 LFN21 LFN22 LFN2m MRn LFN11 LFN12 LFN1n Number of entries equals the number of Mobile Routers at the scene. Dst prefixGatewayDev 2001:db8:1::/64« connected »eth0 defaultfe80::MR1_ingresseth0 Routing table on LFN11 Number of entries is constant. Slide 8

9. Security Example risk: attacker MR claims towards other MRs that it owns the MNP of a victim MR – victim MR no longer receives its traffic. More threats. Is SeND appropriate. Certificates when PKI infrastructure is absent. Ongoing work. Slide 9

10. Additional scenarios: arrival of a router, deletion of entries (MNPP doesn’t); Cases with or without Access Point (MNPP) – cases exclusively without AP (this draft). Differences from draft-jhlee-mext-mnpp-00 Slide 10

11. Deletion: how does MR know it will leave? Obscurely written rt update Format of RS message? (any extension?) Security: this introduces more risks than rfc3756; need to use certs. Need of text describing use cases [Jong-Hyouk] Bug in distinctor of prefixes (/64 instead of /24). Use of distinctive ESSIDs on egress and ingress interfaces. Use of link-local addresses (notation, pertinence) How is MNP provided initially? Adapted to MEXT or AUTOCONF? [AUTOCONF member] Remarks from WG lists Slide 11

12. Wrong email address of a co-author Private Remarks Slide 12

13. Implementation Extensions to ICMP Router Advertisements sent on the egress interface Implementation on linux with radvd 1.4 Packet Dissectors for Wireshark, for the packet formats Link-layer security on egress using WPA-NONE PSK TKIP/AES (yes, it is secure); and WEP too some times. Slide 13

14. Thanks in advance to the note takers! Comments Slide 14