[LAC-TF] Summary LAC IPv6 TF ---- October 1-31, 2009

[Mariela Rocha]

Summary of the e-mails sent to the LAC IPv6 TF mailing list ----- 
October 1-31, 2009

---------------------------------------------------------------------------------------------------- 


Subject: /48 blocks

(Complete original messages available beginning at: 
_http://mail.lacnic.net/pipermail/lactf/2009-September/002532.html_)

Ricardo Patara (LACNIC) replied to Fabián Mejía's question by sharing 
LACNIC's experience on the subject. He said that when the organization 
began routing /48 prefixes it was necessary to work with the different 
providers in order to verify that the filters would allow these 
announcements. In order to avoid problems, he recommended verifying that 
ISPs maintain their filters up to date.

Jordi Palet (ES) provided his opinion on Ricardo's comment, stating that 
because LACNIC cannot guarantee routing, nor is it the organization's 
mission to do so, the reasonable thing to do would be to report the case 
and provide the applicant with the possibility of selecting a /32. He 
stated: "I understand that for a small company requesting IPv6 addresses 
a /48 might be enough (...) but a university needs more than a /48, and 
the logical size would be a /32, which is in fact what has been used 
previously". He then continued as follows: "Many operators don't want to 
accept PI IPv6 addresses from LACNIC, but instead use more severe 
filters. This cannot be managed if each time a new /48 is assigned it is 
necessary to modify all the filters around the world".

Raul Echeberría (LACNIC) replied to Jordi supporting what was said by 
Ricardo Patara (LACNIC) and added: "At LACNIC we use a /48 for ourselves 
and a /48 in our NIC Brazil datacenter network where our equipment is 
located. Our addresses don't have routability issues". "The policy 
allows assigning between a /48 and a /32. Clearly this must be 
considered together with the resource preservation criterion". "The 
policies can obviously be modified, but this possibility should be 
discussed on the policy list". In this regard he added: "I think we must 
be careful not to generate negative feelings in relation to IPv6 
operation and policies".

Jordi Palet (ES) replied to Fabían Mejía (EC) expressing that according 
to his point of view: "it is a serious mistake to route prefixes longer 
than a /32, as this prefix (/32) is the longest that all operators will 
route by default".
He commented on RFC3177: "The IETF has attempted to modify this document 
several times but has never reached consensus. This means that there is 
consensus in that the document is valid as it is, at least in the 
opinion of more than a thousand engineers working at the IETF. I think 
this speaks volumes." "In the end, the idea behind this is to AVOID the 
need to use NAT with IPv6 to have a single IPv6 address or a group of 
IPv6 addresses, and then private addresses, etc."
He then continued as follows: "The research conducted by Tony Hain 
indicates that, if we follow RFC3177 and assign a /48 to each end-site 
(residential user, bank or company office, university or laboratory 
division), we will have IPv6 resources for the next 480 years." "If my 
memory is correct, the critical infrastructure assignment policy states 
that the assignment must be between a /48 and a /32. It is logical for a 
NAP to receive a /48 as 1) this is all it needs, and 2) it is not 
published. However, in all other cases I believe it is customary to 
assign a /32." "As author of the PI IPv6 policy, the idea was the same: 
based on the decisions made in relation to critical infrastructure, 
(...) to allow the hostmaster flexibility in case in the future 
different cases appear or the global routing policy is modified and this 
maximum length is no longer /32."
Jordi added: "I don't know whether hostmasters are assigning a /48 to 
those who request PI IPv6 by default. It was not so in the past, when 
/32s were assigned without further justification. Perhaps it is 
necessary to clarify this." "In my opinion it would be enough to justify 
a /32 with a statement such as 'some operators filter /32, I will not 
use all the /48s, but I cannot allow myself the luxury of being filtered'."

To conclude, he added: "It is my recommendation that prefixes longer 
than /32 should also be filtered, as many operators continue to do. 
Otherwise we will lose aggregation, one of the goals we have set for IPv6."


Fabían Mejía (EC) addressed Jordi and the list in general saying that: 
"The fact is that LACNIC's end user IPv6 application form says that, by 
default, LACNIC will assign /48 (...). It is also a fact that end users 
are in no position to demand that major ISPs modify their filters, which 
is why in my opinion a range should be assigned that will avoid any 
problems. The implementation of IPv6 might be hindered if it is a bumpy 
experience from the start."
He added: "It is very important to receive more feedback, and some 
specific questions come to mind: Which ISPs filter prefixes longer than 
/32? Do these ISPs have looking glasses to verify the block?"

----------------------------------------------------------------------------------------------------- 


Subject: FAQ: Section 4

(Complete original messages available beginning at: 
_http://mail.lacnic.net/pipermail/lactf/2009-October/002546.html_)

In order to continue drafting the questions for this section of the FAQ, 
Mariela Rocha (AR) summarized what had already been discussed up to the 
moment in two proposed questions for the section.

----------------------------------------------------------------------------------------------------- 


Subject: FAQ: Group 4 - Question "a"

(Complete original messages available beginning at: 
_http://mail.lacnic.net/pipermail/lactf/2009-October/002547.html_)

As no objections were received in relation to the wording of Section 4 
questions, Mariela Rocha (AR) proposed answering the first question: 
What are some examples of actions promoted/conducted/supported/funded by 
non-government organizations that have had a positive regional impact on 
IPv6 deployment?

----------------------------------------------------------------------------------------------------- 


Other contributions:

Jorge Villa (CU): 3Tera Adds IPv6 Support to AppLogic Cloud Computing 
Platform

_http://www.datastorageconnection.com/article.mvc/3Tera-Adds-IPv6-Support-To-AppLogic-Cloud-0001?atc~c=771+s=773+r=001+l=a&VNETCOOKIE=NO 
<http://www.datastorageconnection.com/article.mvc/3Tera-Adds-IPv6-Support-To-AppLogic-Cloud-0001?atc%7Ec=771+s=773+r=001+l=a&VNETCOOKIE=NO>_