<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    Hi,<br>
    Im cutting a little bit this or it will be longer as the bible is.<br>
    <div class="moz-cite-prefix"><br>
    </div>
    <blockquote cite="mid:20140703085403.GK43103@Space.Net" type="cite">
      And this is different for you as compared to a big Cable ISP
      exactly why?
      Everybody who is growing his IPv4 network is facing the same
      challenges,
      as there are no more IPv4 addresses to sustain the demand.
      So yes, if these are the requirements, you will need to do logging
      of NAT
      pool mappings, and depending on the amount of customers you have,
      some pretty expensive storage to hold the data... (things like A+P
      / MAP help
      here, because you're not randomly masquerading customer IPs, but
      it will
      be done by block). Be assured, for a telco with a million
      customers, this
      will not be easier or cheaper than for an ISP with 10.000
    </blockquote>
    <br>
    I dont know the legal things of other countrys, I dont even know
    everything for our country.<br>
    Logging the NAT pool map could not be the solution. Again, the court
    dont sais what was doing, just say an IP and a Date, and for
    example, if court sais: Hey, tell me who was using this IP in this
    date/hour. The IP was scamming on Facebook. The logs will show like
    75% of customers sharing the same IP were using facebook in that
    moment. <br>
    There is also another legal problem. I'll try to inform but I think
    at this moment here is illegal to sniff and <u>save</u> our
    customers connections. If i dont remember bad, you can sniff but
    only in realtime, just to see what is happening at the moment on
    your network.<br>
    <br>
    <blockquote cite="mid:20140703085403.GK43103@Space.Net" type="cite">
      <blockquote type="cite">
        <pre wrap="">At this moment, Im sure there are LIRs with a /22 who only need a /24 
and LIRs with a /22 who need more. If the proposal to remove the minimum 
allocation of /22 goes well, maybe something can be done about this.
- New LIRs recieving a first allocation of /23 or /24? (And you can say; 
This will f**k the routing table. But /24 announces already happens)
- New LIRs can ask for more allocations but in stacks of /24 up to a 
total of /21?
</pre>
      </blockquote>
      <pre wrap="">
Yes, this will f**k the routing table.  If we go there, and next thing you
find that ISPs are unwilling to accept these /24s, because their routers'
TCAM is full, who are you going to complain to?</pre>
    </blockquote>
    But there is actually /24's announces everywhere, Do you think it
    will mess up the table more than it is now?<br>
    <blockquote cite="mid:20140703085403.GK43103@Space.Net" type="cite">
      <pre wrap="">

[..]
</pre>
      <blockquote type="cite">
        <pre wrap="">Maybe and for the future, we should start talking about what should IANA 
do about legacy allocations not in use. Maybe forcing them to return 
space if they dont use/dont want it anymore instead of giving the chance 
to sell it. Dont know, Im really new to the world of RIRs/LIRs so Im 
sure you will know more about this than me. This could have been 
discussed before, dont know.
</pre>
      </blockquote>
      <pre wrap="">
The only way to *solve* this is to go to IPv6.  Everything else is just
investing into a dead technology, and drawing out the pains.</pre>
    </blockquote>
    I'm totally with you. Totally dude. Im an IPv6 fanboy. But that
    doesnt mean to dont try to have a solution for today. (<-- I dont
    know if I said it well)<br>
    One of the requirements I said for having more allocation than /22
    from RIPE was exactly that. Not only having an IPv6 allocation, not
    only having that allocation (or a chunk) announced. I said to have
    it in really production. From core network to customer cpe when
    supported, Dual-Stacking them.<br>
    As you said, investing in IPv4 is investing into a dead technology.
    We dont want to spend lots of money and work in a dead technology.
    We spend money on new hardware that supports IPv6 and time doing it
    work.<br>
    <br>
    Best Regards,<br>
    <pre class="moz-signature" cols="72">-- 
Daniel Baeza
Centro de Observación de Red
Dpto. Internet y Telefonía
Television Costa Blanca S.L.
Telf. 966190565
WEB: <a class="moz-txt-link-freetext" href="http://www.tvt.es">http://www.tvt.es</a>
Correo: <a class="moz-txt-link-abbreviated" href="mailto:datos@tvt-datos.es">datos@tvt-datos.es</a>

--AVISO LEGAL--
 
En cumplimiento de la Ley Orgánica 15/1999, de 13 de diciembre de protección de datos de carácter personal, se pone en conocimiento del destinatario del presente correo electrónico, que los datos incluidos en este mensaje, están dirigidos exclusivamente al citado destinatario cuyo nombre aparece en el encabezamiento, por lo que si usted no es la persona interesada rogamos nos comunique el error de envío y se abstenga de realizar copias del mensaje o de los datos contenidos en el mismo o remitirlo o entregarlo a otra persona, procediendo a borrarlo de inmediato. 
Asimismo le informamos que sus datos de correo han quedado incluidos en nuestra base de datos a fin de dirigirle, por este medio, comunicaciones comerciales, profesionales e informativas y que usted dispone de los derechos de acceso, rectificación, cancelación y especificación de los mismos, derechos que podrá hacer efectivos dirigiéndose a Televisión Costa Blanca, S.L., C/ San Policarpo 41 Bajo. C.P: 03181 Torrevieja (Alicante).</pre>
  </body>
</html>