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

From: Hiroki Nakano <[email-masked]>
Date: Thu, 14 Mar 2013 03:18:19 +0900

I talked with Volz and Tomek yesterday and we also agree
that DHCPv4 with Rapid Commit Option has no problem
for IPv4 configuration by one round trip exchange of packets.
DHCPv6 has a little missing part related to default route,
but another idea using RS and RA solves this as Alex mentioned.
Other potential problems are DAD and M-flag of RA, but we have
Optimistic DAD mechanism and Volz pointed out that DHCPv6 could
be used without RA.  However, I recognize that dhcpv6-route-option
has some difficulty to reach a consensus in IETF.

Bacause 802.11ai is just one of "specific link layer",
I'm not sure this working group is suitable for discussion
about implementation issues related to DHCPv4 and 802.11ai,
(at least, not for RS and RA...)
but if anyone having interests in this topic, I'd like to
talk about this topic after the dhcwg session informally
and please let me hear your comments.
Especially, I am wondering who decides detailed use of DHCPv4 on
802.11ai, IEEE people or IETF people? and who should write
specification for it as an 802.11 document or as a RFC?
if you are writing I-D for this topic, which working group
will you submit to? dhc? 6man? v6ops??, etc...
Of course, technical topics are welcome.

Regards,

Hiroki Nakano
Trans New Technology, Inc. <[email-masked]>

(13/02/13 21:23), Alexandru Petrescu wrote:
> 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
>>
>>
>
>
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 13 Mar 2013 18:25:05 +0000

There may also be some areas to explore further - such as what happens if there are multiple DHCP servers or if Rapid Commit is not allowed and how that plays into this. But it likely is just a minor issue as the first response may be optimized but additional are forwarded to client normally,

- Bernie

---

From: Hiroki Nakano <[email-masked]>
Date: Thu, 14 Mar 2013 04:36:25 +0900

Sure.
It is important that we have the new optimized sequence
applicable to most cases and the other cases work
as well as what we currently have.  It can make us happy.
Nobody will oppose this basic idea.
The problem is, when, where and who agree and write down
the details of combination and implemenation of protocols.

Regards,

Hiroki Nakano

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 13 Mar 2013 21:00:25 +0000

My 2 cents (hat off as co-chair) is this is an IEEE effort - using existing standards.

IEEE has lots of standards. Isn't that why there is IEEE 802.11ai standard committee?

We (dhc, ietf) also aren't involved in all of the issues and alternatives so it would hardly be fair to ask us to do this.

I don't think anyone sees issues with what you intend to do as you are just altering how packets transit the network (encapsulating) and perhaps tweaking when things occur (as you want dhcp to start earlier than it would otherwise - before link is "up" - and that might be more of an issue for device vendors as it may require changes in dhcp client implementations).

But it should work even if that isn't done as DHCP would just happen a bit later and you would lose some of the 11ai improvements.

You are certainly free to write a draft - most drafts start out as individual submissions. And take it to a few people to figure out if it is really needed and if so where it may best be placed.

- Bernie

---

From: Hiroki Nakano <[email-masked]>
Date: Thu, 14 Mar 2013 23:45:26 +0900

Barnie, thank you for your opinion.

I understand protocols generally want to stay independent
from their adjacent layers, while someone have to make
glue between layers to build up the whole system.
The old days, IP people made glue by theirselves in order
to use IP on various link layers.  Today, IP is the winner.
Other protocols else want to have relation with IP and
make glue between them and IP in the outside of IETF.
My concern is that bad glues undermine the heart of IP
little by little and I believe IETF is the only group
who can prevent it.

Anyway, we are competing right now in 802.11WG TGai.
I am supporting an DHCP-based protocol for IP address
assignment and against an 802.11ai original protocol.
Please help me if you agree with me.
I can provide more information if you have interest.

Regards,

Hiroki Nakano

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 14 Mar 2013 14:56:01 +0000

It would be bad news if DHCP is abandoned - there is no disagreement there. DHCP is also important to configure more than just the address (and these are critical for complete connectivity).

I think you have had some additional discussions with Ted?

I think it is best if IEEE uses the official liaison process if they want an opinion from the IETF (or DHC WG) -- sorry, but I don't know the full details of this process. There is a document that describes this -  http://tools.ietf.org/html/rfc4441 though it looks like this is under review, see http://www.iab.org/2013/01/09/iab-adopts-the-ieee-802ietf-relationship/ and http://tools.ietf.org/html/draft-dawkins-iab-rfc4441rev-02.

