Re: [address-policy-wg] [sig-policy]Address Policy SIG Proposal
- Date: Tue, 22 Jul 2003 12:59:48 +0200
Dear colleagues,
Having analysed the proposal that is under discussion within APNIC:
>It is proposed that:
>* The IANA allocate IPv6 space to RIRs (including new RIRs) in prefix
> units no less than /8.
>* The RIRs may practice 'sparse allocations' within the allocated blocks
and that the practice of reserving a /29 is discontinued.
we fully support it and we are in favor to include it in the IPv6 Address
Policy for the RIPE region.
Kind regards,
Azucena
Para: Address Policy WG
address-policy-wg@localhost
cc:
Asunto: [address-policy-wg] [sig-policy]Address
Policy SIG Proposal
Clasificación: Uso Interno
FYI
Forwarded message from Anne Lord anne@localhost:
----- Mensaje de Anne Lord anne@localhost en Tue, 22 Jul 2003 11:54:37
+1000 (EST) -----
Para: sig-policy@localhost,
sig-policy-chair@localhost
cc: sig@localhost
Asunto: [sig-policy]Address Policy SIG Proposal
Dear Arano San, Yong Wan, Kenny and SIG-Policy subscribers,
A proposal(P) is submitted below for the forthcoming Address Policy SIG
in Korea on August 21st. It is a follow up to RIPE-261.
Your comments and feedback are appreciated and most welcome.
Best wishes,
Anne
----------------------------------------------------------------------
See you at APNIC 16
Seoul, Korea, 19-22 August 2003 http://www.apnic.net/meetings
---------------------------------------------------------------------
A follow up to RIPE-261: Requesting larger IPv6 allocations from IANA
and practicing 'sparse allocations'
Proposed by: APNIC Secretariat
Version: 1.0
Date: 22 July 2003
1. Summary
The document 'IPv6 Address Space Management' (ripe-2611) proposes a model
for managing global unicast IPv6 address space through a system of 'sparse
allocations' from a global pool. This is different from the current
regional
approach, which is based on existing IPv4 practices where each RIR receives
a separate block of IPv6 address space to manage. The objective of the
proposal was to maximise aggregation and to avoid the creation of an 'IPv6
swamp' of discontiguous address ranges.
The proposal has recently been presented at RIR policy meetings(2) and has
been circulated on respective RIR policy discussion mailing lists. Feedback
received from the community has suggested general support for the aims of
the proposal (to maximize aggregation), but has differed on the actual
implementation details. There has been some regional consensus(3) in
favour of the RIRs receiving larger initial allocations of IPv6 address
space from the IANA (Internet Assigned Number Authority), within which
'sparse allocations' can be practiced.
2. Background and Problem
The early system of IP address management for IPv4 created what is referred
to as the 'swamp' - a series of fragmented address ranges that cannot be
combined to form a single CIDR prefix. The existing system of IPv6 Address
Space management risks re-creating 'swamp' address space.
The RIRs receive IPv6 allocations in fixed /23 blocks from IANA. Under the
current policy framework, the RIRs make /32 allocations (minimum) with
reservations up to a /29 prefix. Allocations are made sequentially,
thus no organisation can expect to receive a contiguous allocation once
the /29 reservation has been utilised. In the longer term, the effect
of this practice will cause fragmentation of the address ranges, similar
to the 'swamp' space described above for IPv4.
The system of address space management proposed in 'IPv6 Address Space
Management' (ripe-261) specifically addresses this problem by maximising
the aggregatable prefixes received by any one ISP through a system of
allocations from a central pool of address space.
Internet community feedback reached no consensus on ripe-261. Objections
raised noted that the proposal, if implemented, would no longer allow
filtering on RIR allocations.
There is general support for trying to avoid the creation of an IPv6
'swamp' space. One approach, which preserves regional integrity but
which is conscious of the above, is for the IANA to allocate the RIRs
larger allocations.
3. Proposal
It is proposed that:
* The IANA allocate IPv6 space to RIRs (including new RIRs) in prefix
units no less than /8.
* The RIRs may practice 'sparse allocations' within the allocated blocks
and that the practice of reserving a /29 is discontinued.
4. Implementation
A common consensus across the four RIR regions would be required before
any change is made to the existing management framework. If this is
reached,
it is proposed that the usual three month period allowed for implementation
in the APNIC region is waived.
5. References
(1) 'IPv6 Address Space Management' (ripe-261), Paul Wilson, Axel Pawlik,
Raymond Plzak. http://www.ripe.net/ripe/docs/ipv6-sparse.html
(2) URLs of meeting discussions
* APNIC http://www.apnic.net/meetings/15/sigs/policy
* ARIN http://www.arin.net/library/minutes/ARIN_XI/ppm.html
* RIPE NCC http://www2.ripe.net/ripe/wg/lir/r45-minutes.html
(3)RIPE 45, Barcelona, Spain
http://www2.ripe.net/ripe/wg/lir/r45-minutes.html
* sig-policy: APNIC SIG on resource management policy
*
_______________________________________________
sig-policy mailing list
sig-policy@localhost
http://mailman.apnic.net/mailman/listinfo/sig-policy
--
leo vegoda
RIPE NCC
Registration Services Manager
___________________________________________________________________________
Este mensaje se dirige exclusivamente a su destinatario y puede contener
información privilegiada o confidencial. Si no es vd. el destinatario
indicado, queda notificado de que la utilización, divulgación y/o copia sin
autorización está prohibida en virtud de la legislación vigente. Si ha
recibido este mensaje por error, le rogamos que nos lo comunique
inmediatamente por esta misma vía y proceda a su destrucción.
This message is intended exclusively for its addressee and may contain
information that is CONFIDENTIAL and protected by professional privilege.
If you are not the intended recipient you are hereby notified that any
dissemination, copy or disclosure of this communication is strictly
prohibited by law. If this message has been received in error, please
immediately notify us via e-mail and delete it.
___________________________________________________________________________
|