Category: Networking and Internet

mini-cookbook: ssh passwordless

Reading time: < 1 minute

Sense ajudes, descripcions ni notes… només per refrescar el tema amb 1s:

  • client ssh:
    • ssh-keygen -t dsa
    • id_dsa.pub el copiem al servidor
  • servidor ssh:
    • afegim contingut id_dsa.pub al ~/.ssh/authorized_keys
    • borrem id_dsa.pub

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.

Substituts wireless dels cables USB

Reading time: 2 – 4 minutes

Actualment s’esta treballant en tres línies a l’hora d’elminar els cables del PC, normalment USB, el típic cable de ratolí, telcat, impresora, escaner, camara de fotos, etc. Totes les solucions són usant com a tecnologia de radio el UWB (wikipedia: UWB). De fet, durant aquest gener la IEEE va decidir desistir en l’estandarització d’aquesta tecnologia que havia de ser l’estàndard 802.15.3a. Però múltiples desacrods en el grup de treball van acabar en la conclusió de que no s’entandaritzaria.

freescale-fig1.gif

Doncs bé les tendències en les que s’estan treballant per tal de substituir els cables del PC als periferics són:

  • 1. Convertir directament les dades serie de l’USB en senyals de radio d’Ultra-Wideband(UWB). Ni els dispositius USB ni els host USB necessiten cap canvi ja que tot és completament transparent a nivel d’USB.
  • freescale-fig2.gif
  • 2. Usar només els connectors USB, però re-empaquetar totes les dades amb un altre protocol, per exemple TCP/IP. Així doncs la comunicació per aire es fa sobre aquest nou protocol, quan arriba al destí es re-converteix a USB. Així es manté compatibilitat amb els dispostius. Excepte les que usen el mode isochronous.
  • 3. Consisteix en redissenyar l’USB internament fins hi tot els sistemes electrònics. Només mantenint compatibilitat en les aplicacions però re-fent tots els drivers de host i de dispositius.

Si voleu aprofundir més en la discusió podeu llegir l’article Making USB without wires work for consumers (local).

Hardware

Alguns dispositius que ja implementen alguna de les tècniques explicades anteriorment:

Com funciona la VoIP: protocols, codecs i altres

Reading time: 10 – 16 minutes

Aquí teniu la continuació que us vaig prometre de les bases de la VoIP. Aquest article intentaré fer-lo tan entenedor com l’anterior però no serà senzill perquè els temes ha parlar són ja força tècnics i especialitzats. Malgrat això és molt necessari tenir-los clars sinó quan toquem sistemes de VoIP reals no sabrem a que es refereixen els manuals o els altres companys quan ens expliquen els motius pels que passen les coses. O simplement, perquè fan falta certs dispositius en les configuracions.

Altre cop he de fer referència a Network System Design Line, aquest cop a l’article How VoIP works: Protocols, codecs, and more (local).

Resumint les idees bàsiques

En l’article de les bases de la VoIP va quedar molt clar el procés que segueix una trucada de VoIP. També es va insinuar la importància del temps que es triga en mostrejar les ones analògiques de la veu (digitalitzar la veu) i l’espai que ocupa aquesta digitalització. Això repercutirà de forma directa en el temps que triguem en transportar aquesta informació fins a l’altre extrem on es farà el procés invers fins que l’interlocutor senti la nostre veu.

Bé doncs, en aquest document em centraré en explicar que es fa després de digitalitzar la veu, o sigui, es comprimeix aquesta informació abans de ser transportada perquè ocupi menys espai (això ho fan els codecs). Per altre banda, cal que pensem que quan enviem un email o una fotografia a través d’una xarxa IP aquesta informació no és sensible al temps. O sigui, ens és igual que trigui uns segons més o menys en arribar això no afecta en el missatge que es transporta. Obviament en una conversa això no és així i aquests paquets han d’arribar prou ràpid a l’altre extrem perquè la sensació de “temps real” sigui suficient.

Les xarxes IP, per defecte, són xarxes de tipus best-effort això vol dir que tots els paquets que viatgen a través d’elles intenten passar el més ràpid possible però sense cap tipus d’arbitratge. Parlant en plata, la llei del més fort. Per tant, es tracta inicialment d’un entorn poc indicat per transportar informació sensible al temps. Per exemple, informació en temps real (o streaming) d’audio i/o video.

Per tal d’adequar millor aquest medi a les comunicacions sensibles al temps s’usen tècniques de QoS. O sigui, intentem montar un sistema d’arbitratge en els nodes de la xarxa per tal de prioritzar el tràfic sensible al temps. Per exemple, el tràfic de VoIP. Si la xarxa en la que s’ha de treballar no té gaire càrrega de tràfic això no és massa important. Cal tenir present que internet no és una xarxa amb QoS. Per tant, és un entorn hostil per les nostres trucades de VoIP.

