Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe

[Qiong <[e-mail]>]

Hi Ole,

Please see inline ~~


On Sat, Dec 1, 2012 at 8:11 PM, Ole Trøan <[e-mail]> 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/ *
===============================================