SpaceNet AG Joseph-Dollinger-Bogen 14 80807 München – Homenet multi-Router, multi-ISP – automagisch! Gert Döring, SpaceNet AG, München

SpaceNet AG • Joseph-Dollinger-Bogen 14 • 80807 München – http://www.space.net/

Homenet

multi-Router, multi-ISP –

automagisch!

Gert Döring, SpaceNet AG, München

Heise IPv6-Konferenz, 22.05.2014, Frankfurt


Inhalt

• „niemand braucht zu Hause mehr als einen Router“

• … und wenn doch?

• DHCPv6-PD („klassisch“)

• CableLabs´ hipnet

• homenet („die Zukunft“?)

• „Proof of Concept“-Test mit OpenWRT


Green ISP

Blue ISP

Internet

Green ISPRouter

Ein Router ist genug!

Ein „typisches“ Heim-Netz:• Enduser-ISP• 1 dynamische IPv4-Adresse extern• privates Netz mit DHCP intern• „off the shelf“-Heimrouter mit NAT

NAT

192.168.1.x


Green ISP

Blue ISP

Internet

Router

Green ISPRouter

Ein Router ist genug?

192.168.1.x

192.168.10.x

Zwei kaskadierteRouter funktionierenbei IPv4 „dank“ NAT– aber „eher zufällig“,und auch nur „one-way“

IPv6 hat keinNAT-by-default,also geht das damitsowieso nicht –neue Ansätzesind gefragt

NAT

NAT

192.168.1.x

Zweiter Router als „WLAN-Access-Point“


Mehr Router!

Green ISP

Blue ISP

Internet

Router

Green ISPRouter

Router

LTE/UMTS

ZigBee/6LoPANGateway

Internet of ThingsHeating & Light,

Power Meter

Multi-Router-Szenarien z.B. fürAusfallsicherheit,Technologiewechsel,Gastnetz, ...


Green ISP

Internet

Router

Green ISPRouter

Router

Routerkaskade mit IPv6, „klassisch“• Router verteilen (immer kleiner

werdende) IPv6-Prefixe per DHCPv6-Prefix Delegation (PD)

• Auf jedem Link ein /64, per RA oder DHCPv6 an Hosts kommuniziert

• Strikte Top-Down-Struktur nötig• Eindeutige Default-Route

DHCPv6-PD2001:608:5::/56

2001:608:5:1::/64RA: 2001:608:5:0::/64

DHCPv6-PD

2001:608:5:10::/60DHCPv6-PD?

RA: 2001:608:5:11::/6420

01:6

08:5

:12:

:/64

DH

CP

v6-P

D20

01:6

08:5

:18:

:/62

2001:608:4:1a::/64

???

Umgang mit redundanten

Links (Schleifen) ist nicht definiert.


Routerkaskade mit IPv6, „klassisch“

• Kaskadierte Router mit IPv6 heute schon machbar…• strikte Hierarchie in Richtung ISP

• DHCPv6 Prefix Delegation verteilt kleiner werdende Netzblöcke

• Router verteilen daraus /64s auf ihre Interfaces

• aber…• strikte Baumstruktur nötig

• kein Support für Multihoming (mehrere ISPs)

• kein sinnvolles Handling von Topologie- oder Prefix-Änderungen

• nicht Teil der „IPv6 CPE“ spec (RFC7084)

• kaum Support für „Server-Seite“ in Home-Routern*

• kein Konzept für „Naming-Support im Homenet“ (mDNS)


CableLabs / Hipnet

• „near term future routers for the home“:• saubere Topologie-Erkennung, auch wenn Schleifen

vorkommen („LAN-Ports von zwei Routern zusammengesteckt“)

• automatische Erkennung von „LAN“ und „WAN“-Ports, aka „directionless routers“

• ohne dafür ein Routing-Protokoll zu brauchen

• multihoming (nur) als active/backup (mit renumbering)

• service discovery / naming: multicast forwarding

• https://ripe66.ripe.net/presentations/115-HIPnet_RIPE66.pdf


Green ISP

Blue ISP

Internet

Router

Green ISPRouter

Blue ISPRouter

Router

CableLabs / Hipnet

RS?

RS

?

RS?

RS?

RS?RS?

RS

?

RA!

RA!R

A!

up

up

Router schickt auf allen(!) Ports Router Solicitations

und DHCPv6-PD-Requests.Antwort bestimmt „up“-Port

