Subject: Fw: [apnic-announce] IPv6 Policy Document Revision

From: Kazu Yamamoto (山本和彦) <[email-masked]>
Date: Thu, 06 Jul 2000 17:27:14 +0900 (JST)

Folks,

It seems to me that RTRs are going a wrong way, changing /48 per site
policy. If you think so, please speak up on [email-masked] now.

--Kazu

Subject: [apnic-announce] IPv6 Policy Document Revision
From: [email-masked]
To: [email-masked]
Date: Wed, 5 Jul 2000 17:24:24 +1000 (EST)

[Note "reply-to:" field]

Summary

Both ARIN and the RIPE NCC have had discussions with the Internet
communities in their region concerning the size of address prefixes 
to be assigned to IPv6 end sites.  APNIC is now seeking input from 
the community in the Asia Pacific region on this issue. If you care 
about this, please read on. 

Some background

The existing IPv6 policy document 'Provisional IPv6 Assignment and 
Allocation Policy Document' was published in May 1999. Formal revision
of the document commenced in October 1999. The existing document
is available at:

http://www.apnic.net/drafts/ipv6/ipv6-policy-280599.html 

Feedback on the existing document was collected from the Internet community 
at large facilitated through the regional processes of consultation by 
the RIRs as well as input from the membership of the 6bone and the
IETF IPv6 working groups. The deadline for comments was 31st January 2000.

On 29th March, the RIRs, chairs of the IPv6 related IETF working
groups and 6bone particpants met in Adelaide. The purpose of the meeting
was to expand and elaborate in person on the comments made by the 
IAB/IETF/6bone concerning the existing policy document. 

One of the issues of concern that had been previously raised by
members is the size of the end-site prefix (the 'SLA ID', currently 
defined in rfc2374 as 16 bits at a /48). This includes *all* types 
of end-sites including a single device. A /48 is sufficient address 
space to create 64K of subnets. 

The technical motivation for the 16 bit SLA ID field and the 
'one size fits all' principle was described in rfc2374 as:

  "The size of the Site-Level Aggregation Identifier field is 16 bits.
   This supports 65,535 individual subnets per site.  The design goal
   for the size of this field was to be sufficient for all but the
   largest of organizations.  Organizations which need additional
   subnets can arrange with the organization they are obtaining Internet
   service from to obtain additional site identifiers and use this to
   create additional subnets.

   The Site-Level Aggregation Identifier field was given a fixed size in
   order to force the length of all prefixes identifying a particular
   site to be the same length (i.e., 48 bits).  This facilitates
   movement of sites in the topology (e.g., changing service providers
   and multi-homing to multiple service providers)."

It is possible to imagine in future a variety of types of end-sites 
being connected to the Internet.  Some of these devices will be part 
of routed networks and others will not.  The question proposed is whether 
'one size fits all' (the /48) is appropriate for all end-sites? 

Both the RIPE and ARIN communities have rejected this.  

APNIC has been asked to consult with the Internet community in the 
Asia Pacific on this issue.
 
To date, there has been no consensus on what alternatives should be 
taken, but 3 different approaches have been identified in addition to 
the 16 bit SLA ID field specified in rfc2374. 

These are:

1) /64 for single devices (such as mobile phones), /48 for all other sites

2) /64 for single devices, /48 for large end sites which need more 
   than 256 subnets, and /56 for other sites (eg small, domestic/home sites)

3) Assign what is needed for the forseeable needs of the site, as a
   variable-length prefix of between /48 and /64. (It is important to
   remember that for any site that becomes multi-homed it is necessary to 
   use equal length prefixes from each provider even in the case where 
   one provider has allocated more prefix space than the other).

We are interested in your opinions, so that we may convey this to the 
other RIRs and to the IETF community. Please direct all follow up 
discussion and comments to <[email-masked]>. For details of 
how to subscribe to this mailing list, please visit our web site at:
http://www.apnic.net/general.html#mailing-lists .

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
APNIC Secretariat
<[email-masked]>
                                                     Tel: +61-7-3367-0490
