Subject: Re: draft-narten-ipv6-3177bis-48boundary-02.txt

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 12 Jul 2006 11:24:27 -0400

Hi all,

I've reviewed this document and my comments are as follows.

1. Introduction
"giving out an excessive". I think we need to define excessive and/or say if
this is an objective or subjective perception.

A general comment/opinion. I don't think this document should be published
as is, because it provides a bad message to the market about IPv6 assignment
recommendations not being stable. I will be in favor of a "smaller" revision
of RFC3177, not so much disruptive as this one, but in the other way around,
discouraging /128 and /64 assignments.

I think the motivations behind the /48 are still valid and one of the main
goals of IPv6 addressing space is to ensure enough space to end-users, which
is only ensured with a clear boundary recommendation.

Furthermore, the lack of a clear boundary disrupts the RFC3177 goal of
ensuring a consistent subnet to facilitate management and renumbering. In
practice receiving a new assignment from and ISP w/o a specific
recommendation will be a big source of troubles if different ISPs decide to
do different things. Take the case of a user moving from an existing ISP
with today provides a /48 to a new one.

In addition, as an end user, it provides a recommendation to ISPs to provide
a reduced service in terms of the number of subnets, instead of the actual
/48 recommendations (with a clear example for /56), which I think is very
bad, especially when it is based in a subjective view of "excessive".

I also think that the lack of clarity in stating that more than a single /64
is required in most of the cases is going to be wrongly taken as a "go for
/64".

Regards,
Jordi

> De: Thomas Narten <[email-masked]>
> Responder a: <[email-masked]>
> Fecha: Wed, 12 Jul 2006 09:30:27 -0400
> Para: <[email-masked]>
> Asunto: FWD: draft-narten-ipv6-3177bis-48boundary-02.txt
> 
> ------- Forwarded Message
> 
> From: Thomas Narten <[email-masked]>
> To: [email-masked]
> Date: Wed, 12 Jul 2006 09:26:27 -0400
> Subject: draft-narten-ipv6-3177bis-48boundary-02.txt
> 
> FYI, draft-narten-ipv6-3177bis-48boundary-02.txt was submitted just
> prior to the ID cutoff, and the authors believe it is ready for
> publication as an RFC. We are in discussion with the ADs about having
> the document shepherded through the IESG as an informational document.
> Note that this document would formally replace RFC3177.
> 
> Comments welcome of course!
> 
> Thomas
> 
> ------- End of Forwarded Message
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

**********************************************
The IPv6 Portal: http://www.ipv6tf.org

Bye 6Bone. Hi, IPv6 !
http://www.ipv6day.org

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

---

From: Mark Smith <[email-masked]>
Date: Thu, 13 Jul 2006 06:46:02 +0930

Hi,

Following on from Jordi's comment,

> bad, especially when it is based in a subjective view of "excessive".

although I haven't had a chance yet to read the new draft quite yet, I
think pointing out the following paper might be worth useful as it
discusses the motivations behind a similar addressing decision from the
past (from when I was a young lad of 10!) :

http://portal.acm.org/citation.cfm?id=802680&coll=portal&dl=ACM&CFID=76839379&CF
"48-bit Absolute Internet and Ethernet Host Numbers",
Yogen K. Dalal and Robert S. Printis, 1981.

It seems to me that the fundamental decision here is the choice or
balance between conservation and convenience. With a scarce resource,
you need to make conservation a priority, which of course is what (now)
happens with IPv4. With an abundant resource, such as Ethernet
addresses, or IPv6 addresses (and IPv4 addresses for most of the
classful days), you can make (operational/deployment etc.) convenience
a priority, with the cost of that convenience a higher level of
consumption of the resource. This additional consumption isn't "waste",
because it provides a direct and useful benefit. However, if you apply
a scarce resource usage mentality (which is the IPv4 one these days), it
would appear to be, because "convenience" is basically a luxury, not a
necessity.

Obviously, in both the scarce or abundant cases you need to make sure
actual waste doesn't occur.

