Subject: Re: [dhcwg] IEEE 802.11ai and DHCP

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 29 Jul 2013 20:04:31 +0200

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

---

From: Hiroki Nakano <[email-masked]>
Date: Tue, 30 Jul 2013 14:12:47 +0900

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. <[email-masked]>

(13/07/30 3:04), Alexandru Petrescu wrote:
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 30 Jul 2013 11:14:18 +0200

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

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

>> Has the TGai provided a generic container framework to quickly
>> transfer DHCP messages?
>>
>> Alex
>>
>>> 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.
>>>
>>>> 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
>>>>
>>>>
>>>>> 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.
>>>>>
>>>>> 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.
>>>>>
>>>>>  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,
>>>>>
>>>>> list [email-masked]
>>>> list [email-masked]

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 30 Jul 2013 20:06:21 +0900

> autoconfiguration for a Mobile Router (address/plen, prefix, default

Liaison statements (according to BCP103) from IEEE could resolve
the problem for IETF not admitting DHCP perform full configuration
without RA.

Or, IPv6 won't be efficiently supported by 11ai, which might help
IPv6 fundamentalists recognize the reality that SLAAC, which is
full of states in the worst way to have them distributed, is rather
harmful than useless.

						Masataka Ohta