Subject: RE: IPv6 Addr/Prefix clarification

From: "Michel Py" <[email-masked]>
Date: Fri, 1 Feb 2002 08:33:21 -0800

Kre and Philip,

> I find it almost impossible to work out where /80 comes from (unless
> you mean to find a need to do so, in which case, then yes, I'd find
> that pretty difficult too, though I prefer more often to have
> constant 0 bits in higher order positions than lower ones, so I'd
> tend to make the mask longer, and put 0's in the subnet section
> rather than shorter with 0's in the host part - but that's just
> aesthetics). But if there's something supposedly magic about the last
> 48 bits (48 now is 100% irrelevant to autoconf, so it cannot be
> that) it has escaped me.

What I had in mind was that if someone felt like re-inventing the wheel
and create a new autoconf, it would be extremely difficult not to use
the 48-bit MAC address (nobody would buy having ARP for IPv6), therefore
going beyong /80 would be very difficult.

> For giving advice to the population at large, I'd probably suggest
using
> /64 for almost all nets, to lower the chances of running into limits
in
> the technology that shouldn't be there (but bugs exist everywhere).

Concur.

> Philip Homburg wrote:
> What happens if an organization has a modem bank for dail-in? Do you
> hand out /64s or something larger? Suppose that you want to give each
> 'modem user' a fixed prefix, how soon do you run out of prefixes?

Modem users will be more than happy with a /64, because they do not need
to
subnet. If one wants to share the modem connection for their home
network,
that home network is a single subnet and will do fine with a /64.
Broadband
home connections (cable/dsl) would do ok with a /64, too, for the same
reason.

Why would someone want a /68 (or whatever) for the living room, a /68
for
the john, a /68 for the kitchen, a /68 for the garage?

Michel.

--------------------------------------------------------------------
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: Philip Homburg <[email-masked]>
Date: Fri, 01 Feb 2002 18:35:21 +0100

In your letter dated Fri, 1 Feb 2002 08:33:21 -0800 you wrote:
>to subnet.

The kids get their own networks to play multi-person games, the
light switches go on a separate network, any piece of hardware that is
not completely secure should not be on a broadcast network, so the ADSL or
cable modem, the wireless basestation, etc. each get their own networks.
VPNs may require their own prefixes, etc.

					Philip Homburg

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 1 Feb 2002 09:56:45 -0800

> VPNs may require their own prefixes, etc.

This is why sites should be allocated /48s. There is no inherent reason
to break into the interface id space for subnets. This is particularly
true when the reason is simply to satisfy the draconian address
conservation attitude required to extend the life of IPv4 until IPv6 can
be deployed.

Tony

---

From: Tim Chown <[email-masked]>
Date: Fri, 1 Feb 2002 18:03:01 +0000 (GMT)

> conservation attitude required to extend the life of IPv4 until IPv6 can

If that's static /48's, the /29 boundary will need revision...(and
certainly a /35 would be useless to any medium ISP).

Would you apply the RFC3194 0.8 HD ratio to subnets within a single ISP?
I don't see that provider networks would be flat or near 100% utilisation
as you suggest in your previous email.
 
Tim

---

From: Keith Moore <[email-masked]>
Date: Fri, 01 Feb 2002 13:39:57 -0500

> going beyong /80 would be very difficult.

We're talking about a technology that will hopefully be used for decades.
We don't want to wire assumptions about the sizes of MAC addresses 
during that time into the IPv6 architecture.  

To me it seems entirely plausible that networks consisting of large 
numbers of point-to-point links, assembled into trees, will be all the 
rage in a few years.  Even Ethernet is becoming more a point-to-point 
technology rather than a bus technology.

Keith

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 1 Feb 2002 11:43:26 -0800

> certainly a /35 would be useless to any medium ISP).

Did the term 'slow-start' get lost somewhere? As I understand rir
policy, the /35 was never intended to be the only allocation a serious
ISP would get. Static vs dynamic is a non-issue, because either there
are enough prefixes to route the currently connected customers or there
aren't. If a service provider wants to allocate prefixes to customers
that aren't connected, they will need a larger block than the one that
allocates dynamically based on connected status.

> as you suggest in your previous email.