Bei mehreren Möglichkeiten entscheidet u.A. angebotene Präfix-Länge und Bandbreite

RS?

RA!

Router-Solicitation undDHCPv6-PD-SOLICIT

Router-Advertisementund DHCPv6 ADVERTISE


Green ISP

Blue ISP

Internet

Router

Green ISPRouter

Blue ISPRouter

Router

CableLabs / Hipnet

RS?

RS

?R

S?

RS?

RA!

RA!R

A!

up

up

RS?

up

up

RA!RA!RA!

RA!

DHCPv6-PD

DHCPv6-PD

DHCPv6-PDRA!

Sind mehrere„down“-Portszusammen-geschaltet,sehen ClientsRAs von allenRoutern

WiFi-Ports sind niemalsKandidaten für „up“-Port

Hipnet-Ansatz erzeugt „eindeutige“ TopologiePrefix-Verteilung wieder mit DHCPv6-PD + RA

RA!


CableLaps / Hipnet

• Probleme mit dem „Hipnet“-Ansatz:• kein wohldefinierter „Keepalive“-Mechanismus, um Router-

Ausfall zu erkennen (active/backup)• kein Update-Mechanismus für „neue Informationen“

• könnte man über DHCPv6 „RECONFIGURE“ und kurze RA-Intervalle lösen

• nur active/backup multihoming• primärer und sekundärer ISP-Router müssen sich „sehen“

(damit Backup-Router inaktiv wird)• multi-level DHCPv6-PD führt zu starkem Verschnitt• LANs mit mehreren Routern nicht arbitriert, d.h. Clients sehen

mehrere Router und mehrere Prefixe• Naming (mDNS) über Multicast-Forwarding. „Besser als nichts“,

hat aber keine Conflict-Resolution („InkJet“ – ja, aber welcher?)


Homenet

• Was ist „Homenet“?• Working-Group der IETF, die sich genau mit der

Frage beschäftigt „wie soll ein typisches Home-Netz zukünftig aussehen?“

• auto-konfigurierend (Adressen & Naming)

• multihoming mit mehreren Providern

• keine Scheu vor „Routingprotokollen“

• Fokus auf IPv6, Support von IPv4 „soweit möglich“

• http://datatracker.ietf.org/wg/homenet/

• http://datatracker.ietf.org/doc/draft-ietf-homenet-arch/


Homenet: The Protocols

• zum ISP:• RS/RA, DHCPv6-PD – „wie immer“

• im Homenet:• HNCP als „Information Flooding“-Protokoll

(erste Entwürfe mit OSPFv3)

• verteilter Algorithmus für Prefix-Vergabe (/64)

• hybrid mDNS + DNS für „Naming“

• Source/Destination-Address-Routing, entweder als Teil von HNCP, oder extern (Babels, OSPFv3, …)

• RA, DHCPv6 für Kommunikation mit Hosts – „wie immer“


Green ISP

Internet

Router

Green ISPRouter

Router

Homenet – single-homed

ext

RS?

RA!

Router-Solicitation, DHCPv4-und DHCPv6-PD-SOLICIT

Router-Advertisement, DHCPv4und/oder DHCPv6 ADVERTISE

RS?

RS?

RS?RS?

RA!

RS?

RS

?R

S?

RS?

RS?

• Homenet-Router sind ebenfalls „directionless“• Ports, auf denen ein DHCPv4- oder -v6-Request (SOLICIT) beantwortet wird, sind EXTERN• DHCP-Request von Homenet-Routern werden ignoriert(!)• Ports mit (authentisierten*) HNCP-Neighbours sind INTERN• auf internen Port werden RAs gesendet und DHCPv4/v6-Requests von Hosts beantwortet• auf internen Ports werden RA ignoriert(!)• auf externen Ports wird (ggf.) Firewall und IPv4-NAT aktiviert

ext

HNS HNCP NetworkState Update

HNS

HNSHNS

HN

S

HNS

HN

S

HNS

HNSDHCPv6-PD

HNCP in sync

Anders als bisher erfolgt Prefix-Verteilung im „Homenet“ nicht mehr über DHCPv6-PD...

HNS


Green ISP

Internet

Router

Green ISPRouter

Router

DPDP

Homenet – single-homed

extDHCPv6-PD

Delegated Prefix:2001:608:5:200::/56DNS: 2001:608::2

RA!

RA!

RA!

RA!

