Re: [address-policy-wg] 2006-01 Discussion Period extended until 19 June 2007 (Provider Independent (PI) IPv6 Assignments for End User Organisations)

[Leo Vegoda <leo.vegoda@localhost]

Hi Jordi,

On 31 May 2007, at 11:12am, JORDI PALET MARTINEZ wrote:

[...]

> > > > It would be helpful to people considering requesting a PI IPv6  
> > > > prefix
> > > > and the RIPE NCC if the policy gave a clear statement of what is
> > > > required.
> > > Not sure if that's so easy, and I'm not really sure is really
> > > needed. Do you
> > > have any idea ? We could also apply that "idea", may be, to the
> > > standard
> > > IPv6 allocation policy.
> > >
> > > It will be good to understand if the staff is having problems
> > > there, or it
> > > is just enough the way they are doing and it may be applied then
> > > here the
> > > same.
> > One of the three principles guiding the policy process is that "it is
> > transparent. All discussions and results are documented and freely
> > available to all."[1] If the criteria for a decision are too
> > difficult to define in the policy text then there's something wrong
> > somewhere.
> I think in some situations, the staff needs to have some  
> flexibility. Is not
> a matter of wrong policy, is a matter of avoiding a complex one  
> with too
> many cases, because every ISP may be one, and we have already  
> guidelines
> such as RFC3177 and utilization, which the staff, I guess, uses to
> understand if the right prefix is a /32 or a /30 or whatever. May  
> be having
> a reference to that is enough ?
I agree that flexibility is good and a complex policy will not work  
for all cases. Nonetheless, without a statement of what the policy is  
both the registry staff and the potential requesters are in the dark  
and that's not really fair to either of them.
The policy needs to define some basis for determining the length of a  
PI prefix so that everyone knows what the policy actually is. The  
first attempt might not be the right answer but that's not a problem  
as we know that the IPv6 policy is an interim policy and it will be  
reviewed in the future when we have more experience in the  
administration of IPv6.
> > > > Also, the proposed text does not define a maximum size for an  
> > > > IPv6 PI
> > > > assignment. When this is combined with a lack of definition for the
> > > > qualification requirements it seems that a /32 of IPv6 PI could be
> > > > assigned. Is that intended?
> > > Not at all, it is not intended to assign a /32. However, if the
> > > case justify
> > > it, we aren't closing the door. I really think it is difficult to
> > > find a
> > > case that could justify that, in fact probably is very difficult to
> > > justify
> > > cases that justify something shorter than /44, but you never know
> > > how big
> > > can be a data center or content provider, for example.
> > I think it's difficult to define a case justifying it, too. But that
> > doesn't mean that unreasonable requests won't be made. And if you
> > don't have a clearly defined set of criteria you make things
> > needlessly difficult for both the requesters and the registry.
> Same as above, if the utilization based on RFC3177 recommendations  
> is a good
> parameter, then the criteria can be defined in a simple way that  
> accommodate
> all the cases while hostmasters have a good point to check.
I think we need something a little better defined than the text in  
RFC 3177. It says:
    -  Very large subscribers could receive a /47 or slightly shorter
       prefix, or multiple /48's.

Unfortunately, "very large" isn't quantifiable and changes according  
to your perspective.
I'm not sure what the appropriate utilisation requirements should be.  
I do know that this proposal isn't intended for ISPs that need  
address space as they can get at least a /32 allocation. Maybe we  
should be asking for input from people that have already deployed  
IPv6 on large enterprise networks, at university campuses and so on  
to describe their experiences and help us work out a quantifiable  
utilisation requirement for receiving more than a /48.
Regards,

--
Leo Vegoda
IANA Numbers Liaison