Subject: [dhcwg] IEEE 802.11ai and DHCP

From: Hiroki Nakano <[email-masked]>
Date: Wed, 13 Feb 2013 05:25:28 +0900

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]>

---

From: Ted Lemon <[email-masked]>
Date: Tue, 12 Feb 2013 20:39:11 +0000

Interesting.   Is the situation that you are switching from one access point to another within a single wifi fabric, or are you just trying to get rapid acquisition of the wifi network when you arrive for the first time?

---

From: Hiroki Nakano <[email-masked]>
Date: Wed, 13 Feb 2013 12:49:51 +0900

13/02/13 5:39), Ted Lemon wrote:
> Interesting.   Is the situation that you are switching from one
> access point to another within a single wifi fabric, or are you
> just trying to get rapid acquisition of the wifi network when
> you arrive for the first time?

Thank you for your attention.

Officially, the later one is the target of TGai. TGai is called FILS
(Fast Initial Link Setup.) The 802.11 has 11r for quick roaming within
a single 802 network. In case of APs not configuring for 802 roaming,
all stations arrived are treated as 'the first time', that is,
'initial link setup.'

In the viewpoint of clients, the former case is possible and you may
need more supports from higher layers like MobileIP, SCTP, HTTP
cookies, etc in order to survive your session. I hope we also talk
together about this topic somewhere in IETF:)

Regards,

Hiroki Nakano

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 13 Feb 2013 13:23:15 +0100

Le 12/02/2013 21:25, Hiroki Nakano a écrit :
> 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.

For DHCPv6 - it is possible to use a DHCPv6 single roundtrip to realize
complete configuration to the Client (IPv6 address, default route, DNS
resolver address).

The straightforward means to achieve complete configuration is to use RA
_and_ DHCP (because only RA provides the default route), for a total of
6 messages .

But the better means (single DHCPv6 roundtrip - 2 messages) is to use
DHCPv6 to configure the default route as well, and not use RA:
draft-ietf-mif-dhcpv6-route-option-05 "DHCPv6 Route Options" and
draft-mouton-mif-dhcpv6-drlo-02.txt "Default Router List Option for
DHCPv6 (DRLO)"

Alternatively, use RS/RA single exchange (and not DHCPv6), with DNS
resolver address:
RFC6106 "IPv6 Router Advertisement Options for DNS Configuration"

DAD and MLD are two other protocols which may get in the way to fast
exchanges.  They could be avoided with proper tweaking of specification
and implementation.

> 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.

I think it is indeed a good point to discuss such an I-D.

Alex

>
> Regards,
>
> Hiroki Nakano Trans New Technology, Inc. <[email-masked]>
>
> _______________________________________________ dhcwg mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/dhcwg
>
>