Re: [sig-policy] prop-087: IPv6 address allocation fordeployment purpose
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
> |