From alexandru.petrescu@gmail.com Tue Aug 2 08:22:12 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C041C21F8783 for ; Tue, 2 Aug 2011 08:22:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hw-bzWHVFoex for ; Tue, 2 Aug 2011 08:22:12 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id CA91E21F8781 for ; Tue, 2 Aug 2011 08:22:11 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.2) with ESMTP id p72FMKV7010763 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 2 Aug 2011 17:22:20 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id p72FMJRs004959; Tue, 2 Aug 2011 17:22:19 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [132.166.133.178] (is010183.intra.cea.fr [132.166.133.178]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id p72FMJiY010347; Tue, 2 Aug 2011 17:22:19 +0200 Message-ID: <4E38162B.1040507@gmail.com> Date: Tue, 02 Aug 2011 17:22:19 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: mif Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: [mif] Comments about default route and draft-ietf-mif-dhcpv6-route-option-02 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 15:22:12 -0000 Hello MIF WG, Recently, there were comments on the mailing list about default route, source address and draft-ietf-mif-dhcpv6-route-option "DHCPv6 Route Options" (subsequently called "route-option" draft). Moreover, I commented on the microphone during the MIF WG meeting in Québec, IETF81. I would like to further detail these comments by email. - I need a means to communicate the default route to a Host by using DHCPv6 (instead of RA). - the route-option draft specifies to use DHCPv6 to communicate routes (tuples prefix-nexthop) to a Client. This can indeed be used to communicate a default route as a particular kind of route (i.e. use "::/0" as prefix and the IP address of a default router as "nexthop".) The encoding used by the route-option draft is of the form: nexthop-prefix, nexthop-prefix-prefix-prefix, etc. Whereas this use of this route-option mechanism to communicate default routes is possible, and is extensible, it currently lacks a number of features necessary to communicate default routes. - it is a waste of memory and bandwidth to communicate 136bits of prefix, as the route-option draft does, when it is known that that prefix is ::/0 in the case of default route (RFC). We don't see a simple means to optimize the format of the Route Prefix Option (including the mandatory 136bits) of the current route-option draft. - the default route is special ("when everything else fails"), it is not a simple prefix-nexthop route, because: - the default route appears in a linux routing table as another typical route but it appears as well in the mandatory ND Default Router List associated with more parameters (actually dereferenced pointers to the Neighbor Cache). - the default route is better if it uses a Lifetime. It is assumed ND is already implemented by the vast majority of IPv6 Hosts. (1) The current route-option draft mentions Lifetime to be managed according to general events of DHCP (and not of ND) - this may lead to incoherent behaviour when both DHCP and ND are run on same Host. (2) The Lifetime of DHCP is on 32bits whereas of ND is on 16bit. - it may be advantageous to communicate the MAC address of the gw of the default route, with DHCP. This may speed up implementation, because it avoids the Host to need to perform NS/NA for the IP address of the gw of the default route. The draft route-option does not communicate a MAC address. - the route-option draft can communicate several default routes as follows: nexthop-prefix, nexthop-prefix,... However, a more efficient scheme is possible as follows: 1bit, nexthop, nexthop,... - the scope of the route-option draft reads as environments where routing protocols are more appropriate, whereas a more reduced scope could be to focus exclusively on the obtention of the default route as part of basic IP connectivity (not necessarily the complex topologies afforded by routing protocols). We believe a better technique is possible to communicate default route with DHCPv6. What do people think about these comments? Yours, Alex From alexandru.petrescu@gmail.com Tue Aug 2 08:23:14 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBB0921F8586 for ; Tue, 2 Aug 2011 08:23:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.602 X-Spam-Level: X-Spam-Status: No, score=-1.602 tagged_above=-999 required=5 tests=[AWL=-1.218, BAYES_00=-2.599, FRT_LOLITA1=1.865, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RNQg9m0btDiN for ; Tue, 2 Aug 2011 08:23:14 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 6734E21F856D for ; Tue, 2 Aug 2011 08:23:08 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.2) with ESMTP id p72FNGk5022146 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 2 Aug 2011 17:23:16 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id p72FNFd6005130; Tue, 2 Aug 2011 17:23:15 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [132.166.133.178] (is010183.intra.cea.fr [132.166.133.178]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id p72FNFhk010641; Tue, 2 Aug 2011 17:23:15 +0200 Message-ID: <4E381663.7070109@gmail.com> Date: Tue, 02 Aug 2011 17:23:15 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: mif Content-Type: multipart/mixed; boundary="------------010203090102030700030301" Subject: [mif] Announcing draft-mouton-mif-dhcpv6-drlo-00 about default route with DHCPv6 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 15:23:15 -0000 This is a multi-part message in MIME format. --------------010203090102030700030301 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear MIF, We would like to announce a new draft focusing to offer default route with DHCPv6: "Default Router List Option for DHCPv6 (DRLO)" draft-mouton-mif-dhcpv6-drlo-00.txt http://tools.ietf.org/html/draft-mouton-mif-dhcpv6-drlo-00.txt Thank you in advance for commenting on this draft. Alex and Maximilien -------------------------------------------------------------------- Implementation Details A prototype linux implementation is ongoing, and modifies ISC Client and Server; Relay works unmodified. A wireshark capture is attached (dissector code available upon request). Server uses a new pattern of 'format codes' "6SmMoA", and the conf file says: [...] > option dhcp6.default-router 2002:c130:13c1:11f::ff 8400 > 00:07:32:06:7e:72,2002:c130:13c1:11f:13c1:11f::fe 88 > 00:07:32:06:7e:73 ,2002:c130:13c1:11f::f5 8300 ; [...] Client conf file says: > interface "eth0"{ request > dhcp6.domain-search,dhcp6.name-servers,dhcp6.default-router; } Client says: > RCV: X-- Server ID: 00:01:00:01:15:67:c9:7d:00:12:3f:1c:a2:95 > RCV: | | X-- TEST_AJOUT eth0 et 0 et 2. > RCV: | | X-- DEFAULT_ROUTER_ADDR 2002:c130:13c1:11f::ff. > RCV: | | | X-- Default_router_lifetime 8000. > RCV: | | | X-- Default_router_link_layer_addr 00:22:68:17:59:ae. > RCV: | | X-- TEST_AJOUT eth0 et 0 et 2. > RCV: | | X-- DEFAULT_ROUTER_ADDR 2002:c130:13c1:11f::fe. > RCV: | | | X-- Default_router_lifetime 8400. > RCV: | | | X-- Default_router_link_layer_addr 00:07:32:06:7e:72. > RCV: Advertisement recorded. After execution of the DHCP exchange, the neigh cache is (note "expires" corresponding to the lifetime): > # ip -6 route show [...] > default via 2002:c130:13c1:11f::ff dev eth0 proto kernel metric 1024 > expires 7752sec mtu 1500 advmss 1440 hoplimit 0 [...] Thank you for considering this draft. Alex --------------010203090102030700030301 Content-Type: text/plain; name="dhcp_default_router_list.wireshark" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="dhcp_default_router_list.wireshark" +---------+---------------+----------+ 19:26:59,016,739 ETHER |0 |33|33|00|01|00|02|f0|de|f1|5e|8a|c5|86|dd|60|00|00|00|00|3e|11|40|fe|80|00|00|00|00|00|00|f2|de|f1|ff|fe|5e|8a|c5|ff|02|00|00|00|00|00|00|00|00|00|00|00|01|00|02|02|22|02|23|00|3e|8d|04|01|f3|23|69|00|01|00|0e|00|01|00|01|15|c9|ba|82|f0|de|f1|5e|8a|c5|00|06|00|06|00|18|00|17|00|42|00|08|00|02|00|00|00|03|00|0c|f1|5e|8a|c5|00|00|0e|10|00|00|15|18| +---------+---------------+----------+ 19:26:59,017,183 ETHER |0 |f0|de|f1|5e|8a|c5|00|12|3f|1c|a2|95|86|dd|60|00|00|00|00|a6|11|40|fe|80|00|00|00|00|00|00|02|12|3f|ff|fe|1c|a2|95|fe|80|00|00|00|00|00|00|f2|de|f1|ff|fe|5e|8a|c5|02|23|02|22|00|a6|c9|d7|02|f3|23|69|00|03|00|28|f1|5e|8a|c5|00|00|00|00|00|00|00|00|00|05|00|18|20|02|c1|30|13|c1|01|1f|00|00|00|00|00|00|bb|96|00|00|01|77|00|00|02|58|00|01|00|0e|00|01|00|01|15|c9|ba|82|f0|de|f1|5e|8a|c5|00|02|00|0e|00|01|00|01|15|67|c9|7d|00|12|3f|1c|a2|95|00|17|00|10|20|02|c1|30|13|c1|01|1f|00|00|00|00|00|00|00|01|00|42|00|32|20|02|c1|30|13|c1|01|1f|00|00|00|00|00|00|00|ff|1f|40|06|00|22|68|17|59|ae|20|02|c1|30|13|c1|01|1f|00|00|00|00|00|00|00|fe|20|d0|06|00|07|32|06|7e|72| +---------+---------------+----------+ 19:27:00,088,125 ETHER |0 |33|33|00|01|00|02|f0|de|f1|5e|8a|c5|86|dd|60|00|00|00|00|6c|11|40|fe|80|00|00|00|00|00|00|f2|de|f1|ff|fe|5e|8a|c5|ff|02|00|00|00|00|00|00|00|00|00|00|00|01|00|02|02|22|02|23|00|6c|f7|f3|03|85|0a|82|00|01|00|0e|00|01|00|01|15|c9|ba|82|f0|de|f1|5e|8a|c5|00|02|00|0e|00|01|00|01|15|67|c9|7d|00|12|3f|1c|a2|95|00|06|00|06|00|18|00|17|00|42|00|08|00|02|00|00|00|03|00|28|f1|5e|8a|c5|00|00|0e|10|00|00|15|18|00|05|00|18|20|02|c1|30|13|c1|01|1f|00|00|00|00|00|00|bb|96|00|00|1c|20|00|00|1d|4c| +---------+---------------+----------+ 19:27:00,088,570 ETHER |0 |f0|de|f1|5e|8a|c5|00|12|3f|1c|a2|95|86|dd|60|00|00|00|00|a6|11|40|fe|80|00|00|00|00|00|00|02|12|3f|ff|fe|1c|a2|95|fe|80|00|00|00|00|00|00|f2|de|f1|ff|fe|5e|8a|c5|02|23|02|22|00|a6|de|2c|07|85|0a|82|00|03|00|28|f1|5e|8a|c5|00|00|00|00|00|00|00|00|00|05|00|18|20|02|c1|30|13|c1|01|1f|00|00|00|00|00|00|bb|96|00|00|01|77|00|00|02|58|00|01|00|0e|00|01|00|01|15|c9|ba|82|f0|de|f1|5e|8a|c5|00|02|00|0e|00|01|00|01|15|67|c9|7d|00|12|3f|1c|a2|95|00|17|00|10|20|02|c1|30|13|c1|01|1f|00|00|00|00|00|00|00|01|00|42|00|32|20|02|c1|30|13|c1|01|1f|00|00|00|00|00|00|00|ff|1f|40|06|00|22|68|17|59|ae|20|02|c1|30|13|c1|01|1f|00|00|00|00|00|00|00|fe|20|d0|06|00|07|32|06|7e|72| --------------010203090102030700030301-- From marc.blanchet@viagenie.ca Tue Aug 2 08:30:27 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDB0621F873D for ; Tue, 2 Aug 2011 08:30:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eRKpKannt83s for ; Tue, 2 Aug 2011 08:30:17 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id C251A21F873A for ; Tue, 2 Aug 2011 08:30:17 -0700 (PDT) Received: from h109.viagenie.ca (h109.viagenie.ca [206.123.31.109]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 92FAC21BBB for ; Tue, 2 Aug 2011 11:30:26 -0400 (EDT) Message-ID: <4E381812.7040802@viagenie.ca> Date: Tue, 02 Aug 2011 11:30:26 -0400 From: Marc Blanchet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: mif@ietf.org References: <4E38162B.1040507@gmail.com> In-Reply-To: <4E38162B.1040507@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [mif] Comments about default route and draft-ietf-mif-dhcpv6-route-option-02 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 15:30:28 -0000 Le 11-08-02 11:22, Alexandru Petrescu a écrit : > - it is a waste of memory and bandwidth to communicate 136bits of > prefix, as the route-option draft does, when it is known that that > prefix is ::/0 in the case of default route (RFC). We don't see a > simple means to optimize the format of the Route Prefix Option > (including the mandatory 136bits) of the current route-option draft. > I don't agree with your assessment of waste of memory and bandwidth. This usage of bandwidth is completly noise compared to a single http request on the wire. For implementations, simplicity has benefits, including memory usage. (i.e. all routes are from a single DHCPv6 codepoint makes the implementation simpler, therefore most likely will consume ->less<- memory by combining the default route with other routes into a single dhcpv6 codepoint.) Therefore, I don't agree with your assessment about memory and bandwidth. Marc. > - the default route is special ("when everything else fails"), it is > not a simple prefix-nexthop route, because: > > - the default route appears in a linux routing table as another typical > route but it appears as well in the mandatory ND Default Router List > associated with more parameters (actually dereferenced pointers to > the Neighbor Cache). > > - the default route is better if it uses a Lifetime. It is assumed ND > is already implemented by the vast majority of IPv6 Hosts. (1) The > current route-option draft mentions Lifetime to be managed according > to general events of DHCP (and not of ND) - this may lead to > incoherent behaviour when both DHCP and ND are run on same Host. (2) > The Lifetime of DHCP is on 32bits whereas of ND is on 16bit. > > - it may be advantageous to communicate the MAC address of the gw of > the default route, with DHCP. This may speed up implementation, > because it avoids the Host to need to perform NS/NA for the IP > address of the gw of the default route. The draft route-option does > not communicate a MAC address. > > - the route-option draft can communicate several default routes as > follows: nexthop-prefix, nexthop-prefix,... However, a more > efficient scheme is possible as follows: 1bit, nexthop, nexthop,... > > - the scope of the route-option draft reads as environments where > routing protocols are more appropriate, whereas a more reduced scope > could be to focus exclusively on the obtention of the default route > as part of basic IP connectivity (not necessarily the complex > topologies afforded by routing protocols). > > We believe a better technique is possible to communicate default route > with DHCPv6. > > What do people think about these comments? > > Yours, > > Alex > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif -- ========= IETF81 Quebec city: http://ietf81.ca IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca DTN Implementation: http://postellation.viagenie.ca NAT64-DNS64 Opensource: http://ecdysis.viagenie.ca Space Assigned Number Authority: http://sanaregistry.org From Ted.Lemon@nominum.com Tue Aug 2 08:43:39 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 226AF11E807B for ; Tue, 2 Aug 2011 08:43:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.478 X-Spam-Level: X-Spam-Status: No, score=-106.478 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wtS7pPfgqqJs for ; Tue, 2 Aug 2011 08:43:38 -0700 (PDT) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by ietfa.amsl.com (Postfix) with ESMTP id 349D421F84BF for ; Tue, 2 Aug 2011 08:43:32 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKTjgbJliKxmpHiNkUAcS4OmjI7TWF5d+0@postini.com; Tue, 02 Aug 2011 08:43:42 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 922741B819A for ; Tue, 2 Aug 2011 08:43:31 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id D0A1819005D; Tue, 2 Aug 2011 08:43:29 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.01.0289.001; Tue, 2 Aug 2011 08:43:24 -0700 From: Ted Lemon To: Marc Blanchet Thread-Topic: [mif] Comments about default route and draft-ietf-mif-dhcpv6-route-option-02 Thread-Index: AQHMUSf8EeUO6S0EmUqrEB5G+j+sPZUKJTwAgAADngA= Date: Tue, 2 Aug 2011 15:43:23 +0000 Message-ID: <1185116F-C8B3-4EF2-AEAA-CE6B71E9EAA9@nominum.com> References: <4E38162B.1040507@gmail.com> <4E381812.7040802@viagenie.ca> In-Reply-To: <4E381812.7040802@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.162.214.218] Content-Type: multipart/alternative; boundary="_000_1185116FC8B34EF2AEAACE6B71E9EAA9nominumcom_" MIME-Version: 1.0 Cc: "" Subject: Re: [mif] Comments about default route and draft-ietf-mif-dhcpv6-route-option-02 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 15:43:39 -0000 --_000_1185116FC8B34EF2AEAACE6B71E9EAA9nominumcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Aug 2, 2011, at 11:30 AM, Marc Blanchet wrote: I don't agree with your assessment of waste of memory and bandwidth. This usage of bandwidth is completly noise compared to a single http reques= t on the wire. Calling this a bandwidth issue is kind of a misnomer. This is really an i= ssue of space in the DHCPv6 packet. It's a UDP packet, of limited size, a= nd it's not completely unreasonable to want to save 9 bytes in it. Having said that, I find this argument unconvincing, for the simple reason = that when you count the additional overhead of sending two options, you've = already lost four of those nine bytes. The other argument is about lifetimes. But DHCP already has lifetimes; if= this is unclear in the draft, perhaps the draft needs to be made more clea= r. I haven't read it with this question in mind (indeed, I haven't read i= t in over a year) so I can at least imagine that this is a valid criticism,= but if it is an accurate criticism, it is valid not only for the default r= oute, but for all other routes as well, and so it needs to be addressed in = the current draft. --_000_1185116FC8B34EF2AEAACE6B71E9EAA9nominumcom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
On Aug 2, 2011, at 11:30 AM, Marc Blanchet wrote:
I don't agree with your assessment of waste of memory and bandwidth.
This usage of bandwidth is completly noise compared to a single http reques= t on the wire.

Calling this a bandwidth issue is kind of a misnomer.   This is r= eally an issue of space in the DHCPv6 packet.   It's a UDP packet, of = limited size, and it's not completely unreasonable to want to save 9 bytes = in it.

Having said that, I find this argument unconvincing, for the simple re= ason that when you count the additional overhead of sending two options, yo= u've already lost four of those nine bytes.

The other argument is about lifetimes.   But DHCP already has lif= etimes; if this is unclear in the draft, perhaps the draft needs to be made= more clear.   I haven't read it with this question in mind (indeed, I= haven't read it in over a year) so I can at least imagine that this is a valid criticism, but if it is an accurate = criticism, it is valid not only for the default route, but for all other ro= utes as well, and so it needs to be addressed in the current draft.