Entrant una mica en temes tècnics, el que hem d’aconseguir pel que fa als retards (delay) de la xarxa entre els dos extrems són temps inferiors a 100ms. Tot i que amb retards per paquet de 100 a 200ms poden arribar a passar trucades ja es poden començar a donar fenomens molestos pels interlocutors. Sovint problemes d’echo.

Problemes típics d’una xarxa IP

Quins són els problemes que hem d’intentar evitar que tingui una xarxa IP per poder-hi passar VoIP sobre d’ella:

  • Delay el retard, temps que triguen els paquets a viatjar del punt inicial al final. Els retards massa alts acostumen a provocar problemes d’echo acustic.
  • Packet loss perdua de paquets, sobretot es dona en les xarxes WAN, si els paquets han de viatjar a través de molts punts (gateways) es podrien perdre. Perdent doncs informació del missatge que es transporta.
  • Jitter canvis sobtats i no desitjats en el temps que triguen els paquets en arribar, això pot provar desordre. Per solucionar-ho sovint s’usen buffers i paquets petits, amb poca informació.
  • Echo els paquets arriben més d’una vegada per diferents camins. No és el mateix que l’echo acustic.

Resum de passos que segueix la veu fins arribar a l’altre extrem

En el següent gràfic podem veure quins són tots els passos, un per un, que segueix la nostre veu fins arribar a l’interl·locutor. Com podem veure cada un dels passos té una serie de codecs, protocols i normes associades que a continuació es descriuen.

adifigure1.jpg

Com ja s’ha comentat el primer que es fa després de mostrejar la veu (digitalitzar) es codifica i comprimeix per tal de reduir els requeriments d’amplada de banda. Aquest procés el porten a terme els codecs.

Els paquets de dades comprimits es mouen a través de les xarxes gràcies a un protocol de transport. Els gateways s’encarreguen d’enrutar aquests paquets entre diferents xarxes IP (o d’altres tipus, si cal) fins que els paquets arriben al seu destí. Quan arriba al destí es decodifiquen (i descomprimeixen) els paquets rebuts i es converteixen altre cop en audio.

VoIP en el model OSI

El model de 7 capes OSI defineix qualsevol procés de networking (interconnexió digital en una xarxa). Si hi ha dos extrems que volen tenir una sessió de comunicació, les dades que aquests generen comença a la capa 7, patint les encapsulacions necessaries fins arribar a al medi de transmissió (per on viatgen les dades: cable, aire, llum, etc) a l’altre extrem passa el procés invers des del medi fins a l’usuari. Bé doncs això és el que ens mostra el següent gràfic i ens col·loca cada un dels protocols en una de les capes.

adifigure2.jpg

Session control: H.323 vs. SIP

El primer que ens cal per establir una comunicació en VoIP és un protocol de sessió que ens indiqui com informem a la xarxa que existim, com intentem comunicar-nos amb altres usuaris o com rebem les comunicacions d’altres usuaris. Els dos protocols més coneguts que s’encarreguen d’això són H.323 i SIP. Malgrat n’hi ha molts d’altres com ara IAX (protocol usat per Asterisk).

International Telecommunication Union (ITU) H.323

L’H.323 és un estàndard de la ITU originariament desenvolupat per enviar veu i dades en temps real (videoconferencia i similars). Malgrat això una de les primeres aplicacions que va tenir va ser la VoIP. De fet, el H.323 més que un protocol és en si és un grup de d’estàndards, codecs i protocols que diuen com establir una comunicació multimedia a través d’una xarxa IP. Per exemple, el protocol de senyalització que usa H.323 és el H.225 i el protocol de negociació de funcionalitats el H.245.

Session Initiation Protocol (SIP)

El SIP el va definir la IETF a l’RFC 3261. Es va desenvolupar especialment per la telefonia IP. De fet, es considera una solució molt més neta i senzilla que l’H.323. SIP s’usa amb SDP per tal de descobrir usuaris; a més ofereix la capacitat de descobrir funcionalitats i de gestionar trucades. SDP és esencialment un format que descriu com fixar els paràmetres d’inicialització per tal d’intercanviar la informació multimèdia. Bàsicament SIP/SDP és analoga a H.225/H.245 en el protocol H.323.

