Mar 07

socat tip: create virtual serial port and link it to TCP

Reading time: < 1 minute

Create a virtual serial port and publish it on TCP port:

socat pty,link=/dev/virtualcom0,rawer tcp-listen:2101

In another computer, for instance, another virtual port can be created and connected to the previous one:

socat pty,link=/dev/virtualcom0,rawer tcp:SERVER_IP:2101

If in any of those both sides we want to open a real serial port, for instance, in the server case we can run:

socat /dev/ttyS0,rawer tcp-listen:2101

More information on socat manpage.

Jun 30

Enabling linux kernel to open LOTS of concurrent connections

Reading time: < 1 minute

Just a small recipe about how to enable linux kernel to open tons of concurrent connections. Really simple and useful post entry.

echo “10152 65535″ > /proc/sys/net/ipv4/ip_local_port_range
sysctl -w fs.file-max=128000
sysctl -w net.ipv4.tcp_keepalive_time=300
sysctl -w net.core.somaxconn=250000
sysctl -w net.ipv4.tcp_max_syn_backlog=2500
sysctl -w net.core.netdev_max_backlog=2500
ulimit -n 10240
Jul 14

XMPP amb BOSH: usant HTTP com a protocol de transport

This entry is part 2 of 4 in the series xmpp
Reading time: 4 – 7 minutes

La potència de treballar amb BOSH (Bidirectional-streams Over Synchronous HTTP) rau en que malgrat aparentment l’única forma que hi ha d’implementar XMPP sobre HTTP seria mitjançant tècniques de polling, o sigui, que periódicament el client anés connectant-se al servidor per preguntar si hi ha alguna nova informació per ell.

Doncs BOSH aconsegueix millorar aquest algoritme i el que intenta descriure és quelcom així:

  1. El client fa una connexió ‘HTTP request’ al servidor
  2. El servidor no envia cap resposta, així doncs, la connexió no es tanca.
  3. Quan el servidor té una informació (asíncrona) a enviar al client, llavors busca alguna connexió oberta del client i que estigui esperant resposta, o sigui, qu estigui al punt 2. Llavors el que fa és enviar l’informació a través d’aquesta connexió com una ‘request response’. La connexió es tanca.
  4. Un cop el client rep l’informació inmediatament després de tancar-se l’enllaç, aquest torna a obrir una connexió contra el servidor, o sigui, tornem al punt 1.

Obviament quan el client té alguna cosa a enviar això es fa en el punt 1.

A l’hora de la veritat els servidors de Jabber/XMPP el que tenen per oferir accés via BOSH és un especie de proxy que rep les connexions HTTP i les processa tal com he explica més amunt, per l’altre costat captura els events que rep de cada un dels clients XMPP que esta instanciant i va connectant els fluxes de dades que rep a través d’XMPP als sockets HTTP que té esperant informació.

Servidors BOSH incrustats en servidors XMPP

Obviament això ens porta a pensar, que podem usar un servidor BOSH per un servidor XMPP que no el suporti a mode de proxy. Això es podria programar de forma força senzilla amb twisted, per altre banda, hi ha servidors XMPP que ja suporten de serie el servidor BOSH, alguns exemples són: ejabberd, Tigase, Openfire i Jabber XCP.

Avantatges de tenir el servidor BOSH dins del servidor XMPP:

  • Sovint esta més ben testejat que el codi que podem fer-nos o que ha desenvolupat un tercer per fer aquesta tasca.
  • A priori hauria de ser més eficient, ja que la part de recepció d’events/senyals es fa a través de l’API nativa i no pas d’un client XMPP. Cosa que permet estalviar recursos i ser més eficient en la seva tasca.
  • És més fàcil de configurar, sovint només cal descomentar la línia corresponent del fitxer de configuració i llestos.

Com que no tot podien ser avantatges aquí van els inconvenients:

  • Un servidor BOSH que esta incrustat en un servidor XMPP obviament només pot atendre les peticions que van cap aquell servidor, per tant, si volem que això sigui escalable haurem de montar un balencejador de càrrega sobre el port HTTP per anar desviant connexions entre diferents sevidor BOSH.
  • El suport del servidor BOSH esta lligat al suport que la comunitat doni al servidor XMPP amb el que va lligat, això no sempre és suficient.

Quan no hem de suportar més d’un servidor XMPP, i a més aquest ja suporti BOSH no hi ha hauran mai problemes. La cosa es complicarà quan haguem d’escalar aquesta infraestructura.

Servidors BOSH dedicats, per tant independents del servidor XMPP

Per exemple: Punjab, Araneo, JabberHTTPBind i rhb. Pel que fa les avantatges i desavantatges d’aquest tipus de servidors BOSH, obviament són les mateixes que les anteriors però invertides.

Un servidor BOSH dedicat, per tant, podrà connectar-se a una xarxa XMPP a través d’un servidor XMPP federat sense problemes. Sovint el preu de sobrecarrega que això suposa esta més que justificat. Cal pensar que per cada client s’hauran de tenir sovint dues connexions TCP/HTTP més una connexió TCP/XMPP; per tant, tres sockets oberts per cada client connectat al servidor BOSH. Amb això suposo que queda clara la similitut amb un servidor proxy, no?
Com ja he apuntat abans escalar els servidors BOSH a través de ‘load-balancers’ és molt senzill, per exemple ús recomano nginex. Penseu que amb aquest ‘load-balancer’ podem tenir fins a10.000 connexions HTTP i només consumir 2’5Mb de memòria RAM. Per tant, aquesta també és una molt bona raó per usar-los externs els servidors BOSH. De fet, això no només ho penso jo sinó que aquí també ho pensen: BOSH cloud.
De fet, hi ha gent tan agoserada que gosa dir que XMPP és millor si els clients usen BOSH per accedir-hi, de fet, si llegeixes el raonament no sembla tan dolent: XMPP is better with BOSH.

