Below, in-line.
De: "Wilfried Woeber, UniVie/ACOnet" <Woeber@CC.UniVie.ac.at> Organización: UniVie - ACOnet Responder a: <Woeber@CC.UniVie.ac.at> Fecha: Tue, 27 Feb 2007 08:45:00 +0000 Para: <jordi.palet@consulintel.es> CC: "address-policy-wg@ripe.net" <address-policy-wg@ripe.net> Asunto: Re: [address-policy-wg] Re: 2006-02 Discussion Period extended until 19 March 2007 (IPv6 Address Allocation and Assignment Policy)
JORDI PALET MARTINEZ wrote:
Hi Nick,
I believe it will be more appropriate to use in those cases ULA or ULA-central (this needs to be rescued and moved up in the IETF process, as I already voiced in ppml and in the last ARIN meeting).
However, the point here is to know if you will still support this policy proposal "as is" right now, so we can finally get this done and then new changes applied in the future, or if I need to send a new version which doesn't include the "advertisement" bit, so we can vote for both ?
For obvious reasons I cannot speak for Nick, but my take here is - get it out through the door as it is, if there's support for it. Then we can start a next round to improve. The "real" issue at the moment is to change the address distribution policy, and not the fine-tuning of routing recommendations.
Ok, thanks.
By the way, trying to answer also Wilfried's email, I think the "to whom" it is advertised may be clarified as "The LIR must advertise *to the next hops* the single address block through a single aggregated prefix.".
This is one aspect I am not so sure about: "to the next hops". There may well be very good reasons to advertise smaller portions to your next hop(s). And "we" really don't care about that, do we? The "real" issue imho is to make sure that just one prefix makes it to the core/DFZ/<your favourite term here>.
And as has been pointed out already, from the point of view of an RIR this is (should be?) more like a (strong) recommendation than a formal *address policy* aspect. If this recommendation is violated, the RIR doesn't have appropriate means to sanction anyway...
Well, I'm not sure I agree ... But I think it will be better to stop this part of the thread here if we want to move ahead now :-)
Wilfried.
Regards, Jordi
De: Nick Hilliard <nick@inex.ie> Responder a: <address-policy-wg-admin@ripe.net> Fecha: Mon, 26 Feb 2007 12:14:07 +0000 Para: <Woeber@CC.UniVie.ac.at> CC: "address-policy-wg@ripe.net" <address-policy-wg@ripe.net> Asunto: Re: [address-policy-wg] Re: 2006-02 Discussion Period extended until 19 March 2007 (IPv6 Address Allocation and Assignment Policy)
Just as an editorial comment: We should also remove the "requirement" to advertise the prefix. This is another (useless) artificial barrier to the deployment of IPv6 as a generally avalable technology for building networks.
I'd like to second Wilfred on this point. Just because RIPE has allocated address space, this does not mean that the address space will be visible on the Internet at any particular stage. RIPE NCC provides a general address space registry function, not just a public internet address registry function.
While there is an argument for using PI for private assignments, right now we can't do this in ipv6, because there is no ipv6 PI space yet. But more importantly, there are situations where it may be appropriate for a private entity to register large amounts of v6 address space, where PI would be less appropriate due to sub-assignment issues.
Nick Hilliard -- Network Ability Ltd. | Head of Operations | Tel: +353 1 6169698 3 Westland Square | INEX - Internet Neutral | Fax: +353 1 6041981 Dublin 2, Ireland | Exchange Association | Email: nick@inex.ie
********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.