Asia Pacific Network Information Centre (APNIC) Ltd  Fax: +61-7-3367-0482
Level 1, 33 Park Road, PO Box 2131, Milton, QLD 4064, Australia
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

*            APNIC-ANNOUNCE: Announcements concerning APNIC              *
* To unsubscribe, send "unsubscribe" to [email-masked] *

---

From: Stephen Burley <[email-masked]>
Date: Thu, 06 Jul 2000 11:14:11 +0000

> policy. If you think so, please speak up on [email-masked] now.

Hi
    We discussed it at length in the RIPE 36 meeting and the majority not all
were not in favour of not fixing the boundries but rather allowing the LIR to
decide on merit/justification what amount of space to assign whithin the /48 -
/64 boundries. If we fixit to /48 /56 /64 boundries it becomes too rigid, allow

the LIR's to dictate their own assignment policy (ie flexible or fixed at 3
points /48 /56 /64) which they can justify to the RIR, in this way it pleases
everyone - i garuntee if you fix the boundries it will have to be re-addrressed

later on and will not please all.

My thoughts
Stephen Burley
UUNET EMEA Hostmaster

>
>
>   ------------------------------------------------------------------------
>
> Reply-To: [email-masked]

--
------------------------------------------------------------------------
Stephen Burley         "If patience is a virtue, and ignorance is bliss,
UUNET EMEA Hostmaster            you can have a pretty good life
[email-masked]            if you're stupid and willing to wait"
------------------------------------------------------------------------

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 06 Jul 2000 14:30:32 -0500

Stephen,

Can you explain why people think there is any need to allocate anything
longer than a /48 in the first place? 

   Brian

---

From: Randy Bush <[email-masked]>
Date: Thu, 06 Jul 2000 17:24:00 -0400

> longer than a /48 in the first place? 

i believe the document restricted it to single-device network allocations.
is a /64 too small for a single device?

randy

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 06 Jul 2000 17:29:24 -0500

Well, I'm not sure the concept of single device will mean much.
For example, assuming we do IPv6 over BlueTooth right, what the
phone company thinks is a single device may turn out to be a personal
area network. Or a single 3GPP device might turn out to be three
LANs inside a car. But fundamentally I'm not sure the RIRs need to even
think about it; that question should be well below the horizon for
an RIR policy. IMHO.

  Brian

---

From: Francis Dupont <[email-masked]>
Date: Fri, 07 Jul 2000 09:22:23 +0200

In your previous mail you wrote:

=> many ISPs want to allocate /64 (or worse) to their customers... and
shout a /48 per customer is far too large. I believe this is a consequence
of the slow^N start, ie. the /35 rule (RIRs trim address space of ISPs,
ISPs take back the burden to their customers).
 The idea is to introduce a small site (/56) for "poor & little" customers
and to make it the *default* allocation. IMHO this is an acceptable target.

Regards

[email-masked]

---

From: Randy Bush <[email-masked]>
Date: Fri, 07 Jul 2000 08:56:33 -0400

> ISPs take back the burden to their customers).

someone who gets it!  the /35 game sucks.

randy

---

From: Steve Deering <[email-masked]>
Date: Fri, 7 Jul 2000 07:51:19 -0700

At 1:57 PM +0100 7/7/00, Tim Chown wrote:
>In the case of a national educational network (my particular interest)
>we currently have just 13 bits of network space to allocate to
>institutions, if the institutions (Universities) get a /48 each.

Tim,

/48 was intended to be the *minimum* allocation to a subscriber's site, not
the *maximum*.  Those exceptional subscribers for whom a /48 is too small
are free to request larger blocks from their ISPs.

>At the same time it is bizarre that a University might get the same address 
>space as a small end customer.