Nota final

Per si algú encara no ho tenia clar, això és el que usen les llibreries d’XMPP implementades en JavaScript, o sigui, els client de xat (Jabber/XMPP) que via Web. Per exemple, el client que podem usar des de la pàgina web de gmail.

Obviament les aplicacions Jabber/XMPP són infinites i no només com a clients de xat. Per tant, podeu aprofitar aquestes llibreries JS que implementen BOSH per mostrar de forma interactiva a les vostres interficies web qualsevol tipus de contingut que obtingueu a través de la xarxa XMPP.

May 01

XMPP: introducció

This entry is part 1 of 4 in the series xmpp
Reading time: 5 – 8 minutes

Definició

XMPP Standards Foundation
XMPP (Extensible Messaging and Presence Protocol) és un protocol estàndard i obert que es basa en l’intercanvi de missatges XML. Inicialment va ser concebut per implementar xarxes de missatgeria instantànea (IM) però actualment s’usa per un ventall de funcionalitats molt més ampli. Qualsevol aplicació que necessiti un sistema de missatges entre diferents mòduls distribuits és sensible a usar XMPP per ntercanviar missatges usant aquesta tecnologia com a middleware. Potser les eines més conegudes que usen XMPP com a middleware són Jabber, GTalk i les funcions de videoconferència i audioconferència de la mateixa Google.

Les funcionalitats que ens ofereix el protocol són realment amplies i potents:

  • Rudundància
  • Escalavilitat
  • No calen VPNs per accedir al serveis dins d’una xarxa amb NAT
  • Suport SSL i Certificats
  • Backends on es guarden usuaris: MySQL, LDAP, etc.
  • Extensible (usa el que s’anomenen XEP)
  • BOSH permet usar XMPP sobre HTTP, cosa que per disseny del protol XMPP seria un problema.

Glossari

  • JID: els nodes d’una xarxa XMPP s’identifiquen a través d’aquest identificador, que és de la forma: user@domain/resource (exemple: miquel@servidor.cat/im). Tractament dels JID:
    • user@example.com – conegut com a JID
    • user@example.com/desktop – conegut com a JID o full JID
  • Stanza: els missatges XML que s’intercanvien entre un servidor XMPP i un client s’anomenen Stanzas.  Hi ha tres tipus d’stanzas:
    • Messages: transporten informació entre nodes, els missatges es poden organitzar en threads. N’hi ha de diferents tipus:
      • normal
      • chat
      • groupchat
      • headline
      • error
    • Presence: serveixen per informar de la dipsonibilitat d’un recurs (online/offline):
      • away
      • do not disturb
      • extended away
      • free for chat
    • IQ Stanza (info query): similar a un HTTP GET/POST/PUT, serveix per demanar informacions concretes a un node. Ideals per extendre el protocol. Per exemple, les IQ s’usen per saber quins recursos (usuaris) estan connectats a un canal de xat. N’hi ha de tres tipus:
      • get: demanen informació (HTTP GET)
      • set: proveeixen informació (HTTP POST/PUT)
      • result: retornen informació requerida o confirmen que s’ha acceptat una comanda ‘set’.
  • Extensibility: per tal de que sigui simple extendre el protocol, les stanzas suporten namespaces i qualsevol element XML d’una stanza es pot usar com un payload, per transportar: XHTML tags, Atom feeds, XML-RPCs, etc.
  • Roster: llista de persones que participen en un event.
  • Presence subscriptions: els recursos d’una xarxa (sovint els usuaris) poden subscriures a altres recursos (altres usuaris) per tal de saber si estan o no disponibles en cada moment.
  • Asincronisme: la gràcia del XMPP respecte altres protocols com HTTP és que es tracta d’un protocol asíncron, o sigui, que les connexions s’estableixen durant molt de temps i en qualsevol moment el servidor i/o el client poden enviar i rebre stanzas a través d’aquest canal. Els protocols HTTP estableixen connexions relativament curtes on sovint només hi ha una petició i una resposta després es tanca la connexió.

Polling vs PubSub

Aquest és el gran parigma de les estructures client servidor actuals, sovint els servidors tenen informacions que són pels seus clients. Però per disseny els servidors no podenen connectar amb els seus clients i han d’esperar a que aquests es connectin per donar-los la informació que necessiten. Això dona lloc al que coneixem com a polling, o sigui, que els clients periódicament han d’anar connectant als servidors per saber si tenen quelcom nou per ells. Un bon exemple per entendre això és els servidors POP3 els servidors tenen una serie de correus enmagatzemats a l’espera que els clients a través del seu MUA es connectin per descarregar-se el correu.

Doncs bé en una xarxa XMPP, els clients es troven connectats al servidor en tot moment i tenen establer un canal permanent (real o virtual) entre clients i servidors. Per tant, l’intercanvi d’informació és bidireccional i qualsevol d’ambdues parts port enviar i rebre stanzas sense haber d’establir un nou canal, sinó que aprofiten el que ja tenen. PubSub és la capacitat que tenen els recursos d’XMPP (clients d’XMPP) de subscriures i publicar qualsevol informació, la possibilitat de subscriures a una informació permet que cada cop que el servidor té una informació d’aquell tipus l’enviarà directament al client sense que aquest l’hagi de demanar. Un exemple per entendre millor el PubSub seria el que fan els usuaris al unir-se a un canal de xat; o sigui, informen al servidor que volen rebre qualsevol informació que es publiqui al canal i el servidor quan algún usuari publica una nova informació al canal l’envia automàticament a la resta d’usuaris.

Com és fàcil imaginar XMPP ens dona usa serie d’avantatges per tota una serie d’aplicacions que altres protocols no poden, potser la més poderosa és la que es tracta aquí. Donant un cop d’ull als pros i contres:

Pros (PubSub > Polling)

  • Intercanvi bidireccional d’informació, no cal establir VPNs ni altres sistemes similars perquè hi hagi accés transparent entre servidors i clients.
  • Optimització del canal, no es malgasta ampla de banda fent preguntes per saber si hi ha algo nou, directament rebem les novetats.

Contres (PubSub < Polling)

  • Cal mantenir el canal establert, de forma real o virtual, això no sempre és possible o senzill. Per això apareixen tècniques/protocols com BOSH per permetre-ho.
  • XMPP no esta optimitzat per intercanviar grans volums d’informació.

La extenció més coneguda: Jingle

És una extenció d’XMPP que permet enviar missatges de senyalització entre recursos (clients) d’aplicacions multimèdia interactives com veu o video. Va ser dissenyat per Google i la XMPP Standards Foundation. El contenigut multimèdia s’envia a través d’RTP(Real-time Transport Protocol) amb ICE(Interactive Connectivity Establishment) per tal de poder traspassar els NAT(Network Address Translation).

Fonts

Wikipedia:

Web:

Presentació:

Nov 20

podcast 1×13: desafio networking [la solución]

This entry is part 3 of 3 in the series desafio networking
Reading time: < 1 minute

A pesar de que la solución se alcanzó y aplico durante los meses de agosto y septiembre, hasta hoy no he podido grabar la solución en este podcast. Espero que haya sabido explicarla bien y que quede claro como se ha hecho para solucionar el problema, sinó preguntad.

Oct 03

TCP bouncer amb failover

Reading time: 2 – 4 minutes

Al projecte GATv2 fa un parell de dies que hi he publicat un subprojecte que anomeno tcp-fwd. Es tracta d’un petit i simple aplicatiu programat amb Python i Twisted. La funcionalitat és molt senzilla es tracta d’un bouncer TCP que en cas de no poder connectar amb el primer destí on re-enviar el tràfic TCP ho prova amb el segon, sinó el tercer i així fins a tants servidors com s’hagin definit. Si no es pot acabar establint la connexió es desconnecta l’enllaç TCP cap al bouncer. O sigui, el comportament és transparent pel client original. Pels que no estigueu familiaritzats amb la funcionalitat d’un bouncer la intentaré explicar. Es tracta d’un socket TCP que escolta en un port i actua com un reverse proxy. O sigui, quan rep una connexió acte seguis s’obre una altre connexió cap al servidor i si aquesta es pot establir llavors connecta la primera connexió amb la segona.

L’inconvenient més gran que veig en aquesta idea és que la connexió que arriba al servidor final no té com a origien la IP del client, sinó la IP del servidor que fa de bouncer això fa que el fitxer de logs del servidor final no tingui la informació IP del client que realment s’ha connectat. Malgrat axiò hi ha escenaris en que aquesta eina és molt útil, ja que no sempre el més important són aquests logs sinó que el client acaba obtenint el servei que volia de forma trasparent i el sistema de failover que uso sempre segueix la mateixa seqüència de prova i error per cada socket que s’obre, així doncs, el sistema de failover és instantani i no perd ni una sola crida.

Una de les aplicacions per les que l’estic usant és per fer l’entrega de correu a un postfix. Es tracta d’un servidor de correu que només fa filtratge de correu i els correus que passen els filtres s’entreguen al servidor de correu real de l’empresa, doncs bé, per saber quin és el servidor de l’empresa uso el fitxer de configuració /etc/postfix/transport on s’indica segons el domini el servidor on entregar el correu. Però no he sabut veure com dir-li més d’un servidor de correu on fer l’entrega. Així doncs, el que faig és posar com a IP i port de transport una IP localhost i un port al atzar, llavors el postfix entrega el correu al bouncer situat en aquesta IP localhost i és el bouncer que intenta connectar aquest socket amb algún dels servidors de correu interns. Per tant, el tema és completament transparent pel postfix i els servidors que reben el correu tenen la mateixa IP origen que si ho haguessin rebut directament del postfix.

Suposo que la idea ha quedat ben definida, sinó ja sabeu que podeu fer-me les preguntes que calguin. El codi del projecte el teniu a: tcp-fwd.

Jul 29

podcast 1×11: desafio networking [el problema]

This entry is part 2 of 3 in the series desafio networking
Reading time: < 1 minute

Hablando sobre el problema del articulo sobre el desafio de networking. También aprovecho para enlazar una buena referencia sobre como comprender los problemas de secuencias TCP:

Espero haberme explicado bien y haber podido describir el problema algo mejor que en el articulo anterior, ya que no es sencillo describir un problema tan inusual.

Jun 13

tcpflow: mirant streams tcp en un moment

Reading time: 1 – 2 minutes

Fins ara per poder seguir un protocol dins del enllaç TCP, o sigui els missatges de la capa 5, sempre acabava capturant-lo amb el wireshark o en el seu defecte amb el tcpdump generava un fitxer .cap que després obria al wireshark i a través d’una funció tan simple com el Follow TCP stream em montava la sessió de capa d’aplciació que podia seguir de forma ben còmode. El gran descobriment que vaig fer l’altre dia és el tcpflow una eina la mar de simple i lleugera que com no podia ser d’altre forma usa les llibreries libpcap, le mateixes que el tcpdump i el wireshark per mostrar-nos de forma completament visual i simple a través de la consola o contra un fitxer el contingut de la sessió TCP. Espero que li tregueu tan profit com jo a l’eina.

Aug 18

Capçaleres IPv6

Reading time: 9 – 14 minutes
ipv6.gif