--_000_1185116FC8B34EF2AEAACE6B71E9EAA9nominumcom_-- From Maximilien.MOUTON@cea.fr Wed Aug 3 09:25:15 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEC3F21F8ADC for ; Wed, 3 Aug 2011 09:25:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.815 X-Spam-Level: X-Spam-Status: No, score=-1.815 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tsqktkZAmdqg for ; Wed, 3 Aug 2011 09:25:15 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.144]) by ietfa.amsl.com (Postfix) with ESMTP id 2D4AD21F8A70 for ; Wed, 3 Aug 2011 09:25:13 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.2) with ESMTP id p73GPPfg031545 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 3 Aug 2011 18:25:25 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id p73GPOmd020727; Wed, 3 Aug 2011 18:25:24 +0200 (envelope-from Maximilien.MOUTON@cea.fr) Received: from EXCAH-B2.intra.cea.fr (excah-b2.intra.cea.fr [132.166.88.87]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id p73GPOAt019083; Wed, 3 Aug 2011 18:25:24 +0200 Received: from EXDAG0-A3.intra.cea.fr ([fe80::25a1:c396:2106:4c5b]) by EXCAH-B2.intra.cea.fr ([fe80::6d9a:7f48:7b8f:6abc%12]) with mapi id 14.01.0270.001; Wed, 3 Aug 2011 18:25:24 +0200 From: MOUTON Maximilien To: Ted Lemon , Marc Blanchet Thread-Topic: [mif] Comments about default route and draft-ietf-mif-dhcpv6-route-option-02 Thread-Index: AQHMUfnyHVhCN0zYbUi6PGYhm8FBPg== Date: Wed, 3 Aug 2011 16:25:23 +0000 Message-ID: References: <4E38162B.1040507@gmail.com> <4E381812.7040802@viagenie.ca> <1185116F-C8B3-4EF2-AEAA-CE6B71E9EAA9@nominum.com> In-Reply-To: <1185116F-C8B3-4EF2-AEAA-CE6B71E9EAA9@nominum.com> Accept-Language: en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [132.166.88.105] x-tm-as-product-ver: SMEX-10.0.0.4152-6.800.1017-18300.007 x-tm-as-result: No--51.553800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_C99531C79A5ECB40A08BBB0CEFFE26009A18EXDAG0A3intraceafr_" MIME-Version: 1.0 Cc: "" Subject: Re: [mif] Comments about default route and draft-ietf-mif-dhcpv6-route-option-02 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 16:25:16 -0000 --_000_C99531C79A5ECB40A08BBB0CEFFE26009A18EXDAG0A3intraceafr_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello MIF working group, Marc and Ted, > On Aug 2, 2011, at 11:30 AM, Marc Blanchet wrote: >> I don't agree with your assessment of waste of memory and >> bandwidth. This usage of bandwidth is completly noise compared to >> a single http request on the wire. I agree a single http request is quite bigger than these 136 bits. But for some deployment scenarios, economizing the sending of 136 bits is useful (think resource limited sensor networks, no http traffic, but single heartbeat temperature samples every 10s.) Ted Lemon wrote: > Calling this a bandwidth issue is kind of a misnomer. This is > really an issue of space in the DHCPv6 packet. It's a UDP packet, of > limited size, and it's not completely unreasonable to want to save 9 > bytes in it. We grant we should not have called this issue a waste of memory and bandwidth but rather a waste of place in DHCPv6 packet. (one would also notice that since a default router doesn't need a metric, the metric 1byte field could be saved as well, thus the total unnecessary place is 10 bytes for a default router.) > Having said that, I find this argument unconvincing, for the simple > reason that when you count the additional overhead of sending two > options, you've already lost four of those nine bytes. In a sense yes, two options rather than one is consuming additional header. But not necessarily. We save at least 6bytes for each default router encoded, if we use default router list option (draft-mouton), and often even more. Here is why: imagine the route option contains only one default router and compare the route-option encoding with using default router list option we propose. The route-option encoding is 46 bytes, whereas draft-mouton is 23 bytes (half of it). route option route option header =3D 4 bytes next hop sub option header =3D 4 bytes next hop addr =3D 16 bytes route prefix sub option header =3D 4 bytes prefix length + metric + prefix =3D 18 bytes total =3D 46 bytes default router list option default router list option header =3D 4 bytes default router address =3D 16 bytes router lifetime + link layer address length =3D 3 bytes total =3D 23 bytes The difference draft-mouton vs route-option for encoding one default route is not just 9/10 bytes but 23. And, while saving these 23 bytes the draft-mouton still communicates the lifetime too. > The other argument is about lifetimes. But DHCP already has > lifetimes; Yes, actually DHCPv6 defines 4-byte lifetimes used in IA address option and T1/T2 mechanism of IA_NA in the same manner than neighbor discovery protocol defines valid and preferred lifetime in prefix information option. > if this is unclear in the draft, perhaps the draft needs to be made > more clear. Actually the draft is relatively clear. One aspect is this. route-option draft says: > One notable exception with respect to [RFC4191] is however that a > Route Lifetime element is not defined. I do not agree with this. route-option draft says: > The information conveyed by the DHCPv6 Route Option is considered > valid until changed or refreshed by general events that trigger > DHCPv6 or route table state changes on a node, thus not requiring a > specific route lifetime. Yes, this makes sense, but does not work consistently with ND. > I haven't read it with this question in mind (indeed, I haven't read > it in over a year) so I can at least imagine that this is a valid > criticism, but if it is an accurate criticism, it is valid not only > for the default route, but for all other routes as well, and so it > needs to be addressed in the current draft. Yes and no, the lifetime format mentioned above fits for route lifetime. But the default router lifetime corresponds to the router lifetime defined in rfc 4861 section 4.2, a 2-byte field which maximum value defined in section 6 is 9000 seconds (not for other routes). Thank you for your comments. I would like to ask you and the group about the other comments Alex and myself raised about route-option draft (MAC address, scope generic vs basic connectivity)? Maximilien --_000_C99531C79A5ECB40A08BBB0CEFFE26009A18EXDAG0A3intraceafr_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello MIF = working group, Marc and Ted,

 = ;

> On Au= g 2, 2011, at 11:30 AM, Marc Blanchet wrote:

>> I= don't agree with your assessment of waste of memory and

>> b= andwidth. This usage of bandwidth is completly noise compared to=

>> a= single http request on the wire.

 = ;

I agree a = single http request is quite bigger than these 136 bits. But

for some d= eployment scenarios, economizing the sending of 136 bits is

useful (th= ink resource limited sensor networks, no http traffic, but

single hea= rtbeat temperature samples every 10s.)

 = ;

Ted Lemon = wrote:

> Calli= ng this a bandwidth issue is kind of a misnomer.   This is

> reall= y an issue of space in the DHCPv6 packet. It's a UDP packet, of<= /span>

> = limited size, and it's not completely unreasonable to want to save 9<= /o:p>

> = bytes in it.

 = ;

We grant w= e should not have called this issue a waste of memory and=

bandwidth = but rather a waste of place in DHCPv6 packet.

(one would= also notice that since a default router doesn't need a

metric, th= e metric 1byte field could be saved as well, thus the total

unnecessar= y place is 10 bytes for a default router.)

 = ;

> Havin= g said that, I find this argument unconvincing, for the simple

> reaso= n that when you count the additional overhead of sending two

> optio= ns, you've already lost four of those nine bytes.

 = ;

In a sense= yes, two options rather than one is consuming additional header.

 = ;

But not ne= cessarily.

 = ;

We save at= least 6bytes for each default router encoded, if we use<= /p>

default ro= uter list option (draft-mouton), and often even more.

 = ;

Here is wh= y: imagine the route option contains only one default

router and= compare the route-option encoding with using default router

list optio= n we propose.

 = ;

The route-= option encoding is 46 bytes, whereas draft-mouton is 23 bytes

(half of i= t).

 = ;

route opti= on

 = ;

route opti= on header =3D  4 bytes

next hop s= ub option header =3D  4 bytes

next hop a= ddr =3D 16 bytes

route pref= ix sub option header =3D  4 bytes

prefix len= gth + metric + prefix =3D 18 bytes

total =3D = 46 bytes

 &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;   

default ro= uter list option

 = ;

default ro= uter list option header =3D  4 bytes

default ro= uter address =3D 16 bytes

router lif= etime + link layer address length =3D  3 bytes

total =3D = 23 bytes

 = ;

The differ= ence draft-mouton vs route-option for encoding one default

route is n= ot just 9/10 bytes but 23.

 = ;

And, while= saving these 23 bytes the draft-mouton still communicates the

lifetime t= oo.

 = ;

> The o= ther argument is about lifetimes.   But DHCP already has

> lifet= imes;

 = ;

Yes, actua= lly DHCPv6 defines 4-byte lifetimes used in IA address option

and T1/T2 = mechanism of IA_NA in the same manner than neighbor discovery

protocol d= efines valid and preferred lifetime in

prefix inf= ormation option.

 = ;

> if th= is is unclear in the draft, perhaps the draft needs to be made

> more = clear.

 = ;

Actually t= he draft is relatively clear.

 = ;

One aspect= is this.  route-option draft says:

> One n= otable exception with respect to [RFC4191] is however that a

> Route= Lifetime element is not defined.

 = ;

I do not a= gree with this.

 = ;

route-opti= on draft says:

> The i= nformation conveyed by the DHCPv6 Route Option is considered

> valid= until changed or refreshed by general events that trigger

> DHCPv= 6 or route table state changes on a node, thus not requiring a

> speci= fic route lifetime.

 = ;

Yes, this = makes sense, but does not work consistently with ND.

 = ;

> I hav= en't read it with this question in mind (indeed, I haven't read

> it in= over a year) so I can at least imagine that this is a valid