While I do agree that a /48 per site does seem excessive, particularly
for a home user, and would therefore accept the /56 per site argument,
I think it is very important that the balance isn't isn't tipped too far
back towards conservation when it isn't necessary.

I think one of the fundamental goals of IPv6 is convenience of use and
administration, and I also think it is one of the fundamental benefits
over IPv4. If we have opportunities to make anything in IPv6
convenient, such as renumbering without changing subnet numbers, at the
the cost of some of the abundant IPv6 address space, I think it is a
worthwhile cost.

Regards,
Mark.

(Another curious (amusing ?) example of "waste" we're quite happy to
accept for the convenience or cost benefit is the 12 byte per
packet overhead for addressing on 10GigE point-to-point links, where
addressing isn't actually necessary at all.)

---

From: Ralph Droms <[email-masked]>
Date: Thu, 13 Jul 2006 09:36:11 -0400

Thomas - is there any way in which you can quantify "excessive"?

E.g., make some suppositions for an ISP:

* number of subscribers
* subscribers per aggregation point (CMTS for cable)
* length of prefix required for each aggregation point
* length of prefix to be assigned to an ISP based on the above

- Ralph

On 7/13/06 9:30 AM, "Thomas Narten" <[email-masked]> wrote:

> Hi Jordi.
>> "giving out an excessive". I think we need to define excessive
>> and/or say if this is an objective or subjective perception.
> 
> I have two repsonses to this.
> 
> First. giving out a /48 to every home network (which today has at most
> a handful of machines, which means, one subnet would suffice) is
> widely viewed as excessive. Even a /56 to such end sites seems more
> than enough space to meet needs for at least the next decade (and most
> people seem to be comfortable with that, even if it is a lot of
> space). You've been to RIR meetings. Surely you have noticed this
> sentiment both in the hallway and in comments made (regularly) at the
> microphone.
> [...]
> Thomas
>

---

From: Thomas Narten <[email-masked]>
Date: Thu, 13 Jul 2006 09:58:15 -0400

Ralph,

> Thomas - is there any way in which you can quantify "excessive"?

Whether "excessive" is an appropriate word to use is a judgement
call. YMMV. But, the word "excessive" is literally the word I hear
many people (especially in the RIR and operational community) use when
talking about this issue. And I'll note, that even when the IETF went
forward with 3177 originally, I think we'd have to say consensus was
"rough". Thus, even within the IETF, some people thought /48 was
excessive.

> * length of prefix to be assigned to an ISP based on the above

What 3177bis is talking about is the size of the assignment to a
single end site, e.g., a home, a business, etc. The above are more
about issues internal to an ISP (or a very very large end site), and
thus the above really relate more to the size of the RIR->LIR (ISP)
allocation. I.e., a different issue.

Thomas

---

From: Thomas Narten <[email-masked]>
Date: Thu, 13 Jul 2006 09:30:19 -0400

Hi Jordi.

But more to the point, the current text in the document actually says:

   There are a number of considerations that factor into address
   assignment policies. For example, to provide for the long-term health
   and scalability of the public routing infrastructure, it is important
   that addresses aggregate well. Likewise, giving out an excessive
   amount of address space could result in premature depletion.

How can you possibly object to the use of the word excessive in the
above context?    

> A general comment/opinion. I don't think this document should be
> published as is, because it provides a bad message to the market
> about IPv6 assignment recommendations not being stable. I will be in
> favor of a "smaller" revision of RFC3177, not so much disruptive as
> this one, but in the other way around, discouraging /128 and /64
> assignments.

As you know, policy proposals to move away from /48 are currently
being discussed in the indvidual RIR regions. Indeed, ARIN has already
adopted one
(http://www.arin.net/policy/proposals/2005_8.html). Publishing this
document will not stop the registries from moving away from
/48. Indeed, a primary goal is to make it clear that making such a
decision is for the RIRs to make (i.e., to acknowledge reality), and
that from an IPv6 architectural perspective, this is fine.

So, to be clear, do you disagree with the statement that moving from
/48 to /56 is fine from an architectural perspective? If not, please
be specific.

I do agree there are operational issues with having varying prefix
sizes. But that is something that the RIRs need to take into
consideration as they discuss policy proposals. Indeed, this document
tries to make clear that taking into consideration such operational
considerations should be done.

> I think the motivations behind the /48 are still valid and one of
> the main goals of IPv6 addressing space is to ensure enough space to
> end-users, which is only ensured with a clear boundary
> recommendation.

It is widely viewed that a /56 to everyone would achieve this
adequately, whereas a /48 is "execessive" to achieve this goal.

> with today provides a /48 to a new one.

The document says this. But in any case, this argument needs to be
taken directly to the RIRs.

> In addition, as an end user, it provides a recommendation to ISPs to
> provide a reduced service in terms of the number of subnets, instead
> of the actual /48 recommendations (with a clear example for /56),
> which I think is very bad, especially when it is based in a
> subjective view of "excessive".

> I also think that the lack of clarity in stating that more than a
> single /64 is required in most of the cases is going to be wrongly
> taken as a "go for /64".

I see no evidence that RIR policies are going in that direction. My
sense (this is based on following and participating in RIR discussions
for the last few years) is that those communities understand very well
that a /64 as default end site allocation unit is neither desirable
nor necessary and that there is plenty of address space to make the
default allocations much larger. But they (even from day one) have
largely viewed a /48 as excessively large.

Thomas

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 13 Jul 2006 12:21:46 -0400

On 12-jul-2006, at 9:30, Thomas Narten wrote:

> draft-narten-ipv6-3177bis-48boundary-02.txt

I have several problems with this document.

It's vague. RFC 3177 is very clear and provides easily identifiable  
recommendations supported by arguments. The new draft doesn't provide  
any recommendations to speak of, other than that /48 is probably too  
much for most users. It then sort of tosses the issue over the fence  
into RIR terrain, largely ignoring the importance of maintaining the  
same assignment size when moving from one service provider to  
another, which is a prominent consideration in RFC 3177.

I don't think it would be the worst idea ever for the authors to  
simply retract the document and for the IETF to stand by RFC 3177.

In the alternative, I strongely suggest using RFC 3177 as a model for  
the new document and only insert new text where required by new  
insights, maintaining the overal clarity of the ealier document. It  
should be stressed that having different prefix sizes in the market  
place leads to higher operational cost because moving from one ISP to  
another then requires doing more work than just change a fixed number  
of high bits in all places where addresses appear in configurations.

I'd like to offer the way DHCPv6 prefix delegation is implemented in  
Cisco routers as an example. Cisco routers are capable of requesting  
a prefix over DHCPv6 and then automatically generate addresses for  
subnets based on this prefix. However, this requires adding a  
specific number of bits, so even though the prefix itself doesn't  
appear in a router configuration, its _length_ does.

Obviously it's easier to renumber from a small prefix into a larger  
one, but if different prefix sizes exist it can't be assumed that the  
only movement is from service providers giving out long ones to  
service providers giving out shorter ones.

There is another issue, that is not present in the original RFC 3177,  
but which I stumbled over several times in operational environments,  
so I think it's important it's addressed:

RFC 3177 only talks about the prefix for the end-user. It doesn't  
address the way the end-user communicates with his or her service  
provider. (I'm ignoring the case of a /128.) With a /64 this can  
happen in one of two ways:

1. The ISP assigns the /64 for use on the link between the ISP and  
the user
2. The ISP hands the /64 to the user for internal use

In the first case, the user can't let the device that talks to the  
ISP route IPv6 between an internal subnet and the ISP, but is forced  
to connect all devices that require connectivity directly at the link  
level to the ISP.

In the second case, there aren't any addresses available on the link  
between the user and the ISP, so either additional address space must  
be provisioned, or link locals must be used. Neither of these is  
impossible, but they do require additional complexity that is  
extremely undesireable.

Considering the above, giving out /64 really doesn't address a  
reasonable use case: either the prefix is used on the ISP link and  
then a /128 would also suffice, or the prefix isn't used on the ISP  
link and a second subnet is required.

For these reasons, I think it's important to move away from /64 in  
the RFC 3177 /128-/64-/48 model. The next obvious choice is /60,  
which allows for 16 subnets. The all-ones subnet [1] could be used  
for the ISP subnet by convention, simplifying address provisioning  
and leaving 15 subnets for use by the customer. This is more than  
enough in all cases where only a single router is expected to be  
present on the site in question.

This brings us to a /128-/60-/48 model. The next question is whether  
it's useful to bring the /48 down to /56 as a general recommendation.  
My answer is no. Since for the vast majority of home and small office  
users a /60 will suffice where they would have gotten a /48 under RFC  
3177 (because they have a handful of subnets or in case they will in  
the future), the amount of address space used will already go down  
dramatically, so from an address use point there is no reason to  
fiddle with /48. A second argument is that if someone needs more than  
a /60, there is a reasonable chance that they may eventually also  
grow out of a /56. If and when that happens, they have up to 250  
subnets and renumbering at that point is quite painful, apart from my  
earlier argument about the virtue of having a standardized prefix  
size for a given class of end-users.

Iljitsch van Beijnum

[1] Another choice would be the all-zeros subnet but if the same is  
done with a /48 it would be a shame to use this subnet up for this as  
the all-zeros subnet allows for shorter addresses, especially if more  
zeros follow.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 13 Jul 2006 17:45:08 -0400

Hi Thomas,

Below, in-line.

Regards,
Jordi

> Responder a: <[email-masked]>
> Fecha: Thu, 13 Jul 2006 09:30:19 -0400
> Para: <[email-masked]>
> CC: <[email-masked]>, <[email-masked]>
> Asunto: Re: draft-narten-ipv6-3177bis-48boundary-02.txt
> 
> Hi Jordi.
> 
>> Hi all,
> 

Part of the problem is what each of us considers enough, and this may depend
on knowledge about developments being cooked, which bring the need of more
than 256 subnets, even if you have only a handful of devices in each one.

> space). You've been to RIR meetings. Surely you have noticed this

Yes, having been in probably all the RIR meetings in the last 3 years or so,
my perception is that people is divided in both sides, but there is not a
clear view that one or the other is good. In concrete regions this becomes
more balanced to one side or the other.

Moreover, most of the people talking about this has the view of "/48 is bad"
because they don't understand the scale of magnitude vs. IPv4, they are some
how "IPv4 old fashioned mind set".

The perception was even worst because the previous HD-ratio.

However, now that the HD-ratio change has been accepted in all the regions,
the perception of /48 being a waste, is not realistic.

I recall Tony Hain figures with the HD-ratio change of about 480 years or
so. I think even if we are mistaken by let's say 250-300 years, assuming
that our conservation principles need to account for that much time is
extra-conservation and that can be considered even worst than being
wasteful.

Do we really believe IP will still be sufficient at that time for our needs
?

> How can you possibly object to the use of the word excessive in the

I think is subjective, as explained above with the perception of what is
wasteful and what not from different people.

However, as the text say, it is important that addresses aggregate well, so
I just noticed that this seems to be in favor of my argument, seems better a
balance between more addresses and less "address blocks" (so bigger blocks),
while we aren't wasting space, as it helps avoiding future deaggregation.

Note I'm not saying that RFC3177 is perfect anymore.

> (http://www.arin.net/policy/proposals/2005_8.html). Publishing this

Yes, and ARIN is the only one that approved it at the time being. At least
in three other regions, my recall is that has been rejected for further
discussion in the list, which will need probably an average of 1 year to be
again considered for approval.

> that from an IPv6 architectural perspective, this is fine.

I think we have a disagreement here. It is true that there is not a strict
technical reason for using something different than /48 which may affect
protocols, however, there are other operational reasons which are of the
same relevance.

That's why RFC3177 was not mandating, but providing guidelines, and this I
believe we still need to keep doing. This is what we do in v6ops and if we
don't provide operational guidelines or recommendations or whatever we want
to say for "ways to do the things and why, pros/cons", probably, we should
not have ops WGs at all.

The documents are not just read by RIRs but also by LIRs, enterprises, etc.
They need guidelines, and usually they will take their own decisions, but we
should not create extra-alarmist perceptions when they aren't proven.

> /48 to /56 is fine from an architectural perspective? If not, please

Responded above already. Is fine from an architectural perspective, but not
from the operational perspective considerations.

> considerations should be done.

Same as above, this is ops WG tasks and "open" suggestions may be even worst
than no suggestions at all.

> adequately, whereas a /48 is "execessive" to achieve this goal.

I've the same trouble with "widely". This is somehow a subjective
appreciation. As Ralph suggested, let's make figures for everything and may
be we can get an objective view, otherwise, let's try to keep being
objective.

> I see no evidence that RIR policies are going in that direction. My

No, I was not referring to RIRs here, but to ISPs.

Bye 6Bone. Hi, IPv6 !
http://www.ipv6day.org

---

From: "Jason Schiller ([email-masked])" <[email-masked]>
Date: Fri, 14 Jul 2006 00:20:49 -0400 (EDT)

On Thu, 13 Jul 2006, Iljitsch van Beijnum wrote:

> It 

If everyone accepts that ipv6 addresses have variable length subnet masks
(and everyone has the appropriate tools to handle this) and the RIRs have
a reasonably sound definition of what a good justification is for a given
size IP block, then I fail to see the value of "classful" addresses.

If a customer of ISP 1 adequately justified an ipv6 address with a
particular size mask, and then the customer decides to instead purchase
service from ISP 2, why wouldn't ISP 2 give out the same size ipv6 block?

Granted my two stipulations may create some initial pain, but we seemed to
manage it for IPv4, so I suspect we can do the same for ipv6.  There will
of course need to be some debate over the importance of aggregation
versus the importance of efficient use.  But we should be able to come up
with something reasonably balanced.  

___Jason

---

From: Mark Smith <[email-masked]>
Date: Fri, 14 Jul 2006 22:20:58 +0930

On Fri, 14 Jul 2006 00:20:49 -0400 (EDT)

> size IP block, then I fail to see the value of "classful" addresses.

Go to fixed boundary allocations for end-sites, and _nobody_ needs
appropriate tools or processes to validate the sizes of requests from
end-sites. The bits we sacrifice in the IPv6 address space to do this
would be a cheap cost compared to the ongoing and continual costs of
managing variable length assignments to end-sites. If nothing else,
hopefully the RIR annual fees would go down, because they'd have less
work to do :-) Remember, there is at least 3/4 of the IPv6 address
space with nothing at all in it if we really do end up being completely
wrong. We've got plenty of IPv6 address bits to "waste" on addressing
convenience, as long as we don't blow up any route tables along the way.

> service from ISP 2, why wouldn't ISP 2 give out the same size ipv6 block?

It seems to me that if you abstract that process a bit, the logical
conclusion is to just give nearly everybody the same prefix length, and
completely eliminate the administrative costs of the justification and
validation of the request process. Only the people dealing with the
public routing bits of IPv6 addresses have to understand and worry
about variable length prefix style address management.

I've understood the idea behind the /48 allocation was that it was
enough for nearly everybody - only the largest organisations or
entities would need shorter prefixes. This seemed to me to be
simplicity winning out.

I think introducing a second catagory of allocations, namely /56s, for
most smaller networks / homes etc, would address that "excessive"
criticism, yet still meet well enough a simplicity goal. It would still
increase the costs of address management though, as now allowance for,
and therefore pre-planning has to take place to cater for the instances
where the /56 needs to be increased to a /48. I think it is probably a
minimal enough cost to pay to address the "excessive" criticism,
although personally I'd prefer that even that address managment cost
wasn't incurred at all.

However, I think going to variable sized allocations for end-sites is
throwing the baby out with the bathwater. It increases addressing
administration costs, is much harder to understand for most network
administrators, and is much more error prone. I think IPv6 address
space is abundant enough and cheap enough that we can just eliminate
those IPv4-CIDR-style costs in the most common case, namely the very
large majority of end-sites, by just "throwing a bit of address space at
it". 

Regards,
Mark.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 14 Jul 2006 09:54:54 -0400

On 14-jul-2006, at 8:50, Mark Smith wrote:

>> (and everyone has the appropriate tools to handle this)

Actually the SUBNET mask is now pretty much fixed at 64 bits. From  
RFC 3513:

    For all unicast addresses, except those that start with binary value
    000, Interface IDs are required to be 64 bits long and to be
    constructed in Modified EUI-64 format.

I don't think this was the right decision although in practice using  
someone else isn't a good idea as you're going to run into trouble  
with stateless autoconfig, especially the wway things are now, but  
even in some cases if this is changed to accept variable subnet lengths.

But we were not talking about subnet sizes, but rather end-user  
assignment size.

> managing variable length assignments to end-sites.

Right. Having only a very small number of different assignment sizes  
makes life much easier for ISPs, because that way, the blocks are  
interchangeable. If every user gets a tailored prefix size, then ISPs  
will have more trouble recycling address space that comes back when  
uses leave.

Also, regular users don't have any idea how much they need so it's  
better to use a standard size that fits most users and only think  
about a non-standard size for non-standard users.

On the other hand, I do see the point that hardcoding prefix sizes  
especially in standards but also in procedures is likely to come back  
to bite us in the back at some point.

> If nothing else,
> work to do :-)

++ !

> criticism, yet still meet well enough a simplicity goal.

I agree, except that /56 is still too large for small / home  
networks, and I fear that ISPs will want to skimp even more and give  
out /64s. And as I said before, individual /64s aren't all that  
useful in practice.

> administrators, and is much more error prone.

Agree. There is also the issue that DNS reverse mapping delegations  
are easier on 4-bit boundaries, although this isn't a big enough  
issue to be show stopper on its own.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 14 Jul 2006 10:18:54 -0400

>> draft-narten-ipv6-3177bis-48boundary-02.txt

After speaking with Thomas shortly in the hallway yesterday I  
understand that he doesn't feel it's appropriate (anymore) to tell  
the RIRs what prefix sizes to use. I don't necessarily agree with  
that, but in the interest of moving forward I suggest that we try to  
talk about what the IETF is supposed to know about: technical issues.  
When we agree on those the rest should be easy.  :-)