Within the context of a pop, why not? The only reason this would not be
the case is when a provider considers the allocation to be disjoint from
current connected status (ie: static assignment) and the measurement is
done on the connected set rather than the allocated set. The HD ratio
should be calculated on the allocated set no matter if  that is static
or dynamic.

I can already hear the 'what about renumbering nodes?' question. There
is no reason for this to be an issue. Address use is defined to match
the smallest scope appropriate for the connection, so intra-site/on-link
communications will be immune to changes in the global prefix. If a site
is currently disconnected from the service provider, there is no reason
for it to have a global prefix floating around. The only reasons for an
ISP to make static prefix assignments would be if the site wanted stable
DNS entries, but with a decent DDNS infrastructure that is not even
required.

Tony

---

From: Tim Chown <[email-masked]>
Date: Fri, 1 Feb 2002 21:54:23 +0000 (GMT)

> allocates dynamically based on connected status.

The question is, if a service provider wants to follow the recommendation
for a /48 allocation for a connected site, and the provider wants to
offer static /48's to always-on sites, won't it hit trouble whether it is
using a /35 or a /29?   If you say "either there are enough prefixes to 
route the currently connected customers or there aren't" then you're saying
either we will have ISP's out there who can allocate static /48's to sites, 
or we won't.  It'd be nice if the answer was that we will... even if that 
provider has a million customers.

I feel we're in a slow start inside a slow start and that will be harmful,
because providers won't offer the /48 because there's not enough headroom.
OK, a static /64 is better than today's (typical) dyanmic single IPv4 
address, I agree :-)
 
> should be calculated on the allocated set no matter if  that is static

I observe, as a BT ADSL customer, 9 hops from my NAT box to the BT Internet
gateway.  The question then is whether the provider can build an 
architecture to 100% utilise the address space (unlikely), or if not to 
what extent the address space can be used, in a wide area deployment (e.g. 
for BT xDSL across the UK)?   It should be better than RFC3194, but how
much better?
 
> DNS entries, but with a decent DDNS infrastructure that is not even

My own view is that a static prefix is very important.  Certainly a "decent 
DDNS infrastructure" would have to deal with significantly more renumbering,
and more rapid renumbering, application awareness, more lookups with lower
TTLs, firewalling problems (I set up access to let my friend copy files 
from my MP3 server, but oops his prefix just changed), issues where the 
Mobile IPv6 home agent/prefix is really in the home, etc.  Thus the DDNS 
infrastructure has to fit the model where the servers are on the networks 
with the dynamic addresses.  It just seems so much easier to assume static 
home prefixes.   But if we want that, the implications for the providers' 
allocations needs to be addressed.  

Tim

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 1 Feb 2002 15:08:16 -0800

> provider has a million customers.

To serve a million the service provider will need at least a /28, and
probably a /27 where is the problem? If you are assuming that the rir's
won't allocate a /27 to a provider that can document allocation to a
million customers then we have a problem with rir policy not being
applied consistently with what is documented.

> OK, a static /64 is better than today's (typical) dyanmic single IPv4

There are active discussions about changing the slow-start. We will have
to see what happens, but I believe a /32 is likely. I really doubt that
a provider would have a hard time getting a /27 if they walked in with a
list of a million customers and said here is our plan for allocating
/48's statically to each of them. As I understand it, the rir policy is
intended to ensure efficient allocation, not dictate a business practice
of dynamic allocations. If you have evidence to the contrary please
speak up.

> gateway.

Sounds like a personal problem of provider selection... ;)
My dsl is 3 hops from the nearest border router.
 1     *        *        *     Request timed out.
 2    18 ms    18 ms    18 ms  a4-3-1.evrtwa1-aa2.bbnplanet.net
[4.24.255.193]
 3    20 ms    20 ms    18 ms  p7-0.evrtwa1-cr2.bbnplanet.net
[4.0.79.129]
 4    18 ms    18 ms    24 ms  p3-0.evrtwa1-br2.bbnplanet.net
[4.24.5.109]

> The question then is whether the provider can build an