Basant-me en un parell d’articles de Network Systems Design Line vaig escriure l’article IPv6: repassant les novetats tècniques, doncs bé s’han publicat les parts 3 i 4 que continuen amplicant la introducció feta a les parts 1 i 2 que vaig repassar en el meu article. La part número 3 parla específicament de les característiques de les capçaleres IPv6. Part realment important i interessant en aquesta nova versió IP. Així doncs dedicaré aquest article a resumir la part 3 de l’article de Networki System Design Line que parla sobre les capçaleres IPv6.

IPv6 vs IPv4 formats de capçalera

Per entendre quines són les motivacions que han provat els canvis en la capçalera IPv6 cal tenir clar quins eren els camps de la capçalera IPv4.

  • Version (4bits) obviament conté la versió del protocol en aquest cas fixarem la versió a 4.
  • Header Length (4bits) llargada en octets de la capçalera.
  • Type of Service (ToS) identificador usat en QoS per tal de poder classificar els paquets segons la prioritat que li volem donar.
  • Total length (16bits) llargada en octets del paquet sencer, capçalera més dades. La llargada màxima serà 65.535 octets, que és el màxim que podem definir amb 16 bits.
  • Identification (16bits) Flags (3bits) Fragment Offset (13bits) a través d’aquests tres camps IPv4 implementa el suport de la fragmentació de paquets.
  • Time to Live (TTL) (8bits) número màxim de salts que pot fer un paquet abans d’arribar al seu destí. Amb aquest camp s’evita que si hi ha un problema d’enrutament els paquets saltin infinitament en cercle, sense arribar mai al destí. En cada salt que fa el paquet es decrementa el valor del camp i si aquest arriba a 0 es descarta el paquet.
  • Protocol Number (8bits) indica el codi del protocol que encapsula IP en la capa superior, o sigui, la capa 4. Els números que identifiquen aquests protocols (TCP, UDP, ICMP, etc) els defineix la IANA.
  • Header Checksum (16bits) serveix per comprobar la integritat de les dades de la capçalera.
  • Source IPv4 address (32bits) adreça IP origen.
  • Destination IPv4 Address (32 bits) adreça IP destí.
  • Options (mida variable) s’acostuma a guardar-hi informació necessària per interpretar les dades que transporta el paquet.
  • Padding (mida variable) aquest camp s’usa per ajustar la mida del camp Options a 32 bits totals.
IPv6Figure15.gif

La nova capçalera IPv6 intenta millor els principals problemes de la IPv4 a través de:

  • Mida fixa de la capçalera. Sempre de 40bytes, això afavoreix el poder processar-la de forma més ràpida perquè els routers poden buscar les direccions origen i destí de forma més eficient. Les funcionalitats que tenia IPv4 a través del camp de mida variable, Options ara la obtindrem a través de les extensions de la capçalera, concepte del que es parlarà després.
  • La fragmentació deixa de tenir sentit ja que a través del PMTU discovery els routers ajusten la mida de les trames per tal de que no hi hagi fragmentació en els paquets. Així els camps de Identification, Flags, i Fragment Offset deixen de tenir sentit.
  • Les comprobacions de la capçalera (header checksums) s’eliminen. Aquesta tasca ara és deixa per les capes superiors.

Així doncs, les capçaleres d’IPv6 es defineixen al RFC 2460 i queden com segueix:

  • Version (4bits) versió del protocol IP, sempre fixe a 6.
  • Traffic Class (8bits) fa el mateix que el ToS del IPv4.
  • Flow Label (20bits) a través d’aquest camp identifiquem un fluxe de paquets informant al router que els següents ‘n’ paquets seràn iguals a aquest i per tant, no cal que els processi. Aquesta idea es desenvolupa al RFC 3697. Aquesta informació es fixa en l’origen del paquet i no la poden modificar els routers.
  • Payload Lengh (16bits) com que la capçalera sempre té 40bytes amb 16bits en tenim prou per delimitar la mida de les dades. És important recordar que les extensions de la capçalera es consideren part de les dades.
  • Next Header (8bits) definim quin tipus de extensió de la capçalera segueix a la capçalera bàsica.
  • Hop Limit (8bits) és l’equivalent al TTL. Només se li ha canviat el nom perquè sigui més descriptiu del funcionament del camp.
  • Adreça origen IPv6 (128bits)
  • Adreça destí IPv6 (128bits)

Extensions de capçalera IPv6

Bàsicament les extensions de capçalera són una segona capçalera, opcional, que s’usa per donar les funcions que es donava en IPv4 a través del camp, de mida variable i màxim de 40bytes, Otpions. En IPv6 podem fer aquestes extensions de capçalera tran grans com ens interessin, sempre que respectem la mida màxima del paquet.

A continuació podem veure un exemple d’una capçalera bàsica, i d’una capçalera amb uan extensió de capçalera.

IPv6Figure16a.gif
IPv6Figure16b.gif

A l’RFC 2460 podem trobar les definicions de les extencions de capçalera. Podem trobar-hi, una descripció, el format i la funcionalitat.

Hop-by-Hop Options Header

La capçalera Hop-by-Hop és una extenció de la capçalera bàsica, es defineix en el camp Next Header, de la capçalera bàsica, amb el codi 0. És la única extenció de capçalera que s’ha de processar per tots els nodes del camí entre l’origen i el destí del paquet. S’úsa per exemple per facilitar la expedició de dels Jumbograms (després s’explica què és això), o també facilita que els routers es passin informacions d’expedició (forwarding).

Les opcions que transporta aquesta extenció de capçalera es codifiquen en un format que es diu TLV, a continuació es pot veure un diagrama del format.

IPv6Figure17.gif

Tots els nodes que hi ha en el camí rebran aquesta capçalera i la processaran. Si algún dels nodes no entengues les opcions que conté la capçalera i que ha de processar generaria un paquet de tipus ICMP. Tot i que no totes les opcions han de generar forçosament aquest missatge ICMP, amb això s’eviten problemes d’atacs de denegació de serveig per inundació de paquets ICMP.