Since the assumption until now has been that pretty much everyone  
would receive a /48, it makes sense to determine whether this is  
something that the addressing technology as we understand it today  
can support. In my opinion, that answer is:

Assuming the 2000::/3 unicast address space and a reasonable HD ratio  
target of 80%, it should be possible to support 2^(80% * 45) = 2^36 =  
68 billion /48s. Based on this, there is no technical reason to deny  
anyone a /48.

Then there are technical considerations for a minimum size  
assignment. Today, most end-users connect one or more hosts in their  
site to the internet through an intermediate device that, amongst  
other functionality, functions as an IPv4 router. It's reasonable to  
assume that this situation translates into a scenario in IPv6 where  
users have a router on their site. This requires at least two  
subnets: one internal to the site, that hosts connect to, and one  
used between the user's and ISP's routers. However, there is no  
requirement that these two subnet prefixes (which should be /64 as  
per relevant specifications such as RFC 3513) come from a single  
shorter prefix assigned to the user. This means that the minimum for  
most users would be a /63 or two /64s.

Next: preferred prefix sizes. DNS reverse delegation happens on 4-bit  
boundaries. It's not easy to draw conclusions from current  
operational experience with the reverse DNS in IPv6, but it's not  
unreasonable to assume that more than with IPv4, with IPv6 users will  
run their own reverse DNS servers. This gives a slight preference  
towards assignments on 4-bit boundaries.

