IPv6-Fragen (DHCP und DNS im lokalen Netz)

[Thomas Hochstein]

Moin.

Getreu dem Motto, es gebe keine dummen Fragen, werde ich mal eine
Reihe solcher - rund um IPv6 - stellen. Meine diesbezüglichen
Kenntnisse sind bedauerlicherweise recht theoretisch und ziemlich
lückenhaft.

Es geht mir dabei darum, wie ich ein bestehendes IPv4-DHCP-/DNS-Setup
in meinem lokalen Netz möglichst weitgehend auf IPv6 übertragen kann.

Status quo
----------

Die Verbindung des lokalen Netzes nach außen übernimmt eine FRITZ!Box
7490, die vom Provider eine IPv4- und IPv6-Adresse sowie ein
/56er-Netz IPv6 bekommt. Für IPv4 macht sie NAT, für IPv6 nur
Firewalling. Der eingebaute DHCP-Server ist deaktiviert.

DHCP und DNS macht eine Linux-Maschine im lokalen Netz (BIND und
ISC-DHCP-Server).

Der DHCP-Server teilt bekannten Geräten anhand ihrer MAC eine
statische IP-Adresse zu (nach einer bestimmten Systematik, aber das
ist letztlich Spielerei); für diese Adressen und die zugehörigen
Hostnamen übernimmt der lokale DNS-Server die Vorwärts- und
Rückwärtsauflösung. Der DHCP-Server teilt allen Geräten als DNS-Server
diesen lokalen DNS-Server mit.

Unbekannte Geräte bekommen eine dynamische Adresse aus dem Pool
(Lease) und werden (vorwärts und rückwärts, d.h. mit A und PTR) ins
lokale DNS eingetragen.

Ziel
----

Ich möchte erreichen, dass

1) alle bekannten Geräte auch eine statische IPv6-Adresse erhalten
2) die Vorwärts- und Rückwärtsauflösung für bekannte Geräte auch für
IPv6 funktioniert
3) alle Geräte meinen lokalen DNS-Server als DNS verwenden.

Bonus wäre

4) Vorwärts- und Rückwärtsauflösung füt IPv6 auch für unbekannte
Geräte

Überlegungen
------------

Wie schon geschrieben verstehe ich von IPv6 eher wenig, obschon ich
bereits vor vielen Jahren etliches darüber gelesen und gehört habe.

ad 1):

Wenn ich richtig informiert bin, ist dort Autokonfiguration
vorgesehen: den "hinteren" Teil der Adresse [0] erzeugt der Rechner
aus seiner MAC, den Prefix bekommt er. [1] Das würde heißen, dass Ziel
1) bereits systemimmanent erreicht ist? [2]

ad 2):

Wie bekomme ich dann die DNS-Auflösung hin? Ist für die der Prefix
egal? *grübel* Kann ich also einfach den "hinteren Teil" - der ja aus
der MAC ableitbar ist - in passende Zonen verklöppeln?

ad 3):

Wie übermittele ich per DHCP, dass auch per IPv6 mein lokaler Server
als DNS-Server verwendet weden soll?

Für die Bonusfrage habe ich noch überhaupt keinen Plan.

Gibt es Ideen oder konkrete Leseempfehlungen (URL)?

Ist der Gedanke konzeptionell völlig bescheuert?

Danke im voraus!

-thh

[0] Wie nennt man den richtig?

[1] Wie eigentlich? Irgendwas tut da wohl die FRITZ!Box ...

[2] Könnte ich trotzdem selbst eigene Adressen vergeben? Ggf. wie?
Wäre das sinnvoll?

[Thomas Hochstein]

Moin.

Getreu dem Motto, es gebe keine dummen Fragen, werde ich mal eine
Reihe solcher - rund um IPv6 - stellen. Meine diesbezüglichen
Kenntnisse sind bedauerlicherweise recht theoretisch und ziemlich

lückenhaft. (Und ist das hier die richtigen Gruppe? Falls nicht, wäre
ich für einen Hinweis dankbar.)

vorgesehen: den Suffix der Adresse erzeugt der Rechner
aus seiner MAC, den Prefix bekommt er vom Router, hier also der
FRITZ!Box. Das würde heißen, dass Ziel
1) bereits systemimmanent erreicht ist? [1]

ad 2):

Wie bekomme ich dann die DNS-Auflösung hin? Ist für die der Prefix
egal? *grübel* Kann ich also einfach den "hinteren Teil" - der ja aus

der MAC ableitbar ist - in passende Zonen verklöppeln? Oder lässt sich
das bei regelmäßiger Änderung des Prefix gar nicht sinnvoll machen?

ad 3):

Wie übermittele ich per DHCP, dass auch per IPv6 mein lokaler Server
als DNS-Server verwendet weden soll?

Für die Bonusfrage habe ich noch überhaupt keinen Plan.

Gibt es Ideen oder konkrete Leseempfehlungen (URL)?

Ist der Gedanke konzeptionell völlig bescheuert?

Danke im voraus!

-thh

[1] Könnte ich trotzdem selbst eigene Adressen vergeben? Ggf. wie?
Wäre das sinnvoll?
--
/'\ --- JOIN NOW! ---
\ / ASCII ribbon campaign
X against HTML
/ \ in mail and news

[Ralph Aichinger]

Thomas Hochstein <t...@inter.net> wrote:

> Ich möchte erreichen, dass
>
> 1) alle bekannten Geräte auch eine statische IPv6-Adresse erhalten

Das wird schwer, sehr schwer, zumindest wenn du Android-Geräte hast.

Lies dir

https://code.google.com/p/android/issues/detail?id=32621

und weine. Ja, bestimmt kann man irgendeinen hochkomplexen Workaround
basteln.

> 2) die Vorwärts- und Rückwärtsauflösung für bekannte Geräte auch für
> IPv6 funktioniert

OK

> 3) alle Geräte meinen lokalen DNS-Server als DNS verwenden.

OK

> 4) Vorwärts- und Rückwärtsauflösung füt IPv6 auch für unbekannte
> Geräte

Sollte auch realisierbar sein, zumindes wenn kein Android dabei ist.
Microsoft macht IIRC beim Rückwärtsauflösen irgendwelche Extrawürste
oder sabotiert es eventuell teiweise. Frag mich nicht nach Details,
nur als Warnung da genauer hinzusehen.

> Wenn ich richtig informiert bin, ist dort Autokonfiguration
> vorgesehen: den Suffix der Adresse erzeugt der Rechner
> aus seiner MAC, den Prefix bekommt er vom Router, hier also der
> FRITZ!Box. Das würde heißen, dass Ziel
> 1) bereits systemimmanent erreicht ist? [1]

Sinnvoller ist IMHO eine Zuteilung per DHCPv6 wenn das Ziel
statische IPv6 sind die möglichst wenig sperrig sind.
Ich finde bei der Fehlersuche eine Adresse wie
2a02:ab8:201:5b1::8 sehr viel schmerzloser als z.B.
2a02:ab8:201:5b1:e1ee:583b:d299:96bc, vor allem wenn man weiß
daß im internen Netz das Prefix immer 2a02:ab8:201:5b1 ist
(als Beispiel, bei dir heißt es anders).

Android wird man einstweilen nicht dazu kriegen, DHCPv6 zu
machen, aber sonst geht es mit allen relevanten Endgeräten.

> Wie bekomme ich dann die DNS-Auflösung hin? Ist für die der Prefix
> egal? *grübel* Kann ich also einfach den "hinteren Teil" - der ja aus
> der MAC ableitbar ist - in passende Zonen verklöppeln? Oder lässt sich
> das bei regelmäßiger Änderung des Prefix gar nicht sinnvoll machen?

Wenn du wirklich eine Liste mit statischen Adressen haben willst,
dann kannst du das wie bei v4 machen, entweder mit dynamischen
Einträgen die der DHCP-Server übernimmt, oder per statischen
AAAA-Einträgen für alle Hosts im Netz. So wie in der guten alten
Zeit vor NAT, als jeder Rechner im Netz einfach eine "richtige"
IP und einen DNS-Eintrag gehabt hat. Reverse geht ebenfalls so.
Als Textfiles, oder meinetwegen irgendwelche Datenbankbackends
oder was auch immer.

> ad 3):
>
> Wie übermittele ich per DHCP, dass auch per IPv6 mein lokaler Server
> als DNS-Server verwendet weden soll?