You might also speak with the authors of these documents to see whether they can provide you some guidance.

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hiroki Nakano
Sent: Thursday, March 14, 2013 10:45 AM
To: Bernie Volz (volz)
Cc: [email-masked]
Subject: Re: [dhcwg] IEEE 802.11ai and DHCP

I understand protocols generally want to stay independent from their adjacent layers, while someone have to make glue between layers to build up the whole system.
The old days, IP people made glue by theirselves in order to use IP on various link layers.  Today, IP is the winner.
Other protocols else want to have relation with IP and make glue between them and IP in the outside of IETF.
My concern is that bad glues undermine the heart of IP little by little and I believe IETF is the only group who can prevent it.

Anyway, we are competing right now in 802.11WG TGai.
I am supporting an DHCP-based protocol for IP address assignment and against an 802.11ai original protocol.
Please help me if you agree with me.
I can provide more information if you have interest.

Regards,

Hiroki Nakano

(13/03/14 6:00), Bernie Volz (volz) wrote:
>> It is important that we have the new optimized sequence applicable to 
>> most cases and the other cases work as well as what we currently 
>> have.  It can make us happy.
>> The problem is, when, where and who agree and write down the details 
>> of combination and implemenation of protocols.
>>
>> Regards,
>>
>> Hiroki Nakano
>>> There may also be some areas to explore further - such as what 
>>> happens if there are multiple DHCP servers or if Rapid Commit is not 
>>> allowed and how that plays into this. But it likely is just a minor 
>>> issue as the first response may be optimized but additional are 
>>> forwarded to client normally,
>>>
>>> - Bernie
>>>
>>>> I talked with Volz and Tomek yesterday and we also agree that 
>>>> DHCPv4 with Rapid Commit Option has no problem for IPv4 
>>>> configuration by one round trip exchange of packets.
>>>> DHCPv6 has a little missing part related to default route, but 
>>>> another idea using RS and RA solves this as Alex mentioned.
>>>> Optimistic DAD mechanism and Volz pointed out that DHCPv6 could be 
>>>> used without RA.  However, I recognize that dhcpv6-route-option has 
>>>> some difficulty to reach a consensus in IETF.
>>>>
>>>> Bacause 802.11ai is just one of "specific link layer", I'm not sure 
>>>> this working group is suitable for discussion about implementation 
>>>> issues related to DHCPv4 and 802.11ai, (at least, not for RS and 
>>>> RA...) but if anyone having interests in this topic, I'd like to 
>>>> talk about this topic after the dhcwg session informally and please 
>>>> let me hear your comments.
>>>> if you are writing I-D for this topic, which working group will you 
>>>> submit to? dhc? 6man? v6ops??, etc...
>>>>>> 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 .
>>>>>
>>>>> Alternatively, use RS/RA single exchange (and not DHCPv6), with 
>>>>> DNS resolver address:
>>>>> 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.
>>>>>
>>>>>> _______________________________________________ dhcwg mailing 
>>>>>> list [email-masked] https://www.ietf.org/mailman/listinfo/dhcwg
>>>>>
>>>>>

---

From: Erik Kline <[email-masked]>
Date: Thu, 14 Mar 2013 10:58:07 -0400

> I can provide more information if you have interest.

Is there a link to a document we can review?

