Re: [sig-policy] prop-087: IPv6 address allocation fordeployment purpose
Then the question may be 'how many is too many?'
Regards
Terence
----- Original Message -----
From: "Naresh" <ajwaninaresh at gmail dot com>
To: "'Terence Zhang YH'" <zhangyinghao at cnnic dot cn>; "'Tomohiro -INSTALLER- "Fujisaki/藤崎 智宏"'" <fujisaki at syce dot net>
Cc: <pfs at cisco dot com>; <sig-policy at lists dot apnic dot net>
Sent: Tuesday, August 17, 2010 2:57 PM
Subject: RE: [sig-policy] prop-087: IPv6 address allocation fordeployment purposes
> Too many Technology complexities may deter the objective.
>
> Regards
>
> -----Original Message-----
> From: sig-policy-bounces at lists dot apnic dot net
> [mailto:sig-policy-bounces at lists dot apnic dot net] On Behalf Of Terence Zhang YH
> Sent: Tuesday, August 17, 2010 8:54 AM
> To: Tomohiro -INSTALLER- "Fujisaki/藤崎 智宏"
> Cc: pfs at cisco dot com; sig-policy at lists dot apnic dot net
> Subject: Re: [sig-policy] prop-087: IPv6 address allocation fordeployment
> purposes
>
> Hi, Tomohiro,
>
> I am not talking about renumbering,
> I am talking about adding additional 10/8 addresses when you deploy/upgrade
> 6RD CE,
> so 6RD tunnels are using 10/8 addresses and normal IPv4 services are
> still using the oringinal IPv4 addresses, is this a viable solution?
>
> Another option, keep the non-aggregatable address blocks in
> separate 6RD domains, then aggregate and encode
> less bits in each domain. Is this a viable solution?
>
> Regards
>
> Terence Zhang
>
>
> ----- Original Message -----
> From: "Tomohiro -INSTALLER- "Fujisaki/藤崎 智宏"" <fujisaki at syce dot net>
> To: <zhangyinghao at cnnic dot cn>
> Cc: <pfs at cisco dot com>; <sig-policy at lists dot apnic dot net>
> Sent: Tuesday, August 17, 2010 11:04 AM
> Subject: Re: [sig-policy] prop-087: IPv6 address allocation fordeployment
> purposes
>
>
>>
>> Hi Terence,
>>
>> 6rd is just a technology to establish automatic tunnels between users
>> (6rd CPEs at user site) and 6rd relays in an ISP. So if ISPs can
>> renumber their IPv4 users to use 10.0.0.0/8 and LSN, it will be
>> possible to encode 24 bits or smaller bits in a IPv6 header, as you
>> say. In this case, you can use /32 or longer IPv6 address prefix to
>> deploy 6rd.
>>
>> I suppose ISPs who try to implement 6rd will not want to change their
>> IPv4 addressing.
>>
>>
>> Yours Sincerely,
>> --
>> Tomohiro Fujisaki
>>
>> From: "Terence Zhang YH" <zhangyinghao at cnnic dot cn>
>> Subject: Re: [sig-policy] prop-087: IPv6 address allocation fordeployment
> purposes
>> Date: Tue, 17 Aug 2010 10:35:42 +0800
>>
>> | Hi, All,
>> |
>> | If I understand correctly, 6RD have multiple technique to avoid
>> | ecoding the whole 32-bit IPv4 addresses even if there are
>> | non-aggregatable blocks.
>> |
>> | Such as, using private 10/8 addresses in addition to public IP
> addresses
>> | (kind of dual IPv4 addresses), so only 24-bit need to be
>> | encoded in, or using multiple 6RD domain, so they can aggregate
>> | within each domain, like if a ISP have non-adjacent 3 */16, they
>> | can have 3*6RD domain, and encode only 16-bit. In that way,
>> | they are not neccesarily need longer prefix.
>> |
>> | Is my understanding correct?
>> |
>> | I believe another /32 block is needed for 6RD deployment,
>> | but I think there should be more details about how to evaluate.
>> |
>> | Regards
>> |
>> | Terence Zhang
>> | CNNIC
>> |
>> |
>> | ----- Original Message -----
>> | From: "Tomohiro -INSTALLER-"Fujisaki/藤崎 智宏"" <fujisaki at syce dot net>
>> | To: <pfs at cisco dot com>
>> | Cc: <sig-policy at lists dot apnic dot net>
>> | Sent: Tuesday, August 17, 2010 9:54 AM
>> | Subject: Re: [sig-policy] prop-087: IPv6 address allocation
> fordeployment purposes
>> |
>> |
>> | >
>> | > Hi Philip,
>> | >
>> | > Thank you for your reply.
>> | >
>> | > | > ----------------------------------
>> | > | >
>> | > | > Current IPv6 address allocation policy is basically based on
> number of
>> | > | > subscribers the applicant will have [1], but this does not allow
>> | > | > sufficient allocation size to adequately deploy some IPv6
>> | > | > protocols. For example, the "6rd" protocol needs more than /32 to
>> | > | > implement adequately in an ISP network due to technical reasons
>> | > | > [2].
>> | > |
>> | > | Reference [2] does not say that 6rd needs more than a /32 for
>> | > | implementation.
>> | > |
>> | > | It says that it needs more than a /32 should the ISP want to encode
> the
>> | > | entire IPv4 address the customer uses.
>> | > |
>> | > | How many ISPs use the entire IPv4 address space for their customer
>> | > | public address space?
>> | > |
>> | > | I think the answer is none. ;-)
>> | >
>> | > I'm sorry if I misunderstand your comment, but the problem is not
>> | > number of addresses but prefixes of the addresses.
>> | >
>> | > If ISPs use a same address prefix for all users, it is possible to
>> | > shorten the encoded prefix. I'm not sure how many ISPs request and get
>> | > additional address blocks under same IPv4 address prefixes, but I
>> | > suppose there are not so many ISPs that use a single prefix for all
>> | > of their customers.
>> | >
>> | > | So using 6rd as a justification for getting more than a /32 seems
> rather
>> | > | surprising to me.
>> | > |
>> | > | Perhaps the proposal would benefit from an explanation as to why
>> | > | (technically and operationally) the entire IPv4 address needs to be
>> | > | encoded, rather than, say the final 16 bits which would still give
> the
>> | > | end user an entire /48 to play with. Even an ISP who uses an IPv4 /8
> for
>> | > | customer facing addresses can still give each customer a /56. And
> even
>> | > | if they had an IPv4 /8, they could in theory use that to justify /24
>> | > | worth of IPv6 address space - which would then let them encode the
>> | > | entire IPv4 address for 6rd to give each customer a /56 - or the
> final
>> | > | 24 bits to give the customer a /48. Etc.
>> | >
>> | > OK, I'll try to explain this point in my proposed text or presentation
>> | > materials.
>> | >
>> | > One request to APNIC Secretariat, could you show the allocation
>> | > statistics that how many IPv4 address holders obtain addinional
>> | > address blocks, and if possible, how may multiple IPv4 address block
>> | > holders above got same IPv4 address prefixes? (e.g. initial address is
>> | > 1.0.0.0/22 and additonal address is also under 1.0.0.0/8)
>> | >
>> | >
>> | > Yours Sincerely,
>> | > --
>> | > Tomohiro Fujisaki
>> | > * sig-policy: APNIC SIG on resource management policy
> *
>> | > _______________________________________________
>> | > sig-policy mailing list
>> | > sig-policy at lists dot apnic dot net
>> | > http://mailman.apnic.net/mailman/listinfo/sig-policy
>> | * sig-policy: APNIC SIG on resource management policy
> *
>> | _______________________________________________
>> | sig-policy mailing list
>> | sig-policy at lists dot apnic dot net
>> | http://mailman.apnic.net/mailman/listinfo/sig-policy
>> |
>> |
> * sig-policy: APNIC SIG on resource management policy
> *
> _______________________________________________
> sig-policy mailing list
> sig-policy at lists dot apnic dot net
> http://mailman.apnic.net/mailman/listinfo/sig-policy