Hi Thomas,
I totally agree with your appreciations.
May be one possibility to ensure that this is going to work also with
the
RIRs is to hold this document until the RIRs policy changes align to
it, and
work pro-actively with them in order to make that happening ASAP ?
I will suggest a small change to this text (section 2):
"... While that number may
make sense for larger sites, it is hard to imagine a typical home
user requiring so much space. Indeed, the default end site assignment
today is in practice the same for home users and larger businesses."
For something such as:
"... While that number may
make sense for larger sites, it is hard to imagine, at the time being, a
typical home user requiring so much space, but this can change and we
must
be ready and open to that. Indeed, the default end site assignment
today is
in practice the same for home users and large businesses.
Moreover, the change in the recommended assignment (from /48 to /56)
should
not become a barrier for any customer to get a /48 from the ISP,
whenever
the ISP is required for that, with no need for further justifications
for
that request."
One open question is if this change will impact in the default
allocation of
/32 to the LIRs. I mean, should they still keep considering that the
customers will be able to request a /48 and consequently keep
allocating the
big prefixes that we have seen until now ? If not, should the big
prefixes
already allocated be claimed back ? Yes, I know is a RIR business, but I
think otherwise we clarify it ASAP, it can create a lot of unfairness
in the
process with future allocations.
Moreover, it will be a good suggestion for ISPs to block the
remaining /56
up to the /48 for each customer, in case he ask for it, in order to
avoid
renumbering ? If that's the case, there is any meaning for this change
towards the conservation ?.
Note that there is already some people proposing that the business
model for
IPv6 is precisely charging for the addresses, which I believe is totally
broken and a wrong approach. The business will come because there are
new
services and applications, for which the ISPs will be able to charge,
either
because the service itself or the BW required by the service, or a
combination of both. This will not happen if the addresses aren't
available
for free (the applications will never come in that case, and we will
end-up
with a NATv6 model). Also some ISPs in AP are already providing only
a /64
and charging for a different "service class" if the customer ask for
several
subnets.
Regards,
Jordi
(note: I've copied the globa-v6 list as suggested in previous emails
from
Thomas)
De: Thomas Narten <[EMAIL PROTECTED]>
Responder a: <[EMAIL PROTECTED]>
Fecha: Thu, 14 Jul 2005 10:11:19 +0200
Para: <[EMAIL PROTECTED]>
CC: "ipv6@ietf.org" <ipv6@ietf.org>
Asunto: Re: I-D ACTION:draft-narten-ipv6-3177bis-48boundary-00.txt
Hi Jordi.
I've read yesterday this document, and I'm basically ok with it,
but with
two considerations that I think must be worked out it parallel
somehow:
1) HD-Ratio modification, as it seems to be an integral part of the
discussion.
IMO, changing the HD-ratio is a no-brainer, and I suspect that many
people feel the same way. It's an easy change to make and has minimal
impact. Indeed, there is already an ARIN proposal to do this:
http://www.arin.net/policy/proposals/2005_5.html
So yes, I expect this will be done and will personally push to see
this happen.
2) I've the feeling that if we suggest the ISPs to move to a /56,
they will
then charge the customers (SOHO, end-users) or create to them a lot of
troubles to get a bigger prefix when this is needed.
We should be careful NOT to assume that just because something is done
one way in IPv4, it will be similar in IPv6.
Indeed, I think one of the big cultural changes w.r.t. IPv6 is the
notion that end sites get subnets (emphasis on plural) where this is
clearly NOT the norm for IPv4 today. My sense is (from talking to folk
in the RIR community) is that they all believe this, and that ISPs
working with IPv6 also get this. So I think we've already changed the
starting point here.
Also, in IPv4, the existing practice is to give out a single
address. There are multiple reasons for this, some cultural (i.e.,
status quo). But another point that I think people sometimes forget is
that the existing protocols and busines practices have been built
around giving out a single address (rather than a subnet) and such,
getting a subnet is, in fact, an exception to the norm. As we know,
exceptions can cost more, i.e., in terms of help desk support, etc.
So even though ISPs in IPv4 do tend to charge more for "more than one
address", the reasons for that are a bit subtle, and when they say its
because "more address just cost more", that is really just FUD. In no
case can the case be made that it is because the extra addresses
actually "cost more", i.e., in terms of RIR policies.
Again, my sense in the RIR regions is that folk want the RIR policies
to be very clear that addresses should be available to end sites at
very low cost (i.e., essentially free), and that the cost of a /48
should be the same as a /56 or /64. And with DHCPv6 prefix delegation
(as the protocol/operational mechanism for achieving this) I think we
are on track to see the right thing happen.
To ensure that happens, the RIR policies will need to be sure that
when LIRs need more space from RIRs, the justification should be
based entirely on whether the existing space is sufficiently utilized
(based on the HD-ratio) with the metric being completely neutral as to
whether end sites are getting /48s or /56s.
My feeling is that today we believe that 8 bits for subnetting is
enough, but I think will not be the case soon and this barrier will
then be again a stopper for enabling innovation.
I think there is a general feeling in the RIR community that folks
that ask for more than a /56 should generally get it more-or-less by
asking. I'd welcome help in how to word this. What we don't want is
folk automatically asking for a /48 "just because they can". In
practice, a /56 will really be enough for a large percentage of end
sites, for a long while. Hence, the current "justification" for space
is probably best expressed in terms of size of a site in terms of
subnets. That is something objectively measurable and captures the
sense of whether additional space is really needed.
I know this one is somehow not an IETF business, but we must be
worried about that and may be collectively work for the appropriate
solution in the appropriate fora.
We simply need to pay attention to what is going on in the RIR
community, and followup as appropriate. The good news is that my own
sense (from going to ARIN meetings for 3 years or so, and attending
the last RIPE meeting) is that the community there largely shares the
same goals as I'm hearing here. They do understand that IPv6 is
different than IPv4 and that we need to focus less on conservation
than IPv4. I think that most of the community is actually quite happy
about this.
The cost of managing addresses is not a recurrent cost. I mean, it
will be
ok to charge for a reasonable setup fee if somebody ask for a /48
instead of
a /56, but charging 12Euros (or even more) per month per address as
some
telcos do in EU is a crime.
No. I think there is no justification (in increased $$) for a /48
vs. a /56. The RIR policies should be clear about that. That won't
prevent ISPs from (perhaps) doing this, but they will use weaker
arguments like "a /48 implies more traffic and therefore more $$". But
then again maybe not. In practice, with a /56, end sites can generate
plenty of traffic and ISP charges may end up having to switch to
something based on actual traffice being carried.
Thomas
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
************************************
The IPv6 Portal: http://www.ipv6tf.org
Barcelona 2005 Global IPv6 Summit
Information available at:
http://www.ipv6-es.com
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.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------