It's only "bizarre" if address space is a scarce resource; the purpose and
design of IPv6 was to make it a non-scarce resource.

>The last thing we want is end users running IPv6 NAT.

I think (hope) we all agree on that, and that is one of the reasons to
oppose variable-length allocations to (all but the largest) subscribers.
IPv4 history indicates that ISPs would charge more money for shorter
prefixes, thus creating an economic incentive for many customers to buy
only the smallest amount of address space and use a NAT to expand it locally.

Steve

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 07 Jul 2000 10:29:33 -0500

Stephen Burley wrote:
> Brian E Carpenter wrote:
> Call me oldfashioned but i remember when people thought we had enough space in IPv4
> and it would never run out. If you fix the boundry at a /48 it means an ISP will go
> through their block of addresses way too fast. 

Please define "way too fast" in terms of a world population of say 15 billion
people, compared with the number of /48s available.

> It also means that out customers do
> not have to think about what they are deploying as they know they will get a /48 no
> matter what. 

Indeed. This would be a *big* advantage. Why do think it is a problem?

> So a flexible boundry between /48 and /64 would help us to help
> customers to think about how they will deploy their address space. 

But it will also set us back by ten years in route aggregation.

> 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. 

  Brian

---

From: Brad Huntting <[email-masked]>
Date: Fri, 07 Jul 2000 09:56:23 -0600

> design of IPv6 was to make it a non-scarce resource.

IMHO, the problem lies with using /64 for the default subnet size;
/80 would probably be more than enough for any conceivable "layer
2" protocol.

brad

---

From: Robert Elz <[email-masked]>
Date: Sat, 08 Jul 2000 02:15:57 +1000

Date:        Fri, 07 Jul 2000 09:56:23 -0600
    From:        Brad Huntting <[email-masked]>
    Message-ID:  <[email-masked]>

  | IMHO, the problem lies with using /64 for the default subnet size;

There is no real "problem".   No-one who has ever actually looked
at the numbers believes there is a problem with /48 allocations to
sites (though I personally have no problem considering a pool of
dial in users to be a single site if they have no need for more than
a /64 each).

The "we have to conserve those 2^48 numbers" comes from the same
kind of philosophy as the people who bought a 2 bedroom house, then
had 3 kids, and all of them had to share a bedroom.   That was a
problem, so then they bought a 500 room hotel - but still made the
kids share a room, because they ran out before, and they were
going to make certain that would never happen again.

  | /80 would probably be more than enough for any conceivable "layer
  | 2" protocol.

Except that IEEE has created 64 bit MAC identifiers for use by its
new protocols, and /80 would kill easy autoconf.   For sure, /80
(even /96) leaves way too many addresses for any conceivable subnet
to ever use them all - but making things fit in less is more work
that it is worth.

kre

---

From: Tim Chown <[email-masked]>
Date: Fri, 7 Jul 2000 17:25:08 +0100 (BST)

> are free to request larger blocks from their ISPs.

But that's where the /35 "pressure" applies because if (say) UKERNA wanted 
to offer a /40 to each University it would at present be looking at being
able to connect just 32 Universities.   By 2001 there will be over 800
University and further education colleges online under the UK JANET network.
Of course they're not all big, varying from maybe 4,000 to 40,000 people,
so most could live under a /48.  At least with the current technology that
lives around us.

I would be interested to know what the addressing requirements of a mobile 
provider would be, in terms of scale and subnetting.  What would the 
"home prefix" of 1,000,000 Vodaphone customers be, for example?  I've
not yet seen a draft IPv6 allocation policy for a mobile provider.

tim

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 07 Jul 2000 11:40:35 -0500

Tim Chown wrote:
...
> not yet seen a draft IPv6 allocation policy for a mobile provider.

Good question but it's certainly not a problem unless needlessly
restrictive allocation policies make it so. 1M is a small number in IPv6 land.

  Brian

---