Finally: stable prefix size when changing ISPs. Both for ISPs and end- 
users it's easier if there is only a small number of prefix sizes in  
use. This avoids the situation where a user would receive a smaller  
assignment from a new ISP, making renumbering significantly harder,  
and for ISPs, simplifies reusing address space reclaimed from users  
that have left.

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Sat, 15 Jul 2006 01:49:32 +0200

> than 256 subnets, even if you have only a handful of devices in  

I would be happy if I knew about deployments being cooked  that  
required /64 per user, let alone anything more. I still have a hard  
time imagining what technology will deployed at most sites that  
_require_ separate subnets, but I am trying to be generous and will  
accept that a few might be needed.

- kurtis -

---

From: Mark Smith <[email-masked]>
Date: Sat, 15 Jul 2006 09:32:13 +0930

Hi Iljitsch,

On Fri, 14 Jul 2006 09:54:54 -0400
Iljitsch van Beijnum <[email-masked]> wrote:

> out /64s. 

I'd think the market would sort that out very quickly - if I'm choosing
an ISP for my home, and one gives out /56s, and another gives out a /64
(and then charges more for that /64 because they also are having to
manage the option of providing /56s and /48s), then I'm going to go for
the option that is likely to cause me the least potential
administrative hassle in the future. I think it is inconceivable I'd
every use up 256 subnets at home (and hey, I'm a networking person, so
I'd probably willing to spend time getting around this limitation if I
hit it by going to /80s for my subnets), so the /56 option is more
attractive as I'd never hit it. Even people who don't understand the
technical differences will pursue the /56 option, because people will
always go for more "bangs per buck", even if they're unsure of exactly
what the "bangs" are, as long as somebody tells them more "bangs" are
useful to have even if you don't ever use them.

