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 ]