El protocol SIP ens permet a més establir connexions entre dos extrems sense la necessitat de disposar d’un servidor. Tot i que no és l’habitual. Ja que normalment el que fan els clients SIP és registrar-se contra un servidor públic per tal de mostrar-se a la resta de clients de la xarxa.

Transport layer protocols

Els protocols de senyalització descrits anteriorment són els responsables d’establir les configuracions a usar en una sessió multimèdia entre dos usuaris. Però aquesta informació de senyalització viatjarà per la xarxa a través dels protocols de transport de sempre, o sigui, UDP (no orientat a connexió) i/o TCP (orientat a connexió).

Transportant la conversa: RTP

El protocol RTP ofereix un servei d’entrega de paquets amb informació d’audio i video que ha de ser servida en temps real. Aquest protocol usa com a protocol de transport el UDP per minimitzar la capçalarela (la capçalera UDP és molt més petita que TCP). A canvi d’això no pot garantir l’entrega dels paquets que transporta (UDP no és orientat a connexió, no hi ha retransmissió de paquets perduts), a més tampoc pot garantir que l’ordre en que entrega els paquets sigui el correcte.

Estructura d’un paquet RTP:

adifigure3.jpg

Així doncs el que intenta fer RTP és afegir aquelles funcionalitats que no li dona UDP per tal de que les dades que transporta siguin el màxim útils possible. Les funcionalitats que dona RTP a UDP són: nivell de QoS, marques de temps (timestamps), números de seqüència i confirmació de recepció per cada paquet enviat. També pot suportar esquemes de correcció d’errors per fer més rebustes les dades que transporta, fins hi tot algunes opcions de xifrat bàsiques per les dades del paquet.

Obviament això carrega una mica el paquet UDP, en aquest gràfic podem veure una comparació amb el preu que paguem per obtenir totes aquestes funcionalitats.

adifigure4.jpg

RTP Control Protocol (RTCP)

RTCP és un protocol complementari a RTP i s’usa per enviar informació de control, com a ara el número de paquets perduts, jitter, retard, etc. És molt útil per saber quina és la qualitat de la sessió que estem mantenint. Gràcies a la informació d’aquest protocol podem saber la necessitat que té la nostre xarxa de que li donem suport de QoS. O la necessitat de canviar els codecs que estem usant per ajustar-nos millor a les necessitats de la xarxa en la que treballem.

Codecs

A dalt de tot de la pila VoIP hi trobem els protocols encarregats de comprimir la informació que s’ha mostrejat de la font de digitalització (la nostre veu, imatges de video, etc). Els factors que determinen la eficència d’una codec són: el nivell de compresió (quan més comprimeixi millor), temps compresió i descompresió (quan menys trigui en fer el procés millor), suport a la perdua de paquets (capacitat de reproduir la informació original sense tenir tots els paquets en el destí), correcció d’errors, cost intel·lectual (cal pensar que no tots els codecs són lliures, n’hi ha molts de pagament).

Codecs d’audio:

  • G.711 (any 1988) estàndard internacional per la codificació de converses telefóniques. Usa 64kbps d’amplada de banda per cada conversa.
  • G.723.1 (any 1996) usa de 5.3 a 6.3kbps d’amplada de banda. És capaç de detectar la no activitat de la veu, per tal de consumir menys amplada de banda i també és capaç de generar soroll de confort (soroll necessari per saber que la trucada esta en curs i que no hi ha problemes a la línia). És força bo suportant perdua de paquets i en corregir errors de bits erronis. La família d’estàndards internacional per transportar video H.324 estableix aquest protocol d’audio com a estàndard per l’audio.
  • G.729 (any 1996) usa uns 8kbps d’amplada de banda, però també pot treballar amb 6.4kbps o 11.8kbps. Suporta detecció d’activitat de la veu i generació de soroll de confort.
  • GSM codecs de veu coneguts gràcies a la telefonia mòbil, definits per l’ETSI. L’amplada de banda que usen per treballar és d’uns 13kbps.
  • Speex és OpenSource i el varem desenvolupar a xiph.org. Capaç de treballar amb mostres de 8, 16 i 32kHz. Capaç de treballar amb amplades de banda de 2kpbs fins a 44kbps. A més és resistent als erros de la xarxa, suporta detecció d’activitat de la veu. A més també suporta variable-bit-rates, o sigui, pot adaptar el mostreix segons la complexitat dels sons a enviar, fins hi tot és capaç de soportar codificació en estereo.

Per acabar…

Amb aquest document ja em fet un repas a grans trets dels elements que composen una comunicació de VoIP. Quan ens diposem a configurar un sistema de VoIP trobarem moltes altres sigles, codecs, protocols, etc. però aquest document ens serveix com una referència bàsica sobre la que començar a treballar mentre anem adquirint experiència en aquest món tan interessant.

