[LACNIC/Politicas] [LAC-TF] Privacidad de WHOIS
JORDI PALET MARTINEZ
jordi.palet at consulintel.es
Thu Jul 21 17:57:17 BRT 2005
Creo que no seria valido.
El hecho de vincular aunque solo sea el nombre del beneficiario (al menos si
es persona fisica), con el bloque delegado, ya viola la ley de proteccion de
datos/datos personales.
Sigo insistiendo que es mas facil:
1) Publicar el bloque y el ISP al que esta delegado
2) El ISP DEBE de tener una base de datos con la informacion adicional, pero
solo visible por medio de autorizacion judicial
3) Si un determinado usuario desea explicitamente que su informacion se
publique y asi lo firma en el contrato, el ISP DEBE de publicar la
informacion
4) Si se produce un ataque desde un determinado bloque, el ISP recibira una
queja (no necesariamente judicial) y SIN desvelar la informacion, actuara en
consecuencia contra el usuario (cortandole el servicio, o dandole un aviso
primero o lo que sea), en funcion de la Politica de Uso que el usuario ha
aceptado en el contrato.
No se si asi es mas facil ;-)
Saludos,
Jordi
> De: Ramos <ramos at enet.cu>
> Responder a: "lactf at lac.ipv6tf.org" <lactf at lac.ipv6tf.org>
> Fecha: Thu, 21 Jul 2005 15:44:33 -0400
> Para: Enrique Torres <eta at millicomperu.com.pe>
> CC: "lactf at lac.ipv6tf.org" <lactf at lac.ipv6tf.org>, <politicas at lacnic.net>
> Asunto: Re: [LAC-TF] (no subject)
>
> Enrique y German
>
> Creo que así cumpliríamos con Lacnic y la privacidad de la cual hablamos. No
> se que piensa Jordi al respecto
>
> Saludos Daniel Ramos
> ----- Original Message -----
> From: "Enrique Torres" <eta at millicomperu.com.pe>
> To: "Ramos" <ramos at enet.cu>
> Cc: <politicas at lacnic.net>
> Sent: Thursday, July 21, 2005 2:56 PM
> Subject: Re:
>
>
>> Si Daniel, seria solo declarar el nombre del beneficiario de la sub
>> delegacion
>> manteniendose en reserva todos los datos de contacto relativos a ese
>> beneficiario y llenandose los mismos con los datos del ISP propietario del
>> bloque.
>>
>> Si hacemos esto podemos saber quien se beneficia con la sub delegacion del
>> bloque y para casos de incidentes que es cuando se deberia usar los datos
>> de
>> contacto es el ISP quien actua como un intermediario entre el que Reporta
>> el
>> Incidente y el Beneficiario final.
>>
>> German corrigeme si me equivoco pero creo que la informacion relativa a
>> los
>> contactos de a quien sub delegan los bloques los ISP no tiene mayor
>> relevancia para LACNIC o la utilizan para algun proceso especifico ? Solo
>> se
>> me ocurre que quiza la podrian utilizar para procesos de validacion de la
>> utilizacion de los bloques asignados al ISP cuando este solicita uno nuevo
>> ?
>>
>> Por otro lado viendolo friamente quiza solo tenga valor para LACNIC la
>> informacion relativa a:
>>
>> - el bloque asignado y su tamaño
>> - el pais desde el cual se hace la sub delegacion
>> - el Beneficiario directo por parte de LACNIC del bloque
>> - status de la sub delegacion
>>
>> Enrique
>>
>>
>>
>>
>>
>>
>>
>>> Enrique:
>>>
>>> Saludos.
>>> Por la experiencia de ustedes tu propuesta seria poner solo publico el
>>> nombre de la entidad a la cual se delego el bloque y todo el resto de la
>>> información seria referido al ISP..
>>>
>>> ejemplo:
>>> Copyright LACNIC lacnic.net
>>> % The data below is provided for information purposes
>>> % and to assist persons in obtaining information about or
>>> % related to AS and IP numbers registrations
>>> % By submitting a whois query, you agree to use this data
>>> % only for lawful purposes.
>>> % 2005-07-21 14:34:02 (BRT -03:00)
>>>
>>> inetnum: 200.55.129.0/25
>>> status: reallocated
>>> owner: Servicios Empresariales
>>> ownerid: CU-SEEM-LACNIC
>>> responsible: ISP
>>> address: Direccion del ISP.
>>> address: 10600 - Ciudad de la Habana -
>>> country: CU
>>> phone: +53 7 Phone del ISP []
>>> owner-c: DAR
>>> tech-c: DAR
>>> created: 20040420
>>> changed: 20040420
>>> inetnum-up: 200.55.128/19
>>>
>>> nic-hdl: DAR
>>> person: Daniel Ramos
>>> e-mail: infocom at ENET.CU
>>> address: Ave Independencia y 19 de Mayo, 0,
>>> address: 10600 - La Habana -
>>> country: CU
>>> phone: +53 7 337337 []
>>> created: 20021011
>>> changed: 20021209
>>>
>>> % whois.lacnic.net accepts only direct match queries.
>>> % Types of queries are: POCs, ownerid, CIDR blocks, IP
>>> % and AS numbers.
>>>
>>> Sustituyendo los datos del cliente por el del ISP.
>>>
>>> Seria bueno ver otras criterios....
>>>
>>> Daniel Ramos
>>>
>>>
>>>
>>> ----- Original Message -----
>>> From: "Enrique Torres" <eta at millicomperu.com.pe>
>>> To: <politicas at lacnic.net>
>>> Sent: Thursday, July 21, 2005 12:26 PM
>>> Subject: Re: [LACNIC/Politicas] [LAC-TF] Fwd:I-D
>>> ACTION:draft-narten-ipv6-3177bis-48boundary-00.txt
>>>
>>>> El Jue 21 Jul 2005 10:29, Enrique Torres Angeles escribió:
>>>>> Hola Todos
>>>>>
>>>>> Les cuento un poco la experiencia que tuvimos aqui en Peru al respecto
>>>>> de la confidencialidad de los datos cuando hace unos años comenzamos a
>>>>> implementar el WHOIS y zonas WHOIS delegadas para alimentar los
>>>>> registros de ARIN.
>>>>>
>>>>> Con respecto a la declaracion de los datos completos en el WHOIS la
>>>>> problematica que se dio fue la siguiente:
>>>>>
>>>>> 1- Utilizacion de la base de datos whois por otros operadores de
>>>>> telecomunicaciones para atacar la base de clientes internet de la
>>>>> competencia
>>>>>
>>>>> 2- Utilizacion de las bases de datos whois para crear bases de datos
>>>>> de
>>>>> publicidad o telemercadeo
>>>>>
>>>>> 3- Utilizacion en contadas oportunidades para fraudes basandose en la
>>>>> informacion de la base WHOIS.
>>>>>
>>>>>
>>>>> Contra esta problematica se opto en dos alternativas y creo que son
>>>>> las
>>>>> que se deben analizar
>>>>>
>>>>> 1- Declarar el bloque IP con el nombre de la Organizacion que lo tenia
>>>>> delegado pero en la seccion de contactos administrativos y tecnicos
>>>>> que
>>>>> son los datos visibles se publico la informacion del contacto tecnico
>>>>> y
>>>>> administrativo del ISP que delega el numero.
>>>>>
>>>>> Internamente existian datos que no eran mostrados donde estaba la data
>>>>> real del usuario.
>>>>>
>>>>> 2- Tuvimos solo un caso en donde el cliente no quiso que apareciera
>>>>> ninguna informacion sobre el y se declaro como si el bloque estuviera
>>>>> utilizado por el ISP y con sus contactos administrativos y tecnicos.
>>>>>
>>>>> Cabe mencionar que en este caso fue el que mas complicacion nos creo
>>>>> porque nos llevo a analizar la opcion de añadir un campo que indique
>>>>> el
>>>>> Representante y el Beneficiario del bloque a fin de que solo se
>>>>> publique
>>>>> en el WHOIS los datos del Representante.
>>>>>
>>>>>
>>>>> En conclusion lo que les quiero decir es que este no es un problema
>>>>> complicado de solucionar es un problema mas que todo del tipo
>>>>> administrativo que implica adicionar datos al WHOIS algunos de los
>>>>> cuales no son publicados y definir una opcion al momento de que
>>>>> registra
>>>>> el usuario los datos en que le permite decidir si quiere mantener los
>>>>> datos confidenciales o no.
>>>>>
>>>>> Es claro que ante los RIR esta opcion no era aplicable era solo
>>>>> aplicable para declarar la sub delegaciones hechas por el ISP.
>>>>>
>>>>>
>>>>> Saludos,
>>>>> Enrique
>>>>>
>>>>>> !
>>>>>> Pues como diria un abogado amigo mio: "desconozco mayormente"!
>>>>>>
>>>>>> No que sepa.
>>>>>>
>>>>>> Erick
>>>>>>
>>>>>> At 09:09 a.m. 20/07/2005, rgaglian at adinet.com.uy wrote:
>>>>>>> Erik,
>>>>>>>
>>>>>>> Sabes si LacTLD esta trabajando en este tema tambien?
>>>>>>>
>>>>>>> Roque
>>>>>>>
>>>>>>>> -- Mensaje original --
>>>>>>>> Date: Wed, 20 Jul 2005 01:13:40 -0500
>>>>>>>> To:
>>>>>>>> german at lacnic.net,<lactf at lac.ipv6tf.org>,<rgaglian at adinet.com.uy>
>>>>>>>> From: Erick Iriarte Ahon <faia at amauta.rcp.net.pe>
>>>>>>>> Subject: Re: [LACNIC/Politicas] [LAC-TF]
>>>>>>>> Fwd:I-D ACTION:draft-narten-ipv6-3177bis-48boundary-00.txt
>>>>>>>> Cc: politicas at lacnic.net
>>>>>>>>
>>>>>>>>
>>>>>>>> Hola German.
>>>>>>>>
>>>>>>>>> Creo que Roque ha hecho una observacion muy interesante.
>>>>>>>>> Efectivamente,
>>>>>>>>
>>>>>>>> las
>>>>>>>>
>>>>>>>>> reasignaciones de un /48 deberan registrarse en el WHOIS asi sea
>>>>>>>>> a
>>>>>>>>> usuarios residenciales por lo que la politica de privacidad que
>>>>>>>>> se planteo dias
>>>>>>>
>>>>>>> atras
>>>>>>>
>>>>>>>>> vuelve a resultar interesante analizar.
>>>>>>>>
>>>>>>>> Concuerdo con lo que indicas, el punto claro es establecer el
>>>>>>>> dato
>>>>>>>> del whois hasta que nivel lo queremos llevar?.
>>>>>>>>
>>>>>>>>> La decision de implementar o no esquemas de privacidad de datos
>>>>>>>>> en
>>>>>>>>> la base de datos WHOIS de LACNIC es un tema que recae
>>>>>>>>> directamente en los miembrosde la lista de politicas y
>>>>>>>>> asistentes
>>>>>>>>> al foro publico. Si bien
>>>>>>>>>
>>>>>>>>> tiene aristas
>>>>>>>>> legales la decision de si LACNIC debe implementar una politica
>>>>>>>>> similar
>>>>>>>
>>>>>>> es
>>>>>>>
>>>>>>>> de
>>>>>>>>
>>>>>>>>> ustedes.
>>>>>>>>
>>>>>>>> En general, las aristas legales (y en todos los casos existen las
>>>>>>>> mismas),
>>>>>>>>
>>>>>>>> no deben ser entendidas como "bloqueos" sino como "encaminadores"
>>>>>>>> dentro de
>>>>>>>> procesos sociales en los cuales vivimos.
>>>>>>>>
>>>>>>>>> En otras regiones tal como lo menciona Marcelo el tema de
>>>>>>>>> privacidad de datos fue resuelto dejando a decision del ISP
>>>>>>>>> cuales
>>>>>>>>> asignaciones de sus clientes serian publicos a traves del WHOIS
>>>>>>>>> pero en definitiva todas las reasignaciones se registran la
>>>>>>>>> diferencia es
>>>>>>>
>>>>>>> determinar
>>>>>>>
>>>>>>>>> si son publicas o no.
>>>>>>>>
>>>>>>>> Pero tengamos en cuenta, que en otras regiones (como es el caso
>>>>>>>> europeo
>>>>>>>
>>>>>>> en
>>>>>>>
>>>>>>>> particular), esta claramente definido normativas sobre datos
>>>>>>>> personales/privacidad, mientras que en nuestra region asi de
>>>>>>>> explicito
>>>>>>>>
>>>>>>>> solo Argentina.
>>>>>>>>
>>>>>>>>> La cuestion es determinar si hay una necesidad de un cambio asi
>>>>>>>>> y
>>>>>>>>> si hay quienes lo apoyen
>>>>>>>>
>>>>>>>> SIn embargo creo que sera una interesante experiencia el poder
>>>>>>>> trabajar
>>>>>>>
>>>>>>> en
>>>>>>>
>>>>>>>> politicas de privacidad en relacion al whois.
>>>>>>>>
>>>>>>>> Erick
>>>>>>>>
>>>>>>>>> Saludos
>>>>>>>>>
>>>>>>>>> German Valdez
>>>>>>>>> LACNIC
>>>>>>>>> Potosi 1517
>>>>>>>>> Montevideo Uruguay 11500
>>>>>>>>> http://www.lacnic.net
>>>>>>>>> Participe en el desarrolo de politicas publicas en LACNIC
>>>>>>>>> Suscribase en http://lacnic.net/sp/lists.html
>>>>>>>>>
>>>>>>>>>> -----Mensaje original-----
>>>>>>>>>> De: lactf-bounces at lac.ipv6tf.org
>>>>>>>>>> [mailto:lactf-bounces at lac.ipv6tf.org] En nombre de marcelo
>>>>>>>>>> bagnulo braun
>>>>>>>>>> Enviado el: Martes, 19 de Julio de 2005 06:00 a.m.
>>>>>>>>>> Para: rgaglian at adinet.com.uy
>>>>>>>>>> CC: lactf at lac.ipv6tf.org; politicas at lacnic.net
>>>>>>>>>> Asunto: Re: [LAC-TF] [LACNIC/Politicas] Fwd:I-D
>>>>>>>>>> ACTION:draft-narten-ipv6-3177bis-48boundary-00.txt
>>>>>>>>>>
>>>>>>>>>> Hola Roque,
>>>>>>>>>>
>>>>>>>>>> no he seguido muy de cerca este ultimo tema que mencionas,
>>>>>>>>>> pero creo recordar que en otras regiones solucionaron esto
>>>>>>>>>> dejando a discrecion del ISP si poner o no en el WHOIS los
>>>>>>>>>> datos de los clientes finales, por lo que no me queda claro
>>>>>>>>>> que esto sea un problema grave, pero como dije no estoy muy
>>>>>>>>>> puesto en esto, asi que si me podes corregir...?
>>>>>>>>>>
>>>>>>>>>> saludos, marcelo
>>>>>>>>>>
>>>>>>>>>> El 19/07/2005, a las 2:10, rgaglian at adinet.com.uy escribió:
>>>>>>>>>>> Creo que un punto que no podemos perder desde el punto de
>>>>>>>>>>
>>>>>>>>>> vista de los
>>>>>>>>>>
>>>>>>>>>>> operadores es que si se mantiene el /48 como unidad de
>>>>>>>>>>
>>>>>>>>>> asignación, se
>>>>>>>>>>
>>>>>>>>>>> deberá registrar a cada usuario residencial (ADSL, etc) en
>>>>>>>>>>
>>>>>>>>>> la base de
>>>>>>>>>>
>>>>>>>>>>> datos Whois, con el correspondiente costo administrativo y
>>>>>>>>>>> con un agravamiento de los problemas de confidencialidad ya
>>>>>>>>>>> planteados en esta lista.
>>>>>>>>>>>
>>>>>>>>>>> Roque
>>>>>>>>>>>
>>>>>>>>>>>> -- Mensaje original --
>>>>>>>>>>>> Cc: lactf at lac.ipv6tf.org, politicas at lacnic.net
>>>>>>>>>>>> From: marcelo bagnulo braun <marcelo at it.uc3m.es>
>>>>>>>>>>>> Subject: Re: [LACNIC/Politicas] Fwd:
>>>>>>>>>>>> I-D
>>>>>>>>>>>> ACTION:draft-narten-ipv6-3177bis-48boundary-00.txt Date:
>>>>>>>>>>>> Sun, 17 Jul 2005 12:52:02 +0200
>>>>>>>>>>>> To: rgaglian at adinet.com.uy
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Hola Roque,
>>>>>>>>>>>>
>>>>>>>>>>>> si, a mi me parece un disparate tambien
>>>>>>>>>>>>
>>>>>>>>>>>> tener en cuenta que la eficiencia requerida resultante del
>>>>>>>>>>
>>>>>>>>>> uso del HD
>>>>>>>>>>
>>>>>>>>>>>> ratio para un /19 es de 1,8%!!!!
>>>>>>>>>>>>
>>>>>>>>>>>> ademas, en
>>>>>>>>>>
>>>>>>>>>> draft-narten-iana-rir-ipv6-considerations-00.txt se lantea
>>>>>>>>>>
>>>>>>>>>>>> un ejemplo que me parece ilustrar muy bien tu
>>>>>>>>>>>> preocupacion,
>>>>>>>>>>>> lo transcribo para uds.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> 4.1. An example: Cable Modem/DSL Service in US
>>>>>>>>>>>>
>>>>>>>>>>>> In the hallway at a recent ARIN meeting, I was cornered
>>>>>>>>>>
>>>>>>>>>> by someone
>>>>>>>>>>
>>>>>>>>>>>> who had done a back-of-the envelope calculation that
>>>>>>>>>>>> led
>>>>>>>>>>>> him to believe the current policies needed adjustment. The
>>>>>>>>>>
>>>>>>>>>> argument went
>>>>>>>>>>
>>>>>>>>>>>> like:
>>>>>>>>>>>>
>>>>>>>>>>>> If I assign 4M /48Ç«÷s of IPv6 (one to each cable
>>>>>>>>>>>> modem on
>>>>>>>
>>>>>>> my
>>>>>>>
>>>>>>>>>>>> network), according to the HD-ratio I am justified
>>>>>>>>>>>> to
>>>>>>>>>>>> obtain something around a /20 of IPv6 addresses. In other
>>>>>>>>>>
>>>>>>>>>> words, I am
>>>>>>>>>>
>>>>>>>>>>>> justified in getting 268M /48Ç«÷s even though I am
>>>>>>>>>>
>>>>>>>>>> only using
>>>>>>>>>>
>>>>>>>>>>>> 4M
>>>>>>>>>>>>
>>>>>>>>>>>> of
>>>>>>>>>>>> them. That would be enough for me to assign at
>>>>>>>>>>>> least
>>>>>>>>>>>> two for every household in the US (not just the 19M on my
>>>>>>>>>>>> network).
>>>>>>>>>>>>
>>>>>>>>>>>> Now if all the cable providers (e.g., Comcast, Cox,
>>>>>>>>>>>> Adelphia, Cablevision, Time-Warner, etc.) did the same for
>>>>>>>>>>
>>>>>>>>>> their networks;
>>>>>>>>>>
>>>>>>>>>>>> and each of the DSL companies made a similar move
>>>>>>>>>>
>>>>>>>>>> (SBC, Verizon,
>>>>>>>>>>
>>>>>>>>>>>> Quest, etc.); perhaps we could easily see the
>>>>>>>>>>
>>>>>>>>>> broadband market
>>>>>>>>>>
>>>>>>>>>>>> in
>>>>>>>>>>>> the US alone obtaining some 16 /20Ç«÷s of IPv6 or a
>>>>>>>>>>>> total of /16.
>>>>>>>>>>>> There are only 8192 of those available in the
>>>>>>>>>>>> current
>>>>>>>>>>>> global unicast space of 2001::/3.
>>>>>>>>>>>>
>>>>>>>>>>>> Anyhow, you can see where this might lead...
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Saludos, marcelo
>>>>>>>>>>>>
>>>>>>>>>>>> PD: este tema se esta discutiendo en la lista global-v6
>>>>>>>>>>>> global-v6 mailing list
>>>>>>>>>>>> global-v6 at lists.apnic.net
>>>>>>>>>>>> http://mailman.apnic.net/mailman/listinfo/global-v6
>>>>>>>>>>>> seria bueno que enviaramos nuestros comentarios ahi, de
>>>>>>>>>>
>>>>>>>>>> forma que las
>>>>>>>>>>
>>>>>>>>>>>> opiniones del lacnic tambien se tomen en cuenta
>>>>>>>>>>>>
>>>>>>>>>>>> El 17/07/2005, a las 6:56, rgaglian at adinet.com.uy
>>>>>>>>>>>> escribió:
>>>>>>>>>>>> Marcelo,
>>>>>>>>>>>>
>>>>>>>>>>>> Hace tiempo que queria contestarte este correo con un
>>>>>>>>>>
>>>>>>>>>> comentario que
>>>>>>>>>>
>>>>>>>>>>>> he escuchado más de una vez.
>>>>>>>>>>>>
>>>>>>>>>>>> ¿¿¿Cómo hizo D-Telecom para justificar un /19???
>>>>>>>>>>>>
>>>>>>>>>>>> No he estudiado mucho las políticas actuales de RIPE pero
>>>>>>>>>>
>>>>>>>>>> claramente
>>>>>>>>>>
>>>>>>>>>>>> se desprende del resto de los RIR por estos bloques
>>>>>>>>>>>> gigantes de direcciones asignados a algunos proveedores.
>>>>>>>>>>>>
>>>>>>>>>>>> Un /19 se podría dividir en 539 millones de /48. Es mi
>>>>>>>>>>
>>>>>>>>>> impresión que
>>>>>>>>>>
>>>>>>>>>>>> el plan de numeración que utilizaron (y amparados en el
>>>>>>>>>>
>>>>>>>>>> RFC vigente)
>>>>>>>>>>
>>>>>>>>>>>> da un
>>>>>>>>>>>> /48
>>>>>>>>>>>>
>>>>>>>>>>>> a
>>>>>>>>>>>> cada usuario DSL y A CADA CELULAR.
>>>>>>>>>>>>
>>>>>>>>>>>> Lo que es interesante es que el draft, a primera vista,
>>>>>>>>>>
>>>>>>>>>> no estudia
>>>>>>>>>>
>>>>>>>>>>>> la
>>>>>>>>>>>>
>>>>>>>>>>>> asignación
>>>>>>>>>>>> de direcciones para empresas celulares/moviles.
>>>>>>>>>>>>
>>>>>>>>>>>> Un abrazo
>>>>>>>>>>>>
>>>>>>>>>>>> Roque
>>>>>>>>>>>>
>>>>>>>>>>>> -- Mensaje original --
>>>>>>>>>>>> To: lactf at lac.ipv6tf.org, politicas at lacnic.net
>>>>>>>>>>>> From: marcelo bagnulo braun <marcelo at it.uc3m.es>
>>>>>>>>>>>> Date: Wed, 13 Jul 2005 11:39:33 +0200
>>>>>>>>>>>> Subject: [LACNIC/Politicas] Fwd: I-D
>>>>>>>>>>>> ACTION:draft-narten-ipv6-3177bis-48boundary-00.txt
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> fyi
>>>>>>>>>>>>
>>>>>>>>>>>> Inicio mensaje reenviado:
>>>>>>>>>>>> De: Internet-Drafts at ietf.org
>>>>>>>>>>>> Fecha: 12 de julio de 2005 21:50:03 GMT+02:00
>>>>>>>>>>>> Para: i-d-announce at ietf.org
>>>>>>>>>>>> Asunto: I-D
>>>>>>>>>>>> ACTION:draft-narten-ipv6-3177bis-48boundary-00.txt
>>>>>>>>>>>> Responder a: internet-drafts at ietf.org
>>>>>>>>>>>>
>>>>>>>>>>>> A New Internet-Draft is available from the on-line
>>>>>>>>>>
>>>>>>>>>> Internet-Drafts
>>>>>>>>>>
>>>>>>>>>>>> directories.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Title : IPv6 Address Allocation to
>>>>>>>>>>>> End
>>>>>>>>>>>> Sites Author(s) : T. Narten, et al.
>>>>>>>>>>>> Filename :
>>>>>>>>>>
>>>>>>>>>> draft-narten-ipv6-3177bis-48boundary-00.txt
>>>>>>>>>>
>>>>>>>>>>>> Pages : 8
>>>>>>>>>>>> Date : 2005-7-12
>>>>>>>>>>>>
>>>>>>>>>>>> This document revisits the IAB/IESG recommendations
>>>>>>>>>>>> on
>>>>>>>>>>>> the assignment
>>>>>>>>>>>> of IPv6 address space to end sites. Specifically, it
>>>>>>>>>>
>>>>>>>>>> indicates
>>>>>>>>>>
>>>>>>>>>>>> that
>>>>>>>>>>>> changing the default end-site assignment for typical
>>>>>>>>>>
>>>>>>>>>> home and
>>>>>>>>>>
>>>>>>>>>>>> SOHO
>>>>>>>>>>>> sites from /48 to /56 is consistent with the goals
>>>>>>>>>>
>>>>>>>>>> of IPv6 and
>>>>>>>>>>
>>>>>>>>>>>> RFC
>>>>>>>>>>>> 3177. Although it is for the RIR community to make
>>>>>>>>>>
>>>>>>>>>> adjustments
>>>>>>>>>>
>>>>>>>>>>>> to
>>>>>>>>>>>>
>>>>>>>>>>>> the
>>>>>>>>>>>> IPv6 address space allocation and end site
>>>>>>>>>>
>>>>>>>>>> assignment policies,
>>>>>>>>>>
>>>>>>>>>>>> the
>>>>>>>>>>>> IETF community would be comfortable with RIRs
>>>>>>>>>>>> changing
>>>>>>>>>>>> the default
>>>>>>>>>>>> assignment size to /56 for smaller end sites. This
>>>>>>>>>>>> document obsoletes
>>>>>>>>>>>> RFC 3177 and reclassifies it as historic.
>>>>>>>>>>>>
>>>>>>>>>>>> A URL for this Internet-Draft is:
>>>>>>>>>>>> http://www.ietf.org/internet-drafts/draft-narten-ipv6-317
>>>>>>>>>>>> 7bi s -48boundary-00.txt
>>>>>>>>>>>>
>>>>>>>>>>>> To remove yourself from the I-D Announcement list, send
>>>>>>>>>>
>>>>>>>>>> a message
>>>>>>>>>>
>>>>>>>>>>>> to i-d-announce-request at ietf.org with the word
>>>>>>>>>>
>>>>>>>>>> unsubscribe in the
>>>>>>>>>>
>>>>>>>>>>>> body
>>>>>>>>>>>>
>>>>>>>>>>>> of
>>>>>>>>>>>>
>>>>>>>>>>>> the message.
>>>>>>>>>>>> You can also visit
>>>>>>>>>>>> https://www1.ietf.org/mailman/listinfo/I-D-announce
>>>>>>>>>>>> to change your subscription settings.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Internet-Drafts are also available by anonymous FTP.
>>>>>>>>>>>> Login with the username "anonymous" and a password of
>>>>>>>>>>>> your e-mail address. After logging in, type "cd
>>>>>>>>>>>> internet-drafts" and then "get
>>>>>>>>>>>> draft-narten-ipv6-3177bis-48boundary-00.txt".
>>>>>>>>>>>>
>>>>>>>>>>>> A list of Internet-Drafts directories can be found in
>>>>>>>>>>>> http://www.ietf.org/shadow.html or
>>>>>>>>>>>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Internet-Drafts can also be obtained by e-mail.
>>>>>>>>>>>>
>>>>>>>>>>>> Send a message to:
>>>>>>>>>>>> mailserv at ietf.org.
>>>>>>>>>>>> In the body type:
>>>>>>>>>>>> "FILE
>>>>>>>>>>>> /internet-drafts/draft-narten-ipv6-3177bis-48boundary-00.
>>>>>>>>>>>> txt ".
>>>>>>>>>>>>
>>>>>>>>>>>> NOTE: The mail server at ietf.org can return the
>>>>>>>>>>>> document in MIME-encoded form by using the "mpack"
>>>>>>>>>>>> utility.
>>>>>>>>>>
>>>>>>>>>> To use this
>>>>>>>>>>
>>>>>>>>>>>> feature, insert the command "ENCODING mime"
>>>>>>>>>>
>>>>>>>>>> before the "FILE"
>>>>>>>>>>
>>>>>>>>>>>> command. To decode the response(s), you will
>>>>>>>>>>
>>>>>>>>>> need "munpack" or
>>>>>>>>>>
>>>>>>>>>>>> a MIME-compliant mail reader. Different
>>>>>>>>>>
>>>>>>>>>> MIME-compliant mail
>>>>>>>>>>
>>>>>>>>>>>> readers
>>>>>>>>>>>> exhibit different behavior, especially when
>>>>>>>>>>>> dealing with "multipart" MIME messages (i.e. documents
>>>>>>>>>>>> which
>>>>>>>>>>
>>>>>>>>>> have been split
>>>>>>>>>>
>>>>>>>>>>>> up into multiple messages), so check your local
>>>>>>>>>>
>>>>>>>>>> documentation on
>>>>>>>>>>
>>>>>>>>>>>> how to manipulate these messages.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Below is the data which will enable a MIME compliant
>>>>>>>>>>
>>>>>>>>>> mail reader
>>>>>>>>>>
>>>>>>>>>>>> implementation to automatically retrieve the ASCII
>>>>>>>>>>
>>>>>>>>>> version of the
>>>>>>>>>>
>>>>>>>>>>>> Internet-Draft.
>>>>>>>>>>>> Content-Type: text/plain
>>>>>>>>>>>> Content-ID: <2005-7-12130012.I-D at ietf.org>
>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> I-D-Announce mailing list
>>>>>>>>>>>> I-D-Announce at ietf.org
>>>>>>>>>>>> https://www1.ietf.org/mailman/listinfo/i-d-announce
>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> Politicas mailing list
>>>>>>>>>>>> Politicas at lacnic.net
>>>>>>>>>>>> http://www.lacnic.net/mailman/listinfo/politicas
>>>>>>>>>>>>
>>>>>>>>>>>> Ing.Roque Gagliano
>>>>>>>>>>>> rgaglian at adinet.com.uy
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> Politicas mailing list
>>>>>>>>>>>> Politicas at lacnic.net
>>>>>>>>>>>> http://www.lacnic.net/mailman/listinfo/politicas
>>>>>>>>>>>
>>>>>>>>>>> Ing.Roque Gagliano
>>>>>>>>>>> rgaglian at adinet.com.uy
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> Politicas mailing list
>>>>>>>>>>> Politicas at lacnic.net
>>>>>>>>>>> http://www.lacnic.net/mailman/listinfo/politicas
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> LACTF mailing list
>>>>>>>>>> LACTF at lac.ipv6tf.org
>>>>>>>>>> http://lacnic.net/mailman/listinfo/lactf
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Politicas mailing list
>>>>>>>>> Politicas at lacnic.net
>>>>>>>>> http://www.lacnic.net/mailman/listinfo/politicas
>>>>>>>
>>>>>>> Ing.Roque Gagliano
>>>>>>> rgaglian at adinet.com.uy
>>>>>>
>>>>>> _______________________________________________
>>>>>> Politicas mailing list
>>>>>> Politicas at lacnic.net
>>>>>> http://www.lacnic.net/mailman/listinfo/politicas
>>>>
>>>> _______________________________________________
>>>> Politicas mailing list
>>>> Politicas at lacnic.net
>>>> http://www.lacnic.net/mailman/listinfo/politicas
>>>>
>>>>
>>>>
>>>> --
>>>> No virus found in this incoming message.
>>>> Checked by AVG Anti-Virus.
>>>> Version: 7.0.323 / Virus Database: 267.9.2/53 - Release Date: 7/20/2005
>>
>>
>>
>> --
>> No virus found in this incoming message.
>> Checked by AVG Anti-Virus.
>> Version: 7.0.323 / Virus Database: 267.9.2/53 - Release Date: 7/20/2005
>>
>
> _______________________________________________
> LACTF mailing list
> LACTF at lac.ipv6tf.org
> http://lacnic.net/mailman/listinfo/lactf
************************************
The IPv6 Portal: http://www.ipv6tf.org
Barcelona 2005 Global IPv6 Summit
Information available at:
http://www.ipv6-es.com
This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
More information about the Politicas
mailing list