On 28 nov 2009, at 15:57, Remco van Mook wrote:
Hi Remi,
could you help me in understanding why an ISP with, say, a /14 and 2 /16s of address space would need a /28 of space to do 6rd? In my understanding, even using a /56 per customer would give you a requirement for just 19 bits of ipv6 space (18 bits for the /14, 1 extra to also make the /16s fit) on top of the /56s, if you just use 3 instances of 6rd and prefix compression. This gives a requirement of a /37 for deploying 6rd, not a /28. Even if you add a whole bunch of /15s and /24s to the mix, it will only add a few bits to the requirement, not 11.
Not that I don't want to give out the space if needed, but I'm trying to understand the reasoning behind it. I find 'too complicated' a tough argument to swallow given that the current and working IPv4 setup in an environment like this is already way more complicated.
My I propose to add the following to section 3.5 of RIPE-481 (or similair wording) analogues to 6.5 of the v4 policy: Current text: 3.5. Conservation Although IPv6 provides an extremely large pool of address space, address policies should avoid unnecessarily wasteful practices. Requests for address space should be supported by appropriate documentation and stockpiling of unused addresses should be avoided. Proposed new text: 3.5. Conservation and Administrative Ease Although IPv6 provides an extremely large pool of address space, historical evidence shows that what now seems infinit might one day turn out to become a scarce resource, Address policies should avoid unnecessarily wasteful practices of such resources. Requests for address space should be supported by appropriate documentation and stockpiling of unused addresses should be avoided. Assignment of address space based on the sole argument of administrative ease is not permitted. Examples of this include, but are not limited to, ease of billing administration and network management. Rationale: Classfull addressing in IPv4 proofs a nice example, but one can also look at 16 bit ASN or the global supply of oil for proof that resources that once seemed infinite can become scarce. Especially in 'greenfield' deployments such as 6rd, which is still in the process of being standardized, and IPv6 in general, circumstances which may be considered 'wastefull' can be easily avoided. Arguments supporting the proposal: We slowly become aware what the costs of deploying a new technique or protocol are, one of the prime arguments global addoption of 32 bit ASN and IPv6 is slow is cost. We should try and prevent future cost by doing the same exercise twice by all means. We keep telling our selves and the rest of the world IPv6 is not different, "96 bits no difference", it seems logical to keep the policies as much the same as possible. One might argue that with standardizing an ethernet subnet to 64 bits all was lost anyway, this is not the case and mistakes from the past should be used as an example to prevent further damage instead of a validation to make the same mistake twice. Arguments against this proposal: By addopting this change now we again create a difference between the early adopters and people who follow, this is similair to the assignment of /8 address blocks in the early days of IPv4. By prohibiting assignment for administrative ease we will slow IPv6 adoption even more MarcoH