• ISP weist Prefix (wie gehabt) per DHCPv6-PD zu• im Homenet wird Prefix-Information an alle Router geflooded• jeder Router wählt daraus ein zufälliges /64 pro Interface• collision-check über flooding im Home-Net

• auf jedem Link vergibt nur ein Router (DR) ein Prefix• sobald /64 vergeben ist, können Hosts per RA informiert werden• Administrator darf statische /64-Prefixe vergeben

AP R2AP R2

Assigned Prefix (Router R2)2001:608:5:26d::/64

Jeder Router vergibt auf Basis der externen Prefix-Infos eigenständig /64s, keine Hierarchie

RA!

RA! Router-Advertisement, DHCPv4und/oder DHCPv6 ADVERTISE


Homenet – HNCP im Detail

• Every router has a Router ID and a set of data in TLV form, building this routers's "NodeState" data set. For less computionally intensive comparison, a hash value of this NodeState data is built, H(R).

• this NodeData is data like "which neighbour routers exist on which link" (intrinsic to HNCP) or "which prefixes have been assigned by upstream routers" ("external" data used by protocols on top of HNCP)

• In steady state (synchronized):

• each router knows the NodeState for all other routers

• each router periodically publishes a "NetworkState Update" message, which consists of a hash of (all individual NodeState hashes). This update is sent by link-local multicast on all links.

• as every router has the same state, the NetworkState hash will be the same on every router, so comparison of "are we all in sync?" is very easy, just the hash needs to be compared

• If a router has new information (like: new prefix from upstream), it updates its NodeState data, increments its serial number, calculates a new hash H(R), and a new NetworkState hash. Then it sends the new H(H) value out

• each neighbour will notice that the hash values do no longer match, and request a detailed list of individual router hashes + serial numbers (NetworkState Request) by link-local unicast message

• by comparing hashes and serial numbers, the router will know which router has updated its data, and request an update for this router's data from the publishing neighbour (NodeData Request), again by link-local unicast message

• then, this newly updated router will update its local copy of the announcing router's NodeData with all new information, build a new NetworkState hash, and publish the new hash in a NetworkState Update multicast message

• the next neighbours "further down" in the network will now see the updated NetworkState hash, and come back querying for the updated NodeData.

• In other words: updated information is only flooded by means of a change in the NetworkState hash, and optionally NodeData hash, but the actual update is unicast-pulled by each neighbour who does not yet have it.

• The use of a NetworkState hash and serial numbers for each individual NodeData hash avoids the need to have a global "Network serial number“ and ACKed TLA updates etc. to get the network synchronized


Green ISP

Blue ISP

Internet

Router

Green ISPRouter

Blue ISPRouter

Router

Homenet – multi-homed: Prefixe

ext

ext

DHCPv6-PD

RA!

RA!

RA!

RA!RA!

RA! Router-Advertisement, DHCPv4und/oder DHCPv6 ADVERTISE, Green ISP

DHCPv6-PD

RA

!

Delegated Prefix:2001:470:721f::/52DNS: 2001:470:20::2

DP

DP

DP

DPDPDP

DP Delegated Prefix, Blue ISP

RA!

RA!

RA!

RA!

RA

!

RA!

2001:608:5:26d::/64

2001:470:721f:f78::/64

10.48.211.0/24

2001:608:5:2a1::/64

2001:470:721f:5f1::/64

10.163.63.0/24

Jeder Link hat ein /64 von jedem Upstream-ISP (1x blau, 1x grün), dazu noch IPv4 und ggf. ULA


Green ISP

Blue ISP

Internet

Router

Green ISPRouter

Blue ISPRouter

Router

Homenet – multi-homed: Routing

ext

ext

defaultdefault default

defa

ult

default

default

defaultdefaultdefault

default

default

Default-Routing im Homenet muß (wegen ISP-Filter nach BCP38) abhängig von Source-IP sein

default Default-Route

default

default

Default-Route für grüne Source-IPsDefault-Route für blaue Source-IPs

2001:608:5:2a1::beef2001:470:721f:5f1::babe

• PCs mit mehreren globalen IPv6-Adressen• ISPs mit Source-Adress-Filter (Anti-Spoofing, BCP38)• wie funktioniert Default-Routing?


Homenet – multihomed (3)

• Multihoming in Homenet bedeutet:• alle Devices haben mehrere globale IPv6-Adressen

• Router müssen Pakete Source-IP-abhängig forwarding

• für abgehende Verbindungen wählt jedes Gerät für jede Verbindung anhand der verwendeten Source-Adresse aus,über welchen ISP die Verbindung gehen soll