Bases de la VoIP

Reading time: 8 – 12 minutes

Des de fa un parell d’anys s’ha posat molt de moda parlar de Veu sobre IP (VoIP) però sovint comencem la casa per la taulada i de vegades val la pena tenir una referència on acudir per consultar com funciona tot plegat des de sota, així doncs amb aquest article espero poder explicar una mica que hi ha darrera d’aquest màgia. Després d’aquest article en tinc un altre preparat que és molt més aplicat i específic no tan teòric, parlant més a fons dels aspectes tècnics de la VoIP.

Com ja comença a ser habitual per escriure articles d’aquest tipus m’inspiro en articles escrits a Network Systems Design Line, concretament m’he inspirat en Voice over IP (VoIP)–The basics (local).

Quan parlem de VoIP ens referima un conjunt de serveis que pretenen oferir un servei telefonic tan a usuaris residencials com a empreses. A més la VoIP la usen els proveedors de serveis per transportar trucades entre ells. A més les empreses tan petites com grans la poden usar per comunicar les seves oficines. A més la VoIP es pot usar com a substitut o complement a la telefonia convencional.

Sovint les operadores telefóniques usen serveis de VoIP de forma transparent pels usuaris per tal de connectar les trucades entre usuaris. Així poden reaprofitar les seves infraestructures tan per transportar veu com dades simultaneament. La principal diferència entre els serveis tradicionals de telèfon i la VoIP és que el primer es basa en la conmutació de circuits i el segon en la conmutació de paquets. Així doncs quan connectem dues trucades de veu convencionals en el fons el que estem fent és connectar un cable d’un extrem de la trucada a l’altre. Això implica tenir els recursos de la xarxa reservats durant el temps que dura la trucada. Per tant, es fa un ús molt ineficient de l’amplada de banda disponible en aquest cable/circuit que esta connectat durant tot el temps de la trucada de forma permanent. Aquest problema es soluciona en la conmutació de paquets ja que es multiplexen les trucades en el temps i un mateix circuit pot transportar més d’una trucada de forma simultanea.

EFigure1.gif

Arribats en aquest punt ja tenim clar que l’ús de les xarxes de conmutació de paquets són més eficients si la densistat de trucades a transportar de forma simultanea augmenta. Perquè ens fem una idea les fibres òptiques transosceaniques poden transportar més de 100 milions de trucades cada una.

Components bàsics d’un servei telefónic

Bàsicament per tal de poder posar en funcionament un servei de telèfon fan falta els següents 4 components:

  • Senyalització es refereix a la comunicació entre el telèfon i el servei telefónic. Informa de que hem despenjat/penjat el telèfon, quin número hem marcat, que ens esta entrant una trucada, etc.
  • Conversa la veu que es transmet a través de la xarxa.
  • Funcionalitats trucada en espera, desviament de trucades, bústia de veu, etc.
  • Alimentació com enviem l’eletricitat al telèfon perquè funcioni. En els serveis telfónics convencionals aquesta alimentació l’ofereix la pròpia línea.

Senyalització en la VoIP

La senyalització es refereix bàsicament a com el telèfon es comunica amb la central telefónica. Però els conmutadors de xarxa intermitjos també han de reenviar-se aquestes senyals de control fins a arribar al teléfon de l’usuari. Així doncs cal entendre alguns tipus de senyalitzacions bàsiques.

Com un teléfon sap que volem fer una trucada? en el següent gràfic podem veure un esquema del procés. Quan despengem el telèfon, la central telefónica ens envia el to. Llavors marquem el número amb el que volem parlar, quan això passa s’intercanvien una serie de freqüències (o pulsos) entre el nostre teléfon i la centra telefónica per tal de comunicar a aquesta quin és el teléfon amb el que volem marcar. Llavors la central determina la ruta de la trucada que volem fer i notifica al destí que volem parlar amb ell, o sigui, es posa a sonar el teléfon destí.

EFigure2.gif

Fixeu-vos que en aquests senzills passos i que tots tenim tan clar ja hi ha una bona colla de senyalitzacions que han viatjat per la línia i encara no em començat la conversa. De tota aquesta idea hi ha un detall important, la part del sistema telefónic que hi ha dins de casa nostre no ha canviat des de fa 20 o 30 anys. Així tots els canvis s’han fet a la xarxa i de forma completament transparent pels usuaris.

Si un dels extrems de la trucada uses VoIP l’esquema podria quedar, per exemple, així:

EFigure3.gif