És important tenir en compte l’impacte en el rendiment que té el fet de processar les capçaleres hop-by-hop en cada un dels routers. Una de les funcionalitats que té és el fet de suportar paquets molt grans. La capçalera bàsica només permet una mida que es pugui definir en 16bits, o sigui, de com a molt 65.536 octets.

Les extensions hop-by-hop contenen un camp de 32 bits de llargada que pot representar paquets molt grans, anomenats Jumbograms. Quan volguem usar el camp de 32bits de la capçalera hop-by-hop el camp Payload length de la capçalera bàsica el posarem a 0, amb això s’idenfica un paquet Jumbogram.

A través de l’RFC 2711 es defineix l’opció Router Alert que a través de la caçalera hop-by-hop permet enviar intruccions d’expedició (forwarding instructions). Per exemple, per fer reserves d’amplada de banda amb RSVP. O per alertar als routers que han de processar paquets multicast, això es fa a través dels paquets Multicast Listener Discovery.

Destination Options Header

Com el propi nom indica, aquesta extenció de la capçalera bàsica es refereix nomes a les Option de la direcció de destí. Per exemple s’usen amb MIPv6. El codi usat en el camp Next Header a la capçalera bàsica és el 60.

Routing Header

Identificada amb el codi 43, al camp Next Header. S’usa per reforçar el camí a seguir per alguns paquets. El camí el defineix l’origen, i podria no coincidir amb el camí calculat pels routers intermitjos.

La capçalera routing header conté un camp de tipus (type) que permet saber amb exactitut a funcionlitat d’aquesta capçalera. En aquest moment hi ha dos tipus de funcionalitats definides:

  • Type 0 (RFC 2460) especifica tots els salts que ha de fer el paquet per viatjar fins al seu destí. El que faràn els routers intermitjos és anar canviant la direcció destí de la capçalera bàsica en funció de la capçalera extesa per forçar el salt cap al següent node, si haguessin de fer algún salt no contemplat aquest no modificaria la direcció destí d’aquell moment ni apareixeria ni s’afegiria a la capçalera extesa. Per tant, aquests salts no contemplats serien transparents al procés.
  • Type 2 (RFC 3775) usat amb MIPv6. Conté una única adreça unicast, l’adreça del home, i habilita al node corresponent perquè re-envii el tràfic directament a un node mòbil.

Fragment Header

La fragmentació requereix molt de procés en els nodes. Per tal d’evitar les necessitats de sobrecarregar els processadors dels nodes a IPv6 no s’admet la fragmentació de paquets. Abans d’enviar un paquet, l’origen ha de passar per un procés de descobriment de PMTU. Això determinarà quina és la màxima mida que pot tenir un paquet per aquell camí sense que es fragmentin els paquets. Malgrat els routers ja no han de controlar el problema de la fragmentació els nodes destí si que han de saber recomposar un paquet fragmentat. Per tal de poder-ho fer, s’usen les extensions de capçalera Fragment Option Header.

Authentication Header

Aquesta capçalera s’assembla a la capçalera IPSec AH (RFC 2402) usada en IPv4. Aquest sistema autentica l’origen d’una transmissió i assegura la integritat del paquet. El camp Next Header l’identifica amb el codi 51.

Encapsulating Security Payload Header

S’assembla a la idea implmentada en IPSec ESP (RFC 2406) en IPv4. Identificat amb el codi 50 al camp next header.

Mobility Header

Definit a l’RFC 3775 i usat en les comunicacions entre nodes mòbils, nodis corresponents (correspondent nodes) i amb agents domèstics (home agents) en l’establiment i el control de bindings. Identificat amb el codi 135 al next header field.

Acabant…

Amb aquest article n’hi ha prou per veure que el tema de la capçalera s’ha cuidat moltíssim i que hi ha infinitat de combinacions que permeten extendre la capçalera bàsica per gaire bé qualsevol necessitat que se’ns ocurreixi. A més si ens cal fins hi tot podem crear noves extencions per les nostres necessitats. Sota el meu punt de vista aquest és un dels avantatges més potents en IPv6.

Aug 05

IPv6: repassant les novetats tècniques

Reading time: 17 – 28 minutes
ipv6.gif

IPv6 el protocol que des de fa anys i anys ens diuen que serà la versió a substituir al IPv4 comença a estar cada dia més implantat als backbones de les grans empreses, com podria ser google. Malgrat això sota la meva opinió encara trigarem força temps a notar-ho els usuaris mortals. Però mai esta de més començar-se a preparar pel canvi que ens ve a sobre. Per això he decidit resumir un article de dues parts publicat a Network Systems Design Line: An IPv6 Refresher part I (local) i part II (local).

Adreçament IPv6

El principal problema que ha tingut IPv4 per tal de que s’acabessin les direccions IP disponibles ha estat sobretot que no hi havia una planificació d’assignació d’IPs. Els 32bit dels quals disposa IPv ofereixen uns 2.000 milions d’IPs usables. IPv6 planteja usar 128bits per les adreces IP així doncs l’espai adreçable és brutal: 3.402823669e+38 adreces. Malgrat sembli un espai adreçable excessivament gran també es va pensar això dels 32bits del IPv4 fa uns quants anys així doncs millor curar-se en salut. Cal pensar però que el fet de tenir unes adreces IP amb tants bits tindrà un impacte amb el rendiment dels equips de comunicacions. Per exemple, un processador de 64bits és capaç de processar l’adreça origen i la destí d’IPv4 en un sol cicle de CPU però en IPv6 necessitarà 4 cicles de CPU, realment l’increment és molt gran.