Da Android DHCPv6 ignoriert solltes du zweierlei machen.

Einerseits per DHCPv6 den DNS verteilen. Ich mache das derzeit mit
dhcpy6d, einem DHCPv6-Server so:

nameserver = 2a02:ab8:201:5b1::1
domain_search_list = h5.or.at local

Andererseits solltes du für (mindestens) Android auch SLAAC
vollständig konfigurieren. Bei mir übernimmt das radvd, ich glaub
eh die Standardlösung für SLAAC. Das ist mein ganzes Konfigurationsfile
am Router:

interface eth0
{
AdvSendAdvert on;
AdvLinkMTU 1280;
AdvManagedFlag on;
MinRtrAdvInterval 15;

RDNSS 2a02:0ab8:0201:05b1::1 {};
DNSSL h5.or.at local {};
};

Einigermaßen sinnvoll ist es vermutlich das was DHCPv6 rausschickt
mit dem was SLAAC verbreitet synchron zu halten.

Ah ja, und weil Google einen auf stur macht was DHCPv6 betrifft, will
sich Microsoft nicht lumpen lassen, und setzt auch etwas nicht um,
nämlich diese Verbreitung von DNS-Servern per SLAAC, aka RFC6106.
Microsoft pusht sehr stark DHCPv6, Google pusht sehr stark SLAAC.

Apple und Linux unterstützen beides, und verursachen relativ
weniger Schmerzen.

> Gibt es Ideen oder konkrete Leseempfehlungen (URL)?

Kauf dir "IPv6-Workshop" von Dan Lüdtke. Ist das Geld wert.

> Ist der Gedanke konzeptionell völlig bescheuert?

Nö, ganz im Gegenteil.

/ralph

[Juergen P. Meier]

Thomas Hochstein <t...@inter.net>:

> Getreu dem Motto, es gebe keine dummen Fragen, werde ich mal eine
> Reihe solcher - rund um IPv6 - stellen. Meine diesbezüglichen
> Kenntnisse sind bedauerlicherweise recht theoretisch und ziemlich
> lückenhaft. (Und ist das hier die richtigen Gruppe? Falls nicht, wäre
> ich für einen Hinweis dankbar.)

Eigentlich nur soweit es Unix betrifft.

> Es geht mir dabei darum, wie ich ein bestehendes IPv4-DHCP-/DNS-Setup
> in meinem lokalen Netz möglichst weitgehend auf IPv6 übertragen kann.

IPv6 kennt drei Varianten Hosts zu konfigurieren:

1) SLAAC ohne DHCP
2) SLAAC mit DHCP
3) DHCP

(eigentlich sinds vier: die vierte ist "manuell konfiguriert")

Nur die dritte Variante entspricht dem, was bei IPv4+DHCP ueblich war.

Mit SLAAC gibts nur eine IP-Adresse und Prefix-information.
Das Gateway lernt man bei IPv6 per ND/RD.

In Option 2 wird DHCP nur fuer zusaetzliche Paraemter (DNS setup, NTP,
Proxy, Zeitzone, etc.pp.) verwendet, die IP gibts per SLAAC.

In Variante 3 dann macht DHCP alles, was es bei IPv4 schon gemacht hat.

Bei Variante 1 gibts kein DNS-Setup. DNS muss man dann per Multicast
(mDNS) machen, denn man lernt keine DNS-Server. Die gibts nur per DHCP.

Ueblich ist Variante 2 wenn man kein IP-Adressmanagement hat,
ansonsten Variante 3.

> Status quo
> ----------
>
> Die Verbindung des lokalen Netzes nach außen übernimmt eine FRITZ!Box
> 7490, die vom Provider eine IPv4- und IPv6-Adresse sowie ein
> /56er-Netz IPv6 bekommt. Für IPv4 macht sie NAT, für IPv6 nur
> Firewalling. Der eingebaute DHCP-Server ist deaktiviert.

Die /56er netze verteilt sie als /64 weiter.
Die Fritzbox kann DHCPv6 (macht sie im Default).

> DHCP und DNS macht eine Linux-Maschine im lokalen Netz (BIND und
> ISC-DHCP-Server).

Hast du auch einen DHCPv6 Server?

> Der DHCP-Server teilt bekannten Geräten anhand ihrer MAC eine
> statische IP-Adresse zu (nach einer bestimmten Systematik, aber das

Wenn du das auch bei v6 willst, musst du Variante 3) machen.
Das kann die Fritzbox IIRC nicht, die macht nur Variante 2.

> ist letztlich Spielerei); für diese Adressen und die zugehörigen
> Hostnamen übernimmt der lokale DNS-Server die Vorwärts- und
> Rückwärtsauflösung. Der DHCP-Server teilt allen Geräten als DNS-Server
> diesen lokalen DNS-Server mit.

Schon deswegen wirst du den DHCPv6-Server in der Fritzbox ausschalten
muessen.

> Unbekannte Geräte bekommen eine dynamische Adresse aus dem Pool
> (Lease) und werden (vorwärts und rückwärts, d.h. mit A und PTR) ins
> lokale DNS eingetragen.
>
> Ziel
> ----
>
> Ich möchte erreichen, dass
>
> 1) alle bekannten Geräte auch eine statische IPv6-Adresse erhalten

Variante 3): Kein SLAAC und DHCPv6 mit Adresszuweisung.

> 2) die Vorwärts- und Rückwärtsauflösung für bekannte Geräte auch für
> IPv6 funktioniert
> 3) alle Geräte meinen lokalen DNS-Server als DNS verwenden.
>
> Bonus wäre
>
> 4) Vorwärts- und Rückwärtsauflösung füt IPv6 auch für unbekannte
> Geräte

DAs kommt bei Varainte 3) dann automatisch, wenn der DHCP server DNS
eintraege schreiben darf.

> Überlegungen
> ------------
>
> Wie schon geschrieben verstehe ich von IPv6 eher wenig, obschon ich
> bereits vor vielen Jahren etliches darüber gelesen und gehört habe.
>
> ad 1):
>
> Wenn ich richtig informiert bin, ist dort Autokonfiguration
> vorgesehen: den Suffix der Adresse erzeugt der Rechner
> aus seiner MAC, den Prefix bekommt er vom Router, hier also der
> FRITZ!Box. Das würde heißen, dass Ziel
> 1) bereits systemimmanent erreicht ist? [1]

Das ist Variante 1 bzw. 2: SLAAC.
SLAAC ist aber optional, der Router der den Prefix announced kann es
(per Flag in den RA paketen) explizit verbieten und DHCPv6
IP-Adressvergabe vorschreiben. (das muesste die Fritzbox machen)

> ad 2):
>
> Wie bekomme ich dann die DNS-Auflösung hin? Ist für die der Prefix
> egal? *grübel* Kann ich also einfach den "hinteren Teil" - der ja aus
> der MAC ableitbar ist - in passende Zonen verklöppeln? Oder lässt sich
> das bei regelmäßiger Änderung des Prefix gar nicht sinnvoll machen?

Ohne DHCP Adressvergabe kein automatisches DNS. (oder du erlaubst
jedem Client die Zone zu schreiben und laesst alle Clients ihre Namen
selbst updaten. Eine Dumme Idee[tm] wenn du nicht allen Clients
vollstens vertrauen kannst).

> ad 3):
>
> Wie übermittele ich per DHCP, dass auch per IPv6 mein lokaler Server
> als DNS-Server verwendet weden soll?

So wie bei IPv4, als DHCP Option (ist die gleiche Option).

> Für die Bonusfrage habe ich noch überhaupt keinen Plan.
> Gibt es Ideen oder konkrete Leseempfehlungen (URL)?

> Ist der Gedanke konzeptionell völlig bescheuert?

Nein.

> Danke im voraus!

HTH

> [1] Könnte ich trotzdem selbst eigene Adressen vergeben? Ggf. wie?
> Wäre das sinnvoll?

Auch mit SLAAC kannst du trotzdem eigene Adressen verwenden. IPv6
schreibt DAD vor, so dass Kollisionen immer sofort entdeckt werden.

Juergen
--
Juergen P. Meier - "This World is about to be Destroyed!"
end
If you think technology can solve your problems you don't understand
technology and you don't understand your problems. (Bruce Schneier)

[Juergen P. Meier]