En aquest cas, el terminal telefónic esta connectata a un adaptador que el connecta a internet. Aquest adaptador actua com a traductor, converteix la nostre veu en paquets de tipus IP que s’envien a través d’internet. En aquest cas la senyalització és igual que en cas anterior, però l’adaptador es dedica a traduir les senyals analògiques en paquets que viatgen a través d’IP. Després el nostre proveedor de servei de VoIP convertirà aquests paquets en senyals altre cop compatibles amb la xarxa de teléfon convencional. Perquè el destí pugui entendre la trucada. Tot això serà completament transparent pels usuaris que no han de notar cap diferència.

Finalment si ens imaginem la senyalització entre dues trucades de VoIP, l’esquema quedaria així:

EFigure4.gif

El primer que salta a la vista és que ja no ens cal al xarxat telefónica convencional. Així doncs la senyalització digital que genera un extrem pot viatjar a través de la xarxa IP fins arribar al destí. Així doncs acabem de convertir el sistema de teléfon convencional en un sistema de dades IP completament. On no ens calen altre elements que els ja coneguts per les nostres xarxes de dades.

Com ho fa la VoIP per transportar una conversa

La veu humana esta composta per ones de so analògiques. Els sistemes de teléfon tradicionals transporten la veu com una successió de canvis de voltatge a través d’un parell de cables (s’anomenen senyals portadores). Quan aquestes senyals arriben a l’altre extrem el que fan és amplificar-se a través d’un altaveu, això produeix un so molt semblant al so original. En els sistemes de telefonia digitals (inclosa la VoIP), no tenim un circuit dedicat a transferir la veu. La veu humana es converteix en un fluxe digital (o series de 1s i 0s) que arriba fins al destinari on s’intenta re-generar els sons que van ser emesos per l’emisor. La converció analogic-digital de l’origen s’anomena mostreix (sampling), bàsicament es tracta de prendre una serie de mesures sobre els freqüències emeses per la veu a intervals de temps fixes. Després el que es fa és transportar aquestes mesures i no pas les freqüències emeses per la veu.

EFigure5.gif

Esquema dels processos de mostreix de la veu:

EFigure6.gif

La gràcia perquè la senyal origen s’assembli al màxim possible amb la de destí esta en prendre el màxim número de mesures possible. Però cal pensar que quantes més mesures es prenguin més mesures s’hauran d’enviar i més ràpida haurà de ser la línia de dades. Així doncs cal buscar un compromís entre la qualitat de mostres preses i l’espai que ocupen, per poder-les enviar prou ràpid.

Perquè tinguem quatre dades reals la freqüència més baixa que emet la veu humana és d’uns 100Hz i la més alta de 1700Hz. Entre els sorolls i les freqüències harmoniques que emetem més o menys necessitem uns 4000Hz com a molt agut. S’agafen unes 8000 mostres cada segon, o sigui, la freqüència de mostreix és d’uns 8KHz. Aquestes unitats de mesura capturades es posen dins dels paquets i s’envien cap al destinari on es generen les freqüències segons les dades que indiquen les mesures rebudes.

Alimentant les xarxes de VoIP

En les xarxes telefóniques convencionals com he dit l’alimentació electrica del teléfon s’agafa de la línia així doncs no ens hem de preocupar d’endollar el teléfon a la xarxa eléctrica de casa. Això que sembla una tonteria permet, per exemple, fer trucades telefóniques quan s’envà la llum. En un sistema digital això seria un greu problema perquè la línia no transporta l’alimentació del terminal telefónic.

EFigure8.gif

Per tant, quan marxa la llum amb un sistema digital no podem fer trucades si s’envà la llum. Això suposa un gran problema ja que en cas d’emergència no ens podem comunicar. Així doncs, cal que pensem en algún sistema d’alimentació alternatiu per quan en cas d’emergència haguem d’usar el teléfon o quedarem aïllats.

Resumint

Escencialment la forma de trucar no ha canviat per l’usuari. Però si que els processos tècnics que composen el procés de fer una trucada han canviat moltíssim internament i tecnològicament ja no té res que veure un sistema de telefonia convencional amb els nous sistemes de telefonia de VoIP. Així doncs el que abans era un problema pels enginyers de telecomunicacions, ara és un problema pels enginyers de xarxes.

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

PoE – Power over Ethernet

Reading time: 2 – 2 minutes

Jugant amb els amics més d’una vegada hem injectat l’alimentació d’un dispositiu a través del cable ethernet l’invent és una mica d’anar per casa. Però serveix per estalviar-se una bona quantitat de calers i poder tirar només un cable entre el switch i el dispositu a alimentar. Per exemple, en algunes instal·lacions wifi del poble s’ha fet: Unim eBosc i ePineda (quasi 1km).

