[sig-ipv6] BOUNCE sig-ipv6@lists.apnic.net: Non-member submission from [dancer@zeor.simegen.com]

[owner-sig-ipv6@lists.apnic.net]

>From owner-sig-ipv6  Tue Jul 11 08:31:50 2000
Received: from keon.simegen.com ([203.2.135.4])
	by whois.apnic.net (8.9.3/8.9.3) with ESMTP id IAA98963
	for <sig-ipv6@apnic.net>; Tue, 11 Jul 2000 08:31:49 +1000 (EST)
From: dancer@zeor.simegen.com
Received: from anaconda.simegen.com [203.28.9.32] 
	by keon.simegen.com with esmtp (Exim 3.12 #1 (Debian))
	id 13Bm4F-0003at-00; Tue, 11 Jul 2000 08:30:24 +1000
Received: from localhost ([127.0.0.1] helo=zeor.simegen.com)
	by anaconda.simegen.com with esmtp (Exim 3.12 #1 (Debian))
	id 13Bm4A-0000Ml-00; Tue, 11 Jul 2000 08:30:18 +1000
Sender: dancer
Message-ID: <396A4E79.AB70AB07@zeor.simegen.com>
Date: Tue, 11 Jul 2000 08:30:18 +1000
X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.4.0-test1-ac21 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: Joao Luis Silva Damas <joao@ripe.net>
CC: Brian E Carpenter <brian@hursley.ibm.com>,
        Stephen Burley <stephenb@uk.uu.net>, Kazu@venus.Sun.COM,
        Yamamoto@venus.Sun.COM, ipng@sunroof.eng.sun.com,
        ngtrans@sunroof.eng.sun.com, arano@byd.ocn.ad.jp, sig-ipv6@apnic.net,
        mir@ripe.net, ipv6-wg@ripe.net, richardj@arin.net
Subject: Re: (ngtrans) Fw: [apnic-announce] IPv6 Policy Document Revision
References: <20000706.172714.91311805.kazu@Mew.org>
	 <39646A02.CACB8F8C@uk.uu.net> <3964DE58.7DB92581@hursley.ibm.com>
	 <3965A5F0.8505E7BA@uk.uu.net> <3965F75D.E9B4FF6A@hursley.ibm.com> <a04320404b58f5377cf45@[193.0.1.195]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Joao Luis Silva Damas wrote:

> Brian,
>
> At 10:29 -0500 7/7/00, Brian E Carpenter wrote:
> ...snip...
> >  > A /64 for dialup
> >>  is also too rigid because the way technology is going a /64 is not
> >>going to be
> >>  enough subnets for what wiill be a dial up connection with a large
> >>lan behind it.
> >
> >Indeed. But that isn't an issue the RIRs need to think about.
>
> It is not the RIRs trying to force variable length prefixes. At the
> RIPE meeting in Budapest and the ARIN meeting in Calgary we reported
> what the outcome of conversations with IETF people was (the /48, /56,
> /64 options for allocation).
> This seemed to be a reasonable way of doing it for the IPv6/ngtrans
> IETF people and to the RIR people present in Adelaide.
>
> At both the ARIN and RIPE meetings, ISPs (the people who will use the
> address space, after all) were the ones that suggested variable
> length prefixes for allocation and the RIRs must go by the community
> consensus (BTW, at the RIPE meeting no consensus was reached, with
> both the variable length and the 3 fixed lengths having supporters).
>
> A second issue is to think about a way of getting the IETF IPv6
> people and the 3 RIR communities to talk to each other at the same,
> otherwise we are entering a loop, with at least 4 separate
> discussions and each dependant on the other 3.

The only practical reason I can see for variable-length prefixes is for
the ISP to charge more money for allocation of any prefix shorter than a
/64. Guaranteed, the average ISP (no, I won't tar you all with the same
brush) if permitted to allocate a /64 won't allocate anything shorter
unless lubricated with many times the amount of cash.

Perhaps it sounds cynical, but that's based on my experiences with ISPs.
Under IPv4, I can see how a scarce resource falls under the supply/demand
paradigm. Let's not falsely inflate the value  of a /48 to the end-user
by making longer prefixes available. Those longer prefixes will simply
become the norm, which was not our intent, was it?

D


*              sig-ipv6:  APNIC SIG on IPv6 technology and policy issues           *
* To unsubscribe: send "unsubscribe" to sig-ipv6-request@apnic.net *