> criti= cism, but if it is an accurate criticism, it is valid not only

> for t= he default route, but for all other routes as well, and so it

> needs= to be addressed in the current draft.

 = ;

Yes and no= , the lifetime format mentioned above fits for route lifetime.

But the de= fault router lifetime corresponds to the router lifetime<= /p>

defined in= rfc 4861 section 4.2, a 2-byte field which maximum

value defi= ned in section 6 is 9000 seconds (not for other routes).<= /p>

 = ;

Thank you = for your comments.

 = ;

I would li= ke to ask you and the group about the other comments Alex and

myself rai= sed about route-option draft (MAC address, scope generic vs

basic connectivity)?=

 <= /p>

Maximilien

--_000_C99531C79A5ECB40A08BBB0CEFFE26009A18EXDAG0A3intraceafr_-- From denghui02@gmail.com Fri Aug 12 16:34:06 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A0CA21F88A1 for ; Fri, 12 Aug 2011 16:34:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.523 X-Spam-Level: X-Spam-Status: No, score=-103.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DHEWi5GlfS4W for ; Fri, 12 Aug 2011 16:34:05 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 52A3F21F888A for ; Fri, 12 Aug 2011 16:34:05 -0700 (PDT) Received: by wwf5 with SMTP id 5so2337518wwf.13 for ; Fri, 12 Aug 2011 16:34:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=eTn8SUMArsYCt9D0oiOCFa2kPd/oufuBbfJpbsAvz4o=; b=qMSB+2sDpNMQzvBS4jE7/fBKV82tCRDMvDFykMjHEGwCX2zFVetKN+F7NCBOCKsbZp SXStMAFmhu4wmCkVGWw4Z9oSvk6d06OmXKD97jb27idIv/+pLIYqv+DY3fpfQ5gTfgAS 9LA3f+PBS8Ez+6TDeYSGYnTWD5dRILArMhU84= MIME-Version: 1.0 Received: by 10.216.24.30 with SMTP id w30mr3390373wew.68.1313192081441; Fri, 12 Aug 2011 16:34:41 -0700 (PDT) Received: by 10.216.25.204 with HTTP; Fri, 12 Aug 2011 16:34:41 -0700 (PDT) In-Reply-To: <4271D8B5-93A8-4D4D-99BA-957FC85C294E@nominum.com> References: <5D36713D8A4E7348A7E10DF7437A4B920122BF40@SZXEML506-MBS.china.huawei.com> <4271D8B5-93A8-4D4D-99BA-957FC85C294E@nominum.com> Date: Sat, 13 Aug 2011 07:34:41 +0800 Message-ID: From: Hui Deng To: MIF Mailing List Content-Type: multipart/alternative; boundary=0016367f9b768943be04aa575b67 Subject: [mif] Fwd: [dhcwg] Review of draft-ietf-mif-dhcpv6-route-option X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 23:34:06 -0000 --0016367f9b768943be04aa575b67 Content-Type: text/plain; charset=ISO-8859-1 just forwarding to MIF mailing list for reference ---------- Forwarded message ---------- From: Ted Lemon Date: 2011/8/13 Subject: Re: [dhcwg] Review of draft-ietf-mif-dhcpv6-route-option To: Sheng Jiang Cc: dhc WG On Aug 12, 2011, at 5:40 AM, Sheng Jiang wrote: The major issue I have for this draft is: why design an IA container if "client will never use more than one IA_RT" (stated in this draft) and it has only one sub-option - Next Hop option. For me, it seems more explicit and simple to directly define Next Hop Option and allow multiple Next Hop Option if needed. If it really is the case that there is only going to be one suboption, I think you are correct. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg --0016367f9b768943be04aa575b67 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable just forwarding to MIF mailing list for reference

