Re: [sig-policy] prop-087: IPv6 address allocation fordeployment purpose
Hi Terence,
Thank you so much for your prompt reply!
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 11:24:15 +0800
| 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?
Oh, I see. Please correct me if I misunderstood your comment.
You mean ISPs assign another IPv4 address (10/8) to users, and route
10/8 in their network. I think if it might be a solution, but current
CPEs cannot handle multiple IPv4 address well (e.g. address
configuration, address selection, etc), and ISPs will not want to
route 10/8 in their network.
Of course it might be possible to develop new CPEs which can handle
these cases, but I personally think in such a case, it will be better
to deploy IPv4/IPv6 dual stack network.
| 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?
In this case, multiple 6rd relays and per-domain user configuration
will be necessary. One benefit of 6rd is that 6rd relay is totally
stateless and possible to use IPv4 anycast address for its tunnel
end point address. This configuration weaken this advantage.
| Regards
|
| Terence Zhang
Yours Sincerely,
--
Tomohiro Fujisaki
|
|
| ----- 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
| > |
| > |
|
|