Doncs bé fins que no m’he llegit l’article que us vull recomanar pensava que l’estàndard PoE de la IEEE no era gaire més del que ja feiem nosaltres. Però després de llegir Power over Ethernet: the reality of designing a powered device (local) realment he vist que per començar els elements que fan falta per crear un dispositiu que compleixi l’estàndard PoE són força més complexes i professionals que com ho feiem nosaltres. Un bon exemple és mirar l’esquema dels components que componen un dispositiu PoE.

Així doncs us recomano perdre 5min en llegir l’article i tenir el tema PoE més que clar. Que sempre va bé saber perquè paguem tants calers per certes coses.

Tipus d’VPNs

Reading time: 7 – 12 minutes

Quan parlem d’VPNs gairebé tothom té clar perquè serveixen i què fan. El fotut és quan comencem a parlar de quin tipus d’implementació s’ha d’usar o s’ha usat per montar-la. Això fa que un munt de sigles comencin a saltar sobre la taula i al final si no tenim una molt bona base tècnica som incapaços d’entendre a què es refereixen. Aprofitant un article que ha aparegut a Network Systems DesignLine, de fet, és la primera part d’una serie encara incompleta anomenada Compare, design, and deploy VPNs–A tutorial–Part I he decidit fer un petit resum dels tipus d’VPN més comuns.

Dispositius d’una VPN

Per tal de poder parlar en propietat quan parlem dels elements de la VPN a continuació s’intenta definir una mica els dispositius que intervenen (o poden intervenir) en una VPN i on estan situats.

En el costat del client:

  • Customer (C) devices els dispositius C són simples, per exemple routers i switchos dins de la xarxa del client. Aquests dispositius no estan connectats a la xarxa del proveedor de servei. Aquests dispositius no saben distingir si estan o no dintre d’una VPN.
  • Customer Edge (CE) devices són els dispotius del client que donen conectivitat a la xarxa del proveedor de serveis.(via Provider Edge [PE]).
    • CE-r routers
    • CE-s switches

En les VPNs basades en CE, els dispositius CE si que estan disponibles per ser usades amb la VPN. Si les VPNs estan basades en els PE, els dispositius CE no estan disponibles per la VPN.

En les VPNs site-to-site, els dispositius del proveidor de serveis es poden classificar en:

  • Service Provider (P) devices els dispositius P com ara routers i switches dins de la xarxa del proveedor que no es connecten directament a la xarxa del client.
  • Service Provider Edge (PE) devices connectats directament a la xarxa del client a través dels dispositius CE. En les VPNs basades en PE aquests dispositius són visibles des de l’VPN, en les basades en CE no són visibles.
    • PE-r Provider Edge routers
    • PE-s Provider Edge switches
    • PE-rs Provider Edge devices that are capable of both routing and switching
VPNFigure1.gif

VPNs de capa 2, com ara VPLS, afegeixen un nivell a la gerarquia per ser més escalable (VPLS llavors passa a ser Hierarchical VPLS [H-VPLS]). En aquest cas, les funcionalitats dels dispositius PE, es divideixen en dos parts U-PE i N-PE.

Cal que no oblidem que els U-PE i els N-PE són equivalents al PE-CLE i al PE-POP, respectivament. Quan tenim un dispositiu PE-U de capa 2, podem referir-nos a ell com un MTU-s.

VPNFigure2.gif

Altres dispositius d’una VPN poden ser els NAS i els concentradors o gateways d’VPN. Un NAS és un dispositiu que fa d’interficie entre la xarxa d’accés (com ara PSTN) i les xarxes de conmutació de paquets (com ara un backbone IP). En un accés remot VPN el NAS pot treballar com a finalitzador de tunel.

Depenent del protocol usat per establir un accés remot el NAS es pot anomenar de diferents formes Layer Two Forwarding (L2F) Protocol NAS, Layer Two Tunneling Protocol (L2TP) Access Concentrator (LAC),o Point-to-Point Tunneling Protocol (PPTP) Access Concentrator (PAC).

Un gateway o concentrador d’VPNs actua com a punt final d’un túnel (VPN endpoint), especialment quan parlem d’accessos remots o VPNs basades en CEs (site-to-site).

Segons el protocol usat per aquests accessos remots el gateway o concentrador d’VPNs es pot anomenar, per exemple, L2F Home Gateway, L2TP Network Server (LNS), o PPTP Network Server (PNS).

Tecnologies i protocols usats en VPN del tipus Site-to-Site (o LAN-to-LAN)