CAN or WILL ?? It is certainly possible and easy to build complex
infrastructures that don't scale well, but usually hard to build simple
ones that naturally align with growth. One of the big problems I see
from a long-term perspective with static assignments is 'how portable
are the addresses?' If customers can move around the topology and keep
the same address, the complexity goes way up and the HD ratio goes way
down (actually if you treated the entire /28-48 as a single flat-route,
the HD ration could hit 100%). If on the other hand the addresses were
static with topology, it would be fairly straight-forward to align the
sub-allocations along with population/pop-density (a town with ~1000
residents won't need more than a /38).

> allocations needs to be addressed.

I agree and would be happy if all service providers were enlightened
enough to *want* to provide static prefixes. If someone with a million
existing customers has tried to show the rir's a plan for a static
prefix assignment network and failed, I would like to know so a few of
us can start working the issue.

In any case I believe a robust ddns is required, and would prefer to see
that as an edge service (ie: set-top) with the access device providing a
nice, stable, single-point-needing-auth server for local devices that
come and go on a frequent basis. It also makes the problem of ddns auth
within the home easier because that can all be based on site-local
addresses which the edge device knows didn't come through it from the
public side.

Tony

---

From: Tim Chown <[email-masked]>
Date: Sat, 2 Feb 2002 00:16:11 +0000 (GMT)

> applied consistently with what is documented.

That's fine - my question was, because of the regionalisation and scoping
for growth in network deployment, whether a /27 was enough (if you did
use RFC3194 and its 0.8 HD ration you'd need a /23 for 1 million objects,
but given the provider is in sole control of one network, I agree it should
be far more efficient).
 
> of dynamic allocations. If you have evidence to the contrary please

No, just an observation that the static/dynamic issue is not discussed in
the IESG recommendations document.  Perhaps it shouldn't be, but if 
providers read it, some reference may be useful (static /64 is mentioned
for mobile networks, but of the five example recommendations, only that
one explicitly says static).
 
I would hope registries would not refuse an allocation based on the fact
that they wished to make static allocations, if say only 75% of their
customers were connected at one time and they could thus save a few bits
of space by dynamic allocations.  (The question then is why would a provider
use dynamic allocations - presumably as a means to resize/juggle their
network, though at present it's often used, even with free ddns services
available, to deter people from running services from their home networks,
which is exactly what we want IPv6 for...).

> My dsl is 3 hops from the nearest border router.

I didn't say BT Openworld was the best :-)   I recall it was more hops
until recently, and that for one trace I hit the default 30 hop limit...(!)
But it's an indication that address utlisation won't be as good as people
may hope?

>  ...... One of the big problems I see

I was assuming the static addresses were aligned with topology.  Then
the premise would be that your IPv6 prefix is static for the home you are
in, if you keep the same provider.  Having considered an addressing plan
for a national academic network, I don't know how (say) a plan for a
BT Openworld IPv6 deployment might look (apart from more complicated
than your provider's, I expect!).

The static prefix I agree has implications for the provider in planning the
deployment, and their ability to reshuffle their addressing scheme as the
topology and regional demand changes.  Perhaps the IESG proposal should
have a section on this, if it's deemed appropriate and revelant?

Tim

---

From: Pekka Savola <[email-masked]>
Date: Sat, 2 Feb 2002 21:58:09 +0200 (EET)

> allocates dynamically based on connected status.

IMO, there are two problems (neither are critical, but rather nasty):

- /29 is the easy "RIR allocation" limit currently: if that won't be 
enough, there will be fragmentation: some sTLA's get more than one prefix.

Note: at 80% HD ratio, this would only be enough for about 38K customers.

- /48 is the easy "organization allocation" limit: consider a
university/big organization like Nokia with /48: well enough for for its 
own infrastructure but completely inadequate for:
 - giving e.g. dial-in/DSL users a /48 (heh :-)
 - giving e.g. dial-in/DSL users a /64 (at 80% HD ratio, about 7K users 
could be supported)
 ==> also fragmentation..

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 03 Feb 2002 12:18:28 +0100

Michel Py wrote:
...
> the john, a /68 for the kitchen, a /68 for the garage?

Count the light bulbs and electric motors in your house. I don't want to
exclude *anything* for the future. Luxury cars already contain several
CAN subnets.

   Brian

---

From: Peter Bieringer <[email-masked]>
Date: Sun, 03 Feb 2002 20:45:30 +0100

--On Sunday, February 03, 2002 12:18:28 PM +0100 Brian E Carpenter
<[email-masked]> wrote:

> Count the light bulbs and electric motors in your house. I don't
> want to exclude *anything* for the future. Luxury cars already
> contain several CAN subnets.

Bridging can solve the problem and it's cheaper than routing.
Perhaps a cost reduce factor.

BTW: firewalling can be done also in a intelligent bridge. Afaik
there is already such a project going on connecting Linux bridging
with netfilter.

        Peter

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 04 Feb 2002 09:19:50 +0100

Being a victim of the bridging wars from ten or fifteen years ago,
I can assure you that bridging is a lousy solution and not the one
we should use as a strategy. What we learned then, people will relearn
now.

   Brian

---

From: Robert Elz <[email-masked]>
Date: Mon, 04 Feb 2002 15:17:31 +0700

Date:        Sun, 03 Feb 2002 20:45:30 +0100
    From:        Peter Bieringer <[email-masked]>
    Message-ID:  <47560000.1012765530@localhost>

  | Bridging can solve the problem and it's cheaper than routing.
  | Perhaps a cost reduce factor.

Bridging isn't always possible - bridging only works amongst compatible
link level technologies.

Please, can we stop telling people how they have to run their nets, and
get back to implementing the fullest possible flexibility, so they can
choose, and we (the internet) isn't locked out of new technologies that
might arise.

I am not entirely sure how this question switched from what (if any)
knowledge of address boundaries should be in implementations, to what size
allocations ISPs should make (the two are just about unrelated), but all the
recent discussions are just repeating the same old stuff over and over, with
no sign that a different conclusion will be reached than it has been every
time in the past.

kre

---

From: Tim Chown <[email-masked]>
Date: Fri, 8 Feb 2002 08:22:51 +0000 (GMT)

On Thu, 7 Feb 2002, Steve Deering wrote:

> No, the plan as I understand it is to apply the HD ratio to the number
> of /48s, when evaluating an ISP's application for more address space.

So if an ISP came along and said "we have a million customers signed up,
we want to give them static /48 prefixes to their current home xDSL lines,
and thus we'd like a /23", that should be approved? (2^25^0.8 ~= 1M)
Of course, as Tony says, no such ISP exists yet, nor may it for some time.

> If that's so, and taking high end of that prediction (12 billion), we
> ought to be able to assign a half a dozen (70 billion / 12 billion)
> static /48s to every living human (not just every "site" or household),
> hierarchically structured for routing and allocation, at a manageable
> HD ratio of 80%.  And remember that's just with the 001 space.  We can
> use the rest of the space for the animals, aliens, robots and non-living
> humans.

The problem is, if our friend Mr Fleming is right, the aliens with be running 
IPv8 from some different galaxy/stargate prefix :-)

Tim

---

From: Steve Deering <[email-masked]>
Date: Thu, 7 Feb 2002 17:45:04 -0800

>certainly a /35 would be useless to any medium ISP).