---------- Forwarded message ----------
From:= Ted Lemon <Ted.Lemon@nominum.com>
D= ate: 2011/8/13
Subject: Re: [dhcwg] Review of draft-ietf-mif-dhcpv6-route-option
To: Sh= eng Jiang <jiangsheng@huawei.co= m>
Cc: dhc WG <dhcwg@ietf.or= g>


On Aug 12, 2011, at 5:40 AM, Sheng Jiang wrote:
The major issue I have for th= is draft is: why design an IA container if "client will never use more= than one IA_RT" (stated in this draft) and it has only one sub-option= - Next Hop option. For me, it seems more explicit and simple to directly d= efine Next Hop Option and allow multiple Next Hop Option if needed.<= /blockquote>

If it really is the case that there is only going to be one suboption,= I think you are correct.


_______________________________________________dhcwg mailing list
dhcwg@ietf.org=
https://www.ietf.org/mailman/listinfo/dhcwg


--0016367f9b768943be04aa575b67-- From wdec.ietf@gmail.com Thu Aug 18 05:11:07 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1201D21F8A6C for ; Thu, 18 Aug 2011 05:11:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.51 X-Spam-Level: X-Spam-Status: No, score=-3.51 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vXqLThsUofQb for ; Thu, 18 Aug 2011 05:11:06 -0700 (PDT) Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by ietfa.amsl.com (Postfix) with ESMTP id 20B6721F871E for ; Thu, 18 Aug 2011 05:11:06 -0700 (PDT) Received: by pzk33 with SMTP id 33so4833267pzk.18 for ; Thu, 18 Aug 2011 05:12:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rjn3RGylg1sENbSDyv2+yu+ToC/1Vmc+J8nYBoFJggY=; b=QMYMm6U7EXjfl5pBdq97ANVjDAQZgVnql2PY+B0d4pleJtpC3iO7gX5XrmT6RFJvL3 p2SvH4HMGByJ5AhEyrN6yCcWIGOwZ/hwl4sNmce6cVnWFHxwxEez7l4LBaMnuTjreAJY wfnmaGU8lB7l3s/Bjt00szlWPQDAF49/dkEzA= MIME-Version: 1.0 Received: by 10.142.201.6 with SMTP id y6mr344205wff.314.1313669519980; Thu, 18 Aug 2011 05:11:59 -0700 (PDT) Received: by 10.142.211.4 with HTTP; Thu, 18 Aug 2011 05:11:59 -0700 (PDT) In-Reply-To: <4E381663.7070109@gmail.com> References: <4E381663.7070109@gmail.com> Date: Thu, 18 Aug 2011 14:11:59 +0200 Message-ID: From: Wojciech Dec To: Alexandru Petrescu Content-Type: multipart/alternative; boundary=000e0cd32be017391004aac685af Cc: mif Subject: Re: [mif] Announcing draft-mouton-mif-dhcpv6-drlo-00 about default route with DHCPv6 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 12:11:07 -0000 --000e0cd32be017391004aac685af Content-Type: text/plain; charset=ISO-8859-1 Hello Alex, reading through the draft, other than it proposing a new option with a different format, could you elaborate on why/what is the issue in http://tools.ietf.org/html/draft-ietf-mif-dhcpv6-route-option-02 for conveying the default router info (which the draft already covers)? Thanks, Wojciech. On 2 August 2011 17:23, Alexandru Petrescu wrote: > Dear MIF, > > We would like to announce a new draft focusing to offer default route > with DHCPv6: > > "Default Router List Option for DHCPv6 (DRLO)" > draft-mouton-mif-dhcpv6-drlo-**00.txt > http://tools.ietf.org/html/**draft-mouton-mif-dhcpv6-drlo-**00.txt > > Thank you in advance for commenting on this draft. > > Alex and Maximilien > > ------------------------------**------------------------------**-------- > Implementation Details > > A prototype linux implementation is ongoing, and modifies ISC Client and > Server; Relay works unmodified. > > A wireshark capture is attached (dissector code available upon request). > > Server uses a new pattern of 'format codes' "6SmMoA", and the conf file > says: > [...] > >> option dhcp6.default-router 2002:c130:13c1:11f::ff 8400 >> 00:07:32:06:7e:72,2002:c130:**13c1:11f:13c1:11f::fe 88 >> 00:07:32:06:7e:73 ,2002:c130:13c1:11f::f5 8300 ; >> > [...] > > Client conf file says: > >> interface "eth0"{ request >> dhcp6.domain-search,dhcp6.**name-servers,dhcp6.default-**router; } >> > Client says: > >> RCV: X-- Server ID: 00:01:00:01:15:67:c9:7d:00:12:**3f:1c:a2:95 >> RCV: | | X-- TEST_AJOUT eth0 et 0 et 2. >> RCV: | | X-- DEFAULT_ROUTER_ADDR 2002:c130:13c1:11f::ff. >> RCV: | | | X-- Default_router_lifetime 8000. >> RCV: | | | X-- Default_router_link_layer_addr 00:22:68:17:59:ae. >> RCV: | | X-- TEST_AJOUT eth0 et 0 et 2. >> RCV: | | X-- DEFAULT_ROUTER_ADDR 2002:c130:13c1:11f::fe. >> RCV: | | | X-- Default_router_lifetime 8400. >> RCV: | | | X-- Default_router_link_layer_addr 00:07:32:06:7e:72. >> RCV: Advertisement recorded. >> > > After execution of the DHCP exchange, the neigh cache is (note "expires" > corresponding to the lifetime): > >> # ip -6 route show >> > [...] > >> default via 2002:c130:13c1:11f::ff dev eth0 proto kernel metric 1024 >> expires 7752sec mtu 1500 advmss 1440 hoplimit 0 >> > [...] > > Thank you for considering this draft. > > Alex > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > > --000e0cd32be017391004aac685af Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello Alex,