En les VPNs site-to-site (o LAN-to-LAN) la informació del client viatja entre dispositius CE o entre dispositius PE.

  • IPsec són un conjunt de protocols dissenyats per protegir el tràfic IP entre gateways o hosts. Normalment s’usa aquest protocol per establir VPNs entre CEs.
  • GRE usat per fer túnels i transport de multiprotocols entre CEs. La seguretat de GRE és baixa o no inherent al protocol, però si volem podem aprofitar IPSsec per securitzar els túnels montats en GRE.
  • Draft Martini (Any Transport over MPLS–AToM) permet transportar protocols punt a punt com ara Frame Relay, ATM, Ethernet, Ethernet VLAN (802.1Q), High-Level Data Link Control (HDLC), i tràfic PPP sobre MPLS.
  • L2TPv3 permet transportar protocols com ara Frame Relay, ATM, Ethernet, Ethernet VLAN, HDLC, i tràfic PPP sobre IP o altres protocols de backbone.
  • IEEE 802.1Q tunneling (Q-in-Q) permet als proveedors de servei transportar tagged Ethernet (802.1Q) entre xarxes dels clients a través d’un backbone compartit. Per tal de fer això l’únic que es fa és tornar a afegir una altre etiqueta, a la afegida pel 802.1Q de la xarxa del client, aquesta vegada l’etiqueta 802.1Q és de la xarxa del proveedor.
  • MPLS LSPs (Label Switch Routers) els paquets es conmuten segons l’etiqueta afegida al paquet. LSPs poden rebre senyals de TDP, el LDP, o el RSVP.

Tecnologies i protocols usats en accessos remots

  • The Layer Two Forwarding (L2F) Protocol és propietari de Cisco. Bàsicament es va dissenyar per fer túnels PPP (o SLIP) per enllaços entre NAS i VPN gateways en oficines centrals. Els usuaris remots connecten al NAS, i les trames PPP de l’usuari remot són enviades pel túnel cap al VPN gateway.
  • The Point-to-Point Tunneling Protocol (PPTP) el van desenvolupar Microsoft, 3com i Ascend Communications. Com el L2F, el PPTP permet crear túnels per accessos remots a través de trames PPP entre un NAS i un VPN gateway. PPTP també permet crear túnels entre l’usari remot i el VPN gateway. PPP encapsula els paquets enviats a través dels túnels PPTP i sovint com a mètode de protecció s’usa MPPE.
  • The Layer 2 Tunneling Protocol versions 2 i 3 (L2TPv2/L2TPv3) és un estàndard de la IETF i combina les millors funcionalitats del L2F i el PPPTP. En un entorn d’accés remot, L2TP permet enviar trames PPP del client a través del NAS contra el VPN gateway o concentrador de túnels. L2TP té la seguretat com a element intrinsec, sovint s’usa IPSec per protegir-los.
  • IPSec permet establir túnels tipus site-to-site (LAN-to-LAN>), accessos remots o usuaris mòbils.
  • The Secure Sockets Layer (SSL) és un protocol de seguretat que va ser desenvolupat per Netscape Communications (SSL v1,v2 i v3). Ens permet crear enllaços remots segurs als usuaris mòbils. Funcionalment esta molt limitat, perquè no ens cal un client d’VPN. Cal no oblidar que TLS és un estàndard IETF molt similar la SSLv3.

Per tal de disfrutar d’un conjunt de funcionalitats més potent cal instal·lar un client d’VPN SSL específic.

Modelant i Caracteritzant una VPNs

Un bon mapa perno perdres en el món de les VPNs:

VPNFigure3.gif

VPNs creades pel proveedor o pel client

Exemples d’VPNs creades pels proveedors:

  • Virtual Private Wire Service (VPWS) VPNs
  • Virtual Private LAN Service (VPLS) VPNs
  • IP-Only Private LAN Service (IPLS) VPNs
  • BGP/MPLS (RFC4364/2547bis) VPNs (BGP/MPLS VPNs are also known as MPLS Layer 3 VPNs.)
  • Virtual Router (VR)-based VPNs
  • IPsec VPNs

Exemples d’VPN creades en el client:

  • GRE VPNs
  • IPsec VPNs
  • SSL VPNs

Site-to-Site i VPNs d’accés remot

Les VPNs les crei el proveidor o el client, només poden oferir dos tipus d’accés:

  • Site-to-site ofereixen connectivitat entre xarxes distants geograficament connectant-les com si es tractes d’una xarxa local. Bàsicament es ditingeixen dos tipus les intranet i les extranet segons si connecten xarxes de la mateixa organització o de diferents organitzacions, respectivament.