Ralph Aichinger <r...@pi.h5.or.at>:

>> 1) alle bekannten Geräte auch eine statische IPv6-Adresse erhalten
>
> Das wird schwer, sehr schwer, zumindest wenn du Android-Geräte hast.
>
> Lies dir
>
> https://code.google.com/p/android/issues/detail?id=32621

Wie was, die Android-teile koennen kein DHCPv6? was ist dass denn fuer
ein Schrott?

Sind wir noch in den 90ern oder was?

> und weine. Ja, bestimmt kann man irgendeinen hochkomplexen Workaround
> basteln.

Android-Geraete auf die Blackliste und in ein eigenes SSID isolieren.
Da kann man sie dann mit Windows XP und anderen Praehistorischem Zeug
zusammen stecken, das die Jahrtausendwende verschlafen hat.

> Einigermaßen sinnvoll ist es vermutlich das was DHCPv6 rausschickt
> mit dem was SLAAC verbreitet synchron zu halten.

Wenn SLAAC fuer Legacy-Devices wie Androide und Windows XP gemacht wird,
muss und wird niemand sonst per DHCP eine IP Adresse annehmen.
Dann gibts einfach gar keine statischen Zuweisungen.

> Ah ja, und weil Google einen auf stur macht was DHCPv6 betrifft, will
> sich Microsoft nicht lumpen lassen, und setzt auch etwas nicht um,
> nämlich diese Verbreitung von DNS-Servern per SLAAC, aka RFC6106.

Das ist ja auch eine reichlich daemliche Idee, Funktionen die nach
DHCP gehoeren *UND* dort bereits implementiert sind, halbgar und
unvollstaendig in ein Protokoll zu zwaengen, das dafuer von Anfang an
*ausdruecklich* nicht vorgesehen ist.
Typisch fuer die Neue Art der Problemloesung: lieber ungeschickte
Workarounds als eine Loesung.
Jon Postel rotiert bei sowas nur noch in seinem Grab.

Nein, da muss ich Microsoft beipflichten, solch dummen Unfug zu
boycottieren ist die einzig Richtige[tm] Entscheidung.

> Microsoft pusht sehr stark DHCPv6, Google pusht sehr stark SLAAC.
> Apple und Linux unterstützen beides, und verursachen relativ
> weniger Schmerzen.

Ach. Kaum haelt man sich an Standards, schon funktioniern Dinge.

Was fuer eine Ueberraschung.

[Ralph Aichinger]

Juergen P. Meier <nospa...@jors.net> wrote:
> Ralph Aichinger <r...@pi.h5.or.at>:
>>> 1) alle bekannten Geräte auch eine statische IPv6-Adresse erhalten
>>
>> Das wird schwer, sehr schwer, zumindest wenn du Android-Geräte hast.
>>
>> Lies dir
>>
>> https://code.google.com/p/android/issues/detail?id=32621
>
> Wie was, die Android-teile koennen kein DHCPv6? was ist dass denn fuer
> ein Schrott?
>
> Sind wir noch in den 90ern oder was?

Das schlimmste ist: Sie sind auch noch stolz drauf. Man kann mutmaßen
was die wahre Intention dahinter ist, daß sie es nicht umsetzen können
schließe ich mal aus. Ich nehme an, die Idee ist den lokalen Admins
das "Verwalten" möglichst schwer zu machen, und Android-Geräte zu
möglichst opaken "Black Boxes" werden zu lassen. Dazu paßt auch z.B.
der unterschiedliche Umgang mit im DHCP mitgeschickten Hostnamen
zwischen Apple und Google: Bei Apple meldet sich ein Telefon als
"Susis iPhone" oder "Mimis iPad" oder so ähnlich an. Bei Google
ist man "andoid-a4da3888a0d2" und wenn man 100 Telefone im WLAN hat
dann haben die alle derartige UUID-änliche Strings dahinter. Erleichtert
Fehlersuche und Remote-Support ungemein.

> Android-Geraete auf die Blackliste und in ein eigenes SSID isolieren.
> Da kann man sie dann mit Windows XP und anderen Praehistorischem Zeug
> zusammen stecken, das die Jahrtausendwende verschlafen hat.

So in die Richtung.

> Wenn SLAAC fuer Legacy-Devices wie Androide und Windows XP gemacht wird,
> muss und wird niemand sonst per DHCP eine IP Adresse annehmen.
> Dann gibts einfach gar keine statischen Zuweisungen.

Ich hab hier beides aufgedreht, eventuell hab ich noch an irgendwelchen
Flags gedreht (man kann IIRC per SLAAC sagen, daß DHCPv6 beachtet werden
soll) und eigentlich geht das recht transparent auf allen Plattformen,
egal ob Windows (7 bis 10), oder Linux (NetworkManager). Auch mitgebrachte
iPhones von Gästen scheinen keine Probleme zu haben. Man hat halt beide
Adressen: Die "schöne" DHCPv6-Adresse und die zufällige SLAAC-Adresse.
Erstere scheinti in der Realität wenn vorhanden bevorzugt verwendet zu werden.
Das ganze funktioniert IMHO in der Praxis ganz gut. Wenn irgendwelche
versteckten Gefahren lauern, dann würde ich gerne mehr drüber wissen.

Und ja: Android ignoriert das alles und will IIRC alles über SLAAC, d.h.
beim DNS bin ich mir nicht sicher, aber die Adresse kann man ihm nicht per
DHCPv6 mitteilen.

> Das ist ja auch eine reichlich daemliche Idee, Funktionen die nach
> DHCP gehoeren *UND* dort bereits implementiert sind, halbgar und
> unvollstaendig in ein Protokoll zu zwaengen, das dafuer von Anfang an
> *ausdruecklich* nicht vorgesehen ist.

Man könnte es auch pragmatisch sehen: Wenn man das ganze als 2x2-Matrix
aufzeichnet (Adresse und DNS jeweils per DHCPv6 oder SLAAC) dann ignoriert
Google die eine Spalte und Microsoft immerhin auch noch ein Feld. Es verlangt
ja niemand daß es per default aktiviert werden soll, aber eine Option sollte
es sein (Apple fällt ja auch kein Zacken aus der Krone). Vor allem in kleineren
Netzwerken könnte man dann alles per SLAAC erschlagen.

/ralph

[Marc Haber]

"Juergen P. Meier" <nospa...@jors.net> wrote:

>Mit SLAAC gibts nur eine IP-Adresse und Prefix-information.
>Das Gateway lernt man bei IPv6 per ND/RD.

Ich könnte also SLAAC abschalten und trotzdem ein Gateway lernen? Wie
muss ich den radvd dazu konfigurieren?

Ich hab nämlich das Problem, dass meine Systeme zusätzlich zu ihrer
lokal statisch konfigurierten Adresse noch eine per SLAAC lernen und
diese dann bevorzugen. Und natürlich hat diese Adresse keinen
DNS-Eintrag und wird deswegen abgewiesen.

|2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
| link/ether 52:54:00:93:ff:c8 brd ff:ff:ff:ff:ff:ff
| inet 192.168.181.100/24 brd 192.168.181.255 scope global eth0
| valid_lft forever preferred_lft forever
| inet6 2001:db8:0:3281:5054:ff:fe93:ffc8/64 scope global
| valid_lft 86204sec preferred_lft 14204sec
| inet6 2001:db8:0:3281::64:100/64 scope global
| valid_lft forever preferred_lft forever
| inet6 fe80::5054:ff:fe93:ffc8/64 scope link
| valid_lft forever preferred_lft forever

Die SLAAC-Adresse manuell auf deprecated zu setzen funktioniert
neuerdings nicht mehr, das wird beim nächsten RA überschrieben.

>In Option 2 wird DHCP nur fuer zusaetzliche Paraemter (DNS setup, NTP,
>Proxy, Zeitzone, etc.pp.) verwendet, die IP gibts per SLAAC.

Statische IP?

>In Variante 3 dann macht DHCP alles, was es bei IPv4 schon gemacht hat.

Und wenn der DHCP-Server nicht da ist gibt es keine IP und man kommt
auch nicht auf die Endsysteme drauf?

>Bei Variante 1 gibts kein DNS-Setup. DNS muss man dann per Multicast
>(mDNS) machen, denn man lernt keine DNS-Server. Die gibts nur per DHCP.

RDNSSD, oder IPv4.