reading through the draft, other than it proposing a new= option with a different format, could you elaborate on why/what is the iss= ue in http://tools.ietf.org/html/draft-ietf-mif-dhcpv6-route-option-02 for conveying the default router info (which the draft already covers)?
Thanks,
Wojciech.

On 2 August 2011= 17:23, Alexandru Petrescu <alexandru.petrescu@gmail.com> wrote:
Dear MIF,

We would like to announce a new draft focusing to offer default route
with DHCPv6:

=A0 =A0 =A0 =A0 =A0 "Default Router List Option for DHCPv6 (DRLO)&quo= t;
=A0 =A0 =A0 =A0 =A0 =A0 =A0 draft-mouton-mif-dhcpv6-drlo-00.txt
http://tools.ietf.org/html/draft-mouton-mif-dhcpv6= -drlo-00.txt

Thank you in advance for commenting on this draft.

Alex and Maximilien

-------------------------------------------------------------= -------
Implementation Details

A prototype linux implementation is ongoing, and modifies ISC Client and Server; Relay works unmodified.

A wireshark capture is attached (dissector code available upon request).
Server uses a new pattern of 'format codes' "6SmMoA", and= the conf file
says:
[...]
option dhcp6.default-router 2002:c130:13c1:11f::ff 8400
00:07:32:06:7e:72,2002:c130:13c1:11f:13c1:11f::fe 88
00:07:32:06:7e:73 ,2002:c130:13c1:11f::f5 8300 ;
[...]