Yes, those boundaries are currently under discussion in the registry
community, and I certainly expect them to change.  (Though as pointed
out by Tony, those were intended just as *initial* allocations to ISPs
before they have many IPv6 customers; ISPs with lots of customers will
get bigger blocks, and if it works out as planned, in most cases those
larger blocks will include the initial smaller blocks, so that assigning
more space to an ISP won't increase the number of routes to that ISP
(but rather just shrink the prefix of the existing route).

>as you suggest in your previous email.

No, and that's not what the policies under discussion in the RIRs assume.

By the way, if I've operated my calculator correctly, there are
approximately 35 trillion /48s in the 001-prefix part of the IPv6 address
space.  Applying the HD ratio calculation to that number yields:

     HD = .80 ("manageable")      =  70 billion
     HD = .85 ("painful")         = 330 billion
     HD = .87 ("practical limit") = 610 billion

(using U.S. definition of "billion", i.e., 10^9)

I read a reference to an article recently (in Science or some comparable
journal; I really need to hunt it down) that stated that the current
world population is about 6.1 billion and that population scientists
are projecting that human population will hit its peak sometime around
2070, though the predicted peak number varies widely between 9 and 12
billion.

Steve

---

From: Steve Deering <[email-masked]>
Date: Fri, 8 Feb 2002 11:01:13 -0800

>and thus we'd like a /23", that should be approved? (2^25^0.8 ~= 1M)

Yes, absolutely, assuming they can present some evidence that they
really do have that many customers.  Also, if the ISP were growing
quickly enough they might well be given a bigger block than a /23,
so they wouldn't have to come back again for more too soon.  I believe
the registries are considering taking growth rate into account, as
well as customer count, when deciding how much space to allocate to
an ISP.

Steve

---

From: Keith Moore <[email-masked]>
Date: Fri, 08 Feb 2002 15:54:23 -0500

> really do have that many customers.  

does the decision to use ASCII hex labels (rather than bitstrings) in ip6.arpa
affect the allocation?  would the RIRs be expected to dole out prefixes in
4-bit increments in order to make DNS delegation for PTR lookups easier? 
--------------------------------------------------------------------
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: Thu, 7 Feb 2002 17:51:13 -0800

>technology rather than a bus technology.

Like Ethernet bridges, we can do IP-layer "host routing" among an
interconnected set of point-to-point links, treating the interconnected
set as a single subnet (i.e., sharing a single /64).  This is the multi-
link subnet idea, and I think it would be a very nice way to handle
residential and small office sites with multiple links, being just as
"plug-and-play" as Ethernet bridges (no need to assign subnet numbers,
etc.)

Steve

---

From: Steve Deering <[email-masked]>
Date: Fri, 8 Feb 2002 13:28:28 -0800

>4-bit increments in order to make DNS delegation for PTR lookups easier? 

I sure hope not.  I have heard Randy and others claim that there is no
reason to impose such a restriction, regardless of the dropping of the
bitstring representation.  Doesn't current IPv4 usage (which also doesn't
use bitstrings, and which doesn't restrict CIDR prefixes to be only
multiples of 4-bits long) provide a working example of how it can be done?