>DAs kommt bei Varainte 3) dann automatisch, wenn der DHCP server DNS
>eintraege schreiben darf.

Welchen DHCP-Server empfiehlst Du? Geht das dann auch redundant? Gibt
es ein dhcrelay für IPv6 oder kann man dafür das normale dhcrelay
verwenden? Was müssten kommerzielle Rotuer können, um DHCPv6 zu
relayen?

Grüße
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

[Marc Haber]

Ralph Aichinger <r...@pi.h5.or.at> wrote:
>Das schlimmste ist: Sie sind auch noch stolz drauf. Man kann mutmaßen
>was die wahre Intention dahinter ist, daß sie es nicht umsetzen können
>schließe ich mal aus. Ich nehme an, die Idee ist den lokalen Admins
>das "Verwalten" möglichst schwer zu machen, und Android-Geräte zu
>möglichst opaken "Black Boxes" werden zu lassen. Dazu paßt auch z.B.
>der unterschiedliche Umgang mit im DHCP mitgeschickten Hostnamen
>zwischen Apple und Google: Bei Apple meldet sich ein Telefon als
>"Susis iPhone" oder "Mimis iPad" oder so ähnlich an. Bei Google
>ist man "andoid-a4da3888a0d2" und wenn man 100 Telefone im WLAN hat
>dann haben die alle derartige UUID-änliche Strings dahinter. Erleichtert
>Fehlersuche und Remote-Support ungemein.

Erkläre nie mit Bosheit, was Du auch mit Dummheit oder Desinteresse
erklären kannst. Apples Geräte sind einfach eindrucksvoll gut
durchdacht. Googles Geräte sind einfach nur auf den schnellen Dollar
ausgelegt.

[Marc Haber]

Ralph Aichinger <r...@pi.h5.or.at> wrote:
>Man hat halt beide
>Adressen: Die "schöne" DHCPv6-Adresse und die zufällige SLAAC-Adresse.
>Erstere scheinti in der Realität wenn vorhanden bevorzugt verwendet zu werden.

ja, genau das ist ein Problem.

[Ralph Aichinger]

Marc Haber <mh+usene...@zugschl.us> wrote:
> Ich hab nämlich das Problem, dass meine Systeme zusätzlich zu ihrer
> lokal statisch konfigurierten Adresse noch eine per SLAAC lernen und
> diese dann bevorzugen. Und natürlich hat diese Adresse keinen
> DNS-Eintrag und wird deswegen abgewiesen.
>
> |2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
> | link/ether 52:54:00:93:ff:c8 brd ff:ff:ff:ff:ff:ff
> | inet 192.168.181.100/24 brd 192.168.181.255 scope global eth0
> | valid_lft forever preferred_lft forever
> | inet6 2001:db8:0:3281:5054:ff:fe93:ffc8/64 scope global
> | valid_lft 86204sec preferred_lft 14204sec
> | inet6 2001:db8:0:3281::64:100/64 scope global
> | valid_lft forever preferred_lft forever
> | inet6 fe80::5054:ff:fe93:ffc8/64 scope link
> | valid_lft forever preferred_lft forever
>
> Die SLAAC-Adresse manuell auf deprecated zu setzen funktioniert
> neuerdings nicht mehr, das wird beim nächsten RA überschrieben.

Ich bin mir nicht sicher, ob ich an meinem Setup was gedreht habe,
aber da habe ich das gegenteilige Verhalten. Die Programme binden lokal
an die per DHCPv6 verteilte Adresse und nicht an die von SLAAC.

10: wl0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 74:da:38:88:a0:d2 brd ff:ff:ff:ff:ff:ff
inet 10.0.17.8/24 brd 10.0.17.255 scope global dynamic wl0
valid_lft 10526sec preferred_lft 10526sec
inet6 2a02:ab8:201:5b1::8/128 scope global
valid_lft forever preferred_lft forever
inet6 2a02:ab8:201:5b1:e1ee:583b:d299:96bc/64 scope global noprefixroute dynamic
valid_lft 7156sec preferred_lft 1756sec
inet6 fe80::4124:ac99:fc63:9bd5/64 scope link
valid_lft forever preferred_lft forever
ralph@blau:~$ ssh pi
ralph@pi's password:

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Mon Aug 29 21:41:51 2016 from sputnik.h5.or.at
ralph@pi:~$ who --ips
ralph pts/0 2016-08-29 21:40 2a02:ab8:201:5b1::8

/ralph

[Marc Haber]

Ralph Aichinger <r...@pi.h5.or.at> wrote:
>Marc Haber <mh+usene...@zugschl.us> wrote:
>> Ich hab nämlich das Problem, dass meine Systeme zusätzlich zu ihrer
>> lokal statisch konfigurierten Adresse noch eine per SLAAC lernen und
>> diese dann bevorzugen. Und natürlich hat diese Adresse keinen
>> DNS-Eintrag und wird deswegen abgewiesen.
>>
>> |2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
>> | link/ether 52:54:00:93:ff:c8 brd ff:ff:ff:ff:ff:ff
>> | inet 192.168.181.100/24 brd 192.168.181.255 scope global eth0
>> | valid_lft forever preferred_lft forever
>> | inet6 2001:db8:0:3281:5054:ff:fe93:ffc8/64 scope global
>> | valid_lft 86204sec preferred_lft 14204sec
>> | inet6 2001:db8:0:3281::64:100/64 scope global
>> | valid_lft forever preferred_lft forever
>> | inet6 fe80::5054:ff:fe93:ffc8/64 scope link
>> | valid_lft forever preferred_lft forever
>>
>> Die SLAAC-Adresse manuell auf deprecated zu setzen funktioniert
>> neuerdings nicht mehr, das wird beim nächsten RA überschrieben.
>
>Ich bin mir nicht sicher, ob ich an meinem Setup was gedreht habe,
>aber da habe ich das gegenteilige Verhalten. Die Programme binden lokal
>an die per DHCPv6 verteilte Adresse und nicht an die von SLAAC.

Ob das an DHCPv6 gegen statisch konfigurier liegt? Oder pur nach der
Reihenfolge (DHCPv6 langsamer als SLAAC, SLAAC langsamer als "statisch
konfiguriert", die letzte gewinnt)?

Ausprobieren kann man das nicht mehr, in systemd-networkd bringt man
nirgends mehr einfach ein sleep unter.

[Sven Geggus]

Thomas Hochstein <t...@inter.net> wrote:

> 1) alle bekannten Geräte auch eine statische IPv6-Adresse erhalten

Das wird nur funktionieren, wenn das /56er Prefix statisch ist.

Bei gewöhnlichen Telekom xDSL Anschlüssen ist das nicht der Fall.

Gruss

Sven

--
Das Internet ist kein rechtsfreier Raum, das Internet ist aber auch
kein bürgerrechtsfreier Raum. (Wolfgang Wieland Bündnis 90/Die Grünen)

/me is giggls@ircnet, http://sven.gegg.us/ on the Web

[Juergen P. Meier]

Sven Geggus <use...@fuchsschwanzdomain.de>:

> Thomas Hochstein <t...@inter.net> wrote:
>
>> 1) alle bekannten Geräte auch eine statische IPv6-Adresse erhalten
>
> Das wird nur funktionieren, wenn das /56er Prefix statisch ist.
>
> Bei gewöhnlichen Telekom xDSL Anschlüssen ist das nicht der Fall.

Statischer Hostpart reicht. Der Prefix ist dann dynamisch.

Bei DHCP ist das einfach, bei manuell muss man ein bisschen tricken je
nach OS.

[Juergen P. Meier]

Sven Geggus <use...@fuchsschwanzdomain.de>:

> Thomas Hochstein <t...@inter.net> wrote:
>
>> 1) alle bekannten Geräte auch eine statische IPv6-Adresse erhalten
>
> Das wird nur funktionieren, wenn das /56er Prefix statisch ist.
>
> Bei gewöhnlichen Telekom xDSL Anschlüssen ist das nicht der Fall.

Statischer Hostpart reicht. Der Prefix ist dann dynamisch.

Bei DHCP ist das einfach, bei manuell muss man ein bisschen tricken je
nach OS.

Aber im Grunde sollte man die ISPs wie Telekom und Co. in den Arsch
treten dass sie solchen dummen Schwachfug ueberhaupt machen.

[Marc Haber]

