[address-policy-wg] Discrepancy Between RIPE Policies on IPv4 and IPv6 Provider Independent (PI) Address Space

Hi,

On Tue, May 04, 2010 at 05:34:50PM +0200, Richard Hartmann wrote:
> On Tue, May 4, 2010 at 17:22, Gert Doering <gert at space.net> wrote:
> > "if people can use PI to give single IPv6 addresses to their end
> > customers, we might see DSL deployments with single address + NAT,
> > and this not something I want to see"...)
> 
> What provisions are in place that would stop anyone from doing the
> same with PA space? What stops anyone from implementing them for both
> IPv6 PA & PI?

There is no real incentive to do so, as you can get a huuuuuge block of
addresses fairly easily.

The incentive to do this with PI is "save on the costs" - and then, since
the PI policy doesn't permit you to give address blocks from the PI space 
to your access customers, the consequence would be "if you can only give 
a single IPv6 address to the customers, that's all the customer is going 
to get" (and the blame will be pointed to the RIPE NCC).

There be dragons - consider well what your message to the "large-scale
access providers" is supposed to be, and what the implications might be.

(There's more dragons, and babies & bathwater as well - make sure that a
policy that takes into account the large-scale access providers doesn't 
break things for web hosting shops...  and these seem to be more our 
problem right now)

Gert Doering
        -- APWG chair
-- 
Total number of prefixes smaller than registry allocations:  150584

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 306 bytes
Desc: not available
URL: </ripe/mail/archives/address-policy-wg/attachments/20100504/762949fa/attachment.sig>