Steve

---

From: Pekka Savola <[email-masked]>
Date: Sat, 9 Feb 2002 01:10:40 +0200 (EET)

> multiples of 4-bits long) provide a working example of how it can be done?

Allocations on non-nibble boundaries are possible of course.. it could
just mean about 8 different almost identical delegations in the worst
case.

Or are you referring to "Class-less reverse delegation" (RFC2317)?  I'm 
not sure if that'd help all that much.

---

From: David Terrell <[email-masked]>
Date: Fri, 8 Feb 2002 23:30:46 -0800

> not sure if that'd help all that much.

My understanding was that 2317 was only needed on sub /24 allocations,
though of course it could be used to allocate a /17 "efficiently".

I do not think 2317 should be propagated forward into ip6.arpa.  The 
need is not present.

-- 
David Terrell            | "When we said that you needed to cut the
[email-masked]             | wires for ultimate security, we didn't
Nebcorp Prime Minister   | mean that you should go wireless instead."
http://wwn.nebcorp.com/  |   - Casper Dik
--------------------------------------------------------------------
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: Jochen Kaiser <[email-masked]>
Date: Mon, 11 Feb 2002 01:13:14 +0100

> Perhaps a cost reduce factor.

I doubt, that optmimizing a L2 structure is much cheaper then sophisticating a
 L3 structure. Look at the tuning, which cisco (or other major player) 
does with L2. You don't want this at the end-customers household since 
it needs monitoring and fine tuning and has many sources of errors. 

However, the end-customer side and the corresponding scenarios aren't
examined enough for IPv6 so far. Is someone doing research in this
field and has some papers to read?

with kind regards,

jochen kaiser
university of erlangen

---

From: Rob Austein <[email-masked]>
Date: Fri, 08 Feb 2002 18:24:02 -0500

> just mean about 8 different almost identical delegations in the worst

Right.  Which should trivially easy to automate for any organization
big enough to need to worry about it.

> not sure if that'd help all that much.

RFC 2317 describes a hack that's not particularly useful for IPv6.
Even for IPv4 it's only useful in situations where there's an
allocation boundary within the least significant label; the
corresponding situation in the IPv6 case would imply an allocation
boundary in the least significant nibble of the 128-bit IPv6 address.