On Fri, Oct 19, 2012 at 10:45 AM, Satoru Matsushima <
[email protected]> wrote:
> Hi Zhen,
>
> On 2012/10/19, at 11:16, Zhen Cao wrote:
>
> > My question is why local-mac couldn't solve your problem. As far as I
> > know, any local-mac mode AP needs to encapsulate EAP packet into
> > neither CAPWAP-DATA nor CTL
> >
> > as far as i understand, the local-mac mode will encapsulate the CAPWAP
> message into 802.3 header.
> > +-+wireless frames +-+ 802.3 frames +-+
> > | |----------------| |--------------| |
> > | | | | | |
> > | |----------------| |--------------| |
> > | |wireless PHY/ | | CAPWAP | |
> > | | MAC sublayer | | | |
> > +-+ +-+ +-+
> > STA WTP AC
> >
>
> Thanks, same view on me. The local-mac isn't designed to encapsulate EAP
> packet into CAPWAP-{CTL|DATA} but the split-mac is the mode which
> CAPWAP-DATA deliver the EAP packet.
>
Not actually. EAP is not exempted from the tunnel by RFC5415.
>
> >
> > because AP send messages to AAA server as
> > EAP authenticator.
> >
> > This way, when UE handover between different AP, the security session
> cannot be switched to the new AP.
> >
>
> Well, I understand that what problem you want to solve is keep 802.11i
> security session continuously in UE handover between different APs. If so,
> I may suggest that you can clarify the comparison of solutions in the
> document that local-mac + ERP, which a product of the IETF hokey wg, vs.
> split-mac + EAP encapsulation into CAPWAP-CTL for example.
>
Thanks for the suggestion. Before that I need to clarify another aspect:
now that in the non-EAP authentication WLAN, we already have the AP not
directly interfacing with AAA, for a smooth upgrade, we had better keep
this arch.
>
> cheers,
> --satoru
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