I do not think that anything requiring DHCPv6 for IPv6 address assignment
will work in the general case (furthermore: I think it's a bad idea).

---

From: Tomek Mrugalski <[email-masked]>
Date: Thu, 14 Mar 2013 11:16:30 -0400

> little by little and I believe IETF is the only group
DHCPv4 and v6 are generic protocols that can work on many access
technologies. It would be infeasible to bring in specification on how to
run DHCP on things like Bluetooth, WiMAX, LTE, UMTS and other.

Long time ago I was involved in 802.16 (WiMAX) project. I remember that
there were IEEE documents that explained if/when to use DHCP, should
it be v4 or v6, what specific options to request etc. I still have
802.16-2004 document that discusses in section 9.1.1 DHCP usage. You may
want to take a look at it and shape your TGai document in a similar fashion.

During our discussion it came to my attention that in your scenario
speed is of essence. DHCP mostly (all except elapsed time) uses timer
specified in seconds. If you want change that behavior (e.g.
retransmissions happening much sooner than after 1 second), this would
require changing DHCP protocol. It could potentially warrant a new draft
discussing this issue and potentially proposing solution. If you want to
follow that path, it recommend that you discuss the proposed solution
first on this mailing list before jumping immediately into writing a draft.

Hope that helps,
Tomek

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 15 Mar 2013 02:04:22 +0100

Le 14/03/2013 15:58, Erik Kline a écrit :
>
> Anyway, we are competing right now in 802.11WG TGai. I am supporting
> an DHCP-based protocol for IP address assignment and against an
> 802.11ai original protocol. Please help me if you agree with me. I
> can provide more information if you have interest.
>
>
> I do not think that anything requiring DHCPv6 for IPv6 address
> assignment will work in the general case (furthermore: I think it's a
>  bad idea).

Erik, I need to get a moment to discuss about this.

Generally speaking, I think the implicit conclusions of RA for address
autoconfiguration everywhere is little useful.  There exist explicit
cases where only DHCPv6 can help (e.g. Prefix Delegation to a
Machine-class Router needing addresses as well).

On one hand people oppose ND Prefix Delegation and on another hand
people oppose DHCPv6 Default Route.  That obviously leads to the
necessity to use _both_.  Both means double software implementation,
double message exchanges and so on.

Alex

---

From: Masataka Ohta <[email-masked]>
Date: Sun, 17 Mar 2013 16:19:25 +0900

> double message exchanges and so on.

Default route may be provided by an 802.11ai original mechanism.

						Masataka Ohta

---

From: Erik Kline <[email-masked]>
Date: Sun, 17 Mar 2013 08:22:38 -0400

> Default route may be provided by an 802.11ai original mechanism.

What's the best way to get IETF<->IEEE communication on this then?  If they
(accidentally) do anything that alters the existing IPv6 architecture
requirements without IETF/6man review then...we'll have to sort it all out
somehow.

---

From: Ted Lemon <[email-masked]>
Date: Sun, 17 Mar 2013 12:45:24 +0000

On Mar 17, 2013, at 8:22 AM, Erik Kline <[email-masked]> wrote:
> What's the best way to get IETF<->IEEE communication on this then?  If they (accidentally) do anything that alters the existing IPv6 architecture requirements without IETF/6man review then...we'll have to sort it all out somehow.

I don't think 802.11ai wants to do this by accident.   They want to do it because the IETF doesn't have consensus to do it.   So I think it's unrealistic to propose that the IEEE would not do this work because it wouldn't get past 6man.   That's not the relationship that exists between IETF and IEEE.   If you want to participate in IEEE's process, you pretty much have to go to IEEE.

---

From: Masataka Ohta <[email-masked]>
Date: Sun, 17 Mar 2013 23:53:53 +0900

Ted Lemon wrote:

> I don't think 802.11ai wants to do this by accident.   They want
> to do it because the IETF doesn't have consensus to do it.
> So I think it's unrealistic to propose that the IEEE would not do
> this work because it wouldn't get past 6man.

And, it will motivate IETF to make its protocols consistent.

						Masataka Ohta

---

From: Erik Kline <[email-masked]>
Date: Sun, 17 Mar 2013 11:02:57 -0400

> And, it will motivate IETF to make its protocols consistent.

In the minds of those for whom RAs are satisfactory, they are (pretty)
consistent.

---

From: Alexandru Petrescu <[email-masked]>
Date: Sun, 17 Mar 2013 17:17:17 +0100

Le 17/03/2013 13:22, Erik Kline a écrit :
> On 17 March 2013 03:19, Masataka Ohta
> <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>> necessity to use _both_.  Both means double software
>> implementation, double message exchanges and so on.
>
> What's the best way to get IETF<->IEEE communication on this then?

At IETF there are several people involved in the liaison process IETF-IEEE.

I noticed this in the 802.11p and 802.15.4 contexts.

> If they (accidentally) do anything that alters the existing IPv6
> architecture requirements without IETF/6man review then...we'll have
> to sort it all out somehow.

I agree.  Yes, and I can explain why this is needed, depending on the
existing status of advancement of 802.11ai and default route assignment.
(e.g. is the default router assigned by an exclusively link-layer message?)

This could be discussed.

Alex

---

From: Erik Kline <[email-masked]>
Date: Sun, 17 Mar 2013 13:29:20 -0400

> (e.g. is the default router assigned by an exclusively link-layer message?)

Well, we know that we disagree.

Of course, if there is to be a discussion I suspect that this list is
probably not the right venue, meaning that I suspect that >80-90% of the
subscribers don't care about this particular issue and there are probably
those not on this list who do.

To clarify, might we be talking about the contents of section 5 of:

https://mentor.ieee.org/802.11/dcn/12/11-12-0151-15-00ai-proposed-specification-framework-for-tgai.docx

I'm not sure I've got the right doc, but anyway, I'll see about how
possible participation in the IEEE process, I guess.

---

From: Alexandru Petrescu <[email-masked]>
Date: Sun, 17 Mar 2013 19:09:14 +0100

Le 17/03/2013 18:29, Erik Kline a écrit :
> existing status of advancement of 802.11ai and default route
> assignment. (e.g. is the default router assigned by an exclusively
> link-layer message?)
>
> This could be discussed.
>
>
> Of course, if there is to be a discussion I suspect that this list
> is probably not the right venue, meaning that I suspect that >80-90%
> of the subscribers don't care about this particular issue and there
> are probably those not on this list who do.

It's not the only group where this particular topic is of interest only
to a minority.  There is 6MAN, v6ops, MIF.  MIF drops this out of its
new Charter.

When one requests a new email list at IETF one needs to think about its
name... what would a name be?

Alex

---

From: Hiroki Nakano <[email-masked]>
Date: Tue, 19 Mar 2013 04:55:03 +0900

> possible participation in the IEEE process, I guess.

The bimonthly week of TGai has been started today
in the same place as IETF86 of the last week.
The battle is a draw for now.

https://mentor.ieee.org/802.11/dcn/13/11-13-0040-04-00ai-higher-layer-packet-container-proposal-text.doc
https://mentor.ieee.org/802.11/dcn/13/11-13-0267-00-00ai-fils-ip-address-setup.doc

Come and join us, please.

Regards,

Hiroki Nakano

---

From: Ted Lemon <[email-masked]>
Date: Mon, 18 Mar 2013 20:12:43 +0000

> The battle is a draw for now.

Are you going to discuss this further in this IEEE meeting, or is that it until next time?

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 19 Mar 2013 02:08:43 +0000

You might work DHCPv6 into your proposal (similar to DHCPv4 - though it isn't explicitly mentioned whereas stateless is).

It is important to note in your design that if the client doesn't do all of the things, it can still work (although a bit slower). Whereas with the other technique a lot has to change.

You might note that there are a lot of other configuration items that come along for virtually nothing when doing DHCP and, although in many Wi-Fi networks it probably isn't used a lot, but the DHCP could be set up to do DNS updates on the client's behalf. It also doesn't look like there is any way to communicate the domain name search list (clients could do DHCPINFORMs / INFORMATION-REQUEST later to get at least these other configuration items).

Also, how will the other technique work when the client attempts to do DHCP? Seems like a lot of change to the client stack, especially as hopefully this switch between 802.11ai and non-802.11ai interfaces should be smooth and transparent? I don't believe these would usually look like different interfaces to the client? But we don't know what the full standard says. So how will this other technique co-exist with non-802.11ai interfaces in a providers network (i.e., they have been using DHCP to configure their clients and now when they switch to 802.11ai they need to do something new or different).

Also, there is no way to move between APs (even 802.11ai) since there are different address allocation techniques (in your approach as the DHCP server is used, it could give out the same address if the network supports a flat address space). In the other technique the AP might communicate to some central controller, but now you'd need a protocol for conveying the address information between the AP and central controller?

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hiroki Nakano
Sent: Monday, March 18, 2013 3:55 PM
To: [email-masked]
Subject: Re: [dhcwg] IEEE 802.11ai and DHCP

> possible participation in the IEEE process, I guess.

The bimonthly week of TGai has been started today in the same place as IETF86 of the last week.
The battle is a draw for now.

Regards,

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 19 Mar 2013 03:27:15 +0100

Hello,

In this, there are two questions:
- is is appropriate to assign this Gateway IPv6 Address and its MAC
   address by using a link-layer protocol instead of IPv6 protocols?
- is it appropriate to assign this Gateway IPv6 Address and its MAC
   address by using DHCPv6 instead of ND protocol?

My responses is yes and yes, depending on context.

What do you think?

And, I must check whether the way of assignment by using the link layer
protocol is enough for what the IPv6 ND protocol needs.  Does the link 
layer protocol way of assigning the IPv6 Gateway provide a lifetime? 
(the lifetime is necessary in the ND's data structures for this 
Gateway).  Is it able to provide _several_ such IPv6 Gateways? 
(typically it is not forbidden by IPv6 implementations to have several 
default routes).

See below for my interpretation.

Le 18/03/2013 20:55, Hiroki Nakano a écrit :
>> I'm not sure I've got the right doc, but anyway, I'll see about
>> how possible participation in the IEEE process, I guess.
>
> The bimonthly week of TGai has been started today in the same place
> as IETF86 of the last week. The battle is a draw for now.
>

I quickly went through the documents.

In the first, there is this new parameter to the function
MLME-ASSOCIATE.confirm(...FILS IP Address Assignment Data...)

Associate.Confirm is a link layer message sent to the Client, in
response to a request.

This containq "Assigned IPv6 address, Gateway IPv6 address and IPv6
Gateway MAC Address are included if this bit is set to ‘1’" as the Table
-8.4.2.ai1.ai2-1 "IP Address Response Control" says.

This is a mix of what IETF protocols do.  The 'IPv6 address'
is currently provided by either the couple RFC4862 "Stateless Address
Autoconfiguration" and RFC2464 "IPv6 over Ethernet", or by RFC3315
"DHCPv6".  The 'Gateway IPv6 Address' is provided only by RFC4861
"Neighbor Discovery in IPv6" by setting the Router Lifetime to non-zero;
the MAC address of this Gateway is present in the Neigbor Advertisement
message of same RFC4861 (only ND RFC4861, not DHCPv6).

Remark, currently DHCPv6 contrary to DHCPv4 does not provide neither the
Gateway IPv6 Address nor its corresponding MAC Address. (except the
following individual IETF submission draft-mouton-mif-dhcpv6-drlo-02.txt
"Default Router List Option for DHCPv6 (DRLO)" - which does assign the
IPv6 address of the Default Router and its MAC address by using DHCPv6.)

In this, there are two questions:
- is is appropriate to assign this Gateway IPv6 Address and its MAC
   address by using a link-layer protocol instead of IPv6 protocols?
- is it appropriate to assign this Gateway IPv6 Address and its MAC
   address by using DHCPv6 instead of ND protocol?

My oppinion is yes and yes, because of the context.

What do you think?

And, I must check whether the way of assignment by using the link layer
protocol is enough for what the ND protocol needs. Is the link layer
protocol way of assigning the IPv6 Gateway provide a lifetime? (the
lifetime is necessary in the ND's data structures for this Gateway). Is
it able to provide _several_ such IPv6 Gateways? (typically it is not
forbidden by IPv6 implementations to have several default routes).

> Come and join us, please.

Thank you for the invitation!  Noted.  I guess IETFers are already
there.

I would like to add that there is much ongoing private discussion right
now about the use of DHCPv6 to assign routes/defaultRouters/src-based
routes to a Client.  It was discussed until now since 3-4 years in 6MAN
Working Group, DHC WG, MIF WG.  Right now much of this discussion
happens privately.  I would like there to be a common unique place where
to discuss this DHCPv6 routes/DefRoutes/src-based routes, and 
relationship to 802.11ai.

Our new Area Director expressed will for setting up such a list, if 
there is enough interest:
http://www.ietf.org/mail-archive/web/mif/current/msg02068.html

Alex

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 19 Mar 2013 12:34:27 +0900

Bernie Volz (volz) wrote:

> It also doesn't look like there is any way to communicate the
> domain name search list (clients could do DHCPINFORMs /
> INFORMATION-REQUEST later to get at least these other
> configuration items).

FYI, domain name search list is considered evil in IETF DNS
related WGs.

Even ignoring an obvious security problem, the list should
be configured statically by users, who know frequently used
domain names by them, which has nothing to do with the current
locations of the users.

						Masataka Ohta

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 19 Mar 2013 04:54:47 +0100

Le 19/03/2013 03:08, Bernie Volz (volz) a écrit :
[...]
> Also, there is no way to move between APs (even 802.11ai) since
> there are different address allocation techniques (in your approach
> as the DHCP server is used, it could give out the same address if
> the network supports a flat address space). In the other technique
> the AP might communicate to some central controller, but now you'd
> need a protocol for conveying the address information between the AP
> and central controller?

This reads as a technique similar to what RFC5213 "Proxy Mobile IPv6" does.

Remark this topology described in the document referred at IEEE 802.11ai:

                STA ---- AP ---- Router

is also considered by both DHCPv6 (Client---Relay---Server) and by Proxy
Mobile IPv6 (MobileNode---MAG---LMA).  These multihop networks are less
pertinent to Neighbor Discovery.

Alex

>
> - Bernie
>
> -----Original Message----- From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Hiroki Nakano Sent:
> Monday, March 18, 2013 3:55 PM To: [email-masked] Subject: Re:
> [dhcwg] IEEE 802.11ai and DHCP
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 19 Mar 2013 05:02:53 +0100

> Also, how will the other technique work when the client attempts to
> do DHCP? Seems like a lot of change to the client stack,

I agree with the question and it seems to me as well that a lof of
change in the client IP stack may be needed.

In addition to DHCPv6, the basic IPv6-over-Ethernet RFCs may need to get
updated to make sure they dont auto-configure addresses, nor defroutes,
when running over 802.11ai.

It would be strange to see an IPv6-over-802.11ai IETF document, because
one would expect IPv6 over 'ai' to work just like IPv6 over 802.11b
which is same as IPv6-over-Ethernet.

(which reminds of IPv6-over-802.16... 16ng IETF Working Group).

Alex

> especially as hopefully this switch between 802.11ai and non-802.11ai
> interfaces should be smooth and transparent? I don't believe these
> would usually look like different interfaces to the client? But we
> don't know what the full standard says. So how will this other
> technique co-exist with non-802.11ai interfaces in a providers
> network (i.e., they have been using DHCP to configure their clients
> and now when they switch to 802.11ai they need to do something new or
> different).
>

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 20 Mar 2013 08:07:24 +0900

> which is same as IPv6-over-Ethernet.

Actually, Ethernet with CSMA/CD and Wifi with CSMA/CA behaves
differently for broadcast/multicast packets.

With Wifi, as it is impossible to detect collisions, every
packet is ACKed to confirm collision did not occur. Otherwise,
the packet is resent. However, ACK is applicable only to unicast.

Thus, broadcast/multicast over Wifi is not as reliable as
that over Ethernet.

Thus, though IP-over-Ethernet works as IP-over-Wifi, it sometimes
loss broadcast/multicast packets and may not be very efficient.

						Masataka Ohta

---

From: Hiroki Nakano <[email-masked]>
Date: Wed, 20 Mar 2013 21:43:37 +0900

> or is that it until next time?

I'm participating in the discussion at Caribe Royale.
We are making effort to have a conclusion in this week.
If TGai decides to provide a generic container framework
which can be used to transfer DHCP messages,
why don't you continue to talk about DHCP and 802.11ai? :)

Regards,

Hiroki Nakano

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 20 Mar 2013 13:59:33 +0100

Le 20/03/2013 13:43, Hiroki Nakano a écrit :
>>> The bimonthly week of TGai has been started today in the same
>>> place as IETF86 of the last week. The battle is a draw for now.
>>
> I'm participating in the discussion at Caribe Royale. We are making
> effort to have a conclusion in this week. If TGai decides to provide
> a generic container framework which can be used to transfer DHCP
> messages,

To transfer DHCP messages?  Or to transfer parameters which are usually
configured by DHCPv6 and by Stateless-Address-Auto-configuration?

Do you mean a typical Ethernet frame which would carry a DHCPv6 message
with EtherType 0x86DD?

Or other kind of Ethernet container which would be dedicated to transfer
specifically DHCPv6 messages?

There may be interest to realize fast configuration with DHCPv6.  There
are some IP tools at our disposal.  One that may be useful is also the
RAPID COMMIT option of DHCP.

> why don't you continue to talk about DHCP and 802.11ai? :)

Because we must be careful about this discussion DHCPv6-and-routes
discussion.

DHCPv6-and-routes/routers-to-Client have been discussed in public in few
mailing lists (6MAN, MIF, DHC), since 2-5 years, and in private.  There
is risk of contingency, it is sensitive.  There are risks of being
qualified as architecturally incompatible.

For the particular case of DHCPv6-defaultroute - this approaches in some
way very much the IEEE 802.16ai documents that were pointed in this list.

The IEEE 802.11ai documents propose - among other things - to put the
IPv6 Gateway address in the 802.16ai message.  The 'IPv6 Gateway' is
practically the IPv6 address of the router which should be used as
Default Router by the Client STA.

Regardless of the discussion whether the IPv6 Gateway should be present
in a link-layer message (rather than in a DHCPv6, or Router
Advertisement message)...

... there is lack of consensus - read strong disagreements at IETF -
about whether the IPv6 Gateway should be present in DHCPv6 message at
all (because typically the Default Router's address is present in a
Router Advertisement message - currently DHCPv6 doesnt have an option to
deliver default routes to Client).  These disagreements hurt at many places.

(I have my own oppinion about this idea of using IPv6 Gateway address in
a DHCPv6 message vs RA message;  there are several Internet Drafts which
propose to use DHCPv6 to configure routes, default routes, etc.)

Alex

---

From: Hiroki Nakano <[email-masked]>
Date: Thu, 21 Mar 2013 22:48:40 +0900

> configured by DHCPv6 and by Stateless-Address-Auto-configuration?

My position is that generic container should be defined to transfer
packets of upper layers such as DHCPv4, RS/RA, DHCPv6 etc.

> Do you mean a typical Ethernet frame which would carry a DHCPv6 message

Yes.

The newest proposal is at the URL below.
https://mentor.ieee.org/802.11/dcn/13/11-13-0235-02-00ai-ip-address-setup.doc
We finally have merged two proposals and implementors can choose them.
And this framework has been approved by TGai yesterday.

IEEE 802.11ai is just A link layer.
Therefore, how to use 802.11ai should be discussed by people of
upper layers and it is none of business of TGai itself.

On the other hand,
TGai has its own use cases and the principle.
As Tomek pointed out before, speed is of essence of TGai.
Imagine that you go through in front of an AP by car.
You have only 10 seconds.  It's only for 10 seconds you can
communicate with the AP!  You never want to waste even one
round trip of packets.
Accommodating numerous STA is the other aspect of TGai.
Assume that an AP is installed at Tokyo station.
1000 people per minute are passing beside the AP.
They all perform 802.11 association process and
IP layer configuration process such as DHCP.
All of piled protocols should be required to be as
efficient as possible for such environments.

I hope to share these principles with IETF people widely
and discuss the whole protocol stack from the link layer
to application layers.  Some people already have
the understanding and I'm so happy:)

P.S.
An interesting report is below.
https://mentor.ieee.org/802.11/dcn/13/11-13-0323-02-00ai-tgai-experimental-test-report-of-fils.pptx
Check it out.
If you can not play video in ppt, you can see at
http://www.youtube.com/watch?v=xOKaVOPWXTU
I'm also in this video. hehe:)

Regards,

Hiroki Nakano

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 21 Mar 2013 19:24:09 +0100

Le 21/03/2013 14:48, Hiroki Nakano a écrit :
>>> I'm participating in the discussion at Caribe Royale. We are
>>> making effort to have a conclusion in this week. If TGai decides
>>> to provide a generic container framework which can be used to
>>> transfer DHCP messages,
>>
>> To transfer DHCP messages?  Or to transfer parameters which are
>> usually configured by DHCPv6 and by
>> Stateless-Address-Auto-configuration?
>

I can understand that position to which I could agree.

>> Do you mean a typical Ethernet frame which would carry a DHCPv6
>> message with EtherType 0x86DD?
>
> Yes.

Makes sense to me.

> https://mentor.ieee.org/802.11/dcn/13/11-13-0235-02-00ai-ip-address-setup.doc

Thank
you for providing the link and thanks IEEE for making public
ongoing working documents.

But, this proposal seems to put the IPv6 Gateway address and the MAC
address of the IPv6 Gateway into MAC messages, and not IP messages.

For example on page 12, Figure 8.4.2.ai2.ai3-1 and figure below it.

I may be ignorant about how IEEE specifications are expressed - sorry if
I misunderstand.

> We finally have merged two proposals and implementors can choose

Do you mean there are two different proposals in the same document?

May I ask you - with respect to the assignment of the IPv6 Gateway
address, and its MAC address: are there two different methods, in this
document, about assigning these parameters to a Client?

Is any of the described methods likely to considering IPv6 Router
Advertisements ('RA') to configure these two parameters?  Is any of the
described methods likely to be considering DHCPv6 to configure these two
parameters?

> And this framework has been approved by TGai yesterday.

I read this as good news and I am happy for the group.

> IEEE 802.11ai is just A link layer. Therefore, how to use 802.11ai
> should be discussed by people of upper layers and it is none of
> business of TGai itself.

Ok.

> On the other hand, TGai has its own use cases and the principle. As
> Tomek pointed out before, speed is of essence of TGai. Imagine that
> you go through in front of an AP by car. You have only 10 seconds.
> It's only for 10 seconds you can communicate with the AP!  You never
> want to waste even one round trip of packets.

Ok, I can understand that.  For vehicle communication the situation may
be that way, and even a bit more complicated.  In a vehicle there may be
a need of more than just one IPv6 address - maybe an entire prefix is
needed within the vehicle, in addition to the address for the egress
interface of the Router in the vehicle.  At that point maybe DHCPv6
PRefix Delegation is needed (in addition to just DHCPv6 for address, or
just RA for address and default route).

> Accommodating numerous STA is the other aspect of TGai. Assume that
> an AP is installed at Tokyo station. 1000 people per minute are
> passing beside the AP. They all perform 802.11 association process
> and IP layer configuration process such as DHCP. All of piled
> protocols should be required to be as efficient as possible for such
> environments.

Efficiency is a good requirement.

I dont know how many STAs are supported with IPv6 and RA on a single
WiFi Access Point... all communicating simultaneously.

I could guess that the WiFi situation could be improved if more than one
Access Point were deployed, with some channel number selection.

I could guess that numerous periodic beacons IPv6 RAs may be too much
aditional noise that could be avoided if DHCP were used (DHCP doesn't
beacon periodic advertisements).

> I hope to share these principles with IETF people widely and discuss
> the whole protocol stack from the link layer to application layers.
> Some people already have the understanding and I'm so happy:)

Ok - the details you presented until now are interesting to me.  I think
there may be other people interested.

I can explain why I am interested.

I am working on a method to use DHCPv6 to communicate Default Routers to
Clients.  This is also for efficiency reasons, but not quite the
scenario you describe.

I consider an LTE Machine-class device which is constrained in terms of
power consumption, memory size, clock speed.  This connects to LTE but
also offers WiFi to a group of other devices deployed in a vehicle.  One
would like this to be quickly configured.

But the full set of configuration parameters is IPv6 address, IPv6
Default Router, maybe DNS Resolvers address, maybe MAC address and IPv6
Delegated Prefix (this is not the prefix of that IPv6 address).  To
configure all these one may need to  use both DHCPv6 and ND.

It's practically impossible today to do all in one shot
Request-Response.  One can do e.g. Neighbour Discovery (or SLAAC) to
configure the address and the default route but must do DHCPv6 to
delegate the prefix.  This is too many messages.

If DHCPv6 could do Default Router then a single message exchange would
be sufficient.

If RA could do Prefix Delegation, then also a single message exchange
would be sufficient.

That said, a few other people expressed interest in using DHCPv6 to
communicate routes to Clients.  And to communicate maybe src-based
routes to Clients.

However, the situation right now is that we dont know where to discuss
these aspects of DHCPv6 and route to Client options.

I believe the 802.11ai aspects are ok to discuss here - the Chair has
allowed this discussion although I doubt it's in the DHC Charter (I have
to read).

All in all - this is why I am interested in 802.11ai.

Yours,

Alex

Alex

>
> P.S. An interesting report is below.
Check it out.
> http://www.youtube.com/watch?v=xOKaVOPWXTU I'm also in this video.
> hehe:)
>
> Regards,
>

---

From: Jouni Korhonen <[email-masked]>
Date: Tue, 26 Mar 2013 11:09:21 +0200

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

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 28 Mar 2013 17:12:31 +0100

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

>> 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.
>>
>> 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.
>>
>> in addition provide framework for higher layers such as IP to send
>> and receive packets during 802.11 association process. The