"Juergen P. Meier" <nospa...@jors.net> wrote:

>Sven Geggus <use...@fuchsschwanzdomain.de>:
>> Thomas Hochstein <t...@inter.net> wrote:
>>
>>> 1) alle bekannten Geräte auch eine statische IPv6-Adresse erhalten
>>
>> Das wird nur funktionieren, wenn das /56er Prefix statisch ist.
>>
>> Bei gewöhnlichen Telekom xDSL Anschlüssen ist das nicht der Fall.
>
>Statischer Hostpart reicht. Der Prefix ist dann dynamisch.
>
>Bei DHCP ist das einfach, bei manuell muss man ein bisschen tricken je
>nach OS.

Erzähl mal.

>Aber im Grunde sollte man die ISPs wie Telekom und Co. in den Arsch
>treten dass sie solchen dummen Schwachfug ueberhaupt machen.

Ohne dynamischen Prefix keine Privacy für Privatkunden. Eigentlich
bräuchte man beides.

[Thomas Hochstein]

Sven Geggus schrieb:

> Thomas Hochstein <t...@inter.net> wrote:
>
>> 1) alle bekannten Geräte auch eine statische IPv6-Adresse erhalten
>
> Das wird nur funktionieren, wenn das /56er Prefix statisch ist.

Das hatte ich befürchtet.

> Bei gewöhnlichen Telekom xDSL Anschlüssen ist das nicht der Fall.

Ich weiß. :)

-thh

[Christoph 'Mehdorn' Weber]

Hallo!

* Thomas Hochstein <t...@inter.net>:

> 1) alle bekannten Geräte auch eine statische IPv6-Adresse erhalten

Zumindest bei Linux basiert das Suffix für SLAAC typischerweise
auf der MAC-Adresse und ist somit automatisch statisch, wenn man
es nicht umschaltet. Und Windows kann man so einstellen. Bisher
genügt mir das so.

> 2) die Vorwärts- und Rückwärtsauflösung für bekannte Geräte auch für
> IPv6 funktioniert

Daran arbeite ich noch. Im Heimnetz habe ich kürzlich etwas mit
dnsmasq experimentiert und generiere einfach neben den statischen
Einträgen für DHCPv4 die Namen zu den MAC-basierten SLAAC-Adressen
gleich mit (per Script, das ich auf Anfrage auch herausgeben
würde; veröffentlichen mag ich es noch nicht, da es noch deutliche
Mängel hat).

> 3) alle Geräte meinen lokalen DNS-Server als DNS verwenden.

Damit habe ich mich noch nicht groß beschäftigt. Man kann ihn im
RA mitgeben, aber das hat sich noch nicht sehr verbreitet.
Momentan posaune ich ihn auch mit Avahi durch die Gegend, und die
Clients, die avahi-dnsconfd haben, lernen ihn ganz nebenbei.

Aber da bisher alle Hosts noch IPv4 haben, verteile ich den
Nameserver derzeit (auch) einfach darüber.


Eigentlich hänge ich mich aber in den Thread, weil ich wissen
möchte, wie ihr das mit Privacy Extensions macht.

Im Prinzip sind die recht interessant, weil die Gegenseite dann
nicht sieht, wer genau aus dem Subnetz anfragt. Statistiken über
Nutzungsgewohnheiten etc. werden erschwert. Wenn man da eine
korrekte Auflösung implementiert (wie auch immer), die wieder
eindeutig auf den Host zeigt, ist der Privacy-Effekt natürlich
weg. Will man nicht.

Alternativ könnte man z.B. bei Bind (vermutlich) mit "Generate"
arbeiten und einfach Dummy-Namen fürs gesamte Subnetz erzeugen.
Und bestimmt gibt es auch eine Möglichkeit, die nur herauszugeben,
wenn gerade keine bessere Adresse existiert, die z.B. fest
eingetragen oder per DNS-Update gelernt wurde. Allerdings bin ich
mir nicht sicher, wie die >= 2^64 Adressen auf die Performanz
wirken.

Oder einfach weglassen? Wobei ich da befürchte, daß manche
Services eingeschränkt sind, denn z.B. bei Spamfiltern bekommt man
gern mal einen höheren Score, wenn die Auflösung nicht möglich ist
oder nicht paßt.

Oder richtet man mit iproute2 und ip6tables für spezielle
Ziel-Ports etc. dann Sonderwürste ein, indem man das auf eine
Routing-Tabelle mit fixer Quell-Adresse verschiebt? Aber IIRC
kann man da jeweils nur komplette Adressen angeben, muß das also
irgendwie verscripten, damit Präfix-Änderungen nachgezogen werden.

Irgendwie fühlt sich das alles häßlich an, weshalb ich Privacy
Extensions momentan auf bestimmten Hosts noch meide, obwohl ich
sie allgemein gern nutzen würde.

Christoph

--
"Kein Weltraum links auf dem Geraet"
(Uebersetzungs-Liste der Fehlermeldungen
in einer unbekannten Produktbeschreibung)

[Juergen P. Meier]

Christoph 'Mehdorn' Weber <spam...@das-mehdorn.de>:

> Hallo!
>
> * Thomas Hochstein <t...@inter.net>:
>
>> 1) alle bekannten Geräte auch eine statische IPv6-Adresse erhalten
>
> Zumindest bei Linux basiert das Suffix für SLAAC typischerweise
> auf der MAC-Adresse und ist somit automatisch statisch, wenn man
> es nicht umschaltet. Und Windows kann man so einstellen. Bisher
> genügt mir das so.

Das ist bei allen Systemen, die SLAAC Standardkonform umsetzen so.
Sogar bei Android hat Google das noch nicht kaputt gemacht.

Das, worauf du zu 99% ansprichst, nennt sich "Privacy Extensions" und
hat mit Anonymitaet des Users nichts zu tun. Das garantiert nur die
Anonymitaet des Endgeraetes selbst (die Privatsphaere des Rechners
wird geschuetzt, nicht die des Anwenders davor!). Dabei wird der
Hostpart per SLAAC nicht aus der modifizierten EUID-64 der MAC Adresse
des Interfaces gebildet, sondern als Zufallszahl erzeugt.

Die uebrigen 1% heissen DAD (Duplicate Address Detection) und sind
ebenfalls Standard. Sie verhindern das z.B. zwei geklonte VMs im
selben VLAN die selbe IP-Adresse nutzen. Eine von beiden wuerfelt sich
wegen DAD eine neue zufaellige Adresse aus. DAD ist bei PE Pflicht,
schliesslich sind die Zufallszahlengeneratoren in vielen Endgeraeten
nicht gut genug.

>> 2) die Vorwärts- und Rückwärtsauflösung für bekannte Geräte auch für
>> IPv6 funktioniert
>
> Daran arbeite ich noch. Im Heimnetz habe ich kürzlich etwas mit

Ohne jedem dahergelaufenen Client DNS-Updates zu erlauben (was
ausserhalb einer isolierten Client-Zone eine Ganz Besonders Dumme
Idee[tm] ist), gilt folgendes:

Das geht mit SLLAC nur bedingt (wenn man eine entsprechende CMDB oder
Asset-DB mit allen erfassten MAC-Adressen hat, die entsprechend
mit dem IPAM System (bzw. DHCP und DNS Server) gekoppelt ist.
Bei PE geht das prinzipiell gar nicht.
Nur bei Infrastrukturseitiger Adressvergabe (M+O Flag im RA, DHCPv6
vergibt die Adressen) geht das ohne DNS-UPdate durch den Client.

Voll unterstuetzt implementiert ist das mit dem DNS-Update uebrigens
nur in Windows. Bei allen anderen OSen musst du das derzeit noch
aussen herum stricken, weil der Kernel selbst (der die Adresswuerfelei
macht) keine DNS-Updates verschickt.

> dnsmasq experimentiert und generiere einfach neben den statischen
> Einträgen für DHCPv4 die Namen zu den MAC-basierten SLAAC-Adressen
> gleich mit (per Script, das ich auf Anfrage auch herausgeben
> würde; veröffentlichen mag ich es noch nicht, da es noch deutliche
> Mängel hat).

Also die erste Bedingung ist erfuellt. (eine CMDB kann auch einfach
nur ein Textfile mit allen Endgeraeten und ihren relevanten
Konfigurationsparametern (sprich: MAC-Adresse) sein ;)

Solange niemand PE nutzt, geht das.

Verhindern kannst du PE nicht solange du SLAAC erlaubst.

>> 3) alle Geräte meinen lokalen DNS-Server als DNS verwenden.
>
> Damit habe ich mich noch nicht groß beschäftigt. Man kann ihn im
> RA mitgeben, aber das hat sich noch nicht sehr verbreitet.