• Kontrolle beim End-User, nicht beim Router oder ISP

• session-survivability über shim6, sctp oder mp-tcp

• für eingehende Verbindung wird ISP über Ziel-Adresse gewählt (d.h. über DNS kontrollierbar)

• „das wird nie funktionieren!!“• (Anm. am Rande: das ist auch nur für Home-Netze gedacht)


Multi-Address Multihoming

geht nicht?

zu kompliziert?

verstehen die User nicht?

Image taken from Mark Townsley‘s homenettalk at RIPE 67 and used with permission


Multi-Address Multihoming

Client wählt den zu verwendenden ISP über Source-Adresse

volle Kontrolle durch Benutzer, z.B. via Browser-Plugin


Multi-Address Multihoming: missing pieces

• Für „nimm das, was am besten geht“:• Source-Address-Failover bzw. Source-Address-Probing und –

Caching („happy eyeballs 2“)• ietf-mif-happy-eyeballs-extension

• Für „Anwendung X soll (nur) über ISP Y laufen“:• eine einfach(!!) zu verwaltende globale Policy-Tabelle, mit der

man seine Präferenz je nach Anwendung konfigurieren kann (vgl. iOS)

• einen Mechanismus, über den man an ein IPv6-Prefix ein Label kleben kann („SpaceNet“, „Telekom“) – z.B. via DHCPv6, via RA, oder via „well-defined lookups“

• draft-lepape-6man-prefix-metadata, draft-korhonen-6man-prefix-properties,draft-bhandari-dhcp-class-based-prefix

• direkter API-Support in Anwendungen, die ihre User selbst fragen möchten („SpaceNet“, „HE.Net“, „beides versuchen“)


Homenet – andere Aspekte• Naming und Service Discovery

• mDNS + DNS „hybrid“

• jeder Router lernt (und antwortet) via mDNS, steckt das Ergebnis in eine lokale DNS-Zone, die über HNCP bei allen anderen Routern delegiert wird

• lokaler DNS-Recursor kennt Namen und Zonen

• draft-stenberg-homenet-dnssd-hybrid-proxy-zeroconf

• draft-cheshire-mdnsext-hybrid

• Sicherheitsmodell mit „voll authentisierten“ Homenet-Routern (optional!)• Anmeldung z.B. über „pairing mit Smartphone-Hilfe“

• HNCP sieht cryptographisch starke Hashes und Signaturen bereits vor

• draft-behringer-homenet-trust-bootstrap

• Interaktion mit Hipnet- oder RFC7084-CPEs• Homenet-Router bieten DHCPv6-PD und DHCPv4 für Downstream-Router

• Service-Discovery und „Homenet hinter RFC7084“ sind „schwierig“

• draft-winters-homenet-sper-interaction


Homenet – Implementationen?

• Beispielimplementation auf Basis von OpenWRT• install OpenWRT „trunk“

• # opkg update && opkg install hnet-full

• # vi /etc/config/network config interface ´hlan´ option interface ´eth1´ option proto ´hnet´ config interface ´hwan´ option interface ´eth0´ option proto ´hnet´

• # /etc/init.d/network reload

• http://www.homewrt.org/doku.php


Homenet - Testnetz

Testplattform: OpenWRT „barrier breaker“ (trunk r40576), vom 02.05.2014

TP-Linktl-1043nd v2

TP-Linktl-wdr3600

TP-Linktl-wdr36003x TP-Linktl-wdr3600

Blue ISP:Cisco 1841 mitHE.Net-Tunnel

Green ISP:SpaceNet


Homenet - Testnetz

IP-Adress-Distribution für blaues und grünes IPv6-Prefix (und IPv4) funktioniert!

root@BlueISPRouter:~# ip addr show2: eth0: („WAN“) inet 193.149.45.33/29 brd 193.149.45.39 inet6 2001:470:721f:ffff:12fe:edff:fee6:5f33/64 3: eth1: („LAN“) inet 10.0.45.11/24 brd 10.0.45.255 inet6 2001:608:5:24f:12fe:edff:fee6:5f32/64 inet6 2001:470:721f:9a4:12fe:edff:fee6:5f32/64

gert@mobile$ ip addr show2: eth0: inet6 2001:608:5:2a1:21e:33ff:fe28:9069/64 valid_lft 2866sec preferred_lft 1062sec inet6 2001:470:721f:5f1:21e:33ff:fe28:9069/64 valid_lft 3505sec preferred_lft 1703sec inet 10.163.63.153/24 brd 10.163.63.255


