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

Hi Kosuke,

El 18/07/2005, a las 15:12, Kosuke Ito escribió:

> 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?
>
well, i guess that these are two different issues:
- on one hand, the size of end-sites assigments, which seems to be one  
of the main focus of the discussion here (to move it from /48 to /56)
- on the other hand, whether this change, would imply a change in the  
minimum allocation to lirs

IMHO, i am much more concerned with the first point than with the  
second point. I mean, i can live with the /32, but i am worried about  
the /48
(Besides, probably changing the /48 would also impact in the size of  
bigger allocations (i.e. prefix shorter than 32 bots) since now each  
site won't account for a /48)

> 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


How does the router obtains the /48? is this automatic? does it uses  
DHCP prefix option?

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

AFAIU, so far the proposal is to have two prefix lengths /48 for big  
end sites and /56 for smaller sites. I am not sure how much more  
complexity this would add...
I mean, automatic prefix delegation using dhcp prefix option would  
support this transparently.


> Who pay this price?
>

obviously this an increased cost (there ain't no such thing as a free  
lunch) But quite a few bits are not wasted so, i would need very good  
reasons or very high costs (whatever you want to see it) not to support  
this proposal. I so far, i am far from convinced that the costs  
involved in the support of this policy are high, but i am open to be  
convinced otherwise

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

i will forward this question to lacnic people

regards, marcelo


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