Obviament els 128bits es poden respresentar com una successió de 0s i 1s, que a la vegada per tal d’escursar aquesta mida exagerada ho podem representar en números hexadessimals fins a obtenir una successió de 32 caràcters. Però això pels humans encara es fa intractable així doncs podem separar aquesta representació en 8 grups de 4 caràcters hexadessimals separats per dos punts (:). La representació decimal que s’usava en IPv separada per punts no és aplicable a IPv6. Pel que fa a la representació de les adreces IPv6 s’afegeixen un parell de normes més:

  • Eliminem els zeros a l’esquerra. P.e. 00A1 -> A1
  • Els grups de 4 zeros seguits es poden obviar i coloquem només l’indicador de grup, o sigui, els dos punts (:). P.e. 0000:0000:23A1 -> ::23A1
IPv6Figure1.gif

Com que els (:) sempre s’han usat per separar la IP del port, l’RFC 2732 suggereix posar la direcció IPv6 entre corxets per evitar confusions.

IPv6Example1.gif

Arquitectura de les adreces IPv6

A l’RFC 3513 es parla de tres tipus d’adreces:

  • Unicast identifica un node, el tràfic unicast va dirigit a un únic node.
  • Multicast identifica a un grup de nodes, el tràfic multicast va dirigit als nodes del grup.
  • Anycast identifica a un grup de nodes, el tràfic anycast va dirigit al node més proper del grup.

Adreces IPv6 Unicast

El tràfic més important de la xarxa és l’unicast que intenta transportar la informació dels servies IP a través de la xarxa, des d’un node origen cap a un node destí. Per tal de fer agrupacions de nodes que es puguin enrutar IPv4 ens ofereix mecanismes com l’adreçament per subnetting. Així doncs qualsevol IP d’IPv6 esta formada per dos grups un que indica a quina xarxa pertany i un altre que indica quin host és. Per tal de mantenir un paral·lelisme en la forma de d’adreçament es fa igual que en subnetting al final de l’adreça es posa una (/) i el número de bits que defineixen les IPs de xarxa.

L’RFC 3513 deixa molt clar que l’ID d’interficie hauria de ser: “Per totes les adreces unicast, excepte per les que comencin amb el valor binary 000, els IDs haurien de tenir 64 bits de llargada i amb format “Modified EUI-64″”. Aquesta regla preten mantenir un ID únic per totes les interficies de xarxa de forma global. Per generar l’ID d’interficie es pot fer de les següents formes:

  • Generat a partir de l’adreça de capa 2 en format “modified EUI-64”, amb aquesta informació generem el ID de la interficie. Els 7 primer bits de més pes del EUI-64 defineixen l’abast local quan aquests bits els trobem a 0, si els trobem en valor a 1 l’abast és global, no només local. Hi ha diferents mecanismes per definir cada tipus de medi al construir el ID d’interficie en el format “modified EUI-64” (més endavant en tornaré a parlar).
  • L’RFC 3041 defineix com autogenerar de forma aleatoria l’adreça. Aquest mecanisme s’ha desevolupat bàsicament per preservar la privacitat de les adreces globals.
  • Es pot obtenir l’ID d’interficie via DHCPv6.
  • Es pot configurar de forma manual.
  • CGAs basades en l’RFC 3972 a través de hash amb una clau pública. Aquest mètode de generar IDs d’interficie afegeix un nivell de seguretat i ofereix la capacitat d’autenticació. Els procés de descobriment dels veïns (Neighbor Discovery process) usen CGAs.

És important tenir clar el concepte de l’abast (scope), que seria algo així com l’abast del domini d’una xarxa, ja sigui a nivell físic o lògic. El fet de dominar el concepte de l’abast (scope) ens permetrà entendre millor el tràfic d’una xarxa i podrem aplicar polítiques sobre aquest tràfic de forma molt més senzilla. És obvi, que en les xarxes que usen adraçament enrutable, com IP, el direccoinament és essencial i això dona encara més importància a l’abst (scope) al que pertanyen els direccionaments unicast.

En IPv6, les adreces unicast tenen definits tres tipus d’abst (scopes):

  • The link-local scope identifica tots els hosts en un domini de capa 2. Les adreces unicast usades en aquest scope s’anomenen link-local addresses.
  • The unique-local scope identifica tots els dispositius descobribles dintre d’una administrative site o domini que tipicament conté diferents enllaços. Les adreces unicast usades en aquest scope s’anomenen ULAs.
  • The global scope identifica tots els dispositius descobribles a través d’internet. Les adreces unicast usades en aquest scope s’anomenen GUAs.
IPv6Figure2.gif

Els rangs de direccions privades (p.e. 10.x.y.z) usades actualment en les xarxes privades de moltes empreses és un dels temes importants a comentar. El grup de treball de la IETF que ha definit el IPv6 ha definit un scope i un tipus d’adreces unicast anomenat unique-local, mantenint les propietats que ja teniem amb les IPs privades d’IPv4.

Link-Local Addresses

Quan un node d’una xarxa IPv6 es posa en marxa, cada interficie té una direcció de capa 3 que només pot accedir als altres nodes del mateix enllaç. Aquest enllaç local té un abast de les adreces que estan connectats a ell, les adreces d’aquestes interficies s’anomenen adres link-local. En principi aquestes direccions no sabem sortir a través d’un gateway. Com a molt poden descobrir quina és la direcció d’aquesta porta d’enllaç.

IPv6Figure3.gif
IPv6Figure3.gif

Unique Local Unicast Address (ULAs)

Si el que volem és montar-nos un direccionament privat, no enrutable de forma global, tal com feiem amb IPv4 amb, per exemple, 10.x.y.z. el que hem de fer és referir-nos al RFC 4193 on es defineix un scope anomenat unique-local unicast address i les adreces d’aquest abast malgrat han de ser úniques per tot internet, per evitar els problemes que origina en IPv4 el fet de tenir rangs privats no únics, podem continuar tenint direccionaments privats a les nostres xarxes de forma local. Però ara enrutables a través de la resta de nodes d’internet. Per tant, ja no tenim la dependència del NAT com passava en IPv4.