From: [email-masked]
Date: Sat, 08 Jul 2000 01:45:41 +0900

>University and further education colleges online under the UK JANET network.

	While I understand the problem you have, I would like t know why
	you'd like to offer /40 to every universities.  Are there any reason
	not to do /48 for universities, or couple of /48s? 

	We (WIDE) offer /48 for leaf sites (an organization which has no
	plan to have sub-organization, i.e. universities and companies,
	not an ISP), and /40 to non-leaf downstream sites (an organization
	which has plan t have sub-organization, i.e. an ISP).
	Once a leaf site use up /48, they'd be able to get another /48 from us.
	Until now we saw no problem with it.
	"/48 allocation to everyone" is just fine for me (or us).
	We cannot predict the future growth of leaf site.
	We don't want to, we don't need to.  SOHO can evolve into
	multinational company.

	We have more important problem to tackle.  The problem lies elsewhere,
	I believe.  Once our network grows into /29, and to /16, we'd need
	to carry 2^(48-29) or 2^(48-16) routes in a TLA.  It's like having
	the whole IPv4 space in one ISP.  We need to have a very careful plan
	on inner-TLA topology, so that we can aggregate internal routes nicely.
	We may need more experiences/standards in hierarchical interior routing
	operation.

itojun

---

From: Robert Elz <[email-masked]>
Date: Sat, 08 Jul 2000 02:48:10 +1000

Date:        Fri, 7 Jul 2000 17:25:08 +0100 (BST)
    From:        Tim Chown <[email-masked]>
    Message-ID:  <[email-masked]>

  | But that's where the /35 "pressure" applies because if (say) UKERNA wanted 
  | to offer a /40 to each University

Why would i want to do that?   /48 to everyone is what should be offered.
If a site is truly *huge* (that is, is so big an IPv4 class A net isn't
enough for it) then perhaps it gets a /47 - or even a /46.   Why would
anyone routinely be allocating /40?

  | Of course they're not all big, varying from maybe 4,000 to 40,000 people,
  | so most could live under a /48.

All of those could live in a /48.

  | I would be interested to know what the addressing requirements of a mobile 
  | provider would be, in terms of scale and subnetting.

If one assumes (which would probably be wrong) that all the mobile
nodes are sharing some kind of switched link level, then one /64
would be enough for all of that ... Of course, that would make for
pretty huge tables, so some degree of subnetting might be appropriate.
But a /48 is probably going to be enough, even for that size site.
And of course, some of the mobiles might be gateways to other local
nets in which case those nets would be getting their own /48 (or
if they really don't need it, perhaps just /64).

kre

---

From: [email-masked]
Date: Sat, 08 Jul 2000 01:55:58 +0900

sorry for too much cross-posting.  I think the following part in the
	APNIC text is slightly unclear.

>   than 256 subnets, and /56 for other sites (eg small, domestic/home sites)

	Does /64 mean "address behind the device", or "address for the ppp
	link"?

	(1)				(2)

	ISP router			ISP router
	  |link local only		  |link local and global
	  |				  |	<--- /64 is here
	  |link local only		  |link local and global
	customer router			customer device
	  |link local and global
	==+=== <--- /64 is here

	Note that it is legal and possible to run routing protocol on
	diagram (1).  All of IPv6 routing protocol is written this way
	(and static routing is possible too).

itojun

---

From: Ignatios Souvatzis <[email-masked]>
Date: Fri, 7 Jul 2000 18:57:50 +0200

On Sat, Jul 08, 2000 at 02:15:57AM +1000, Robert Elz wrote:

> new protocols, and /80 would kill easy autoconf.

Of course.

> For sure, /80
> to ever use them all -

For traditional subnets, you're right, but...

assuming everybody could afford (at least) on phone, IP(v6) over the NMBA
network called "the world-wide phone system" already would need more then
2^32 addresses, right? /80 would be a problem even for all phones in Germany.

Regards,
	Ignatios

---

From: [email-masked]
Date: Fri, 7 Jul 2000 19:04:47 +0200 (CEST)

> Why would i want to do that?   /48 to everyone is what should be offered.

A university might have a dialup service for its employees and students.
I think they should get a /48 at home. So the university needs many /48s.
With a /40 they can have no more than 256 students/employees :-)

	rvdp

