[address-policy-wg] IPv6 allocations for 6RD

That's really funny, you explicitly mention "waste of address space"
in your draft, trying to bash on the 6RD draft. You propagate waste of
router memory and all the other funny stuff caused by large routing
tables, which is really much better than handing out more bits to the
LIRs.

Cheers,
Florian

Am 1. Dezember 2009 14:36 schrieb Lutz Donnerhacke <lutz at iks-jena.de>:
> * Jim Reid wrote:
>> As for the mechanics of /24s for 6RD, I'm still confused and
>> uncertain. It's not clear why so much space is needed and if such
>> allocations are wasteful or not. They don't look like an efficient use
>> of address space.
>
> 6to4 is a transition technology based on anycast routing.
>
> Because several 6to4 anycast routers are badly managed, some people patched
> some implementations of the protocol to use PA-space instead of anycast. By
> switching the address space, the badly behaving routers out there needs not
> to be fixed, because anycast is not longer in use.
>
> The 6to4 mapping algorithm simply embed the whole IPv4 space into the
> 6to4-addresses. That's a clever trick and IPv6 encourages such tricks.
>
> By moving the address space, a lot of bits are determined by the existing
> IPv4 PA space of the ISP. A clever mapping is provided and possible with
> 6rd, but this configuration requires some clue to be done right. If the ISP
> has several disjunct PA spaces, configruation and provisioning can become
> complex.
>
> The question to the APWG is now: Do we want to hand out much more IPv6 space
> then necessary in order to allow the ISP to:
>  - postphone the IPv6 deployment in the backbone (use 6rd instead)
>  - do not fix the misbehaving routers out there (use unicast instead)
>  - simplify the provisioning system (use a single, trival mapping instead)
>
> If the APWG does consider rapid rollout higher than address space, the
> policy should be changed. If the APWG does not consider changing addresses
> for saving money, the policy should remain as it is.
>
> My personal impression is, that all those problems does not exist. In order
> to overcome the anycast problems quickly, I submitted an IETF draft which
> allows unicast routing below an anycast fallback. This technology was tested
> years ago and worked well.
>
> For the other points, I personally feel bad by handing out addresses to
> those ISP which does not spend the necessary money in their infrastructure
> and managment systems.
>
>