This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
[address-policy-wg] 2005-08 New Policy Proposal
- Previous message (by thread): [address-policy-wg] 2005-08 New Policy Proposal
- Next message (by thread): [address-policy-wg] 2005-08 New Policy Proposal
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Geoff Huston
gih at apnic.net
Wed Oct 5 14:42:07 CEST 2005
Yes, I can see your point, and agree with it. regards, Geoff At 08:12 PM 5/10/2005, Wilfried Woeber, UniVie/ACOnet wrote: >RIPE NCC Policy Coordinator wrote: > > > PDP Number: 2005-08 > > Proposal to Amend the IPv6 Assignment and Utilisation Requirement Policy > >Proposing a bit of word-smithing: > >" Rationale: >[ ... ] >As a consequence of that, LIRs will need far more address space, depleting >the available >pool of addresses at an accelerated rate and reducing the lifetime of the >IPv6 protocol." > >Proposed replacement text: >As a consequence of that, LIRs and ISPs will distribute (to End Sites) >IPv6 addresses in >blocks much greater than presumably necessary for an average end site - >thus depleting the >pool of unallocated or unassigned IPv6 addresses at an accelerated speed. > >Why? >I have a particular problem with the assertion that the "lifetime" of the >protocol is >reduced! The protocol itself will remain valid anyway, we would just have >to modify the >procedures for distributing the addresses. > >And the inclusion of "unallocated or unassigned" IPv6 addresses: because >formally the pool >of available addresses is of fixed size. > > >Thanks for consideration! >Wilfried.
- Previous message (by thread): [address-policy-wg] 2005-08 New Policy Proposal
- Next message (by thread): [address-policy-wg] 2005-08 New Policy Proposal
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]