Client conf file says:
interface "eth0"{ request
dhcp6.domain-search,dhcp6.name-servers,dhcp6.default-router; = }
Client says:
RCV: =A0X-- Server ID: 00:01:00:01:15:67:c9:7d:00:12:3f:1c:a2:95
RCV: =A0| | X-- TEST_AJOUT eth0 et 0 et 2.
RCV: =A0| | X-- DEFAULT_ROUTER_ADDR 2002:c130:13c1:11f::ff.
RCV: =A0| | | X-- Default_router_lifetime 8000.
RCV: =A0| | | X-- Default_router_link_layer_addr 00:22:68:17:59:ae.
RCV: =A0| | X-- TEST_AJOUT eth0 et 0 et 2.
RCV: =A0| | X-- DEFAULT_ROUTER_ADDR 2002:c130:13c1:11f::fe.
RCV: =A0| | | X-- Default_router_lifetime 8400.
RCV: =A0| | | X-- Default_router_link_layer_addr 00:07:32:06:7e:72.
RCV: =A0Advertisement recorded.

After execution of the DHCP exchange, the neigh cache is (note "expire= s"
corresponding to the lifetime):
# ip -6 route show
[...]
default via 2002:c130:13c1:11f::ff dev eth0 =A0proto kernel metric 1024
expires 7752sec mtu 1500 advmss 1440 hoplimit 0
[...]