Homenet - Testnetz

root@BlueISPRouter:~# ip -6 route |grep defdefault from :: via fe80::21e:f7ff:fe38:afd5 dev eth0default from 2001:470:721f::/52 via fe80::21e:f7ff:fe38:afd5 dev eth0default from 2001:470:721f:ffff::/64 via fe80::21e:f7ff:fe38:afd5 dev eth0default from 2001:608:5:200::/56 via fe80::c24a:ff:febe:77f2 dev eth1

root@R3:~# ip -6 routedefault from :: via fe80::c24a:ff:febe:77f2 dev eth0.2default from 2001:470:721f::/52 via fe80::c24a:ff:febe:77f2 dev eth0.2default from 2001:470:721f:ffff::/64 via fe80::c24a:ff:febe:77f2 dev eth0.2default from 2001:608:0:62::/64 via fe80::c24a:ff:febe:77f2 dev eth0.2default from 2001:608:5:200::/56 via fe80::c24a:ff:febe:77f2 dev eth0.22001:470:721f:e5::/64 dev eth0.32001:470:721f:5f1::/64 dev eth0.12001:470:721f:664::/64 via fe80::c24a:ff:febe:7860 dev eth0.12001:470:721f:69f::/64 via fe80::c24a:ff:febe:7860 dev eth0.12001:470:721f:7a2::/64 dev eth0.22001:470:721f:9a4::/64 via fe80::c24a:ff:febe:77f2 dev eth0.22001:470:721f:c31::/64 via fe80::c24a:ff:febe:77f2 dev eth0.22001:470:721f:eef::/64 via fe80::c24a:ff:febe:77f2 dev eth0.22001:470:721f:f15::/64 via fe80::c24a:ff:febe:7860 dev eth0.12001:470:721f:f78::/64 via fe80::c24a:ff:febe:7860 dev eth0.1unreachable 2001:470:721f::/52 dev lo2001:608:5:23c::/64 dev eth0.32001:608:5:24f::/64 via fe80::c24a:ff:febe:77f2 dev eth0.22001:608:5:26d::/64 via fe80::c24a:ff:febe:7860 dev eth0.12001:608:5:26e::/64 via fe80::c24a:ff:febe:77f2 dev eth0.22001:608:5:2a1::/64 dev eth0.12001:608:5:2a7::/64 dev eth0.22001:608:5:2ab::/64 via fe80::c24a:ff:febe:7860 dev eth0.12001:608:5:2bd::/64 via fe80::c24a:ff:febe:7860 dev eth0.12001:608:5:2ce::/64 via fe80::c24a:ff:febe:77f2 dev eth0.22001:608:5:2f4::/64 via fe80::c24a:ff:febe:7860 dev eth0.1unreachable 2001:608:5:200::/56 dev lofe80::/64 dev eth0.1fe80::/64 dev eth0.2fe80::/64 dev eth0.3

root@GreenISPRouter:~# ip -6 route |grep defdefault from :: via fe80::214:1cff:fed2:30c0 dev eth0.2default from 2001:470:721f::/52 via fe80::12fe:edff:fee6:5f32 dev eth0.1default from 2001:470:721f:ffff::/64 via fe80::12fe:edff:fee6:5f32 dev eth0.1default from 2001:608:0:62::/64 via fe80::214:1cff:fed2:30c0 dev eth0.2default from 2001:608:5:200::/56 via fe80::214:1cff:fed2:30c0 dev eth0.2

root@R2:~# ip -6 route |grep defdefault from :: via fe80::c24a:ff:febe:77f2 dev eth0.5default from 2001:470:721f::/52 via fe80::c24a:ff:febe:77f2 dev eth0.5default from 2001:470:721f:ffff::/64 via fe80::c24a:ff:febe:77f2 dev eth0.5default from 2001:608:0:62::/64 via fe80::c24a:ff:febe:77f2 dev eth0.5default from 2001:608:5:200::/56 via fe80::c24a:ff:febe:77f2 dev eth0.5

Routing im Homenet abhängig von Ziel und Source-Adresse des Pakets


Homenet - Testnetz

Routing im Homenet abhängig von Ziel und Source-Adresse des Pakets