IPv6Figure4.gif

L’espectre reservat per les adreces unicast de tipus ULA és el FC00::/7, tal com podem veure en l’esquema anterior. Alguns comentaris dels elements de l’esquema:

  • L identifica la política d’assignacions. Actualment només s’usa el valor 1 (FD00::/8) informant de que es tracta d’una assignació local.
  • Global ID és un identificador de 40 bits que assegura que la direcció és única. Aquest identificador es genera de forma pseu-aleatoria i no pot ser seqüèncial. Perquè les ULAs no huarien de ser enrutables globalment, no tenen la necessitat de ser agregades, per això els IDs globals no cal que siguin seqüèncials.
  • Subnet ID l’administrador de la xarxa local assigna aquest valor per tal d’organitzar la jerarquia de la xarxa local.
  • Interface ID té el mateix significat per totes les adreces unicast i té 64 bits en format “modified EUI-64”.

Una millora important pel que fa a les ULAs, respecte al sistema de direccions privades anterior, és que ara és més senzill internconnectar dues xarxes privades aïllades a través d’internet. Ja que aquestes saben la forma d’arribar entre una i l’altre sense necessitat d’una VPN. Per exemple, mai hi haurà conflictes d’IP entre dues xarxes privades aïllades gràcies al direccionament IPv6.

Global Unicast Address

Les direccions GUA, com el seu nom indica pretenen ser úniques a nivell mundial i enrutables. Aquestes direccions s’idenfiquen amb els 3 bits de més pes fixats amb els valors “001” (2000::/3), com es defineix en el RFC 3587.

Degut a que l’espai de direccions és molt més gran que en IPv4, per tal de que les taules d’enrutament no sigui excessivament grans IPv6 es veu obligat a establir unes normes en els prefixes d’agregació molt estrictes. Gràcies a això es poden controlar molt millor aquestes taules d’enrutament que tan podrien preocupar pel rendiment dels dispositius de xarxa. S’han dedicat molts esofrços a desenvolupar una estructura flexible que faciliti una simple agregació de les GUAs.

Finalment a l’RFC 3587 es defineixen les agregacions a través d’unes polítiques molt riguroses per tal de simplificar al màxim l’estructura de les GUAs:

IPv6Figure5.gif
  • Global routing prefix l’ISP assigna un tros del seu prefix assignat per la IANA, i aquest reservar un subespai pels seus clients. Normalment menys de 48bits, els procediments a seguir estan comentat a l’RFC 3177.
  • Subnet ID cada organització rep un prefix del seu ISP on el prefix global d’enrutament identifica el SP i la organitzación dins l’SP, i el subnet ID identifica l’estructura de l’organització.
  • Interface ID els 64bits de menys pes s’usen per l’ID d’interficie dels nodes del l’enllaç.

Taula amb el resum de les assignacions d’adreces IPv6 de tipus ULA en el moment d’escriure aquest document:

IPv6Table1.gif

El RIRs actuals són:

  • African Network Information Center (AfriNIC)
  • Asia Pacific Network Information Center (APNIC)
  • American Registry for Internet Numbers (ARIN)
  • Regional Latin-American and Caribbean IP Address Registry (LACNIC)
  • Rseaux IP Europens (RIPE NCC)

Els RIRs assignen troços dels prefixes que han rebut de la IANA als NIR, als LIR, o als ISPs. Per fer totes aquestes assignacions s’usen de 32 a 35 bits.

IPv6Figure6.gif

Special-Use Addresses

Finalment, un petit grup d’adreces unicast té ua definició especial d’ús. No tenen un scrope associciat, per això es discuteixen a part de les altre adreces unicast.

  • The unspecified address is not assigned to any interfaces. However, it is used as an SA by devices that do not have an IPv6 address or their IPv6 address has not been yet proven to be unique within the local link. The unspecified IPv6 address has all 128 bits set to 0. It can be represented as 0:0:0:0:0:0:0:0, or as :: in compressed form.
  • The loopback address is used by every node to refer to itself, and it is similar to the 127.0.0.1 address in IPv4. In IPv6, the loopback address has all the 127 leading bits set to 0, and the last bit is 1. It can be represented as 0:0:0:0:0:0:0:1, or as ::1 in compressed form.

Les altres dos tipus espacials d’adreces esta relacionat en la coexistència entre IPv4 i IPv6. Enllaçant els dos espais d’adreces és molt important suportar la coexistència d’aquests dos espais d’adreces. Així doncs s’han desenvolupat dos mecanismes per mantenir les relacions entre adreces IPv4 i IPv6:

  • The IPv4-compatible IPv6 address was defined to be used for dynamic tunneling and is built by adding the IPv4 address to 96 bits set to 0. This address type was deprecated and it is no longer used.
  • The IPv4-mapped IPv6 address is used to represent the address of an IPv4 node in an IPv6 format. The IPv4-mapped IPv6 address is built by adding the IPv4 address to 80 bits set to 0 followed by 16 bits set to 1.

Exemple: la IPv4 192.168.10.1 amb les seves correspondències IPv6 segons el sistema IPv4-compatible i IPv4-mapped.

IPV6Example4.gif
IPv6Table2.gif

IPv6 Anycast Addresses

Quan una direcció unicast s’assigna a múltiples interficies, típicament que pertanyen a diferents nodes, això s’esdevé en una adreça anycast i s’especifica a l’RFC 3513. Les adreces anycast i unicast no es poden distingir, així doncs cal indicar-li al node que la seva adreça unicast és del tipus anycast. Un paquet de tipus anycast serà entregat a l’adreça destí unicast més propera que trobi. Una adreça anycast no es pot usar com a adreça origen. Sovint aquest recurs, anycast, s’usa per replicar serveis molt importants dins d’una xarxa, com podrien ser els DNS, els servidors web, etc.

