Ja klar und für jedes VLAN schmeiße ich dann Kabel durch die Wohnung oder das Büro.
wieso?
ein VLAN ohne eigenem IP-Segment macht nichtmal im Home-Bereich Sinn 
weil genau das willst Du ja mit der VLAN-Trennung erreichen,
dass Dir andere im selben Netzwerk nicht IP(v6)-mässig in die Quere kommen ...
sagte ja, ohne Layer 3 schmeiss den managed Switch weg 
Nicht jeder Managed Switch ist auch ein L3 Switch.
stimmt, es hat auch nicht jeder Managed Switch einen Sinn
Unmanaged regelt das
(einzig auf die Backplane bei unmanaged Switches sollte man schauen,
bei einem 8-Port GBit-Switch ist alles unter 12 GBit/sec zum wegwerfen)
Ein IP Netz läuft immer über eine Broadcast Domäne, sprich über ein getrenntes L2 Segment.
nicht unbedingt; mehrere VLANs können sich ein IP-Netz z.B. 192.168.17.0/24 teilen;
In dem Moment, wo du mehrere L2 Segmente bzw. VLANs hast, brauchst du dazwischen L3 Vermittlungsgeräte (Router) oder eine Bridge.
im Falle von L3 Vermittlungsgeräten (z.B. Router, Managed Switche sind eigentlich Layer 3) sind unterschiedliche IP-Netze möglich,
im Falle von L2 Vermittlungsgeräten (z.B. Bridge, Unmanaged Switche sind Layer 2) ist eine Layer 3 Trennung (unterschiedliche IP-Netze) nicht möglich;
ein Layer 1 Vermittlungsgerät (z.B. Repeater, Hub) erweitert nur die Reichweite (Kabellänge)
darum ja die Frage ob er die IP-Netz-Trennung auch braucht ...
was meinst Du mit getrennte Netze?
sprichst Du wirklich von unterschiedlichen IPv4-Segmenten bzw. IPv6-Prefixen?
wenn es nur darum geht dass du auf der einen Seite mit dem einen Kabel zuwenig hast,
ist hier ein unmanaged Switch das richtige;
vor x Jahren hatten wir vom Büro ins Wohnzimmer durchgebohrt und auf beiden Seiten eine Doppeldose CAT6 montiert;
eine f. das TV und eine f. den PC der daneben im Wohnzimmer steht;
(ein Luxus f. ein blueray Laufwerk)
auf der Wohnzimmerseite sind entsprechend das TV and der PC mit Patchkabeln angesteckt,
und auf der Büroseite mit kurzen Kabel-Stummeln am Switch;
die anderen 6 Ports vom 8-Port Switch hängt die LAN-Seite des Routers,
ein Drucker und unsere PCs - jeder hat an alten und an neuen PC, und fertig is das Home-RZ
Ohne VLANs an mindestens zwei Stellen bin ich verloren.
sprichst Du hier von VLANs, welche nicht nur auf Layer 2 eine Trennung haben,
sondern auch auf Layer 3 z.B. unterschiedliche IP-Netze sind?
Ist die Strecke zu lang, ist das Kabel zu kurz!
nicht unbedingt, aber wie groß ist Deine Hütte KB19,
das maximale Repeaterset würde bis zu ½ km erlauben;
aber da machst wegen der galvanischen Trennung eher einen LWL dazwischen und dafür brauchts aber a bissi mehr als einen dummen (managed) Switch;
Unmanaged rules
(ich verwemde ausschließlich unmanaged Switches)
beim Ausmisten gerade einen 5 Euro Gutschein gefunden
hast da im Real Life ausgemistet od. nur Datenmüll beseitigt?
Dann ist wohl eher dein Programm beschissen und nicht die Paketverwaltung.
das mag sein, ist aber bei allem so;
wenn Du die 'richtige' Hardware hast, dann hast Du bei Windows entweder überhaupt keine Probleme od. eben die vollen Probleme;
analoges auch bei Linux ...
ich finde halt nur Schade, dass diese 2 Welten sich derart unterscheiden¹;
ReactOS hat zwar ambitionierte Ziele, bis es 'fertig' ist, kratzt es aber niemanden mehr;
Linux als Desktopsystem kann aufgehen od. man hat Pech;
¹ Quellcode-Kompatibel das wär schon was;
Update-Unfug? Also zumindest bei Debian und CentOS hatte ich noch nie Probleme
dann hattest noch nie ein Programm von außerhalb der Paketverwaltung, des die 'Hello World'-Schallmauer durchbrochen hat;
(es war ein Closed-Source Programm, auch sowas soll es mit Linux geben, des mir den Verstand raubte)
bei Windows lehn ich mich entspannt zurück
aber des mit Linux war schon ein Nervenkratzen, jedesmal wenn ich die Version hochzog - des war öfters als die halbjährl. Fkt.supdates von Win10 -
verweigerte das Programm seinen Dienst, und brauchte selbst ein Update;
ich gab auf, als dann des Zwangs-Update vom Programm mit der Hardware kein Auslangen mehr fand;
hatte meinen alten PC aus dem Jahr 2009 - ein Core2Quad - testweise mit einem Fedora am laufen
klar, eine VM sichert ma einfach durch Kopie vom VMDK und noch a paar Files;
der Gedanke den Host mit Linux zu betreiben habe ich Dank anderer Linux-Unsinnigkeiten verworfen ...
der Unfug in der Update-Weltmeisterschaft ist in der Linux-Welt noch a Schauferl größer;
bei dem was ich gerade in Bezug auf die Sicherung des Systemlaufwerks (NVMe SSD)
erlebe wundert es mich wirklich nicht, wenn kaum jemand bereit ist f. Software Geld auszugeben;
hatte letztes Jahr ein neues Acronis TrueImage gekauft; generierte einen USB-Stick,
und das lief bis ich eine der kleineren Platten durch was größeres ersetzte;
bis zur Liste der Platten und dann geht nichts mehr, nur die Maus bewegt sich noch ...
ein Glück ich kaufte v2019 mit Update auf v2020; auch die letzte Aktualisierung von v2020
verweigerte ihren Dienst; dann probierte ich v2019, und siehe da, damit geht es;
und warum?
keine Ahnung, ich vermute es mal, dass es da keinen Pfusch im Netz veranstalten kann,
weil es kein Netzwerkinterface erkennt ...
des erklär mal einer
bei mir hab ich seit gut 20 Jahren gerade mal die 21ste IP-Adresse
wobei sowas kann Fluch und Segen glztg. sein;
besonders wenn man eine IP aus dem Range hat, wo zwar der ISP
einen fetten Anteil hat, ein halbes /16, und genau das ist der Fluch,
wenn die andere Hälfte in Afrika (Ägypten) ist ...
Valkyrie und hattest Du die SSD(s) einfach neu initialisiert oder waren die auch hinüber?
wobei die Frage: inwieweit unterscheiden sich hier USB-Sticks von SSDs - sind doch beides Flash-Speicher, oder irre ich mich?
(selbiges würde wahrscheinlich auch f. die diversen Speicher wie z.B. in Digicams gelten?
)
mainziman Das ist doch nur ein Problem, wenn man nicht mindestens /64 je Subnetz verwendet.
genau solche Krankheiten lassen einem vor IPv6 davonlaufen;
weil des erklärst dann wen, dass er f. ein und das selbe physikalische Netz
mehrere /64 Prefixe braucht ...
wo er doch nur ein einziges IPv4-Subnetz dafür hat ...
ich hab bei IPv4 ein /16-Subnetz mit Subnetmask 255.255.0.0
und davon hab ich ein /24-Teil f. DHCP herausgepickt;
und vom /64-IPv6-Prefix hab ich ebenfalls ein /80-Teil herausgepickt
f. stateful DHCPv6 ...
ob das so clever war auf /64 zu gehen?
ich hätt hier das etwas anders dimensioniert
/64 pro Kunden und als kleinste Einheit f. SLAAC einfach nur ein /80,
da hat die gesamte MAC-Adresse 1:1 Platz;
ich weiß irgendwer hat da mal was von Erweiterung der MAC-Adressen auf 64-Bit erwähnt,
nur das ist illusorisch, weil damit funktioniert dann nicht mal mehr IPv4 ...
(weil 802.3 Ethernet nicht mehr funktioniert, des baut auf 48-bit MAC-Adressen auf)
SLAAC an sich ist ja noch kein großes Problem
irgendwie schon, weil ich das abgedreht habe, verwende nur stateful DHCPv6
ich will ja die IPv6 Adressen nicht irgendwo kreuzweise haben, sondern etwas geordnet;
damit ich z.B. einem /80 am Router einfach ausgehend sperren kann;
ist das evtl. einer der Gründe wieso es sich in Firmenumgebungen nicht wirklich durchsetzt?
H6G ja die Vorteile von IPv6 sind ja real und gut; Du hast sogar soviele Adressen, dass Du das WHOIS als Rindviechdatenbank 'mißbrauchen' kannst,
einfach jedem Rindviech einen IPv6-GPS-Tracker verpassen und rein ins WHOIS 
beim Fleischzerteiltechniker kannst dann sagen, ich hätt gern zwei Steaks vom Rindviech mit IPv6 [beef::007] f. Kalenderwoche 47 vorbestellt;
die Vorurteile, welche gegen IPv6 existieren, sind auch nicht von der Hand zu weisen;
moimentan sind ja nur IPv6-Adressen mit 2 od. 3 als 1tes Halbbyte vergeben, aber es ließe sich damit wirklich bei den globalen Routern,
wenn man es geschickt gemacht hätte, derart schlanke Routing-Tables verwirklichen, dann hätt ma an Hand des ersten Halbbyte direkt nach Kontinent routen könnte, und die nächsten 3 Halbbytes nach Land; f. große Länder wie z.B. eben Dtl. hätt es halt mehrerer solcher 'Landzuweisungen' gegeben;
aber die CIA/NSA u. sonstiges Fußpilz-Orgs hätten hier sicher was dagegen gehabt;
das hätte schon was f. sich, wenn das gleich richtig angegangen worden wäre;
weil immer noch paar Verstrahlte mit IPv4 only rumlaufen.
sicher, dass Deine 50% sich nicht evtl. ganz anders darstellen;
ich mein der folgende Vergleich trifft es vlt. ganz gut ...
jetzt mal unabhängig vom ökologischen Fußabdruck, welchen E-Autos bereits bei der Erstzulassung haben,
aber wenn Du nur die sogenannten 'Sonntagsfahrer' von Verbrenner auf E umstellst wird sich an der Luftsituation
in den Ballungsräumen/Städten genau nichts ändern;
so ist es auch bei IPv6, gibst Du dieses erstmal den Wenig-/Kaum-Nutzern, hast Du zwar viele IPv6-Adressen vergeben
der Datentraffic läuft aber weiter fast ausschließlich auf IPv4 ...
bei meinem Router hab ich momentan das da (uptime: 27¾ Tage)
beim WAN-Device (IPv4only, welcher auch 6in4 inkludiert)
RX bytes:975203566830 (908.2 GiB)
TX bytes:384634394439 (358.2 GiB)
beim 6in4-Device (IPv6only)
RX bytes:92510020477 (86.1 GiB)
TX bytes:13251441994 (12.3 GiB)
das Datenvolumen f. HomeOffice ist hier gar nicht dabei, weil das hängt in der IPv4only DMZ
die Zahlen sprechen f. sich ... nicht mal 10% des Datenvolumens ist IPv6 ...
Ist es wirklich ein Henne Ei Problem?
das würde ich meinen;
Du hättest auch telekom.at nehmen können sieht dort nicht besser aus;
ja die Endkundenprovider sind Teil des ganzen,
wieso sollen die mit IPv6 kommen, wenn sie sehen, was alles noch IPv4only ist;
ich stelle mir gerade die Frage ob der DualStack Tag vor gefühlt x 1000 Jahren nur reines Bla bla war;
Und damit stehen wir in Deutschland noch gut da, mit einer IPv6 Abdeckung von 50% - andere Staaten sind da noch rückständiger, bspw. die USA.
und jetzt Hand auf's Herz, was würde alles nicht gehen, wenn Du den 50% das IPv6 wieder nimmst gegenüber dem Gedanken, wenn Du von denen die IPv6 haben,
das IPv4 abdrehst;
just my 2 cents, dass ohne IPv6 kaum was nicht geht, und ohne IPv4 alles zusammenbricht;
Zum Thema IPv4 Murx, mit IPv6 wird da auch gewaltig gemurxt;
mein ISP hat zwar die Vorbereitungen schon getroffen, die DNS-Server und diverse andere Server sind DualStack;
und das war es auch schon; f. Kunden bis auf weiteres IPv4only ...
ich würde es ja verstehen, dass der ISP sagt: "auf meinen DNS-Servern nur von meinem Netz",
aber des auch bei den authoritativen DNS-Servern f. Dritte?
Muss mein Handy jetzt auch noch Apple Talk oder IPX können?
Nein natürlich nicht;
Aber alles umzusetzen ist eine große Aufgabe. Wie du bereits festgestellt hast gibt es viele DHCP Alternativen - aber warum sollte ein Android alle beherrschen. Zu welchem Zweck?
bei einem Phone lass ich es mir noch einreden dass man hier evtl. Abstriche macht,
aber wenn ich nur meinen Drucker anschau, welchen Sinn hat es, SLAAC only zu können,
weder eine echt fixe IPv6 noch stateful DHCPv6 sind möglich; und damit ist es nicht wirklich einsetzbar,
weil man ja gerne einen DNS-Namen dafür am DNS eintragen will ...
(ich hab IPv6 einfach deaktiviert, so kann ich es nicht gebrauchen)
Kommt darauf an welchen RFC man nimmt. https://www.system.de/ipv6-rfc/
Die Auswahl ist ja gigantisch.
genau hier ist auch das Problem ... hier stehen halt bei IPv4 mehr als 3 Jahrzehnte etablierte Implementationen dahinter
und bei IPv6 gibts noch keine fertige ...
ich mein Du kannst folgendes auch bei Linux in der Geschichte nachvollziehen;
welches Windows machte die ersten Gehversuche mit IPv6?
richtig, WinXP und seine Derivate wie XP x64 bzw. der Server 2003 (x64);
und aus welchem Jahr stammte das?
und konnte man es wirklich mit IPv6 einsetzen? Nein.
2006/2007 kam dann Windows VISTA,
das konnte man erstmals überhaupt mit viel Bauchweh mit IPv6 einsetzen;
zu diesem Zeitpunkt waren die ersten RFC bereits mehr als 10 Jahre(!) alt;
und Hardware die mit IPv6 umgehen konnte, war kaum vorhanden;
wohlgemerkt: wenn man f. den Consumer keine entsprechende Hardware am Markt hat,
dann hat man verloren, weil schließlich sind eine Menge an Consumer, welche mangels
entsprechender Hardware mit IPv4 angebunden werden mussten gewichtiger als eine einzige Firma ...
in welchem Jahr tauchten die ersten Devices/Phones auf, welche auch eine IP-Verbindung hatten?
da war jedenfalls von IPv6 noch nichts am Markt ...
wann hatte in Österreich A1 Telekom bei den Mobilen Geräten (Phones, Tablets) IPv6 (DualStack eigtl. Light) eingeführt?
das wäre jedenfalls die Chance gewesen IPv6 mit den Mobilen Devices in die Breite zu tragen,
weil ohne der entsprechenden Anbindung durch den Mobilfunkbetreiber kamen die Dinger ohnehhin nicht ins Netz;
dort hätte anfangs eine Umsetzung zwischen beiden Netzen stattfinden können und nach und nach
durch den IPv6 Einzug hättte man weniger und weniger an Umsetzung machen müssen,
bis diese schlussendlich komplett weggefallen wäre;
was ist aber die Realität?
man findet z.B. kaum eine Bank, welche deren Infrastruktur mit DualStack angebunden hat;
jetzt nicht den Webauftritt selbst, sondern Electronic Banking ist bis auf kaum existente Ausnahmen noch immer durchwegs IPv4only;
(damit müssen Consumer auch per IPv4 angebunden werden)
aber wie heißt es so schön:
"wenn ich IPv4 brauche um zu bekommen, was IPv6 nicht hat,
dann brauch ich auch kein IPv6 um zu haben was IPv4 ohnehin bereits hat;"
(irgendwie ein Henne-Ei Problem)
ich stell es jetzt in den Raum, aber die SIcherheitslücken von denen zuerst bei SSLv3, dann bei TLSv1.0, .... die Rede ist/war,
haben/hatten diese was damit zu tun, ob von IPv4 od. IPv6 die Rede ist?
der "Gedanke" dass man es nur einmal implementieren muss, und es dann sowohl mit IPv4 und IPv6 läuft, funktioniert nicht wirklich;
ein Code-Snippet in einem Programm von mir ...
(natürlich als Routinen, die ich mehrfach verwende)
#define UNKNOWN 0
#define IPV4 1
#define IPV6 2
int getAddrType( const char* pszIPaddr, int* pnIPaddrType )
{
int nIPaddrType = UNKNOWN;
int nRet;
struct addrinfo hint;
struct addrinfo* prslt = (struct addrinfo*) NULL;
memset( (void*) &hint, (int) '\0', sizeof( hint ) );
hint.ai_family = PF_UNSPEC;
hint.ai_flags = AI_NUMERICHOST;
nRet = getaddrinfo( pszIPaddr, (const char*) NULL, &hint, &prslt );
if ( nRet );
else
{
if ( prslt->ai_family == AF_INET )
nIPaddrType = IPV4;
else
if ( prslt->ai_family == AF_INET6 )
nIPaddrType = IPV6;
}
freeaddrinfo( prslt );
if ( pnIPaddrType )
*pnIPaddrType = nIPaddrType;
return nRet;
}
int getDNSname( const char* pszIPaddr, char* pszDNSname )
{
int nIPaddrType = UNKNOWN;
int nRet = getAddrType( pszIPaddr, &nIPaddrType );
struct hostent* pHostEnt;
if ( nRet )
return nRet;
switch( nIPaddrType )
{
case IPV4 :
{
struct in_addr ipv4addr;
inet_pton( AF_INET, pszIPaddr, &ipv4addr );
pHostEnt = gethostbyaddr( (const void*) &ipv4addr, sizeof( ipv4addr ), PF_INET );
}
break;
case IPV6 :
{
struct in6_addr ipv6addr;
inet_pton( AF_INET6, pszIPaddr, &ipv6addr );
pHostEnt = gethostbyaddr( (const void*) &ipv6addr, sizeof( ipv6addr ), PF_INET6 );
}
break;
default : ;
}
if ( pHostEnt && pHostEnt->h_name )
{
if ( pszDNSname )
strcpy( pszDNSname, (char*) pHostEnt->h_name );
return 0;
}
else
{
if ( pszDNSname )
*pszDNSname = '\0';
return -1;
}
}Ich kann mir kaum vorstellen, dass die Storageserver physisch immer auf dem selben Server liegen wie z. B. der root Server auch.
das ist aber nicht das Thema; Du kündigt ja auch beim Webspace sämtliche Inklusivdomains mit;
es geht darum: es sollte möglich sein, einen Storage Space unabhängig von einem vServer zu haben;