Thank you for considering this draft.

Alex

_______________________________________________
mif mailing list
mif@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/mif


--000e0cd32be017391004aac685af-- From alexandru.petrescu@gmail.com Thu Aug 18 07:28:04 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72E5021F8B5D for ; Thu, 18 Aug 2011 07:28:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.179 X-Spam-Level: X-Spam-Status: No, score=0.179 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, GB_ABOUTYOU=0.5, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nfSKdNeV6FMj for ; Thu, 18 Aug 2011 07:28:04 -0700 (PDT) Received: from smtp1-g21.free.fr (unknown [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id AAD6A21F8B42 for ; Thu, 18 Aug 2011 07:28:02 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id E1AC59400C4; Thu, 18 Aug 2011 16:28:48 +0200 (CEST) Message-ID: <4E4D219F.6070906@gmail.com> Date: Thu, 18 Aug 2011 16:28:47 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Wojciech Dec References: <4E381663.7070109@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 110817-1, 17/08/2011), Outbound message X-Antivirus-Status: Clean Cc: mif Subject: Re: [mif] Announcing draft-mouton-mif-dhcpv6-drlo-00 about default route with DHCPv6 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 14:28:04 -0000 Le 18/08/2011 14:11, Wojciech Dec a écrit : > Hello Alex, > > reading through the draft, other than it proposing a new option with > a different format, could you elaborate on why/what is the issue in > http://tools.ietf.org/html/draft-ietf-mif-dhcpv6-route-option-02 for > conveying the default router info (which the draft already covers)? Hello Wojciech, Thank you for reading our draft. With respect to your draft: indeed I believe there may some issues with the way it proposes to convey the default router info. For example, if I am not mistaken, your draft does not communicate the MAC address of the default router. Some times communicating the MAC address could speed up the process (avoid the subsequent NS/NA to solve the MAC address). Also, it does not treat of lifetime of this default route (although it does treat of DHCP lifetimes). An ND-lifetime could be necessary sometimes to the ND structures in the Default Router List. Your draft communicates the default route as 128 0 bits, which may be too long in certain constrained environments (it adds around half to size of the entire message). There may be other issues about your draft that I would like to discuss. On another hand, what do you think about our draft, other than just being a different format than yours? Then, do you think it may be useful to communicate MAC and ND-lifetime of default route? Thanks, Alex > > Thanks, Wojciech. > > On 2 August 2011 17:23, Alexandru Petrescu > > > wrote: > > Dear MIF, > > We would like to announce a new draft focusing to offer default route > with DHCPv6: > > "Default Router List Option for DHCPv6 (DRLO)" > draft-mouton-mif-dhcpv6-drlo-__00.txt > http://tools.ietf.org/html/__draft-mouton-mif-dhcpv6-drlo-__00.txt > > > Thank you in advance for commenting on this draft. > > Alex and Maximilien > > ------------------------------__------------------------------__-------- > > > Implementation Details > > A prototype linux implementation is ongoing, and modifies ISC Client > and Server; Relay works unmodified. > > A wireshark capture is attached (dissector code available upon > request). > > Server uses a new pattern of 'format codes' "6SmMoA", and the conf > file says: [...] > > option dhcp6.default-router 2002:c130:13c1:11f::ff 8400 > 00:07:32:06:7e:72,2002:c130:__13c1:11f:13c1:11f::fe 88 > 00:07:32:06:7e:73 ,2002:c130:13c1:11f::f5 8300 ; > > [...] > > Client conf file says: > > interface "eth0"{ request > dhcp6.domain-search,dhcp6.__name-servers,dhcp6.default-__router; } > > Client says: > > RCV: X-- Server ID: 00:01:00:01:15:67:c9:7d:00:12:__3f:1c:a2:95 > RCV: | | X-- TEST_AJOUT eth0 et 0 et 2. RCV: | | X-- > DEFAULT_ROUTER_ADDR 2002:c130:13c1:11f::ff. RCV: | | | X-- > Default_router_lifetime 8000. RCV: | | | X-- > Default_router_link_layer_addr 00:22:68:17:59:ae. RCV: | | X-- > TEST_AJOUT eth0 et 0 et 2. RCV: | | X-- DEFAULT_ROUTER_ADDR > 2002:c130:13c1:11f::fe. RCV: | | | X-- Default_router_lifetime 8400. > RCV: | | | X-- Default_router_link_layer_addr 00:07:32:06:7e:72. > RCV: Advertisement recorded. > > > After execution of the DHCP exchange, the neigh cache is (note > "expires" corresponding to the lifetime): > > # ip -6 route show > > [...] > > default via 2002:c130:13c1:11f::ff dev eth0 proto kernel metric 1024 > expires 7752sec mtu 1500 advmss 1440 hoplimit 0 > > [...] > > Thank you for considering this draft. > > Alex > > _______________________________________________ mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > > From denghui02@hotmail.com Fri Aug 26 08:44:41 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B679821F8C13 for ; Fri, 26 Aug 2011 08:44:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.739 X-Spam-Level: X-Spam-Status: No, score=-100.739 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mkbIheW0uqga for ; Fri, 26 Aug 2011 08:44:41 -0700 (PDT) Received: from col0-omc2-s8.col0.hotmail.com (col0-omc2-s8.col0.hotmail.com [65.55.34.82]) by ietfa.amsl.com (Postfix) with ESMTP id 3A7C721F8BD7 for ; Fri, 26 Aug 2011 08:44:41 -0700 (PDT) Received: from COL118-W22 ([65.55.34.71]) by col0-omc2-s8.col0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 26 Aug 2011 08:45:57 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_ac12a1be-5204-4e4c-81a0-8721fc425eeb_" X-Originating-IP: [220.175.150.141] From: Hui Deng To: , Date: Fri, 26 Aug 2011 23:45:57 +0800 Importance: Normal In-Reply-To: <0AB09EDBCD1C484EBE45978D62F3513C3CEC4C79@TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com> References: <0AB09EDBCD1C484EBE45978D62F3513C3CEC4C79@TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com> MIME-Version: 1.0 X-OriginalArrivalTime: 26 Aug 2011 15:45:57.0910 (UTC) FILETIME=[3F754360:01CC6407] Subject: [mif] MIF Minutes X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 15:44:41 -0000 --_ac12a1be-5204-4e4c-81a0-8721fc425eeb_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 8bit Hello all Please review the last IETF minutes, Feel free to let us know any corrections. http://www.ietf.org/proceedings/81/minutes/mif.txt thanks -Chairs --_ac12a1be-5204-4e4c-81a0-8721fc425eeb_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: 8bit
Hello all
 
Please review the last IETF minutes,
Feel free to let us know any corrections.
http://www.ietf.org/proceedings/81/minutes/mif.txt
 
thanks
 
-Chairs
 
--_ac12a1be-5204-4e4c-81a0-8721fc425eeb_-- From denghui02@gmail.com Fri Aug 26 08:47:26 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C49721F8B59 for ; Fri, 26 Aug 2011 08:47:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.31 X-Spam-Level: X-Spam-Status: No, score=-102.31 tagged_above=-999 required=5 tests=[AWL=-1.162, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qCVqSbor-gjl for ; Fri, 26 Aug 2011 08:47:26 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id B877721F899F for ; Fri, 26 Aug 2011 08:47:25 -0700 (PDT) Received: by wyg8 with SMTP id 8so2926781wyg.31 for ; Fri, 26 Aug 2011 08:48:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hlaasfWcQyu+vdU3PhjIy7yaoo7xa9Brg1unQPTC5hE=; b=siIpHJFemPWhDIOrVrNtmDsr20P27oJ5VLh9Jhpt1EjROAPW1SQXzy7uWr3oGX0yjW v1xPsy+eEVOJxbv4RPJ9q5xbtcWIfiKY6rinoVy/jorlodW5cAGYRPBu5q6sRjIO2xaB jeV+dP3EhfaLC9nxYLor4bZCrl6gHXo8bSt9s= MIME-Version: 1.0 Received: by 10.216.19.75 with SMTP id m53mr1879161wem.73.1314373719822; Fri, 26 Aug 2011 08:48:39 -0700 (PDT) Received: by 10.216.38.81 with HTTP; Fri, 26 Aug 2011 08:48:39 -0700 (PDT) In-Reply-To: References: <0AB09EDBCD1C484EBE45978D62F3513C3CEC4C79@TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com> Date: Fri, 26 Aug 2011 23:48:39 +0800 Message-ID: From: Hui Deng To: Hui Deng Content-Type: multipart/alternative; boundary=0016e64c3dbeac129704ab6a7a16 Cc: mif@ietf.org Subject: Re: [mif] MIF Minutes X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 15:47:26 -0000 --0016e64c3dbeac129704ab6a7a16 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable I forget to thank Christopher Palmer to take notes thanks a lot -Hui =D4=DA 2011=C4=EA8=D4=C226=C8=D5 =CF=C2=CE=E711:45=A3=ACHui Deng =D0=B4=B5=C0=A3=BA > Hello all > > Please review the last IETF minutes, > Feel free to let us know any corrections. > http://www.ietf.org/proceedings/81/minutes/mif.txt > > thanks > > -Chairs > > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > > --0016e64c3dbeac129704ab6a7a16 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable
I forget to thank Christopher Palmer to take notes
 =
thanks a lot<= /span>
 =
-Hui

 
=D4=DA 2011=C4=EA8=D4=C226=C8=D5 =CF=C2=CE=E711:= 45=A3=ACHui Deng <denghui02@hotmail.com>=D0=B4=B5=C0=A3=BA
Hello all
 
Please review the last IETF minutes= ,
Feel free to let us know any corrections.
http://www.ietf.org= /proceedings/81/minutes/mif.txt
 
thanks
 
-Chairs
 

____________________________________________= ___
mif mailing list
mif@ietf.org=
https://www.ietf.org/mailman/listinfo/mif


--0016e64c3dbeac129704ab6a7a16-- From denghui02@hotmail.com Mon Aug 29 00:30:17 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 492D421F8834 for ; Mon, 29 Aug 2011 00:30:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.391 X-Spam-Level: X-Spam-Status: No, score=-101.391 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8BqvKWZOWtFT for ; Mon, 29 Aug 2011 00:30:16 -0700 (PDT) Received: from col0-omc2-s6.col0.hotmail.com (col0-omc2-s6.col0.hotmail.com [65.55.34.80]) by ietfa.amsl.com (Postfix) with ESMTP id 455F521F8829 for ; Mon, 29 Aug 2011 00:30:16 -0700 (PDT) Received: from COL118-W59 ([65.55.34.71]) by col0-omc2-s6.col0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 29 Aug 2011 00:31:39 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_e1633dee-2319-437e-910d-1fc4be57c276_" X-Originating-IP: [221.130.253.135] From: Hui Deng To: , Margaret , Jari Arkko Date: Mon, 29 Aug 2011 15:31:39 +0800 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 29 Aug 2011 07:31:39.0934 (UTC) FILETIME=[B12A83E0:01CC661D] Subject: [mif] Last Call for MIF DNS server selection document X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2011 07:30:17 -0000 --_e1633dee-2319-437e-910d-1fc4be57c276_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 8bit Hello all, Based on the last IETF mif meeting, we are issueing working group last call for the document: http://tools.ietf.org/id/draft-ietf-mif-dns-server-selection-03.txt This is a 2 week LC, it will finish on September 12, Please send substantive review and editorial comments to mif@ietf.org, thanks, Margaret and Hui --_e1633dee-2319-437e-910d-1fc4be57c276_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: 8bit
Hello all,
 
Based on the last IETF mif meeting, we are issueing working group last call for the document:
http://tools.ietf.org/id/draft-ietf-mif-dns-server-selection-03.txt
 
This is a 2 week LC, it will finish on September 12,
Please send substantive review and editorial comments to mif@ietf.org,
 
thanks,
 
Margaret and Hui
 
--_e1633dee-2319-437e-910d-1fc4be57c276_-- From iesg-secretary@ietf.org Tue Aug 30 08:23:51 2011 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9097E21F8CAB; Tue, 30 Aug 2011 08:23:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cKyPZiTTYbKL; Tue, 30 Aug 2011 08:23:48 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 025A421F8CB4; Tue, 30 Aug 2011 08:23:47 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20110830152346.20573.61428.idtracker@ietfa.amsl.com> Date: Tue, 30 Aug 2011 08:23:46 -0700 Cc: mif mailing list , mif chair , RFC Editor Subject: [mif] Document Action: 'Current Practices for Multiple Interface Hosts' to Informational RFC (draft-ietf-mif-current-practices-12.txt) X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2011 15:23:51 -0000 The IESG has approved the following document: - 'Current Practices for Multiple Interface Hosts' (draft-ietf-mif-current-practices-12.txt) as an Informational RFC This document is the product of the Multiple Interfaces Working Group. The IESG contact persons are Jari Arkko and Ralph Droms. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-mif-current-practices/ Technical Summary An increasing number of hosts are operating in multiple-interface environments, where different network interfaces are providing unequal levels of service or connectivity. This document summarizes current practices in this area, and describes in detail how some common operating systems cope with these challenges. Working Group Summary There is a consensus in the MIF WG for publication as an informational RFC. Document Quality The document has gone through various reviews and a successful WGLC. Personnel Responsible AD is Jari Arkko and the document shepherd is Hui Deng.