---

From: Ignatios Souvatzis <[email-masked]>
Date: Fri, 7 Jul 2000 19:04:34 +0200

On Fri, Jul 07, 2000 at 05:25:08PM +0100, Tim Chown wrote:
> able to connect just 32 Universities.

Hm... but... 

a /48 (2^16 networks) is already more than any University (I know of) has
today in v4-land. This will allow for quite some growth.

So there is no need to given them a /40 _now_. Sparsely - allocated /48 are 
fine, can be extended if needed, unless filled up, in which case renumbering
is easy. At least much easier than in v4-world.

Regards,
	-is

---

From: Ignatios Souvatzis <[email-masked]>
Date: Fri, 7 Jul 2000 19:17:48 +0200

> With a /40 they can have no more than 256 students/employees :-)

Not necessarily.
They would be counted as part of the site, and get less than a /48.

However, assuming all of them are connected at the same time (!!!),
/48 would not be enough, and they'd need something bigger, maybe a /44.

Regards,
	-is

-- 
 * Progress (n.): The process through which Usenet has evolved from
   smart people in front of dumb terminals to dumb people in front of
   smart terminals.  -- [email-masked] (obscurity)
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Stephen Burley <[email-masked]>
Date: Fri, 07 Jul 2000 09:42:08 +0000

Call me oldfashioned but i remember when people thought we had enough space in IPv4
and it would never run out. If you fix the boundry at a /48 it means an ISP will go
through their block of addresses way too fast. It also means that out customers do
not have to think about what they are deploying as they know they will get a /48 no
matter what. So a flexible boundry between /48 and /64 would help us to help
customers to think about how they will deploy their address space. 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.

Just my thoughts.

--
------------------------------------------------------------------------
Stephen Burley         "If patience is a virtue, and ignorance is bliss,
UUNET EMEA Hostmaster            you can have a pretty good life
[SB855-RIPE]                 if you're stupid and willing to wait"
------------------------------------------------------------------------

---

From: Tim Chown <[email-masked]>
Date: Fri, 7 Jul 2000 13:57:30 +0100 (BST)

I agree with Francis' comment on the /35 allocations.  If the /29
allocations were made in full from the outset there would be less
pressure at the other end...

In the case of a national educational network (my particular interest)
we currently have just 13 bits of network space to allocate to
institutions, if the institutions (Universities) get a /48 each.  At 
the same time it is bizarre that a University might get the same address 
space as a small end customer.  It is also likely that some Universities 
will command more than one /48, particularly if highly distributed.
If we have single (or multiple) subnets per room (at worst a cheap 
wireless access point per room), that /48 will look small very fast.

At present, the foreseeable allocations seem to offer little room for
the second-layer ISPs (e.g. the Universities).   It's almost as if we're
being painted into a corner by the initial 2001:: allocation and the
committment (rightly or wrongly) by the registries to ensure there are 
only 8K (13 bits) of top level routes in the DFZ, while at the same time
hedging their bets via the /35 strategy.

tim

---

From: Robert Elz <[email-masked]>
Date: Sat, 08 Jul 2000 04:00:43 +1000

Date:        Fri, 7 Jul 2000 18:57:50 +0200
    From:        Ignatios Souvatzis <[email-masked]>
    Message-ID:  <[email-masked]>

This is a non-issue, because we're not doing this, but ...

  | assuming everybody could afford (at least) on phone, IP(v6) over the NMBA
  | network called "the world-wide phone system" already would need more then
  | 2^32 addresses, right?