The /48 option also is provides an "inconceivable" subnet limit. What
it does though, when compared with the /56 option, is pushes that
boundary of inconceivability to be inclusive of almost every potential
IPv6 user out there, elminating the costs of dealing with running out
of subnets for almost everybody. For those who are likely to hit a
subnet limitation with a /48, I'm pretty sure they'll be smart enough to
recognise that from day one, and request the enough address space
they'll need before they need it. 

> And as I said before, individual /64s aren't all that  
> useful in practice.
> 

True. Simplicity in DNS reverse mapping is another benefit of "throwing
addressing bits" at the problem. 

Regards,
Mark.

---

From: "Tony Hain" <[email-masked]>
Date: Sat, 15 Jul 2006 15:58:37 -0700

Kurt Erik Lindqvist wrote:
> ...

You appear to be focused on number of devices. Think different media types.
There is no reason that any new media type should be stuck with 25 year old
framing technology. We get there by default now because multi-media bridging
is known to be broken and to date routing has been too hard. There is
nothing really magic about local routing though so it is reasonable to
conclude that over the 500+ year lifetime we expect for IPv6 that differing
media types will arrive with framing that is better routed than bridged, and
that trivial management of local routing for structured topologies will
appear. 

Tony

---

From: Thierry Ernst <[email-masked]>
Date: Wed, 19 Jul 2006 17:49:50 +0200