VPNFigure4.gif
  • Accés remot també anomenades VPNs d’accés permeten a un usuari mòbil o domèstic accedir a la xarxa de l’organització i accedir als seus recursos de xarxa com si estiguessis físicament a la xarxa.
VPNFigure5.gif

Gentoo trick: eina quickpkg

Reading time: < 1 minute

Dins del paquet gentoolkit podem trobar una eina que fins fa una estoneta no coneixia i que per culpa d’això m’havia fet perdre molt de temps, l’eina és realment interessant s’anomena quickpkg i ens permet crear un paquet binari a partir d’un paquet ja existent en el sistema. Realment útil quan volem tenir la còpia de seguretat de la versió d’un paquet que ja funciona en la nostre màquina i volem provar una nova versió sense haver de perdre altre vegada tot el temps fins que es torna a fer la compilació del paquet. Així doncs amb aquest eina podem estalviar realment moltes hores perdudes, almenys en el meu cas les havia perdut fins ara tontament.

Els paquets que es crein amb quickpkg obviament quedaran a:

${PKGDIR}/All
${PKGDIR}/

Grabar video-tutorials

Reading time: 3 – 5 minutes

Malgrat hi ha un molt bon programa amb una GUI basada en GTK per linux per capturar sessions i grabar veu a les sessions. El wink. O sigui, amb el que podem construir video-tutorials on expliquem com fer qualsevol cosa. Amb Gentoo no sé perquè no em funcionava a més la versió 1.5 que és la última disponible per linux no suporta grabació de veu. Així que m’he decantat per probar el vnc2swf que junt amb el pyvnc2swf (no inclòs al portage de linux) permet grabar sessions d’VNC i grabar fitxers d’audio al mateix temps. Esta prou bé l’script amb Python automatitza molt les coses. Obviament es tracta d’una aplicació basada en CLI i per tant, no té interficie gràfica i jo diria que no permet editar els arxius un cop grabats. No sé si el flash (.swf) es pot editar un cop grabat l’audio i el video. Però em sembla que és l’única manera d’editar un video-tutorial un cop grabat.

Perquè ens fem una idea del que fa l’script de Python és llençar el vnc2swf i al mateix temps podem invocar el arecord (graba .wav via ALSA). Així doncs quan a través de la mini-interfice gràfica que té el pyvnc2swf premem el botó d’stop es graba un fitxer .wav i un .swf amb el nostre video i l’audio per separat. Llavors el que fem amb el lame és convertir el .wav a .mp3 i després unim l’.mp3 amb el .swf de forma que quedin un sol arxiu .swf, el propi script ens ha creat també una pàgina .html des d’on es crida l’objecte de flash.

Com que hi ha força arxius i paràmetres a usar a continuació adjunto un petit cookbook que explica com fer-ho:

# Llencem el servidor d'Xvnc
vncserver -geometry 800x600 :10
# Modifiquem el fitxer ~/.vnc/xstartup perquè es llenci el KDE amb l'escriptori del servidor Xvnc
cat xstartup
#!/bin/sh
startkde &
# Llencem el pyvnc2swf amb la seva mini-GUI per llençar i parar les grabacions
vnc2swf.py -o out.swf -r 5 -S "arecord -r 22050 voice.wav" localhost:10
# Finalment llencem el client d'vnc per controlar la sessió que volem grabar
vncviewer -depth 8 -compresslevel 9 -quality 9 :10

Els paràmetres que li passem al vnc2swf.py són per indicar el fitxer de sortida (-o), després li diem que grabi 5 fotogrames cada segon (-r 5) després llencem en swap el arecord prenent mostres a 22KHz i grabant la seva sortida a voice.wav. Finalment li diem que la sessió a la que s’ha de connectar en mode de només lectura és a localhost:10, o sigui, el port 5910.

Un cop parem la sessió es generarà un fitxer out.html des d’on es cridarà l’objecte de flash out.swf aquest arxiu no té incrustat el so grabat a voice.wav per adjuntar-lo hem de fer:

# Convertim a .mp3 el fitxer amb l'audio voice.wav
lame voice.wav
# Adjunt l'audio del fitxer voice.wav.mp3 al fitxer out.swf i la sortida ens quedarà a out2.swf
edit.py -o out2.swf -a voice.wav.mp3 out.swf

A l’executar l’edit.py també es crearà el fitxer out2.html que crida l’objecte de flash out2.swf amb l’audio inclòs. Perquè us feu una idea de la sortida us adjunto aquest screenshot:

pyvnc2swf.png
Scroll to Top