That's going to depend upon whether there is internal structure in that
numbering, aside from what is in the phone numbers already.  2^32 is
probably too small for that particular subnet, but ...

  | /80 would be a problem even for all phones in Germany.

Germany really has more than 2^48 phones?  Or even more than a 2^48
phone number space?   That's a 15 (decimal) digit phone number space.

In any case, the 2^64 space allocated for subnets is easily going to
be big enough to map the POTS number space, should anyone actually
want to do that.

kre

---

From: Robert Elz <[email-masked]>
Date: Sat, 08 Jul 2000 04:03:55 +1000

Date:        Fri, 7 Jul 2000 19:04:47 +0200 (CEST)
    From:        [email-masked]
    Message-ID:  <[email-masked]>

  | A university might have a dialup service for its employees and students.

If they're really acting as an ISP, then they should be treated as
an ISP, and get an ISP sized number space.

On the other hand, many universities do this kind of thing now
(in fact, I am using such a link right now) and the numbering is
just taken from part of the university's number space .  That
should work just the same for IPv6.

kre

---

From: Ronald van der Pol <[email-masked]>
Date: Fri, 7 Jul 2000 20:09:41 +0200 (CDT)

> an ISP, and get an ISP sized number space.

That is what Tim was saying. Universities might be assigned a /40.

> should work just the same for IPv6.

Yes, it will work. But I think it's strange when you get a /48 from
a commercial ISP and a longer prefix from your university. Maybe you
will have both and have two (differently sized) prefixes. A nightmare!

	rvdp

---

From: "Matt Crawford" <[email-masked]>
Date: Fri, 07 Jul 2000 13:21:54 -0500

The question to answer is, for a liberal estimate of the number of
"sites" required 50 years from now, how efficiently (how non-wastefully)
do assignments need to be made to fit within available space?

An extremely liberal estimate of the number of sites required would be
one per person.  Taking the upper range of the year 2050 population
projection from http://www.popin.org/pop1998/ ...

    World population currently stands at 5.9 billion persons and
    is growing at 1.33 per cent per year, or an annual net
    addition of 78 million people. World population in the mid
    21st century is expected to be in the range of 7.3 to 10.7
    billion. The medium-fertility projection, which is usually
    considered as "most likely", indicates that world population
    will reach 8.9 billion in 2050.

tells us to reckon on 11 billion sites.  The available space for
assignment of /48 site identifiers is 45 bits worth if we confine
ourselves to one three-bit Format Prefix.  (Six more such are potentially
available.)  Using the H-ratio of RFC 1715 to compute the required
efficiency of assignment as log_10(1.07*10^10) / 45 = 0.22.  This is less
than the efficiencies of telephone numbers and DECnetIV or IPv4 addresses
shown in RFC 1715*.  Coupled with the generous assumption of a site per
person, the reasonable expectation of easier renumbering for IPv6 than
IPv4 or the telephone, and the availability of 6x more unicast address
space, I can't see any way to justify a claim that a /48 per site can't
be supported.
				Matt Crawford

(* Actually, RFC 1715 understates the efficiency of phone number
allocation by using the number of nodes /before/ an increase in
numbering space was made but counting the bits /after/ the increase.)
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: [email-masked]
Date: Fri, 7 Jul 2000 20:34:22 +0200 (CEST)

On Fri, 7 Jul 2000, Matt Crawford wrote:

> efficiency of assignment as log_10(1.07*10^10) / 45 = 0.22. 

What does this mean? Do sites (/48) on average have 0.22*2^16=
14417 networks (/64s)?

	rvdp

---

From: "Matt Crawford" <[email-masked]>
Date: Fri, 07 Jul 2000 13:57:11 -0500

> What does this mean? Do sites (/48) on average have 0.22*2^16=