Hi,

What about this one: vehicles will not embed one but probably a couple
of IP subnets. One subnet will be used for vehicle-related control
traffic, and another one for multimedia. Once this comes into the
assembly line, such vehicles will come by millions.

I guess the same will happen for home networking, with one segment for
multimedia and one to control windows, light switches, etc.

Thierry

On Sat, 15 Jul 2006 01:49:32 +0200

-- 
Thierry ERNST, PhD
http://www.nautilus6.org/~thierry
IETF NEMO WG Chair, IETF MonAmi6 Chair, Nautilus6 Chair
--
INRIA Rocquencourt Project-Team IMARA, France.
+33 1 39 63 59 30 (office)

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Tue, 25 Jul 2006 08:09:56 +0200

> that trivial management of local routing for structured topologies  

I think that over those 500+ years we might even have solved routing.  
In the mean time even for new encap types you will not see more than  
1-5 networks in a home.

- kurtis -

---

From: Mark Smith <[email-masked]>
Date: Tue, 25 Jul 2006 19:46:11 +0930

Hi Kurtis,

On Tue, 25 Jul 2006 08:09:56 +0200

> In the mean time even for new encap types you will not see more than  

You might be right. OTOH, imagine if your end up being wrong ! Do we
really want to have to go through a subnet renumbering event for the
most likely largest number of networks in the world - all residential
and small businesses, say 5 or 10 years from now ? If we've got enough
IPv6 address space such that we can avoid creating this potential
problem in the future, and we certainly do have enough address space,
then why not future proof the end-site addressing allocations against
this ? The cost of avoiding this problem is virtually nothing.

