Re: [dhcwg] IEEE 802.11ai and DHCP

[Hiroki Nakano <[e-mail]>]

Thank you for remembering 802.11ai :)

At the last meeting on IEEE802.11WG in Geneva, July,
TGai finished its internal work for Draft 1.0.
According to this draft, 802.11 will have capability
to convey L3 packets by Association Request/Response frame.
Just in my personal opinion, I think this feature will not
change so much in the future process of 802.11.

I'm trying to fix experimentally DHCPv4 client/server to
support RCO. In addition, DHCP client should start when
WLAN layer decides to connect some BSS and to start
an association process, that is, when the link-up flag
of the interface is still off. Moreover, DHCP client has to
pass the first packet to WLAN layer by 802.11's MLME API
defined in TGai.
DHCP and WLAN layer need close collaboration
and possiblly need discussion for implementation.

And, how about IPv6...?

Regards,

Hiroki Nakano
Trans New Technology, Inc. <[e-mail]>


(13/07/30 3:04), Alexandru Petrescu wrote:
> Any news about IEEE 802.11ai and DHCP?
>
> Has the TGai provided a generic container framework to quickly transfer
> DHCP messages?
>
> Alex
>
> Le 28/03/2013 17:12, Alexandru Petrescu a écrit :
>> Le 26/03/2013 10:09, Jouni Korhonen a écrit :
>>>
>>> I find it quite interesting and slightly surprising IEEE is
>>> working on this. In cellular space (3gpp) we have had about
>>> equivalent mechanism at the NAS protocol layer from the beginning.
>>
>> I tend to agree.
>>
>> For example, there is this link-layer RANAP protocol.  In this, the
>> UserEquipment sends a "Activate PDP Context Request" with a "DNS
>> Server IPv6 Address Request", and receives the IPv6 address of the
>> DNS Server in a "Activate PDP Context Accept".
>>
>> This link-layer messaging is redundant with two other IP protocols:
>> (1) Router Advertisement sending the DNS IPv6 address (RFC61606 "IPv6
>> Router Advertisement Options for DNS Configuration") _and_ with (2)
>> DHCPv6 configuration options containing the address of the DNS
>> server.
>>
>>> It works but has always been a bit of headache, since multiple
>>> ways to do the same thing with loads of optional features on
>>> different layers caused nasty implementation/deployment challenges.
>>> I hope IEEE does this better now that they are doing it ;)
>>
>> I think that _if_ at IETF there were such protocol to realize this
>> fast configuration in the same way that IEEE needs for crowded
>> hotspot then one could suggest it to IEEE.
>>
>> Alex
>>
>>>
>>> - Jouni
>>>
>>>
>>> On Feb 12, 2013, at 10:25 PM, Hiroki Nakano <[e-mail]>
>>> wrote:
>>>
>>>> Dear all,
>>>>
>>>> I'm participating in IEEE 802.11 WG TGai task group which is for
>>>> FILS (Fast Initiali Link Setup). They are working for speeding
>>>> up of 802.11 process and trying to provide a new framework for
>>>> higher layer protocols.
>>>>
>>>> I'd like to introduce the overview of prospective 802.11ai
>>>> specification and discuss usages of DHCP on it with DHC WG
>>>> people in March. The followings are a brief introduction.
>>>>
>>>> TGai supposes Wireless LAN is used in very crowded envirionment
>>>> such as railway stations in a giant metropolis. TGai also
>>>> supposes moving hosts through the front of Access Points. In
>>>> these cases, it is effective to reduce management frames of
>>>> 802.11, especially frames for probing APs, authentication and
>>>> association. The current framework takes a few seconds to set up
>>>> network connectivity before starting to communicate. The target
>>>> of TGai is under one second.
>>>>
>>>> TGai is trying to reduce management frames of 802.11 itself, and
>>>> in addition provide framework for higher layers such as IP to
>>>> send and receive packets during 802.11 association process. The
>>>> currently proposed framework provides "ONE round-trip packet
>>>> exchange" by piggybacking on 802.11 Association Request/Response
>>>> frames.
>>>>
>>>> My interest is how to fit DHCP to this framework. In case of
>>>> DHCPv4, this is achieved by using Rapid Commit Option (RFC4039)
>>>> and making some additional and trivial rules. In case of DHCPv6,
>>>> we have to use both RA and DHCPv6. In addition, DAD and randomly
>>>> generated addresses have to be considered. Share your idea,
>>>> please.
>>>>
>>>> 802.11 TGai is still going on and its specification is subject
>>>> to change, but I'd like to discuss in IETF DHCP issues related
>>>> to 802.11ai and arrange I-D according to the progress of TGai
>>>> task group.
>>>>
>>>> Regards,
>>>>
>>>> Hiroki Nakano Trans New Technology, Inc. <[e-mail]>
>>>>
>>>> _______________________________________________ dhcwg mailing
>>>> list [e-mail] https://www.ietf.org/mailman/listinfo/dhcwg
>>>
>>> _______________________________________________ dhcwg mailing list
>>> [e-mail] https://www.ietf.org/mailman/listinfo/dhcwg
>>>
>>>
>>
>>
>>
>> _______________________________________________ dhcwg mailing list
>> [e-mail] https://www.ietf.org/mailman/listinfo/dhcwg
>>
>
> _______________________________________________
> dhcwg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dhcwg