L’adreça anycast del router de la subxarxa es defineix a l’RFC 3513 per cada prefix com l’adreça amb l’ID d’interficie a ‘0’. Un router ha de suportar l’adreça anycast del router de la subxarxa per tots els prefixes configurats a les seves interficies. Un paquet que vagi dirigit a alguna de les interficies haurà de ser entregat al router més proper que tingui una interficie amb aquest prefix.

L’RFC 2526 defineix un conjunt adicional d’adreces anycast reservades donat un prefix. A continuació podem veure l’estrucutra de les adreces anycast.

IPv6Figure8.gif

El format de les adreces deixa clar l’intent de reservar part de les adreces d’una subxarxa per usar-les com a anycast. Això es va fer per evitar possibles conflictes amb altres adreces reservades. El camp anycast ID del gràfic anterior pot prendre els següents valors: 0 a 125,127 (00-7D, 7F) estan reservades; ID 126 (7E) és l’única que esta en ús per les adreces anycast dels agents domèstics d’MIPv6.

Note: MIPv6 provides a host with a mechanism to discover the address of one of his home agents (HAs). The host can attempt to register to the home agent’s anycast address (described in this section) hosting its home prefix. One of the HAs will receive the request, reject the registration, and instead reply to the host with a list of the actual addresses of the HAs it can use.

IPv6 Multicast Addresses

Una adreça multicast identifica un grup d’interficies. Un paquet amb una direcció de destí multicast s’entregarà a tots els membres del grup. Cal recordar també que una adreça multicast no pot ser mai origen. Una adreça multicast té els seus 8 bits de més pes amb valors a 1 (FF00::/8) com podem veure en el següent gràfic.

IPv6Figure9.gif

Tres dels quatre bits en els flag estan en usa actualment:

  • El bit de menys pes “T” definit a l’RFC 3513 té sempre com a valor 0 per les adreces multicast assignades per la IANA. Si té valor 1, es refereix a adreces multicast no assignades de forma permanent.
  • El bit “P” definit a l’RFC 3306, indica que una adreça multicast esta basada (1) o no (0) en una adreça unicast.
  • El bit “R” definit a l’RFC 3956, si té com a valor 1 indica que conté adreces unicast del tipus RP (repetidors de multicast) en el grup d’adreces que conté.

El 4rt bit que falta esta reservat per usos futurs i actualment es deixa sempre fix a 0. El bit “P” indica que una adreça multicast esta formada en base a una adreça unicast; perquè una adreça unicast es considera que té un temps de vida limitat, per tant, una adreça multicast d’aquest tipus no podrà ser permanent. Això vol dir que el bit “P” amb valor 1 requereix que el bit “T” també tingui valor 1.

Scoping és una potent funcionalitat incorporada a les adreces multicast d’IPv6. Proporciona als routers la informació necessaria per transportar el tràfic multicast al domini que toca. A continuació podem veure una taula amb els possibles valors dels 4 bits.

IPv6Table3.gif

Unicast-Prefix-Based Multicast Addresses

Les adreces GLOP que es van introduir a IPv4 per tal de crear adreces multicast globals i úniques per organitzacions que tinguessin ASNs. Les adreces es contruien en base als ASNs globlas i únics. L’RFC 3306 amplia aquest concepte i defineix un mecanisme que genera adreces multicast IPv6 globals basades en un prefixe unicast com podem veure en el següent gràfic.

IPv6Figure10.gif

Els bits reservats es fixen a 0 (els 64 bits del camp del prefixe unicast). Per exemple, a continuació podem veure l’adreça multicast de la direcció unicast 2001:100:abc:1::/64.

IPv6Example5.gif

Nota: L’abast de l’adreça unicast basada en el prefix no huaria d’exedir la del prefixe unicast “embedid”.

Solicited-Node Multicast Addresses

A partir de l’adreça unicast de capa 3 gràcies a aquest mecanisme podem saber l’adreça d’enllaç local (la MAC). El format de l’adreça FF02::1:FF00:0000/104, on els 24 bits de menys pes són els mateixos per les adreces unicast que anycast que les han generat. Això representa un mètoda deterministic per identificar el grup d’enllaços locals multicast en que un host amb una direcció IPv6 unicast esta escoltant. Si no es pot determinar això llavors aquesta informació multicast s’ha d’enviar a l’adreça del solicited-node multicast.

IPv6 and Layer 2 Addressing

Les adreces IPv6 tenen dues correlació amb les adreces de capa 2. La primera IPv6 és capaç de generar un ID d’interficie a partir d’una adreça de capa 2. La segona és comuna amb IPv4, proveeix d’un mecanisme per mapejar les adreces IP mutlicast amb les adreces multicast de capa 2.

EUI-64 Interface Identifiers

La IEEE va especificar el format d’identificadors EUI-64. Per fer un identificador IPv6 d’ID d’interficie, la única cosa que s’ha de fer és moure el sisé bit en l’ordre estàndard d’internet (universal/bit local).

La IEEE també va especificar un mecanisme per generar un identificador de 64bits (EUI-64) a partir dels 48 bits de l’adreça de capa 2. Amb aquest mecanisme podem establir una correlació entre les adreces MAC i les ID d’interficie com a part de l’adreça IPv6. A continuació pdoem veure un exemple de com es genera un ID d’interficie a partir d’una MAC. Primer cal crear l’identificador EUI-64 i després el modifiquem per crear l’ID d’interficie.

IPv6Figure13.gif

Pv6 Addressing Architecture at a Glance

IPv6Table6.gif
IPv6Table6b.gif