Along those lines, I'm curious what you (and other people who seem to
be against /48s for end sites) think of the "excessive" 46 bits of
address space that ethernet uses, when the reality is that no more than
12 bits of address space would probably have been plenty for the
even the biggest LAN segments (I've seen one sadly) ? Bare in mind that
that addressing size decision was made around 1980, when even LAN
segments with 4000 devices would have been inconceivable, so even 12
bit addressing at the time would have seemed beyond "excessive".

Regards,
Mark.

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Tue, 25 Jul 2006 19:36:02 +0200

> this ? The cost of avoiding this problem is virtually nothing.

There are two problems here. 1) I am pretty convinced that the IETF  
shouldn't be running address-policy for the ISPs. Especially since  
there are also complexity here that I am not sure we understand (i.e  
RIR -> LIR charging schemes). 2) I am not advocating 5 subnets, nor  
am I in favour of 2^16. I am sure there is a middle ground and that  
we shouldn't carve it in stone.

> bit addressing at the time would have seemed beyond "excessive".

I could probably say a lot about the MAC addresses but this is the  
wrong SDO.

- kurtis -

---

From: Mark Smith <[email-masked]>
Date: Wed, 26 Jul 2006 06:20:00 +0930

Hi Kurtis,

On Tue, 25 Jul 2006 19:36:02 +0200

