Re: [dhcwg] IEEE 802.11ai and DHCP

["Bernie Volz (volz)" <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] On Behalf Of Hiroki Nakano
Sent: Thursday, March 14, 2013 10:45 AM
To: Bernie Volz (volz)
Cc: [e-mail]
Subject: Re: [dhcwg] IEEE 802.11ai and DHCP

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
Trans New Technology, Inc. <[e-mail]>


(13/03/14 6:00), Bernie Volz (volz) wrote:
> 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
>
> On Mar 13, 2013, at 3:36 PM, "Hiroki Nakano" <[e-mail]> wrote:
>
>> 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
>> Trans New Technology, Inc. <[e-mail]>
>>
>>
>> (13/03/14 3:25), Bernie Volz (volz) wrote:
>>> 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
>>>
>>> On Mar 13, 2013, at 2:18 PM, "Hiroki Nakano" <[e-mail]> wrote:
>>>
>>>> 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. <[e-mail]>
>>>>
>>>>
>>>>
>>>> (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. <[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