Hi Ole, Please see inline ~~
On Sat, Dec 1, 2012 at 8:11 PM, Ole Trøan <[email protected]> wrote: > Qiong, > > [...] > > > MAP could also create its tunnel endpoint address from the WAN prefix > (not address). > > so you'd have, for CPE tunnel end point address: > > Thanks for clarification. But if MAP uses the WAN prefix as its tunnel > endpoint address, does BR need to keep all the records for CPEs (because > the CPE's WAN prefix might be arbitary) ? Or do you mean the CPE's WAN > prefix will be embedded with EA bits ? Would you please explain it a bit > more ? > > from MAP's perspective it doesn't matter if it is a /64 on the WAN or a > /56 delegated prefix. > any prefix can have EA bits. > [Qiong] In theory, right. But I think it still have several issues here: 1) The /64 WAN prefix or a /56 delegated prefix does not have a flag saying "hey, I'm the one with EA bits". Then, how can a CPE choose which prefix to extract the EA bits ? Or do you need another configuration flag to indicate which prefix to embed to EA bits? 2) Some operators have adpoted stateful DHCPv6 on the WAN interface. In that case, multiple CPEs can be within the same /64 prefix in the WAN side with different last 64 bits. However, if EA bits is embedded in the WAN prefix, it will have extra impact on operators' addressing model, consuming more address. And also it seems difficult to configure non-contiguous addresses in DHCPv6 server for stateful dhcpv6 mode(configure a lot of pools with different /64 prefix?). And if I remember correctly, when dIVI-pd came out, it said clearly that it was designed for delegated prefix. I thought it was the original intension of current stateless solutions (please correct me if I'm wrong). And I do suggest to simplify the implementation, rather than leaving too much flexibility and increase the complexity. > > > 1) arbitrary IPv6 address (DS-lite) > > Why it is arbitary ? Is it the source address of the tunnel endpoint ? > > in DS-lite the tunnel concentrator learns the tunnel endpoint address when > the NAT bindings are created. > so the CPE is free to pick whatever IPv6 address it has. this is different > from Public 4over6 and LW46 [Qiong] In theory, right. But still, I have a few comments on it: 1) In DS-Lite, the operator may apply source address filtering for security consideration. Currently, we are applying the acl using WAN address. The arbitrary IPv6 address may lead this address filtering fail. 2) Even in DS-Lite, operators may adopt bulk port allocation for each subscriber (each subscriber will be reserved a port-set in AFTR when the first packet creates the NAT binding). If the CPE arbitrary chooses different IPv6 address, this port-set reservation can not work neither... 3) Current DS-Lite CPEs all choose the WAN address as the tunnel endpoint, which is simple and easy to manage. where the > address has to be configured on both ends. > [Qiong] Lw4o6 and public 4over6 can also use arbitary address if the lwAFTR does not do source address filtering/validation . The upstream packet only needs be decapsulated and the downstream packet can find the matching tunnel endpoint address using public v4 address and port. But still, for management and security reasons, I still suggest to use the WAN address as the tunnel endpoint address. Best wishes Qiong > > cheers, > Ole -- ============================================== Qiong Sun China Telecom Beijing Research Institude Open source code: lightweight 4over6: *http://sourceforge.net/projects/laft6/* PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/ * ===============================================
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
