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/address-policy-wg@ripe.net/
[address-policy-wg] Re: Status of 2011-02 Policy Proposal (Removal of multihomed requirement for IPv6)?
- Previous message (by thread): [address-policy-wg] Re: Status of 2011-02 Policy Proposal (Removal of multihomed requirement for IPv6)?
- Next message (by thread): [address-policy-wg] Status of 2011-02 Policy Proposal (Removal of multihomed requirement for IPv6)?
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Wilfried Woeber, UniVie/ACOnet
Woeber at CC.UniVie.ac.at
Mon Aug 8 14:27:05 CEST 2011
Hi Håvard, Community, please allow me follow up on this contribution, and some other comments, by stating that 1) from a purely "traditional" technical point of view, I don't totally like it, but 2) I consciously *do* support the proposal. Actually for various reasons. Please see below... Havard Eidnes wrote: > Hi, > > I'm not sure I agree with the proposed policy. > [...] > > So by removing the requirement for multi-homing to get IPv6 PI > space yet one more part of the dike to stem the flood into the > DFZ is whittled away. Yes, probably. But this "flood" is running into the DFZ since the days well before significant take-up of IPv6. And nobody felt motivated to do anything against it. Has anyone been reading the weekly routing table statistics for all these years, and maybe noticed that there is a ("technically cheap") considerable potential to *shrink* the DFZ? ;-) So, yes, from a purely technical aspect, I agree, from a reality-check point of view I consider the aspect as moot. > Who is willing to predict whether IPv6 PI > after this policy is passed is going to be the modern-day > equivalent of the old "swamp" in the 192.0.0.0/8 space, where > route aggregation is impossible and ownership of address blocks > is scattered far and wide. Maybe, even a good chance for that. But, again, looking back the few decades to classful addressing and the TWD - those "inefficient" approaches made it easy to get IPv4 rolled out and broke the ground for the success of today's Internet. So, I am willing to take the chance here with IPv6 and closely track the result. As someone else has correctly pointed out already, the RIPE Community can change policy at any time. > Underlying, and unstated seems to be an assumption that "everyone > has a birthgiven right to a non-changing IPv6 address when one > changes provider". Is that really a given? No, I guess not. But - on the other hand, my feeling is that the recipients of resources do have some "right" to a consistent set of policies and to a stable environment. *Not* removing the MH requirement for IPv6 PI, but soon having accepted the minimum IPv4 PI assignment size as /24 for *routing reasons* strikes me as - well - royally broken (ref. 2006-05). The policy imbalance IPv4 / IPv6 has already been mentioned. As an aside, those IPv6 PI assignments are going to be made from (a) specific block(s), so the "no routing guarantee" can kick in at any time, at the sole discretion of an individual ISP. > Best regards, > > - Håvard And, last but not least, the current situation does not consider the following two scenarios/aspects: - seeing the NCC motivated to check the MH-ness, from their vantage point(s), while there is no mechanism available to do that "correctly" or decisively[1], and - there is no provision in the existing policy that (explicitely) describes the consequences of (maybe temporarily?) loosing the MH-ness. Hth, with no hats on other than being a "silver surfer" who eventually decided to accept the fact that the Internet, in this millennium, is no longer an exlusively technology-driven environment. I consider this :-) and :-( , but that's OT... Wilfried. [1] the way I am reading the policy, there is no requirement to have all paths, and announcement origins, of a particualr prefix visible in the DFZ or "everywhere" on the 'net. Thus the NCC seeing MH from their vantage point(s) *is* a useful reading, but *not* seeing that from their poisition *doesn't tell them anything*. Which IMHO invalidates the whole concept of requiring MH-ness by expecting the NCC to verify that.
- Previous message (by thread): [address-policy-wg] Re: Status of 2011-02 Policy Proposal (Removal of multihomed requirement for IPv6)?
- Next message (by thread): [address-policy-wg] Status of 2011-02 Policy Proposal (Removal of multihomed requirement for IPv6)?
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]