> On 25 jul 2006, at 12.16, Mark Smith wrote:
<snip>
> RIR -> LIR charging schemes).

I agree with that. RFC3177 seems to be a IESG/IAB recommendation /
Informational RFC. If ISPs / RIRs etc. don't follow the recommendation,
then it's probably useful for the IETF to point out the technical pros
and cons of their decision.

> 2) I am not advocating 5 subnets, nor  

My thoughs are to aim for simplicity and operational convenience.
Giving everybody a /48 would make running IPv6 simple and operationally
convenient for nearly every end-site to be or currently in existance.

> I could probably say a lot about the MAC addresses but this is the  

Fair enough. I was really only trying to prompt thinking about what
simplicity and operational advantages have been gained from using
"excess" address space in ethernet, when that amount of address space
certainly wasn't necessary around 1980, and, based on the address
management tasks people are performing with IPv4 successfully enough
today, wouldn't be necessary now either. Operational and functional
convenience was prioritised over necessity when the ethernet address
size decision was made, and has paid many dividends.

Regards,
Mark.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 25 Jul 2006 23:32:20 +0200

On 25-jul-2006, at 22:50, Mark Smith wrote:

>>> address space that ethernet uses, when the reality is that no more
>>> than 12 bits of address space would probably have been plenty for  
>>> the
>>> even the biggest LAN segments

> certainly wasn't necessary around 1980

Ethernet originally had 16- and 48-bit addresses. The 16-bit  
addresses apparently didn't catch on. The advantage of having a long  
address is that you can burn in a unique address in the factory and  
be done with it. With 16-bit addresses that wouldn't be possible, and  
with 32-bit addresses it would have been difficult given the u/l and  
g bits and the two-level hierarchy.

> and, based on the address
> today,

People thought coal stoves worked well too back in the day. But  
generating the lower bits in the IPv6 address from the MAC address is  
so much more convenient that having to administer IPv4 host addresses  
manually or through complex automation seems like stone age  
technology in comparison.

> wouldn't be necessary now either. Operational and functional

I'm sure that if ethernet addresses had been managed by the RIRs we'd  
have EtherNAT today.  :-)  :-(