Per experimenteller Erweiterung die bisher niemand ausser Microsoft
implementiert hat? Tolle Wurst.

Dafuer gibts DHCP. Das ist quasi das, wofuer DHCP erfunden wurde.

Du sollst dein Steak ja nicht mit dem Loeffel schneiden, egal wie
scharf du die Loeffelkante gewetzt hast, dafuer nimmt man ein Messer.

> Momentan posaune ich ihn auch mit Avahi durch die Gegend, und die
> Clients, die avahi-dnsconfd haben, lernen ihn ganz nebenbei.

mDNS und SRV-Records. Das ist die selbst-lern-Alternative.

> Aber da bisher alle Hosts noch IPv4 haben, verteile ich den
> Nameserver derzeit (auch) einfach darüber.

DA es um inhaerernt IP-Protokollunabhaengige Dynammische Hosts
Configuration Parameter ist DHCP - egal ueber welches Transportmedium
- natuerlich auch immer genau die eine richtige Wahl dafuer.

> Eigentlich hänge ich mich aber in den Thread, weil ich wissen
> möchte, wie ihr das mit Privacy Extensions macht.

Ich verbiete diesen Dummfug*. Meine Rechner brauchen keine Anonymitaet
in meinem Netz. Ich sorge wenn fuer Anonymitaet der *User*. Und zwar
dort, wo das angebracht ist.

RA: M Flag. Verhindert SLAAC und sperrt ausserdem zu geltenden
Internet-Standards absichtlich vom Hersteller inkompatibel gemachte
Android-Devices aus. Ein durchaus angenehmer Nebeneffekt (YMMV).

Ausserdem muss ich mein Cisco-OnePK Projekt mal wieder Aufnehmen:
"Transparent De-Psydonymization of Privacy-Extension IPv6 Endpoint
Addresses inbound on Access Ports to Access Switches via dynamic NAT66"
Das als Plugin-in fuer die Switch-Software von Access-Switches raeumt
systematisch mit PE Auf und NATtet alle zufalls-Hostparts auf die
jeweilige aus der MAC-Adresse gebildete "richtige" EUI-64 Adresse.
Und auch wenn mein anvisierter Veroeffentlichungstermin nach dem
31 Maerz folgt, will ich dass das Teil voll funktionsfaehig ist.

Muahahahahaha.

> Im Prinzip sind die recht interessant, weil die Gegenseite dann
> nicht sieht, wer genau aus dem Subnetz anfragt. Statistiken über

Im Subnetz selbst sieht die gegenstelle ganz genau wer das ist.
Der Trick mit der Privatsphaere fuer das Endgeraet funktioniert
nur in gerouteten Netzen, wo im Ethernet-Header nicht die MAC-Adresse
des Endgeraets steht.

> Nutzungsgewohnheiten etc. werden erschwert. Wenn man da eine

Man kann sie nicht mehr direkt auf Endgerate herunterbrechen.

Die Dienste dieser Welt sehen also nicht mehr /anhand der IP-Adresse/
mit welchem Gereat Herr W. aus I. genau die Bauanleitung zum
Freifunkgeraet heruntergeladen hat. Sie muessen diese Information dann
wieder - wie bei IPv4 wegen ueberall NAT auch - aus dem
Applikationsprotokoll (HTTP header) ziehen.

IPv6 Privacy Extensions bieten *dir* als *Anwender* keinen Schutz vor
Ueberwachung. Weil in Soho-Netzen der Anwender ueber seinen Prefix
identifiziert wird, nicht ueber die Hostadresse.

Und ob du die Bombenbauanleitung oder die Sturmgewehrbestellung jetzt
von dienem PC, deinem Tablet oder deinem Smartphone im WLAN abgesetzt
hast, interessiert das SEK das gerade Zeitgleich durch deine Haustuere
und dein Balkonfenster bricht nicht die Bohne.

Das Endgeraet wird durch PE verschleihert, nicht der User.
Es ist ein ganz bestimmter Spezialfall, wo die Identitaet des
Endgerates bijektiv mit der Identitaet eines Users verbunden ist.
Diesen Spezialfall findest du ausserhalb eines Uni-Campus oder eines
Enterprise-Netzes jedoch nicht.

Zuviele Leute hoeren nach dem lesen des ersten Wort dieses Begriffs
auf zu denken und bekommen so voellig falsche Vorstellungen. Auch
Leute bei Medien, die ihre falsche Vorstellung dann fleissig verbreiten.

> korrekte Auflösung implementiert (wie auch immer), die wieder
> eindeutig auf den Host zeigt, ist der Privacy-Effekt natürlich
> weg. Will man nicht.

Host != User.

Bei IPv6 und Privathaushalten gilt vielmehr:

User == Prefix.

> Alternativ könnte man z.B. bei Bind (vermutlich) mit "Generate"
> arbeiten und einfach Dummy-Namen fürs gesamte Subnetz erzeugen.

Du muesstest eine halbe Trillionen NAmen generieren. Soviel RAM hat
dein DNS-SErver nicht, um so eine Zone zu laden.

> Und bestimmt gibt es auch eine Möglichkeit, die nur herauszugeben,
> wenn gerade keine bessere Adresse existiert, die z.B. fest
> eingetragen oder per DNS-Update gelernt wurde. Allerdings bin ich
> mir nicht sicher, wie die >= 2^64 Adressen auf die Performanz
> wirken.

Der RAM Verbrauch toetet dich lange vor der Performance.

> Oder einfach weglassen? Wobei ich da befürchte, daß manche
> Services eingeschränkt sind, denn z.B. bei Spamfiltern bekommt man
> gern mal einen höheren Score, wenn die Auflösung nicht möglich ist
> oder nicht paßt.

Ja. Deswegen muss man - wenn man PE zulaesst aber trotzdem diesen
Service bereitstellen will - zwangslaeufig Dynamische DNS-Updates
*vom* Client erlauben. D.h. jeder Client darf Vorwaerts- und
Rueckwaertszonen beschreiben. Eine BEsonders Dumme IDee[tm] wenn man
dafuer keine isolierte Clent-Zone hat.

Fuer Demonstrationszwecke habe ich immer eine gebridgte VM auf der
Platte liegen deren Hostname zufaelligerweise "proxy" lautet.
(das ist idR. ohne bleibende Schaeden demonstrierbar)

Spaetestens der erste Gast, dessen Hostname genauso lautet wie der des
Windows Domaincontrollers, wird dafuer sorgen dass sich jeder ueber
eigene client-Zonen Gedanken macht. Waehrend er das AD wieder
zusammenflickt.

Also: "clients.deine.domain" als DynDNS-zone wo jeder Client (auth per
Subnet o.ae.) selbst seinen Namen mit IPv6-IP registrieren darf, und
schon geht das mit NAmen-zu-IP auch mit SLAAC und sogar PE.

> Oder richtet man mit iproute2 und ip6tables für spezielle
> Ziel-Ports etc. dann Sonderwürste ein, indem man das auf eine
> Routing-Tabelle mit fixer Quell-Adresse verschiebt? Aber IIRC
> kann man da jeweils nur komplette Adressen angeben, muß das also
> irgendwie verscripten, damit Präfix-Änderungen nachgezogen werden.

Auch ein schoen haesslicher Hack.

> Irgendwie fühlt sich das alles häßlich an, weshalb ich Privacy
> Extensions momentan auf bestimmten Hosts noch meide, obwohl ich
> sie allgemein gern nutzen würde.

Wozu? Nein, das ist eine durchaus ernst gemeinte Frage. Was willst du
damit /genau/ erreichen?

[Juergen P. Meier]

Ingrid
[IPv6 PE]

Apropos:

Wo IPv6 PE schlecht fuer den Anwender sind:

* IP-Addressbasiert authentifizierte und autorisierte Benutzer in
Zugriffsbeschraenkten Netzen.
Das sollte Selbsterklaerend sein, denn es gibt Netze wo der Zugang zum
Netz selbst und bestimmten Ressourcen per IP-Adresse autorisiert wird,
mit der sich der Benutzer zuvor Authentifiziert hat (Die Debatte, wie
Dumm das ist bitte woanders fuehren, das aendert nichts daran, das es
in der Praxis leider oft gemacht wird). IPv6 PE sorgen dafuer, dass
der Nutzer eine IP-Adresse nutzt, die nicht autorisiert ist. Do'h

* Session-State auf Applikationsebene der ueber State-Grenzen der
Transport-Schicht und Netzwerkschicht hinausragend gebildet wird.
Es gibt genuegend (derartig dumm implementierte) WEb-Services die die
IP-Adresse in den Session-State eines Endbenutzers mit einbeziehen.
Bei IPv4 merkt man ob der statik seiner IP-Adresse davon idR. nichts.
Nur selten aendert sich da die am Server aufschlagende Client-IP.
Bei IPv6 mit PE hingegen kann der naechste HTTP/TCP-Connect schon von
der gerade neue ausgewuerfelten Temp Addresse kommen, weil der TCP/IP
Stack nichts vom Session-State auf Applikationsebene weis.
Dies gilt auch fuer Services hinter Loadbalancern, die eine
Session-Stickyness anhand der Client-IP-Adresse festmachen (in vielen
Loadbalancerprodukten und Loesungen ein Default).

Wo IPv6 PE gut fuer den Anwender ist:

* In Campus-Netzen wo man eine Identifikation und Verfolgung des
Benutzers eines Devices durch zur Identifikation und Tracking nicht
ermaechtigte Dritte Parteien verhindern moechte.

(Campuse existieren u.A. bei Universitaeten, Schulen, Flughaefen,
Hotels, "Enterprises" (Firmen),...)

Wo IPv6 PE keine signifikante positive Wirkung hat:
* In SoHo-Netzen wo einem Haushalt** genau ein Prefix zugewiesen ist.
* In strukturierten Firmennetzen mit Benutzerauthentifikation auf
ISO/OSI-Ebene 5 und hoeher (z.B. User-Auth auf Anwendungsebene,
Windows-domain-zugehoerigkeit, HTTP-Proxyauth etc.)
* Sobald man VPN tunnel zu einem gesicherten Netz aufbaut und allen
Traffic ueber diesen VPN Tunnel leitet (klassisches Mobile Worker VPN)
Und diverse andere Szenarien die mir gerade nicht einfallen.

** Haushalt:= Eine begrenzte Gruppe von Menschen mit direktem Bezug
zueinander.


Wann und Wo sollte man PE nutzen (oder nicht)?
= PE nicht nutzen nur weil man ein Bauchgefuehl der Privatsphaere will
+ PE dort Nutzen, wo andere Netzteilnehmer potentiell boese Absichten
haben und die Moeglichkeit des User-Trackings gegeben ist (z.B.
oeffentliche (Campus-)WLANs)
+ PE dort Nutzen, wo man die Netzadmins aergern moechte, aber dabei
jederzeit bereit ist, die Konsequenzen fuer dieses HAndeln zu tragen.
- PE nicht im Heimnetzwerk nutzen. Das ist idR. ueberfluessig.
- PE nicht in Zugangsbeschraenkten Netzen nutzen (dieselben
Zugangsbeschraenkung sorgt idR. ja auch dafuer, dass es keine boesen
Dritten gibt, die dich unerlaubt Tracken wollen/koennen).

etc.

[Christoph 'Mehdorn' Weber]

Hallo!

* Juergen P. Meier <nospa...@jors.net>:
> Christoph 'Mehdorn' Weber <spam...@das-mehdorn.de>:

>> Zumindest bei Linux basiert das Suffix für SLAAC typischerweise
>> auf der MAC-Adresse

[..]

>> . Und Windows kann man so einstellen.

> Das, worauf du zu 99% ansprichst, nennt sich "Privacy Extensions"

Nein, das meine ich nicht. Windows ab Vista benutzt nicht
EUI-64, sondern würfelt einmalig zufällig pro Interface, siehe
hier:

<https://technet.microsoft.com/en-us/magazine/2007.08.cableguy.aspx#s3>

Privacy Extension kann man separat umschalten:

<https://technet.microsoft.com/en-us/magazine/2007.08.cableguy.aspx#s4>


Rest später. Ich gehe erst einmal einkaufen.

Christoph

--
[Ueber die Columbia] Wer auch immer heute Geburtstag hatte,
ich finde, ein kleineres Feuerwerk haette es auch getan.
(Adrian Knoth)

[Christoph 'Mehdorn' Weber]

Hallo!

* Juergen P. Meier <nospa...@jors.net>:

> Wo IPv6 PE schlecht fuer den Anwender sind:
> * IP-Addressbasiert authentifizierte und autorisierte Benutzer in
> Zugriffsbeschraenkten Netzen.

Ja, in /etc/hosts.allow schalte ich derzeit auch einfach ganze
Subnetze frei. Aber die Authentifizierung läuft bei SSH&Co.
glücklicherweise separat.

> Das sollte Selbsterklaerend sein, denn es gibt Netze wo der Zugang zum
> Netz selbst und bestimmten Ressourcen per IP-Adresse autorisiert wird,
> mit der sich der Benutzer zuvor Authentifiziert hat (Die Debatte, wie
> Dumm das ist bitte woanders fuehren

In Kombination mit IPsec finde ich es nicht mal so schlecht. Mal
sollte nur darauf achten, daß der erlaubte Bereich deckungsgleich
mit dem ist, der per IPsec gesichert ist, und letzteres auch
erzwingen. Dann sortiert der Kernel das schon aus, wenn sich
jemand einfach eine Adresse im Subnetz klaut, aber nicht passend
verschlüsselt.

Die Möglichkeiten, das falsch zu konfigurieren, sind aber nicht
zu unterschätzen.

Christoph

--
[Planetopia] So etwas kann man immer nicht so lange ansehen:
"Die Sonne ... [ist ein] lebensspendender Planet" *ZAP*
"[Eine Festplatte] ist das Gehirn eines Computers" *ZAP*
(Bodo Eggert)

[Christoph 'Mehdorn' Weber]

Hallo!

* Juergen P. Meier <nospa...@jors.net>:

> Die uebrigen 1% heissen DAD (Duplicate Address Detection) und sind
> ebenfalls Standard. Sie verhindern das z.B. zwei geklonte VMs im
> selben VLAN die selbe IP-Adresse nutzen.

Im Prinzip nett, aber wenn die praktisch dann mit derselben
MAC-Adresse unterwegs sind, hat man wahrscheinlich trotzdem noch
interessante Effekte.

>> dnsmasq experimentiert und generiere einfach neben den statischen
>> Einträgen für DHCPv4 die Namen zu den MAC-basierten SLAAC-Adressen
>> gleich mit

> Also die erste Bedingung ist erfuellt. (eine CMDB kann auch einfach
> nur ein Textfile mit allen Endgeraeten und ihren relevanten
> Konfigurationsparametern (sprich: MAC-Adresse) sein ;)
> Solange niemand PE nutzt, geht das.

Sag ich ja.

>>> 3) alle Geräte meinen lokalen DNS-Server als DNS verwenden.
>> Damit habe ich mich noch nicht groß beschäftigt. Man kann ihn im
>> RA mitgeben, aber das hat sich noch nicht sehr verbreitet.
> Per experimenteller Erweiterung die bisher niemand ausser Microsoft
> implementiert hat? Tolle Wurst.

Ich bilde mir ein, auch schon etwas daemon-artiges für Linux
gesehen zu haben. Aber darum ging es mir nicht (primär).


Ich sortiere jetzt die Zitate mal etwas um:

>> Irgendwie fühlt sich das alles häßlich an, weshalb ich Privacy
>> Extensions momentan auf bestimmten Hosts noch meide, obwohl ich
>> sie allgemein gern nutzen würde.
> Wozu? Nein, das ist eine durchaus ernst gemeinte Frage. Was willst du
> damit /genau/ erreichen?

> Ich verbiete diesen Dummfug*. Meine Rechner brauchen keine Anonymitaet
> in meinem Netz.

In meinem Netz brauche ich es im Prinzip auch nicht. Mir geht es
hauptsächlich um meine Rechner in fremden Netzen, also
insbesondere mobile Geräte, die man auch mal zu Bekannten mitnimmt
etc.

