Re: Re: I-D ACTION:draft-narten-ipv6-3177bis-48boundary-00.txt

marcelo bagnulo braun wrote:

> Hi,
> 
> El 14/07/2005, a las 16:43, Kosuke Ito escribió:
> 
>>
> 
>> Do we like to creat SWAMP already?
>>
> 
> i fail to understand why this change would create swamp? could you 
> expand on this?

I just extend my imagination that we may be about stepping
into the same mistake we made for IPv4, such as network
management nightmare of managing sider space, longer prefix
allocation, etc. which swell ISPs management cost.
But maybe, the minimum initial allocation of /32 would not be
changed, wouldn't it?
Then, my SWAMP statement made before would not be the case.

>>
>> Regarding the assignment size, when we held JP Open Policy
>> Meeting last week, there are many voices saying that
>> varying assignment size is too much impact on the current
>> commercial service not in its network operation but also
>> for the low-cost routing devices handling /48.
>>
> 
> why would this have such impact on devices? do they have the /48 
> hardcoded? could you expand on this point?

Many of home routers sold in Japan is designed and build
to associate with an ISP's service operational scheme.
Currently, a home router receiving /48 from the ISP block
and assigned a /64 out of it automatically ( and manually
done by the user if necessary).

>> According to them, they have already been in service,
>> so they consider that it is not practical to change the
>> assignment policy.
> 
> 
> I guess it is easier if all users get a /48 indeed, but how much effort 
> is required to determine the proper prefix for each costumer? is there 
> any additional operational cost that you could let us know?

If the assignment size gets various, more overhead functionality
needs to be implemented into the home router to set the appropriate
assignemnt size user by user, and/or ISP needs to decide its size
user by user (since the size of assignment under /48 is determined
by ISPs).
Who pay this price?

> 
>> Is it practical to change in other regions?
>>
> 
> We had a discussion about IPv6 address management in the LACNIC VIII 
> meeting in Lima (30 of june 2005) and my reading of the comments of the 
> meeting is that they are pretty much in line with the considerations 
> expressed by Thomas in his drafts.

Thank you.
How many acctual/commercial assignments have been made (or
registered) in LACNIC area?

Kosuke

> Regards, marcelo
> 
> 
>> I believe that we can avoid any change in the policy
>> if we look back the goals and refrain from asking as
>> large allocation size and large assignment size as
>> possible just because they can.
>>
>> Nevertheless, if we keep the current pace of allocation,
>> one extrapolation study said that IPv6 might be allocated
>> 50% in 60 years in the worst(?) case.
>> Seems to me, lasting 120 years of IPv6 is long enough,
>> isn't it??
>>
>> Kosuke
>>
>>
>> JORDI PALET MARTINEZ wrote:
>>
>>> 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 <narten-r/[email protected]>
>>>> Responder a: <[email protected]>
>>>> Fecha: Thu, 14 Jul 2005 10:11:19 +0200
>>>> Para: <[email protected]>
>>>> CC: "[email protected]" <[email protected]>
>>>> 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
>>>> [email protected]
>>>> 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
>>> [email protected]
>>> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
>>> --------------------------------------------------------------------
>>
>>
>>
>> -- 
>> **********IPv6 Internet Wonderland!************
>> Kosuke Ito, Master Planning and Steering Group
>> IPv6 Promotion Council of Japan
>> (Visiting Researcher, SFC Lab. KEIO University)
>> Tel:+81-3-5209-4588  Fax:+81-3-3255-9955
>> Cell:+81-90-4605-4581
>> mailto: [email protected]   http://www.v6pc.jp/
>> Lifetime e-mail: [email protected]
>>
>> _______________________________________________
>> global-v6 mailing list
>> [email protected]
>> http://mailman.apnic.net/mailman/listinfo/global-v6
>>
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email protected]
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 
> 


-- 
**********IPv6 Internet Wonderland!************
Kosuke Ito, Master Planning and Steering Group
IPv6 Promotion Council of Japan
(Visiting Researcher, SFC Lab. KEIO University)
Tel:+81-3-5209-4588  Fax:+81-3-3255-9955
Cell:+81-90-4605-4581
mailto: [email protected]   http://www.v6pc.jp/
Lifetime e-mail: [email protected]

_______________________________________________
global-v6 mailing list
[email protected]
http://mailman.apnic.net/mailman/listinfo/global-v6