This means that if they want to have more than 10^(0.22 * 16) = 3311
subnets, they must assign them more efficiently (more densely) than
site identifiers are assigned.  This should not be difficult to do,
since they would have no need to do variable-length subnet masks like
we're doing at this site in IPv4.  (Our subnets range in size from
/28 to /21.)
				Matt Crawford
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Steve Deering <[email-masked]>
Date: Fri, 7 Jul 2000 12:04:52 -0700

>What does this mean? Do sites (/48) on average have 0.22*2^16=

No.  You really need to read RFC 1715 to understand it.  The H ratio is a
measure of the assignment efficiency of an address space, which takes into
account the inevitable wastage that you get when the addresses must have
hierarchical structure.

In this particular case, the H Ratio that Matt computed applies to the
efficiency of allocation of the high-order /48 (a 45 bit space, when you
exclude the format prefix).  It says nothing about the usage of the low-
order 80 bits (which is irrelevant, for the point that Matt is making).

Steve

---

From: Ignatios Souvatzis <[email-masked]>
Date: Mon, 10 Jul 2000 09:57:23 +0200

> phone number space?   That's a 15 (decimal) digit phone number space.

more than 2^16 phones. Oops. Of course, the phone would be a single device.
I shouldn't post on Fridays.

Regards,
	-is

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 10 Jul 2000 11:59:32 -0500

Of course we should talk, the next opportunity is the Pittsburgh IETF.

However, let's be careful about deducing general policy from what today's
ISPs believe, based on IPv4 experience. Things are truly different 
in IPv6. 

   Brian

Joao Luis Silva Damas wrote:
> 
> Brian,
> 
> At 10:29 -0500 7/7/00, Brian E Carpenter wrote:
> ...snip...
> >  > A /64 for dialup
> 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.
> 
> Joao
> 
> >   Brian

---

From: [email-masked]
Date: Tue, 11 Jul 2000 08:30:18 +1000

> 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

---

From: Joao Luis Silva Damas <[email-masked]>
Date: Mon, 10 Jul 2000 12:36:04 +0200

Brian,

Joao

---

From: Kazu Yamamoto (山本和彦) <[email-masked]>
Date: Tue, 11 Jul 2000 11:10:27 +0900 (JST)

From: Joao Luis Silva Damas <[email-masked]>
Subject: Re: (ngtrans) Fw: [apnic-announce] IPv6 Policy Document Revision

> discussions and each dependant on the other 3.

Please make the way.

--Kazu

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 11 Jul 2000 09:37:51 -0500

Daniel Karrenberg wrote:
> 
> At 06:59 PM 7/10/00, Brian E Carpenter wrote:
> we - the RIRs - are in no position to tell the ISPs that they are stupid and
> that they "don't understand". I think even the mighty IAB should be a little
> careful before going that route; it is the ISPs, after all, who convert
> integers to address space by routing traffic based on it.
> 
> Policies will change as we go along and all those involved understand more and
> get more comfortable with things.

Indeed, my words that you quote were written to avoid insulting the ISP's
intelligence and experience... but IPv6 is truly different.

   Brian

---

From: Randy Bush <[email-masked]>
Date: Tue, 11 Jul 2000 08:12:06 -0700

> intelligence and experience... but IPv6 is truly different.

yes.  it's not deployed.

and to get it deployed, as bernard just said well on the ietf list, we need
to make it *significantly* more attractive than the status quo, like five
times as attractive.

one attraction could be address space.  and ipv6 has a lot of it, though,
having been through some decades in this game it is hard to believe that
this year's effectively-infinite will not be next year's (or decade's) joke.

so it would be nice if we could have an ipv6 address space allocation policy
which allowed users to perceive the benefits of the larger address space.
and, imiho, we should err on the side of generosity.

but we should not forget that we have four more wonderful marvels of ipv6 to
find if we want it to sell.

randy

---

From: Daniel Karrenberg <[email-masked]>
Date: Tue, 11 Jul 2000 10:28:01 +0200

Brian,

Daniel