Da kann es nützlich sein, damit die Systeme nicht so leicht
verfolgt werden können, denn ohne Privacy Extensions ist das
Suffix bei ausgehenden Verbindungen bei SLAAC immer gleich. Und
alle Dienste, die mein System gelegentlich anfragt, sei es der
Update-Mirror, ein NTP-Server oder sonstwas (und auch jeder auf
der Strecke) kann dann trivial am Suffix nachvollziehen --
verschlüsselte Verbindung zwecklos -- wo mein System überall war.
Und das möchte ich nicht.

Und bevor ich immer daran denken muß, PE daheim abzuknipsen und
unterwegs an, wäre es einfacher, es generell anzuwerfen.

> Im Subnetz selbst sieht die gegenstelle ganz genau wer das ist.

Mag sein. Im Ethernet-Segment bekommt man das schon immer
trivial über die MAC-Adresse heraus. Der Punkt bei SLAAC ist, daß
die MAC-Adresse (wenn auch leicht umformatiert) schnell mal in die
gesamte Welt verbreitet wird.

Andererseits ist SLAAC auch sehr praktisch. Trivial-Router mit
radvd hingestellt und fertig. Bei DHCPv6 erwarte ich etwas mehr
Aufwand.

> Die Dienste dieser Welt sehen also nicht mehr /anhand der IP-Adresse/
> mit welchem Gereat Herr W. aus I. genau die Bauanleitung zum
> Freifunkgeraet heruntergeladen hat.

Unterstellung. Die Idee zu meinem Hotspot hab ich von einem
Bekannten und es dann anhand der Manpages zusammengepfriemelt.

> Das Endgeraet wird durch PE verschleihert, nicht der User.
> Es ist ein ganz bestimmter Spezialfall, wo die Identitaet des
> Endgerates bijektiv mit der Identitaet eines Users verbunden ist.
> Diesen Spezialfall findest du ausserhalb eines Uni-Campus oder eines
> Enterprise-Netzes jedoch nicht.

Meiner Meinung nach bei mobilen Geräten schon.

> Bei IPv6 und Privathaushalten gilt vielmehr:
> User == Prefix.

Zumindest mit Tunnel-Provider, da ist es in der Tat recht
statisch. Wie's bei den großen Anbietern aussieht, die das
nach und nach endlich an Endkunden durchreichen, überblicke
ich nicht, aber gerüchteweise planen einige regelmäßige
Präfix-Rotationen.

>> Alternativ könnte man z.B. bei Bind (vermutlich) mit "Generate"
>> arbeiten und einfach Dummy-Namen fürs gesamte Subnetz erzeugen.
> Du muesstest eine halbe Trillionen NAmen generieren. Soviel RAM hat
> dein DNS-SErver nicht, um so eine Zone zu laden.

Na gut. Bisher hab ich nur kleine Bereiche generiert, und mir
die Implementation nie angesehen. Hätte auch sein können, daß Bind
die nicht vorher generiert, sondern erst bei Bedarf, wenn
entsprechende Anfragen kommen. Dann wäre das Speicher-Problem
nicht so kritisch.

Andererseits geht das wohl auch beim ersten klassischen
Zone-Transfer in die Hose.


[PE-Adressen für bestimmte Verbindungen meiden]

>> Oder richtet man mit iproute2 und ip6tables für spezielle
>> Ziel-Ports etc. dann Sonderwürste ein, indem man das auf eine
>> Routing-Tabelle mit fixer Quell-Adresse verschiebt? Aber IIRC
>> kann man da jeweils nur komplette Adressen angeben, muß das also
>> irgendwie verscripten, damit Präfix-Änderungen nachgezogen werden.
> Auch ein schoen haesslicher Hack.

Ja, wobei es offenbar eine bessere Methode geben muß, denn im
Thread wurde bereits berichtet, daß einige Systeme offenbar die
PE-Adressen für ausgehende Verbindungen bevorzugen, und andere
DHCPv6 (wenn ich mir das im Detail richtig gemerkt habe). Da muß
also irgendwo ein Schalter sein. Aber selbst, wenn man ihn findet,
ist er vielleicht zu global.


Und dann gibt es natürlich auch noch Tools, die die MAC-Adresse
regelmäßig neu würfeln, aber dann geht auch nebenbei die statische
Zuordnung bei DHCPv4 auf dieser Basis kaputt und wer weiß was noch
alles. Will man auch nicht.

Christoph

--
Pyramiden sind mathematische Ausdruecke mit Exponenten,
mit denen in der Analysis staendig herumgealbert wird. --
Nein, das sind die Pheromone.
(Roger Schwentker, Mark-Oliver Wolter)

[Marc Haber]

"Juergen P. Meier" <nospa...@jors.net> wrote:

>Per experimenteller Erweiterung die bisher niemand ausser Microsoft

... und systemd-networkd, so viel Ehre muss sein, ...

>implementiert hat? Tolle Wurst.

[Christian Weisgerber]

On 2016-09-15, Christoph 'Mehdorn' Weber <spam...@das-mehdorn.de> wrote:

[Privacy Extensions]

> In meinem Netz brauche ich es im Prinzip auch nicht. Mir geht es
> hauptsächlich um meine Rechner in fremden Netzen, also
> insbesondere mobile Geräte, die man auch mal zu Bekannten mitnimmt
> etc.

Beim Laptop auf Reisen erzeuge ich einfach bei jedem Reboot eine
zufällige MAC-Adresse.

http://www.cbc.ca/news/politics/csec-used-airport-wi-fi-to-track-canadian-travellers-edward-snowden-documents-1.2517881

--
Christian "naddy" Weisgerber na...@mips.inka.de

[Anonymous]

Marc Haber <mh+usene...@zugschl.us> wrote:
> "Juergen P. Meier" <nospa...@jors.net> wrote:
>
> >Per experimenteller Erweiterung die bisher niemand ausser Microsoft
>
> ... und systemd-networkd, so viel Ehre muss sein, ...

RDNSS wird von vielen Systemen unterstuetzt. Ausser von Microsoft.
Juergen weiss mal wieder nicht, wovon er spricht.

https://en.wikipedia.org/wiki/Comparison_of_IPv6_support_in_operating_systems

[Andreas Kohlbach]

On Thu, 15 Sep 2016 20:48:49 +0000 (UTC), Christian Weisgerber wrote:
>
> On 2016-09-15, Christoph 'Mehdorn' Weber <spam...@das-mehdorn.de> wrote:
>
> [Privacy Extensions]
>> In meinem Netz brauche ich es im Prinzip auch nicht. Mir geht es
>> hauptsächlich um meine Rechner in fremden Netzen, also
>> insbesondere mobile Geräte, die man auch mal zu Bekannten mitnimmt
>> etc.
>
> Beim Laptop auf Reisen erzeuge ich einfach bei jedem Reboot eine
> zufällige MAC-Adresse.

Wie machst du das technisch? maccchanger?

So weit ich hörte, kann man auch dem NetworkManager seit kurzem sagen,
für bereits registrierte (oder auch grundsätzlich?) WIFI Sourcen immer eine
zufällige MAC zu erzeugen. Ich finde aber in dessen GUI (noch dazu stürzt
diese seit ein paar Tagen auch ab) keine Einstellung dazu.

Ich finde in einigen Dateien unter /etc/NetworkManager/system-connections/
allerdings

mac-address-randomization=

was ich auf "1" setze. Trotzdem wird bei ifconfig meine echte MAC
angezeigt. Was aber an etwas anderem liegen mag. Denn selbst wenn ich per
macchanger diese ändere (und ifconfig das auch anzeigt), wird nach
Verbinden zu einer WIFI Source wieder meine echte MAC aufgeführt. Ich
kann nicht finden, warum.
--
Andreas
You know you are a redneck if
you have flowers planted in a bathroom appliance in your front yard.

[Christian Weisgerber]

On 2016-09-16, Andreas Kohlbach <selem20....@spamgourmet.net> wrote:

>> Beim Laptop auf Reisen erzeuge ich einfach bei jedem Reboot eine
>> zufällige MAC-Adresse.
>
> Wie machst du das technisch?

Hier auf OpenBSD mit der ersten Zeile

lladdr random

im /etc/hostname.<if>, was dann von netstart(8) als

ifconfig <if> lladdr random

ausgeführt wird.