traceroute to www.heise.de from 2001:608:5:2a1:21e:33ff:fe28:9069 1 R3.eth0_1.R3.home (2001:608:5:2a1:c24a:ff:fe38:ecba) 2 GreenISPRouter.eth0_3.GreenISPRouter.home (2001:608:5:2ce:c24a:ff:febe:77f2) 3 Cisco-M-Vlan62.Space.Net (2001:608:0:62::ffff) 4 Cisco-M-XVI-Vlan11.Space.Net (2001:608:0:11::111) 5 Cisco-M-LI-Te1-1-v23.Space.Net (2001:608:0:e77::229) 6 Cisco-F-VI-Te1-5.Space.Net (2001:67c:158c:1::10) 7 te0-0-2-3.c150.f.de.plusline.net (2001:7f8::3012:0:1) 8 te7-2.c101.f.de.plusline.net (2a02:2e0:12:19::101) 9 2a02:2e0:3fe:ff21:c::2 (2a02:2e0:3fe:ff21:c::2)10 2a02:2e0:3fe:ff21:c::2 (2a02:2e0:3fe:ff21:c::2)

default

defaultdefault

default

default

default

Pakete „ins Internet“ laufen entweder nach rechts zum GreenISP oder nach oben zum BlueISPRouter, je nach Source-Adresse

traceroute to www.heise.de from 2001:470:721f:5f1:21e:33ff:fe28:9069 1 R3.eth0_1.R3.home (2001:470:721f:5f1:c24a:ff:fe38:ecba) 2 GreenISPRouter.eth0_5.R2.home (2001:470:721f:c31:c24a:ff:febe:77f2) 3 BlueISPRouter.eth1.BlueISPRouter.home (2001:470:721f:9a4:12fe:edff:fee6:5f32) 4 2001:470:721f:ffff::ffff (2001:470:721f:ffff::ffff) 5 cron2-1.tunnel.tserv6.fra1.ipv6.he.net (2001:470:1f0a:ae6::1) 6 v399.core1.fra1.he.net (2001:470:0:69::1) 7 te0-0-2-3.c150.f.de.plusline.net (2001:7f8::3012:0:1) 8 te1-3.c102.f.de.plusline.net (2a02:2e0:12:20::102) 9 2a02:2e0:3fe:ff12:c::1 (2a02:2e0:3fe:ff12:c::1)10 2a02:2e0:3fe:ff12:c::1 (2a02:2e0:3fe:ff12:c::1)

defa

ult


Letzte Worte

• „Heim-Netze mit mehr als einem Router“ existieren, und werden in Zukunft eher häufiger anzutreffen sein

• die existierenden Lösungen (RFC7084- und Hipnet-CPEs) sind nicht allgemein genug einsetzbar

• die Homenet-Architektur ist zwar noch relativ jung, überzeugt aber bereits durch „running code“

• wichtig ist im nächsten Schritt die Akzeptanz und Implementierung durch „normale“ Router-Hersteller

• ... und die IPv6-Experten sollten aufhören,Lösungen mit „einem Routingprotokoll imHeim-Netz“ als „das wird nie was“ totzureden

• ... dann wird‘s auch was


Referenzen

• Homenet:

• http://datatracker.ietf.org/wg/homenet/

• http://datatracker.ietf.org/doc/draft-ietf-homenet-arch/

• draft-stenberg-homenet-hncp-00.txt• draft-pfister-homenet-prefix-assignment-00.txt• draft-stenberg-homenet-dnssd-hybrid-proxy-zeroconf-00.txt• draft-kline-homenet-default-perimeter-00.txt• draft-ietf-mif-happy-eyeballs-extension-04.txt• draft-v6ops-ipv6-multihoming-without-ipv6nat-06.txt RFC7157

• http://www.homewrt.org/ - Implementation (für OpenWRT)

• Hipnet:• http://www.cablelabs.com/the-future-of-home-networking-putting-the-hip-in-hipnet

• http://tools.ietf.org/id/draft-grundemann-hipnet-00.txt

• https://ripe66.ripe.net/presentations/115-HIPnet_RIPE66.pdf


Finis

• Noch Fragen? Jederzeit gerne an [email protected]

• die SpaceNet AG…• Internet Service Provider seit 1994• Ihr Partner für komplexe Hosting-Lösungen• IPv6-Erfahrung seit 1997• http://www.space.net (natürlich mit IPv6!)

Documents

SpaceNet AG Joseph-Dollinger-Bogen 14 80807 München – Homenet multi-Router, multi-ISP – automagisch! Gert Döring, SpaceNet AG, München