Re: what problem is solved by proscribing non-64 bit prefixes?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: what problem is solved by proscribing non-64 bit prefixes?
- To: "Dunn, Jeffrey H." <jdunn at mitre.org>
- Subject: Re: what problem is solved by proscribing non-64 bit prefixes?
- From: Brian E Carpenter <brian.e.carpenter at gmail.com>
- Date: Thu, 02 Oct 2008 09:42:57 +1300
- Cc: Alexandru Petrescu <alexandru.petrescu at gmail.com>, ipv6 at ietf.org, Steve_Eiserman at ao.uscourts.gov, ralph.liguori at disa.mil, Pasi.Eronen at nokia.com, "Sherman, Kurt T." <ksherman at mitre.org>, draft-ietf-v6ops-addcon at tools.ietf.org, rbonica at juniper.net, night at nist.gov, dougm at nist.gov, v6ops-chairs at tools.ietf.org, "Martin, Cynthia E." <cemartin at mitre.org>
- Delivered-to: ietfarch-ipv6-archive at core3.amsl.com
- Delivered-to: ipv6 at core3.amsl.com
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=6sydtqKE6npk/HCBPiZgkgc2vH0kK2d1P2ktbCb68LE=; b=BDkU5/86qQyVL9xU+JGCsVBgidxfsJnCIoA2NtbnsWPN0FqZbB9OTHgj5YqV6EKSQg bOBK5BWlugUXcE5haQQFCTz7ZsVA+netp9dCtTIdrCiLTb+itx+hl0qqJKJlOAM0oGEZ AAnka/kTJPEb9RzISbiC89lTROrMfhwAEVK4w=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=MNA7Im0wBtX2uFY6VGGDVlLYFxJQtcm3AmW6odrwJO9YEs8mwobzOTH7vd2vnICcjs QdgscvURWykWyEbQlQBjMFyVwGSkuYDJPyyfqxWwMnzUys3A2jt2xCfuQgY9Ee3W4O7v TnBCjIX82r5oGCo3aXUah9M0B14Pssi/Brs7M=
- In-reply-to: <0AC4B700F00DBB4C94F95727E0991414014B24F5 at IMCSRV7.MITRE.ORG>
- List-archive: <https://www.ietf.org/mailman/private/ipv6>
- List-help: <mailto:ipv6-request@ietf.org?subject=help>
- List-id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
- List-post: <mailto:ipv6@ietf.org>
- List-subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
- List-unsubscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
- Organization: University of Auckland
- References: <C0F2465B4F386241A58321C884AC7ECC085AB2AF at E03MVZ2-UKDY.domain1.systemhost.net> <48E37330.3060801 at gmail.com> <0AC4B700F00DBB4C94F95727E0991414014B24F5 at IMCSRV7.MITRE.ORG>
- Sender: ipv6-bounces at ietf.org
- User-agent: Thunderbird 2.0.0.6 (Windows/20070728)
On 2008-10-02 02:04, Dunn, Jeffrey H. wrote:
> More to the point, what would a individual household do with Avogadro's
> number worth of IPv6 addresses (2^80 = 1.2x10^24)? This seems
> extremely wasteful. Further, a reasonable sized ISP with a couple of
> million customers would require a /28 or more just for their
> residential customer base. This sounds like a prescription for address
> exhaustion.
Not in the least. Please remember that we have raised the size of the
address space to the *fourth* power; we squared it and squared it again.
Even if we'd stuck to the original plan of assigning /48s everywhere,
that means we've *squared* the size of the subnet prefix space (/24 to /48).
Unless really stupid allocation mechanisms are allowed, that is enough
for any imaginable future. And all the evidence is that the RIRs are
being extremely conservative in their practices for allocation. So
I don't see even a remote cause for concern.
On the other hand I see enormous value in allowing any size of network
on any customer's premises. It's not for this generation of engineers
and ISPs to constrain what our great-grandchildren might invent.
Brian
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 at ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.