Re: [dhcwg] IEEE 802.11ai and DHCP

[Alexandru Petrescu <[e-mail]>]

Le 30/07/2013 07:12, Hiroki Nakano a écrit :
> 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...?

Thanks for the report from IEEE TGai and for the question.

IPv6 still needs both DHCP and SLAAC to realize complete
autoconfiguration for a Mobile Router (address/plen, prefix, default route).

I am interested in these aspects from a vehicular perspective: a vehicle
equipped with a Mobile Router connecting to other vehicles, or to ITS
infrastructure, all with 802.11p.

In 802.11p there is no 802.11 Associate Req/Resp, but there is a need
for IPv6 and fast auto-configuration there as well.

Some layers above 80211 but below IP (WAVE, ETSI ITS) do offer some
messages that could be used to shorten IP autoconfiguration time.

Alex

>
> 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
> _______________________________________________ dhcwg mailing list
> [e-mail] https://www.ietf.org/mailman/listinfo/dhcwg