From jouni.nospam@gmail.com Thu Dec 1 08:43:55 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 327B011E82A2 for ; Thu, 1 Dec 2011 08:43:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 zBP6tEtAV9ie for ; Thu, 1 Dec 2011 08:43:54 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6586C11E82A7 for ; Thu, 1 Dec 2011 08:43:54 -0800 (PST) Received: by lahj13 with SMTP id j13so959024lah.31 for ; Thu, 01 Dec 2011 08:43:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=i0KqnYLxtMGvRWZ09H96DTSvDSkjeVSThpwoDthHTiA=; b=NJfB4Eq9Aj5/2HCLcaCkW4+asExY0ofWcENHP2IUUoo81sd0ZUsSnYdnSJTMzpncJi sb6ZlWDR3rsMxoJz1eiY24lms2xZIlTBqdzcJTvBVePaHvgjFFQQr4EHmvLdRB9sirPR IIH35DA8/3rnqwvKUVXKt+gmPi85ENTQiFnK4= Received: by 10.152.104.20 with SMTP id ga20mr5230892lab.13.1322757833407; Thu, 01 Dec 2011 08:43:53 -0800 (PST) Received: from [10.37.43.191] ([77.95.242.69]) by mx.google.com with ESMTPS id pc8sm5635542lab.8.2011.12.01.08.43.35 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 01 Dec 2011 08:43:41 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: Date: Thu, 1 Dec 2011 18:43:26 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7C1F8DA5-357F-4403-BE0D-E72D425B71C9@gmail.com> References: <282BBE8A501E1F4DA9C775F964BB21FE3EB78C3C98@GRFMBX704BA020.griffon.local> <916CE6CF87173740BC8A2CE44309696204193417@008-AM1MPN1-053.mgdnok.nokia.com> <4EC512A2.2060509@gmail.com> <890A58CF-8EAD-4F92-9981-9B5AA07EBF00@nominum.com> <4EC63E26.70104@gmail.com> <86163A8F-8628-4F67-BE93-3747F95A2F52@nominum.com> <4ECB6EAE.2010701@gmail.com> <702C34B3-F6B7-4EFB-91D5-8538540534A1@nominum.com> <4ECBE3BE.5070501@gmail.com> <759E821F-B503-4C8D-A79B-5F9A68A3613F@nominum.com> To: mif@ietf.org X-Mailer: Apple Mail (2.1084) Subject: Re: [mif] Use cases for draft-ietf-mif-dhcpv6-route-option needed 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, 01 Dec 2011 16:43:55 -0000 On Nov 30, 2011, at 8:18 PM, Tao Sun wrote: > Forgot to include a website link in the previous email. Now I included = it. > =20 > Regards, > =20 > Tao Sun >=20 > On Thu, Dec 1, 2011 at 2:13 AM, Tao Sun wrote: > Hi All, > =20 > Thanks for the discussion. As one of the author of the draft, I would = like to share our view on DHCPv6 used case in three aspects. > *Network management and configuration. > 1. It is efficient for the network to configure this in a central = DHCPv6 server to do unified routing policy configuration. The gateways = (e.g., GGSN in cellular network) only need to perform DHCPv6 relay. Just want to point out that 3GPP specs do not define/mandate DHCPv6 = relay function in GGSN/PGW.. It is a server when seen from the UE point = of view. [snip] - JOuni From hisuntao@gmail.com Thu Dec 1 09:07: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 DF20D1F0C70 for ; Thu, 1 Dec 2011 09:07:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 YsZGuEBsHKTp for ; Thu, 1 Dec 2011 09:07:51 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id C1BBB1F0C71 for ; Thu, 1 Dec 2011 09:07:50 -0800 (PST) Received: by vcbfy13 with SMTP id fy13so1843821vcb.31 for ; Thu, 01 Dec 2011 09:07:50 -0800 (PST) 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=ubXXjIzwe/+dbdaMezLT2cRaSnC8ngtlUrAXeBf7mrc=; b=u+ALmZQudcJ90mHem0cV/R7BE1QAiIBCFrhVLViqjgQko2vOKj7qkWM64rlYL6jX9O NMGjL3crq+3KV2NUwZcux+pRQfqeiDKncUZ77LAAYDbCJy6/pwgOnNj2/2A00f61s8aY yxjO/+yX3pX4j+cwRGlq1YvChSTOutSdismxs= MIME-Version: 1.0 Received: by 10.52.24.13 with SMTP id q13mr6847937vdf.104.1322759270261; Thu, 01 Dec 2011 09:07:50 -0800 (PST) Received: by 10.220.194.133 with HTTP; Thu, 1 Dec 2011 09:07:49 -0800 (PST) In-Reply-To: References: <282BBE8A501E1F4DA9C775F964BB21FE3EB78C3C98@GRFMBX704BA020.griffon.local> <916CE6CF87173740BC8A2CE44309696204193417@008-AM1MPN1-053.mgdnok.nokia.com> <4EC512A2.2060509@gmail.com> <890A58CF-8EAD-4F92-9981-9B5AA07EBF00@nominum.com> <4EC63E26.70104@gmail.com> <86163A8F-8628-4F67-BE93-3747F95A2F52@nominum.com> <4ECB6EAE.2010701@gmail.com> <702C34B3-F6B7-4EFB-91D5-8538540534A1@nominum.com> <4ECBE3BE.5070501@gmail.com> <759E821F-B503-4C8D-A79B-5F9A68A3613F@nominum.com> Date: Fri, 2 Dec 2011 01:07:49 +0800 Message-ID: From: Tao Sun To: Lorenzo Colitti Content-Type: multipart/alternative; boundary=20cf3071cd006d621604b30ae42f Cc: "mif@ietf.org" Subject: Re: [mif] Use cases for draft-ietf-mif-dhcpv6-route-option needed 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, 01 Dec 2011 17:07:52 -0000 --20cf3071cd006d621604b30ae42f Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Thanks for the discussion. Inline please. On Thu, Dec 1, 2011 at 2:48 AM, Lorenzo Colitti wrote: > On Wed, Nov 30, 2011 at 10:13, Tao Sun wrote: > >> **Cellular network >> >> 1. In cellular network, DHCPv6 is used for IPv6 parameter >> configuration and RA is used for SLAAC of handset. This is start from 3G= PP >> release 8 (or earlier). >> >> 2. The network gateway in cellular network (e.g., GGSN) can >> naturally support DHCPv6 extension since the gateway acts as a DHCPv6 >> relay. However, it is very hard to update those gateways to use RA >> announcing the route information. >> >> 3. The handsets with MIF feature need to visit subscribed/operator >> provided service. Some traffic is routed to the operator=92s network thr= ough >> 3G interface instead of to Internet through WiFi. DHCPv6 will be used >> to configure these specific routes. >> > > You can already do this today with RIOs, and I don't see why there need t= o > be two ways of doing the same thing. Adding a different method to configu= re > the same information is twice the code and more than twice the complexity= , > since when you have two sources of information with different semantics y= ou > need to figure out how to merge them, what happens if they disagree, what > to do if one is wrong, what to do if one expires, and so on. > We can not do this today. As 1 and 2 mentioned, both the deployed gateway and the 3GPP specification need to be updated to use RIO. I agree we need to consider the disagree/confliction among policies. That is caused by the multiple interface feature. If you use RA for all the interfaces, the rule received may still conflict. Addressing the confliction is exactly what MIF WG shall consider IMHO. > Also, in the mobile case I don't understand how you would use a > different gateway anyway. The mobile network is a point-to-point link, so > there's no way to distinguish multiple gateways. How would you use this? > > There are two types of scenarios. 1) A host is connected to the mobile network and WiFi at the same time, a typical scenario of MIF. 2) A mobile host connects to multiple APNs simultaneously, i.e., multiple PDN connection is established. The type 2) scenrio is also considered to be addressed in the OPIIS (Operator Policies for IP Interface Selection) work item in 3GPP. > ***Broadband network >> >> 1. WiFi network. Some WiFi hotspots provide local services. The >> route configuration on RG is needed to direct some traffic to local netw= ork >> while other traffic to the Internet. >> > > I don't understand why you need host changes to do this. Since the hotspo= t > router is a router, it can simply forward the packets the right way by > itself. > > You may refer to the Section of 3.4 of this draft or Section 5.2 of RFC 4191. > 2. VPN network. When a user connect to enterprise VPN network, >> the routing of VPN traffic need to be configured. Due to the large numbe= r >> of such VPN network, we cannot assume all the VPN network only use RA. >> DHCPv6 provides another choice which may be preferred by the VPN network= . >> > > The rationale here seems to be that "if we create a new option, some > networks might use it". That's certainly true, but it doesn't provide a > compelling reason why we need the option in the first place. > To us, its a compelling reason due to the network managment/operation, per-subscriber service, foresee burden of modification to existing gateway and specifications. Best Regards, Tao --20cf3071cd006d621604b30ae42f Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Thanks for the discussion. Inline please.

On Thu, Dec 1, 2011 at 2:48 AM, Lorenzo Colitti = <lorenzo@google.= com> wrote:
On Wed, Nov 30, 2011 at 10:13, Tao Sun = <hisuntao@gmail.= com> wrote:
**Cellular network

1.=A0=A0=A0=A0=A0=A0 In cellular network, DHCPv6 is used for= IPv6 parameter configuration and RA is used for SLAAC of handset. This is = start from 3GPP release 8 (or earlier).

2.=A0=A0=A0=A0=A0=A0 The network gateway in cellular network= (e.g., GGSN) can naturally support DHCPv6 extension since the gateway acts= as a DHCPv6 relay. However, it is very hard to update those gateways to us= e RA announcing the route information.

3.=A0=A0=A0=A0=A0=A0 The handsets with MIF feature need to v= isit subscribed/operator provided service. Some traffic is routed to the op= erator=92s network through 3G interface instead of to Internet through WiFi= . =A0DHCPv6 will be used to configure these specific routes.


You can already do this today with RIOs, and=A0I don't see why the= re need to be two ways of doing the same thing.=A0Adding a different method= to configure the same information is=A0twice the code and more than twice = the complexity, since when you have two sources of information with differe= nt semantics you need to figure out how to merge them, what happens if they= disagree, what to do if one is wrong, what to do if one expires, and so on= .
We can not do=A0this today. As 1 and 2 mentioned, both the deployed ga= teway and the 3GPP specification need to be updated to use RIO.
I agree we need to consider the disagree/confliction among policies. T= hat is caused by the multiple interface feature. If you use RA for all the = interfaces, the rule received may still conflict. Addressing the conflictio= n is exactly what MIF WG shall consider IMHO.

=A0
Also, in the mobile case I don't understand how you would use a di= fferent gateway anyway.=A0The mobile network is a point-to-point link, so t= here's no way to distinguish multiple gateways. How would you use this?=
=A0=A0
There are two types of scenarios. 1) A host is connected=A0to the=A0mo= bile network and WiFi at the same time, a typical scenario of MIF. 2) A mob= ile host connects to multiple APNs simultaneously, i.e., multiple PDN conne= ction is established.=A0The type=A02)=A0scenrio is also considered to be ad= dressed=A0in the OPIIS (Operator Policies for IP In= terface Selection) work item in 3GPP.
=A0

<= font size=3D"3">***Broadband network

1.=A0=A0=A0=A0=A0=A0 WiFi network. Some WiFi hotspots provid= e local services. The route configuration on RG is needed to direct some tr= affic to local network while other traffic to the Internet.


I don't understand why you need host changes to do this. Since the= hotspot router is a router, it can simply forward the packets the right wa= y by itself.
=A0
You may refer to the=A0 Section of 3.4 of this draft or Section 5.2 of= RFC 4191.
=A0

2.=A0=A0=A0=A0=A0=A0 VPN network. When a user connect to ent= erprise VPN network, the routing of VPN traffic need to be configured. Due = to the large number of such VPN network, we cannot assume all the VPN netwo= rk only use RA. DHCPv6 provides another choice which may be preferred by th= e VPN network.


The rationale here seems to be that "if we create a new option, s= ome networks might use it". That's certainly true, but it doesn= 9;t provide a compelling reason why we need the option in the first place.<= /div>
To us, its a compelling reason due to the network managment/operation,= per-subscriber service, foresee burden of modification to existing gateway= and specifications.
=A0
Best Regards,
=A0
Tao
--20cf3071cd006d621604b30ae42f-- From hisuntao@gmail.com Thu Dec 1 09:24:11 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 0201F11E8176 for ; Thu, 1 Dec 2011 09:24:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[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 xBobIbk8PmTW for ; Thu, 1 Dec 2011 09:24:09 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4F68511E80E0 for ; Thu, 1 Dec 2011 09:24:09 -0800 (PST) Received: by vcbfy13 with SMTP id fy13so1862584vcb.31 for ; Thu, 01 Dec 2011 09:24:08 -0800 (PST) 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=A6VhbkSW+WZHqpE6POgjKQymlcN5QoFAGyeRF9SRWzY=; b=Nb3YXlQgqs7U8HieyfpAaDg/8gTnZB9NhHJG+GQrWnYzKA30svjvvmvasmnkS4XPBt BrqyQI7bpuosuzvUvOJStRWHdOvVXO1jiSq5ho7OBssuYapGxDTc+CZHaJYx7pXAeFJw AnlSC1EfbiCjIyVK48vJTqkrfcb1yDuNeaBk0= MIME-Version: 1.0 Received: by 10.220.232.9 with SMTP id js9mr1421277vcb.19.1322760248357; Thu, 01 Dec 2011 09:24:08 -0800 (PST) Received: by 10.220.194.133 with HTTP; Thu, 1 Dec 2011 09:24:08 -0800 (PST) In-Reply-To: <7C1F8DA5-357F-4403-BE0D-E72D425B71C9@gmail.com> References: <282BBE8A501E1F4DA9C775F964BB21FE3EB78C3C98@GRFMBX704BA020.griffon.local> <916CE6CF87173740BC8A2CE44309696204193417@008-AM1MPN1-053.mgdnok.nokia.com> <4EC512A2.2060509@gmail.com> <890A58CF-8EAD-4F92-9981-9B5AA07EBF00@nominum.com> <4EC63E26.70104@gmail.com> <86163A8F-8628-4F67-BE93-3747F95A2F52@nominum.com> <4ECB6EAE.2010701@gmail.com> <702C34B3-F6B7-4EFB-91D5-8538540534A1@nominum.com> <4ECBE3BE.5070501@gmail.com> <759E821F-B503-4C8D-A79B-5F9A68A3613F@nominum.com> <7C1F8DA5-357F-4403-BE0D-E72D425B71C9@gmail.com> Date: Fri, 2 Dec 2011 01:24:08 +0800 Message-ID: From: Tao Sun To: jouni korhonen Content-Type: multipart/alternative; boundary=14dae9cdbf65b9f1b004b30b1e0c Cc: mif@ietf.org Subject: Re: [mif] Use cases for draft-ietf-mif-dhcpv6-route-option needed 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, 01 Dec 2011 17:24:11 -0000 --14dae9cdbf65b9f1b004b30b1e0c Content-Type: text/plain; charset=ISO-8859-1 Hi Jouni, Thanks for the clarification. That is ture GGSN/PGW is not mandate to do relay. "May" instead of "shall" is used to describe GGSN/PGW's action. The only mandate is to use RA to obtain /64 prefix. Regards, Tao On Fri, Dec 2, 2011 at 12:43 AM, jouni korhonen wrote: > > > On Nov 30, 2011, at 8:18 PM, Tao Sun wrote: > > > Forgot to include a website link in the previous email. Now I included > it. > > > > Regards, > > > > Tao Sun > > > > On Thu, Dec 1, 2011 at 2:13 AM, Tao Sun wrote: > > Hi All, > > > > Thanks for the discussion. As one of the author of the draft, I would > like to share our view on DHCPv6 used case in three aspects. > > *Network management and configuration. > > 1. It is efficient for the network to configure this in a central DHCPv6 > server to do unified routing policy configuration. The gateways (e.g., GGSN > in cellular network) only need to perform DHCPv6 relay. > > Just want to point out that 3GPP specs do not define/mandate DHCPv6 relay > function in GGSN/PGW.. It is a server when seen from the UE point of view. > > [snip] > > - JOuni > > > > --14dae9cdbf65b9f1b004b30b1e0c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Jouni,
=A0
Thanks for the clarification. That is ture GGSN/PGW is not mandate to = do relay. "May" instead of "shall" is used to describe = GGSN/PGW's action.=A0The only mandate is to use RA to obtain /64 prefix= .
=A0
Regards,
=A0
Tao
On Fri, Dec 2, 2011 at 12:43 AM, jouni korhonen = <jouni.nospa= m@gmail.com> wrote:


On Nov 30, 2011, at 8:18 PM, Tao Sun wrote:
> Forgot to include a website link in the previous email. Now I includ= ed it.
>
> Regards,
>
> Tao Sun
>
> On = Thu, Dec 1, 2011 at 2:13 AM, Tao Sun <hisuntao@gmail.com> wrote:
> Hi All,
>
> Thanks for the discussion. As one of the autho= r of the draft, I would like to share our view on DHCPv6 used case in three= aspects.
> *Network management and configuration.
> 1. It is e= fficient for the network to configure this in a central DHCPv6 server to do= unified routing policy configuration. The gateways (e.g., GGSN in cellular= network) only need to perform DHCPv6 relay.

Just want to point out that 3GPP specs do not define/mandate DHCP= v6 relay function in GGSN/PGW.. It is a server when seen from the UE point = of view.

[snip]

- JOuni




--14dae9cdbf65b9f1b004b30b1e0c-- From hisuntao@gmail.com Thu Dec 1 09:45:47 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 C42C911E8231 for ; Thu, 1 Dec 2011 09:45:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[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 wU-Epaup0JHl for ; Thu, 1 Dec 2011 09:45:46 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id A471311E8219 for ; Thu, 1 Dec 2011 09:45:43 -0800 (PST) Received: by vcbfy13 with SMTP id fy13so1887008vcb.31 for ; Thu, 01 Dec 2011 09:45:42 -0800 (PST) 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=qR3aq9YacBlRhft7YBpBEqwcwsRuWgbXXaHQgI4mjDU=; b=OjToakFoLuabHQ9z0L4154jkNcVLfCQyYTHl8y6A+8hakFOqhYD5CbPf/8nAWo4iQz 8rIX80Alp525pXDZYKa7Rbyf0KctKKyx33zscS2UgtPKaj61ltf/YYBukag31JURjL36 KDpmxDqGz9BRBcO72O04qKDYcslq3QcHX0VpM= MIME-Version: 1.0 Received: by 10.52.29.97 with SMTP id j1mr7012299vdh.87.1322761541581; Thu, 01 Dec 2011 09:45:41 -0800 (PST) Received: by 10.220.194.133 with HTTP; Thu, 1 Dec 2011 09:45:41 -0800 (PST) In-Reply-To: References: <282BBE8A501E1F4DA9C775F964BB21FE3EB78C3C98@GRFMBX704BA020.griffon.local> <916CE6CF87173740BC8A2CE44309696204193417@008-AM1MPN1-053.mgdnok.nokia.com> <4EC512A2.2060509@gmail.com> <890A58CF-8EAD-4F92-9981-9B5AA07EBF00@nominum.com> <4EC63E26.70104@gmail.com> <86163A8F-8628-4F67-BE93-3747F95A2F52@nominum.com> <4ECB6EAE.2010701@gmail.com> <702C34B3-F6B7-4EFB-91D5-8538540534A1@nominum.com> <4ECBE3BE.5070501@gmail.com> <759E821F-B503-4C8D-A79B-5F9A68A3613F@nominum.com> <4ED6A08D.9090703@gmail.com> Date: Fri, 2 Dec 2011 01:45:41 +0800 Message-ID: From: Tao Sun To: Lorenzo Colitti Content-Type: multipart/alternative; boundary=20cf3079c0fccefa0604b30b6bf5 Cc: "mif@ietf.org" Subject: Re: [mif] Use cases for draft-ietf-mif-dhcpv6-route-option needed 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, 01 Dec 2011 17:45:47 -0000 --20cf3079c0fccefa0604b30b6bf5 Content-Type: text/plain; charset=ISO-8859-1 Thanks for the discussion. Inline please. On Thu, Dec 1, 2011 at 7:23 AM, Lorenzo Colitti wrote: > On Wed, Nov 30, 2011 at 13:30, Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: > >> To me this is a killer argument. A general solution that is applicable >> to all deployment scenarios is vastly better than a free-for all of >> vendor options, which will increase the implementation burden for >> everybody and reduce the chances of smooth zero-conf operation. >> > > Actually, what decreases the implementation burden is not having the > option at all. The use cases I've heard so far for this option are all a > bit specious and I think they are outweighed by the harm that would be > caused if this option were to get into general use. > Form the discussion in this thread, the use cases exist in BBF and cellular network, apply to host and RG/CPE and are met by individual user and network operators. To me, they are not specious. > > The reasoning goes something like this: > > 1. The option is defined. > 2. OS foo implements it. > 3. Some network, somewhere, decides that they're only going to use DHCPv6 > for routing, because they only support OS foo. > 4. Other OSes are forced to implement the option because if they don't, > they are at a disadvantage compared to OS foo > 5. Once all OSes implement it, some other network, somewhere else, decides > that they're only going to support DHCPv6 for routing because it's easier > and because it matches what they do in IPv4, so they turn off RAs. > You need not worry about turning off RAs. RA is mandated for mobile host to abtain /64 prefix in cellular network. While, for DHCPv6, you anyway need to switch on it IMHO. When you enable the tethering feature, the mobile host shall use DHCPv6 for prefix delegation. > Then we have a problem, because DHCPv6 has much less rich semantics than > RAs in the general case. A few examples: > > - DHCPv6 is static. A lease is a promise and it can't be deprecated except > by the server that originally made the promise. If that server is not > around any more, or if clients don't support reconfigure, it can't be > deprecated at all. You can work around this with short lease times, but > that creates a scaling problem on the DHCPv6 server, because it's > centralized. > - The way the standards and the clients are written, clients pick one > DHCPv6 advertise and stick to it. So they can't merge multiple sources of > information. > - DHCPv6 does not share fate with routing; in fact, it has no knowledge of > routing. > - The combination of the fact that you can't merge multiple sources of > information and the fact that you can only provide static information means > that you're basically forced to hand out stuff that doesn't change. If > you're using DHCPv6 to set the default router, that basically means you're > forced to use VRRP or NAT if you want any sort of redundancy. > > To me, the lack of functionality that will result if we take the path of > least resistance described above far outweighs the benefits of being able > to configure [default] routes and on-link prefixes on a per-host basis. You > can do this in lots of other ways, for example assigning the hosts you want > to treat differently to different VLANs. > Here we discuss host with multiple interface. I am not sure how VLAN can be used here. This also introduced the extra complexity. > > >> 2) Per user/host configuration makes DHCPv6 be used for the >> >> on-demand configuration. >> >> RA/RIO does not meet this requirement, which is a real requirement >> in networks with heterogeneous types of host. DHCPv6 does meet this >> requirement. >> > > You can use selective unicast router advertisements for this if you want. > There's no reason you can't look the RA properties in RADIUS. And of > course, you can put the separate hosts on separate VLANs (which is probably > the right thing to do in general). > If you use selective unicast RA for those on-demand subscribers, you are more likely using RA in a stateful way. The benefits of RA is lost. Regards, Tao > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > > --20cf3079c0fccefa0604b30b6bf5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks for the discussion. Inline please.

On Thu, Dec 1, 2011 at 7:23 AM, Lorenzo Colitti = <lorenzo@google.= com> wrote:
On Wed, Nov 30, 2011 at 13:30, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
To me this is a killer argument. A general solution that is applicable=
to all deployment scenarios is vastly better than a free-for all ofvendor options, which will increase the implementation burden for
everybody and reduce the chances of smooth zero-conf operation.

Actually, what decreases the implementation burden is not having the o= ption at all.=A0The use cases I've heard so far for this option are all= a bit specious and I think they are outweighed by the harm that would be c= aused if this option were to get into general use.
Form the discussion in this thread, the use cases exist in=A0BBF and c= ellular network, apply to host and RG/CPE and are met by individual user an= d network operators. To me, they are not specious.

The reasoning goes something like this:

1. The option is defined.
2. OS foo implements it.
3. Some network, somewhere, decides that they're only going to use= DHCPv6 for routing, because they only support OS foo.
4. Other OSes are forced to implement the option because if they don&#= 39;t, they are at a disadvantage compared to OS foo
5. Once all OSes implement it, some other network, somewhere else, dec= ides that they're only going to support DHCPv6 for routing because it&#= 39;s easier and because it matches what they do in IPv4, so they turn off R= As.
You need not worry about turning off RAs. RA is mandated for mobile ho= st to abtain /64 prefix in cellular network. While, for DHCPv6, you anyway= =A0need to switch on it IMHO. When you enable the tethering feature,=A0the = mobile host shall use=A0DHCPv6 for prefix delegation.
Then we have a problem, because DHCPv6 has much less rich semantics th= an RAs in the general case. A few examples:

- DHCPv6 is static. A lease is a promise and it can't be deprecate= d except by the server that originally made the promise. If that server is = not around any more, or if clients don't support reconfigure, it can= 9;t be deprecated at all. You can work around this with short lease times, = but that creates a scaling problem on the DHCPv6 server, because it's c= entralized.
- The way the standards and the clients are written, clients pick one = DHCPv6 advertise and stick to it. So they can't merge multiple sources = of information.
- DHCPv6 does not share fate with routing; in fact, it has no knowledg= e of routing.
- The combination of the fact that you can't merge multiple source= s of information and the fact that you can only provide static information = means that you're basically forced to hand out stuff that doesn't c= hange. If you're using DHCPv6 to set the default router, that basically= means you're forced to use VRRP or NAT if you want any sort of redunda= ncy.

To me, the lack of functionality that will result if we take the path = of least resistance described above far outweighs the benefits of being abl= e to configure [default] routes and on-link prefixes on a per-host basis. Y= ou can do this in lots of other ways, for example assigning the hosts you w= ant to treat differently to different VLANs.
Here we discuss host with multiple interface. I am not sure how VLAN c= an be used here. This also introduced the extra complexity.

>> 2) Per user/host configuration makes DHCPv6 be used for the>> on-demand configuration.

RA/RIO does not meet this = requirement, which is a real requirement
in networks with heterogeneous = types of host. DHCPv6 does meet this
requirement.

You can use selective unicast router advertisements for this if you wa= nt. There's no reason you can't look the RA properties in RADIUS. A= nd of course, you can put the separate hosts on separate VLANs (which is pr= obably the right thing to do in general).
=A0
If you use selective unicast RA for those on-demand subscribers, you a= re more likely=A0using RA in a stateful way. The benefits of RA is lost.
=A0
Regards,
Tao
________________________________= _______________
mif mailing list
mif@= ietf.org
htt= ps://www.ietf.org/mailman/listinfo/mif


--20cf3079c0fccefa0604b30b6bf5-- From lorenzo@google.com Thu Dec 1 10:00:13 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 A5B911F0C70 for ; Thu, 1 Dec 2011 10:00:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.758 X-Spam-Level: X-Spam-Status: No, score=-102.758 tagged_above=-999 required=5 tests=[AWL=0.218, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 nXgUx3o-U8DQ for ; Thu, 1 Dec 2011 10:00:12 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id A12571F0C7B for ; Thu, 1 Dec 2011 10:00:12 -0800 (PST) Received: by yenl9 with SMTP id l9so1253764yen.31 for ; Thu, 01 Dec 2011 10:00:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=UEXwxLoCe5E0tcY1EoQR+vCPsY6txWPiLWfKTOMIG24=; b=NH8jWCvgv9m6M0VL43ITfnRyCncyTeIYUwoUkPLCadP2jn1i5N5m4k4hvKOA0qpi2J JGTC8En9ElO41IjSHjFw== Received: by 10.236.128.138 with SMTP id f10mr13955037yhi.2.1322762412274; Thu, 01 Dec 2011 10:00:12 -0800 (PST) Received: by 10.236.128.138 with SMTP id f10mr13955013yhi.2.1322762412122; Thu, 01 Dec 2011 10:00:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.150.202.14 with HTTP; Thu, 1 Dec 2011 09:59:51 -0800 (PST) In-Reply-To: References: <282BBE8A501E1F4DA9C775F964BB21FE3EB78C3C98@GRFMBX704BA020.griffon.local> <916CE6CF87173740BC8A2CE44309696204193417@008-AM1MPN1-053.mgdnok.nokia.com> <4EC512A2.2060509@gmail.com> <890A58CF-8EAD-4F92-9981-9B5AA07EBF00@nominum.com> <4EC63E26.70104@gmail.com> <86163A8F-8628-4F67-BE93-3747F95A2F52@nominum.com> <4ECB6EAE.2010701@gmail.com> <702C34B3-F6B7-4EFB-91D5-8538540534A1@nominum.com> <4ECBE3BE.5070501@gmail.com> <759E821F-B503-4C8D-A79B-5F9A68A3613F@nominum.com> From: Lorenzo Colitti Date: Thu, 1 Dec 2011 09:59:51 -0800 Message-ID: To: Tao Sun Content-Type: multipart/alternative; boundary=20cf3005dd90b263af04b30b9ff7 X-System-Of-Record: true Cc: "mif@ietf.org" Subject: Re: [mif] Use cases for draft-ietf-mif-dhcpv6-route-option needed 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, 01 Dec 2011 18:00:13 -0000 --20cf3005dd90b263af04b30b9ff7 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Dec 1, 2011 at 09:07, Tao Sun wrote: > You can already do this today with RIOs, and I don't see why there need to >> be two ways of doing the same thing. Adding a different method to configure >> the same information is twice the code and more than twice the complexity, >> since when you have two sources of information with different semantics you >> need to figure out how to merge them, what happens if they disagree, what >> to do if one is wrong, what to do if one expires, and so on. >> > We can not do this today. As 1 and 2 mentioned, both the deployed gateway > and the 3GPP specification need to be updated to use RIO. > What I meant is that a protocol and IETF perspective, you can do this today using RIOs. So the protocol is there if 3GPP wants to use it. The 3GPP specs need to be updated regardless of whether we decide to standardize the proposed DHCPv6 route option or not. > I agree we need to consider the disagree/confliction among policies. That > is caused by the multiple interface feature. If you use RA for all the > interfaces, the rule received may still conflict. Addressing the > confliction is exactly what MIF WG shall consider IMHO. > It is not caused by having multiple interfaces, it is caused by the fact that there are potentially two sources of information. It can happen even on only one interface, if the network on that interface supports both RAs and DHCPv6 route. > Also, in the mobile case I don't understand how you would use a >> different gateway anyway. The mobile network is a point-to-point link, so >> there's no way to distinguish multiple gateways. How would you use this? >> >> > There are two types of scenarios. 1) A host is connected to the mobile > network and WiFi at the same time, a typical scenario of MIF. 2) A mobile > host connects to multiple APNs simultaneously, i.e., multiple PDN > connection is established. The type 2) scenrio is also considered to be > addressed in the OPIIS (Operator Policies for IP Interface Selection) > work item in 3GPP. > #1 can't be solved using either the DHCPv6 route option or RIOs because in general the carrier network doesn't know the IPv6 address of the default gateway on the wifi network. #2 can be fixed both using DHCPv6 route option and using RIOs. > >> ***Broadband network >>> >>> 1. WiFi network. Some WiFi hotspots provide local services. The >>> route configuration on RG is needed to direct some traffic to local network >>> while other traffic to the Internet. >>> >> >> I don't understand why you need host changes to do this. Since the >> hotspot router is a router, it can simply forward the packets the right way >> by itself. >> >> > You may refer to the Section of 3.4 of this draft or Section 5.2 of RFC > 4191. > I don't see how Section 3.4 of this draft ("applicability to routers") is relevant to this discussion. Section 5.2 of RFC 5191 describes a different scenario (two routers on the same link) than the one you suggested here (one router on a given link). > 2. VPN network. When a user connect to enterprise VPN network, >>> the routing of VPN traffic need to be configured. Due to the large number >>> of such VPN network, we cannot assume all the VPN network only use RA. >>> DHCPv6 provides another choice which may be preferred by the VPN network. >>> >> >> The rationale here seems to be that "if we create a new option, some >> networks might use it". That's certainly true, but it doesn't provide a >> compelling reason why we need the option in the first place. >> > To us, its a compelling reason due to the network managment/operation, > per-subscriber service, foresee burden of modification to existing gateway > and specifications. > Who is "us", and what is the use case? I don't see why the ones discussed so far can't use RIOs. --20cf3005dd90b263af04b30b9ff7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Dec 1, 2011 at 09:07, Tao Sun <hisunt= ao@gmail.com> wrote:
You can already do this today with RIOs, and=A0I= don't see why there need to be two ways of doing the same thing.=A0Add= ing a different method to configure the same information is=A0twice the cod= e and more than twice the complexity, since when you have two sources of in= formation with different semantics you need to figure out how to merge them= , what happens if they disagree, what to do if one is wrong, what to do if = one expires, and so on.
We can not do=A0this today. As 1 and 2 mentioned, both the deplo= yed gateway and the 3GPP specification need to be updated to use RIO.
=

What I meant is that a protocol and = IETF perspective, you can do this today using RIOs. So the protocol is ther= e if 3GPP wants to use it. The 3GPP=A0specs need to be updated regardless o= f whether we decide to standardize the proposed DHCPv6 route option or not.=
=A0
I agree we need to consider the disagree/confliction among policies. T= hat is caused by the multiple interface feature. If you use RA for all the = interfaces, the rule received may still conflict. Addressing the conflictio= n is exactly what MIF WG shall consider IMHO.

It is not caused by having multiple interfaces,= =A0it is caused by the fact that there are potentially two sources of infor= mation. It can happen even on only one interface, if the network on that in= terface supports both RAs and DHCPv6 route.
=A0
Also, in the mobile case I don't understand how you would use a di= fferent gateway anyway.=A0The mobile network is a point-to-point link, so t= here's no way to distinguish multiple gateways. How would you use this?=
=A0=A0
There are two types of scenarios. 1) A host is connected=A0to th= e=A0mobile network and WiFi at the same time, a typical scenario of MIF. 2)= A mobile host connects to multiple APNs simultaneously, i.e., multiple PDN= connection is established.=A0The type=A02)=A0scenrio is also considered to= be addressed=A0in the OPIIS (Operator Policies for= IP Interface Selection) work item in 3GPP.

#1 can't be solved using either = the DHCPv6 route option or RIOs because in general the carrier network does= n't know the IPv6 address of the default gateway on the wifi network.
#2 can be fixed both using DHCPv6 route option and using RIOs.

=A0

***Broadband network

1.=A0=A0=A0=A0=A0=A0 WiFi network. Some WiFi hotspots provide= local services. The route configuration on RG is needed to direct some tra= ffic to local network while other traffic to the Internet.


I don't understand why you need host changes to do this. Since the= hotspot router is a router, it can simply forward the packets the right wa= y by itself.
=A0
You may refer to the=A0 Section of 3.4 of this draft or Section = 5.2 of RFC 4191.

I don't see how Secti= on 3.4 of this draft ("applicability to routers") is relevant to = this discussion.=A0Section 5.2 of RFC 5191 describes a different scenario (= two routers on the same link) than the one you suggested here (one router o= n a given link).
=A0

2.=A0=A0=A0=A0=A0=A0 VPN network. When a user connect to ente= rprise VPN network, the routing of VPN traffic need to be configured. Due t= o the large number of such VPN network, we cannot assume all the VPN networ= k only use RA. DHCPv6 provides another choice which may be preferred by the= VPN network.


The rationale here seems to be that "if we create a new option, s= ome networks might use it". That's certainly true, but it doesn= 9;t provide a compelling reason why we need the option in the first place.<= /div>
To us, its a compelling reason due to the network managment/operation,= per-subscriber service, foresee burden of modification to existing gateway= and specifications.

Who is "us&= quot;, and what is the use case? I don't see why the ones discussed so = far can't use RIOs.
--20cf3005dd90b263af04b30b9ff7-- From lorenzo@google.com Thu Dec 1 10:06:38 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 28ED81F0CB1 for ; Thu, 1 Dec 2011 10:06:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.774 X-Spam-Level: X-Spam-Status: No, score=-102.774 tagged_above=-999 required=5 tests=[AWL=0.202, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 m8cWbFxiO52S for ; Thu, 1 Dec 2011 10:06:37 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 380961F0C7B for ; Thu, 1 Dec 2011 10:06:37 -0800 (PST) Received: by ghrr18 with SMTP id r18so2519707ghr.31 for ; Thu, 01 Dec 2011 10:06:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=HCCngRx25xjTdF8RBofqMkHOtb8Rw6b0SCu7ca00Bqg=; b=wKNPkPDLfU3wTDHF5NGoaURw04nCXr/16EUW73OA2DCex7lJLYBEumLq0UHqVyGVw+ 2p2or4+AV3nmRT4pb7Zw== Received: by 10.236.183.52 with SMTP id p40mr13494874yhm.19.1322762796615; Thu, 01 Dec 2011 10:06:36 -0800 (PST) Received: by 10.236.183.52 with SMTP id p40mr13494855yhm.19.1322762796489; Thu, 01 Dec 2011 10:06:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.150.202.14 with HTTP; Thu, 1 Dec 2011 10:06:15 -0800 (PST) In-Reply-To: References: <282BBE8A501E1F4DA9C775F964BB21FE3EB78C3C98@GRFMBX704BA020.griffon.local> <916CE6CF87173740BC8A2CE44309696204193417@008-AM1MPN1-053.mgdnok.nokia.com> <4EC512A2.2060509@gmail.com> <890A58CF-8EAD-4F92-9981-9B5AA07EBF00@nominum.com> <4EC63E26.70104@gmail.com> <86163A8F-8628-4F67-BE93-3747F95A2F52@nominum.com> <4ECB6EAE.2010701@gmail.com> <702C34B3-F6B7-4EFB-91D5-8538540534A1@nominum.com> <4ECBE3BE.5070501@gmail.com> <759E821F-B503-4C8D-A79B-5F9A68A3613F@nominum.com> <4ED6A08D.9090703@gmail.com> From: Lorenzo Colitti Date: Thu, 1 Dec 2011 10:06:15 -0800 Message-ID: To: Tao Sun Content-Type: multipart/alternative; boundary=bcaec52c5ea99b5c5e04b30bb6af X-System-Of-Record: true Cc: "mif@ietf.org" Subject: Re: [mif] Use cases for draft-ietf-mif-dhcpv6-route-option needed 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, 01 Dec 2011 18:06:38 -0000 --bcaec52c5ea99b5c5e04b30bb6af Content-Type: text/plain; charset=ISO-8859-1 On Thu, Dec 1, 2011 at 09:45, Tao Sun wrote: > >> Actually, what decreases the implementation burden is not having the >> option at all. The use cases I've heard so far for this option are all a >> bit specious and I think they are outweighed by the harm that would be >> caused if this option were to get into general use. >> > Form the discussion in this thread, the use cases exist in BBF and > cellular network, apply to host and RG/CPE and are met by individual user > and network operators. To me, they are not specious. > I can see the BBF use case, but that seems to be a rather specific use case and could be solved using a BBF-specific option. I can't see the cellular use case, since the cellular network already uses RAs. > The reasoning goes something like this: >> >> 1. The option is defined. >> 2. OS foo implements it. >> 3. Some network, somewhere, decides that they're only going to use DHCPv6 >> for routing, because they only support OS foo. >> 4. Other OSes are forced to implement the option because if they don't, >> they are at a disadvantage compared to OS foo >> 5. Once all OSes implement it, some other network, somewhere else, >> decides that they're only going to support DHCPv6 for routing because it's >> easier and because it matches what they do in IPv4, so they turn off RAs. >> > You need not worry about turning off RAs. RA is mandated for mobile host > to abtain /64 prefix in cellular network. While, for DHCPv6, you > anyway need to switch on it IMHO. When you enable the tethering > feature, the mobile host shall use DHCPv6 for prefix delegation. > I'm not talking about mobile networks specifically here. I think this particular event (turning off RAs) is more likely that to happen on a wifi network or an enterprise network. > To me, the lack of functionality that will result if we take the path >> of least resistance described above far outweighs the benefits of being >> able to configure [default] routes and on-link prefixes on a per-host >> basis. You can do this in lots of other ways, for example assigning the >> hosts you want to treat differently to different VLANs. >> > Here we discuss host with multiple interface. I am not sure how VLAN can > be used here. This also introduced the extra complexity. > The DHCPv6 route option has nothing to do with multiple interfaces. It is equally applicable to a use case where you have only one interface. As regards VLANs: my point was that if you want different hosts to have different gateways, you can put them on different VLANs and have different RAs on each VLAN. You don't have to do it via DHCPv6. >> 2) Per user/host configuration makes DHCPv6 be used for the >>> >> on-demand configuration. >>> >>> RA/RIO does not meet this requirement, which is a real requirement >>> in networks with heterogeneous types of host. DHCPv6 does meet this >>> requirement. >>> >> >> You can use selective unicast router advertisements for this if you want. >> There's no reason you can't look the RA properties in RADIUS. And of >> course, you can put the separate hosts on separate VLANs (which is probably >> the right thing to do in general). >> > > If you use selective unicast RA for those on-demand subscribers, you are > more likely using RA in a stateful way. The benefits of RA is lost. > >From the network point of view maybe. But not from the point of view of the node that is receiving the RA. That node can still support / merge multiple sources of information; it only needs to support one protocol (RA) to configure routes and doesn't need the additional complexity that comes from supporting two ways to configure the same thing; and so on. --bcaec52c5ea99b5c5e04b30bb6af Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Dec 1, 2011 at 09:45, Tao Sun <hisuntao@gmail.com&g= t; wrote:

Actually, what decreases the im= plementation burden is not having the option at all.=A0The use cases I'= ve heard so far for this option are all a bit specious and I think they are= outweighed by the harm that would be caused if this option were to get int= o general use.
Form the discussion in this thread, the use cases exist in=A0BBF= and cellular network, apply to host and RG/CPE and are met by individual u= ser and network operators. To me, they are not specious.

I can see the BBF use case, but that seems to be a rath= er specific use case and could be solved using a BBF-specific option. I can= 't see the cellular use case, since the cellular network already uses R= As.
=A0
The reasoning goes something like this:

1. The option is defined.
2. OS foo implements it.
3. Some network, somewhere, decides that they're only going to use= DHCPv6 for routing, because they only support OS foo.
4. Other OSes are forced to implement the option because if they don&#= 39;t, they are at a disadvantage compared to OS foo
5. Once all OSes implement it, some other network, somewhere else, dec= ides that they're only going to support DHCPv6 for routing because it&#= 39;s easier and because it matches what they do in IPv4, so they turn off R= As.
You need not worry about turning off RAs. RA is mandated for mob= ile host to abtain /64 prefix in cellular network. While, for DHCPv6, you a= nyway=A0need to switch on it IMHO. When you enable the tethering feature,= =A0the mobile host shall use=A0DHCPv6 for prefix delegation.

I'm not talking about mobi= le networks specifically here. I think this particular event (turning off R= As) is more likely that to happen on a wifi network or an enterprise networ= k.
=A0
To me, the lack of functionality that will result if we take the path = of least resistance described above far outweighs the benefits of being abl= e to configure [default] routes and on-link prefixes on a per-host basis. Y= ou can do this in lots of other ways, for example assigning the hosts you w= ant to treat differently to different VLANs.
Here we discuss host with multiple interface. I am not sure how = VLAN can be used here. This also introduced the extra complexity.

The DHCPv6 route option has nothing to d= o with multiple interfaces. It is equally applicable to a use case where yo= u have only one interface.

As regards VLANs: my point was that if you want differe= nt hosts to have different gateways, you can put them on different VLANs an= d have different RAs on each VLAN. You don't have to do it via DHCPv6.<= br>

>> 2) Per user/host configuration makes DHCPv6 be used for the>> on-demand configuration.

RA/RIO does not meet this = requirement, which is a real requirement
in networks with heterogeneous = types of host. DHCPv6 does meet this
requirement.

You can use selective unicast router advertisements for this if you wa= nt. There's no reason you can't look the RA properties in RADIUS. A= nd of course, you can put the separate hosts on separate VLANs (which is pr= obably the right thing to do in general).
=A0
If you use selective unicast RA for those on-demand subscribers,= you are more likely=A0using RA in a stateful way. The benefits of RA is lo= st.

From the network point of v= iew maybe. But not from the point of view of the node that is receiving the= RA. That node can still support / merge multiple sources of information; i= t only needs to support one protocol (RA) to configure routes and doesn'= ;t need the additional complexity that comes from supporting two ways to co= nfigure the same thing; and so on.
--bcaec52c5ea99b5c5e04b30bb6af-- From Ted.Lemon@nominum.com Thu Dec 1 10:19:49 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 A59C711E808A for ; Thu, 1 Dec 2011 10:19:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.397 X-Spam-Level: X-Spam-Status: No, score=-106.397 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 zk2PHMJ8GnFm for ; Thu, 1 Dec 2011 10:19:49 -0800 (PST) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by ietfa.amsl.com (Postfix) with ESMTP id D6A3D11E8073 for ; Thu, 1 Dec 2011 10:19:48 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKTtfFNnqxiiW93qsRVtDmek5Bj+MBDKbE@postini.com; Thu, 01 Dec 2011 10:19:48 PST 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 2808E1B827C for ; Thu, 1 Dec 2011 10:19:34 -0800 (PST) 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 8DE99190052; Thu, 1 Dec 2011 10:19:31 -0800 (PST) (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.0339.001; Thu, 1 Dec 2011 10:19:31 -0800 From: Ted Lemon To: Lorenzo Colitti Thread-Topic: [mif] Use cases for draft-ietf-mif-dhcpv6-route-option needed Thread-Index: AQHMpeNOuu/E0pVKc0uk0cJFS4z9vZWzLpa7gAYCCQCAAF+4gIAAK9UAgAAIrACADIz6AIAAAUwAgAA15ICAAB90AIABM/WAgAAFv4CAAAO0AA== Date: Thu, 1 Dec 2011 18:19:31 +0000 Message-ID: References: <282BBE8A501E1F4DA9C775F964BB21FE3EB78C3C98@GRFMBX704BA020.griffon.local> <916CE6CF87173740BC8A2CE44309696204193417@008-AM1MPN1-053.mgdnok.nokia.com> <4EC512A2.2060509@gmail.com> <890A58CF-8EAD-4F92-9981-9B5AA07EBF00@nominum.com> <4EC63E26.70104@gmail.com> <86163A8F-8628-4F67-BE93-3747F95A2F52@nominum.com> <4ECB6EAE.2010701@gmail.com> <702C34B3-F6B7-4EFB-91D5-8538540534A1@nominum.com> <4ECBE3BE.5070501@gmail.com> <759E821F-B503-4C8D-A79B-5F9A68A3613F@nominum.com> <4ED6A08D.9090703@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_D085F8557F704A4789F4A8309F3E28BBnominumcom_" MIME-Version: 1.0 Cc: "mif@ietf.org" Subject: Re: [mif] Use cases for draft-ietf-mif-dhcpv6-route-option needed 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, 01 Dec 2011 18:19:49 -0000 --_000_D085F8557F704A4789F4A8309F3E28BBnominumcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On Dec 1, 2011, at 1:06 PM, Lorenzo Colitti wrote: As regards VLANs: my point was that if you want different hosts to have dif= ferent gateways, you can put them on different VLANs and have different RAs= on each VLAN. You don't have to do it via DHCPv6. If we are deciding between a DHCPv6 route option and requiring people to se= t up VLANs for every customer, I think it's pretty clear which choice is le= ss onerous. I think you need a better argument here=97I agree that there = should be only one source of routing info, but this is a better argument ag= ainst that position than in favor of it. --_000_D085F8557F704A4789F4A8309F3E28BBnominumcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <895A849AD921974A995531416ACDBDD8@nominum.com> Content-Transfer-Encoding: quoted-printable
On Dec 1, 2011, at 1:06 PM, Lorenzo Colitti wrote:
As regards VLANs: my point was that if you want different hosts to have diffe= rent gateways, you can put them on different VLANs and have different RAs o= n each VLAN. You don't have to do it via DHCPv6.

If we are deciding between a DHCPv6 route option and requiring people = to set up VLANs for every customer, I think it's pretty clear which choice = is less onerous.   I think you need a better argument here=97I agree t= hat there should be only one source of routing info, but this is a better argument against that position than in = favor of it.
--_000_D085F8557F704A4789F4A8309F3E28BBnominumcom_-- From alexandru.petrescu@gmail.com Thu Dec 1 10:27: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 0E2B411E8082 for ; Thu, 1 Dec 2011 10:27:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] 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 vZyPbfzYWKF7 for ; Thu, 1 Dec 2011 10:27:26 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id DE01911E8073 for ; Thu, 1 Dec 2011 10:27:25 -0800 (PST) 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 pB1IRO2E007776 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 1 Dec 2011 19:27:24 +0100 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 pB1IRNaB007963 for ; Thu, 1 Dec 2011 19:27:23 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id pB1IRKhY022750 for ; Thu, 1 Dec 2011 19:27:23 +0100 Message-ID: <4ED7C708.3060009@gmail.com> Date: Thu, 01 Dec 2011 19:27:20 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: mif@ietf.org References: <282BBE8A501E1F4DA9C775F964BB21FE3EB78C3C98@GRFMBX704BA020.griffon.local> <916CE6CF87173740BC8A2CE44309696204193417@008-AM1MPN1-053.mgdnok.nokia.com> <4EC512A2.2060509@gmail.com> <890A58CF-8EAD-4F92-9981-9B5AA07EBF00@nominum.com> <4EC63E26.70104@gmail.com> <86163A8F-8628-4F67-BE93-3747F95A2F52@nominum.com> <4ECB6EAE.2010701@gmail.com> <702C34B3-F6B7-4EFB-91D5-8538540534A1@nominum.com> <4ECBE3BE.5070501@gmail.com> <759E821F-B503-4C8D-A79B-5F9A68A3613F@nominum.com> <4ED6A08D.9090703@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [mif] Use cases for draft-ietf-mif-dhcpv6-route-option needed 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, 01 Dec 2011 18:27:27 -0000 Le 01/12/2011 00:23, Lorenzo Colitti a écrit : > On Wed, Nov 30, 2011 at 13:30, Brian E Carpenter > > wrote: > > To me this is a killer argument. A general solution that is applicable > to all deployment scenarios is vastly better than a free-for all of > vendor options, which will increase the implementation burden for > everybody and reduce the chances of smooth zero-conf operation. > > > Actually, what decreases the implementation burden is not having the > option at all. The use cases I've heard so far for this option are all a > bit specious and I think they are outweighed by the harm that would be > caused if this option were to get into general use. > > The reasoning goes something like this: > > 1. The option is defined. > 2. OS foo implements it. > 3. Some network, somewhere, decides that they're only going to use > DHCPv6 for routing, because they only support OS foo. > 4. Other OSes are forced to implement the option because if they don't, > they are at a disadvantage compared to OS foo > 5. Once all OSes implement it, some other network, somewhere else, > decides that they're only going to support DHCPv6 for routing because > it's easier and because it matches what they do in IPv4, so they turn > off RAs. > > Then we have a problem, because DHCPv6 has much less rich semantics than > RAs in the general case. Yes, but generally speaking each is less rich than the other. Whereas DHCPv6 does not communicate RA's MTU, RA does not communicate DHCPv6's printer lists. Alex > A few examples: > > - DHCPv6 is static. A lease is a promise and it can't be deprecated > except by the server that originally made the promise. If that server is > not around any more, or if clients don't support reconfigure, it can't > be deprecated at all. You can work around this with short lease times, > but that creates a scaling problem on the DHCPv6 server, because it's > centralized. > - The way the standards and the clients are written, clients pick one > DHCPv6 advertise and stick to it. So they can't merge multiple sources > of information. > - DHCPv6 does not share fate with routing; in fact, it has no knowledge > of routing. > - The combination of the fact that you can't merge multiple sources of > information and the fact that you can only provide static information > means that you're basically forced to hand out stuff that doesn't > change. If you're using DHCPv6 to set the default router, that basically > means you're forced to use VRRP or NAT if you want any sort of redundancy. > > To me, the lack of functionality that will result if we take the path of > least resistance described above far outweighs the benefits of being > able to configure [default] routes and on-link prefixes on a per-host > basis. You can do this in lots of other ways, for example assigning the > hosts you want to treat differently to different VLANs. > > >> 2) Per user/host configuration makes DHCPv6 be used for the > >> on-demand configuration. > > RA/RIO does not meet this requirement, which is a real requirement > in networks with heterogeneous types of host. DHCPv6 does meet this > requirement. > > > You can use selective unicast router advertisements for this if you > want. There's no reason you can't look the RA properties in RADIUS. And > of course, you can put the separate hosts on separate VLANs (which is > probably the right thing to do in general). > > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif From Ted.Lemon@nominum.com Thu Dec 1 10:29:58 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 03F9F11E80FE for ; Thu, 1 Dec 2011 10:29:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.426 X-Spam-Level: X-Spam-Status: No, score=-106.426 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 QcBpPN06H13T for ; Thu, 1 Dec 2011 10:29:57 -0800 (PST) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by ietfa.amsl.com (Postfix) with ESMTP id 3A72111E80F8 for ; Thu, 1 Dec 2011 10:29:57 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKTtfHpELkxjM/0ewLEFnpAUQZtNQOf//P@postini.com; Thu, 01 Dec 2011 10:29:57 PST 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 3BD681B82BF for ; Thu, 1 Dec 2011 10:29:56 -0800 (PST) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (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 32B15190052; Thu, 1 Dec 2011 10:29:56 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.01.0339.001; Thu, 1 Dec 2011 10:29:56 -0800 From: Ted Lemon To: Alexandru Petrescu Thread-Topic: [mif] Use cases for draft-ietf-mif-dhcpv6-route-option needed Thread-Index: AQHMpeNOuu/E0pVKc0uk0cJFS4z9vZWzLpa7gAYCCQCAAF+4gIAAK9UAgAAIrACADIz6AIAAAUwAgAA15ICAAB90AIABP5gAgAAAuAA= Date: Thu, 1 Dec 2011 18:29:55 +0000 Message-ID: <2D3E1A0A-9746-45EA-85C4-B9EC11D84052@nominum.com> References: <282BBE8A501E1F4DA9C775F964BB21FE3EB78C3C98@GRFMBX704BA020.griffon.local> <916CE6CF87173740BC8A2CE44309696204193417@008-AM1MPN1-053.mgdnok.nokia.com> <4EC512A2.2060509@gmail.com> <890A58CF-8EAD-4F92-9981-9B5AA07EBF00@nominum.com> <4EC63E26.70104@gmail.com> <86163A8F-8628-4F67-BE93-3747F95A2F52@nominum.com> <4ECB6EAE.2010701@gmail.com> <702C34B3-F6B7-4EFB-91D5-8538540534A1@nominum.com> <4ECBE3BE.5070501@gmail.com> <759E821F-B503-4C8D-A79B-5F9A68A3613F@nominum.com> <4ED6A08D.9090703@gmail.com> <4ED7C708.3060009@gmail.com> In-Reply-To: <4ED7C708.3060009@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_2D3E1A0A974645EA85C4B9EC11D84052nominumcom_" MIME-Version: 1.0 Cc: "" Subject: Re: [mif] Use cases for draft-ietf-mif-dhcpv6-route-option needed 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, 01 Dec 2011 18:29:58 -0000 --_000_2D3E1A0A974645EA85C4B9EC11D84052nominumcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Dec 1, 2011, at 1:27 PM, Alexandru Petrescu wrote: Yes, but generally speaking each is less rich than the other. Whereas DHCP= v6 does not communicate RA's MTU, RA does not communicate DHCPv6's printer = lists. What Lorenzo is talking about when he says DHCP is less rich is that DHCP c= lients are currently required to choose one provisioning domain when more t= han one is present. It has nothing to do with what options are on offer. --_000_2D3E1A0A974645EA85C4B9EC11D84052nominumcom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <55F90F965BEE4448B4CE0642FA42C2EE@nominum.com> Content-Transfer-Encoding: quoted-printable
On Dec 1, 2011, at 1:27 PM, Alexandru Petrescu wrote:
Yes, but generally speaking each is less rich than the other.  Whereas DHC= Pv6 does not communicate RA's MTU, RA does not communicate DHCPv6's printer= lists.

What Lorenzo is talking about when he says DHCP is less rich is that D= HCP clients are currently required to choose one provisioning domain when m= ore than one is present.   It has nothing to do with what options are = on offer.

--_000_2D3E1A0A974645EA85C4B9EC11D84052nominumcom_-- From alexandru.petrescu@gmail.com Thu Dec 1 10:30:31 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 F1AF711E80EB for ; Thu, 1 Dec 2011 10:30:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] 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 Ubx3i9oTK9QF for ; Thu, 1 Dec 2011 10:30:31 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 3DC6711E8073 for ; Thu, 1 Dec 2011 10:30:31 -0800 (PST) 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 pB1IUSCl015498 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 1 Dec 2011 19:30:28 +0100 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 pB1IUSMx008653 for ; Thu, 1 Dec 2011 19:30:28 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id pB1IURWL023760 for ; Thu, 1 Dec 2011 19:30:28 +0100 Message-ID: <4ED7C7C3.5080601@gmail.com> Date: Thu, 01 Dec 2011 19:30:27 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: mif@ietf.org References: <282BBE8A501E1F4DA9C775F964BB21FE3EB78C3C98@GRFMBX704BA020.griffon.local> <916CE6CF87173740BC8A2CE44309696204193417@008-AM1MPN1-053.mgdnok.nokia.com> <4EC512A2.2060509@gmail.com> <890A58CF-8EAD-4F92-9981-9B5AA07EBF00@nominum.com> <4EC63E26.70104@gmail.com> <86163A8F-8628-4F67-BE93-3747F95A2F52@nominum.com> <4ECB6EAE.2010701@gmail.com> <702C34B3-F6B7-4EFB-91D5-8538540534A1@nominum.com> <4ECBE3BE.5070501@gmail.com> <759E821F-B503-4C8D-A79B-5F9A68A3613F@nominum.com> <7C1F8DA5-357F-4403-BE0D-E72D425B71C9@gmail.com> In-Reply-To: <7C1F8DA5-357F-4403-BE0D-E72D425B71C9@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [mif] Use cases for draft-ietf-mif-dhcpv6-route-option needed 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, 01 Dec 2011 18:30:32 -0000 Le 01/12/2011 17:43, jouni korhonen a écrit : > > > On Nov 30, 2011, at 8:18 PM, Tao Sun wrote: > >> Forgot to include a website link in the previous email. Now I >> included it. >> >> Regards, >> >> Tao Sun >> >> On Thu, Dec 1, 2011 at 2:13 AM, Tao Sun wrote: >> Hi All, >> >> Thanks for the discussion. As one of the author of the draft, I >> would like to share our view on DHCPv6 used case in three aspects. >> *Network management and configuration. 1. It is efficient for the >> network to configure this in a central DHCPv6 server to do unified >> routing policy configuration. The gateways (e.g., GGSN in cellular >> network) only need to perform DHCPv6 relay. > > Just want to point out that 3GPP specs do not define/mandate DHCPv6 > relay function in GGSN/PGW.. Yes, but there are 3GPP specs implying that the DHCP Server is _not_ the PGW and the DHCP Server is somewhere outside the 3GPP operator network ("external" config or so). At which point the only possibility to keep PGW able to participate in DHCP configuration is PGW to be a Relay. This may be an assumption silently made by the 3GPP specs, or a misunderstanding from my part. Alex It is a server when seen from the UE > point of view. > > [snip] > > - JOuni > > > > _______________________________________________ mif mailing list > mif@ietf.org https://www.ietf.org/mailman/listinfo/mif > From alexandru.petrescu@gmail.com Thu Dec 1 10:40:34 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 6D49411E808A for ; Thu, 1 Dec 2011 10:40:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] 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 Tj0IfGcwtb0i for ; Thu, 1 Dec 2011 10:40:34 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 94F8C11E8082 for ; Thu, 1 Dec 2011 10:40:33 -0800 (PST) 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 pB1IeW2K010435 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 1 Dec 2011 19:40:32 +0100 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 pB1IeWB9011014 for ; Thu, 1 Dec 2011 19:40:32 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id pB1IeSSi027399 for ; Thu, 1 Dec 2011 19:40:32 +0100 Message-ID: <4ED7CA1C.1080606@gmail.com> Date: Thu, 01 Dec 2011 19:40:28 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: mif@ietf.org References: <282BBE8A501E1F4DA9C775F964BB21FE3EB78C3C98@GRFMBX704BA020.griffon.local> <916CE6CF87173740BC8A2CE44309696204193417@008-AM1MPN1-053.mgdnok.nokia.com> <4EC512A2.2060509@gmail.com> <890A58CF-8EAD-4F92-9981-9B5AA07EBF00@nominum.com> <4EC63E26.70104@gmail.com> <86163A8F-8628-4F67-BE93-3747F95A2F52@nominum.com> <4ECB6EAE.2010701@gmail.com> <702C34B3-F6B7-4EFB-91D5-8538540534A1@nominum.com> <4ECBE3BE.5070501@gmail.com> <759E821F-B503-4C8D-A79B-5F9A68A3613F@nominum.com> <7C1F8DA5-357F-4403-BE0D-E72D425B71C9@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [mif] Use cases for draft-ietf-mif-dhcpv6-route-option needed 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, 01 Dec 2011 18:40:34 -0000 Le 01/12/2011 18:24, Tao Sun a écrit : > Hi Jouni, Thanks for the clarification. That is ture GGSN/PGW is not > mandate to do relay. "May" instead of "shall" is used to describe > GGSN/PGW's action. The only mandate is to use RA to obtain /64 > prefix. And that mandate is not sufficient when the UE is actually a Router ("mobile hotspot", "tethering"). For these cases, DHCPv6-PD is suggested by 3GPP specs. Thus, the 3GPP specs assume that a UE-Router (new term for this conversation) runs both RA _and_ DHCP. But 3GPP specs overlook the fact that an UE-Router would't use RA to auto-configure an address (stateless autoconf is only for Hosts). Hence 3GPP specs could consider that _only_ DHCP should should be used by DHCPv6. In this sense, the above only mandate ("use RA to obtain /64 prefix") could be dropped altogether. Alex > Regards, Tao On Fri, Dec 2, 2011 at 12:43 AM, jouni korhonen > > wrote: > > > > On Nov 30, 2011, at 8:18 PM, Tao Sun wrote: > >> Forgot to include a website link in the previous email. Now I > included it. >> >> Regards, >> >> Tao Sun >> >> On Thu, Dec 1, 2011 at 2:13 AM, Tao Sun > wrote: >> Hi All, >> >> Thanks for the discussion. As one of the author of the draft, I > would like to share our view on DHCPv6 used case in three aspects. >> *Network management and configuration. 1. It is efficient for the >> network to configure this in a central > DHCPv6 server to do unified routing policy configuration. The > gateways (e.g., GGSN in cellular network) only need to perform DHCPv6 > relay. > > Just want to point out that 3GPP specs do not define/mandate DHCPv6 > relay function in GGSN/PGW.. It is a server when seen from the UE > point of view. > > [snip] > > - JOuni > > > > > > > _______________________________________________ mif mailing list > mif@ietf.org https://www.ietf.org/mailman/listinfo/mif From lorenzo@google.com Thu Dec 1 11:19:29 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 2E94721F8514 for ; Thu, 1 Dec 2011 11:19:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.827 X-Spam-Level: X-Spam-Status: No, score=-102.827 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 SlVTLupg0kQG for ; Thu, 1 Dec 2011 11:19:28 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id A92F021F84D6 for ; Thu, 1 Dec 2011 11:19:28 -0800 (PST) Received: by ggnp4 with SMTP id p4so2617690ggn.31 for ; Thu, 01 Dec 2011 11:19:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=KziT8qTMHDCZMXAQiKpZ0k2G/WqDVK9vIF5T+Iytrnk=; b=rr7f67JHV8Gv6jbUPuPALiNYDQKb9ftULMx/+J1Cz32pfou0LPDIT/BjtwfuNmqtXw eDQcjk4fufFIiv0BHsiA== Received: by 10.236.183.52 with SMTP id p40mr14017023yhm.19.1322767168275; Thu, 01 Dec 2011 11:19:28 -0800 (PST) Received: by 10.236.183.52 with SMTP id p40mr14017003yhm.19.1322767168124; Thu, 01 Dec 2011 11:19:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.150.202.14 with HTTP; Thu, 1 Dec 2011 11:19:07 -0800 (PST) In-Reply-To: References: <282BBE8A501E1F4DA9C775F964BB21FE3EB78C3C98@GRFMBX704BA020.griffon.local> <916CE6CF87173740BC8A2CE44309696204193417@008-AM1MPN1-053.mgdnok.nokia.com> <4EC512A2.2060509@gmail.com> <890A58CF-8EAD-4F92-9981-9B5AA07EBF00@nominum.com> <4EC63E26.70104@gmail.com> <86163A8F-8628-4F67-BE93-3747F95A2F52@nominum.com> <4ECB6EAE.2010701@gmail.com> <702C34B3-F6B7-4EFB-91D5-8538540534A1@nominum.com> <4ECBE3BE.5070501@gmail.com> <759E821F-B503-4C8D-A79B-5F9A68A3613F@nominum.com> <4ED6A08D.9090703@gmail.com> From: Lorenzo Colitti Date: Thu, 1 Dec 2011 11:19:07 -0800 Message-ID: To: Ted Lemon Content-Type: multipart/alternative; boundary=bcaec52c5ea92d361f04b30cbb05 X-System-Of-Record: true Cc: "mif@ietf.org" Subject: Re: [mif] Use cases for draft-ietf-mif-dhcpv6-route-option needed 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, 01 Dec 2011 19:19:29 -0000 --bcaec52c5ea92d361f04b30cbb05 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Dec 1, 2011 at 10:19, Ted Lemon wrote: > On Dec 1, 2011, at 1:06 PM, Lorenzo Colitti wrote: > > As regards VLANs: my point was that if you want different hosts to have > different gateways, you can put them on different VLANs and have different > RAs on each VLAN. You don't have to do it via DHCPv6. > > > If we are deciding between a DHCPv6 route option and requiring people to > set up VLANs for every customer, I think it's pretty clear which choice is > less onerous. > Why? In BBF scenarios, the VLANs are almost always created on-demand. I think that was one of the major use cases presented for this option, right? --bcaec52c5ea92d361f04b30cbb05 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Dec 1, 2011 at 10:19, Ted Lemon <Ted.Lemon@nominum.co= m> wrote:
On Dec 1, 2011, at 1:06 PM, Lorenzo Colitti wrote:
= As regards VLANs: my point was that if you want different hosts to have diffe= rent gateways, you can put them on different VLANs and have different RAs o= n each VLAN. You don't have to do it via DHCPv6.

If we are deciding between a DHCPv6 route option and requiring p= eople to set up VLANs for every customer, I think it's pretty clear whi= ch choice is less onerous.

Why? In BBF scenarios, the VLANs are almost alw= ays created on-demand. I think that was one of the major use cases presente= d for this option, right?
--bcaec52c5ea92d361f04b30cbb05-- From lorenzo@google.com Thu Dec 1 11:23:08 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 5010121F8D52 for ; Thu, 1 Dec 2011 11:23:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.835 X-Spam-Level: X-Spam-Status: No, score=-102.835 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 SP1ybLmG7pAH for ; Thu, 1 Dec 2011 11:23:07 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id BCA5811E80CA for ; Thu, 1 Dec 2011 11:23:05 -0800 (PST) Received: by yenl9 with SMTP id l9so1349422yen.31 for ; Thu, 01 Dec 2011 11:23:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=oXsTLRYcv1eE/yMOzSAB4ITnwjEUxhH2E33SDKAVxqE=; b=hhC0/tm8s8GaYS6+aayNzEr8PYAEHnGQoJoBS6j2/4WGniQi9PDfBsxM0In44sLJP+ ALxwrtGOtg3guzJXJw+w== Received: by 10.236.128.138 with SMTP id f10mr14573377yhi.2.1322767385335; Thu, 01 Dec 2011 11:23:05 -0800 (PST) Received: by 10.236.128.138 with SMTP id f10mr14573352yhi.2.1322767385157; Thu, 01 Dec 2011 11:23:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.150.202.14 with HTTP; Thu, 1 Dec 2011 11:22:44 -0800 (PST) In-Reply-To: <4ED7CA1C.1080606@gmail.com> References: <282BBE8A501E1F4DA9C775F964BB21FE3EB78C3C98@GRFMBX704BA020.griffon.local> <916CE6CF87173740BC8A2CE44309696204193417@008-AM1MPN1-053.mgdnok.nokia.com> <4EC512A2.2060509@gmail.com> <890A58CF-8EAD-4F92-9981-9B5AA07EBF00@nominum.com> <4EC63E26.70104@gmail.com> <86163A8F-8628-4F67-BE93-3747F95A2F52@nominum.com> <4ECB6EAE.2010701@gmail.com> <702C34B3-F6B7-4EFB-91D5-8538540534A1@nominum.com> <4ECBE3BE.5070501@gmail.com> <759E821F-B503-4C8D-A79B-5F9A68A3613F@nominum.com> <7C1F8DA5-357F-4403-BE0D-E72D425B71C9@gmail.com> <4ED7CA1C.1080606@gmail.com> From: Lorenzo Colitti Date: Thu, 1 Dec 2011 11:22:44 -0800 Message-ID: To: Alexandru Petrescu Content-Type: multipart/alternative; boundary=20cf3005dd901ce0f304b30cc85d X-System-Of-Record: true Cc: mif@ietf.org Subject: Re: [mif] Use cases for draft-ietf-mif-dhcpv6-route-option needed 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, 01 Dec 2011 19:23:08 -0000 --20cf3005dd901ce0f304b30cc85d Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Dec 1, 2011 at 10:40, Alexandru Petrescu < alexandru.petrescu@gmail.com> wrote: > Le 01/12/2011 18:24, Tao Sun a =E9crit : > > Hi Jouni, Thanks for the clarification. That is ture GGSN/PGW is not >> mandate to do relay. "May" instead of "shall" is used to describe >> GGSN/PGW's action. The only mandate is to use RA to obtain /64 >> prefix. >> > > And that mandate is not sufficient when the UE is actually a Router > ("mobile hotspot", "tethering"). For these cases, DHCPv6-PD is > suggested by 3GPP specs. Thus, the 3GPP specs assume that a UE-Router > (new term for this conversation) runs both RA _and_ DHCP. But 3GPP > specs overlook the fact that an UE-Router would't use RA to > auto-configure an address (stateless autoconf is only for Hosts). That's not true - RFC 6204 says that an IPv6 CE router can use autoconf to create an address. I think it's reasonable to say that if you were to implement tethering using DHCPv6 PD, you would follow RFC 6204. > Hence 3GPP specs could consider that _only_ DHCP should should be used > by DHCPv6. In this sense, the above only mandate ("use RA to obtain > /64 prefix") could be dropped altogether. > See what I mean? We're already talking about not using RAs at all any more, and we don't even have a DHCPv6 route option yet... --20cf3005dd901ce0f304b30cc85d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Dec 1, 2011 at 10:40, Alexandru Petrescu= <alexandru.petrescu@gmail.com> wrote:
Le 01/12/2011 18:24, Tao Sun a =E9crit :

Hi Jouni, Thanks for the clarification. That is ture GGSN/PGW is not
mandate to do relay. "May" instead of "shall" is used t= o describe
GGSN/PGW's action. The only mandate is to use RA to obtain /64
prefix.

And that mandate is not sufficient when the UE is actually a Router
("mobile hotspot", "tethering"). =A0For these cases, DH= CPv6-PD is
suggested by 3GPP specs. =A0Thus, the 3GPP specs assume that a UE-Router (new term for this conversation) runs both RA _and_ DHCP. =A0But 3GPP
specs overlook the fact that an UE-Router would't use RA to
auto-configure an address (stateless autoconf is only for Hosts).

That's not true - RFC 6204 says that an IPv6 CE = router can use autoconf to create an address. I think it's reasonable t= o say that if you were to implement tethering using DHCPv6 PD, you would fo= llow RFC 6204.
=A0
Hence=A03GPP specs could consi= der that _only_ DHCP should should be used by=A0DHCPv6. =A0In this sense, t= he above only mandate ("use RA to obtain /64=A0prefix") could be = dropped altogether.

See what I mean? We're already talking= about not using RAs at all any more, and we don't even have a DHCPv6 r= oute option yet...
--20cf3005dd901ce0f304b30cc85d-- From Ted.Lemon@nominum.com Thu Dec 1 11:35:03 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 E67F811E80D6 for ; Thu, 1 Dec 2011 11:35:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.464 X-Spam-Level: X-Spam-Status: No, score=-106.464 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 wJX5Ft-pGaZO for ; Thu, 1 Dec 2011 11:35:03 -0800 (PST) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by ietfa.amsl.com (Postfix) with ESMTP id 0A77611E8095 for ; Thu, 1 Dec 2011 11:35:02 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKTtfW5v8TOe74UlwsZ/jnlpXX/I2zpBbV@postini.com; Thu, 01 Dec 2011 11:35:03 PST 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 16AB71B828D for ; Thu, 1 Dec 2011 11:35:02 -0800 (PST) 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 09ED3190052; Thu, 1 Dec 2011 11:35:02 -0800 (PST) (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.0339.001; Thu, 1 Dec 2011 11:35:02 -0800 From: Ted Lemon To: Lorenzo Colitti Thread-Topic: [mif] Use cases for draft-ietf-mif-dhcpv6-route-option needed Thread-Index: AQHMpeNOuu/E0pVKc0uk0cJFS4z9vZWzLpa7gAYCCQCAAF+4gIAAK9UAgAAIrACADIz6AIAAAUwAgAA15ICAAB90AIABM/WAgAAFv4CAAAO0AIAAEKiAgAAEcAA= Date: Thu, 1 Dec 2011 19:35:01 +0000 Message-ID: References: <282BBE8A501E1F4DA9C775F964BB21FE3EB78C3C98@GRFMBX704BA020.griffon.local> <916CE6CF87173740BC8A2CE44309696204193417@008-AM1MPN1-053.mgdnok.nokia.com> <4EC512A2.2060509@gmail.com> <890A58CF-8EAD-4F92-9981-9B5AA07EBF00@nominum.com> <4EC63E26.70104@gmail.com> <86163A8F-8628-4F67-BE93-3747F95A2F52@nominum.com> <4ECB6EAE.2010701@gmail.com> <702C34B3-F6B7-4EFB-91D5-8538540534A1@nominum.com> <4ECBE3BE.5070501@gmail.com> <759E821F-B503-4C8D-A79B-5F9A68A3613F@nominum.com> <4ED6A08D.9090703@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_CA1C0151930A4ED9BD25B0CDC2BAC60Dnominumcom_" MIME-Version: 1.0 Cc: "mif@ietf.org" Subject: Re: [mif] Use cases for draft-ietf-mif-dhcpv6-route-option needed 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, 01 Dec 2011 19:35:04 -0000 --_000_CA1C0151930A4ED9BD25B0CDC2BAC60Dnominumcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Dec 1, 2011, at 2:19 PM, Lorenzo Colitti wrote: Why? In BBF scenarios, the VLANs are almost always created on-demand. I thi= nk that was one of the major use cases presented for this option, right? I don't actually know what the BBF is doing. If they are creating per-cus= tomer VLANs in this case, then you're right. But I think the intention he= re was to have less state in the edge routers, not more. Using dynamicall= y-created per-customer VLANs isn't less state. --_000_CA1C0151930A4ED9BD25B0CDC2BAC60Dnominumcom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <2F4173E4B7F79A4A9469C5E948C3F66C@nominum.com> Content-Transfer-Encoding: quoted-printable
On Dec 1, 2011, at 2:19 PM, Lorenzo Colitti wrote:
Why? In BBF scenarios, the VLANs are almost always created on-demand. I think t= hat was one of the major use cases presented for this option, right?=

I don't actually know what the BBF is doing.   If they are creati= ng per-customer VLANs in this case, then you're right.   But I think t= he intention here was to have less state in the edge routers, not more. &nb= sp; Using dynamically-created per-customer VLANs isn't less state.

--_000_CA1C0151930A4ED9BD25B0CDC2BAC60Dnominumcom_-- From jouni.nospam@gmail.com Thu Dec 1 12:01:23 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 35D1211E8114 for ; Thu, 1 Dec 2011 12:01:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 UEIYoFr6nZII for ; Thu, 1 Dec 2011 12:01:22 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 012E21F0C36 for ; Thu, 1 Dec 2011 11:59:53 -0800 (PST) Received: by lahj13 with SMTP id j13so1066437lah.31 for ; Thu, 01 Dec 2011 11:59:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=FBGfYiZd8YRt5PU0NU5Am5PF8yOKB3ObqnNCt4r6TEk=; b=foRgt//duuHv6KGYj+yKsKKAOs6ivea7OxVYGJNfipcRh0kIIkaX18BfkY71oinnM9 FimkOIu8aulPru4kJM696uwaehHmxMYDdfXW0ZCc8lZECiirgCgt8w81pk+YLeL/bkkT CuyMnPRYeXDgNhjrGZd6ny7dPSvEr4hj4i+AM= Received: by 10.152.130.71 with SMTP id oc7mr5735978lab.25.1322769592727; Thu, 01 Dec 2011 11:59:52 -0800 (PST) Received: from a88-112-207-66.elisa-laajakaista.fi (a88-112-207-66.elisa-laajakaista.fi. [88.112.207.66]) by mx.google.com with ESMTPS id pw12sm6093086lab.13.2011.12.01.11.59.50 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 01 Dec 2011 11:59:51 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: Date: Thu, 1 Dec 2011 21:59:49 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5BD543FE-A152-44C3-A1D7-4CC2AFF5DA68@gmail.com> References: <282BBE8A501E1F4DA9C775F964BB21FE3EB78C3C98@GRFMBX704BA020.griffon.local> <916CE6CF87173740BC8A2CE44309696204193417@008-AM1MPN1-053.mgdnok.nokia.com> <4EC512A2.2060509@gmail.com> <890A58CF-8EAD-4F92-9981-9B5AA07EBF00@nominum.com> <4EC63E26.70104@gmail.com> <86163A8F-8628-4F67-BE93-3747F95A2F52@nominum.com> <4ECB6EAE.2010701@gmail.com> <702C34B3-F6B7-4EFB-91D5-8538540534A1@nominum.com> <4ECBE3BE.5070501@gmail.com> <759E821F-B503-4C8D-A79B-5F9A68A3613F@nominum.com> <7C1F8DA5-357F-4403-BE0D-E72D425B71C9@gmail.com> To: Tao Sun X-Mailer: Apple Mail (2.1084) Cc: mif@ietf.org Subject: Re: [mif] Use cases for draft-ietf-mif-dhcpv6-route-option needed 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, 01 Dec 2011 20:01:23 -0000 Actually.. to be more precise. Stage-2 and stage-3 have a slightly = different view on this "DHCP matter", and depending on spec and whether = it is about v4 or v6. I did remember with a bit lag there was something = fishy about this ;) =20 So, lets put in this way. There should not be a DHCPv6 relay in GGSN/PGW = according to architecture, rather explicitly stated server and client = functions. However, protocol specs do give an example of relay = functionality. Therefore, we can assume someone actually might have = implemented a relay in GGSN/PGW. - Jouni On Dec 1, 2011, at 7:24 PM, Tao Sun wrote: > Hi Jouni, > =20 > Thanks for the clarification. That is ture GGSN/PGW is not mandate to = do relay. "May" instead of "shall" is used to describe GGSN/PGW's = action. The only mandate is to use RA to obtain /64 prefix. > =20 > Regards, > =20 > Tao > On Fri, Dec 2, 2011 at 12:43 AM, jouni korhonen = wrote: >=20 >=20 > On Nov 30, 2011, at 8:18 PM, Tao Sun wrote: >=20 > > Forgot to include a website link in the previous email. Now I = included it. > > > > Regards, > > > > Tao Sun > > > > On Thu, Dec 1, 2011 at 2:13 AM, Tao Sun wrote: > > Hi All, > > > > Thanks for the discussion. As one of the author of the draft, I = would like to share our view on DHCPv6 used case in three aspects. > > *Network management and configuration. > > 1. It is efficient for the network to configure this in a central = DHCPv6 server to do unified routing policy configuration. The gateways = (e.g., GGSN in cellular network) only need to perform DHCPv6 relay. >=20 > Just want to point out that 3GPP specs do not define/mandate DHCPv6 = relay function in GGSN/PGW.. It is a server when seen from the UE point = of view. >=20 > [snip] >=20 > - JOuni >=20 >=20 >=20 >=20 From Fred.L.Templin@boeing.com Thu Dec 1 12:10:54 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 B7C5811E80EF for ; Thu, 1 Dec 2011 12:10:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 Zjg1jwhDISEu for ; Thu, 1 Dec 2011 12:10:48 -0800 (PST) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by ietfa.amsl.com (Postfix) with ESMTP id C50B911E8089 for ; Thu, 1 Dec 2011 12:10:47 -0800 (PST) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by stl-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id pB1KAWnC013740 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 1 Dec 2011 14:10:33 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with SMTP id pB1KA64O009914; Thu, 1 Dec 2011 12:10:23 -0800 (PST) Received: from XCH-NWHT-06.nw.nos.boeing.com (xch-nwht-06.nw.nos.boeing.com [130.247.25.110]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id pB1K9vS3009473 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Thu, 1 Dec 2011 12:09:58 -0800 (PST) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-06.nw.nos.boeing.com ([130.247.25.110]) with mapi; Thu, 1 Dec 2011 12:09:57 -0800 From: "Templin, Fred L" To: Andrew Sullivan Date: Thu, 1 Dec 2011 12:09:56 -0800 Thread-Topic: [mif] IRON as a multiple interface solution Thread-Index: Acyt+SVzR1PpkUYRTvCp3A+bmVJOzQCYBPHA Message-ID: References: <4EC5B720.8020605@gmail.com> <83A7D27A-9036-4252-AC94-3A89125C961B@nominum.com> <4EC63ECC.8010700@gmail.com> <20111119220355.GA893@shinkuro.com> <20111128181115.GC45293@shinkuro.com> In-Reply-To: <20111128181115.GC45293@shinkuro.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mif@ietf.org" Subject: Re: [mif] IRON as a multiple interface solution 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, 01 Dec 2011 20:10:54 -0000 Hi Andrew, I took the time to go off and look at the mif wg documents. All of it is good work - and all of it is compatible with IRON. The mif documents talk about two primary classes of interfaces: 1) ISP interfaces, and 2) VPN interfaces. IRON introduces a third class of interface which can be considered an "Internet interface". While it is true that most ISP interfaces provide access to the Internet, ISP interfaces have volatile configuration information that can change, e.g., if the ISP point of connection changes. Conversely, the IRON Internet interface has non-volatile configuration information that remains the same even if the ISP connections change (e.g., if the node is mobile). Since ISP interfaces may have access to private namespaces, those interfaces (along with their associated IP addresses) can be chosen for DNS resolution and for accessing services within the private namespace the same as described in the mif documents. Since the IRON Internet interface has a non-volatile configuration on the open Internet, however, it provides a stable handle for default communications with Internet-based correspondents. Again, this is all very compatible with the mif work, and fits like a glove with what IRON expects. Thanks - Fred fred.l.templin@boeing.com =20 > -----Original Message----- > From: Andrew Sullivan [mailto:ajs@anvilwalrusden.com]=20 > Sent: Monday, November 28, 2011 10:11 AM > To: Templin, Fred L > Cc: Hui Deng; Andrew Sullivan; mif@ietf.org > Subject: Re: [mif] IRON as a multiple interface solution >=20 > On Mon, Nov 28, 2011 at 09:22:45AM -0800, Templin, Fred L wrote: > > That said, IRON does not preclude the host from accessing > > services within the underlying ISP networks. To do so, > > however, the host would have to use its ISP-delegated > > address(es) and not the VSP-delegated address. > >=20 > > Does this match your understanding? >=20 > The central problem, however, is that if you are looking up the > address for a name, you don't obviously know where it is (i.e. you > don't know what network you need to go to). What I don't get in the > IRON approach is how you cope with the fact that a user simply types > some name into an application. We can't hardly ask them which network > they want to use to look up the name. The MIF approach, as much as it > makes me airsick, does address that issue. >=20 > A >=20 > --=20 > Andrew Sullivan > ajs@anvilwalrusden.com > = From jouni.nospam@gmail.com Thu Dec 1 12:17:58 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 1154F11E8143 for ; Thu, 1 Dec 2011 12:17:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 8278pRneA4k7 for ; Thu, 1 Dec 2011 12:17:57 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 501CE11E80EF for ; Thu, 1 Dec 2011 12:17:57 -0800 (PST) Received: by lahj13 with SMTP id j13so1075644lah.31 for ; Thu, 01 Dec 2011 12:17:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=57xMHWbge9dDgEJxzynsSIieZmUI0ROeDmR6d/9GXA0=; b=CyErZJ1i9g2ktBkIxJwr37EcziLbq4C9PVHEp2AvSk506NGyD53tJJwgws2Ym7i/Qu Z/wi0z1L21G0vrOcY1PMpitcdr2G8l2AxGROaViCghcfswe1UG5ldghrseFCUhbbW77v j3tYk7hzxwiPAOxcWsoRJORWHbFSJIlBjIzqc= Received: by 10.152.110.99 with SMTP id hz3mr5902300lab.29.1322770676298; Thu, 01 Dec 2011 12:17:56 -0800 (PST) Received: from a88-112-207-66.elisa-laajakaista.fi (a88-112-207-66.elisa-laajakaista.fi. [88.112.207.66]) by mx.google.com with ESMTPS id px20sm6162725lab.2.2011.12.01.12.17.53 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 01 Dec 2011 12:17:54 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <4ED6A08D.9090703@gmail.com> Date: Thu, 1 Dec 2011 22:17:51 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9ACC70F6-6D21-4981-A3CE-BA3469658F62@gmail.com> References: <282BBE8A501E1F4DA9C775F964BB21FE3EB78C3C98@GRFMBX704BA020.griffon.local> <916CE6CF87173740BC8A2CE44309696204193417@008-AM1MPN1-053.mgdnok.nokia.com> <4EC512A2.2060509@gmail.com> <890A58CF-8EAD-4F92-9981-9B5AA07EBF00@nominum.com> <4EC63E26.70104@gmail.com> <86163A8F-8628-4F67-BE93-3747F95A2F52@nominum.com> <4ECB6EAE.2010701@gmail.com> <702C34B3-F6B7-4EFB-91D5-8538540534A1@nominum.com> <4ECBE3BE.5070501@gmail.com> <759E821F-B503-4C8D-A79B-5F9A68A3613F@nominum.com> <4ED6A08D.9090703@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1084) Cc: "mif@ietf.org" Subject: Re: [mif] Use cases for draft-ietf-mif-dhcpv6-route-option needed 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, 01 Dec 2011 20:17:58 -0000 On Nov 30, 2011, at 11:30 PM, Brian E Carpenter wrote: [snip] >>> 3) The centralized relay architecture is a widely >>> used way at present for IPv4 and it will also be used for IPv6.=20 >=20 > That's the wrong way to say it IMHO. There are sound reasons why > operators want a centralised host management system with distributed > relays. The fact that the solution for IPv4 is called DHCP doesn't > imply that the best solution for IPv6 is called DHCPv6. However, until > there is a well-defined central management system for prefix = delegation > and routing options via RA, it seems that DHCPv6 *is* the only = available Like AAA? That is used and will be used a lot for address & prefix = management, and can also be used for distributing per subscriber route = information.=20 > solution. And then we loop back to point 1): it's better to have a = generic > option than a bunch of competing vendor options. I would not say competing vendor but competing SDO options. - Jouni > Brian > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif From brian.e.carpenter@gmail.com Thu Dec 1 13:15:11 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 922B921F93C2 for ; Thu, 1 Dec 2011 13:15:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 AJtwtmRPMcLV for ; Thu, 1 Dec 2011 13:15:11 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id D312E21F93BB for ; Thu, 1 Dec 2011 13:15:10 -0800 (PST) Received: by bkbzt19 with SMTP id zt19so3028586bkb.31 for ; Thu, 01 Dec 2011 13:15:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=2JU3LJrhY2+e+P6jJtsbgQbVshlVoxgAQaIN2wEZpHg=; b=qSL84lP6sIW42ZN2Pwlv1jmk1nTNk5p9ART/fYO3f/eyJ9MNIyR1/vu5EIc78h5cju 4+LALAZR+yGfuhjD4XnV4D0c9lfNvQM2V7EsYQemSJ30XhpXCGd9I/qszw3B77f5VOU1 8z3huGZKE9zIMtQQtYyLIf/Lg4L9rY2Eta/L0= Received: by 10.204.133.212 with SMTP id g20mr154231bkt.82.1322774109954; Thu, 01 Dec 2011 13:15:09 -0800 (PST) Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id q6sm14105394bka.6.2011.12.01.13.15.06 (version=SSLv3 cipher=OTHER); Thu, 01 Dec 2011 13:15:09 -0800 (PST) Message-ID: <4ED7EE53.8080402@gmail.com> Date: Fri, 02 Dec 2011 10:14:59 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Lorenzo Colitti References: <282BBE8A501E1F4DA9C775F964BB21FE3EB78C3C98@GRFMBX704BA020.griffon.local> <916CE6CF87173740BC8A2CE44309696204193417@008-AM1MPN1-053.mgdnok.nokia.com> <4EC512A2.2060509@gmail.com> <890A58CF-8EAD-4F92-9981-9B5AA07EBF00@nominum.com> <4EC63E26.70104@gmail.com> <86163A8F-8628-4F67-BE93-3747F95A2F52@nominum.com> <4ECB6EAE.2010701@gmail.com> <702C34B3-F6B7-4EFB-91D5-8538540534A1@nominum.com> <4ECBE3BE.5070501@gmail.com> <759E821F-B503-4C8D-A79B-5F9A68A3613F@nominum.com> <4ED6A08D.9090703@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "mif@ietf.org" Subject: Re: [mif] Use cases for draft-ietf-mif-dhcpv6-route-option needed 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, 01 Dec 2011 21:15:11 -0000 I'm not going to repeat my arguments because Tao Sun is doing a great job of explaining why DHCPv6 is going to be used in any case. But on one point... On 2011-12-02 07:06, Lorenzo Colitti wrote: ... > I'm not talking about mobile networks specifically here. I think this > particular event (turning off RAs) is more likely that to happen on a wifi > network or an enterprise network. I really don't see that as a real risk. Any network manager that tried it would get so many help desk calls that it would be back on within the hour. Of course, we should make sure that all scenarios that we document in the IETF (and not just in MIF) make it clear that RA is a MUST with no exceptions. Brian From lorenzo@google.com Thu Dec 1 13:22:23 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 4213C21F9427 for ; Thu, 1 Dec 2011 13:22:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.858 X-Spam-Level: X-Spam-Status: No, score=-102.858 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 4BbxTxyb3+z4 for ; Thu, 1 Dec 2011 13:22:22 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id B0A3421F9426 for ; Thu, 1 Dec 2011 13:22:22 -0800 (PST) Received: by yenl9 with SMTP id l9so1480436yen.31 for ; Thu, 01 Dec 2011 13:22:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=K7M0IXZ2/o6JiWl015v9N7EQ1zEYVtdiTuQFDFpPptQ=; b=X+uLHHSH7vEqBjznWTS8wlUDiNmbpFwzmaHTmXaCoE/jaFN8mplSaec0anA4dJ/QrP 2zlQOd72lkH/WpHKQhEg== Received: by 10.101.180.18 with SMTP id h18mr2252393anp.51.1322774542295; Thu, 01 Dec 2011 13:22:22 -0800 (PST) Received: by 10.101.180.18 with SMTP id h18mr2252387anp.51.1322774542151; Thu, 01 Dec 2011 13:22:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.150.202.14 with HTTP; Thu, 1 Dec 2011 13:22:01 -0800 (PST) In-Reply-To: <4ED7EE53.8080402@gmail.com> References: <282BBE8A501E1F4DA9C775F964BB21FE3EB78C3C98@GRFMBX704BA020.griffon.local> <916CE6CF87173740BC8A2CE44309696204193417@008-AM1MPN1-053.mgdnok.nokia.com> <4EC512A2.2060509@gmail.com> <890A58CF-8EAD-4F92-9981-9B5AA07EBF00@nominum.com> <4EC63E26.70104@gmail.com> <86163A8F-8628-4F67-BE93-3747F95A2F52@nominum.com> <4ECB6EAE.2010701@gmail.com> <702C34B3-F6B7-4EFB-91D5-8538540534A1@nominum.com> <4ECBE3BE.5070501@gmail.com> <759E821F-B503-4C8D-A79B-5F9A68A3613F@nominum.com> <4ED6A08D.9090703@gmail.com> <4ED7EE53.8080402@gmail.com> From: Lorenzo Colitti Date: Thu, 1 Dec 2011 13:22:01 -0800 Message-ID: To: Brian E Carpenter Content-Type: multipart/alternative; boundary=001636c92695b3ef5004b30e72d0 X-System-Of-Record: true Cc: "mif@ietf.org" Subject: Re: [mif] Use cases for draft-ietf-mif-dhcpv6-route-option needed 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, 01 Dec 2011 21:22:23 -0000 --001636c92695b3ef5004b30e72d0 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Dec 1, 2011 at 13:14, Brian E Carpenter wrote: > > I'm not talking about mobile networks specifically here. I think this > > particular event (turning off RAs) is more likely that to happen on a > wifi > > network or an enterprise network. > > I really don't see that as a real risk. Any network manager that tried it > would get so many help desk calls that it would be back on within the hour. > Not once all operating systems (or all the operating systems that this particular network desires to support) support the DHCPv6 route option. > Of course, we should make sure that all scenarios that we document in > the IETF (and not just in MIF) make it clear that RA is a MUST with no > exceptions. For operators, it doesn't necessarily matter what we say. It matters what works and what doesn't. --001636c92695b3ef5004b30e72d0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Dec 1, 2011 at 13:14, Brian E Carpenter = <brian.= e.carpenter@gmail.com> wrote:
> I'm not talking about mobile networks specifical= ly here. I think this
> particular event (turning off RAs) is more likely that to happen on a = wifi
> network or an enterprise network.

I really don't see that as a real risk. Any network manager that = tried it
would get so many help desk calls that it would be back on within the hour.=

Not once all operating systems (or all= the operating systems that this particular network desires to support) sup= port the DHCPv6 route option.
=A0
Of course, we should make sure that all scenarios that we document in the= =A0IETF (and not just in MIF) make it clear that RA is a MUST with no excep= tions.

For operators, it doesn't necess= arily matter what we say. It matters what works and what doesn't.
--001636c92695b3ef5004b30e72d0-- From brian.e.carpenter@gmail.com Thu Dec 1 13: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 43B4111E80BE for ; Thu, 1 Dec 2011 13:34:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.449 X-Spam-Level: X-Spam-Status: No, score=-103.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, 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 8i6Bco0+TOXe for ; Thu, 1 Dec 2011 13:34:05 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 037EC11E80BB for ; Thu, 1 Dec 2011 13:34:04 -0800 (PST) Received: by faap14 with SMTP id p14so2065135faa.31 for ; Thu, 01 Dec 2011 13:34:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Dv3HSu1CR3sve/tBo17m3Ap9/rzKS6PuSMlL6151rCQ=; b=dJ9E4U5I+NHmZccevAJH5fshOz7sIyoFHoERkZQLt/F5UfRgcmxTSTFBzexUYndmXQ F518D3aYSnghLiQvNXqkxVulxLoNcEpfjPb3uobVILGzhuLXSkwNHm2trbnkkmgqVBD0 /5/gCuxq9RS6Lw3ApzGhLtgDB7xsYzcQsTj4E= Received: by 10.205.132.146 with SMTP id hu18mr9410284bkc.123.1322775240899; Thu, 01 Dec 2011 13:34:00 -0800 (PST) Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id e18sm14167405bkr.15.2011.12.01.13.33.58 (version=SSLv3 cipher=OTHER); Thu, 01 Dec 2011 13:34:00 -0800 (PST) Message-ID: <4ED7F2C0.4040902@gmail.com> Date: Fri, 02 Dec 2011 10:33:52 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: jouni korhonen References: <282BBE8A501E1F4DA9C775F964BB21FE3EB78C3C98@GRFMBX704BA020.griffon.local> <916CE6CF87173740BC8A2CE44309696204193417@008-AM1MPN1-053.mgdnok.nokia.com> <4EC512A2.2060509@gmail.com> <890A58CF-8EAD-4F92-9981-9B5AA07EBF00@nominum.com> <4EC63E26.70104@gmail.com> <86163A8F-8628-4F67-BE93-3747F95A2F52@nominum.com> <4ECB6EAE.2010701@gmail.com> <702C34B3-F6B7-4EFB-91D5-8538540534A1@nominum.com> <4ECBE3BE.5070501@gmail.com> <759E821F-B503-4C8D-A79B-5F9A68A3613F@nominum.com> <4ED6A08D.9090703@gmail.com> <9ACC70F6-6D21-4981-A3CE-BA3469658F62@gmail.com> In-Reply-To: <9ACC70F6-6D21-4981-A3CE-BA3469658F62@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "mif@ietf.org" Subject: Re: [mif] Use cases for draft-ietf-mif-dhcpv6-route-option needed 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, 01 Dec 2011 21:34:06 -0000 On 2011-12-02 09:17, jouni korhonen wrote: > On Nov 30, 2011, at 11:30 PM, Brian E Carpenter wrote: > > [snip] > > >>>> 3) The centralized relay architecture is a widely >>>> used way at present for IPv4 and it will also be used for IPv6. >> That's the wrong way to say it IMHO. There are sound reasons why >> operators want a centralised host management system with distributed >> relays. The fact that the solution for IPv4 is called DHCP doesn't >> imply that the best solution for IPv6 is called DHCPv6. However, until >> there is a well-defined central management system for prefix delegation >> and routing options via RA, it seems that DHCPv6 *is* the only available > > Like AAA? That is used and will be used a lot for address & prefix management, and can also be used for distributing per subscriber route information. I stand corrected - the point is that AAA is centrally managed and tied to subscriber info. RA is neither in any present implementation that I'm aware of. It was designed thinking of completely unmanaged networks. >> solution. And then we loop back to point 1): it's better to have a generic >> option than a bunch of competing vendor options. > > I would not say competing vendor but competing SDO options. Procedurally, as far as the IETF is concerned, they would be vendor options I think. But in any case they would amount to solving the same problem N times. See http://www.tuv.com/media/germany/50_trainingandconsulting/pdf/patente/Circular_transportation_facilitation_device.pdf Brian From lorenzo@google.com Thu Dec 1 13:37:10 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 8E50511E8089 for ; Thu, 1 Dec 2011 13:37:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.863 X-Spam-Level: X-Spam-Status: No, score=-102.863 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 croprNzn6MP5 for ; Thu, 1 Dec 2011 13:37:09 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id BBCA011E809D for ; Thu, 1 Dec 2011 13:37:08 -0800 (PST) Received: by ghrr18 with SMTP id r18so2746925ghr.31 for ; Thu, 01 Dec 2011 13:37:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=Qv6ppyWYssqjLZOrQSkRxjLpAXestsAEGpOtYQ5n+4o=; b=BHiECDJ19JHzWAESWhEKkJUFHfJ+EVNOz+gk5ov7KNa6qB+0Y5IR4yIMJZkeKkBvO0 qtI/oVO+4mhjsmH4l0mg== Received: by 10.236.75.167 with SMTP id z27mr14934905yhd.53.1322775428357; Thu, 01 Dec 2011 13:37:08 -0800 (PST) Received: by 10.236.75.167 with SMTP id z27mr14934880yhd.53.1322775428119; Thu, 01 Dec 2011 13:37:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.150.202.14 with HTTP; Thu, 1 Dec 2011 13:36:47 -0800 (PST) In-Reply-To: <4ED7F2C0.4040902@gmail.com> References: <282BBE8A501E1F4DA9C775F964BB21FE3EB78C3C98@GRFMBX704BA020.griffon.local> <916CE6CF87173740BC8A2CE44309696204193417@008-AM1MPN1-053.mgdnok.nokia.com> <4EC512A2.2060509@gmail.com> <890A58CF-8EAD-4F92-9981-9B5AA07EBF00@nominum.com> <4EC63E26.70104@gmail.com> <86163A8F-8628-4F67-BE93-3747F95A2F52@nominum.com> <4ECB6EAE.2010701@gmail.com> <702C34B3-F6B7-4EFB-91D5-8538540534A1@nominum.com> <4ECBE3BE.5070501@gmail.com> <759E821F-B503-4C8D-A79B-5F9A68A3613F@nominum.com> <4ED6A08D.9090703@gmail.com> <9ACC70F6-6D21-4981-A3CE-BA3469658F62@gmail.com> <4ED7F2C0.4040902@gmail.com> From: Lorenzo Colitti Date: Thu, 1 Dec 2011 13:36:47 -0800 Message-ID: To: Brian E Carpenter Content-Type: multipart/alternative; boundary=20cf3005dde682bb1704b30ea738 X-System-Of-Record: true Cc: "mif@ietf.org" Subject: Re: [mif] Use cases for draft-ietf-mif-dhcpv6-route-option needed 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, 01 Dec 2011 21:37:10 -0000 --20cf3005dde682bb1704b30ea738 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Dec 1, 2011 at 13:33, Brian E Carpenter wrote: > > Like AAA? That is used and will be used a lot for address & prefix > management, and can also be used for distributing per subscriber route > information. > > I stand corrected - the point is that AAA is centrally managed and tied > to subscriber info. RA is neither in any present implementation that I'm > aware of. That's not true. I have personally designed a network that used layer 2 information (VLAN tags) to cause a router to look up a prefix in RADIUS that it would then send out in an RA for hosts on that VLAN to do SLAAC. That's both centrally managed and tied to subscriber info. --20cf3005dde682bb1704b30ea738 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Dec 1, 2011 at 13:33, Brian E Carpenter = <brian.= e.carpenter@gmail.com> wrote:
> Like AAA? That is used and will be used a lot for ad= dress & prefix management, and can also be used for distributing per su= bscriber route information.

I stand corrected - the point is that AAA is centrally managed and ti= ed to=A0subscriber info. RA is neither in any present implementation that I= 'm aware=A0of.
=A0
That's not true. I ha= ve personally designed a network that used layer 2 information (VLAN tags) = to cause a router to look up a prefix in RADIUS that it would then send out= in an RA for hosts on that VLAN to do SLAAC. That's both centrally man= aged and tied to subscriber info.
--20cf3005dde682bb1704b30ea738-- From brian.e.carpenter@gmail.com Thu Dec 1 13:57:45 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 C51ED1F0CB7 for ; Thu, 1 Dec 2011 13:57:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.499 X-Spam-Level: X-Spam-Status: No, score=-103.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, 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 C5l52ie8rfqL for ; Thu, 1 Dec 2011 13:57:45 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 09FD61F0CBF for ; Thu, 1 Dec 2011 13:57:44 -0800 (PST) Received: by bkbzt19 with SMTP id zt19so3078291bkb.31 for ; Thu, 01 Dec 2011 13:57:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=F74+zMPnxykHeuP9jFKzt3SSSG4mmR49UqzRh41Qa/Y=; b=aTAwKNijY899ESzCPRW/VgisJMcdkgyi0bWZx5KU9AAyucnLbCWBznn8w5eZcC73vQ HlGtGdXqWyR70ZaV5yF7OE9/49qHu3dcYFFbgmfGLkZ1Dv7SpUROLEJLmbpF3Nopf/hc kvNk4kGKK8uYCpdjbXtKCnlTSZg5QiH/IATCI= Received: by 10.204.7.77 with SMTP id c13mr9304720bkc.32.1322776663989; Thu, 01 Dec 2011 13:57:43 -0800 (PST) Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id x14sm14341014bkf.10.2011.12.01.13.57.41 (version=SSLv3 cipher=OTHER); Thu, 01 Dec 2011 13:57:43 -0800 (PST) Message-ID: <4ED7F84E.9080906@gmail.com> Date: Fri, 02 Dec 2011 10:57:34 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Lorenzo Colitti References: <282BBE8A501E1F4DA9C775F964BB21FE3EB78C3C98@GRFMBX704BA020.griffon.local> <916CE6CF87173740BC8A2CE44309696204193417@008-AM1MPN1-053.mgdnok.nokia.com> <4EC512A2.2060509@gmail.com> <890A58CF-8EAD-4F92-9981-9B5AA07EBF00@nominum.com> <4EC63E26.70104@gmail.com> <86163A8F-8628-4F67-BE93-3747F95A2F52@nominum.com> <4ECB6EAE.2010701@gmail.com> <702C34B3-F6B7-4EFB-91D5-8538540534A1@nominum.com> <4ECBE3BE.5070501@gmail.com> <759E821F-B503-4C8D-A79B-5F9A68A3613F@nominum.com> <4ED6A08D.9090703@gmail.com> <9ACC70F6-6D21-4981-A3CE-BA3469658F62@gmail.com> <4ED7F2C0.4040902@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "mif@ietf.org" Subject: Re: [mif] Use cases for draft-ietf-mif-dhcpv6-route-option needed 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, 01 Dec 2011 21:57:45 -0000 On 2011-12-02 10:36, Lorenzo Colitti wrote: > On Thu, Dec 1, 2011 at 13:33, Brian E Carpenter > wrote: > >>> Like AAA? That is used and will be used a lot for address & prefix >> management, and can also be used for distributing per subscriber route >> information. >> >> I stand corrected - the point is that AAA is centrally managed and tied >> to subscriber info. RA is neither in any present implementation that I'm >> aware of. > > > That's not true. I have personally designed a network that used layer 2 > information (VLAN tags) to cause a router to look up a prefix in RADIUS > that it would then send out in an RA for hosts on that VLAN to do SLAAC. > That's both centrally managed and tied to subscriber info. If you're using VLANs you are operating multiple LANs as far as IP is concerned, so this is not really solving the problem of heterogeneous hosts on the same LAN. I have to say that using VLANs in low-end networks is very similar to attaching booster rockets to a pig that refuses to fly. Surely we (the IETF) should be aiming to solve this problem at L3? I'm not saying that the RA architecture can't be enhanced to support this - for example by describing a stateful RA server - but that really would end up looking awfully like a DHCPv6 server in all but protocol details. Brian From Ted.Lemon@nominum.com Thu Dec 1 14:23:13 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 0E5F91F0C38 for ; Thu, 1 Dec 2011 14:23:13 -0800 (PST) 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.121, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 adL0f+Ul0DOK for ; Thu, 1 Dec 2011 14:23:12 -0800 (PST) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 4C17521F9441 for ; Thu, 1 Dec 2011 14:23:12 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKTtf+T0ATZFGa5Ex+6Hoaa5/4ImZguICa@postini.com; Thu, 01 Dec 2011 14:23:12 PST 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 4567A1B82BF for ; Thu, 1 Dec 2011 14:23:11 -0800 (PST) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (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 315C2190052; Thu, 1 Dec 2011 14:23:10 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.01.0339.001; Thu, 1 Dec 2011 14:23:10 -0800 From: Ted Lemon To: Brian E Carpenter Thread-Topic: [mif] Use cases for draft-ietf-mif-dhcpv6-route-option needed Thread-Index: AQHMpeNOuu/E0pVKc0uk0cJFS4z9vZWzLpa7gAYCCQCAAF+4gIAAK9UAgAAIrACADIz6AIAAAUwAgAA15ICAAX3tgIAAFT0AgAAA0YCAAAXOAP//gQrv Date: Thu, 1 Dec 2011 22:23:09 +0000 Message-ID: References: <282BBE8A501E1F4DA9C775F964BB21FE3EB78C3C98@GRFMBX704BA020.griffon.local> <916CE6CF87173740BC8A2CE44309696204193417@008-AM1MPN1-053.mgdnok.nokia.com> <4EC512A2.2060509@gmail.com> <890A58CF-8EAD-4F92-9981-9B5AA07EBF00@nominum.com> <4EC63E26.70104@gmail.com> <86163A8F-8628-4F67-BE93-3747F95A2F52@nominum.com> <4ECB6EAE.2010701@gmail.com> <702C34B3-F6B7-4EFB-91D5-8538540534A1@nominum.com> <4ECBE3BE.5070501@gmail.com> <759E821F-B503-4C8D-A79B-5F9A68A3613F@nominum.com> <4ED6A08D.9090703@gmail.com> <9ACC70F6-6D21-4981-A3CE-BA3469658F62@gmail.com> <4ED7F2C0.4040902@gmail.com> , <4ED7F84E.9080906@gmail.com> In-Reply-To: <4ED7F84E.9080906@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mif@ietf.org" Subject: Re: [mif] Use cases for draft-ietf-mif-dhcpv6-route-option needed 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, 01 Dec 2011 22:23:13 -0000 On Dec 1, 2011, at 4:57 PM, "Brian E Carpenter" wrote: > I'm not saying that the RA architecture can't be enhanced to support > this - for example by describing a stateful RA server - but that > really would end up looking awfully like a DHCPv6 server in all but > protocol details. One small advantage to this would be that the change would only be required= on the router, not on the nodes being configured by the router. From lorenzo@google.com Thu Dec 1 14:23:59 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 487DB21F92C7 for ; Thu, 1 Dec 2011 14:23:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.871 X-Spam-Level: X-Spam-Status: No, score=-102.871 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 5b0-yK2DkDjQ for ; Thu, 1 Dec 2011 14:23:58 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id B0A8A21F8481 for ; Thu, 1 Dec 2011 14:23:58 -0800 (PST) Received: by yenl9 with SMTP id l9so1538142yen.31 for ; Thu, 01 Dec 2011 14:23:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=iXs+2bFhrWGZ03JyeyCrOlFAn8Iu2M28C7QGKgjwPSQ=; b=DKrCqxt3j4ScT0Ry4WPWlD4jqcvvHWDqm7ci5Jq3OU2gssoXm/CoTov2inWezu4ZkO /6d94e8EI+if0Q08uyMw== Received: by 10.236.183.52 with SMTP id p40mr15000482yhm.19.1322778238334; Thu, 01 Dec 2011 14:23:58 -0800 (PST) Received: by 10.236.183.52 with SMTP id p40mr15000459yhm.19.1322778238140; Thu, 01 Dec 2011 14:23:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.150.202.14 with HTTP; Thu, 1 Dec 2011 14:23:37 -0800 (PST) In-Reply-To: <4ED7F84E.9080906@gmail.com> References: <282BBE8A501E1F4DA9C775F964BB21FE3EB78C3C98@GRFMBX704BA020.griffon.local> <916CE6CF87173740BC8A2CE44309696204193417@008-AM1MPN1-053.mgdnok.nokia.com> <4EC512A2.2060509@gmail.com> <890A58CF-8EAD-4F92-9981-9B5AA07EBF00@nominum.com> <4EC63E26.70104@gmail.com> <86163A8F-8628-4F67-BE93-3747F95A2F52@nominum.com> <4ECB6EAE.2010701@gmail.com> <702C34B3-F6B7-4EFB-91D5-8538540534A1@nominum.com> <4ECBE3BE.5070501@gmail.com> <759E821F-B503-4C8D-A79B-5F9A68A3613F@nominum.com> <4ED6A08D.9090703@gmail.com> <9ACC70F6-6D21-4981-A3CE-BA3469658F62@gmail.com> <4ED7F2C0.4040902@gmail.com> <4ED7F84E.9080906@gmail.com> From: Lorenzo Colitti Date: Thu, 1 Dec 2011 14:23:37 -0800 Message-ID: To: Brian E Carpenter Content-Type: multipart/alternative; boundary=bcaec52c5ea900413b04b30f4ff2 X-System-Of-Record: true Cc: "mif@ietf.org" Subject: Re: [mif] Use cases for draft-ietf-mif-dhcpv6-route-option needed 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, 01 Dec 2011 22:23:59 -0000 --bcaec52c5ea900413b04b30f4ff2 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Dec 1, 2011 at 13:57, Brian E Carpenter wrote: > If you're using VLANs you are operating multiple LANs as far as IP > is concerned, so this is not really solving the problem of heterogeneous > hosts on the same LAN. > Correct. I'm making the statement that in many of the use cases I've heard so far, you don't have to solve this problem by changing the protocols that are defined (e.g., by adding a route option), you can solve it at a different layer, and that doing so is actually simpler. In the BBF use case, for example, the hosts are actually forbidden to talk to each other without using the BNG as an intermediary (for various reasons including legal intercept, billing, and so on). In this case, using separate VLANs is actually a much better solution than the complex combination of DHCP snooping, ARP spoofing, and MAC-to-IP forcing that is done in many existing deployments today. The complex solution works in IPv4, but it really starts to show its limitations in IPv6. I don't think the right solution is to complicate IPv6 until it reaches the level of complexity that we have been forced to reach in IPv4 due to address exhaustion and the resort to NATs as a crutch that allows the network operator to fix the problem by making the application layer more complex. --bcaec52c5ea900413b04b30f4ff2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Dec 1, 2011 at 13:57, Brian E Carpenter = <brian.= e.carpenter@gmail.com> wrote:
If you're using VLANs you are o= perating multiple LANs as far as IP
is concerned, so this is not really solving the problem of heterogeneous hosts on the same LAN.

Correct. I'm= making the statement that in many of the use cases I've heard so far, = you don't have to solve this problem by changing the protocols that are= defined (e.g., by adding a route option), you can solve it at a different = layer, and that doing so is actually simpler.

In the BBF use case, for example, the hosts are actuall= y forbidden to talk to each other without using the BNG as an intermediary = (for various reasons including legal intercept, billing, and so on). In thi= s case, using separate VLANs is actually a much better solution than the co= mplex combination of DHCP snooping, ARP spoofing, and MAC-to-IP forcing tha= t is done in many existing deployments today. The complex solution=A0works = in IPv4, but it really starts to show its limitations in IPv6.

I don't think the right solution is to complicate I= Pv6 until it reaches the level of complexity that we have been forced to re= ach in IPv4 due to address exhaustion and the resort to NATs as a crutch th= at allows the network operator to fix the problem by making the application= layer more complex.
--bcaec52c5ea900413b04b30f4ff2-- From jouni.nospam@gmail.com Thu Dec 1 22:53:25 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 DDE541F0C74 for ; Thu, 1 Dec 2011 22:53:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 I42ZsAhrNU9t for ; Thu, 1 Dec 2011 22:53:25 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id B58F21F0C6C for ; Thu, 1 Dec 2011 22:53:24 -0800 (PST) Received: by lahj13 with SMTP id j13so1246069lah.31 for ; Thu, 01 Dec 2011 22:53:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=4H7NqW15HbQZfusoRLgvsMUDs4IW3AFZNIUcr1mRziM=; b=gIFxesC+Yq2HUmTCzf9onqAvMLUBHvEo4vvIrzBp5e2aRTU5ALKd46dgKp+QHAzCUx UdgO5AMFmD7GcslThvESnTqRhfci+mJ6VfF+fRIC+LXTxLVfjWwqdzf63F3/H03nCLYD hJuJHNs+Hlqk7p8mEAh4PspM9HHQn7WrAM4oY= Received: by 10.152.103.51 with SMTP id ft19mr6773811lab.42.1322808803671; Thu, 01 Dec 2011 22:53:23 -0800 (PST) Received: from a88-112-207-66.elisa-laajakaista.fi (a88-112-207-66.elisa-laajakaista.fi. [88.112.207.66]) by mx.google.com with ESMTPS id op2sm7425020lab.6.2011.12.01.22.53.20 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 01 Dec 2011 22:53:21 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <4ED7F2C0.4040902@gmail.com> Date: Fri, 2 Dec 2011 08:53:18 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5AB3B2FC-8914-42AB-9173-8172D926462F@gmail.com> References: <282BBE8A501E1F4DA9C775F964BB21FE3EB78C3C98@GRFMBX704BA020.griffon.local> <916CE6CF87173740BC8A2CE44309696204193417@008-AM1MPN1-053.mgdnok.nokia.com> <4EC512A2.2060509@gmail.com> <890A58CF-8EAD-4F92-9981-9B5AA07EBF00@nominum.com> <4EC63E26.70104@gmail.com> <86163A8F-8628-4F67-BE93-3747F95A2F52@nominum.com> <4ECB6EAE.2010701@gmail.com> <702C34B3-F6B7-4EFB-91D5-8538540534A1@nominum.com> <4ECBE3BE.5070501@gmail.com> <759E821F-B503-4C8D-A79B-5F9A68A3613F@nominum.com> <4ED6A08D.9090703@gmail.com> <9ACC70F6-6D21-4981-A3CE-BA3469658F62@gmail.com> <4ED7F2C0.4040902@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1084) Cc: "mif@ietf.org" Subject: Re: [mif] Use cases for draft-ietf-mif-dhcpv6-route-option needed 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, 02 Dec 2011 06:53:26 -0000 Hi, On Dec 1, 2011, at 11:33 PM, Brian E Carpenter wrote: > On 2011-12-02 09:17, jouni korhonen wrote: >> On Nov 30, 2011, at 11:30 PM, Brian E Carpenter wrote: >>=20 >> [snip] >>=20 >>=20 >>>>> 3) The centralized relay architecture is a widely >>>>> used way at present for IPv4 and it will also be used for IPv6.=20 >>> That's the wrong way to say it IMHO. There are sound reasons why >>> operators want a centralised host management system with distributed >>> relays. The fact that the solution for IPv4 is called DHCP doesn't >>> imply that the best solution for IPv6 is called DHCPv6. However, = until >>> there is a well-defined central management system for prefix = delegation >>> and routing options via RA, it seems that DHCPv6 *is* the only = available >>=20 >> Like AAA? That is used and will be used a lot for address & prefix = management, and can also be used for distributing per subscriber route = information.=20 >=20 > I stand corrected - the point is that AAA is centrally managed and = tied to > subscriber info. RA is neither in any present implementation that I'm = aware > of. It was designed thinking of completely unmanaged networks. Latest yesterday I tweaked with such implementation. It is quite common = feature e.g. in 3GPP defined networks that the per subscriber prefix for = RA comes off AAA. It has been there in specs for say 9 years and = deployed at least several years. Also the per subscriber delegated = prefixes may come from AAA.. like the rest of the end host configuration = information. >=20 >>> solution. And then we loop back to point 1): it's better to have a = generic >>> option than a bunch of competing vendor options. >>=20 >> I would not say competing vendor but competing SDO options. >=20 > Procedurally, as far as the IETF is concerned, they would be vendor > options I think. But in any case they would amount to solving the same > problem N times. See > = http://www.tuv.com/media/germany/50_trainingandconsulting/pdf/patente/Circ= ular_transportation_facilitation_device.pdf great stuff ;-)=20 - Jouni >=20 > Brian From zehn.cao@gmail.com Fri Dec 2 00:39:33 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 88CE321F9398 for ; Fri, 2 Dec 2011 00:39:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 jivlmWtGxTt4 for ; Fri, 2 Dec 2011 00:39:33 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id F3AD121F9309 for ; Fri, 2 Dec 2011 00:39:32 -0800 (PST) Received: by iaek3 with SMTP id k3so1493826iae.31 for ; Fri, 02 Dec 2011 00:39:32 -0800 (PST) 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:content-transfer-encoding; bh=y0uhFH5rXcdEzAlt0rNGjQYcvMDUhHIrEs8eWf0pCZU=; b=s36JF/eTbQsQk62WC5+UkyjVB25WDy3DuV6zQTmRez2BNG2yr869sdzQwtQMMRi4U0 o+vqE5Tx6rshyJFMx/jFi5VXvm9tFQjS6t+yeNgZ7fGmuoiqNzylvRVV4e6rjHAF8Nvs 1W2lQ6+PFj/JHyMCfohuH1hR63FNmDjZQpOfM= MIME-Version: 1.0 Received: by 10.42.161.9 with SMTP id r9mr12201726icx.49.1322815172568; Fri, 02 Dec 2011 00:39:32 -0800 (PST) Received: by 10.42.164.133 with HTTP; Fri, 2 Dec 2011 00:39:31 -0800 (PST) In-Reply-To: References: <282BBE8A501E1F4DA9C775F964BB21FE3EB78C3C98@GRFMBX704BA020.griffon.local> <916CE6CF87173740BC8A2CE44309696204193417@008-AM1MPN1-053.mgdnok.nokia.com> <4EC512A2.2060509@gmail.com> <890A58CF-8EAD-4F92-9981-9B5AA07EBF00@nominum.com> <4EC63E26.70104@gmail.com> <86163A8F-8628-4F67-BE93-3747F95A2F52@nominum.com> <4ECB6EAE.2010701@gmail.com> <702C34B3-F6B7-4EFB-91D5-8538540534A1@nominum.com> <4ECBE3BE.5070501@gmail.com> <759E821F-B503-4C8D-A79B-5F9A68A3613F@nominum.com> <4ED6A08D.9090703@gmail.com> <9ACC70F6-6D21-4981-A3CE-BA3469658F62@gmail.com> <4ED7F2C0.4040902@gmail.com> <4ED7F84E.9080906@gmail.com> Date: Fri, 2 Dec 2011 16:39:31 +0800 Message-ID: From: Zhen Cao To: Lorenzo Colitti Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "mif@ietf.org" Subject: Re: [mif] Use cases for draft-ietf-mif-dhcpv6-route-option needed 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, 02 Dec 2011 08:39:33 -0000 On Fri, Dec 2, 2011 at 6:23 AM, Lorenzo Colitti wrote: > On Thu, Dec 1, 2011 at 13:57, Brian E Carpenter > wrote: >> >> If you're using VLANs you are operating multiple LANs as far as IP >> is concerned, so this is not really solving the problem of heterogeneous >> hosts on the same LAN. > > > Correct. I'm making the statement that in many of the use cases I've hear= d > so far, you don't have to solve this problem by changing the protocols th= at > are defined (e.g., by adding a route option), you can solve it at a > different layer, and that doing so is actually simpler. > > In the BBF use case, for example, the hosts are actually forbidden to tal= k > to each other without using the BNG as an intermediary (for various reaso= ns > including legal intercept, billing, and so on). In this case, using separ= ate > VLANs is actually a much better solution than the complex combination of > DHCP snooping, ARP spoofing, and MAC-to-IP forcing that is done in many > existing deployments today. The complex solution=A0works in IPv4, but it > really starts to show its limitations in IPv6. For per-user configuration, the situation is that users are dynamic and I do not see how the VLAN can be configured according to their different requirements. If you use the extended information in the VLAN setup and use selective unicast RA in 3GPP case, I think that already reaches (and actually more complicated than) the threshold for doing it using DHCPv6. From denghui@chinamobile.com Fri Dec 2 01:12:03 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 C654621F994A for ; Fri, 2 Dec 2011 01:12:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.377 X-Spam-Level: X-Spam-Status: No, score=-0.377 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RELAY_IS_221=2.222] 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 56MW8aFELrlR for ; Fri, 2 Dec 2011 01:12:03 -0800 (PST) Received: from imss.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id CD6CE21F9949 for ; Fri, 2 Dec 2011 01:12:02 -0800 (PST) Received: from imss.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id BAFB2E803; Fri, 2 Dec 2011 17:12:01 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by imss.chinamobile.com (Postfix) with ESMTP id 94B8FE7F8; Fri, 2 Dec 2011 17:12:01 +0800 (CST) Received: from Hui ([10.2.2.169]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2011120217115871-16715 ; Fri, 2 Dec 2011 17:11:58 +0800 From: "Hui Deng" To: "'Templin, Fred L'" , "'Andrew Sullivan'" References: <4EC5B720.8020605@gmail.com> <83A7D27A-9036-4252-AC94-3A89125C961B@nominum.com> <4EC63ECC.8010700@gmail.com> <20111119220355.GA893@shinkuro.com> <20111128181115.GC45293@shinkuro.com> In-Reply-To: Date: Fri, 2 Dec 2011 17:12:00 +0800 Message-ID: <01da01ccb0d2$72f6f630$58e4e290$@com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acyt+SVzR1PpkUYRTvCp3A+bmVJOzQCYBPHAAB446gA= X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2011-12-02 17:11:58, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2011-12-02 17:12:00, Serialize complete at 2011-12-02 17:12:00 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" Content-Language: zh-cn X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-18554.006 X-TM-AS-Result: No--26.827-7.0-31-10 X-imss-scan-details: No--26.827-7.0-31-10;No--26.827-7.0-31-10 X-TM-AS-User-Approved-Sender: No;No X-TM-AS-User-Blocked-Sender: No Cc: mif@ietf.org Subject: Re: [mif] IRON as a multiple interface solution 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, 02 Dec 2011 09:12:04 -0000 Hi Fred You are saying current MIF document is compatible with IRON. And current MIF document has already solved MIF's issues, so guess that IRON is proposing something else like generic internet access which is out of MIF. Regards, -Hui > -----Original Message----- > From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of > Templin, Fred L > Sent: Friday, December 02, 2011 4:10 AM > To: Andrew Sullivan > Cc: mif@ietf.org > Subject: Re: [mif] IRON as a multiple interface solution > > Hi Andrew, > > I took the time to go off and look at the mif wg > documents. All of it is good work - and all of it > is compatible with IRON. > > The mif documents talk about two primary classes of > interfaces: 1) ISP interfaces, and 2) VPN interfaces. > IRON introduces a third class of interface which > can be considered an "Internet interface". > > While it is true that most ISP interfaces provide > access to the Internet, ISP interfaces have volatile > configuration information that can change, e.g., if > the ISP point of connection changes. Conversely, the > IRON Internet interface has non-volatile configuration > information that remains the same even if the ISP > connections change (e.g., if the node is mobile). > > Since ISP interfaces may have access to private > namespaces, those interfaces (along with their > associated IP addresses) can be chosen for DNS > resolution and for accessing services within the > private namespace the same as described in the mif > documents. Since the IRON Internet interface has > a non-volatile configuration on the open Internet, > however, it provides a stable handle for default > communications with Internet-based correspondents. > > Again, this is all very compatible with the mif > work, and fits like a glove with what IRON expects. > > Thanks - Fred > fred.l.templin@boeing.com > > > -----Original Message----- > > From: Andrew Sullivan [mailto:ajs@anvilwalrusden.com] > > Sent: Monday, November 28, 2011 10:11 AM > > To: Templin, Fred L > > Cc: Hui Deng; Andrew Sullivan; mif@ietf.org > > Subject: Re: [mif] IRON as a multiple interface solution > > > > On Mon, Nov 28, 2011 at 09:22:45AM -0800, Templin, Fred L wrote: > > > That said, IRON does not preclude the host from accessing > > > services within the underlying ISP networks. To do so, > > > however, the host would have to use its ISP-delegated > > > address(es) and not the VSP-delegated address. > > > > > > Does this match your understanding? > > > > The central problem, however, is that if you are looking up the > > address for a name, you don't obviously know where it is (i.e. you > > don't know what network you need to go to). What I don't get in the > > IRON approach is how you cope with the fact that a user simply types > > some name into an application. We can't hardly ask them which network > > they want to use to look up the name. The MIF approach, as much as it > > makes me airsick, does address that issue. > > > > A > > > > -- > > Andrew Sullivan > > ajs@anvilwalrusden.com > > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif From Fred.L.Templin@boeing.com Fri Dec 2 08:56:33 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 0E91A11E808B for ; Fri, 2 Dec 2011 08:56:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 ppMF+0WuamaH for ; Fri, 2 Dec 2011 08:56:32 -0800 (PST) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by ietfa.amsl.com (Postfix) with ESMTP id 546A411E807F for ; Fri, 2 Dec 2011 08:56:32 -0800 (PST) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by blv-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id pB2GuIdk011690 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 2 Dec 2011 08:56:19 -0800 (PST) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id pB2GuIHC009521; Fri, 2 Dec 2011 08:56:18 -0800 (PST) Received: from XCH-NWHT-03.nw.nos.boeing.com (xch-nwht-03.nw.nos.boeing.com [130.247.71.23]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id pB2GuH4T009511 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Fri, 2 Dec 2011 08:56:17 -0800 (PST) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-03.nw.nos.boeing.com ([130.247.71.23]) with mapi; Fri, 2 Dec 2011 08:56:17 -0800 From: "Templin, Fred L" To: Hui Deng , "'Andrew Sullivan'" Date: Fri, 2 Dec 2011 08:56:17 -0800 Thread-Topic: [mif] IRON as a multiple interface solution Thread-Index: Acyt+SVzR1PpkUYRTvCp3A+bmVJOzQCYBPHAAB446gAAD8Pa0A== Message-ID: References: <4EC5B720.8020605@gmail.com> <83A7D27A-9036-4252-AC94-3A89125C961B@nominum.com> <4EC63ECC.8010700@gmail.com> <20111119220355.GA893@shinkuro.com> <20111128181115.GC45293@shinkuro.com> <01da01ccb0d2$72f6f630$58e4e290$@com> In-Reply-To: <01da01ccb0d2$72f6f630$58e4e290$@com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mif@ietf.org" Subject: Re: [mif] IRON as a multiple interface solution 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, 02 Dec 2011 16:56:33 -0000 Hi Hui, I am saying that IRON defines a new interface type that would be one among possibly many interfaces of a mif node. The properties of this interface type include: - maintains stable network layer addresses even if ISP connections change - supports session continutity and fault tolerance as ISP connections change - avoids end user network renumbering when ISP connections change in case the mif node acts as a router There is more to it than just this, but the IRON interface is another mif node interface type and therefore needs to be taken under consideration, e.g., for interface selection, source address selection, etc. Thanks - Fred fred.l.templin@boeing.com > -----Original Message----- > From: Hui Deng [mailto:denghui@chinamobile.com]=20 > Sent: Friday, December 02, 2011 1:12 AM > To: Templin, Fred L; 'Andrew Sullivan' > Cc: mif@ietf.org > Subject: RE: [mif] IRON as a multiple interface solution >=20 > Hi Fred >=20 > You are saying current MIF document is compatible with IRON. > And current MIF document has already solved MIF's issues,=20 > so guess that IRON is proposing something else like generic=20 > internet access > which is out of MIF. >=20 > Regards, >=20 > -Hui >=20 > > -----Original Message----- > > From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On=20 > Behalf Of > > Templin, Fred L > > Sent: Friday, December 02, 2011 4:10 AM > > To: Andrew Sullivan > > Cc: mif@ietf.org > > Subject: Re: [mif] IRON as a multiple interface solution > >=20 > > Hi Andrew, > >=20 > > I took the time to go off and look at the mif wg > > documents. All of it is good work - and all of it > > is compatible with IRON. > >=20 > > The mif documents talk about two primary classes of > > interfaces: 1) ISP interfaces, and 2) VPN interfaces. > > IRON introduces a third class of interface which > > can be considered an "Internet interface". > >=20 > > While it is true that most ISP interfaces provide > > access to the Internet, ISP interfaces have volatile > > configuration information that can change, e.g., if > > the ISP point of connection changes. Conversely, the > > IRON Internet interface has non-volatile configuration > > information that remains the same even if the ISP > > connections change (e.g., if the node is mobile). > >=20 > > Since ISP interfaces may have access to private > > namespaces, those interfaces (along with their > > associated IP addresses) can be chosen for DNS > > resolution and for accessing services within the > > private namespace the same as described in the mif > > documents. Since the IRON Internet interface has > > a non-volatile configuration on the open Internet, > > however, it provides a stable handle for default > > communications with Internet-based correspondents. > >=20 > > Again, this is all very compatible with the mif > > work, and fits like a glove with what IRON expects. > >=20 > > Thanks - Fred > > fred.l.templin@boeing.com > >=20 > > > -----Original Message----- > > > From: Andrew Sullivan [mailto:ajs@anvilwalrusden.com] > > > Sent: Monday, November 28, 2011 10:11 AM > > > To: Templin, Fred L > > > Cc: Hui Deng; Andrew Sullivan; mif@ietf.org > > > Subject: Re: [mif] IRON as a multiple interface solution > > > > > > On Mon, Nov 28, 2011 at 09:22:45AM -0800, Templin, Fred L wrote: > > > > That said, IRON does not preclude the host from accessing > > > > services within the underlying ISP networks. To do so, > > > > however, the host would have to use its ISP-delegated > > > > address(es) and not the VSP-delegated address. > > > > > > > > Does this match your understanding? > > > > > > The central problem, however, is that if you are looking up the > > > address for a name, you don't obviously know where it is (i.e. you > > > don't know what network you need to go to). What I don't=20 > get in the > > > IRON approach is how you cope with the fact that a user=20 > simply types > > > some name into an application. We can't hardly ask them=20 > which network > > > they want to use to look up the name. The MIF approach,=20 > as much as it > > > makes me airsick, does address that issue. > > > > > > A > > > > > > -- > > > Andrew Sullivan > > > ajs@anvilwalrusden.com > > > > > _______________________________________________ > > mif mailing list > > mif@ietf.org > > https://www.ietf.org/mailman/listinfo/mif >=20 >=20 > = From hisuntao@gmail.com Fri Dec 2 09:18:24 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 A79851F0C36 for ; Fri, 2 Dec 2011 09:18:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 0SiDuM0XtDBR for ; Fri, 2 Dec 2011 09:18:23 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 31FB721F888A for ; Fri, 2 Dec 2011 09:18:23 -0800 (PST) Received: by vcbfy13 with SMTP id fy13so2814102vcb.31 for ; Fri, 02 Dec 2011 09:18:22 -0800 (PST) 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=Z/miS6V7C5/ljXm6QBYqw3QOrfXUNMFO1wfn2+KtnOM=; b=BEdThiT8uHz7HjkW9rGd9b+nbZvgRrnkahIQCiL3DPAa0lNO2D9Ajkpt20rPNrY6jj 7VPNzIGzaGg7YMGSmiv5QEzrwzGpNYK/mcC7+mLaivwMe7PeFeC7SzpVEdKacjw+RLvX uCWpGDEJ07NS+pnQrcx1z8AB2COM4Jm6BmePo= MIME-Version: 1.0 Received: by 10.52.31.166 with SMTP id b6mr4114833vdi.70.1322846302534; Fri, 02 Dec 2011 09:18:22 -0800 (PST) Received: by 10.220.194.133 with HTTP; Fri, 2 Dec 2011 09:18:22 -0800 (PST) In-Reply-To: References: <282BBE8A501E1F4DA9C775F964BB21FE3EB78C3C98@GRFMBX704BA020.griffon.local> <916CE6CF87173740BC8A2CE44309696204193417@008-AM1MPN1-053.mgdnok.nokia.com> <4EC512A2.2060509@gmail.com> <890A58CF-8EAD-4F92-9981-9B5AA07EBF00@nominum.com> <4EC63E26.70104@gmail.com> <86163A8F-8628-4F67-BE93-3747F95A2F52@nominum.com> <4ECB6EAE.2010701@gmail.com> <702C34B3-F6B7-4EFB-91D5-8538540534A1@nominum.com> <4ECBE3BE.5070501@gmail.com> <759E821F-B503-4C8D-A79B-5F9A68A3613F@nominum.com> Date: Sat, 3 Dec 2011 01:18:22 +0800 Message-ID: From: Tao Sun To: Lorenzo Colitti Content-Type: multipart/alternative; boundary=bcaec51a81e0f47cdd04b31f278b Cc: "mif@ietf.org" Subject: Re: [mif] Use cases for draft-ietf-mif-dhcpv6-route-option needed 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, 02 Dec 2011 17:18:24 -0000 --bcaec51a81e0f47cdd04b31f278b Content-Type: text/plain; charset=ISO-8859-1 On Fri, Dec 2, 2011 at 1:59 AM, Lorenzo Colitti wrote: > On Thu, Dec 1, 2011 at 09:07, Tao Sun wrote: > >> You can already do this today with RIOs, and I don't see why there >>> need to be two ways of doing the same thing. Adding a different method to >>> configure the same information is twice the code and more than twice the >>> complexity, since when you have two sources of information with different >>> semantics you need to figure out how to merge them, what happens if they >>> disagree, what to do if one is wrong, what to do if one expires, and so on. >>> >> We can not do this today. As 1 and 2 mentioned, both the deployed gateway >> and the 3GPP specification need to be updated to use RIO. >> > > What I meant is that a protocol and IETF perspective, you can do this > today using RIOs. So the protocol is there if 3GPP wants to use it. The > 3GPP specs need to be updated regardless of whether we decide to > standardize the proposed DHCPv6 route option or not. > We cannot only discuss the aplicability in IETF perspective. It is indeed significant change. The operator always needs to consider the huge number of legacy device and network elements. Change user's device and update network elements are really non-trival things. > > >> I agree we need to consider the disagree/confliction among policies. >> That is caused by the multiple interface feature. If you use RA for all the >> interfaces, the rule received may still conflict. Addressing the >> confliction is exactly what MIF WG shall consider IMHO. >> > > It is not caused by having multiple interfaces, it is caused by the fact > that there are potentially two sources of information. It can happen even > on only one interface, if the network on that interface supports both RAs > and DHCPv6 route. > For one interface in a single administrative domain, the network can pick one mechanism. Even if two ways are used simutaneously (I do not see this is necessary though), the administrator shall make the routing policy. Again, I still think regardless which mechanism is used. MIF shall address the issue of multiple sources of informaiton. > Also, in the mobile case I don't understand how you would use a >>> different gateway anyway. The mobile network is a point-to-point link, so >>> there's no way to distinguish multiple gateways. How would you use this? >>> >>> >> There are two types of scenarios. 1) A host is connected to the mobile >> network and WiFi at the same time, a typical scenario of MIF. 2) A mobile >> host connects to multiple APNs simultaneously, i.e., multiple PDN >> connection is established. The type 2) scenrio is also considered to be >> addressed in the OPIIS (Operator Policies for IP Interface Selection) >> work item in 3GPP. >> > > #1 can't be solved using either the DHCPv6 route option or RIOs because in > general the carrier network doesn't know the IPv6 address of the default > gateway on the wifi network. > I don't understand why one interface need to know the address of the default gateway on the other network. If neither DHCPv6 and RIO cannot solve this MIF scenario, what solution can solve it? > #2 can be fixed both using DHCPv6 route option and using RIOs. > Here you *can* do this using RIO, but limited in IETF protocal perspective. > > >> >>> ***Broadband network >>>> >>>> 1. WiFi network. Some WiFi hotspots provide local services. The >>>> route configuration on RG is needed to direct some traffic to local network >>>> while other traffic to the Internet. >>>> >>> >>> I don't understand why you need host changes to do this. Since the >>> hotspot router is a router, it can simply forward the packets the right way >>> by itself. >>> >>> >> You may refer to the Section of 3.4 of this draft or Section 5.2 of RFC >> 4191. >> > > I don't see how Section 3.4 of this draft ("applicability to routers") is > relevant to this discussion. Section 5.2 of RFC 5191 describes a different > scenario (two routers on the same link) than the one you suggested here > (one router on a given link). > Section 3.4 related with your previous question, the hotspot router is a multi-homing router which may need some specific route. > > >> 2. VPN network. When a user connect to enterprise VPN network, >>>> the routing of VPN traffic need to be configured. Due to the large number >>>> of such VPN network, we cannot assume all the VPN network only use RA. >>>> DHCPv6 provides another choice which may be preferred by the VPN network. >>>> >>> >>> The rationale here seems to be that "if we create a new option, some >>> networks might use it". That's certainly true, but it doesn't provide a >>> compelling reason why we need the option in the first place. >>> >> To us, its a compelling reason due to the network managment/operation, >> per-subscriber service, foresee burden of modification to existing gateway >> and specifications. >> > > Who is "us", and what is the use case? I don't see why the ones discussed > so far can't use RIOs. > Us means operators owns and manage both cellular network and WiFi netowrk. WiFi plays more and more important roles in mobile operator's network. --bcaec51a81e0f47cdd04b31f278b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Fri, Dec 2, 2011 at 1:59 AM, Lorenzo Colitti = <lorenzo@google.= com> wrote:
On Thu, Dec 1, 2011 at 09:07, Tao Sun &= lt;hisuntao@gmail.c= om> wrote:
You can already do this today with RIOs, and=A0I don't see why the= re need to be two ways of doing the same thing.=A0Adding a different method= to configure the same information is=A0twice the code and more than twice = the complexity, since when you have two sources of information with differe= nt semantics you need to figure out how to merge them, what happens if they= disagree, what to do if one is wrong, what to do if one expires, and so on= .
We can not do=A0this today. As 1 and 2 mentioned, both the deployed ga= teway and the 3GPP specification need to be updated to use RIO.
=

What I meant is that a protocol and IETF perspective, you can do this = today using RIOs. So the protocol is there if 3GPP wants to use it. The 3GP= P=A0specs need to be updated regardless of whether we decide to standardize= the proposed DHCPv6 route option or not.
We cannot only discuss the=A0aplicability in IETF perspective. It is i= ndeed significant change. The operator always needs to consider the huge nu= mber of legacy device and network elements. Change user's device and up= date network elements are really non-trival things.
=A0
I agree we need to consider the disagree/confliction among policies. T= hat is caused by the multiple interface feature. If you use RA for all the = interfaces, the rule received may still conflict. Addressing the conflictio= n is exactly what MIF WG shall consider IMHO.

It is not caused by having multiple interfaces,=A0it is caused by = the fact that there are potentially two sources of information. It can happ= en even on only one interface, if the network on that interface supports bo= th RAs and DHCPv6 route.
For one interface in a single administrative domain, the network can p= ick one mechanism. Even if two ways are used simutaneously (I do not see=A0= this is necessary though), the administrator shall make the routing policy.=
=A0
Again, I still think regardless which mechanism is used. MIF shall add= ress the issue of multiple sources of informaiton.
=A0
Also, in the mobile case I don't understand how you would use a di= fferent gateway anyway.=A0The mobile network is a point-to-point link, so t= here's no way to distinguish multiple gateways. How would you use this?=
=A0=A0
There are two types of scenarios. 1) A host is connected=A0to the=A0mo= bile network and WiFi at the same time, a typical scenario of MIF. 2) A mob= ile host connects to multiple APNs simultaneously, i.e., multiple PDN conne= ction is established.=A0The type=A02)=A0scenrio is also considered to be ad= dressed=A0in the OPIIS (Operator Policies for IP In= terface Selection) work item in 3GPP.

#1 can't be solved using either the DHCPv6 route option or RIOs be= cause in general the carrier network doesn't know the IPv6 address of t= he default gateway on the wifi network.
I don't understand why one interface need to know the address of t= he default gateway on the other network. If neither DHCPv6 and RIO cannot s= olve this MIF scenario, what solution can solve it?
=A0
#2 can be fixed both using DHCPv6 route option and using RIOs.
Here=A0you=A0*can* do this using RIO, but limited in IETF protocal per= spective.

=A0

<= font size=3D"3">***Broadband network

1.=A0=A0=A0=A0=A0=A0 WiFi network. Some WiFi hotspots provid= e local services. The route configuration on RG is needed to direct some tr= affic to local network while other traffic to the Internet.


I don't understand why you need host changes to do this. Since the= hotspot router is a router, it can simply forward the packets the right wa= y by itself.
=A0
You may refer to the=A0 Section of 3.4 of this draft or Section 5.2 of= RFC 4191.

I don't see how Section 3.4 of this draft ("applicability= to routers") is relevant to this discussion.=A0Section 5.2 of RFC 519= 1 describes a different scenario (two routers on the same link) than the on= e you suggested here (one router on a given link).
Section 3.4 related with your previous question, the hotspot router is= a multi-homing router which may need some specific route.
=A0

2.=A0=A0=A0=A0=A0=A0 VPN network. When a user connect to ent= erprise VPN network, the routing of VPN traffic need to be configured. Due = to the large number of such VPN network, we cannot assume all the VPN netwo= rk only use RA. DHCPv6 provides another choice which may be preferred by th= e VPN network.


The rationale here seems to be that "if we create a new option, s= ome networks might use it". That's certainly true, but it doesn= 9;t provide a compelling reason why we need the option in the first place.<= /div>
To us, its a compelling reason due to the network managment/operation,= per-subscriber service, foresee burden of modification to existing gateway= and specifications.

Who is "us", and what is the use case? I don't see why t= he ones discussed so far can't use RIOs.
Us means operators owns and manage both cellular network and WiFi neto= wrk. WiFi plays more and more important roles in mobile operator's netw= ork.

--bcaec51a81e0f47cdd04b31f278b-- From hisuntao@gmail.com Fri Dec 2 10:15: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 2E84D11E8080 for ; Fri, 2 Dec 2011 10:15:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[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 1rRheYRWQoK0 for ; Fri, 2 Dec 2011 10:15:38 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4271C1F0C36 for ; Fri, 2 Dec 2011 10:15:37 -0800 (PST) Received: by vcbfy13 with SMTP id fy13so2864149vcb.31 for ; Fri, 02 Dec 2011 10:15:36 -0800 (PST) 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=LZRwXxFuijjbdghd//ME6ZLoyWnPZyPsl9HKYUZwRkM=; b=NvTOMfdnFW6neetVJ6UiQjR0WyaQ7E6y+ynNZdW3BTveXRoEQNU7+Gekc3qvj3zItr kkCoozKQAX66EfymsdwXtYtR+wmntfR8tP9kEyYmSXVUjpmr8tpb8tKYKgoY7r7KDAb1 wsUwrZVe5E8Pxs00puEv4FaAKxfwh00IBcPGc= MIME-Version: 1.0 Received: by 10.220.213.135 with SMTP id gw7mr2086929vcb.54.1322849736319; Fri, 02 Dec 2011 10:15:36 -0800 (PST) Received: by 10.220.194.133 with HTTP; Fri, 2 Dec 2011 10:15:36 -0800 (PST) In-Reply-To: References: <282BBE8A501E1F4DA9C775F964BB21FE3EB78C3C98@GRFMBX704BA020.griffon.local> <916CE6CF87173740BC8A2CE44309696204193417@008-AM1MPN1-053.mgdnok.nokia.com> <4EC512A2.2060509@gmail.com> <890A58CF-8EAD-4F92-9981-9B5AA07EBF00@nominum.com> <4EC63E26.70104@gmail.com> <86163A8F-8628-4F67-BE93-3747F95A2F52@nominum.com> <4ECB6EAE.2010701@gmail.com> <702C34B3-F6B7-4EFB-91D5-8538540534A1@nominum.com> <4ECBE3BE.5070501@gmail.com> <759E821F-B503-4C8D-A79B-5F9A68A3613F@nominum.com> <4ED6A08D.9090703@gmail.com> Date: Sat, 3 Dec 2011 02:15:36 +0800 Message-ID: From: Tao Sun To: Lorenzo Colitti Content-Type: multipart/alternative; boundary=bcaec54ee8ee9fe0df04b31ff448 Cc: "mif@ietf.org" Subject: Re: [mif] Use cases for draft-ietf-mif-dhcpv6-route-option needed 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, 02 Dec 2011 18:15:39 -0000 --bcaec54ee8ee9fe0df04b31ff448 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Dec 2, 2011 at 2:06 AM, Lorenzo Colitti wrote: > On Thu, Dec 1, 2011 at 09:45, Tao Sun wrote: > >> >>> Actually, what decreases the implementation burden is not having the >>> option at all. The use cases I've heard so far for this option are all a >>> bit specious and I think they are outweighed by the harm that would be >>> caused if this option were to get into general use. >>> >> Form the discussion in this thread, the use cases exist in BBF and >> cellular network, apply to host and RG/CPE and are met by individual user >> and network operators. To me, they are not specious. >> > > I can see the BBF use case, but that seems to be a rather specific use > case and could be solved using a BBF-specific option. I can't see the > cellular use case, since the cellular network already uses RAs. > I have to repeat my previous words that cellular network only use RA to do SLAAC today. Further more, even SLAAC is not well supported by some vendor's network elment today. > > >> The reasoning goes something like this: >>> >>> 1. The option is defined. >>> 2. OS foo implements it. >>> 3. Some network, somewhere, decides that they're only going to use >>> DHCPv6 for routing, because they only support OS foo. >>> 4. Other OSes are forced to implement the option because if they don't, >>> they are at a disadvantage compared to OS foo >>> 5. Once all OSes implement it, some other network, somewhere else, >>> decides that they're only going to support DHCPv6 for routing because it's >>> easier and because it matches what they do in IPv4, so they turn off RAs. >>> >> You need not worry about turning off RAs. RA is mandated for mobile host >> to abtain /64 prefix in cellular network. While, for DHCPv6, you >> anyway need to switch on it IMHO. When you enable the tethering >> feature, the mobile host shall use DHCPv6 for prefix delegation. >> > > I'm not talking about mobile networks specifically here. I think this > particular event (turning off RAs) is more likely that to happen on a wifi > network or an enterprise network. > As I pointed out in my previous email, WiFi network is already part of mobile network. China Mobile deployed about more than one hundred of thousand hotspots (over 1 million WiFi AP). Users use the same smart phone to visit cellular network and WiFi network. > To me, the lack of functionality that will result if we take the path >>> of least resistance described above far outweighs the benefits of being >>> able to configure [default] routes and on-link prefixes on a per-host >>> basis. You can do this in lots of other ways, for example assigning the >>> hosts you want to treat differently to different VLANs. >>> >> Here we discuss host with multiple interface. I am not sure how VLAN can >> be used here. This also introduced the extra complexity. >> > > The DHCPv6 route option has nothing to do with multiple interfaces. It is > equally applicable to a use case where you have only one interface. > If you have only one interface, DHCPv6 route option is not necessary for configuring those specific routing informaiton. > > As regards VLANs: my point was that if you want different hosts to have > different gateways, you can put them on different VLANs and have different > RAs on each VLAN. You don't have to do it via DHCPv6. > > >> 2) Per user/host configuration makes DHCPv6 be used for the >>>> >> on-demand configuration. >>>> >>>> RA/RIO does not meet this requirement, which is a real requirement >>>> in networks with heterogeneous types of host. DHCPv6 does meet this >>>> requirement. >>>> >>> >>> You can use selective unicast router advertisements for this if you >>> want. There's no reason you can't look the RA properties in RADIUS. And of >>> course, you can put the separate hosts on separate VLANs (which is probably >>> the right thing to do in general). >>> >> >> If you use selective unicast RA for those on-demand subscribers, you are >> more likely using RA in a stateful way. The benefits of RA is lost. >> > > From the network point of view maybe. But not from the point of view of > the node that is receiving the RA. That node can still support / merge > multiple sources of information; it only needs to support one protocol (RA) > to configure routes and doesn't need the additional complexity that comes > from supporting two ways to configure the same thing; and so on. > Good you see the suffer of network using RA in this way. Hope you also see the complexity using VLAN on smart phones. --bcaec54ee8ee9fe0df04b31ff448 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Fri, Dec 2, 2011 at 2:06 AM, Lorenzo Colitti = <lorenzo@google.= com> wrote:
On Thu, Dec 1, 2011 at 09:45, Tao Sun &= lt;hisuntao@gmail.c= om> wrote:

Actually, what decreases the implementation burden is not having t= he option at all.=A0The use cases I've heard so far for this option are= all a bit specious and I think they are outweighed by the harm that would = be caused if this option were to get into general use.
Form the discussion in this thread, the use cases exist in=A0BBF and c= ellular network, apply to host and RG/CPE and are met by individual user an= d network operators. To me, they are not specious.

I can see the BBF use case, but that seems to be a rather specific use= case and could be solved using a BBF-specific option. I can't see the = cellular use case, since the cellular network already uses RAs.
I have to repeat my previous words that cellular network only use RA t= o do SLAAC today. Further more, even SLAAC is not well supported=A0by=A0som= e vendor's=A0network elment=A0today.
=A0
The reasoning goes something like this:

1. The option is defined.
2. OS foo implements it.
3. Some network, somewhere, decides that they're only going to use= DHCPv6 for routing, because they only support OS foo.
4. Other OSes are forced to implement the option because if they don&#= 39;t, they are at a disadvantage compared to OS foo
5. Once all OSes implement it, some other network, somewhere else, dec= ides that they're only going to support DHCPv6 for routing because it&#= 39;s easier and because it matches what they do in IPv4, so they turn off R= As.
You need not worry about turning off RAs. RA is mandated for mobile ho= st to abtain /64 prefix in cellular network. While, for DHCPv6, you anyway= =A0need to switch on it IMHO. When you enable the tethering feature,=A0the = mobile host shall use=A0DHCPv6 for prefix delegation.

I'm not talking about mobile networks specifically here. I think t= his particular event (turning off RAs) is more likely that to happen on a w= ifi network or an enterprise network.
As I pointed out in my previous email, WiFi network is already part of= mobile=A0network.=A0China Mobile deployed about more than one hundred of t= housand=A0hotspots (over 1 million WiFi AP). Users use the same smart phone= to visit cellular network and WiFi network.
=A0
To me, the lack of functionality that will result if we take the path = of least resistance described above far outweighs the benefits of being abl= e to configure [default] routes and on-link prefixes on a per-host basis. Y= ou can do this in lots of other ways, for example assigning the hosts you w= ant to treat differently to different VLANs.
Here we discuss host with multiple interface. I am not sure how VLAN c= an be used here. This also introduced the extra complexity.

The DHCPv6 route option has nothing to do with multiple interfaces. It= is equally applicable to a use case where you have only one interface.
If you have only one interface, DHCPv6 route option is not necessary f= or configuring=A0those specific routing informaiton.

As regards VLANs: my point was that if you want different hosts to hav= e different gateways, you can put them on different VLANs and have differen= t RAs on each VLAN. You don't have to do it via DHCPv6.

>> 2) Per user/host configuration makes DHCPv6 be used for the>> on-demand configuration.

RA/RIO does not meet this = requirement, which is a real requirement
in networks with heterogeneous = types of host. DHCPv6 does meet this
requirement.

You can use selective unicast router advertisements for this if you wa= nt. There's no reason you can't look the RA properties in RADIUS. A= nd of course, you can put the separate hosts on separate VLANs (which is pr= obably the right thing to do in general).
=A0
If you use selective unicast RA for those on-demand subscribers, you a= re more likely=A0using RA in a stateful way. The benefits of RA is lost.

From the network point of view maybe. But not from the point of view o= f the node that is receiving the RA. That node can still support / merge mu= ltiple sources of information; it only needs to support one protocol (RA) t= o configure routes and doesn't need the additional complexity that come= s from supporting two ways to configure the same thing; and so on.
Good you see the suffer of network using RA in this way. Hope you also= see the complexity using VLAN on smart phones.

--bcaec54ee8ee9fe0df04b31ff448-- From hisuntao@gmail.com Fri Dec 2 10:34:28 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 3E26121F8C00 for ; Fri, 2 Dec 2011 10:34:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[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 e5JAEmnNTJHL for ; Fri, 2 Dec 2011 10:34:27 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 36EBD21F8BF9 for ; Fri, 2 Dec 2011 10:34:27 -0800 (PST) Received: by vbbez10 with SMTP id ez10so2865898vbb.31 for ; Fri, 02 Dec 2011 10:34:26 -0800 (PST) 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=ojchzpovEiD/iPS+avrfgka0UElXmjMr57J1FzRSKio=; b=Hy7qN95DSGoU0Gfw/VOI0w1WOynvpEpAO8Z/U2HkmkA1/HNRa84eD5gRn0FY2BMKPe 8zd5LtAAcLJlp26xR18zhfY3SQeKdfpCmrpEPtFQXP6v01UL6BztrIH3SV9tcm+X2Uy5 qIiQL6E81nlp+M3xQG+tDkcZJrmlHOqqAexpM= MIME-Version: 1.0 Received: by 10.52.29.97 with SMTP id j1mr9975298vdh.87.1322850866653; Fri, 02 Dec 2011 10:34:26 -0800 (PST) Received: by 10.220.194.133 with HTTP; Fri, 2 Dec 2011 10:34:26 -0800 (PST) In-Reply-To: References: <282BBE8A501E1F4DA9C775F964BB21FE3EB78C3C98@GRFMBX704BA020.griffon.local> <916CE6CF87173740BC8A2CE44309696204193417@008-AM1MPN1-053.mgdnok.nokia.com> <4EC512A2.2060509@gmail.com> <890A58CF-8EAD-4F92-9981-9B5AA07EBF00@nominum.com> <4EC63E26.70104@gmail.com> <86163A8F-8628-4F67-BE93-3747F95A2F52@nominum.com> <4ECB6EAE.2010701@gmail.com> <702C34B3-F6B7-4EFB-91D5-8538540534A1@nominum.com> <4ECBE3BE.5070501@gmail.com> <759E821F-B503-4C8D-A79B-5F9A68A3613F@nominum.com> <7C1F8DA5-357F-4403-BE0D-E72D425B71C9@gmail.com> <4ED7CA1C.1080606@gmail.com> Date: Sat, 3 Dec 2011 02:34:26 +0800 Message-ID: From: Tao Sun To: Lorenzo Colitti Content-Type: multipart/alternative; boundary=20cf3079c0fcff69b404b3203791 Cc: mif@ietf.org Subject: Re: [mif] Use cases for draft-ietf-mif-dhcpv6-route-option needed 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, 02 Dec 2011 18:34:28 -0000 --20cf3079c0fcff69b404b3203791 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Dec 2, 2011 at 3:22 AM, Lorenzo Colitti wrote: > On Thu, Dec 1, 2011 at 10:40, Alexandru Petrescu < > alexandru.petrescu@gmail.com> wrote: > >> Le 01/12/2011 18:24, Tao Sun a =E9crit : >> >> Hi Jouni, Thanks for the clarification. That is ture GGSN/PGW is not >>> mandate to do relay. "May" instead of "shall" is used to describe >>> GGSN/PGW's action. The only mandate is to use RA to obtain /64 >>> prefix. >>> >> >> And that mandate is not sufficient when the UE is actually a Router >> ("mobile hotspot", "tethering"). For these cases, DHCPv6-PD is >> suggested by 3GPP specs. Thus, the 3GPP specs assume that a UE-Router >> (new term for this conversation) runs both RA _and_ DHCP. But 3GPP >> specs overlook the fact that an UE-Router would't use RA to >> auto-configure an address (stateless autoconf is only for Hosts). > > > That's not true - RFC 6204 says that an IPv6 CE router can use autoconf t= o > create an address. I think it's reasonable to say that if you were to > implement tethering using DHCPv6 PD, you would follow RFC 6204. > > >> Hence 3GPP specs could consider that _only_ DHCP should should be used >> by DHCPv6. In this sense, the above only mandate ("use RA to obtain >> /64 prefix") could be dropped altogether. >> > > See what I mean? We're already talking about not using RAs at all any > more, and we don't even have a DHCPv6 route option yet... > RA still must be used by the host to get the /64 prefix first and establish the connection towards the gateway. After that, DHCPv6 PD is used if shorter than /64 prefix is required. If you worry about the possibility of dropping the use of RA, the draft can be updated to clearly state that using DHCPv6 for route option shall not prevent using RA for SLAAC... somthing like that. I > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > > --20cf3079c0fcff69b404b3203791 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Fri, Dec 2, 2011 at 3:22 AM, Lorenzo Colitti = <lorenzo@google.= com> wrote:
On Thu, Dec 1, 2011 at 10:40, Alexandru Petrescu <alexandru.petrescu@gmail.com> wrote:
Le 01/12/2011 18:24, Tao Sun a = =E9crit :=20

Hi Jouni, Thanks for the clarifi= cation. That is ture GGSN/PGW is not
mandate to do relay. "May"= ; instead of "shall" is used to describe
GGSN/PGW's action. The only mandate is to use RA to obtain /64
prefi= x.

And that mandate is not sufficient when the UE= is actually a Router
("mobile hotspot", "tethering"= ). =A0For these cases, DHCPv6-PD is
suggested by 3GPP specs. =A0Thus, the 3GPP specs assume that a UE-Router(new term for this conversation) runs both RA _and_ DHCP. =A0But 3GPP
s= pecs overlook the fact that an UE-Router would't use RA to
auto-conf= igure an address (stateless autoconf is only for Hosts).

That's not true - RFC 6204 says that an IPv6 CE router can use aut= oconf to create an address. I think it's reasonable to say that if you = were to implement tethering using DHCPv6 PD, you would follow RFC 6204.
=A0
Hence=A03GPP specs could conside= r that _only_ DHCP should should be used by=A0DHCPv6. =A0In this sense, the= above only mandate ("use RA to obtain /64=A0prefix") could be dr= opped altogether.

See what I mean? We're already talking about not using RAs at all = any more, and we don't even have a DHCPv6 route option yet...
=
=A0
RA still must=A0be used=A0by the host to get the /64 prefix first and = establish the connection towards the gateway. After that, DHCPv6 PD is used= if shorter than /64 prefix is required.
If you worry about the possibility of dropping=A0the use of RA, the dr= aft can be updated to clearly state that using DHCPv6 for route option shal= l not prevent using RA for SLAAC... somthing like that.
=A0
I
________________________________= _______________
mif mailing list
mif@= ietf.org
htt= ps://www.ietf.org/mailman/listinfo/mif


--20cf3079c0fcff69b404b3203791-- From hisuntao@gmail.com Fri Dec 2 10:50:01 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 99C5711E80F1 for ; Fri, 2 Dec 2011 10:50:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[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 aQdYjPo038Qw for ; Fri, 2 Dec 2011 10:49:50 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id D623011E80B5 for ; Fri, 2 Dec 2011 10:49:49 -0800 (PST) Received: by vbbez10 with SMTP id ez10so2878601vbb.31 for ; Fri, 02 Dec 2011 10:49:49 -0800 (PST) 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=HjBHD37tk4h+5D6hd5U7Vy9bRxoVM1cEyQgoVYQh75Y=; b=sJ17P6VvyaieSHxXW1qe/kw6+GONn/kt95PepZLko8GMH26By/rnqzTBFN2HC9Qv6G R0nEqiUb1SJRYM24qX8YHNEt6Msvz3ZVdTi7C0hkj2qG+zv7a1GelZqvH7mmjSfeosXr B2FcyFY9Y1aRYKOaFJZnbd7UVQLjVI0fgxkvc= MIME-Version: 1.0 Received: by 10.52.31.166 with SMTP id b6mr4378241vdi.70.1322851789265; Fri, 02 Dec 2011 10:49:49 -0800 (PST) Received: by 10.220.194.133 with HTTP; Fri, 2 Dec 2011 10:49:49 -0800 (PST) In-Reply-To: <5AB3B2FC-8914-42AB-9173-8172D926462F@gmail.com> References: <282BBE8A501E1F4DA9C775F964BB21FE3EB78C3C98@GRFMBX704BA020.griffon.local> <916CE6CF87173740BC8A2CE44309696204193417@008-AM1MPN1-053.mgdnok.nokia.com> <4EC512A2.2060509@gmail.com> <890A58CF-8EAD-4F92-9981-9B5AA07EBF00@nominum.com> <4EC63E26.70104@gmail.com> <86163A8F-8628-4F67-BE93-3747F95A2F52@nominum.com> <4ECB6EAE.2010701@gmail.com> <702C34B3-F6B7-4EFB-91D5-8538540534A1@nominum.com> <4ECBE3BE.5070501@gmail.com> <759E821F-B503-4C8D-A79B-5F9A68A3613F@nominum.com> <4ED6A08D.9090703@gmail.com> <9ACC70F6-6D21-4981-A3CE-BA3469658F62@gmail.com> <4ED7F2C0.4040902@gmail.com> <5AB3B2FC-8914-42AB-9173-8172D926462F@gmail.com> Date: Sat, 3 Dec 2011 02:49:49 +0800 Message-ID: From: Tao Sun To: jouni korhonen Content-Type: multipart/alternative; boundary=bcaec51a81e0fd596d04b3206e1d Cc: "mif@ietf.org" Subject: Re: [mif] Use cases for draft-ietf-mif-dhcpv6-route-option needed 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, 02 Dec 2011 18:50:01 -0000 --bcaec51a81e0fd596d04b3206e1d Content-Type: text/plain; charset=ISO-8859-1 On Fri, Dec 2, 2011 at 2:53 PM, jouni korhonen wrote: > Hi, > > On Dec 1, 2011, at 11:33 PM, Brian E Carpenter wrote: > > > On 2011-12-02 09:17, jouni korhonen wrote: > >> On Nov 30, 2011, at 11:30 PM, Brian E Carpenter wrote: > >> > >> [snip] > >> > >> > >>>>> 3) The centralized relay architecture is a widely > >>>>> used way at present for IPv4 and it will also be used for IPv6. > >>> That's the wrong way to say it IMHO. There are sound reasons why > >>> operators want a centralised host management system with distributed > >>> relays. The fact that the solution for IPv4 is called DHCP doesn't > >>> imply that the best solution for IPv6 is called DHCPv6. However, until > >>> there is a well-defined central management system for prefix delegation > >>> and routing options via RA, it seems that DHCPv6 *is* the only > available > >> > >> Like AAA? That is used and will be used a lot for address & prefix > management, and can also be used for distributing per subscriber route > information. > > > > I stand corrected - the point is that AAA is centrally managed and tied > to > > subscriber info. RA is neither in any present implementation that I'm > aware > > of. It was designed thinking of completely unmanaged networks. > > Latest yesterday I tweaked with such implementation. It is quite common > feature e.g. in 3GPP defined networks that the per subscriber prefix for RA > comes off AAA. It has been there in specs for say 9 years and deployed at > least several years. Also the per subscriber delegated prefixes may come > from AAA.. like the rest of the end host configuration information. > > [Tao] Could you be more specific which spec you are referring to? Unfortunately, it is not ture that such implementation has "deployed at least several years". Few vandor implement their network elements with good support of RA, not mention of the per subscriber prefix from AAA or the RIO. The basic RA works in new network element on 4G PDN gateways in recent one year or so . > > > >>> solution. And then we loop back to point 1): it's better to have a > generic > >>> option than a bunch of competing vendor options. > >> > >> I would not say competing vendor but competing SDO options. > > > > Procedurally, as far as the IETF is concerned, they would be vendor > > options I think. But in any case they would amount to solving the same > > problem N times. See > > > http://www.tuv.com/media/germany/50_trainingandconsulting/pdf/patente/Circular_transportation_facilitation_device.pdf > > great stuff ;-) > > - Jouni > > > > > > Brian > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > --bcaec51a81e0fd596d04b3206e1d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Fri, Dec 2, 2011 at 2:53 PM, jouni korhonen <= span dir=3D"ltr"><jouni.nospam= @gmail.com> wrote:
Hi,

On Dec 1, 2011, at 11:33 PM, Brian E Carpenter wrote:=

> On 2011-12-02 09:17, jouni korhonen wrote:
>> On Nov = 30, 2011, at 11:30 PM, Brian E Carpenter wrote:
>>
>> [sn= ip]
>>
>>
>>>>> 3) The centralized relay archi= tecture is a widely
>>>>> used way at present for IPv4 an= d it will also be used for IPv6.
>>> That's the wrong way t= o say it IMHO. There are sound reasons why
>>> operators want a centralised host management system with distr= ibuted
>>> relays. The fact that the solution for IPv4 is calle= d DHCP doesn't
>>> imply that the best solution for IPv6 is= called DHCPv6. However, until
>>> there is a well-defined central management system for prefix d= elegation
>>> and routing options via RA, it seems that DHCPv6 = *is* the only available
>>
>> Like AAA? That is used and = will be used a lot for address & prefix management, and can also be use= d for distributing per subscriber route information.
>
> I stand corrected - the point is that AAA is centrally managed= and tied to
> subscriber info. RA is neither in any present implemen= tation that I'm aware
> of. It was designed thinking of completel= y unmanaged networks.

Latest yesterday I tweaked with such implementation. It is quite = common feature e.g. in 3GPP defined networks that the per subscriber prefix= for RA comes off AAA. It has been there in specs for say 9 years and deplo= yed at least several years. Also the per subscriber delegated prefixes may = come from AAA.. like the rest of the end host configuration information.
=A0
[Tao] Could you be more specific which spec you are referring to?=A0 U= nfortunately, it is not ture that such implementation has "deployed at= least several years". Few vandor implement their network elements wit= h good support of RA, not mention of the=A0per subscriber prefix from AAA o= r the RIO. The=A0basic RA=A0works in=A0new network=A0element on=A04G PDN ga= teways in recent one year or so=A0.=A0
=A0
>
>>> solution. And then we loop back to p= oint 1): it's better to have a generic
>>> option than a bu= nch of competing vendor options.
>>
>> I would not say co= mpeting vendor but competing SDO options.
>
> Procedurally, as far as the IETF is concerned, they would be v= endor
> options I think. But in any case they would amount to solving= the same
> problem N times. See
> http://www.tuv.com/media/germa= ny/50_trainingandconsulting/pdf/patente/Circular_transportation_facilitatio= n_device.pdf

great stuff ;-)

- Jouni


>
> =A0Brian

____________________= ___________________________
mif mailing list
mif@ietf.org
https://www.ietf.org/mailman/listinfo/mif

--bcaec51a81e0fd596d04b3206e1d-- From lorenzo@google.com Fri Dec 2 11:06:56 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 7056221F8C0F for ; Fri, 2 Dec 2011 11:06:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.882 X-Spam-Level: X-Spam-Status: No, score=-102.882 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 6P0oVc37I--6 for ; Fri, 2 Dec 2011 11:06:56 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id D98F621F8C08 for ; Fri, 2 Dec 2011 11:06:55 -0800 (PST) Received: by ywm13 with SMTP id 13so3687791ywm.31 for ; Fri, 02 Dec 2011 11:06:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=2VdZxJPfuKwM/aeGf694+0dg7PiBhq+xCMzJ6OCiErQ=; b=xEKDnsUlGKyK9OTwL/5XLOywnkBFmwBiVY7TBJ9xQS8Fxtl3X9FYLU0T0zU0jA2ayM fqqRtGupqd83X16UJ4YQ== Received: by 10.236.128.138 with SMTP id f10mr21794297yhi.2.1322852814460; Fri, 02 Dec 2011 11:06:54 -0800 (PST) Received: by 10.236.128.138 with SMTP id f10mr21794271yhi.2.1322852814282; Fri, 02 Dec 2011 11:06:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.150.202.14 with HTTP; Fri, 2 Dec 2011 11:06:33 -0800 (PST) In-Reply-To: References: <282BBE8A501E1F4DA9C775F964BB21FE3EB78C3C98@GRFMBX704BA020.griffon.local> <916CE6CF87173740BC8A2CE44309696204193417@008-AM1MPN1-053.mgdnok.nokia.com> <4EC512A2.2060509@gmail.com> <890A58CF-8EAD-4F92-9981-9B5AA07EBF00@nominum.com> <4EC63E26.70104@gmail.com> <86163A8F-8628-4F67-BE93-3747F95A2F52@nominum.com> <4ECB6EAE.2010701@gmail.com> <702C34B3-F6B7-4EFB-91D5-8538540534A1@nominum.com> <4ECBE3BE.5070501@gmail.com> <759E821F-B503-4C8D-A79B-5F9A68A3613F@nominum.com> <4ED6A08D.9090703@gmail.com> <9ACC70F6-6D21-4981-A3CE-BA3469658F62@gmail.com> <4ED7F2C0.4040902@gmail.com> <4ED7F84E.9080906@gmail.com> From: Lorenzo Colitti Date: Fri, 2 Dec 2011 11:06:33 -0800 Message-ID: To: Zhen Cao Content-Type: multipart/alternative; boundary=20cf3005dd9015e0b304b320acc9 X-System-Of-Record: true Cc: "mif@ietf.org" Subject: Re: [mif] Use cases for draft-ietf-mif-dhcpv6-route-option needed 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, 02 Dec 2011 19:06:56 -0000 --20cf3005dd9015e0b304b320acc9 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Dec 2, 2011 at 00:39, Zhen Cao wrote: > For per-user configuration, the situation is that users are dynamic > and I do not see how the VLAN can be configured according to their > different requirements. If you use the extended information in the > VLAN setup and use selective unicast RA in 3GPP case, I think that > already reaches (and actually more complicated than) the threshold for > doing it using DHCPv6. > I'm not talking about VLANs for the 3GPP case. In the 3GPP case you have a bunch of point to point interfaces (tunnels / PDP contexts / PDNs; one or more per user) that each have their own network segment (a /64). Per-user configuration is achieved simply by saying "the user on tunnel X gets an RA with prefix Y". This is how IPv6 on mobile networks works today. If you want more specific routes, you can easily include those in the RA, because as Jouni says, this is tied into AAA already. --20cf3005dd9015e0b304b320acc9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Dec 2, 2011 at 00:39, Zhen Cao <zehn.c= ao@gmail.com> wrote:
For per-user configuration, the situation is that users are dynamic and I do not see how the VLAN can be configured according to their
different requirements. If you use the extended information in the
VLAN setup and use selective unicast RA in 3GPP case, I think that
already reaches (and actually more complicated than) the threshold for
doing it using DHCPv6.

I'm not talking about VLANs for the 3GPP ca= se. In the 3GPP case you have a bunch of point to point interfaces (tunnels= / PDP contexts / PDNs; one or more per user) that each have their own netw= ork segment (a /64). Per-user configuration is achieved simply by saying &q= uot;the user on tunnel X gets an RA with prefix Y".=A0This is how IPv6= on mobile networks works today.

If you want more specific routes, you can easily includ= e those in the RA, because as Jouni says, this is tied into AAA already. --20cf3005dd9015e0b304b320acc9-- From lorenzo@google.com Fri Dec 2 11:19:01 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 8B3261F0C72 for ; Fri, 2 Dec 2011 11:19:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.885 X-Spam-Level: X-Spam-Status: No, score=-102.885 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 C0Kkkt7lofyL for ; Fri, 2 Dec 2011 11:19:00 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8F1D51F0C6D for ; Fri, 2 Dec 2011 11:19:00 -0800 (PST) Received: by yenl9 with SMTP id l9so2431737yen.31 for ; Fri, 02 Dec 2011 11:18:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=g+ahn56SBfqQ9T/9CLS8680BDywALZt7kHNXXzawnMk=; b=l5KKUKAPlZbR79S1AoW668m9qoJx50wPVkKaUg07hGPoku2/chPPFzt6BUnTljA9XE VoDETBVUBTxBeNkKozfQ== Received: by 10.236.75.167 with SMTP id z27mr21357680yhd.53.1322853532506; Fri, 02 Dec 2011 11:18:52 -0800 (PST) Received: by 10.236.75.167 with SMTP id z27mr21357661yhd.53.1322853532325; Fri, 02 Dec 2011 11:18:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.150.202.14 with HTTP; Fri, 2 Dec 2011 11:18:31 -0800 (PST) In-Reply-To: References: <282BBE8A501E1F4DA9C775F964BB21FE3EB78C3C98@GRFMBX704BA020.griffon.local> <916CE6CF87173740BC8A2CE44309696204193417@008-AM1MPN1-053.mgdnok.nokia.com> <4EC512A2.2060509@gmail.com> <890A58CF-8EAD-4F92-9981-9B5AA07EBF00@nominum.com> <4EC63E26.70104@gmail.com> <86163A8F-8628-4F67-BE93-3747F95A2F52@nominum.com> <4ECB6EAE.2010701@gmail.com> <702C34B3-F6B7-4EFB-91D5-8538540534A1@nominum.com> <4ECBE3BE.5070501@gmail.com> <759E821F-B503-4C8D-A79B-5F9A68A3613F@nominum.com> From: Lorenzo Colitti Date: Fri, 2 Dec 2011 11:18:31 -0800 Message-ID: To: Tao Sun Content-Type: multipart/alternative; boundary=20cf3005dde6e258a304b320d635 X-System-Of-Record: true Cc: "mif@ietf.org" Subject: Re: [mif] Use cases for draft-ietf-mif-dhcpv6-route-option needed 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, 02 Dec 2011 19:19:01 -0000 --20cf3005dde6e258a304b320d635 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Dec 2, 2011 at 09:18, Tao Sun wrote: > What I meant is that a protocol and IETF perspective, you can do this >> today using RIOs. So the protocol is there if 3GPP wants to use it. The >> 3GPP specs need to be updated regardless of whether we decide to >> standardize the proposed DHCPv6 route option or not. >> > We cannot only discuss the aplicability in IETF perspective. It is indeed > significant change. The operator always needs to consider the huge number > of legacy device and network elements. Change user's device and update > network elements are really non-trival things. > Of course. But since the specs need to be updated anyway, and implementations have to be updated anyway, the fact that changing existing implementations is a lot of work is not an argument in support of either RIO or DHCPv6 route: both require work to be done. RIO has the advantage that less work needs to be done, because the protocol and some implementations exist already. I know that on Android it would be much easier to implement RIO than a DHCPv6 route option. > Again, I still think regardless which mechanism is used. MIF shall >>> address the issue of multiple sources of informaiton. >>> >> I think MIF should deal with the issue of how to make things work using multiple interfaces. Making things work in two different ways on one interface is orthogonal. > There are two types of scenarios. 1) A host is connected to the mobile >>> network and WiFi at the same time, a typical scenario of MIF. 2) A mobile >>> host connects to multiple APNs simultaneously, i.e., multiple PDN >>> connection is established. The type 2) scenrio is also considered to be >>> addressed in the OPIIS (Operator Policies for IP Interface Selection) >>> work item in 3GPP. >>> >> >> #1 can't be solved using either the DHCPv6 route option or RIOs because >> in general the carrier network doesn't know the IPv6 address of the default >> gateway on the wifi network. >> > I don't understand why one interface need to know the address of the > default gateway on the other network. If neither DHCPv6 and RIO cannot > solve this MIF scenario, what solution can solve it? > The default gateway address on the other interface is needed if you want offload traffic to the other interface. That's what I thought you meant. If all you want to do is say "this carrier walled garden is reachable through the carrier interface, and the rest of the interface is over wifi", then you can do that using either RIOs or DHCPv6 route option. > I don't see how Section 3.4 of this draft ("applicability to routers") >>>> is relevant to this discussion. Section 5.2 of RFC 5191 describes a >>>> different scenario (two routers on the same link) than the one you >>>> suggested here (one router on a given link). >>>> >>> Section 3.4 related with your previous question, the hotspot router is > a multi-homing router which may need some specific route. > Sure, but that specific route can be given to that router in many ways (static configuration, RIO, routing protocol). We don't have to define a new DHCPv6 route option to do that. > To us, its a compelling reason due to the network managment/operation, >>>> per-subscriber service, foresee burden of modification to existing gateway >>>> and specifications. >>>> >>> >> Who is "us", and what is the use case? I don't see why the ones discussed >> so far can't use RIOs. >> > Us means operators owns and manage both cellular network and WiFi netowrk. > WiFi plays more and more important roles in mobile operator's network. > Then please explain the use case in more detail, and how you would use the proposed DHCPv6 route option to solve the use case. I think you'll find that what you're trying to do can be done today (from a protocol perspective) using RIOs. --20cf3005dde6e258a304b320d635 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Dec 2, 2011 at 09:18, Tao Sun <hisuntao@gmail.com&g= t; wrote:
What I meant is that a protoco= l and IETF perspective, you can do this today using RIOs. So the protocol i= s there if 3GPP wants to use it. The 3GPP=A0specs need to be updated regard= less of whether we decide to standardize the proposed DHCPv6 route option o= r not.
We cannot only discuss the=A0aplicability in IETF perspective. I= t is indeed significant change. The operator always needs to consider the h= uge number of legacy device and network elements. Change user's device = and update network elements are really non-trival things.

Of course. But since the specs need = to be updated anyway, and implementations have to be updated anyway, the fa= ct that changing existing implementations is a lot of work is not an argume= nt in support of either RIO or DHCPv6 route: both require work to be done. = RIO has the advantage that less work needs to be done, because the protocol= and some implementations exist already. I know that on Android it would be= much easier to implement RIO than a DHCPv6 route option.
=A0
Again, I still think regardless which mechanism is used. MIF shall add= ress the issue of multiple sources of informaiton.
=

I think MIF should deal with the issue of how to make things work using mul= tiple interfaces. Making things work in two different ways on one interface= is orthogonal.
=A0
There are two types of scenarios. 1) A host is connected=A0to the=A0mo= bile network and WiFi at the same time, a typical scenario of MIF. 2) A mob= ile host connects to multiple APNs simultaneously, i.e., multiple PDN conne= ction is established.=A0The type=A02)=A0scenrio is also considered to be ad= dressed=A0in the OPIIS (Operator Policies for IP In= terface Selection) work item in 3GPP.

#1 can't be solved using either the DHCPv6 route option or RIOs be= cause in general the carrier network doesn't know the IPv6 address of t= he default gateway on the wifi network.
I don't understand why one interface need to know the addres= s of the default gateway on the other network. If neither DHCPv6 and RIO ca= nnot solve this MIF scenario, what solution can solve it?

The default gateway address on the other interface is n= eeded if you want offload traffic to the other interface. That's what I= thought you meant.

If all you want to do is say &= quot;this carrier walled garden is reachable through the carrier interface,= and the rest of the interface is over wifi", then you can do that usi= ng either RIOs or DHCPv6 route option.
=A0
I don't see how Section 3.4 of this dra= ft ("applicability to routers") is relevant to this discussion.= =A0Section 5.2 of RFC 5191 describes a different scenario (two routers on t= he same link) than the one you suggested here (one router on a given link).=
Section 3.4 related with your previous question, the hotspot rou= ter is a multi-homing router which may need some specific route.

Sure, but that specific route can be give= n to that router in many ways (static configuration, RIO, routing protocol)= . We don't have to define a new DHCPv6 route option to do that.

=A0
To us, its a compelling reason due to the n= etwork managment/operation, per-subscriber service, foresee burden of modif= ication to existing gateway and specifications.

Who is "us", and what is the use case? I don't see why t= he ones discussed so far can't use RIOs.
Us means operators owns and manage both cellular network and WiF= i netowrk. WiFi plays more and more important roles in mobile operator'= s network.

Then please explain = the use case in more detail, and how you would use the proposed DHCPv6 rout= e option to solve the use case. I think you'll find that what you'r= e trying to do can be done today (from a protocol perspective) using RIOs.<= /div>
--20cf3005dde6e258a304b320d635-- From lorenzo@google.com Fri Dec 2 11:21:31 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 9567C21F8C9C for ; Fri, 2 Dec 2011 11:21:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.888 X-Spam-Level: X-Spam-Status: No, score=-102.888 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 c-uVbxjhxv7C for ; Fri, 2 Dec 2011 11:21:31 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id CAE0721F8C96 for ; Fri, 2 Dec 2011 11:21:30 -0800 (PST) Received: by yenl9 with SMTP id l9so2434156yen.31 for ; Fri, 02 Dec 2011 11:21:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=lC8tagtPVAtS63RalTZYem6qVDB8t5fblHxfyLdqj7E=; b=C5UW6UbQeyPjlFrQwoITYdwVGXyo7dfbUfi7yoE2D60yk+f5ytoUg5KQhuLz2Kluw4 nTbyel4O8Wg6tj0UBB2w== Received: by 10.236.183.52 with SMTP id p40mr21138559yhm.19.1322853690435; Fri, 02 Dec 2011 11:21:30 -0800 (PST) Received: by 10.236.183.52 with SMTP id p40mr21138533yhm.19.1322853690291; Fri, 02 Dec 2011 11:21:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.150.202.14 with HTTP; Fri, 2 Dec 2011 11:21:09 -0800 (PST) In-Reply-To: References: <282BBE8A501E1F4DA9C775F964BB21FE3EB78C3C98@GRFMBX704BA020.griffon.local> <916CE6CF87173740BC8A2CE44309696204193417@008-AM1MPN1-053.mgdnok.nokia.com> <4EC512A2.2060509@gmail.com> <890A58CF-8EAD-4F92-9981-9B5AA07EBF00@nominum.com> <4EC63E26.70104@gmail.com> <86163A8F-8628-4F67-BE93-3747F95A2F52@nominum.com> <4ECB6EAE.2010701@gmail.com> <702C34B3-F6B7-4EFB-91D5-8538540534A1@nominum.com> <4ECBE3BE.5070501@gmail.com> <759E821F-B503-4C8D-A79B-5F9A68A3613F@nominum.com> <4ED6A08D.9090703@gmail.com> From: Lorenzo Colitti Date: Fri, 2 Dec 2011 11:21:09 -0800 Message-ID: To: Tao Sun Content-Type: multipart/alternative; boundary=bcaec52c5ea94cb7f904b320e00e X-System-Of-Record: true Cc: "mif@ietf.org" Subject: Re: [mif] Use cases for draft-ietf-mif-dhcpv6-route-option needed 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, 02 Dec 2011 19:21:31 -0000 --bcaec52c5ea94cb7f904b320e00e Content-Type: text/plain; charset=ISO-8859-1 On Fri, Dec 2, 2011 at 10:15, Tao Sun wrote: > I'm not talking about mobile networks specifically here. I think this >> particular event (turning off RAs) is more likely that to happen on a wifi >> network or an enterprise network. >> > As I pointed out in my previous email, WiFi network is already part of > mobile network. China Mobile deployed about more than one hundred of > thousand hotspots (over 1 million WiFi AP). Users use the same smart phone > to visit cellular network and WiFi network. > Ok, so then let's take a look at that use case and see why it requires a DHCPv6 route option to be defined. I suspect that you can do what you want using RIO. --bcaec52c5ea94cb7f904b320e00e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Dec 2, 2011 at 10:15, Tao Sun <hisuntao@gmail.com&g= t; wrote:
I'm not talking about mobile ne= tworks specifically here. I think this particular event (turning off RAs) i= s more likely that to happen on a wifi network or an enterprise network.
As I pointed out in my previous email, WiFi network is already p= art of mobile=A0network.=A0China Mobile deployed about more than one hundre= d of thousand=A0hotspots (over 1 million WiFi AP). Users use the same smart= phone to visit cellular network and WiFi network.

Ok, so then let's take a look at= that use case and see why it requires a DHCPv6 route option to be defined.= I suspect that you can do what you want using RIO.
--bcaec52c5ea94cb7f904b320e00e-- From jouni.nospam@gmail.com Fri Dec 2 13:55:28 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 B33C511E8133 for ; Fri, 2 Dec 2011 13:55:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 o9v7y+mqmQaY for ; Fri, 2 Dec 2011 13:55:27 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0671011E812C for ; Fri, 2 Dec 2011 13:55:26 -0800 (PST) Received: by lagw12 with SMTP id w12so70147lag.31 for ; Fri, 02 Dec 2011 13:55:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=QHVmzciKGrJKzVs9KSv+tv23My5bUjWOqRfAmLVyW0g=; b=W55/f4JnWh7nsSIru+1aAtfD7zvEhEtfWYbzLFI1dF8n9i6Be23woiQ+q6MBz/Dqks 61EInafBboMPzAzqoCJGG5O69hJx4j1Uk93V2UQjXdu5Xz8S85QYaSB4j6qGNhh+9dqV xNF+8FYR/M+Xci5FGXU7QGFM5sxMDifLaXxYw= Received: by 10.152.134.77 with SMTP id pi13mr71718lab.21.1322862925986; Fri, 02 Dec 2011 13:55:25 -0800 (PST) Received: from [188.117.15.109] ([188.117.15.109]) by mx.google.com with ESMTPS id op2sm9773145lab.6.2011.12.02.13.55.23 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 02 Dec 2011 13:55:24 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Jouni In-Reply-To: Date: Fri, 2 Dec 2011 23:55:22 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <282BBE8A501E1F4DA9C775F964BB21FE3EB78C3C98@GRFMBX704BA020.griffon.local> <916CE6CF87173740BC8A2CE44309696204193417@008-AM1MPN1-053.mgdnok.nokia.com> <4EC512A2.2060509@gmail.com> <890A58CF-8EAD-4F92-9981-9B5AA07EBF00@nominum.com> <4EC63E26.70104@gmail.com> <86163A8F-8628-4F67-BE93-3747F95A2F52@nominum.com> <4ECB6EAE.2010701@gmail.com> <702C34B3-F6B7-4EFB-91D5-8538540534A1@nominum.com> <4ECBE3BE.5070501@gmail.com> <759E821F-B503-4C8D-A79B-5F9A68A3613F@nominum.com> <4ED6A08D.9090703@gmail.com> <9ACC70F6-6D21-4981-A3CE-BA3469658F62@gmail.com> <4ED7F2C0.4040902@gmail.com> <5AB3B2FC-8914-42AB-9173-8172D926462F@gmail.com> To: Tao Sun X-Mailer: Apple Mail (2.1251.1) Cc: "mif@ietf.org" Subject: Re: [mif] Use cases for draft-ietf-mif-dhcpv6-route-option needed 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, 02 Dec 2011 21:55:28 -0000 On Dec 2, 2011, at 8:49 PM, Tao Sun wrote: > Latest yesterday I tweaked with such implementation. It is quite = common feature e.g. in 3GPP defined networks that the per subscriber = prefix for RA comes off AAA. It has been there in specs for say 9 years = and deployed at least several years. Also the per subscriber delegated = prefixes may come from AAA.. like the rest of the end host configuration = information. > =20 > [Tao] Could you be more specific which spec you are referring to? = Unfortunately, it is not ture that such implementation has TS29.061.. you can trace it back about ~9 for RADIUS interface to = provide prefix for a RA. - Jouni > "deployed at least several years". Few vandor implement their network = elements with good support of RA, not mention of the per > subscriber prefix from AAA or the RIO. The basic RA works in new = network element on 4G PDN gateways in recent one year or so .=20 From brian.e.carpenter@gmail.com Fri Dec 2 14:15:21 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 820F311E80BF for ; Fri, 2 Dec 2011 14:15:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.566 X-Spam-Level: X-Spam-Status: No, score=-103.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, 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 sizwWnrzHd7d for ; Fri, 2 Dec 2011 14:15:21 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id C103211E8083 for ; Fri, 2 Dec 2011 14:15:20 -0800 (PST) Received: by faap14 with SMTP id p14so2877140faa.31 for ; Fri, 02 Dec 2011 14:15:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=nt34T3Jni+Car5uEJxXKrE9iWyaxYMw77cgVdDGzFqs=; b=NLrNDo0oiWAMGDx5NrC9BheK9Lud1TVQk37Yzfa2pOwOnWQvAdpDJX11n7/+a1Iz0+ p+ZQ34DwXFZjgxo7Sr3dGknxOUiTcO4G7vXbHLkIImbu/blS/MR7O7LTXdnwssomSmLV 6iyRGFmZWA379tamCcpR1TE/q2kPGQAOtQung= Received: by 10.180.105.3 with SMTP id gi3mr187191wib.36.1322864119886; Fri, 02 Dec 2011 14:15:19 -0800 (PST) Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id m25sm12393697wbp.6.2011.12.02.14.15.16 (version=SSLv3 cipher=OTHER); Fri, 02 Dec 2011 14:15:19 -0800 (PST) Message-ID: <4ED94DED.5070108@gmail.com> Date: Sat, 03 Dec 2011 11:15:09 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Jouni References: <282BBE8A501E1F4DA9C775F964BB21FE3EB78C3C98@GRFMBX704BA020.griffon.local> <916CE6CF87173740BC8A2CE44309696204193417@008-AM1MPN1-053.mgdnok.nokia.com> <4EC512A2.2060509@gmail.com> <890A58CF-8EAD-4F92-9981-9B5AA07EBF00@nominum.com> <4EC63E26.70104@gmail.com> <86163A8F-8628-4F67-BE93-3747F95A2F52@nominum.com> <4ECB6EAE.2010701@gmail.com> <702C34B3-F6B7-4EFB-91D5-8538540534A1@nominum.com> <4ECBE3BE.5070501@gmail.com> <759E821F-B503-4C8D-A79B-5F9A68A3613F@nominum.com> <4ED6A08D.9090703@gmail.com> <9ACC70F6-6D21-4981-A3CE-BA3469658F62@gmail.com> <4ED7F2C0.4040902@gmail.com> <5AB3B2FC-8914-42AB-9173-8172D926462F@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "mif@ietf.org" Subject: Re: [mif] Use cases for draft-ietf-mif-dhcpv6-route-option needed 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, 02 Dec 2011 22:15:21 -0000 Where can I find TS29.061? Brian On 2011-12-03 10:55, Jouni wrote: > On Dec 2, 2011, at 8:49 PM, Tao Sun wrote: > >> Latest yesterday I tweaked with such implementation. It is quite common feature e.g. in 3GPP defined networks that the per subscriber prefix for RA comes off AAA. It has been there in specs for say 9 years and deployed at least several years. Also the per subscriber delegated prefixes may come from AAA.. like the rest of the end host configuration information. >> >> [Tao] Could you be more specific which spec you are referring to? Unfortunately, it is not ture that such implementation has > > TS29.061.. you can trace it back about ~9 for RADIUS interface to provide prefix for a RA. > > - Jouni > > >> "deployed at least several years". Few vandor implement their network elements with good support of RA, not mention of the per >> subscriber prefix from AAA or the RIO. The basic RA works in new network element on 4G PDN gateways in recent one year or so . > > > From lorenzo@google.com Fri Dec 2 14:23:54 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 F1C8221F8C4E for ; Fri, 2 Dec 2011 14:23:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.895 X-Spam-Level: X-Spam-Status: No, score=-102.895 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 UQHyhSYGeMDN for ; Fri, 2 Dec 2011 14:23:53 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0353021F8C48 for ; Fri, 2 Dec 2011 14:23:52 -0800 (PST) Received: by iaek3 with SMTP id k3so2607516iae.31 for ; Fri, 02 Dec 2011 14:23:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=s+3K2F6II9mN8RU87ZmvzIX+GLHafQmJZA7jeW8WlAY=; b=aD+MhL/gHKJCoJk4Q2o1LD3J0sZ3wfKx2QguseJ3J42xk02ySsiIa7zXyxWNC9arLD MtJiIyMihzAnJzBkoFeQ== Received: by 10.231.0.221 with SMTP id 29mr57991ibc.17.1322864632472; Fri, 02 Dec 2011 14:23:52 -0800 (PST) Received: by 10.231.0.221 with SMTP id 29mr57983ibc.17.1322864632305; Fri, 02 Dec 2011 14:23:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.122.218 with HTTP; Fri, 2 Dec 2011 14:23:31 -0800 (PST) In-Reply-To: <4ED94DED.5070108@gmail.com> References: <282BBE8A501E1F4DA9C775F964BB21FE3EB78C3C98@GRFMBX704BA020.griffon.local> <916CE6CF87173740BC8A2CE44309696204193417@008-AM1MPN1-053.mgdnok.nokia.com> <4EC512A2.2060509@gmail.com> <890A58CF-8EAD-4F92-9981-9B5AA07EBF00@nominum.com> <4EC63E26.70104@gmail.com> <86163A8F-8628-4F67-BE93-3747F95A2F52@nominum.com> <4ECB6EAE.2010701@gmail.com> <702C34B3-F6B7-4EFB-91D5-8538540534A1@nominum.com> <4ECBE3BE.5070501@gmail.com> <759E821F-B503-4C8D-A79B-5F9A68A3613F@nominum.com> <4ED6A08D.9090703@gmail.com> <9ACC70F6-6D21-4981-A3CE-BA3469658F62@gmail.com> <4ED7F2C0.4040902@gmail.com> <5AB3B2FC-8914-42AB-9173-8172D926462F@gmail.com> <4ED94DED.5070108@gmail.com> From: Lorenzo Colitti Date: Fri, 2 Dec 2011 14:23:31 -0800 Message-ID: To: Brian E Carpenter Content-Type: multipart/alternative; boundary=00151773d3d27e974d04b3236cf2 X-System-Of-Record: true Cc: "mif@ietf.org" Subject: Re: [mif] Use cases for draft-ietf-mif-dhcpv6-route-option needed 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, 02 Dec 2011 22:23:54 -0000 --00151773d3d27e974d04b3236cf2 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Dec 2, 2011 at 14:15, Brian E Carpenter wrote: > Where can I find TS29.061? http://www.3gpp.org/ftp/Specs/html-info/29061.htm --00151773d3d27e974d04b3236cf2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Dec 2, 2011 at 14:15, Brian E Carpenter = <brian.e.carpenter@gmail.com> wrote:
Where can I find TS29.061?

--00151773d3d27e974d04b3236cf2-- From jouni.nospam@gmail.com Fri Dec 2 14:26:53 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 3F22F21F8C53 for ; Fri, 2 Dec 2011 14:26:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, 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 tIBpQjEwEzba for ; Fri, 2 Dec 2011 14:26:52 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3A83F11E80BF for ; Fri, 2 Dec 2011 14:26:52 -0800 (PST) Received: by lagw12 with SMTP id w12so79020lag.31 for ; Fri, 02 Dec 2011 14:26:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=BrZEEkQ0sJpdK6NvIluM9t3L232hV31eEwM0A5RluNg=; b=Yyd1t1YUHfpqhGFkahedvqgK8bqam2WShlA/Y1kMX9/9Og9K4+TW3xlLsWO4jwPIYc rAE7qtpc9nQMG4Lgm1quje3xxmyUTRrUiOZlph1trwYJMQyjQK1kJ6PDieV27i0qZXwS u49zR7is/jAAP2w9AM/OGI1JCS1ImMhkMslqg= Received: by 10.152.102.173 with SMTP id fp13mr118235lab.24.1322864811220; Fri, 02 Dec 2011 14:26:51 -0800 (PST) Received: from [188.117.15.109] ([188.117.15.109]) by mx.google.com with ESMTPS id nj4sm9823730lab.12.2011.12.02.14.26.48 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 02 Dec 2011 14:26:49 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Jouni In-Reply-To: <4ED94DED.5070108@gmail.com> Date: Sat, 3 Dec 2011 00:26:46 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <282BBE8A501E1F4DA9C775F964BB21FE3EB78C3C98@GRFMBX704BA020.griffon.local> <916CE6CF87173740BC8A2CE44309696204193417@008-AM1MPN1-053.mgdnok.nokia.com> <4EC512A2.2060509@gmail.com> <890A58CF-8EAD-4F92-9981-9B5AA07EBF00@nominum.com> <4EC63E26.70104@gmail.com> <86163A8F-8628-4F67-BE93-3747F95A2F52@nominum.com> <4ECB6EAE.2010701@gmail.com> <702C34B3-F6B7-4EFB-91D5-8538540534A1@nominum.com> <4ECBE3BE.5070501@gmail.com> <759E821F-B503-4C8D-A79B-5F9A68A3613F@nominum.com> <4ED6A08D.9090703@gmail.com> <9ACC70F6-6D21-4981-A3CE-BA3469658F62@gmail.com> <4ED7F2C0.4040902@gmail.com> <5AB3B2FC-8914-42AB-9173-8172D926462F@gmail.com> <4ED94DED.5070108@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1251.1) Cc: "mif@ietf.org" Subject: Re: [mif] Use cases for draft-ietf-mif-dhcpv6-route-option needed 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, 02 Dec 2011 22:26:53 -0000 http://www.3gpp.org/ftp/Specs/html-info/29061.htm=20 - Jouni On Dec 3, 2011, at 12:15 AM, Brian E Carpenter wrote: > Where can I find TS29.061? >=20 > Brian >=20 > On 2011-12-03 10:55, Jouni wrote: >> On Dec 2, 2011, at 8:49 PM, Tao Sun wrote: >>=20 >>> Latest yesterday I tweaked with such implementation. It is quite = common feature e.g. in 3GPP defined networks that the per subscriber = prefix for RA comes off AAA. It has been there in specs for say 9 years = and deployed at least several years. Also the per subscriber delegated = prefixes may come from AAA.. like the rest of the end host configuration = information. >>>=20 >>> [Tao] Could you be more specific which spec you are referring to? = Unfortunately, it is not ture that such implementation has >>=20 >> TS29.061.. you can trace it back about ~9 for RADIUS interface to = provide prefix for a RA. >>=20 >> - Jouni >>=20 >>=20 >>> "deployed at least several years". Few vandor implement their = network elements with good support of RA, not mention of the per >>> subscriber prefix from AAA or the RIO. The basic RA works in new = network element on 4G PDN gateways in recent one year or so .=20 >>=20 >>=20 >>=20 From alexandru.petrescu@gmail.com Sat Dec 3 06:45:00 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 6259121F8E6B for ; Sat, 3 Dec 2011 06:45:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.171 X-Spam-Level: X-Spam-Status: No, score=-0.171 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, 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 V-HLbDeeFosU for ; Sat, 3 Dec 2011 06:44:59 -0800 (PST) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id 910C521F8E6A for ; Sat, 3 Dec 2011 06:44:57 -0800 (PST) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id BEFBE940815; Sat, 3 Dec 2011 15:44:51 +0100 (CET) Message-ID: <4EDA35DD.8050005@gmail.com> Date: Sat, 03 Dec 2011 15:44:45 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Tao Sun References: <282BBE8A501E1F4DA9C775F964BB21FE3EB78C3C98@GRFMBX704BA020.griffon.local> <916CE6CF87173740BC8A2CE44309696204193417@008-AM1MPN1-053.mgdnok.nokia.com> <4EC512A2.2060509@gmail.com> <890A58CF-8EAD-4F92-9981-9B5AA07EBF00@nominum.com> <4EC63E26.70104@gmail.com> <86163A8F-8628-4F67-BE93-3747F95A2F52@nominum.com> <4ECB6EAE.2010701@gmail.com> <702C34B3-F6B7-4EFB-91D5-8538540534A1@nominum.com> <4ECBE3BE.5070501@gmail.com> <759E821F-B503-4C8D-A79B-5F9A68A3613F@nominum.com> <7C1F8DA5-357F-4403-BE0D-E72D425B71C9@gmail.com> <4ED7CA1C.1080606@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 111203-1, 03/12/2011), Outbound message X-Antivirus-Status: Clean Cc: mif@ietf.org Subject: Re: [mif] Use cases for draft-ietf-mif-dhcpv6-route-option needed 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: Sat, 03 Dec 2011 14:45:00 -0000 Le 02/12/2011 19:34, Tao Sun a écrit : > > > On Fri, Dec 2, 2011 at 3:22 AM, Lorenzo Colitti > wrote: > > On Thu, Dec 1, 2011 at 10:40, Alexandru Petrescu > > > wrote: > > Le 01/12/2011 18:24, Tao Sun a écrit : > > Hi Jouni, Thanks for the clarification. That is ture GGSN/PGW is not > mandate to do relay. "May" instead of "shall" is used to describe > GGSN/PGW's action. The only mandate is to use RA to obtain /64 > prefix. > > > And that mandate is not sufficient when the UE is actually a Router > ("mobile hotspot", "tethering"). For these cases, DHCPv6-PD is > suggested by 3GPP specs. Thus, the 3GPP specs assume that a > UE-Router (new term for this conversation) runs both RA _and_ DHCP. > But 3GPP specs overlook the fact that an UE-Router would't use RA to > auto-configure an address (stateless autoconf is only for Hosts). > > > That's not true - RFC 6204 says that an IPv6 CE router can use > autoconf to create an address. I think it's reasonable to say that if > you were to implement tethering using DHCPv6 PD, you would follow RFC > 6204. > > Hence 3GPP specs could consider that _only_ DHCP should should be > used by DHCPv6. In this sense, the above only mandate ("use RA to > obtain /64 prefix") could be dropped altogether. > > > See what I mean? We're already talking about not using RAs at all any > more, and we don't even have a DHCPv6 route option yet... > > RA still must be used by the host to get the /64 prefix first and > establish the connection towards the gateway. After that, DHCPv6 PD > is used if shorter than /64 prefix is required. YEs, that is what the 3GPP specs say. But I wonder whether better ways exist, to reduce the software code size, and number of messages exchanged on the air: use just DHCPv6 not RA to obtain address and its on-link prefix, prefix behind it, default route and DNS address. > If you worry about the possibility of dropping the use of RA, the > draft can be updated to clearly state that using DHCPv6 for route > option shall not prevent using RA for SLAAC... somthing like that. In a sense I could agree with this statement, to not prevent use of RA for SLAAC. Even better would be to say _how_ the potentially conflicting information received from RA and DHCP could be somehow ordered. Additionally, it is worth mentioning that DHCP route option per se has not any counterpart mechanism in pure non-4191 RA (the prefix advertised by RA, most widely implemented is the on-link prefix, as a "connected C" route at most, not to be confused with the "non-connected" route, as is likely to happen with the DHCP route-option). _Only_ if we talk route option to be a default route do we talk potential conflict DHCP-RA. For pure route-option there could be conflict between DHCP and e.g. OSPF but not DHCP and RA. Alex > I > > _______________________________________________ mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > > From alexandru.petrescu@gmail.com Sat Dec 3 06:50: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 2A3A021F8E98 for ; Sat, 3 Dec 2011 06:50:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.129 X-Spam-Level: X-Spam-Status: No, score=0.129 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, J_CHICKENPOX_33=0.6, 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 nZTgW74OiY9o for ; Sat, 3 Dec 2011 06:50:11 -0800 (PST) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id 315CB21F8E7C for ; Sat, 3 Dec 2011 06:50:09 -0800 (PST) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 92057940814 for ; Sat, 3 Dec 2011 15:50:04 +0100 (CET) Message-ID: <4EDA3716.3060607@gmail.com> Date: Sat, 03 Dec 2011 15:49:58 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: mif@ietf.org References: <282BBE8A501E1F4DA9C775F964BB21FE3EB78C3C98@GRFMBX704BA020.griffon.local> <4EC512A2.2060509@gmail.com> <890A58CF-8EAD-4F92-9981-9B5AA07EBF00@nominum.com> <4EC63E26.70104@gmail.com> <86163A8F-8628-4F67-BE93-3747F95A2F52@nominum.com> <4ECB6EAE.2010701@gmail.com> <702C34B3-F6B7-4EFB-91D5-8538540534A1@nominum.com> <4ECBE3BE.5070501@gmail.com> <759E821F-B503-4C8D-A79B-5F9A68A3613F@nominum.com> <4ED6A08D.9090703@gmail.com> <9ACC70F6-6D21-4981-A3CE-BA3469658F62@gmail.com> <4ED7F2C0.4040902@gmail.com> <4ED7F84E.9080906@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 111203-1, 03/12/2011), Outbound message X-Antivirus-Status: Clean Subject: Re: [mif] Use cases for draft-ietf-mif-dhcpv6-route-option needed 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: Sat, 03 Dec 2011 14:50:12 -0000 Le 02/12/2011 20:06, Lorenzo Colitti a écrit : > On Fri, Dec 2, 2011 at 00:39, Zhen Cao > wrote: > > For per-user configuration, the situation is that users are dynamic > and I do not see how the VLAN can be configured according to their > different requirements. If you use the extended information in the > VLAN setup and use selective unicast RA in 3GPP case, I think that > already reaches (and actually more complicated than) the threshold for > doing it using DHCPv6. > > > I'm not talking about VLANs for the 3GPP case. In the 3GPP case you have > a bunch of point to point interfaces (tunnels / PDP contexts / PDNs; one > or more per user) that each have their own network segment (a /64). > Per-user configuration is achieved simply by saying "the user on tunnel > X gets an RA with prefix Y". This is how IPv6 on mobile networks works > today. > > If you want more specific routes, you can easily include those in the > RA, I don't know how much software exist for RFC4191 specific routes to be received by a Router (not a Host)? Also, to support specific routes in RA towards a Router there would be need of specification change. (you pointed to an RFC6xxx but it read to me as Informational). Alex because as Jouni says, this is tied into AAA already. > > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif From hisuntao@gmail.com Mon Dec 5 09:51:56 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 82AFA21F8C26 for ; Mon, 5 Dec 2011 09:51:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[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 860lLsc+-M+E for ; Mon, 5 Dec 2011 09:51:55 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0E3A021F8C1F for ; Mon, 5 Dec 2011 09:51:54 -0800 (PST) Received: by vbbez10 with SMTP id ez10so1737838vbb.31 for ; Mon, 05 Dec 2011 09:51:53 -0800 (PST) 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=vmf21xeeG+TGslEpwT920eJycFO3Ij/gryXC8yV/fQg=; b=K9afrcrZaM2O8kMg3xiwlYfO31ZSwOpwKDIVk7YNKhoQ4j5Yh++h3UPGes5IGiRKbp y5x+bDXdd3UFr/TgnP84u/fAwgZeWwU9OetigV+ZrMsQEBeQTEzobf4y+rJSokTrS6ss CgUiObD2iZv+wpOrzmO1dJS72xaOsysDK4wgQ= MIME-Version: 1.0 Received: by 10.52.65.1 with SMTP id t1mr5392242vds.121.1323107513252; Mon, 05 Dec 2011 09:51:53 -0800 (PST) Received: by 10.220.194.133 with HTTP; Mon, 5 Dec 2011 09:51:52 -0800 (PST) In-Reply-To: References: <282BBE8A501E1F4DA9C775F964BB21FE3EB78C3C98@GRFMBX704BA020.griffon.local> <916CE6CF87173740BC8A2CE44309696204193417@008-AM1MPN1-053.mgdnok.nokia.com> <4EC512A2.2060509@gmail.com> <890A58CF-8EAD-4F92-9981-9B5AA07EBF00@nominum.com> <4EC63E26.70104@gmail.com> <86163A8F-8628-4F67-BE93-3747F95A2F52@nominum.com> <4ECB6EAE.2010701@gmail.com> <702C34B3-F6B7-4EFB-91D5-8538540534A1@nominum.com> <4ECBE3BE.5070501@gmail.com> <759E821F-B503-4C8D-A79B-5F9A68A3613F@nominum.com> <4ED6A08D.9090703@gmail.com> <9ACC70F6-6D21-4981-A3CE-BA3469658F62@gmail.com> <4ED7F2C0.4040902@gmail.com> <5AB3B2FC-8914-42AB-9173-8172D926462F@gmail.com> <4ED94DED.5070108@gmail.com> Date: Tue, 6 Dec 2011 01:51:52 +0800 Message-ID: From: Tao Sun To: Jouni Content-Type: multipart/alternative; boundary=20cf3071c76a53bb4704b35bf959 Cc: "mif@ietf.org" Subject: Re: [mif] Use cases for draft-ietf-mif-dhcpv6-route-option needed 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, 05 Dec 2011 17:51:56 -0000 --20cf3071c76a53bb4704b35bf959 Content-Type: text/plain; charset=ISO-8859-1 I traced back the TS 29.061 V3.a.0 which is more than 9 years from now. It is not convincing. While, the spec already mention the using of DHCP for configure paramters: "If the MS is DHCP capable and the IPv6 address has been allocated using Stateless Address Autoconfiguration, the MS may use a procedure as in the example below to configure additional external network protocol parameters, or other parameters that apply to the Intranet or ISP." RADIUS protocal from GGSN to AAA is mostly used for authorization, authentication and accounting and is not a good choice for host specific policy, as stated in the spec: "RADIUS for authentication and DHCP for host configuration and address allocation" On Sat, Dec 3, 2011 at 6:26 AM, Jouni wrote: > > http://www.3gpp.org/ftp/Specs/html-info/29061.htm > > - Jouni > > On Dec 3, 2011, at 12:15 AM, Brian E Carpenter wrote: > > > Where can I find TS29.061? > > > > Brian > > > > On 2011-12-03 10:55, Jouni wrote: > >> On Dec 2, 2011, at 8:49 PM, Tao Sun wrote: > >> > >>> Latest yesterday I tweaked with such implementation. It is quite > common feature e.g. in 3GPP defined networks that the per subscriber prefix > for RA comes off AAA. It has been there in specs for say 9 years and > deployed at least several years. Also the per subscriber delegated prefixes > may come from AAA.. like the rest of the end host configuration information. > >>> > >>> [Tao] Could you be more specific which spec you are referring to? > Unfortunately, it is not ture that such implementation has > >> > >> TS29.061.. you can trace it back about ~9 for RADIUS interface to > provide prefix for a RA. > >> > >> - Jouni > >> > >> > >>> "deployed at least several years". Few vandor implement their network > elements with good support of RA, not mention of the per > >>> subscriber prefix from AAA or the RIO. The basic RA works in new > network element on 4G PDN gateways in recent one year or so . > >> > >> > >> > > --20cf3071c76a53bb4704b35bf959 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I traced back the TS 29.061 V3.a.0 which is more than 9 years from now= . It is not convincing.
=C2=A0
While, the spec already mention the using of DHCP for configure paramt= ers:
&= quot;If the MS is DHCP capable and the IPv6 address has been allocated usin= g Stateless Address Autoconfiguration, the MS may use a procedure as in the= example below to configure additional external network protocol parameters= , or other parameters that apply to the Intranet or ISP."
<= /span>=C2=A0
R= ADIUS protocal from GGSN to AAA=C2=A0is mostly used for authorization, auth= entication and accounting and is not a good choice=C2=A0for host specific p= olicy, as stated in the spec:
&= quot;RADIUS for authentication a= nd DHCP for host configuration and address allocation"=C2=A0
=C2=A0
On Sat, Dec 3, 2011 at 6:26 AM, Jouni <jouni.nospam@gmail.c= om> wrote:

http://www.3gpp.org/ftp= /Specs/html-info/29061.htm

- Jouni

On Dec 3, 2011, at 12:15 AM, Brian E Carpenter wrote:=

> Where can I find TS29.061?
>
> =C2=A0 Brian
>= ;
> On 2011-12-03 10:55, Jouni wrote:
>> On Dec 2, 2011, at = 8:49 PM, Tao Sun wrote:
>>
>>> Latest yesterday I tweaked with such implementatio= n. It is quite common feature e.g. in 3GPP defined networks that the per su= bscriber prefix for RA comes off AAA. It has been there in specs for say 9 = years and deployed at least several years. Also the per subscriber delegate= d prefixes may come from AAA.. like the rest of the end host configuration = information.
>>>
>>> [Tao] Could you be more specific which spec yo= u are referring to? =C2=A0Unfortunately, it is not ture that such implement= ation has
>>
>> TS29.061.. you can trace it back about ~9= for RADIUS interface to provide prefix for a RA.
>>
>> - Jouni
>>
>>
>>> "= deployed at least several years". Few vandor implement their network e= lements with good support of RA, not mention of the per
>>> sub= scriber prefix from AAA or the RIO. The basic RA works in new network eleme= nt on 4G PDN gateways in recent one year or so .
>>
>>
>>


--20cf3071c76a53bb4704b35bf959-- From lorenzo@google.com Mon Dec 5 10:19:13 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 5880821F8C86 for ; Mon, 5 Dec 2011 10:19:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.602 X-Spam-Level: X-Spam-Status: No, score=-102.602 tagged_above=-999 required=5 tests=[AWL=-0.226, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, 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 cuh95so74iD0 for ; Mon, 5 Dec 2011 10:19:12 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id CCB1821F8C18 for ; Mon, 5 Dec 2011 10:19:12 -0800 (PST) Received: by yenl9 with SMTP id l9so4147080yen.31 for ; Mon, 05 Dec 2011 10:19:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=wYx8qki4O/qMhA2S1qqkVsUr9icQNUFWsf/2ris7xKM=; b=JDgkS4lUqU8v7wuO8TLOLaNZa7dLd5F0Hdw2CEMxJKiZyWH4Ixo51geDXWrX6RbLjC S5uyuR0oG3UjRT7Ep1zw== Received: by 10.236.128.138 with SMTP id f10mr14358614yhi.2.1323109152468; Mon, 05 Dec 2011 10:19:12 -0800 (PST) Received: by 10.236.128.138 with SMTP id f10mr14358600yhi.2.1323109152368; Mon, 05 Dec 2011 10:19:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.150.202.14 with HTTP; Mon, 5 Dec 2011 10:18:51 -0800 (PST) In-Reply-To: <4EDA3716.3060607@gmail.com> References: <282BBE8A501E1F4DA9C775F964BB21FE3EB78C3C98@GRFMBX704BA020.griffon.local> <4EC512A2.2060509@gmail.com> <890A58CF-8EAD-4F92-9981-9B5AA07EBF00@nominum.com> <4EC63E26.70104@gmail.com> <86163A8F-8628-4F67-BE93-3747F95A2F52@nominum.com> <4ECB6EAE.2010701@gmail.com> <702C34B3-F6B7-4EFB-91D5-8538540534A1@nominum.com> <4ECBE3BE.5070501@gmail.com> <759E821F-B503-4C8D-A79B-5F9A68A3613F@nominum.com> <4ED6A08D.9090703@gmail.com> <9ACC70F6-6D21-4981-A3CE-BA3469658F62@gmail.com> <4ED7F2C0.4040902@gmail.com> <4ED7F84E.9080906@gmail.com> <4EDA3716.3060607@gmail.com> From: Lorenzo Colitti Date: Mon, 5 Dec 2011 10:18:51 -0800 Message-ID: To: Alexandru Petrescu Content-Type: multipart/alternative; boundary=20cf3005dd9006a69804b35c5b24 X-System-Of-Record: true Cc: mif@ietf.org Subject: Re: [mif] Use cases for draft-ietf-mif-dhcpv6-route-option needed 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, 05 Dec 2011 18:19:13 -0000 --20cf3005dd9006a69804b35c5b24 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Dec 3, 2011 at 06:49, Alexandru Petrescu < alexandru.petrescu@gmail.com> wrote: > I don't know how much software exist for RFC4191 specific routes to be > received by a Router (not a Host)? > Routers don't listen to RAs in general, so, not much. They also aren't usually DHCPv6 clients. Unless they're customer routers, in which case they use both. > Also, to support specific routes in RA towards a Router there would be > need of specification change. (you pointed to an RFC6xxx but it read to me > as Informational). > The router that is the next-hop to a particular prefix needs to send the RA with an RIO for that prefix, yes. If that router does not wish to be the default router, it can set the default lifetime field to zero. I don't a router can can send an RIO option that says "send traffic to this prefix to this other router". This is good because it encourages fate-sharing, which usually makes things more likely to work. --20cf3005dd9006a69804b35c5b24 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sat, Dec 3, 2011 at 06:49, Alexandru Petrescu= <alex= andru.petrescu@gmail.com> wrote:
I don't know how much software exist for RFC4191 specific routes to be = received by a Router (not a Host)?

Rout= ers don't listen to RAs in general, so, not much. They also aren't = usually DHCPv6 clients. Unless they're customer routers, in which case = they use both.
=A0
Also, to support specific rou= tes in RA towards a Router there would be need of specification change. =A0= (you pointed to an RFC6xxx but it read to me as Informational).

The router that is the next-hop to a parti= cular prefix needs to send the RA with an RIO for that prefix, yes.=A0If th= at router does not wish to be the default router, it can set the default li= fetime field to zero.=A0I don't a router can can send an RIO option tha= t says "send traffic to this prefix to this other router". This i= s good because it encourages fate-sharing, which usually makes things more = likely to work.
--20cf3005dd9006a69804b35c5b24-- From hisuntao@gmail.com Mon Dec 5 11:25: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 ECEBC11E80DD for ; Mon, 5 Dec 2011 11:25:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 inYPg57y2F8x for ; Mon, 5 Dec 2011 11:25:04 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0C79511E80DC for ; Mon, 5 Dec 2011 11:25:03 -0800 (PST) Received: by vbbez10 with SMTP id ez10so1833822vbb.31 for ; Mon, 05 Dec 2011 11:25:03 -0800 (PST) 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=UcO+F7up5Nnr9ft0kvF7q98crQ08hEJJOE0oTa0a9rE=; b=bXVELweg0XdAsgMNkt+HWHENQYLvqISPjoLztvzmkrtKuj+w/IzJp01fqtZf6ZtLkK KBHdZ3Aqxe2ZsYJBcl6T44NKVdTXWkqFFnvskHvLyeHH0zGGxckuBqVvtwWL2D8QTDLq Rh30y1d6fb28IdQ/Xcz6Xu2WsQRR8YKkLD9oE= MIME-Version: 1.0 Received: by 10.52.65.1 with SMTP id t1mr5670111vds.121.1323113103242; Mon, 05 Dec 2011 11:25:03 -0800 (PST) Received: by 10.220.194.133 with HTTP; Mon, 5 Dec 2011 11:25:03 -0800 (PST) In-Reply-To: References: <282BBE8A501E1F4DA9C775F964BB21FE3EB78C3C98@GRFMBX704BA020.griffon.local> <916CE6CF87173740BC8A2CE44309696204193417@008-AM1MPN1-053.mgdnok.nokia.com> <4EC512A2.2060509@gmail.com> <890A58CF-8EAD-4F92-9981-9B5AA07EBF00@nominum.com> <4EC63E26.70104@gmail.com> <86163A8F-8628-4F67-BE93-3747F95A2F52@nominum.com> <4ECB6EAE.2010701@gmail.com> <702C34B3-F6B7-4EFB-91D5-8538540534A1@nominum.com> <4ECBE3BE.5070501@gmail.com> <759E821F-B503-4C8D-A79B-5F9A68A3613F@nominum.com> <4ED6A08D.9090703@gmail.com> Date: Tue, 6 Dec 2011 03:25:03 +0800 Message-ID: From: Tao Sun To: Lorenzo Colitti Content-Type: multipart/alternative; boundary=20cf3071c76a8435f104b35d462a Cc: "mif@ietf.org" Subject: Re: [mif] Use cases for draft-ietf-mif-dhcpv6-route-option needed 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, 05 Dec 2011 19:25:05 -0000 --20cf3071c76a8435f104b35d462a Content-Type: text/plain; charset=ISO-8859-1 Ok. I reiterate the use cases and the justification of using DHCPv6. For the cellular network, I mainly focus on two use cases: 1) A host is connected to the cellular network and WiFi at the same time. Some traffic need to go cellular network, others go to WiFi. 2) A mobile host in the cellular network simultaneously connects to multiple APNs (taking APN1 and APN2 for example) . Some traffics go to APN1, others got to APN2. The justification of adopt DHCPv6 is the following: 1) DHCPv6 is anyway shall be implemented and is suitable for parameter configuration. This is due to prefix delegation for tethering, network parameter configuration such as DNS, network server informaiton of IMS, etc. 2) DHCPv6 is more management/operation friendly due to the central control mechanism. 3) DHCP has been already used for paramter configuration, while using RA will cause significant modification and enhancement for network elements and hosts, especially for per-subscriber purpose (e.g., using VLAN). 4) Using RA to configure the route may cause potentially some messy. In 4G cellular network, both GTP and PMIP protocal are used for mobility management today. In GTP, it is a point-to-point link between mobile host and PGW. However, in PMIP, PGW send /64 prefix to SGW through PBA. The SGW sends RA to mobile host. If RA is also used for route configuration, how SGW obtains the specific route information? how about the complexity due to the large number of SGW as compared with PGW? how the SGW combine the multiple RA route informatio nreceived from sources in use case 2 since there is always only one SGW at a time? ... Based on above, using RA for SLAAC and DHCPv6 for route paramter configuration is a more effective way. In my view, the discussion is adequate enough to move the draft forward to version 4 and we shall not continue to stay on the necessity analysis. Tao Sun On Sat, Dec 3, 2011 at 3:21 AM, Lorenzo Colitti wrote: > On Fri, Dec 2, 2011 at 10:15, Tao Sun wrote: > >> I'm not talking about mobile networks specifically here. I think this >>> particular event (turning off RAs) is more likely that to happen on a wifi >>> network or an enterprise network. >>> >> As I pointed out in my previous email, WiFi network is already part of >> mobile network. China Mobile deployed about more than one hundred of >> thousand hotspots (over 1 million WiFi AP). Users use the same smart phone >> to visit cellular network and WiFi network. >> > > Ok, so then let's take a look at that use case and see why it requires a > DHCPv6 route option to be defined. I suspect that you can do what you want > using RIO. > --20cf3071c76a8435f104b35d462a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Ok. I reiterate the use cases and=A0the justification of using DHCPv6.=
=A0
For the cellular network, I mainly focus on two use cases: 1) A host i= s connected to the cellular=A0network and WiFi at the same time. Some traff= ic need to go cellular network, others go to WiFi. 2) A mobile host in the = cellular network simultaneously connects to multiple APNs (taking APN1 and = APN2 for example)=A0. Some traffics go=A0to APN1, others got to APN2.
=A0
The justification of adopt DHCPv6 is the following:
1) DHCPv6 is anyway shall be implemented and is suitable for parameter= configuration. This is due to prefix delegation for tethering, network par= ameter configuration such as DNS, network server informaiton of IMS, etc.
2) DHCPv6 is more management/operation friendly due to the central con= trol mechanism.
3) DHCP has been already used for paramter configuration, while using = RA will cause significant modification and enhancement for network elements= and hosts, especially for per-subscriber purpose (e.g., using VLAN).
4) Using RA to configure the route may cause potentially some messy. I= n 4G cellular network, both GTP and PMIP protocal=A0are=A0used for mobility= management today. In GTP,=A0it is a point-to-point link between=A0mobile h= ost and PGW. However, in PMIP, PGW send /64=A0prefix to SGW through PBA. Th= e SGW sends RA to mobile host. If RA is also used for route configuration, = how SGW obtains the specific route information? how about the complexity du= e to the large=A0number of SGW as compared with=A0PGW? how the=A0SGW combin= e the multiple RA route informatio nreceived from sources=A0in use case 2 s= ince=A0there is always only one SGW at a time? ...=A0
=A0
Based on above, using RA=A0for SLAAC and DHCPv6=A0for route paramter c= onfiguration is a more effective way.
=A0
In my view, the discussion is adequate enough=A0to move the draft forw= ard to version 4 and we shall not continue to stay on the necessity analysi= s.
=A0
Tao Sun
=A0
On Sat, Dec 3, 2011 at 3:21 AM, Lorenzo Colitti = <lorenzo@google.= com> wrote:
On Fri, Dec 2, 2011 at 10:15, Tao Sun &= lt;hisuntao@gmail.c= om> wrote:
I'm not talking about mobile networks specifically here. I think t= his particular event (turning off RAs) is more likely that to happen on a w= ifi network or an enterprise network.
As I pointed out in my previous email, WiFi network is already part of= mobile=A0network.=A0China Mobile deployed about more than one hundred of t= housand=A0hotspots (over 1 million WiFi AP). Users use the same smart phone= to visit cellular network and WiFi network.

Ok, so then let's take a look at that use case and see why it requ= ires a DHCPv6 route option to be defined. I suspect that you can do what yo= u want using RIO.

--20cf3071c76a8435f104b35d462a-- From jouni.nospam@gmail.com Mon Dec 5 16:40:02 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 97BE611E80C1 for ; Mon, 5 Dec 2011 16:40:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, 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 qmWUB9ka+vMD for ; Mon, 5 Dec 2011 16:40:01 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3606211E80BC for ; Mon, 5 Dec 2011 16:40:01 -0800 (PST) Received: by lagw12 with SMTP id w12so1220320lag.31 for ; Mon, 05 Dec 2011 16:40:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=jdaRvI8QCti4fA8FDTOtTl6kECQFiWcEzRPsHsX+7wQ=; b=ADDB7ShSCfP7FITGGplkxCfvFjOV9tHQsW+2MH0yXETVexYiitHidDOgSAsOPn7WOD mYDSTRnw1F6p9TbJ+d5HIzugT0UAJODdyI/4xHcz7ojZTz78Fh0HiEDnzJ+GShkF7VV/ i9gc154h4oH9KsFC/O1wtXxEaZdSA6KSE7uUA= Received: by 10.152.102.138 with SMTP id fo10mr7578209lab.44.1323132000171; Mon, 05 Dec 2011 16:40:00 -0800 (PST) Received: from [188.117.15.109] ([188.117.15.109]) by mx.google.com with ESMTPS id oy14sm5108353lab.9.2011.12.05.16.39.58 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 05 Dec 2011 16:39:59 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Jouni In-Reply-To: Date: Tue, 6 Dec 2011 02:39:56 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <805C4AB5-9B43-48B5-A54E-B5AAD17B2BD9@gmail.com> References: <282BBE8A501E1F4DA9C775F964BB21FE3EB78C3C98@GRFMBX704BA020.griffon.local> <916CE6CF87173740BC8A2CE44309696204193417@008-AM1MPN1-053.mgdnok.nokia.com> <4EC512A2.2060509@gmail.com> <890A58CF-8EAD-4F92-9981-9B5AA07EBF00@nominum.com> <4EC63E26.70104@gmail.com> <86163A8F-8628-4F67-BE93-3747F95A2F52@nominum.com> <4ECB6EAE.2010701@gmail.com> <702C34B3-F6B7-4EFB-91D5-8538540534A1@nominum.com> <4ECBE3BE.5070501@gmail.com> <759E821F-B503-4C8D-A79B-5F9A68A3613F@nominum.com> <4ED6A08D.9090703@gmail.com> To: Tao Sun X-Mailer: Apple Mail (2.1251.1) Cc: "mif@ietf.org" Subject: Re: [mif] Use cases for draft-ietf-mif-dhcpv6-route-option needed 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, 06 Dec 2011 00:40:02 -0000 Hi, On Dec 5, 2011, at 9:25 PM, Tao Sun wrote: > Ok. I reiterate the use cases and the justification of using DHCPv6. > =20 > For the cellular network, I mainly focus on two use cases: 1) A host = is connected to the cellular network and WiFi at the same time. Some = traffic need to go cellular network, others go to WiFi. 2) A mobile host = in the cellular network simultaneously connects to multiple APNs (taking = APN1 and APN2 for example) . Some traffics go to APN1, others got to = APN2. These are (at least the example 1) doable using RFC4191 and RAs. For the = latter case how the default router for "default traffic" gets selected = (independent of DHCPv6 or RAs) is a bit of an issue if all interfaces = (APNs) are equal. I can use AAA (or hypothetically even PCC) as my central configuration = database.. > The justification of adopt DHCPv6 is the following: > 1) DHCPv6 is anyway shall be implemented and is suitable for parameter = configuration. This is due to prefix delegation for tethering, network = parameter configuration such as DNS, network server informaiton of IMS, = etc. It is still optional for 3GPP networks from specs point of view as far = as I remember. Both RFC3736 and RFC3633 are "Both EPS network elements = and UE may support". > 2) DHCPv6 is more management/operation friendly due to the central = control mechanism. Compared to AAA based on what grounds? > 3) DHCP has been already used for paramter configuration, while using = RA will cause significant modification and enhancement for network = elements and hosts, especially for per-subscriber purpose (e.g., using = VLAN). In the above (cellular oriented) example, I am not so sure. In cellular = (3GPP) networks the RAs are already used in per subscriber manner. > 4) Using RA to configure the route may cause potentially some messy. = In 4G cellular network, both GTP and PMIP protocal are used for mobility = management today. In GTP, it is a point-to-point link between mobile = host and PGW. However, in PMIP, PGW send /64 prefix to SGW through PBA. = The SGW sends RA to mobile host. If RA is also used for route = configuration, how SGW obtains the specific route information? how about = the complexity due to the large number of SGW as compared with PGW? how = the SGW combine the multiple RA route informatio nreceived from sources = in use case 2 since there is always only one SGW at a time? ...=20 This is a good point in cellular context, especially the PMIPv6 case is = very true. > Based on above, using RA for SLAAC and DHCPv6 for route paramter = configuration is a more effective way. Note that I have nothing against DHCPv6 router parameter configuration = work in general (OK to complete it), however, RAs and RFC4191 do have = merits especially in the above example (cellular) context. Specifically = the push model of per-subscriber RAs is attractive. - Jouni > =20 > In my view, the discussion is adequate enough to move the draft = forward to version 4 and we shall not continue to stay on the necessity = analysis. > =20 > Tao Sun > =20 > On Sat, Dec 3, 2011 at 3:21 AM, Lorenzo Colitti = wrote: > On Fri, Dec 2, 2011 at 10:15, Tao Sun wrote: > I'm not talking about mobile networks specifically here. I think this = particular event (turning off RAs) is more likely that to happen on a = wifi network or an enterprise network. > As I pointed out in my previous email, WiFi network is already part of = mobile network. China Mobile deployed about more than one hundred of = thousand hotspots (over 1 million WiFi AP). Users use the same smart = phone to visit cellular network and WiFi network. >=20 > Ok, so then let's take a look at that use case and see why it requires = a DHCPv6 route option to be defined. I suspect that you can do what you = want using RIO. >=20 > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif From lorenzo@google.com Mon Dec 5 16:48: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 61E1111E808A for ; Mon, 5 Dec 2011 16:48:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.898 X-Spam-Level: X-Spam-Status: No, score=-102.898 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 pjV+YuaE-t2O for ; Mon, 5 Dec 2011 16:48:50 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id ED05A11E8089 for ; Mon, 5 Dec 2011 16:48:49 -0800 (PST) Received: by yenl9 with SMTP id l9so4499818yen.31 for ; Mon, 05 Dec 2011 16:48:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=GkmTVusf5uFVEEOPUdYeMkSddjjbaUqi5qChF6OFmh8=; b=psWcODHk7D3yUXEHL4swp2ROPZkZimv6bJFw7mFPtRqJCZxszl7JesIQ9kbRKIvbU+ 0VvMsK1cYNMS48Higz4Q== Received: by 10.236.75.167 with SMTP id z27mr16541350yhd.53.1323132528441; Mon, 05 Dec 2011 16:48:48 -0800 (PST) Received: by 10.236.75.167 with SMTP id z27mr16541339yhd.53.1323132528296; Mon, 05 Dec 2011 16:48:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.150.202.14 with HTTP; Mon, 5 Dec 2011 16:48:26 -0800 (PST) In-Reply-To: References: <282BBE8A501E1F4DA9C775F964BB21FE3EB78C3C98@GRFMBX704BA020.griffon.local> <916CE6CF87173740BC8A2CE44309696204193417@008-AM1MPN1-053.mgdnok.nokia.com> <4EC512A2.2060509@gmail.com> <890A58CF-8EAD-4F92-9981-9B5AA07EBF00@nominum.com> <4EC63E26.70104@gmail.com> <86163A8F-8628-4F67-BE93-3747F95A2F52@nominum.com> <4ECB6EAE.2010701@gmail.com> <702C34B3-F6B7-4EFB-91D5-8538540534A1@nominum.com> <4ECBE3BE.5070501@gmail.com> <759E821F-B503-4C8D-A79B-5F9A68A3613F@nominum.com> <4ED6A08D.9090703@gmail.com> From: Lorenzo Colitti Date: Mon, 5 Dec 2011 16:48:26 -0800 Message-ID: To: Tao Sun Content-Type: multipart/alternative; boundary=20cf3005dde657042504b361cc9e X-System-Of-Record: true Cc: "mif@ietf.org" Subject: Re: [mif] Use cases for draft-ietf-mif-dhcpv6-route-option needed 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, 06 Dec 2011 00:48:51 -0000 --20cf3005dde657042504b361cc9e Content-Type: text/plain; charset=ISO-8859-1 On Mon, Dec 5, 2011 at 11:25, Tao Sun wrote: > 3) DHCP has been already used for paramter configuration, while using RA > will cause significant modification and enhancement for network elements > and hosts, especially for per-subscriber purpose (e.g., using VLAN). > In the 3G scenario you don't need VLANs, as all subscriber interfaces are separate point-to-point interfaces, each with its own /64, and you're already provisioning these /64s on a per-subscriber basis. --20cf3005dde657042504b361cc9e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Dec 5, 2011 at 11:25, Tao Sun <hisuntao@gmail.com&g= t; wrote:
3) DHCP has been already used for paramter configuration, while using = RA will cause significant modification and enhancement for network elements= and hosts, especially for per-subscriber purpose (e.g., using VLAN).

In the 3G scenario you don't need VLAN= s, as all subscriber interfaces are separate point-to-point interfaces, eac= h with its own /64, and you're already provisioning these /64s on a per= -subscriber basis.
--20cf3005dde657042504b361cc9e-- From pierrick.seite@orange.com Tue Dec 6 01:13:11 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 5CCCE21F8B67 for ; Tue, 6 Dec 2011 01:13:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 beOYCB7gWHAk for ; Tue, 6 Dec 2011 01:13:10 -0800 (PST) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by ietfa.amsl.com (Postfix) with ESMTP id DF0E221F8B66 for ; Tue, 6 Dec 2011 01:13:09 -0800 (PST) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 5DD0F8B8027; Tue, 6 Dec 2011 10:14:32 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id 4C7ED8B8025; Tue, 6 Dec 2011 10:14:32 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 6 Dec 2011 10:13:07 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCB3F7.44304D10" Date: Tue, 6 Dec 2011 10:13:06 +0100 Message-ID: <843DA8228A1BA74CA31FB4E111A5C46202127F81@ftrdmel0.rd.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mif] Use cases for draft-ietf-mif-dhcpv6-route-option needed Thread-Index: Acyzg5kZP92MCtsvRfeoQw2q9pm9JwAbochA References: <282BBE8A501E1F4DA9C775F964BB21FE3EB78C3C98@GRFMBX704BA020.griffon.local><916CE6CF87173740BC8A2CE44309696204193417@008-AM1MPN1-053.mgdnok.nokia.com><4EC512A2.2060509@gmail.com><890A58CF-8EAD-4F92-9981-9B5AA07EBF00@nominum.com><4EC63E26.70104@gmail.com><86163A8F-8628-4F67-BE93-3747F95A2F52@nominum.com><4ECB6EAE.2010701@gmail.com><702C34B3-F6B7-4EFB-91D5-8538540534A1@nominum.com><4ECBE3BE.5070501@gmail.com><759E821F-B503-4C8D-A79B-5F9A68A3613F@nominum.com><4ED6A08D.9090703@gmail.com> From: To: , X-OriginalArrivalTime: 06 Dec 2011 09:13:07.0694 (UTC) FILETIME=[44A638E0:01CCB3F7] Cc: mif@ietf.org Subject: Re: [mif] Use cases for draft-ietf-mif-dhcpv6-route-option needed 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, 06 Dec 2011 09:13:11 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCB3F7.44304D10 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, =20 Regarding use-cases below, the operator will likely rely on a = centralized policy server; actually the 3GPP/ANDSF has been specified = for that purpose. =20 Pierrick =20 ________________________________ De : mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part de = Tao Sun Envoy=E9 : lundi 5 d=E9cembre 2011 20:25 =C0 : Lorenzo Colitti Cc : mif@ietf.org Objet : Re: [mif] Use cases for draft-ietf-mif-dhcpv6-route-option = needed =20 Ok. I reiterate the use cases and the justification of using DHCPv6.=20 =20 For the cellular network, I mainly focus on two use cases: 1) A host is = connected to the cellular network and WiFi at the same time. Some = traffic need to go cellular network, others go to WiFi. 2) A mobile host = in the cellular network simultaneously connects to multiple APNs (taking = APN1 and APN2 for example) . Some traffics go to APN1, others got to = APN2. =20 The justification of adopt DHCPv6 is the following: 1) DHCPv6 is anyway shall be implemented and is suitable for parameter = configuration. This is due to prefix delegation for tethering, network = parameter configuration such as DNS, network server informaiton of IMS, = etc. 2) DHCPv6 is more management/operation friendly due to the central = control mechanism.=20 3) DHCP has been already used for paramter configuration, while using RA = will cause significant modification and enhancement for network elements = and hosts, especially for per-subscriber purpose (e.g., using VLAN).=20 4) Using RA to configure the route may cause potentially some messy. In = 4G cellular network, both GTP and PMIP protocal are used for mobility = management today. In GTP, it is a point-to-point link between mobile = host and PGW. However, in PMIP, PGW send /64 prefix to SGW through PBA. = The SGW sends RA to mobile host. If RA is also used for route = configuration, how SGW obtains the specific route information? how about = the complexity due to the large number of SGW as compared with PGW? how = the SGW combine the multiple RA route informatio nreceived from sources = in use case 2 since there is always only one SGW at a time? ...=20 =20 Based on above, using RA for SLAAC and DHCPv6 for route paramter = configuration is a more effective way.=20 =20 In my view, the discussion is adequate enough to move the draft forward = to version 4 and we shall not continue to stay on the necessity = analysis.=20 =20 Tao Sun =20 On Sat, Dec 3, 2011 at 3:21 AM, Lorenzo Colitti = wrote: On Fri, Dec 2, 2011 at 10:15, Tao Sun wrote: I'm not talking about mobile networks specifically here. I think this = particular event (turning off RAs) is more likely that to happen on a = wifi network or an enterprise network. As I pointed out in my previous email, WiFi network is already part of = mobile network. China Mobile deployed about more than one hundred of = thousand hotspots (over 1 million WiFi AP). Users use the same smart = phone to visit cellular network and WiFi network. =20 Ok, so then let's take a look at that use case and see why it requires = a DHCPv6 route option to be defined. I suspect that you can do what you = want using RIO. =20 ------_=_NextPart_001_01CCB3F7.44304D10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 =

Regarding = use-cases below, the operator will likely rely on a centralized policy server; actually = the 3GPP/ANDSF has been specified for that purpose.

 =

Pierrick

 =

De : mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part de Tao Sun
Envoy=E9 : lundi 5 = d=E9cembre 2011 20:25
=C0 : Lorenzo = Colitti
Cc : = mif@ietf.org
Objet : Re: [mif] = Use cases for draft-ietf-mif-dhcpv6-route-option = needed

 

Ok. I reiterate the use cases and the justification of = using DHCPv6.

 

For the cellular network, I mainly focus on two use cases: 1) A = host is connected to the cellular network and WiFi at the same time. Some = traffic need to go cellular network, others go to WiFi. 2) A mobile host in the cellular network simultaneously connects to multiple APNs (taking APN1 = and APN2 for example) . Some traffics go to APN1, others got to = APN2.

 

The justification of adopt DHCPv6 is the = following:

1) DHCPv6 is anyway shall be implemented and is suitable for = parameter configuration. This is due to prefix delegation for tethering, network parameter configuration such as DNS, network server informaiton of IMS, = etc.

2) DHCPv6 is more management/operation friendly due to the = central control mechanism.

3) DHCP has been already used for paramter configuration, while = using RA will cause significant modification and enhancement for network = elements and hosts, especially for per-subscriber purpose (e.g., using VLAN). =

4) Using RA to configure the route may cause potentially some = messy. In 4G cellular network, both GTP and PMIP protocal are used for = mobility management today. In GTP, it is a point-to-point link = between mobile host and PGW. However, in PMIP, PGW send /64 prefix to SGW through = PBA. The SGW sends RA to mobile host. If RA is also used for route = configuration, how SGW obtains the specific route information? how about the complexity = due to the large number of SGW as compared with PGW? how the SGW combine the multiple RA route informatio nreceived from sources in = use case 2 since there is always only one SGW at a time? = ... 

 

Based on above, using RA for SLAAC and DHCPv6 for = route paramter configuration is a more effective way. =

 

In my view, the discussion is adequate enough to move the = draft forward to version 4 and we shall not continue to stay on the necessity analysis.

 

Tao Sun

 

On Sat, Dec 3, 2011 at 3:21 AM, Lorenzo Colitti <lorenzo@google.com> = wrote:

On Fri, Dec 2, 2011 at 10:15, Tao Sun <hisuntao@gmail.com> wrote:

I'm not talking about mobile networks specifically here. I think = this particular event (turning off RAs) is more likely that to happen on a = wifi network or an enterprise network.

As I pointed out in my previous email, WiFi network is already = part of mobile network. China Mobile deployed about more than one = hundred of thousand hotspots (over 1 million WiFi AP). Users use the same = smart phone to visit cellular network and WiFi network.

 

Ok, so then let's take a look at that use case and see why it = requires a DHCPv6 route option to be defined. I suspect that you can do what you = want using RIO.

 

------_=_NextPart_001_01CCB3F7.44304D10-- From hisuntao@gmail.com Tue Dec 6 10:56:03 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 38B9521F8C1F for ; Tue, 6 Dec 2011 10:56:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 0J0x8MLLEF3X for ; Tue, 6 Dec 2011 10:56:02 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0008D21F8C0C for ; Tue, 6 Dec 2011 10:56:01 -0800 (PST) Received: by vbbez10 with SMTP id ez10so2909826vbb.31 for ; Tue, 06 Dec 2011 10:56:01 -0800 (PST) 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=j23xw0J0IPwN8yimxUz8GsbdJwkUURcVFqiizesOvDw=; b=SFBrgg4IKTX341cLBxQrsfmksgRJuea5x2hwpx42Z56k80uwb77vl2FwKTBib7b59V b/0gQ8YnJQ5PHlEDvu2W+vISiPcALoSeblmnVyEEgQCsx4hVReSASNcNl+UXtM0DAPLF SS3T1eVvepKdqFsGP2qRsAz4RxeiIVoLTLVYQ= MIME-Version: 1.0 Received: by 10.52.33.69 with SMTP id p5mr8689745vdi.78.1323197761499; Tue, 06 Dec 2011 10:56:01 -0800 (PST) Received: by 10.220.194.133 with HTTP; Tue, 6 Dec 2011 10:56:01 -0800 (PST) In-Reply-To: <805C4AB5-9B43-48B5-A54E-B5AAD17B2BD9@gmail.com> References: <282BBE8A501E1F4DA9C775F964BB21FE3EB78C3C98@GRFMBX704BA020.griffon.local> <916CE6CF87173740BC8A2CE44309696204193417@008-AM1MPN1-053.mgdnok.nokia.com> <4EC512A2.2060509@gmail.com> <890A58CF-8EAD-4F92-9981-9B5AA07EBF00@nominum.com> <4EC63E26.70104@gmail.com> <86163A8F-8628-4F67-BE93-3747F95A2F52@nominum.com> <4ECB6EAE.2010701@gmail.com> <702C34B3-F6B7-4EFB-91D5-8538540534A1@nominum.com> <4ECBE3BE.5070501@gmail.com> <759E821F-B503-4C8D-A79B-5F9A68A3613F@nominum.com> <4ED6A08D.9090703@gmail.com> <805C4AB5-9B43-48B5-A54E-B5AAD17B2BD9@gmail.com> Date: Wed, 7 Dec 2011 02:56:01 +0800 Message-ID: From: Tao Sun To: Jouni Content-Type: multipart/alternative; boundary=20cf3079ba548ab0e904b370fc53 Cc: "mif@ietf.org" Subject: Re: [mif] Use cases for draft-ietf-mif-dhcpv6-route-option needed 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, 06 Dec 2011 18:56:03 -0000 --20cf3079ba548ab0e904b370fc53 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Dec 6, 2011 at 8:39 AM, Jouni wrote: > Hi, > > On Dec 5, 2011, at 9:25 PM, Tao Sun wrote: > > > Ok. I reiterate the use cases and the justification of using DHCPv6. > > > > For the cellular network, I mainly focus on two use cases: 1) A host is > connected to the cellular network and WiFi at the same time. Some traffic > need to go cellular network, others go to WiFi. 2) A mobile host in the > cellular network simultaneously connects to multiple APNs (taking APN1 and > APN2 for example) . Some traffics go to APN1, others got to APN2. > > These are (at least the example 1) doable using RFC4191 and RAs. For the > latter case how the default router for "default traffic" gets selected > (independent of DHCPv6 or RAs) is a bit of an issue if all interfaces > (APNs) are equal. > [Tao] The interfaces (APNs) are generally not equal, i.e., APN_IMS, APN_Internet. > > I can use AAA (or hypothetically even PCC) as my central configuration > database.. > [Tao] Using AAA, maybe. Using PCC is hypotheses. :-) > > > The justification of adopt DHCPv6 is the following: > > 1) DHCPv6 is anyway shall be implemented and is suitable for parameter > configuration. This is due to prefix delegation for tethering, network > parameter configuration such as DNS, network server informaiton of IMS, etc. > > It is still optional for 3GPP networks from specs point of view as far as > I remember. Both RFC3736 and RFC3633 are "Both EPS network elements and UE > may support". > [Tao] From specs point of view, it is optional. From real implementation, IMHO, it will be implemented, e.g., using LTE as backhaul for tethering is a quite attractive feature. > > > 2) DHCPv6 is more management/operation friendly due to the central > control mechanism. > > Compared to AAA based on what grounds? > [Tao] Using radius with AAA is only used for few enterprise users in some operator's network. > > > 3) DHCP has been already used for paramter configuration, while using RA > will cause significant modification and enhancement for network elements > and hosts, especially for per-subscriber purpose (e.g., using VLAN). > > In the above (cellular oriented) example, I am not so sure. In cellular > (3GPP) networks the RAs are already used in per subscriber manner. > [Tao] You need to update radius protocal and AAA specification in 3GPP to convey the configuration information. The mandatory RA for prefix assignment is supported not long time ago by network elements. Ohter optional extension of RA such as RIO indeeds new requirement for network elements and handset. > > > 4) Using RA to configure the route may cause potentially some messy. In > 4G cellular network, both GTP and PMIP protocal are used for mobility > management today. In GTP, it is a point-to-point link between mobile host > and PGW. However, in PMIP, PGW send /64 prefix to SGW through PBA. The SGW > sends RA to mobile host. If RA is also used for route configuration, how > SGW obtains the specific route information? how about the complexity due to > the large number of SGW as compared with PGW? how the SGW combine the > multiple RA route informatio nreceived from sources in use case 2 since > there is always only one SGW at a time? ... > > This is a good point in cellular context, especially the PMIPv6 case is > very true. > [Tao] Good you share the same view. > > > Based on above, using RA for SLAAC and DHCPv6 for route paramter > configuration is a more effective way. > > Note that I have nothing against DHCPv6 router parameter configuration > work in general (OK to complete it), however, RAs and RFC4191 do have > merits especially in the above example (cellular) [Tao] Besides the exist of 4191, not sure about other merits. > context. Specifically the push model of per-subscriber RAs is attractive. > [Tao] Do you mean the mechanisms of RA offloading? If so, we can discuss it in another thread. > > - Jouni > > > > > > In my view, the discussion is adequate enough to move the draft forward > to version 4 and we shall not continue to stay on the necessity analysis. > > > > Tao Sun > > > > On Sat, Dec 3, 2011 at 3:21 AM, Lorenzo Colitti > wrote: > > On Fri, Dec 2, 2011 at 10:15, Tao Sun wrote: > > I'm not talking about mobile networks specifically here. I think this > particular event (turning off RAs) is more likely that to happen on a wifi > network or an enterprise network. > > As I pointed out in my previous email, WiFi network is already part of > mobile network. China Mobile deployed about more than one hundred of > thousand hotspots (over 1 million WiFi AP). Users use the same smart phone > to visit cellular network and WiFi network. > > > > Ok, so then let's take a look at that use case and see why it requires a > DHCPv6 route option to be defined. I suspect that you can do what you want > using RIO. > > > > _______________________________________________ > > mif mailing list > > mif@ietf.org > > https://www.ietf.org/mailman/listinfo/mif > > --20cf3079ba548ab0e904b370fc53 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Dec 6, 2011 at 8:39 AM, Jouni <jouni.nospam@gmail.c= om> wrote:
Hi,

On Dec 5, 2011, at 9:25 PM, Tao Sun wrote:

>= ; Ok. I reiterate the use cases and the justification of using DHCPv6.
&= gt;
> For the cellular network, I mainly focus on two use cases: 1) A= host is connected to the cellular network and WiFi at the same time. Some = traffic need to go cellular network, others go to WiFi. 2) A mobile host in= the cellular network simultaneously connects to multiple APNs (taking APN1= and APN2 for example) . Some traffics go to APN1, others got to APN2.

These are (at least the example 1) doable using RFC4191 and RAs. = For the latter case how the default router for "default traffic" = gets selected (independent of DHCPv6 or RAs) is a bit of an issue if all in= terfaces (APNs) are equal.
[Tao] The interfaces (APNs)=A0are generally=A0not equal, i.e., APN_IMS= , APN_Internet.
=A0

I can use AAA (or hypothetic= ally even PCC) as my central configuration database..
[Tao] Using AAA, maybe. Using PCC is hypotheses. :-)
=A0

> =A0The justification of adopt DHCPv6 is the foll= owing:
> 1) DHCPv6 is anyway shall be implemented and is suitable for= parameter configuration. This is due to prefix delegation for tethering, n= etwork parameter configuration such as DNS, network server informaiton of I= MS, etc.

It is still optional for 3GPP networks from specs point of view a= s far as I remember. Both RFC3736 and RFC3633 are "Both EPS network el= ements and UE may support".
[Tao] From specs point of view, it is optional. From real implementati= on, IMHO,=A0it will be implemented, e.g., using LTE as backhaul for tetheri= ng is a quite attractive feature.
=A0

> 2) DHCPv6 is more management/operation friendly = due to the central control mechanism.

Compared to AAA based on= what grounds?
[Tao] Using radius with AAA is only used for few enterprise users in= =A0some operator's=A0network.
=A0

> 3) DHCP has been already used for paramter confi= guration, while using RA will cause significant modification and enhancemen= t for network elements and hosts, especially for per-subscriber purpose (e.= g., using VLAN).

In the above (cellular oriented) example, I am not so sure. In ce= llular (3GPP) networks the RAs are already used in per subscriber manner.
=A0
[Tao] You need to update radius protocal and AAA specification in 3GPP= to convey the configuration information. The mandatory RA for prefix assig= nment is supported not long time ago by network elements.=A0Ohter optional = extension of=A0RA such as RIO indeeds new requirement for network elements = and handset.
=A0
=A0

> 4) Using RA to configure the route may cause pot= entially some messy. In 4G cellular network, both GTP and PMIP protocal are= used for mobility management today. In GTP, it is a point-to-point link be= tween mobile host and PGW. However, in PMIP, PGW send /64 prefix to SGW thr= ough PBA. The SGW sends RA to mobile host. If RA is also used for route con= figuration, how SGW obtains the specific route information? how about the c= omplexity due to the large number of SGW as compared with PGW? how the SGW = combine the multiple RA route informatio nreceived from sources in use case= 2 since there is always only one SGW at a time? ...

This is a good point in cellular context, especially the PMIPv6 c= ase is very true.
[Tao] Good you share the same view.

> =A0Based on above, using RA for SLAAC and DHCPv6= for route paramter configuration is a more effective way.

Not= e that I have nothing against DHCPv6 router parameter configuration work in= general (OK to complete it), however, RAs and RFC4191 do have merits espec= ially in the above example (cellular)
[Tao] Besides the exist of 4191, not=A0sure about other merits.
=A0
context. Specifically the push m= odel of per-subscriber RAs is attractive.
=A0
[Tao] Do you mean the mechanisms of RA offloading? If so, we can discu= ss it in another thread.
=A0

- Jo= uni


>
> In my view, the discussion is adequa= te enough to move the draft forward to version 4 and we shall not continue = to stay on the necessity analysis.
>
> Tao Sun
>
> = On Sat, Dec 3, 2011 at 3:21 AM, Lorenzo Colitti <lorenzo@google.com> wrote:
> On Fri, Dec 2, 2011 at 10:15, Tao Sun <hisuntao@gmail.com> wrote:
> I'm not talking abo= ut mobile networks specifically here. I think this particular event (turnin= g off RAs) is more likely that to happen on a wifi network or an enterprise= network.
> As I pointed out in my previous email, WiFi network is already part of= mobile network. China Mobile deployed about more than one hundred of thous= and hotspots (over 1 million WiFi AP). Users use the same smart phone to vi= sit cellular network and WiFi network.
>
> Ok, so then let's take a look at that use case and see why= it requires a DHCPv6 route option to be defined. I suspect that you can do= what you want using RIO.
>
> _______________________________________________
&= gt; mif mailing list
> mif@ietf.org
> https://www.ietf.org/mailman/listinfo/mif


--20cf3079ba548ab0e904b370fc53-- From hisuntao@gmail.com Tue Dec 6 11:09:03 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 35E2421F8B80 for ; Tue, 6 Dec 2011 11:09:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[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 IuCnzH3Pg8GD for ; Tue, 6 Dec 2011 11:09:02 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9538721F8B71 for ; Tue, 6 Dec 2011 11:09:02 -0800 (PST) Received: by vbbez10 with SMTP id ez10so2926299vbb.31 for ; Tue, 06 Dec 2011 11:09:02 -0800 (PST) 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=fPEuXKH26Nfot7v9rdY3GQu4PFX7YvWVMTb/OozC/oY=; b=mcxeJy9yDwlJqoQJzVufBvLoZ3zagu6pXxyN0AC6BLTS1R0VFR3Y3oShx8PhH/6TCq A2W9WQ9dDJ7DXQOk8W4yiiFjtUicAMCjAPV/xGM0Mprbyxcy/G9KI0A5fOXvSTe7cF+8 UBUxi3wZD10g8EjVMWSEniw+fBno3MHSIHgzw= MIME-Version: 1.0 Received: by 10.52.65.102 with SMTP id w6mr8689989vds.129.1323198542130; Tue, 06 Dec 2011 11:09:02 -0800 (PST) Received: by 10.220.194.133 with HTTP; Tue, 6 Dec 2011 11:09:02 -0800 (PST) In-Reply-To: References: <282BBE8A501E1F4DA9C775F964BB21FE3EB78C3C98@GRFMBX704BA020.griffon.local> <916CE6CF87173740BC8A2CE44309696204193417@008-AM1MPN1-053.mgdnok.nokia.com> <4EC512A2.2060509@gmail.com> <890A58CF-8EAD-4F92-9981-9B5AA07EBF00@nominum.com> <4EC63E26.70104@gmail.com> <86163A8F-8628-4F67-BE93-3747F95A2F52@nominum.com> <4ECB6EAE.2010701@gmail.com> <702C34B3-F6B7-4EFB-91D5-8538540534A1@nominum.com> <4ECBE3BE.5070501@gmail.com> <759E821F-B503-4C8D-A79B-5F9A68A3613F@nominum.com> <4ED6A08D.9090703@gmail.com> Date: Wed, 7 Dec 2011 03:09:02 +0800 Message-ID: From: Tao Sun To: Lorenzo Colitti Content-Type: multipart/alternative; boundary=20cf307f3b06122c5604b3712bde Cc: "mif@ietf.org" Subject: Re: [mif] Use cases for draft-ietf-mif-dhcpv6-route-option needed 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, 06 Dec 2011 19:09:03 -0000 --20cf307f3b06122c5604b3712bde Content-Type: text/plain; charset=ISO-8859-1 In 2G/3G, it seems so. However, it seems not feasible for 4G as indicated in 4). Tao On Tue, Dec 6, 2011 at 8:48 AM, Lorenzo Colitti wrote: > On Mon, Dec 5, 2011 at 11:25, Tao Sun wrote: > >> 3) DHCP has been already used for paramter configuration, while using RA >> will cause significant modification and enhancement for network elements >> and hosts, especially for per-subscriber purpose (e.g., using VLAN). >> > > In the 3G scenario you don't need VLANs, as all subscriber interfaces are > separate point-to-point interfaces, each with its own /64, and you're > already provisioning these /64s on a per-subscriber basis. > --20cf307f3b06122c5604b3712bde Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
In 2G/3G, it seems so. However, it seems not feasible for 4G=A0as indi= cated in 4).
=A0
Tao

On Tue, Dec 6, 2011 at 8:48 AM, Lorenzo Colitti = <lorenzo@google.= com> wrote:
On Mon, Dec 5, 2011 at 11:25, Tao Sun &= lt;hisuntao@gmail.c= om> wrote:
3) DHCP has been already used for paramter configuration, while using = RA will cause significant modification and enhancement for network elements= and hosts, especially for per-subscriber purpose (e.g., using VLAN).

In the 3G scenario you don't need VLANs, as all subscriber interfa= ces are separate point-to-point interfaces, each with its own /64, and you&= #39;re already provisioning these /64s on a per-subscriber basis.

--20cf307f3b06122c5604b3712bde-- From lorenzo@google.com Tue Dec 6 11:14:25 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 9E97821F8AA8 for ; Tue, 6 Dec 2011 11:14:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.9 X-Spam-Level: X-Spam-Status: No, score=-102.9 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 h+9Dwxr1Q8WE for ; Tue, 6 Dec 2011 11:14:25 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id EBEA421F8880 for ; Tue, 6 Dec 2011 11:14:24 -0800 (PST) Received: by ggnk5 with SMTP id k5so3405972ggn.31 for ; Tue, 06 Dec 2011 11:14:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=N+wzqiZ3U2QzCTx/2muEoL7EpL7CYW3epSB1PomRm1U=; b=raLEjiXBEA+WUMD9zVqNJAa6xU3GSZyvVu8ysDFg3OOcD9tNlKYM1Wzr/l6Z17EntM IvwKH3oAMSR4cjA4R4og== Received: by 10.236.131.82 with SMTP id l58mr21578176yhi.36.1323198863440; Tue, 06 Dec 2011 11:14:23 -0800 (PST) Received: by 10.236.131.82 with SMTP id l58mr21578138yhi.36.1323198863274; Tue, 06 Dec 2011 11:14:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.150.202.14 with HTTP; Tue, 6 Dec 2011 11:14:01 -0800 (PST) In-Reply-To: References: <282BBE8A501E1F4DA9C775F964BB21FE3EB78C3C98@GRFMBX704BA020.griffon.local> <916CE6CF87173740BC8A2CE44309696204193417@008-AM1MPN1-053.mgdnok.nokia.com> <4EC512A2.2060509@gmail.com> <890A58CF-8EAD-4F92-9981-9B5AA07EBF00@nominum.com> <4EC63E26.70104@gmail.com> <86163A8F-8628-4F67-BE93-3747F95A2F52@nominum.com> <4ECB6EAE.2010701@gmail.com> <702C34B3-F6B7-4EFB-91D5-8538540534A1@nominum.com> <4ECBE3BE.5070501@gmail.com> <759E821F-B503-4C8D-A79B-5F9A68A3613F@nominum.com> <4ED6A08D.9090703@gmail.com> <805C4AB5-9B43-48B5-A54E-B5AAD17B2BD9@gmail.com> From: Lorenzo Colitti Date: Tue, 6 Dec 2011 11:14:01 -0800 Message-ID: To: Tao Sun Content-Type: multipart/alternative; boundary=20cf3011e20336722f04b3713eca X-System-Of-Record: true Cc: "mif@ietf.org" Subject: Re: [mif] Use cases for draft-ietf-mif-dhcpv6-route-option needed 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, 06 Dec 2011 19:14:25 -0000 --20cf3011e20336722f04b3713eca Content-Type: text/plain; charset=ISO-8859-1 On Tue, Dec 6, 2011 at 10:56, Tao Sun wrote: > These are (at least the example 1) doable using RFC4191 and RAs. For the >> latter case how the default router for "default traffic" gets selected >> (independent of DHCPv6 or RAs) is a bit of an issue if all interfaces >> (APNs) are equal. >> > [Tao] The interfaces (APNs) are generally not equal, i.e., APN_IMS, > APN_Internet. > Yes, and each one already has its own RA. Compared to AAA based on what grounds? >> > [Tao] Using radius with AAA is only used for few enterprise users in some > operator's network. > So what entity in the network decides what prefix to assign to a given user when he sets up, say, the Internet PDN? In the above (cellular oriented) example, I am not so sure. In cellular > (3GPP) networks the RAs are already used in per subscriber manner. > > [Tao] You need to update radius protocal and AAA specification in 3GPP to > convey the configuration information. The mandatory RA for prefix > assignment is supported not long time ago by network elements. Ohter > optional extension of RA such as RIO indeeds new requirement for network > elements and handset. > The RADIUS attribute for it already exists, it's called Framed-IPv6-Route: http://tools.ietf.org/html/rfc3162#section-2.5 . The handsets can easily support it if they are based on operating systems that support it. I know Linux does, so Android could use it. Don't know about OS X / iPhone, but on the other hand the iPhone doesn't support IPv6 on the mobile interface yet. --20cf3011e20336722f04b3713eca Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Dec 6, 2011 at 10:56, Tao Sun <hisuntao@gmail.com&g= t; wrote:
These are (at least the example 1) doable using RFC4191 and RAs. Fo= r the latter case how the default router for "default traffic" ge= ts selected (independent of DHCPv6 or RAs) is a bit of an issue if all inte= rfaces (APNs) are equal.
[Tao] The interfaces (APNs)=A0are generally=A0not equal, i.e., A= PN_IMS, APN_Internet.

Yes, and = each one already has its own RA.

Compared to AAA based on what grounds?
[Tao] Using radius with AAA is only used for few enterprise users in=A0some= operator's=A0network.

So w= hat entity in the network decides what prefix to assign to a given user whe= n he sets up, say, the Internet PDN?

<= div class=3D"im">
=A0In the above (cellular oriented) example, I am not so sure. In cell= ular (3GPP) networks the RAs are already used in per subscriber manner.
=A0
[Tao] You need to update radius protocal and AAA specification i= n 3GPP to convey the configuration information. The mandatory RA for prefix= assignment is supported not long time ago by network elements.=A0Ohter opt= ional extension of=A0RA such as RIO indeeds new requirement for network ele= ments and handset.

The RADIUS attribute for it already = exists, it's called Framed-IPv6-Route:=A0http://tools.ietf.org/html/rfc3162#section-2.5= .

The handsets can easily support it if they are based on= operating systems that support it. I know Linux does, so Android could use= it. Don't know about OS X / iPhone, but on the other hand the iPhone d= oesn't support IPv6 on the mobile interface yet.
--20cf3011e20336722f04b3713eca-- From alexandru.petrescu@gmail.com Tue Dec 6 12:34:55 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 C070621F8B74 for ; Tue, 6 Dec 2011 12:34:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.735 X-Spam-Level: X-Spam-Status: No, score=-1.735 tagged_above=-999 required=5 tests=[AWL=1.864, BAYES_00=-2.599, 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 ifs38T886BMj for ; Tue, 6 Dec 2011 12:34:55 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 94EFD21F8669 for ; Tue, 6 Dec 2011 12:34:54 -0800 (PST) Received: by bkbzs8 with SMTP id zs8so163549bkb.31 for ; Tue, 06 Dec 2011 12:34:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=758YmAQi090LFMasvELnRBWXLgupXBO8iYR9ZlhYjWg=; b=FMl2Yyg0/F6MaVpUOtWnrx0sxPugoOzzZrJc+vpLjHbcDliyInAp8hkDcsLlJ3Cxb0 XhQcSHHpZI4qWdi5Q07/piK2q/ddaKIpMt4hcOouYDzGdjT1XriaOLRAO0iL90d7q5/r 9cSRBFC+9moXcwazVtZk7VecTWcV0ime6YNsI= Received: by 10.180.3.37 with SMTP id 5mr19329018wiz.43.1323203693687; Tue, 06 Dec 2011 12:34:53 -0800 (PST) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net. [82.239.213.32]) by mx.google.com with ESMTPS id ep16sm35275237wbb.21.2011.12.06.12.34.51 (version=SSLv3 cipher=OTHER); Tue, 06 Dec 2011 12:34:52 -0800 (PST) Message-ID: <4EDE7C66.500@gmail.com> Date: Tue, 06 Dec 2011 21:34:46 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: mif@ietf.org References: <282BBE8A501E1F4DA9C775F964BB21FE3EB78C3C98@GRFMBX704BA020.griffon.local> <4EC63E26.70104@gmail.com> <86163A8F-8628-4F67-BE93-3747F95A2F52@nominum.com> <4ECB6EAE.2010701@gmail.com> <702C34B3-F6B7-4EFB-91D5-8538540534A1@nominum.com> <4ECBE3BE.5070501@gmail.com> <759E821F-B503-4C8D-A79B-5F9A68A3613F@nominum.com> <4ED6A08D.9090703@gmail.com> <805C4AB5-9B43-48B5-A54E-B5AAD17B2BD9@gmail.com> In-Reply-To: <805C4AB5-9B43-48B5-A54E-B5AAD17B2BD9@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [mif] Use cases for draft-ietf-mif-dhcpv6-route-option needed, vs rfc4191 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, 06 Dec 2011 20:34:55 -0000 Le 06/12/2011 01:39, Jouni a écrit : > Hi, > > On Dec 5, 2011, at 9:25 PM, Tao Sun wrote: > >> Ok. I reiterate the use cases and the justification of using >> DHCPv6. >> >> For the cellular network, I mainly focus on two use cases: 1) A >> host is connected to the cellular network and WiFi at the same >> time. Some traffic need to go cellular network, others go to WiFi. >> 2) A mobile host in the cellular network simultaneously connects >> to multiple APNs (taking APN1 and APN2 for example) . Some >> traffics go to APN1, others got to APN2. > > These are (at least the example 1) doable using RFC4191 and RAs. I think 4191 is desirable if the host is a Host on cellular, not a Router on cellular (tethering IPv6). A pure Router does not consider receiving RAs other than for logging purposes, thus ignoring the potentially present RIO. What is simpler: specify Routers to consider RIO'ed RAs? or specify DHCP extensions to communicate routes? (at least default routes). Additionally, RIO (Route Information Option) does not seem to encode the address of next-hop (it seems left to determine elsewhere, not clear its relationship with the prefix in RIO). The route-option proposal for DHCP seems to tie together explicitely the prefix with the next-hop address, which may have advantages. Alex > For the latter case how the default router for "default traffic" gets > selected (independent of DHCPv6 or RAs) is a bit of an issue if all > interfaces (APNs) are equal. > > I can use AAA (or hypothetically even PCC) as my central > configuration database.. > >> The justification of adopt DHCPv6 is the following: 1) DHCPv6 is >> anyway shall be implemented and is suitable for parameter >> configuration. This is due to prefix delegation for tethering, >> network parameter configuration such as DNS, network server >> informaiton of IMS, etc. > > It is still optional for 3GPP networks from specs point of view as > far as I remember. Both RFC3736 and RFC3633 are "Both EPS network > elements and UE may support". > >> 2) DHCPv6 is more management/operation friendly due to the central >> control mechanism. > > Compared to AAA based on what grounds? > >> 3) DHCP has been already used for paramter configuration, while >> using RA will cause significant modification and enhancement for >> network elements and hosts, especially for per-subscriber purpose >> (e.g., using VLAN). > > In the above (cellular oriented) example, I am not so sure. In > cellular (3GPP) networks the RAs are already used in per subscriber > manner. > >> 4) Using RA to configure the route may cause potentially some >> messy. In 4G cellular network, both GTP and PMIP protocal are used >> for mobility management today. In GTP, it is a point-to-point link >> between mobile host and PGW. However, in PMIP, PGW send /64 prefix >> to SGW through PBA. The SGW sends RA to mobile host. If RA is also >> used for route configuration, how SGW obtains the specific route >> information? how about the complexity due to the large number of >> SGW as compared with PGW? how the SGW combine the multiple RA route >> informatio nreceived from sources in use case 2 since there is >> always only one SGW at a time? ... > > This is a good point in cellular context, especially the PMIPv6 case > is very true. > >> Based on above, using RA for SLAAC and DHCPv6 for route paramter >> configuration is a more effective way. > > Note that I have nothing against DHCPv6 router parameter > configuration work in general (OK to complete it), however, RAs and > RFC4191 do have merits especially in the above example (cellular) > context. Specifically the push model of per-subscriber RAs is > attractive. > > - Jouni > > >> >> In my view, the discussion is adequate enough to move the draft >> forward to version 4 and we shall not continue to stay on the >> necessity analysis. >> >> Tao Sun >> >> On Sat, Dec 3, 2011 at 3:21 AM, Lorenzo Colitti >> wrote: On Fri, Dec 2, 2011 at 10:15, Tao Sun >> wrote: I'm not talking about mobile networks specifically here. I >> think this particular event (turning off RAs) is more likely that >> to happen on a wifi network or an enterprise network. As I pointed >> out in my previous email, WiFi network is already part of mobile >> network. China Mobile deployed about more than one hundred of >> thousand hotspots (over 1 million WiFi AP). Users use the same >> smart phone to visit cellular network and WiFi network. >> >> Ok, so then let's take a look at that use case and see why it >> requires a DHCPv6 route option to be defined. I suspect that you >> can do what you want using RIO. >> >> _______________________________________________ mif mailing list >> mif@ietf.org https://www.ietf.org/mailman/listinfo/mif > > _______________________________________________ mif mailing list > mif@ietf.org https://www.ietf.org/mailman/listinfo/mif From Ted.Lemon@nominum.com Tue Dec 6 12:38:37 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 6D36621F853E for ; Tue, 6 Dec 2011 12:38:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.528 X-Spam-Level: X-Spam-Status: No, score=-106.528 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 7BRE9aWBYc+2 for ; Tue, 6 Dec 2011 12:38:36 -0800 (PST) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id BE42121F84FC for ; Tue, 6 Dec 2011 12:38:33 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKTt59Sf6d3gtaIWbM8y6sC0tWQ9RjtOdt@postini.com; Tue, 06 Dec 2011 12:38:33 PST 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 EBB911B8228 for ; Tue, 6 Dec 2011 12:38:32 -0800 (PST) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (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 E497B190052; Tue, 6 Dec 2011 12:38:32 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.01.0339.001; Tue, 6 Dec 2011 12:38:33 -0800 From: Ted Lemon To: Alexandru Petrescu Thread-Topic: [mif] Use cases for draft-ietf-mif-dhcpv6-route-option needed, vs rfc4191 Thread-Index: AQHMtFadz/MebXd+qkOLeYw7GpqN2pXPy38A Date: Tue, 6 Dec 2011 20:38:32 +0000 Message-ID: References: <282BBE8A501E1F4DA9C775F964BB21FE3EB78C3C98@GRFMBX704BA020.griffon.local> <4EC63E26.70104@gmail.com> <86163A8F-8628-4F67-BE93-3747F95A2F52@nominum.com> <4ECB6EAE.2010701@gmail.com> <702C34B3-F6B7-4EFB-91D5-8538540534A1@nominum.com> <4ECBE3BE.5070501@gmail.com> <759E821F-B503-4C8D-A79B-5F9A68A3613F@nominum.com> <4ED6A08D.9090703@gmail.com> <805C4AB5-9B43-48B5-A54E-B5AAD17B2BD9@gmail.com> <4EDE7C66.500@gmail.com> In-Reply-To: <4EDE7C66.500@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_ED06D3DE7AA54FA5BB1899AF54118CB2nominumcom_" MIME-Version: 1.0 Cc: "" Subject: Re: [mif] Use cases for draft-ietf-mif-dhcpv6-route-option needed, vs rfc4191 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, 06 Dec 2011 20:38:37 -0000 --_000_ED06D3DE7AA54FA5BB1899AF54118CB2nominumcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Dec 6, 2011, at 3:34 PM, Alexandru Petrescu wrote: What is simpler: specify Routers to consider RIO'ed RAs? or specify DHCP extensions to communicate routes? (at least default routes). Of course, the answer to this question will vary depending on whether you a= re a provider operating routers, or a vendor implementing host stacks. Wh= ich is why we are having this discussion. Previous discussions really onl= y considered the network operator case. It's pretty clear that from the host implementation side, RIO is easier tha= n DHCP, because the host already supports it. --_000_ED06D3DE7AA54FA5BB1899AF54118CB2nominumcom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <5CADE13DEFA7784EA428BE57CDF00871@nominum.com> Content-Transfer-Encoding: quoted-printable
On Dec 6, 2011, at 3:34 PM, Alexandru Petrescu wrote:
What is simpler: specify Routers to consider RIO'ed RAs?  or specify
DHCP extensions to communicate routes? (at least default routes).

Of course, the answer to this question will vary depending on whether = you are a provider operating routers, or a vendor implementing host stacks.=   Which is why we are having this discussion.   Previous discuss= ions really only considered the network operator case.

It's pretty clear that from the host implementation side, RIO is easie= r than DHCP, because the host already supports it.

--_000_ED06D3DE7AA54FA5BB1899AF54118CB2nominumcom_-- From alexandru.petrescu@gmail.com Tue Dec 6 12:40:56 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 B841021F8C42 for ; Tue, 6 Dec 2011 12:40:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.356 X-Spam-Level: X-Spam-Status: No, score=-2.356 tagged_above=-999 required=5 tests=[AWL=1.243, BAYES_00=-2.599, 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 USoTqIiQmCsa for ; Tue, 6 Dec 2011 12:40:56 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 40EC321F8511 for ; Tue, 6 Dec 2011 12:40:55 -0800 (PST) Received: by bkbzs8 with SMTP id zs8so170762bkb.31 for ; Tue, 06 Dec 2011 12:40:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=7EZjJ4r/D80YIhUrvHvWx6Xm70BKTG1/d+VeqOacPZU=; b=cvf3n0Q2RzPFgV7sAiYDlfRoQ25/WLORH4I+lSR3TPRrDDwCJ3SIxgESRD2d0y0m4/ ONTPwe6eaWwgPVnXzH7+3yNUIKKXkQRU11SIAMtlXXimFUo7v82uKXoWFPvmL7QKOB7w cPUgxcWmAdSEBYWtSz2Bg624BNk6ILANbGkps= Received: by 10.181.11.226 with SMTP id el2mr19127205wid.64.1323204054133; Tue, 06 Dec 2011 12:40:54 -0800 (PST) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net. [82.239.213.32]) by mx.google.com with ESMTPS id gg1sm35307013wbb.17.2011.12.06.12.40.52 (version=SSLv3 cipher=OTHER); Tue, 06 Dec 2011 12:40:53 -0800 (PST) Message-ID: <4EDE7DCF.1080107@gmail.com> Date: Tue, 06 Dec 2011 21:40:47 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Lorenzo Colitti References: <282BBE8A501E1F4DA9C775F964BB21FE3EB78C3C98@GRFMBX704BA020.griffon.local> <916CE6CF87173740BC8A2CE44309696204193417@008-AM1MPN1-053.mgdnok.nokia.com> <4EC512A2.2060509@gmail.com> <890A58CF-8EAD-4F92-9981-9B5AA07EBF00@nominum.com> <4EC63E26.70104@gmail.com> <86163A8F-8628-4F67-BE93-3747F95A2F52@nominum.com> <4ECB6EAE.2010701@gmail.com> <702C34B3-F6B7-4EFB-91D5-8538540534A1@nominum.com> <4ECBE3BE.5070501@gmail.com> <759E821F-B503-4C8D-A79B-5F9A68A3613F@nominum.com> <7C1F8DA5-357F-4403-BE0D-E72D425B71C9@gmail.com> <4ED7CA1C.1080606@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: mif@ietf.org Subject: Re: [mif] Use cases for draft-ietf-mif-dhcpv6-route-option needed 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, 06 Dec 2011 20:40:56 -0000 Le 01/12/2011 20:22, Lorenzo Colitti a écrit : > On Thu, Dec 1, 2011 at 10:40, Alexandru Petrescu > > wrote: > > Le 01/12/2011 18:24, Tao Sun a écrit : > > Hi Jouni, Thanks for the clarification. That is ture GGSN/PGW is not > mandate to do relay. "May" instead of "shall" is used to describe > GGSN/PGW's action. The only mandate is to use RA to obtain /64 > prefix. > > > And that mandate is not sufficient when the UE is actually a Router > ("mobile hotspot", "tethering"). For these cases, DHCPv6-PD is > suggested by 3GPP specs. Thus, the 3GPP specs assume that a UE-Router > (new term for this conversation) runs both RA _and_ DHCP. But 3GPP > specs overlook the fact that an UE-Router would't use RA to > auto-configure an address (stateless autoconf is only for Hosts). > > > That's not true - RFC 6204 says that an IPv6 CE router can use autoconf > to create an address. Is it possible to make RFC6204 IPv6 CE router to be an arbitrary Router, like a handset device with cellular and wifi doing tethering, or like an OBU with many cellular interfaces, or like sattelite routers? Could all these be IPv6 CE Routers? (CE: Customer Equipment, DSL, BBF, I believe). > I think it's reasonable to say that if you were to > implement tethering using DHCPv6 PD, you would follow RFC 6204. Hm, that seems good guide for this, and I wonder why is it INFORMATIONAL and not on the Standards Track? Alex > > Hence 3GPP specs could consider that _only_ DHCP should should be > used by DHCPv6. In this sense, the above only mandate ("use RA to > obtain /64 prefix") could be dropped altogether. > > > See what I mean? We're already talking about not using RAs at all any > more, and we don't even have a DHCPv6 route option yet... From brian.e.carpenter@gmail.com Tue Dec 6 12:51:13 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 08BCA21F8C4D for ; Tue, 6 Dec 2011 12:51:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.585 X-Spam-Level: X-Spam-Status: No, score=-103.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, 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 yQ1Byl0JJLD5 for ; Tue, 6 Dec 2011 12:51:11 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9388221F8C50 for ; Tue, 6 Dec 2011 12:51:11 -0800 (PST) Received: by iaek3 with SMTP id k3so9305682iae.31 for ; Tue, 06 Dec 2011 12:51:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=GWr6WYnXxbNmrkrQJMDv18o1qKC+Fj7jdq9ZkUcL6fw=; b=rexNz9Q8uBWo6MPe/QERttzy7zoe16Dq7OiDBjOteMOBOkCZrD0xXixEK1tlWUTRau 7q7fAu+VknjRjG/JslSCvJIBrw2sBcxK0DDiW2HFidICX9yYDUNhB69egCuQaM4+SnIH pFHipLYbNKL0RCAAcKjpcZzVjkBASSBdPwf9E= Received: by 10.43.49.66 with SMTP id uz2mr6785895icb.9.1323204666931; Tue, 06 Dec 2011 12:51:06 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz. [130.216.38.124]) by mx.google.com with ESMTPS id zs7sm10833089igb.0.2011.12.06.12.51.03 (version=SSLv3 cipher=OTHER); Tue, 06 Dec 2011 12:51:05 -0800 (PST) Message-ID: <4EDE8032.4050205@gmail.com> Date: Wed, 07 Dec 2011 09:50:58 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Jouni References: <282BBE8A501E1F4DA9C775F964BB21FE3EB78C3C98@GRFMBX704BA020.griffon.local> <916CE6CF87173740BC8A2CE44309696204193417@008-AM1MPN1-053.mgdnok.nokia.com> <4EC512A2.2060509@gmail.com> <890A58CF-8EAD-4F92-9981-9B5AA07EBF00@nominum.com> <4EC63E26.70104@gmail.com> <86163A8F-8628-4F67-BE93-3747F95A2F52@nominum.com> <4ECB6EAE.2010701@gmail.com> <702C34B3-F6B7-4EFB-91D5-8538540534A1@nominum.com> <4ECBE3BE.5070501@gmail.com> <759E821F-B503-4C8D-A79B-5F9A68A3613F@nominum.com> <4ED6A08D.9090703@gmail.com> <9ACC70F6-6D21-4981-A3CE-BA3469658F62@gmail.com> <4ED7F2C0.4040902@gmail.com> <5AB3B2FC-8914-42AB-9173-8172D926462F@gmail.com> <4ED94DED.5070108@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "mif@ietf.org" Subject: Re: [mif] Use cases for draft-ietf-mif-dhcpv6-route-option needed 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, 06 Dec 2011 20:51:13 -0000 Jouni, I found some time to look quickly at this spec, and I see that indeed prefix delegation via AAA *or* DHCPv6 is supported, but there is no mention of RFC 4191 (RIO). Regular use of RA is of course covered. You said >> It is quite common >> feature e.g. in 3GPP defined networks that the per subscriber prefix for RA >> comes off AAA. But that doesn't explain how prefix delegation would be managed with RAs, or how RIOs would be generated. Regards Brian Carpenter On 2011-12-03 11:26, Jouni wrote: > http://www.3gpp.org/ftp/Specs/html-info/29061.htm > > - Jouni > > On Dec 3, 2011, at 12:15 AM, Brian E Carpenter wrote: > >> Where can I find TS29.061? >> >> Brian >> >> On 2011-12-03 10:55, Jouni wrote: >>> On Dec 2, 2011, at 8:49 PM, Tao Sun wrote: >>> >>>> Latest yesterday I tweaked with such implementation. It is quite common feature e.g. in 3GPP defined networks that the per subscriber prefix for RA comes off AAA. It has been there in specs for say 9 years and deployed at least several years. Also the per subscriber delegated prefixes may come from AAA.. like the rest of the end host configuration information. >>>> >>>> [Tao] Could you be more specific which spec you are referring to? Unfortunately, it is not ture that such implementation has >>> TS29.061.. you can trace it back about ~9 for RADIUS interface to provide prefix for a RA. >>> >>> - Jouni >>> >>> >>>> "deployed at least several years". Few vandor implement their network elements with good support of RA, not mention of the per >>>> subscriber prefix from AAA or the RIO. The basic RA works in new network element on 4G PDN gateways in recent one year or so . >>> >>> > > From jouni.nospam@gmail.com Tue Dec 6 13:17:42 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 F0CE911E809F for ; Tue, 6 Dec 2011 13:17:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.539 X-Spam-Level: X-Spam-Status: No, score=-3.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, 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 9U0RoYhQ-h5c for ; Tue, 6 Dec 2011 13:17:42 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id E72DF11E809C for ; Tue, 6 Dec 2011 13:17:41 -0800 (PST) Received: by laap9 with SMTP id p9so531420laa.31 for ; Tue, 06 Dec 2011 13:17:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=9Qjm6nwB+MTuDFRReG7BnUELPiTPxmkrOAn2ntIN+I8=; b=T8EDHeR3i0DuQ7ENuKod9r4i8kpmqhknyjsABN5uPP0+VN9MF8eBHfwHfhF9H96Oiy ybnKtnCSJb/jKo/Tu/HnQ1Sskpx0lhGN+2ARh6G8Mys2OeYtvSodJ/tF3xfp6dpi+vIE 9PeaJAHHTRyifT4OvNBN4ROvEKcf3jM/j/R5Y= Received: by 10.152.104.1 with SMTP id ga1mr9951575lab.40.1323206259486; Tue, 06 Dec 2011 13:17:39 -0800 (PST) Received: from [188.117.15.109] ([188.117.15.109]) by mx.google.com with ESMTPS id pc8sm22076369lab.8.2011.12.06.13.17.37 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 06 Dec 2011 13:17:38 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Jouni In-Reply-To: <4EDE8032.4050205@gmail.com> Date: Tue, 6 Dec 2011 23:17:35 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8A581BC7-5525-457D-938E-086D1ABB2416@gmail.com> References: <282BBE8A501E1F4DA9C775F964BB21FE3EB78C3C98@GRFMBX704BA020.griffon.local> <916CE6CF87173740BC8A2CE44309696204193417@008-AM1MPN1-053.mgdnok.nokia.com> <4EC512A2.2060509@gmail.com> <890A58CF-8EAD-4F92-9981-9B5AA07EBF00@nominum.com> <4EC63E26.70104@gmail.com> <86163A8F-8628-4F67-BE93-3747F95A2F52@nominum.com> <4ECB6EAE.2010701@gmail.com> <702C34B3-F6B7-4EFB-91D5-8538540534A1@nominum.com> <4ECBE3BE.5070501@gmail.com> <759E821F-B503-4C8D-A79B-5F9A68A3613F@nominum.com> <4ED6A08D.9090703@gmail.com> <9ACC70F6-6D21-4981-A3CE-BA3469658F62@gmail.com> <4ED7F2C0.4040902@gmail.com> <5AB3B2FC-8914-42AB-9173-8172D926462F@gmail.com> <4ED94DED.5070108@gmail.com> <4EDE8032.4050205@gm ail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1251.1) Cc: "mif@ietf.org" Subject: Re: [mif] Use cases for draft-ietf-mif-dhcpv6-route-option needed 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, 06 Dec 2011 21:17:43 -0000 Brian, On Dec 6, 2011, at 10:50 PM, Brian E Carpenter wrote: > Jouni, >=20 > I found some time to look quickly at this spec, and I see that indeed > prefix delegation via AAA *or* DHCPv6 is supported, but there is no = mention > of RFC 4191 (RIO). Regular use of RA is of course covered. >=20 > You said >=20 >>> It is quite common >>> feature e.g. in 3GPP defined networks that the per subscriber prefix = for RA >>> comes off AAA.=20 >=20 > But that doesn't explain how prefix delegation would be managed with = RAs, or how > RIOs would be generated. Please, do not put words in my mouth. Did I claim PD would work or be managed with RA? No. Per-subscriber = prefix for RAs is for SLAAC purposes as you very well know. Did I claim 29.061 carries more specific routes for RIOs? No. Did I claim RFC4191 is even supported by 3GPP system? No. A GGSN/PGW = implementation *can* use RFC4191 and put RIOs in RAs if it wishes. The = system specification does not prohibit doing that. A "pedantic" 3GPP UE = would then just ignore those options. If your DHCPv6 server happens to be in GGSN/PGW, you can configure the = delegated prefix using 29.061 AAA profile and Delegated-IPv6-Prefix = attribute - as a one option. - Jouni >=20 > Regards > Brian Carpenter >=20 >=20 > On 2011-12-03 11:26, Jouni wrote: >> http://www.3gpp.org/ftp/Specs/html-info/29061.htm=20 >>=20 >> - Jouni >>=20 >> On Dec 3, 2011, at 12:15 AM, Brian E Carpenter wrote: >>=20 >>> Where can I find TS29.061? >>>=20 >>> Brian >>>=20 >>> On 2011-12-03 10:55, Jouni wrote: >>>> On Dec 2, 2011, at 8:49 PM, Tao Sun wrote: >>>>=20 >>>>> Latest yesterday I tweaked with such implementation. It is quite = common feature e.g. in 3GPP defined networks that the per subscriber = prefix for RA comes off AAA. It has been there in specs for say 9 years = and deployed at least several years. Also the per subscriber delegated = prefixes may come from AAA.. like the rest of the end host configuration = information. >>>>>=20 >>>>> [Tao] Could you be more specific which spec you are referring to? = Unfortunately, it is not ture that such implementation has >>>> TS29.061.. you can trace it back about ~9 for RADIUS interface to = provide prefix for a RA. >>>>=20 >>>> - Jouni >>>>=20 >>>>=20 >>>>> "deployed at least several years". Few vandor implement their = network elements with good support of RA, not mention of the per >>>>> subscriber prefix from AAA or the RIO. The basic RA works in new = network element on 4G PDN gateways in recent one year or so .=20 >>>>=20 >>>>=20 >>=20 >>=20 From brian.e.carpenter@gmail.com Tue Dec 6 13:34:13 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 E415721F8BA2 for ; Tue, 6 Dec 2011 13:34:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.586 X-Spam-Level: X-Spam-Status: No, score=-103.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, 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 Mt979IoDb0i7 for ; Tue, 6 Dec 2011 13:34:13 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id E2FEC21F8B83 for ; Tue, 6 Dec 2011 13:34:12 -0800 (PST) Received: by iaek3 with SMTP id k3so9357206iae.31 for ; Tue, 06 Dec 2011 13:34:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=+K+d8WVYn4MH5mq8boDTGI3U/U3ssldFfDlXPRYXHJw=; b=u15aTclkVyZSGsyJXx8NsYaJZTpnBHU/AGwCZRSzSC5b9YNziBANLGy/Cb1bnVoouf j1axF6zAr3bIvAjF8mNzD2f6Hnx8NIYdWN4bUFYX56HgI8bGm8ijZYtdzFPgxFl5ZHdr yECNXx9miUKor121WEJngVSeGCoLXkFyhDtdY= Received: by 10.231.41.69 with SMTP id n5mr3840470ibe.92.1323207248052; Tue, 06 Dec 2011 13:34:08 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz. [130.216.38.124]) by mx.google.com with ESMTPS id zs7sm11026550igb.0.2011.12.06.13.34.04 (version=SSLv3 cipher=OTHER); Tue, 06 Dec 2011 13:34:06 -0800 (PST) Message-ID: <4EDE8A44.1040209@gmail.com> Date: Wed, 07 Dec 2011 10:33:56 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Jouni References: <282BBE8A501E1F4DA9C775F964BB21FE3EB78C3C98@GRFMBX704BA020.griffon.local> <4EC512A2.2060509@gmail.com> <890A58CF-8EAD-4F92-9981-9B5AA07EBF00@nominum.com> <4EC63E26.70104@gmail.com> <86163A8F-8628-4F67-BE93-3747F95A2F52@nominum.com> <4ECB6EAE.2010701@gmail.com> <702C34B3-F6B7-4EFB-91D5-8538540534A1@nominum.com> <4ECBE3BE.5070501@gmail.com> <759E821F-B503-4C8D-A79B-5F9A68A3613F@nominum.com> <4ED6A08D.9090703@gmail.com> <9ACC70F6-6D21-4981-A3CE-BA3469658F62@gmail.com> <4ED7F2C0.4040902@gmail.com> <5AB3B2FC-8914-42AB-9173-8172D926462F@gmail.com> <4ED94DED.5070108@gmail.com> <4EDE8032.4050205@gmail.com> <8A581BC7-5525-457D-938E-086D1ABB2416@gmail.com> In-Reply-To: <8A581BC7-5525-457D-938E-086D1ABB2416@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "mif@ietf.org" Subject: Re: [mif] Use cases for draft-ietf-mif-dhcpv6-route-option needed 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, 06 Dec 2011 21:34:14 -0000 Jouni, On 2011-12-07 10:17, Jouni wrote: > Brian, > > On Dec 6, 2011, at 10:50 PM, Brian E Carpenter wrote: > >> Jouni, >> >> I found some time to look quickly at this spec, and I see that indeed >> prefix delegation via AAA *or* DHCPv6 is supported, but there is no mention >> of RFC 4191 (RIO). Regular use of RA is of course covered. >> >> You said >> >>>> It is quite common >>>> feature e.g. in 3GPP defined networks that the per subscriber prefix for RA >>>> comes off AAA. >> But that doesn't explain how prefix delegation would be managed with RAs, or how >> RIOs would be generated. > > Please, do not put words in my mouth. I didn't mean to do that at all! I was just trying to state the problem. I'm sorry if it appeared otherwise. > Did I claim PD would work or be managed with RA? No. Per-subscriber prefix for RAs is for SLAAC purposes as you very well know. > Did I claim 29.061 carries more specific routes for RIOs? No. > Did I claim RFC4191 is even supported by 3GPP system? No. A GGSN/PGW implementation *can* use RFC4191 and put RIOs in RAs if it wishes. The system specification does not prohibit doing that. A "pedantic" 3GPP UE would then just ignore those options. We agree; all of those things appear to be unspecified. > If your DHCPv6 server happens to be in GGSN/PGW, you can configure the delegated prefix using 29.061 AAA profile and Delegated-IPv6-Prefix attribute - as a one option. Indeed. What I don't see anywhere is a document describing how to create such a stateful-server model using RAs. I think that's why this thread exists. My understanding has always been that the strategy was to keep RA as a simple model without rich extensibility, and to use DHCPv6 for more complex scenarios. So the judgment to make here is whether all MIF scenarios (and all HOMENET scenarios) are complex in that sense. Brian > - Jouni > > >> Regards >> Brian Carpenter >> >> >> On 2011-12-03 11:26, Jouni wrote: >>> http://www.3gpp.org/ftp/Specs/html-info/29061.htm >>> >>> - Jouni >>> >>> On Dec 3, 2011, at 12:15 AM, Brian E Carpenter wrote: >>> >>>> Where can I find TS29.061? >>>> >>>> Brian >>>> >>>> On 2011-12-03 10:55, Jouni wrote: >>>>> On Dec 2, 2011, at 8:49 PM, Tao Sun wrote: >>>>> >>>>>> Latest yesterday I tweaked with such implementation. It is quite common feature e.g. in 3GPP defined networks that the per subscriber prefix for RA comes off AAA. It has been there in specs for say 9 years and deployed at least several years. Also the per subscriber delegated prefixes may come from AAA.. like the rest of the end host configuration information. >>>>>> >>>>>> [Tao] Could you be more specific which spec you are referring to? Unfortunately, it is not ture that such implementation has >>>>> TS29.061.. you can trace it back about ~9 for RADIUS interface to provide prefix for a RA. >>>>> >>>>> - Jouni >>>>> >>>>> >>>>>> "deployed at least several years". Few vandor implement their network elements with good support of RA, not mention of the per >>>>>> subscriber prefix from AAA or the RIO. The basic RA works in new network element on 4G PDN gateways in recent one year or so . >>>>> >>> > > From jouni.nospam@gmail.com Tue Dec 6 14:18: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 532DD21F8545 for ; Tue, 6 Dec 2011 14:18:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.549 X-Spam-Level: X-Spam-Status: No, score=-3.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, 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 XaNAXMdOA200 for ; Tue, 6 Dec 2011 14:18:38 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 287CC21F8548 for ; Tue, 6 Dec 2011 14:18:37 -0800 (PST) Received: by laap9 with SMTP id p9so552876laa.31 for ; Tue, 06 Dec 2011 14:18:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=bdVtyPxteaOdAvmGB9KMkfZhXYWtCFfYs8I5+AFydJM=; b=qrs8oY5kzCJkwyf5qC81aTQDW6Euy/TDZdG3bE8i3WH4zP24YenGv8FjQCFGLwL7B9 fnSXBE3XSLRkA8quMxy178vYVIpoAIyCWd7aD2uebjn23zv0C3CmnEqpM+HOCgd/D8Ik +beJlf/L8B8urJ/oQ2Y868L8lhStaA27xs3Hg= Received: by 10.152.104.47 with SMTP id gb15mr10407098lab.9.1323209917141; Tue, 06 Dec 2011 14:18:37 -0800 (PST) Received: from [188.117.15.109] ([188.117.15.109]) by mx.google.com with ESMTPS id me18sm22197658lab.10.2011.12.06.14.18.35 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 06 Dec 2011 14:18:36 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Jouni In-Reply-To: Date: Wed, 7 Dec 2011 00:18:33 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6F7A1573-459F-4EB5-A353-33089E3DFF76@gmail.com> References: <282BBE8A501E1F4DA9C775F964BB21FE3EB78C3C98@GRFMBX704BA020.griffon.local> <916CE6CF87173740BC8A2CE44309696204193417@008-AM1MPN1-053.mgdnok.nokia.com> <4EC512A2.2060509@gmail.com> <890A58CF-8EAD-4F92-9981-9B5AA07EBF00@nominum.com> <4EC63E26.70104@gmail.com> <86163A8F-8628-4F67-BE93-3747F95A2F52@nominum.com> <4ECB6EAE.2010701@gmail.com> <702C34B3-F6B7-4EFB-91D5-8538540534A1@nominum.com> <4ECBE3BE.5070501@gmail.com> <759E821F-B503-4C8D-A79B-5F9A68A3613F@nominum.com> <4ED6A08D.9090703@gmail.com> <805C4AB5-9B43-48B5-A54E-B5AAD17B2BD9@gmail.com> To: Tao Sun X-Mailer: Apple Mail (2.1251.1) Cc: "mif@ietf.org" Subject: Re: [mif] Use cases for draft-ietf-mif-dhcpv6-route-option needed 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, 06 Dec 2011 22:18:39 -0000 Hi again, On Dec 6, 2011, at 8:56 PM, Tao Sun wrote: > On Tue, Dec 6, 2011 at 8:39 AM, Jouni wrote: > Hi, >=20 > On Dec 5, 2011, at 9:25 PM, Tao Sun wrote: >=20 > > Ok. I reiterate the use cases and the justification of using DHCPv6. > > > > For the cellular network, I mainly focus on two use cases: 1) A host = is connected to the cellular network and WiFi at the same time. Some = traffic need to go cellular network, others go to WiFi. 2) A mobile host = in the cellular network simultaneously connects to multiple APNs (taking = APN1 and APN2 for example) . Some traffics go to APN1, others got to = APN2. >=20 > These are (at least the example 1) doable using RFC4191 and RAs. For = the latter case how the default router for "default traffic" gets = selected (independent of DHCPv6 or RAs) is a bit of an issue if all = interfaces (APNs) are equal. > [Tao] The interfaces (APNs) are generally not equal, i.e., APN_IMS, = APN_Internet. Afair, there is no information element in bearer setup signaling to = state a certain APN, in case of multiple APNs, should be used as the = default gateway beyond what RFC3484 does. If there is such e.g. in NAS = signaling, let me know, and I'll stand corrected. I would actually be = happy to know if there is one.. [snip] > > The justification of adopt DHCPv6 is the following: > > 1) DHCPv6 is anyway shall be implemented and is suitable for = parameter configuration. This is due to prefix delegation for tethering, = network parameter configuration such as DNS, network server informaiton = of IMS, etc. >=20 > It is still optional for 3GPP networks from specs point of view as far = as I remember. Both RFC3736 and RFC3633 are "Both EPS network elements = and UE may support". > [Tao] =46rom specs point of view, it is optional. =46rom real = implementation, IMHO, it will be implemented, e.g., using LTE as = backhaul for tethering is a quite attractive feature. As I wrote above "from specs point of view".. > > 2) DHCPv6 is more management/operation friendly due to the central = control mechanism. >=20 > Compared to AAA based on what grounds? > [Tao] Using radius with AAA is only used for few enterprise users in = some operator's network. I would say that AAA footprint in current cellular networks as a = subscriber management entity is far more common than DHCPv6. > > 3) DHCP has been already used for paramter configuration, while = using RA will cause significant modification and enhancement for network = elements and hosts, especially for per-subscriber purpose (e.g., using = VLAN). >=20 > In the above (cellular oriented) example, I am not so sure. In = cellular (3GPP) networks the RAs are already used in per subscriber = manner. > =20 > [Tao] You need to update radius protocal and AAA specification in 3GPP = to convey the configuration information. The mandatory RA=20 > for prefix assignment is supported not long time ago by network = elements. Ohter optional extension of RA such as RIO indeeds new = requirement for network elements and handset. Framed-ipv6-prefix for SLAAC purposes has been in specs ~9 years. And it = has been implemented. The DHCP I-D in question here is not even a = standard yet as a comparison. Currently RFC4191 is not even optional in 3GPP system and for RIOs there = is currently no support in 29.061 RADIUS or Diameter profile - these are = known facts. So far there just has not been use case for RFC4191 in 3GPP = context. However, nothing prohibits implementing or using one. [snip] > > Based on above, using RA for SLAAC and DHCPv6 for route paramter = configuration is a more effective way. >=20 > Note that I have nothing against DHCPv6 router parameter configuration = work in general (OK to complete it), however, RAs and RFC4191 do have = merits especially in the above example (cellular) > [Tao] Besides the exist of 4191, not sure about other merits. > =20 > context. Specifically the push model of per-subscriber RAs is = attractive. > =20 > [Tao] Do you mean the mechanisms of RA offloading? If so, we can = discuss it in another thread. That's a side effect of what you can do with RFC4191. The nice feature = is as stated above the "push model of per-subscriber RAs" Anyway, I think I have said what I have to say on this topic.. one can = sense slight pro AAA & RA bias from my side in cellular context ;) = Still, nothing against draft-ietf-mif-dhcpv6-route-optio in general. I = believe folks find multiple uses for it. - JOuni From lorenzo@google.com Tue Dec 6 17:15: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 E2E8E11E808C for ; Tue, 6 Dec 2011 17:15:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.902 X-Spam-Level: X-Spam-Status: No, score=-102.902 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 u9sXGYQMyHdp for ; Tue, 6 Dec 2011 17:15:39 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0C99311E8082 for ; Tue, 6 Dec 2011 17:15:38 -0800 (PST) Received: by ggnk5 with SMTP id k5so30617ggn.31 for ; Tue, 06 Dec 2011 17:15:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=nExMHNmd4WBcn/De48dwyBeUbdMYkISNaArnPNJf9B0=; b=tsKtCCMKG1SlSEkW8gDei8HRMl5gqMNStj8ojm2Fy8ZlLLzl31dBGv3Ej4Jh6Mrhua N1XOFrfTCbYY0mOSguSA== Received: by 10.182.49.1 with SMTP id q1mr3195724obn.48.1323220538521; Tue, 06 Dec 2011 17:15:38 -0800 (PST) Received: by 10.182.49.1 with SMTP id q1mr3195718obn.48.1323220538398; Tue, 06 Dec 2011 17:15:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.121.36 with HTTP; Tue, 6 Dec 2011 17:15:17 -0800 (PST) In-Reply-To: <4EDE7C66.500@gmail.com> References: <282BBE8A501E1F4DA9C775F964BB21FE3EB78C3C98@GRFMBX704BA020.griffon.local> <4EC63E26.70104@gmail.com> <86163A8F-8628-4F67-BE93-3747F95A2F52@nominum.com> <4ECB6EAE.2010701@gmail.com> <702C34B3-F6B7-4EFB-91D5-8538540534A1@nominum.com> <4ECBE3BE.5070501@gmail.com> <759E821F-B503-4C8D-A79B-5F9A68A3613F@nominum.com> <4ED6A08D.9090703@gmail.com> <805C4AB5-9B43-48B5-A54E-B5AAD17B2BD9@gmail.com> <4EDE7C66.500@gmail.com> From: Lorenzo Colitti Date: Tue, 6 Dec 2011 17:15:17 -0800 Message-ID: To: Alexandru Petrescu Content-Type: multipart/alternative; boundary=f46d0447850b26996604b3764a80 X-System-Of-Record: true Cc: mif@ietf.org Subject: Re: [mif] Use cases for draft-ietf-mif-dhcpv6-route-option needed, vs rfc4191 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, 07 Dec 2011 01:15:40 -0000 --f46d0447850b26996604b3764a80 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Dec 6, 2011 at 12:34, Alexandru Petrescu < alexandru.petrescu@gmail.com> wrote: > I think 4191 is desirable if the host is a Host on cellular, not a > Router on cellular (tethering IPv6). A pure Router does not consider > receiving RAs other than for logging purposes, thus ignoring the > potentially present RIO. > IPv6 CE routers already listen to RAs and use them for routing information (see RFC 6204). There's no reason a phone can't do the same. > Additionally, RIO (Route Information Option) does not seem to encode > the address of next-hop (it seems left to determine elsewhere, not clear > its relationship with the prefix in RIO). The next-hop is the router that sent you the RA. This is good because it implies fate-sharing - if the router goes away or is not capable of carrying your packets any more, then the RA goes away as well. If you want to send traffic to a specific prefix through another router on the link, then that router must send the RA itself. It doesn't have to announce itself as a default router if it doesn't want to be - it can just carry traffic to that prefix. --f46d0447850b26996604b3764a80 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Dec 6, 2011 at 12:34, Alexandru Petrescu= <alex= andru.petrescu@gmail.com> wrote:
I think 4191 is desirable if the host is a Host on cellular, not a
Router on cellular (tethering IPv6). =A0A pure Router does not consider
receiving RAs other than for logging purposes, thus ignoring the
potentially present RIO.

IPv6 CE router= s already listen to RAs and use them for routing information (see RFC 6204)= . There's no reason a phone can't do the same.
=A0
Additionally, RIO (Route Information Option= ) does not seem to encode the=A0address of next-hop (it seems left to deter= mine elsewhere, not clear its=A0relationship with the prefix in RIO).

The next-hop is the router that sent you the RA. This i= s good because it implies fate-sharing - if the router goes away or is not = capable of carrying your packets any more, then the RA goes away as well.

If you want to send traffic to a specific prefix throug= h another router on the link, then that router must send the RA itself. It = doesn't have to announce itself as a default router if it doesn't w= ant to be - it can just carry traffic to that prefix.
--f46d0447850b26996604b3764a80-- From alexandru.petrescu@gmail.com Wed Dec 7 09:30:55 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 3D3D711E809B for ; Wed, 7 Dec 2011 09:30:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] 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 JAZXcNJWOkXo for ; Wed, 7 Dec 2011 09:30:54 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 6DE9F11E808C for ; Wed, 7 Dec 2011 09:30:54 -0800 (PST) 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 pB7HUq7E018942 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 7 Dec 2011 18:30:52 +0100 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 pB7HUqX4008513; Wed, 7 Dec 2011 18:30:52 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id pB7HUmlf011368; Wed, 7 Dec 2011 18:30:51 +0100 Message-ID: <4EDFA2C9.5020604@gmail.com> Date: Wed, 07 Dec 2011 18:30:49 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Lorenzo Colitti References: <282BBE8A501E1F4DA9C775F964BB21FE3EB78C3C98@GRFMBX704BA020.griffon.local> <4EC63E26.70104@gmail.com> <86163A8F-8628-4F67-BE93-3747F95A2F52@nominum.com> <4ECB6EAE.2010701@gmail.com> <702C34B3-F6B7-4EFB-91D5-8538540534A1@nominum.com> <4ECBE3BE.5070501@gmail.com> <759E821F-B503-4C8D-A79B-5F9A68A3613F@nominum.com> <4ED6A08D.9090703@gmail.com> <805C4AB5-9B43-48B5-A54E-B5AAD17B2BD9@gmail.com> <4EDE7C66.500@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: mif@ietf.org Subject: Re: [mif] Use cases for draft-ietf-mif-dhcpv6-route-option needed, vs rfc4191 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, 07 Dec 2011 17:30:55 -0000 Le 07/12/2011 02:15, Lorenzo Colitti a écrit : > On Tue, Dec 6, 2011 at 12:34, Alexandru Petrescu > > > wrote: > > I think 4191 is desirable if the host is a Host on cellular, not a > Router on cellular (tethering IPv6). A pure Router does not consider > receiving RAs other than for logging purposes, thus ignoring the > potentially present RIO. > > > IPv6 CE routers already listen to RAs and use them for routing > information (see RFC 6204). There's no reason a phone can't do the > same. Yes, it sounds logic. But, looking again at RFC6204 - that is a set of requirements. It does not say how to implement it. Moreover, it does not request the use of RFC4191 on the WAN interface of CE (or I can not find it requiring it so). For PD, it does not tell what to do with the delegated prefix (it should say adding routes in CEA and in WAN). For reasons like this I think RFC6204 may be enough for CE but not for other settings like a telephone. > Additionally, RIO (Route Information Option) does not seem to encode > the address of next-hop (it seems left to determine elsewhere, not > clear its relationship with the prefix in RIO). > > > The next-hop is the router that sent you the RA. This is good because > it implies fate-sharing - if the router goes away or is not capable > of carrying your packets any more, then the RA goes away as well. > > If you want to send traffic to a specific prefix through another > router on the link, then that router must send the RA itself. It > doesn't have to announce itself as a default router if it doesn't > want to be - it can just carry traffic to that prefix. Fate-sharing may be an advantage for CE, but can also be seen as the bad single point of failure (RA and routing functionality tied together) (if RA software on a Router dumps core, its routing kernel still works ok, thus another router could inform about this route by sending RA about it.) Alex From lorenzo@google.com Wed Dec 7 14:22:08 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 1A30621F8B64 for ; Wed, 7 Dec 2011 14:22:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.903 X-Spam-Level: X-Spam-Status: No, score=-102.903 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 HuJE2cosRFH1 for ; Wed, 7 Dec 2011 14:22:06 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 11A2021F8B53 for ; Wed, 7 Dec 2011 14:22:05 -0800 (PST) Received: by ggnk5 with SMTP id k5so1353525ggn.31 for ; Wed, 07 Dec 2011 14:22:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=6buA3pS3bk2fpAMOao2Bj+lCC/9YyMXtSxcu59uBZz4=; b=fwitlzYGIkPWpsuwN3srD7XX5gIJYP72JEvKQtKsuVgRKwrmwcEbw/sWy+Bry1ziVY u2gGIO4vhycaC8VoX6Pw== Received: by 10.182.159.99 with SMTP id xb3mr106421obb.8.1323296524596; Wed, 07 Dec 2011 14:22:04 -0800 (PST) Received: by 10.182.159.99 with SMTP id xb3mr106415obb.8.1323296524452; Wed, 07 Dec 2011 14:22:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.121.36 with HTTP; Wed, 7 Dec 2011 14:21:44 -0800 (PST) In-Reply-To: <4EDFA2C9.5020604@gmail.com> References: <282BBE8A501E1F4DA9C775F964BB21FE3EB78C3C98@GRFMBX704BA020.griffon.local> <4EC63E26.70104@gmail.com> <86163A8F-8628-4F67-BE93-3747F95A2F52@nominum.com> <4ECB6EAE.2010701@gmail.com> <702C34B3-F6B7-4EFB-91D5-8538540534A1@nominum.com> <4ECBE3BE.5070501@gmail.com> <759E821F-B503-4C8D-A79B-5F9A68A3613F@nominum.com> <4ED6A08D.9090703@gmail.com> <805C4AB5-9B43-48B5-A54E-B5AAD17B2BD9@gmail.com> <4EDE7C66.500@gmail.com> <4EDFA2C9.5020604@gmail.com> From: Lorenzo Colitti Date: Wed, 7 Dec 2011 14:21:44 -0800 Message-ID: To: Alexandru Petrescu Content-Type: multipart/alternative; boundary=14dae9399db145cc1904b387fba7 X-System-Of-Record: true Cc: mif@ietf.org Subject: Re: [mif] Use cases for draft-ietf-mif-dhcpv6-route-option needed, vs rfc4191 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, 07 Dec 2011 22:22:08 -0000 --14dae9399db145cc1904b387fba7 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Dec 7, 2011 at 09:30, Alexandru Petrescu < alexandru.petrescu@gmail.com> wrote: > IPv6 CE routers already listen to RAs and use them for routing >> information (see RFC 6204). There's no reason a phone can't do the >> same. >> > > Yes, it sounds logic. But, looking again at RFC6204 - that is a set of > requirements. It does not say how to implement it. > Well, yes, because that behaviour is specified in RFC 4861 and RFC 4862. Moreover, it does not request the use of RFC4191 on the WAN interface of CE > (or I can not find it requiring it so). > That's a fair point. We should probably say the CE router should support it. > For reasons like this I think RFC6204 may be enough for CE but not for > other settings like a telephone. This I don't understand. A CE and a telephone that implements tehering don't need to do anything different (except you can't implement tethering on a /64 without ND proxy) > Fate-sharing may be an advantage for CE, but can also be seen as the > bad single point of failure (RA and routing functionality tied together) (if > RA software on a Router dumps core, its routing kernel still works ok, > thus another router could inform about this route by sending RA about it.) > Then have two routers sending RAs all the time. The host is smart enough to pick one. --14dae9399db145cc1904b387fba7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Dec 7, 2011 at 09:30, Alexandru Petrescu= <alex= andru.petrescu@gmail.com> wrote:
IPv6 CE routers already li= sten to RAs and use them for routing
information (see RFC 6204). There's no reason a phone can't do the<= br> same.

Yes, it sounds logic. =A0But, looking again at RFC6204 - that is a set of requirements. =A0It does not say how to implement it.
=
Well, yes, because that behaviour is specified in RFC 4861 a= nd RFC 4862.

Moreover, it does not request the use of RFC4191 on the WAN interface of=A0= CE (or I can not find it requiring it so).

<= div>That's a fair point. We should probably say the CE router should su= pport it.
=A0
For reasons like this I think= RFC6204 may be enough for CE but not for
other settings like a telephone.

This I don= 't understand. A CE and a telephone that implements tehering don't = need to do anything different (except you can't implement tethering on = a /64 without ND proxy)
=A0
Fate-sharin= g may be an advantage for CE, but can also be seen as the bad=A0single poin= t of failure (RA and routing functionality tied together) (if
RA software on a Router dumps core, its routing kernel still works ok,
thus another router could inform about this route by sending RA about it.)<= br>

Then have two routers sending RAs all t= he time. The host is smart enough to pick one.
--14dae9399db145cc1904b387fba7-- From lorenzo@google.com Wed Dec 7 14:31:53 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 8EAEA11E80A5 for ; Wed, 7 Dec 2011 14:31:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.905 X-Spam-Level: X-Spam-Status: No, score=-102.905 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 TnSH8nyXt3SH for ; Wed, 7 Dec 2011 14:31:53 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id E950011E8073 for ; Wed, 7 Dec 2011 14:31:52 -0800 (PST) Received: by ggnk5 with SMTP id k5so1363780ggn.31 for ; Wed, 07 Dec 2011 14:31:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=YADa5skUEcJN3Y7YTMjVXQX4K8XMKyCdBcQoMYrE8Zo=; b=tJRHKXCN0Mz6p78Zyxjh50EO/6T9XqJBhfvOMOjTUq3zmajNWaOctkQiVUx8et1SEO AnMRAJUPRnOIuFmbbohw== Received: by 10.182.231.100 with SMTP id tf4mr70833obc.78.1323297112464; Wed, 07 Dec 2011 14:31:52 -0800 (PST) Received: by 10.182.231.100 with SMTP id tf4mr70825obc.78.1323297112239; Wed, 07 Dec 2011 14:31:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.121.36 with HTTP; Wed, 7 Dec 2011 14:31:31 -0800 (PST) In-Reply-To: References: <282BBE8A501E1F4DA9C775F964BB21FE3EB78C3C98@GRFMBX704BA020.griffon.local> <916CE6CF87173740BC8A2CE44309696204193417@008-AM1MPN1-053.mgdnok.nokia.com> <4EC512A2.2060509@gmail.com> <890A58CF-8EAD-4F92-9981-9B5AA07EBF00@nominum.com> <4EC63E26.70104@gmail.com> <86163A8F-8628-4F67-BE93-3747F95A2F52@nominum.com> <4ECB6EAE.2010701@gmail.com> <702C34B3-F6B7-4EFB-91D5-8538540534A1@nominum.com> <4ECBE3BE.5070501@gmail.com> <759E821F-B503-4C8D-A79B-5F9A68A3613F@nominum.com> <4ED6A08D.9090703@gmail.com> From: Lorenzo Colitti Date: Wed, 7 Dec 2011 14:31:31 -0800 Message-ID: To: Tao Sun Content-Type: multipart/alternative; boundary=f46d044796154eb0dd04b3881eb2 X-System-Of-Record: true Cc: "mif@ietf.org" Subject: Re: [mif] Use cases for draft-ietf-mif-dhcpv6-route-option needed 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, 07 Dec 2011 22:31:53 -0000 --f46d044796154eb0dd04b3881eb2 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Dec 5, 2011 at 11:25, Tao Sun wrote: > 4) Using RA to configure the route may cause potentially some messy. In 4G > cellular network, both GTP and PMIP protocal are used for mobility > management today. In GTP, it is a point-to-point link between mobile host > and PGW. However, in PMIP, PGW send /64 prefix to SGW through PBA. The SGW > sends RA to mobile host. If RA is also used for route configuration, how > SGW obtains the specific route information? how about the complexity due to > the large number of SGW as compared with PGW? how the SGW combine the > multiple RA route informatio nreceived from sources in use case 2 > since there is always only one SGW at a time? ... > I'm not sure I understand this. Why can't you configure the SGW to include the RIO in the RA no matter what? If what you're doing is saying that certain carrier services must be on certain interfaces, then the more specific route(s) don't need to be different for each user, right? --f46d044796154eb0dd04b3881eb2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Dec 5, 2011 at 11:25, Tao Sun <hisunt= ao@gmail.com> wrote:
4) Using RA to configure the route may cause potentially some messy. I= n 4G cellular network, both GTP and PMIP protocal=A0are=A0used for mobility= management today. In GTP,=A0it is a point-to-point link between=A0mobile h= ost and PGW. However, in PMIP, PGW send /64=A0prefix to SGW through PBA. Th= e SGW sends RA to mobile host. If RA is also used for route configuration, = how SGW obtains the specific route information? how about the complexity du= e to the large=A0number of SGW as compared with=A0PGW? how the=A0SGW combin= e the multiple RA route informatio nreceived from sources=A0in use case 2 s= ince=A0there is always only one SGW at a time? ...=A0

I'm not sure I understand this. Why ca= n't you configure the SGW to include the RIO in the RA no matter what? = If what you're doing is saying that certain carrier services must be on= certain interfaces, then the more specific route(s) don't need to be d= ifferent for each user, right?
--f46d044796154eb0dd04b3881eb2-- From hisuntao@gmail.com Thu Dec 8 10:42:24 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 3E4FB21F8AB9 for ; Thu, 8 Dec 2011 10:42:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[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 ASD2SCAwOVN8 for ; Thu, 8 Dec 2011 10:42:23 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6C08E21F8B80 for ; Thu, 8 Dec 2011 10:42:23 -0800 (PST) Received: by vcbfy13 with SMTP id fy13so1836798vcb.31 for ; Thu, 08 Dec 2011 10:42:23 -0800 (PST) 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=IirzH55zAwaf91P3f/QyPxN1BqY5+/AdHThbOd4ZCU4=; b=trN0DlWLUSlOeucxE+Hao0L5zi6M2jGkATOPsjUfOMVxJhS8TYHTg/xL37kpTW83/g jIxhvq04ODhQuxdOa8ZRzh/VgHbTaNOqhGfZeR22dBr/MLb+OqrrGR+txO1HRp2X8fvl FzeXrLV3cSZmqnSTK3uaAeRqir2NDudQCdFpM= MIME-Version: 1.0 Received: by 10.52.34.211 with SMTP id b19mr2433449vdj.112.1323369742968; Thu, 08 Dec 2011 10:42:22 -0800 (PST) Received: by 10.220.194.133 with HTTP; Thu, 8 Dec 2011 10:42:22 -0800 (PST) In-Reply-To: References: <282BBE8A501E1F4DA9C775F964BB21FE3EB78C3C98@GRFMBX704BA020.griffon.local> <916CE6CF87173740BC8A2CE44309696204193417@008-AM1MPN1-053.mgdnok.nokia.com> <4EC512A2.2060509@gmail.com> <890A58CF-8EAD-4F92-9981-9B5AA07EBF00@nominum.com> <4EC63E26.70104@gmail.com> <86163A8F-8628-4F67-BE93-3747F95A2F52@nominum.com> <4ECB6EAE.2010701@gmail.com> <702C34B3-F6B7-4EFB-91D5-8538540534A1@nominum.com> <4ECBE3BE.5070501@gmail.com> <759E821F-B503-4C8D-A79B-5F9A68A3613F@nominum.com> <4ED6A08D.9090703@gmail.com> <805C4AB5-9B43-48B5-A54E-B5AAD17B2BD9@gmail.com> Date: Fri, 9 Dec 2011 02:42:22 +0800 Message-ID: From: Tao Sun To: Lorenzo Colitti Content-Type: multipart/alternative; boundary=20cf3079bf3c6fa6fe04b39907ee Cc: "mif@ietf.org" Subject: Re: [mif] Use cases for draft-ietf-mif-dhcpv6-route-option needed 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, 08 Dec 2011 18:42:24 -0000 --20cf3079bf3c6fa6fe04b39907ee Content-Type: text/plain; charset=ISO-8859-1 On Wed, Dec 7, 2011 at 3:14 AM, Lorenzo Colitti wrote: > On Tue, Dec 6, 2011 at 10:56, Tao Sun wrote: > >> These are (at least the example 1) doable using RFC4191 and RAs. For >>> the latter case how the default router for "default traffic" gets selected >>> (independent of DHCPv6 or RAs) is a bit of an issue if all interfaces >>> (APNs) are equal. >>> >> [Tao] The interfaces (APNs) are generally not equal, i.e., APN_IMS, >> APN_Internet. >> > > Yes, and each one already has its own RA. > > Compared to AAA based on what grounds? >>> >> [Tao] Using radius with AAA is only used for few enterprise users in some >> operator's network. >> > > So what entity in the network decides what prefix to assign to a given > user when he sets up, say, the Internet PDN? > [Tao] The gateway (e.g., GGSN) is configured with an address pool and asign IP address based on it. > In the above (cellular oriented) example, I am not so sure. In >> cellular (3GPP) networks the RAs are already used in per subscriber manner. >> >> [Tao] You need to update radius protocal and AAA specification in 3GPP to >> convey the configuration information. The mandatory RA for prefix >> assignment is supported not long time ago by network elements. Ohter >> optional extension of RA such as RIO indeeds new requirement for network >> elements and handset. >> > > The RADIUS attribute for it already exists, it's called Framed-IPv6-Route: > http://tools.ietf.org/html/rfc3162#section-2.5 . > > The handsets can easily support it if they are based on operating systems > that support it. I know Linux does, so Android could use it. Don't know > about OS X / iPhone, but on the other hand the iPhone doesn't support IPv6 > on the mobile interface yet. > [Tao] I know only the WiFi mode support IPv6 for Android previously. I also knew from my colleague that the Android 3.2.2 introduced support of dual stack IPv4/v6 on LTE mode in Oct. this year. Could you help to confirm whether Anroid already support RIO? --20cf3079bf3c6fa6fe04b39907ee Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Dec 7, 2011 at 3:14 AM, Lorenzo Colitti = <lorenzo@google.= com> wrote:
On Tue, Dec 6, 2011 at 10:56, Tao Sun &= lt;hisuntao@gmail.c= om> wrote:
These are (at least the example = 1) doable using RFC4191 and RAs. For the latter case how the default router= for "default traffic" gets selected (independent of DHCPv6 or RA= s) is a bit of an issue if all interfaces (APNs) are equal.
[Tao] The interfaces (APNs)=A0are generally=A0not equal, i.e., APN_IMS= , APN_Internet.

Yes, and each one already has its own RA.

Compared to AAA based on what grounds?
[Tao] Using radius with AAA is only used for few enterprise users in= =A0some operator's=A0network.

So what entity in the network decides what prefix to assign to a given= user when he sets up, say, the Internet PDN?
=A0
[Tao] The gateway (e.g., GGSN) is configured with an address pool and = asign IP address based on it.
=A0
=A0
=A0In the above (cellular oriented) example, I am not so sure. In cell= ular (3GPP) networks the RAs are already used in per subscriber manner.
=A0
[Tao] You need to update radius protocal and AAA specification in 3GPP= to convey the configuration information. The mandatory RA for prefix assig= nment is supported not long time ago by network elements.=A0Ohter optional = extension of=A0RA such as RIO indeeds new requirement for network elements = and handset.

The RADIUS attribute for it already exists, it's called Framed-IPv= 6-Route:=A0http://tools.ietf.org/html/rfc3162#section-2.5 .

The handsets can easily support it if they are based on operating syst= ems that support it. I know Linux does, so Android could use it. Don't = know about OS X / iPhone, but on the other hand the iPhone doesn't supp= ort IPv6 on the mobile interface yet.
=A0
[Tao] I know only the WiFi mode support IPv6 for Android previously. I= also knew from my colleague that the Android 3.2.2 introduced support of d= ual stack IPv4/v6=A0on LTE mode=A0in Oct. this year.=A0=A0Could you help to= confirm whether Anroid already support RIO?
--20cf3079bf3c6fa6fe04b39907ee-- From hisuntao@gmail.com Thu Dec 8 10:51:21 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 C3ABC21F8A69 for ; Thu, 8 Dec 2011 10:51:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[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 w8BV-NGP5nd7 for ; Thu, 8 Dec 2011 10:51:21 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id ECF6921F8B28 for ; Thu, 8 Dec 2011 10:51:20 -0800 (PST) Received: by vbbez10 with SMTP id ez10so1837688vbb.31 for ; Thu, 08 Dec 2011 10:51:18 -0800 (PST) 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=Ee6f0mneTdjyC1LmMLDACkdaylyfSIn2HIXFu0p7KjI=; b=w+cka51yXIXPOBl2CQ69fUB9ijRQb/vepBkVoFefNSAM+oWp1gIwWjEdU158eCKm9O iQsJ+Fj0D5/CdWW+xypXocqZPrjVs1yNHnUB4P2NIdHoWdvziz6GfW047gHFBq+4w2c+ XdJUMepuRgVGCUD+uMSD9O+8il8XY1HWhWD10= MIME-Version: 1.0 Received: by 10.52.26.179 with SMTP id m19mr2475418vdg.95.1323370278573; Thu, 08 Dec 2011 10:51:18 -0800 (PST) Received: by 10.220.194.133 with HTTP; Thu, 8 Dec 2011 10:51:18 -0800 (PST) In-Reply-To: References: <282BBE8A501E1F4DA9C775F964BB21FE3EB78C3C98@GRFMBX704BA020.griffon.local> <4EC63E26.70104@gmail.com> <86163A8F-8628-4F67-BE93-3747F95A2F52@nominum.com> <4ECB6EAE.2010701@gmail.com> <702C34B3-F6B7-4EFB-91D5-8538540534A1@nominum.com> <4ECBE3BE.5070501@gmail.com> <759E821F-B503-4C8D-A79B-5F9A68A3613F@nominum.com> <4ED6A08D.9090703@gmail.com> <805C4AB5-9B43-48B5-A54E-B5AAD17B2BD9@gmail.com> <4EDE7C66.500@gmail.com> Date: Fri, 9 Dec 2011 02:51:18 +0800 Message-ID: From: Tao Sun To: Ted Lemon Content-Type: multipart/alternative; boundary=20cf30780aee5c578b04b3992794 Cc: "" Subject: Re: [mif] Use cases for draft-ietf-mif-dhcpv6-route-option needed, vs rfc4191 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, 08 Dec 2011 18:51:22 -0000 --20cf30780aee5c578b04b3992794 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Dec 7, 2011 at 4:38 AM, Ted Lemon wrote: > On Dec 6, 2011, at 3:34 PM, Alexandru Petrescu wrote: > > What is simpler: specify Routers to consider RIO'ed RAs? or specify > DHCP extensions to communicate routes? (at least default routes). > > > Of course, the answer to this question will vary depending on whether you > are a provider operating routers, or a vendor implementing host stacks. > Which is why we are having this discussion. Previous discussions really > only considered the network operator case. > > It's pretty clear that from the host implementation side, RIO is easier > than DHCP, because the host already supports it. > [Tao] For the host here, you mean Linux or Android or something else? > > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > > --20cf30780aee5c578b04b3992794 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Dec 7, 2011 at 4:38 AM, Ted Lemon <Ted.Lemon@nominum.= com> wrote:
On Dec 6, 2011, at 3:34 PM, Alexandru Petrescu wrote:
What is simpler: specify Rout= ers to consider RIO'ed RAs? =A0or specify
DHCP extensions to communicate routes? (at least default routes).

Of course, the answer to this question will vary depending on whether = you are a provider operating routers, or a vendor implementing host stacks.= =A0 Which is why we are having this discussion. =A0 Previous discussions r= eally only considered the network operator case.

It's pretty clear that from the host implementation side, RIO is e= asier than DHCP, because the host already supports it.
=A0
[Tao] For the host here, you mean Linux or Android or something else?<= /div>
=A0


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


--20cf30780aee5c578b04b3992794-- From lorenzo@google.com Thu Dec 8 10:58:36 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 D165D21F84C1 for ; Thu, 8 Dec 2011 10:58:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.908 X-Spam-Level: X-Spam-Status: No, score=-102.908 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 kE+qQaekDE4B for ; Thu, 8 Dec 2011 10:58:36 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 06BFB21F84B8 for ; Thu, 8 Dec 2011 10:58:35 -0800 (PST) Received: by ggnk5 with SMTP id k5so2684469ggn.31 for ; Thu, 08 Dec 2011 10:58:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=vNyurnxwxj3hL22DH/IwJni98uIhql92p1zdV26N3kA=; b=s/BbwA2M/B6dbSCfeUWnQxNy+XR9lJSnm8vJpBMHhXZ/o7jPQAGX1y0jYYbG8OvD+k +WTaJ0ENDJ9Fv0ZsEnIQ== Received: by 10.182.89.65 with SMTP id bm1mr923782obb.58.1323370715435; Thu, 08 Dec 2011 10:58:35 -0800 (PST) Received: by 10.182.89.65 with SMTP id bm1mr923776obb.58.1323370715303; Thu, 08 Dec 2011 10:58:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.121.36 with HTTP; Thu, 8 Dec 2011 10:58:14 -0800 (PST) In-Reply-To: References: <282BBE8A501E1F4DA9C775F964BB21FE3EB78C3C98@GRFMBX704BA020.griffon.local> <916CE6CF87173740BC8A2CE44309696204193417@008-AM1MPN1-053.mgdnok.nokia.com> <4EC512A2.2060509@gmail.com> <890A58CF-8EAD-4F92-9981-9B5AA07EBF00@nominum.com> <4EC63E26.70104@gmail.com> <86163A8F-8628-4F67-BE93-3747F95A2F52@nominum.com> <4ECB6EAE.2010701@gmail.com> <702C34B3-F6B7-4EFB-91D5-8538540534A1@nominum.com> <4ECBE3BE.5070501@gmail.com> <759E821F-B503-4C8D-A79B-5F9A68A3613F@nominum.com> <4ED6A08D.9090703@gmail.com> <805C4AB5-9B43-48B5-A54E-B5AAD17B2BD9@gmail.com> From: Lorenzo Colitti Date: Thu, 8 Dec 2011 10:58:14 -0800 Message-ID: To: Tao Sun Content-Type: multipart/alternative; boundary=f46d0447a0016450b004b39941fd X-System-Of-Record: true Cc: "mif@ietf.org" Subject: Re: [mif] Use cases for draft-ietf-mif-dhcpv6-route-option needed 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, 08 Dec 2011 18:58:36 -0000 --f46d0447a0016450b004b39941fd Content-Type: text/plain; charset=ISO-8859-1 On Thu, Dec 8, 2011 at 10:42, Tao Sun wrote: > [Tao] Using radius with AAA is only used for few enterprise users >>> in some operator's network. >>> >> >> So what entity in the network decides what prefix to assign to a given >> user when he sets up, say, the Internet PDN? >> > > [Tao] The gateway (e.g., GGSN) is configured with an address pool and > asign IP address based on it. > But that gateway is talking to some AAA server (e.g., RADIUS or something else), right? I can't imagine that all the users on a particular GGSN are locally configured on the box. > The RADIUS attribute for it already exists, it's called >> Framed-IPv6-Route: http://tools.ietf.org/html/rfc3162#section-2.5 . >> >> The handsets can easily support it if they are based on operating systems >> that support it. I know Linux does, so Android could use it. Don't know >> about OS X / iPhone, but on the other hand the iPhone doesn't support IPv6 >> on the mobile interface yet. >> > > [Tao] I know only the WiFi mode support IPv6 for Android previously. I > also knew from my colleague that the Android 3.2.2 introduced support of > dual stack IPv4/v6 on LTE mode in Oct. this year. Could you help to > confirm whether Anroid already support RIO? > It's supported by the Linux kernel but it's currently disabled in the Android kernel for no particular reason that I know of. It would be much easier to enable it than to package a DHCPv6 client. --f46d0447a0016450b004b39941fd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Dec 8, 2011 at 10:42, Tao Sun <hisuntao@gmail.com&g= t; wrote:
[Tao] Using radius with AAA is only used fo= r few enterprise users in=A0some operator's=A0network.

So what entity in the network decides what prefix to assign to a given= user when he sets up, say, the Internet PDN?
=A0
[Tao] The gateway (e.g., GGSN) is configured with an address poo= l and asign IP address based on it.

=
But that gateway is talking to some AAA server (e.g., RADIUS or someth= ing else), right? I can't imagine that all the users on a particular GG= SN are locally configured on the box.
=A0
The R= ADIUS attribute for it already exists, it's called Framed-IPv6-Route:= =A0http://tools.ietf.org/html/rfc3162#section-2.5 .

The handsets can easily support it if they are based on operating syst= ems that support it. I know Linux does, so Android could use it. Don't = know about OS X / iPhone, but on the other hand the iPhone doesn't supp= ort IPv6 on the mobile interface yet.
=A0
[Tao] I know only the WiFi mode support IPv6 for Android previou= sly. I also knew from my colleague that the Android 3.2.2 introduced suppor= t of dual stack IPv4/v6=A0on LTE mode=A0in Oct. this year.=A0=A0Could you h= elp to confirm whether Anroid already support RIO?

It's supported by the Linux kern= el but it's currently disabled in the Android kernel for no particular = reason that I know of. It would be much easier to enable it than to package= a DHCPv6 client.
--f46d0447a0016450b004b39941fd-- From hisuntao@gmail.com Thu Dec 8 11:02:59 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 DB77F21F8B3D for ; Thu, 8 Dec 2011 11:02:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[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 Wweaqr1XcqkH for ; Thu, 8 Dec 2011 11:02:59 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 130DC21F8B36 for ; Thu, 8 Dec 2011 11:02:58 -0800 (PST) Received: by vbbez10 with SMTP id ez10so1848527vbb.31 for ; Thu, 08 Dec 2011 11:02:58 -0800 (PST) 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=oNeyOJOfF9VhQRCDfMBgJ/zX3Vto6sbTVO+nLnQzW/c=; b=ZsrUB2YPK5sW10zgrk3fR9iKr0yOsHHeZNY1LQe7LTgLxvc+IiKjIa+GdqQjgvLvTr WClid4SktA7drhRGIH0v4LjGhvQcjUuB0N/Wq3Js7irc/Hcw0+xM88CYs2o9GAyc5fd5 ZjjnZFnIHd6w0O/Uv5pQRurNYz+fzv4JBllDA= MIME-Version: 1.0 Received: by 10.52.33.69 with SMTP id p5mr2527783vdi.78.1323370978602; Thu, 08 Dec 2011 11:02:58 -0800 (PST) Received: by 10.220.194.133 with HTTP; Thu, 8 Dec 2011 11:02:58 -0800 (PST) In-Reply-To: References: <282BBE8A501E1F4DA9C775F964BB21FE3EB78C3C98@GRFMBX704BA020.griffon.local> <916CE6CF87173740BC8A2CE44309696204193417@008-AM1MPN1-053.mgdnok.nokia.com> <4EC512A2.2060509@gmail.com> <890A58CF-8EAD-4F92-9981-9B5AA07EBF00@nominum.com> <4EC63E26.70104@gmail.com> <86163A8F-8628-4F67-BE93-3747F95A2F52@nominum.com> <4ECB6EAE.2010701@gmail.com> <702C34B3-F6B7-4EFB-91D5-8538540534A1@nominum.com> <4ECBE3BE.5070501@gmail.com> <759E821F-B503-4C8D-A79B-5F9A68A3613F@nominum.com> <4ED6A08D.9090703@gmail.com> Date: Fri, 9 Dec 2011 03:02:58 +0800 Message-ID: From: Tao Sun To: Lorenzo Colitti Content-Type: multipart/alternative; boundary=20cf3079ba5415ed9e04b3995154 Cc: "mif@ietf.org" Subject: Re: [mif] Use cases for draft-ietf-mif-dhcpv6-route-option needed 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, 08 Dec 2011 19:03:00 -0000 --20cf3079ba5415ed9e04b3995154 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Dec 8, 2011 at 6:31 AM, Lorenzo Colitti wrote: > On Mon, Dec 5, 2011 at 11:25, Tao Sun wrote: > >> 4) Using RA to configure the route may cause potentially some messy. In >> 4G cellular network, both GTP and PMIP protocal are used for mobility >> management today. In GTP, it is a point-to-point link between mobile host >> and PGW. However, in PMIP, PGW send /64 prefix to SGW through PBA. The SGW >> sends RA to mobile host. If RA is also used for route configuration, how >> SGW obtains the specific route information? how about the complexity due to >> the large number of SGW as compared with PGW? how the SGW combine the >> multiple RA route informatio nreceived from sources in use case 2 >> since there is always only one SGW at a time? ... >> > > I'm not sure I understand this. Why can't you configure the SGW to include > the RIO in the RA no matter what? If what you're doing is saying that > certain carrier services must be on certain interfaces, then the more > specific route(s) don't need to be different for each user, right? > [Tao]You can configure the PGW. However, you cannot configure SGW. A SGW has no idea what PDN the user will connect to. A user can connect to multiple PDNs through corresponding PGWs simultaneously, but only across one single SGW. Yes, but the specific route for each PDN is different. --20cf3079ba5415ed9e04b3995154 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, Dec 8, 2011 at 6:31 AM, Lorenzo Colitti = <lorenzo@google.= com> wrote:
On Mon, Dec 5, 2011 at 11:25, Tao Sun &= lt;hisuntao@gmail.c= om> wrote:
4) Using RA to configure the route may cause potentially some messy. I= n 4G cellular network, both GTP and PMIP protocal=A0are=A0used for mobility= management today. In GTP,=A0it is a point-to-point link between=A0mobile h= ost and PGW. However, in PMIP, PGW send /64=A0prefix to SGW through PBA. Th= e SGW sends RA to mobile host. If RA is also used for route configuration, = how SGW obtains the specific route information? how about the complexity du= e to the large=A0number of SGW as compared with=A0PGW? how the=A0SGW combin= e the multiple RA route informatio nreceived from sources=A0in use case 2 s= ince=A0there is always only one SGW at a time? ...=A0

I'm not sure I understand this. Why can't you configure the SG= W to include the RIO in the RA no matter what? If what you're doing is = saying that certain carrier services must be on certain interfaces, then th= e more specific route(s) don't need to be different for each user, righ= t?

[Tao]You can configure the PGW. However, you cannot configure SGW.= A SGW has no idea what PDN the user will connect to. A user can connect to= multiple PDNs through corresponding PGWs simultaneously, but only across o= ne single SGW.
=A0
Yes, but the specific route for each PDN is different.
--20cf3079ba5415ed9e04b3995154-- From hisuntao@gmail.com Thu Dec 8 11:19:13 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 5B4F021F8593 for ; Thu, 8 Dec 2011 11:19:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[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 wc6T-fegTz6R for ; Thu, 8 Dec 2011 11:19:12 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 90EE221F8510 for ; Thu, 8 Dec 2011 11:19:12 -0800 (PST) Received: by vbbez10 with SMTP id ez10so1865012vbb.31 for ; Thu, 08 Dec 2011 11:19:12 -0800 (PST) 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=63CD2IsUYJXRwBWyPpBq0Pq91N+s7SJwlt8P99YBAsw=; b=R24viBweJyKEXq4rEdPtGcz7CGO84Qti1Za0TaNrfT+Eh28Y6sCX0nRSFUtkcDmfAE wW6u+sVDfxORFqqDzSJTW60PD51RhV1A1WVE35kQwrAOAIlVWzMu0u/3WnP6YxEwdL/d skeg7Nh6fenLoedqSHSIwb0Ao8zLvDEYlEQzk= MIME-Version: 1.0 Received: by 10.52.34.211 with SMTP id b19mr2526977vdj.112.1323371952077; Thu, 08 Dec 2011 11:19:12 -0800 (PST) Received: by 10.220.194.133 with HTTP; Thu, 8 Dec 2011 11:19:11 -0800 (PST) In-Reply-To: References: <282BBE8A501E1F4DA9C775F964BB21FE3EB78C3C98@GRFMBX704BA020.griffon.local> <916CE6CF87173740BC8A2CE44309696204193417@008-AM1MPN1-053.mgdnok.nokia.com> <4EC512A2.2060509@gmail.com> <890A58CF-8EAD-4F92-9981-9B5AA07EBF00@nominum.com> <4EC63E26.70104@gmail.com> <86163A8F-8628-4F67-BE93-3747F95A2F52@nominum.com> <4ECB6EAE.2010701@gmail.com> <702C34B3-F6B7-4EFB-91D5-8538540534A1@nominum.com> <4ECBE3BE.5070501@gmail.com> <759E821F-B503-4C8D-A79B-5F9A68A3613F@nominum.com> <4ED6A08D.9090703@gmail.com> <805C4AB5-9B43-48B5-A54E-B5AAD17B2BD9@gmail.com> Date: Fri, 9 Dec 2011 03:19:11 +0800 Message-ID: From: Tao Sun To: Lorenzo Colitti Content-Type: multipart/alternative; boundary=20cf3079bf3c1bfbc404b3998ba0 Cc: "mif@ietf.org" Subject: Re: [mif] Use cases for draft-ietf-mif-dhcpv6-route-option needed 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, 08 Dec 2011 19:19:13 -0000 --20cf3079bf3c1bfbc404b3998ba0 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Dec 9, 2011 at 2:58 AM, Lorenzo Colitti wrote: > On Thu, Dec 8, 2011 at 10:42, Tao Sun wrote: > >> [Tao] Using radius with AAA is only used for few enterprise users >>>> in some operator's network. >>>> >>> >>> So what entity in the network decides what prefix to assign to a given >>> user when he sets up, say, the Internet PDN? >>> >> >> [Tao] The gateway (e.g., GGSN) is configured with an address pool and >> asign IP address based on it. >> > > But that gateway is talking to some AAA server (e.g., RADIUS or something > else), right? I can't imagine that all the users on a particular GGSN are > locally configured on the box. > The user's information is not locally configured on the box. The gateway is configured with a block of IP address pool. It assigns IP addresses dynamically to users who attach to it. > > >> The RADIUS attribute for it already exists, it's called >>> Framed-IPv6-Route: http://tools.ietf.org/html/rfc3162#section-2.5 . >>> >>> The handsets can easily support it if they are based on operating >>> systems that support it. I know Linux does, so Android could use it. Don't >>> know about OS X / iPhone, but on the other hand the iPhone doesn't support >>> IPv6 on the mobile interface yet. >>> >> >> [Tao] I know only the WiFi mode support IPv6 for Android previously. I >> also knew from my colleague that the Android 3.2.2 introduced support of >> dual stack IPv4/v6 on LTE mode in Oct. this year. Could you help to >> confirm whether Anroid already support RIO? >> > > It's supported by the Linux kernel but it's currently disabled in the > Android kernel for no particular reason that I know of. It would be much > easier to enable it than to package a DHCPv6 client. > --20cf3079bf3c1bfbc404b3998ba0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Fri, Dec 9, 2011 at 2:58 AM, Lorenzo Colitti = <lorenzo@google.= com> wrote:
On Thu, Dec 8, 2011 at 10:42, Tao Sun &= lt;hisuntao@gmail.c= om> wrote:
[Tao] Using radius with AAA is only used for few enterprise users in= =A0some operator's=A0network.

So what entity in the network decides what prefix to assign to a given= user when he sets up, say, the Internet PDN?
=A0
[Tao] The gateway (e.g., GGSN) is configured with an address pool and = asign IP address based on it.

But that gateway is talking to some AAA server (e.g., RADIUS or someth= ing else), right? I can't imagine that all the users on a particular GG= SN are locally configured on the box.
=A0
The user's information is not locally configured on the box. The g= ateway is configured with a block of IP address pool. It assigns IP address= es dynamically to users who attach to it.
=A0
=A0
The RADIUS attribute for it already exists, it's called Framed-IPv= 6-Route:=A0http://tools.ietf.org/html/rfc3162#section-2.5 .

The handsets can easily support it if they are based on operating syst= ems that support it. I know Linux does, so Android could use it. Don't = know about OS X / iPhone, but on the other hand the iPhone doesn't supp= ort IPv6 on the mobile interface yet.
=A0
[Tao] I know only the WiFi mode support IPv6 for Android previously. I= also knew from my colleague that the Android 3.2.2 introduced support of d= ual stack IPv4/v6=A0on LTE mode=A0in Oct. this year.=A0=A0Could you help to= confirm whether Anroid already support RIO?

It's supported by the Linux kernel but it's currently disabled= in the Android kernel for no particular reason that I know of. It would be= much easier to enable it than to package a DHCPv6 client.

--20cf3079bf3c1bfbc404b3998ba0-- From denghui02@hotmail.com Sat Dec 10 07:12:53 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 CE69E21F8C15 for ; Sat, 10 Dec 2011 07:12:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 NTR2BU21Fzje for ; Sat, 10 Dec 2011 07:12:53 -0800 (PST) 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 4BFFD21F8C14 for ; Sat, 10 Dec 2011 07:12:53 -0800 (PST) Received: from COL118-W18 ([65.55.34.71]) by col0-omc2-s6.col0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 10 Dec 2011 07:12:52 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_739e3042-16f8-4055-a3a9-e8abcdc49165_" X-Originating-IP: [61.149.197.66] From: Hui Deng To: Date: Sat, 10 Dec 2011 23:12:52 +0800 Importance: Normal In-Reply-To: <20111209213221.3695.57478@ietfa.amsl.com> References: <20111209213221.3695.57478@ietfa.amsl.com> MIME-Version: 1.0 X-OriginalArrivalTime: 10 Dec 2011 15:12:52.0721 (UTC) FILETIME=[2FFAF610:01CCB74E] Subject: [mif] FW: New Liaison Statement, "OMA Open Connection Manager API (OpenCMAPI)" 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: Sat, 10 Dec 2011 15:12:53 -0000 --_739e3042-16f8-4055-a3a9-e8abcdc49165_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 8bit Hello all OMA CD wg would like to align their connection manager API design work with MIF api. Feel free to comment on it. thanks -Hui > Subject: New Liaison Statement, "OMA Open Connection Manager API (OpenCMAPI)" > From: lsmt@ietf.org > To: mrw@lilacglade.org; denghui02@hotmail.com > Date: Fri, 9 Dec 2011 21:32:21 +0000 > CC: rdroms.ietf@gmail.com; jari.arkko@piuha.net; mif@ietf.org; msk@cloudmark.com; OMA-LIAISON@MAIL.OPENMOBILEALLIANCE.ORG; OMA-PLENARY@MAIL.OPENMOBILEALLIANCE.ORG; OMA-CD@MAIL.OPENMOBILEALLIANCE.ORG > > Title: OMA Open Connection Manager API (OpenCMAPI) > Submission Date: 2011-12-08 > URL of the IETF Web page: /liaison/1120/ > > From: Open Mobile Alliance (Thierry Berisot ) > To: Multiple Interfaces (mrw@lilacglade.org, denghui02@hotmail.com) > Cc: Ralph Droms ,Jari Arkko ,Multiple Interfaces Discussion List ,Murray Kucherawy ,,, > Reponse Contact: > Technical Contact: > Purpose: For information > > Body: > Attachment(s): > > OMA Open Connection Manager API (OpenCMAPI) https://datatracker.ietf.org/documents/LIAISON/file1301.doc > > --_739e3042-16f8-4055-a3a9-e8abcdc49165_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: 8bit
Hello all
 
OMA CD wg would like to align their connection manager API design work with MIF api.
Feel free to comment on it.
 
thanks
 
-Hui
 
> Subject: New Liaison Statement, "OMA Open Connection Manager API (OpenCMAPI)"
> From: lsmt@ietf.org
> To: mrw@lilacglade.org; denghui02@hotmail.com
> Date: Fri, 9 Dec 2011 21:32:21 +0000
> CC: rdroms.ietf@gmail.com; jari.arkko@piuha.net; mif@ietf.org; msk@cloudmark.com; OMA-LIAISON@MAIL.OPENMOBILEALLIANCE.ORG; OMA-PLENARY@MAIL.OPENMOBILEALLIANCE.ORG; OMA-CD@MAIL.OPENMOBILEALLIANCE.ORG
>
> Title: OMA Open Connection Manager API (OpenCMAPI)
> Submission Date: 2011-12-08
> URL of the IETF Web page: /liaison/1120/
>
> From: Open Mobile Alliance (Thierry Berisot <thierry.berisot@telekom.de>)
> To: Multiple Interfaces (mrw@lilacglade.org, denghui02@hotmail.com)
> Cc: Ralph Droms <rdroms.ietf@gmail.com>,Jari Arkko <jari.arkko@piuha.net>,Multiple Interfaces Discussion List <mif@ietf.org>,Murray Kucherawy <msk@cloudmark.com>,<OMA-LIAISON@MAIL.OPENMOBILEALLIANCE.ORG>,<O MA-PLENARY@MAIL.OPENMOBILEALLIANCE.ORG>,<OMA-CD@MAIL.OPENMOBILEALLIANCE.ORG>
> Reponse Contact:
> Technical Contact:
> Purpose: For information
>
> Body:
> Attachment(s):
>
> OMA Open Connection Manager API (OpenCMAPI) https://datatracker.ietf.org/documents/LIAISON/file1301.doc
>
>
--_739e3042-16f8-4055-a3a9-e8abcdc49165_-- From pierrick.seite@orange.com Sun Dec 11 15:05:28 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 0E06121F84B0 for ; Sun, 11 Dec 2011 15:05:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 I5QWypitE35R for ; Sun, 11 Dec 2011 15:05:27 -0800 (PST) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id E8A2C21F84A6 for ; Sun, 11 Dec 2011 15:05:26 -0800 (PST) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id E6189FC4003; Mon, 12 Dec 2011 00:05:25 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id D5D35FC4001; Mon, 12 Dec 2011 00:05:25 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 Dec 2011 00:05:25 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCB859.5D99352E" Date: Mon, 12 Dec 2011 00:05:24 +0100 Message-ID: <843DA8228A1BA74CA31FB4E111A5C46202128993@ftrdmel0.rd.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mif] FW: New Liaison Statement, "OMA Open Connection Manager API (OpenCMAPI)" Thread-Index: Acy3TjPILpqErJ3bST2/oHHNGvuumwBCbo4g References: <20111209213221.3695.57478@ietfa.amsl.com> From: To: , X-OriginalArrivalTime: 11 Dec 2011 23:05:25.0606 (UTC) FILETIME=[5E07A060:01CCB859] Subject: Re: [mif] FW: New Liaison Statement, "OMA Open Connection Manager API (OpenCMAPI)" 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: Sun, 11 Dec 2011 23:05:28 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCB859.5D99352E Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Hui, =20 It think it does make sense to coordinate effort from IETF/MIF and = OMA-DM on multiple connection API design. Actually, some of the OMA API = requirements are inline with the MIF API, e.g. DNS selection, routing = configuration, first hop selection. Moreover, as discussed during the = last IETF, the multiple interface management should rely on different = APIs acting at different layers; some of these API are clearly not in = the IETF scope but are covered by the OMA DM. =20 Pierrick =20 =20 ________________________________ De : mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part de = Hui Deng Envoy=E9 : samedi 10 d=E9cembre 2011 16:13 =C0 : mif@ietf.org Objet : [mif] FW: New Liaison Statement, "OMA Open Connection Manager = API (OpenCMAPI)" =20 Hello all =20 OMA CD wg would like to align their connection manager API design work = with MIF api. Feel free to comment on it. =20 thanks =20 -Hui =20 > Subject: New Liaison Statement, "OMA Open Connection Manager API = (OpenCMAPI)" > From: lsmt@ietf.org > To: mrw@lilacglade.org; denghui02@hotmail.com > Date: Fri, 9 Dec 2011 21:32:21 +0000 > CC: rdroms.ietf@gmail.com; jari.arkko@piuha.net; mif@ietf.org; = msk@cloudmark.com; OMA-LIAISON@MAIL.OPENMOBILEALLIANCE.ORG; = OMA-PLENARY@MAIL.OPENMOBILEALLIANCE.ORG; = OMA-CD@MAIL.OPENMOBILEALLIANCE.ORG >=20 > Title: OMA Open Connection Manager API (OpenCMAPI) > Submission Date: 2011-12-08 > URL of the IETF Web page: /liaison/1120/ >=20 > From: Open Mobile Alliance (Thierry Berisot = ) > To: Multiple Interfaces (mrw@lilacglade.org, denghui02@hotmail.com) > Cc: Ralph Droms ,Jari Arkko = ,Multiple Interfaces Discussion List = ,Murray Kucherawy = ,,, > Reponse Contact:=20 > Technical Contact:=20 > Purpose: For information >=20 > Body:=20 > Attachment(s): >=20 > OMA Open Connection Manager API (OpenCMAPI) = https://datatracker.ietf.org/documents/LIAISON/file1301.doc >=20 >=20 ------_=_NextPart_001_01CCB859.5D99352E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi = Hui,

 =

It think it does = make sense to coordinate effort from IETF/MIF and OMA-DM on multiple connection API = design. Actually, some of the OMA API requirements are inline with the MIF API, = e.g. DNS selection, routing configuration, first hop selection. Moreover, as = discussed during the last IETF, the multiple interface management should rely on = different APIs acting at different layers; some of these API are clearly not in = the IETF scope but are covered by the OMA DM.

 =

Pierrick

 

 

De : mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part de Hui Deng
Envoy=E9 : samedi 10 = d=E9cembre 2011 16:13
=C0 : = mif@ietf.org
Objet : [mif] FW: = New Liaison Statement, "OMA Open Connection Manager API = (OpenCMAPI)"

 

Hello all
 
OMA CD wg would like to align their connection manager API = design work with MIF api.
Feel free to comment on it.
 
thanks
 
-Hui
 

> Subject: New Liaison Statement, "OMA Open Connection Manager API (OpenCMAPI)"
> From: lsmt@ietf.org
> To: mrw@lilacglade.org; denghui02@hotmail.com
> Date: Fri, 9 Dec 2011 21:32:21 +0000
> CC: rdroms.ietf@gmail.com; jari.arkko@piuha.net; mif@ietf.org; msk@cloudmark.com; OMA-LIAISON@MAIL.OPENMOBILEALLIANCE.ORG; OMA-PLENARY@MAIL.OPENMOBILEALLIANCE.ORG; = OMA-CD@MAIL.OPENMOBILEALLIANCE.ORG
>
> Title: OMA Open Connection Manager API (OpenCMAPI)
> Submission Date: 2011-12-08
> URL of the IETF Web page: /liaison/1120/
>
> From: Open Mobile Alliance (Thierry Berisot <thierry.berisot@telekom.de>)
> To: Multiple Interfaces (mrw@lilacglade.org, = denghui02@hotmail.com)
> Cc: Ralph Droms <rdroms.ietf@gmail.com>,Jari Arkko <jari.arkko@piuha.net>,Multiple Interfaces Discussion List <mif@ietf.org>,Murray Kucherawy <msk@cloudmark.com>,<OMA-LIAISON@MAIL.OPENMOBILEALLIANCE.ORG>= ,<O MA-PLENARY@MAIL.OPENMOBILEALLIANCE.ORG>,<OMA-CD@MAIL.OPENMOBILEALLI= ANCE.ORG>
> Reponse Contact:
> Technical Contact:
> Purpose: For information
>
> Body:
> Attachment(s):
>
> OMA Open Connection Manager API (OpenCMAPI) = https://datatracker.ietf.org/documents/LIAISON/file1301.doc
>
>

------_=_NextPart_001_01CCB859.5D99352E-- From denghui02@hotmail.com Sun Dec 11 19:06:53 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 3556221F8663 for ; Sun, 11 Dec 2011 19:06:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.184 X-Spam-Level: X-Spam-Status: No, score=-100.184 tagged_above=-999 required=5 tests=[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 A8kR+Gqt9PMB for ; Sun, 11 Dec 2011 19:06:52 -0800 (PST) Received: from col0-omc2-s2.col0.hotmail.com (col0-omc2-s2.col0.hotmail.com [65.55.34.76]) by ietfa.amsl.com (Postfix) with ESMTP id B980F21F863E for ; Sun, 11 Dec 2011 19:06:52 -0800 (PST) Received: from COL118-W36 ([65.55.34.72]) by col0-omc2-s2.col0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 11 Dec 2011 19:06:52 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_8dfafe2e-870d-4618-b57d-a3919b8f2f48_" X-Originating-IP: [125.71.208.209] From: Hui Deng To: Date: Mon, 12 Dec 2011 11:06:51 +0800 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 12 Dec 2011 03:06:52.0280 (UTC) FILETIME=[18C2A780:01CCB87B] Subject: [mif] MIF 82th 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: Mon, 12 Dec 2011 03:06:53 -0000 --_8dfafe2e-870d-4618-b57d-a3919b8f2f48_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 8bit Hello all Please kindly help to review 82th minutes, http://www.ietf.org/proceedings/82/minutes/mif.txt Appreciate Peter's great effort for script. Best regards, -Co-Chairs --_8dfafe2e-870d-4618-b57d-a3919b8f2f48_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: 8bit
Hello all
 
Please kindly help to review 82th minutes,
http://www.ietf.org/proceedings/82/minutes/mif.txt
 
Appreciate Peter's great effort for script.
 
Best regards,
 
-Co-Chairs
 
--_8dfafe2e-870d-4618-b57d-a3919b8f2f48_-- From alexandru.petrescu@gmail.com Mon Dec 12 04:19: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 E852B21F8B51 for ; Mon, 12 Dec 2011 04:19:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] 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 tFVn5rgJ2Vi9 for ; Mon, 12 Dec 2011 04:19:04 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 2234121F8B3D for ; Mon, 12 Dec 2011 04:19:03 -0800 (PST) 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 pBCCJ2WA002372 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 12 Dec 2011 13:19:02 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id pBCCJ1Q1011573 for ; Mon, 12 Dec 2011 13:19:01 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id pBCCJ0s6028510 for ; Mon, 12 Dec 2011 13:19:01 +0100 Message-ID: <4EE5F135.2070407@gmail.com> Date: Mon, 12 Dec 2011 13:19:01 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: mif@ietf.org References: <20111209213221.3695.57478@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [mif] FW: New Liaison Statement, "OMA Open Connection Manager API (OpenCMAPI)" 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, 12 Dec 2011 12:19:05 -0000 There is a MIF api? (I didn't know). Some mobility related software was implemented managing connections and it used Socket Interface (as an "api"). For example there is RFC4584 "Extension to Sockets API for Mobile IPv6". But what is MIF api? Alex Le 10/12/2011 16:12, Hui Deng a écrit : > Hello all > > OMA CD wg would like to align their connection manager API design work > with MIF api. > Feel free to comment on it. > > thanks > > -Hui > > > Subject: New Liaison Statement, "OMA Open Connection Manager API > (OpenCMAPI)" > > From: lsmt@ietf.org > > To: mrw@lilacglade.org; denghui02@hotmail.com > > Date: Fri, 9 Dec 2011 21:32:21 +0000 > > CC: rdroms.ietf@gmail.com; jari.arkko@piuha.net; mif@ietf.org; > msk@cloudmark.com; OMA-LIAISON@MAIL.OPENMOBILEALLIANCE.ORG; > OMA-PLENARY@MAIL.OPENMOBILEALLIANCE.ORG; OMA-CD@MAIL.OPENMOBILEALLIANCE.ORG > > > > Title: OMA Open Connection Manager API (OpenCMAPI) > > Submission Date: 2011-12-08 > > URL of the IETF Web page: /liaison/1120/ > > > > From: Open Mobile Alliance (Thierry Berisot ) > > To: Multiple Interfaces (mrw@lilacglade.org, denghui02@hotmail.com) > > Cc: Ralph Droms ,Jari Arkko > ,Multiple Interfaces Discussion List > ,Murray Kucherawy > ,, MA-PLENARY@MAIL.OPENMOBILEALLIANCE.ORG>, > > Reponse Contact: > > Technical Contact: > > Purpose: For information > > > > Body: > > Attachment(s): > > > > OMA Open Connection Manager API (OpenCMAPI) > https://datatracker.ietf.org/documents/LIAISON/file1301.doc > > > > > > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif From pierrick.seite@orange.com Mon Dec 12 05:01:03 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 E718C21F8B27 for ; Mon, 12 Dec 2011 05:01:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] 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 43fOLHMbMATL for ; Mon, 12 Dec 2011 05:01:03 -0800 (PST) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by ietfa.amsl.com (Postfix) with ESMTP id 1229E21F8B2A for ; Mon, 12 Dec 2011 05:01:03 -0800 (PST) Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 8F411AB0022; Mon, 12 Dec 2011 14:02:08 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id D73B9AB0036; Mon, 12 Dec 2011 14:01:58 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 Dec 2011 14:00:12 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 12 Dec 2011 14:00:11 +0100 Message-ID: <843DA8228A1BA74CA31FB4E111A5C46202168E6F@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <4EE5F135.2070407@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mif] FW: New Liaison Statement, "OMA Open Connection Manager API (OpenCMAPI)" Thread-Index: Acy4yD7osXorfCXDQaKCeRQCl44EUQABCL3g References: <20111209213221.3695.57478@ietfa.amsl.com> <4EE5F135.2070407@gmail.com> From: To: , X-OriginalArrivalTime: 12 Dec 2011 13:00:12.0557 (UTC) FILETIME=[FC2DD3D0:01CCB8CD] Subject: Re: [mif] FW: New Liaison Statement, "OMA Open Connection Manager API (OpenCMAPI)" 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, 12 Dec 2011 13:01:04 -0000 Hi Alex, Actually, the MIF WG is expected to specify an API. Hereafter is the = corresponding part of the charter: 3) MIF API: While no changes are needed for applications to run on multiple interface hosts, a new API could provide additional services to applications running on hosts attached to multiple provisioning domains. For instance, these services could assist advanced applications in having greater control over first-hop, source address and/or DNS selection issues. This API will be defined as an abstract interface specification, i.e., specific details about mapping to operating system primitives or programming language will be left out. Pierrick > -----Message d'origine----- > De=A0: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part = de > Alexandru Petrescu > Envoy=E9=A0: lundi 12 d=E9cembre 2011 13:19 > =C0=A0: mif@ietf.org > Objet=A0: Re: [mif] FW: New Liaison Statement, "OMA Open Connection = Manager > API (OpenCMAPI)" >=20 > There is a MIF api? (I didn't know). >=20 > Some mobility related software was implemented managing connections = and > it used Socket Interface (as an "api"). For example there is RFC4584 > "Extension to Sockets API for Mobile IPv6". >=20 > But what is MIF api? >=20 > Alex >=20 > Le 10/12/2011 16:12, Hui Deng a =E9crit : > > Hello all > > > > OMA CD wg would like to align their connection manager API design = work > > with MIF api. > > Feel free to comment on it. > > > > thanks > > > > -Hui > > > > > Subject: New Liaison Statement, "OMA Open Connection Manager API > > (OpenCMAPI)" > > > From: lsmt@ietf.org > > > To: mrw@lilacglade.org; denghui02@hotmail.com > > > Date: Fri, 9 Dec 2011 21:32:21 +0000 > > > CC: rdroms.ietf@gmail.com; jari.arkko@piuha.net; mif@ietf.org; > > msk@cloudmark.com; OMA-LIAISON@MAIL.OPENMOBILEALLIANCE.ORG; > > OMA-PLENARY@MAIL.OPENMOBILEALLIANCE.ORG; OMA- > CD@MAIL.OPENMOBILEALLIANCE.ORG > > > > > > Title: OMA Open Connection Manager API (OpenCMAPI) > > > Submission Date: 2011-12-08 > > > URL of the IETF Web page: /liaison/1120/ > > > > > > From: Open Mobile Alliance (Thierry Berisot > ) > > > To: Multiple Interfaces (mrw@lilacglade.org, = denghui02@hotmail.com) > > > Cc: Ralph Droms ,Jari Arkko > > ,Multiple Interfaces Discussion List > > ,Murray Kucherawy > > ,, > MA-PLENARY@MAIL.OPENMOBILEALLIANCE.ORG>, CD@MAIL.OPENMOBILEALLIANCE.ORG> > > > Reponse Contact: > > > Technical Contact: > > > Purpose: For information > > > > > > Body: > > > Attachment(s): > > > > > > OMA Open Connection Manager API (OpenCMAPI) > > https://datatracker.ietf.org/documents/LIAISON/file1301.doc > > > > > > > > > > > > _______________________________________________ > > mif mailing list > > mif@ietf.org > > https://www.ietf.org/mailman/listinfo/mif >=20 >=20 > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif From denghui02@hotmail.com Thu Dec 15 04:09:36 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 D992D21F8464 for ; Thu, 15 Dec 2011 04:09:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.184 X-Spam-Level: X-Spam-Status: No, score=-100.184 tagged_above=-999 required=5 tests=[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 p4n6fYC1Zuk5 for ; Thu, 15 Dec 2011 04:09:36 -0800 (PST) Received: from col0-omc2-s4.col0.hotmail.com (col0-omc2-s4.col0.hotmail.com [65.55.34.78]) by ietfa.amsl.com (Postfix) with ESMTP id ECBAE21F8463 for ; Thu, 15 Dec 2011 04:09:35 -0800 (PST) Received: from COL118-W22 ([65.55.34.71]) by col0-omc2-s4.col0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 15 Dec 2011 04:09:35 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_afdd9c02-3058-42dc-8cc0-6cdd14b58ca5_" X-Originating-IP: [221.130.253.135] From: Hui Deng To: , Margaret Date: Thu, 15 Dec 2011 20:09:35 +0800 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 15 Dec 2011 12:09:35.0585 (UTC) FILETIME=[693DED10:01CCBB22] Subject: [mif] Adoption of API document as the MIF WG 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: Thu, 15 Dec 2011 12:09:37 -0000 --_afdd9c02-3058-42dc-8cc0-6cdd14b58ca5_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 8bit Hello all Based on last time IETF 82th MIF meeting, we are calling for the adoption of API document as the working group document in the mailing list. Just want to conform if anybody have different opinion on this. thanks -Chairs --_afdd9c02-3058-42dc-8cc0-6cdd14b58ca5_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: 8bit
Hello all
 
Based on last time IETF 82th MIF meeting, we are calling for the adoption of API document as the working group document in the mailing list.
Just want to conform if anybody have different opinion on this.
 
thanks
 
-Chairs
--_afdd9c02-3058-42dc-8cc0-6cdd14b58ca5_-- From denghui@chinamobile.com Thu Dec 15 04:17:05 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 BCD1021F84D7 for ; Thu, 15 Dec 2011 04:17:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.377 X-Spam-Level: X-Spam-Status: No, score=-0.377 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RELAY_IS_221=2.222] 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 LQtQYzVSo-b0 for ; Thu, 15 Dec 2011 04:17:05 -0800 (PST) Received: from imss.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 2E09921F84C9 for ; Thu, 15 Dec 2011 04:17:04 -0800 (PST) Received: from imss.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id CAE9FE838; Thu, 15 Dec 2011 20:16:57 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by imss.chinamobile.com (Postfix) with ESMTP id BDCA3E837; Thu, 15 Dec 2011 20:16:57 +0800 (CST) Received: from Hui ([10.2.43.49]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2011121520165368-19667 ; Thu, 15 Dec 2011 20:16:53 +0800 From: "Hui Deng" To: "'Andrew Sullivan'" , "'Templin, Fred L'" References: <4EC5B720.8020605@gmail.com> <83A7D27A-9036-4252-AC94-3A89125C961B@nominum.com> <4EC63ECC.8010700@gmail.com> <20111119220355.GA893@shinkuro.com> <20111128181115.GC45293@shinkuro.com> In-Reply-To: <20111128181115.GC45293@shinkuro.com> Date: Thu, 15 Dec 2011 20:16:58 +0800 Message-ID: <01ed01ccbb23$7127e070$5377a150$@com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acyt+SSiV3nB5GxjQku3toj+zfni4wNKihNg X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2011-12-15 20:16:53, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2011-12-15 20:16:56, Serialize complete at 2011-12-15 20:16:56 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Content-Language: zh-cn X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-18584.000 X-TM-AS-Result: No--18.324-7.0-31-10 X-imss-scan-details: No--18.324-7.0-31-10;No--18.324-7.0-31-10 X-TM-AS-User-Approved-Sender: No;No X-TM-AS-User-Blocked-Sender: No Cc: mif@ietf.org Subject: Re: [mif] IRON as a multiple interface solution 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, 15 Dec 2011 12:17:05 -0000 I agree that Andrew's argument does make sense. You can't tell which service it belongs to just based on FQDN -Hui > -----Original Message----- > From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On Behalf Of > Andrew Sullivan > Sent: Tuesday, November 29, 2011 2:11 AM > To: Templin, Fred L > Cc: mif@ietf.org > Subject: Re: [mif] IRON as a multiple interface solution > > On Mon, Nov 28, 2011 at 09:22:45AM -0800, Templin, Fred L wrote: > > That said, IRON does not preclude the host from accessing > > services within the underlying ISP networks. To do so, > > however, the host would have to use its ISP-delegated > > address(es) and not the VSP-delegated address. > > > > Does this match your understanding? > > The central problem, however, is that if you are looking up the > address for a name, you don't obviously know where it is (i.e. you > don't know what network you need to go to). What I don't get in the > IRON approach is how you cope with the fact that a user simply types > some name into an application. We can't hardly ask them which network > they want to use to look up the name. The MIF approach, as much as it > makes me airsick, does address that issue. > > A > > -- > Andrew Sullivan > ajs@anvilwalrusden.com > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif From denghui@chinamobile.com Thu Dec 15 04:23:20 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 1316C21F844A for ; Thu, 15 Dec 2011 04:23:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.377 X-Spam-Level: X-Spam-Status: No, score=-0.377 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RELAY_IS_221=2.222] 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 sYkxAewuR8hy for ; Thu, 15 Dec 2011 04:23:19 -0800 (PST) Received: from imss.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id EFC4021F8449 for ; Thu, 15 Dec 2011 04:23:18 -0800 (PST) Received: from imss.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id E85AEE80C; Thu, 15 Dec 2011 20:23:09 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by imss.chinamobile.com (Postfix) with ESMTP id DD9A5E63F; Thu, 15 Dec 2011 20:23:09 +0800 (CST) Received: from Hui ([10.2.43.49]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2011121520225609-19704 ; Thu, 15 Dec 2011 20:22:56 +0800 From: "Hui Deng" To: "'Templin, Fred L'" , "'Andrew Sullivan'" References: <4EC5B720.8020605@gmail.com> <83A7D27A-9036-4252-AC94-3A89125C961B@nominum.com> <4EC63ECC.8010700@gmail.com> <20111119220355.GA893@shinkuro.com> <20111128181115.GC45293@shinkuro.com> <01da01ccb0d2$72f6f630$58e4e290$@com> In-Reply-To: Date: Thu, 15 Dec 2011 20:23:00 +0800 Message-ID: <01ee01ccbb24$48fb0950$daf11bf0$@com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acyt+SVzR1PpkUYRTvCp3A+bmVJOzQCYBPHAAB446gAAD8Pa0AKEviEw X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2011-12-15 20:22:56, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2011-12-15 20:23:09, Serialize complete at 2011-12-15 20:23:09 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Content-Language: zh-cn X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-18584.000 X-TM-AS-Result: No--33.094-7.0-31-10 X-imss-scan-details: No--33.094-7.0-31-10;No--33.094-7.0-31-10 X-TM-AS-User-Approved-Sender: No;No X-TM-AS-User-Blocked-Sender: No Cc: mif@ietf.org Subject: Re: [mif] IRON as a multiple interface solution 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, 15 Dec 2011 12:23:20 -0000 Hi Fred, This new interface type is also a kind of virtual interface which has been mentioned in RFC 6418. -Hui > -----Original Message----- > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] > Sent: Saturday, December 03, 2011 12:56 AM > To: Hui Deng; 'Andrew Sullivan' > Cc: mif@ietf.org > Subject: RE: [mif] IRON as a multiple interface solution > > Hi Hui, > > I am saying that IRON defines a new interface type > that would be one among possibly many interfaces of > a mif node. The properties of this interface type > include: > > - maintains stable network layer addresses even > if ISP connections change > - supports session continutity and fault tolerance > as ISP connections change > - avoids end user network renumbering when ISP > connections change in case the mif node acts > as a router > > There is more to it than just this, but the IRON > interface is another mif node interface type and > therefore needs to be taken under consideration, > e.g., for interface selection, source address > selection, etc. > > Thanks - Fred > fred.l.templin@boeing.com > > > -----Original Message----- > > From: Hui Deng [mailto:denghui@chinamobile.com] > > Sent: Friday, December 02, 2011 1:12 AM > > To: Templin, Fred L; 'Andrew Sullivan' > > Cc: mif@ietf.org > > Subject: RE: [mif] IRON as a multiple interface solution > > > > Hi Fred > > > > You are saying current MIF document is compatible with IRON. > > And current MIF document has already solved MIF's issues, > > so guess that IRON is proposing something else like generic > > internet access > > which is out of MIF. > > > > Regards, > > > > -Hui > > > > > -----Original Message----- > > > From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On > > Behalf Of > > > Templin, Fred L > > > Sent: Friday, December 02, 2011 4:10 AM > > > To: Andrew Sullivan > > > Cc: mif@ietf.org > > > Subject: Re: [mif] IRON as a multiple interface solution > > > > > > Hi Andrew, > > > > > > I took the time to go off and look at the mif wg > > > documents. All of it is good work - and all of it > > > is compatible with IRON. > > > > > > The mif documents talk about two primary classes of > > > interfaces: 1) ISP interfaces, and 2) VPN interfaces. > > > IRON introduces a third class of interface which > > > can be considered an "Internet interface". > > > > > > While it is true that most ISP interfaces provide > > > access to the Internet, ISP interfaces have volatile > > > configuration information that can change, e.g., if > > > the ISP point of connection changes. Conversely, the > > > IRON Internet interface has non-volatile configuration > > > information that remains the same even if the ISP > > > connections change (e.g., if the node is mobile). > > > > > > Since ISP interfaces may have access to private > > > namespaces, those interfaces (along with their > > > associated IP addresses) can be chosen for DNS > > > resolution and for accessing services within the > > > private namespace the same as described in the mif > > > documents. Since the IRON Internet interface has > > > a non-volatile configuration on the open Internet, > > > however, it provides a stable handle for default > > > communications with Internet-based correspondents. > > > > > > Again, this is all very compatible with the mif > > > work, and fits like a glove with what IRON expects. > > > > > > Thanks - Fred > > > fred.l.templin@boeing.com > > > > > > > -----Original Message----- > > > > From: Andrew Sullivan [mailto:ajs@anvilwalrusden.com] > > > > Sent: Monday, November 28, 2011 10:11 AM > > > > To: Templin, Fred L > > > > Cc: Hui Deng; Andrew Sullivan; mif@ietf.org > > > > Subject: Re: [mif] IRON as a multiple interface solution > > > > > > > > On Mon, Nov 28, 2011 at 09:22:45AM -0800, Templin, Fred L wrote: > > > > > That said, IRON does not preclude the host from accessing > > > > > services within the underlying ISP networks. To do so, > > > > > however, the host would have to use its ISP-delegated > > > > > address(es) and not the VSP-delegated address. > > > > > > > > > > Does this match your understanding? > > > > > > > > The central problem, however, is that if you are looking up the > > > > address for a name, you don't obviously know where it is (i.e. you > > > > don't know what network you need to go to). What I don't > > get in the > > > > IRON approach is how you cope with the fact that a user > > simply types > > > > some name into an application. We can't hardly ask them > > which network > > > > they want to use to look up the name. The MIF approach, > > as much as it > > > > makes me airsick, does address that issue. > > > > > > > > A > > > > > > > > -- > > > > Andrew Sullivan > > > > ajs@anvilwalrusden.com > > > > > > > _______________________________________________ > > > mif mailing list > > > mif@ietf.org > > > https://www.ietf.org/mailman/listinfo/mif > > > > > > From brian.e.carpenter@gmail.com Thu Dec 15 12:26: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 1C45311E809A for ; Thu, 15 Dec 2011 12:26:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.567 X-Spam-Level: X-Spam-Status: No, score=-103.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, 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 O60U+U4qv4PX for ; Thu, 15 Dec 2011 12:26:13 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5897911E80AD for ; Thu, 15 Dec 2011 12:26:13 -0800 (PST) Received: by eekc14 with SMTP id c14so1253324eek.31 for ; Thu, 15 Dec 2011 12:26:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=b/8/4X/RXtCwfLrHVcvGGakf4ZbW96QAClkx0CVvJEs=; b=kSUdeVo/LafO0Nfo3vlKLqwXIlqM26owvEiRQNPPkVc+EEgFZB2WgPov79mucM1oP3 4ga623hJ2MlNPqqwWGbkNoKNk3Muo4EvHGYrc6j4s63HXs9NJRZkzKTWarqHB7+Uf0UD +Jt7PJkbukWbzVBiUOmTf7CI5oSVi1Qj7ywsk= Received: by 10.205.138.5 with SMTP id iq5mr2331379bkc.76.1323980771139; Thu, 15 Dec 2011 12:26:11 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz. [130.216.38.124]) by mx.google.com with ESMTPS id fa8sm17598767bkc.14.2011.12.15.12.26.08 (version=SSLv3 cipher=OTHER); Thu, 15 Dec 2011 12:26:10 -0800 (PST) Message-ID: <4EEA57DD.6070207@gmail.com> Date: Fri, 16 Dec 2011 09:26:05 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Hui Deng References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Margaret , mif@ietf.org Subject: Re: [mif] Adoption of API document as the MIF WG 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: Thu, 15 Dec 2011 20:26:14 -0000 Um, exact draft name please? Regards Brian Carpenter On 2011-12-16 01:09, Hui Deng wrote: > Hello all > > Based on last time IETF 82th MIF meeting, we are calling for the adoption of API document as the working group document in the mailing list. > Just want to conform if anybody have different opinion on this. > > thanks > > -Chairs > > > ------------------------------------------------------------------------ > > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif From denghui02@gmail.com Thu Dec 15 16:25:38 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 7B15921F84B4 for ; Thu, 15 Dec 2011 16:25:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.598 X-Spam-Level: X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[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 K3QzIOCkhfoB for ; Thu, 15 Dec 2011 16:25:37 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5FE6621F84B5 for ; Thu, 15 Dec 2011 16:25:37 -0800 (PST) Received: by yenm7 with SMTP id m7so2294923yen.31 for ; Thu, 15 Dec 2011 16:25:37 -0800 (PST) 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=o5Di95mc6yVYqHiH4WyAE4L63A+4M9JjcdjDEnxeBW4=; b=bagsp5eDoxDF7e3rWPktkOPx36B3iYRMrjpdKCDZB5+E9Spodhpl4SzKsYvmDnPfTc l3fkjG25/gAmLHJl0L+L2KYGnTWaHEGNRw+3TP6IWTVfzu8w4M2zqUclqnElNU9Uvbzu tJnkC/nMfpIT5U+ZcvOZrkRhotgGdguDn/VAk= MIME-Version: 1.0 Received: by 10.236.124.15 with SMTP id w15mr8221265yhh.120.1323995137032; Thu, 15 Dec 2011 16:25:37 -0800 (PST) Received: by 10.146.118.14 with HTTP; Thu, 15 Dec 2011 16:25:36 -0800 (PST) In-Reply-To: <4EEA57DD.6070207@gmail.com> References: <4EEA57DD.6070207@gmail.com> Date: Fri, 16 Dec 2011 08:25:36 +0800 Message-ID: From: Hui Deng To: Brian E Carpenter Content-Type: multipart/alternative; boundary=20cf300e519dd3c14704b42aa34c Cc: Margaret , mif@ietf.org, Hui Deng Subject: Re: [mif] Adoption of API document as the MIF WG 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: Fri, 16 Dec 2011 00:25:38 -0000 --20cf300e519dd3c14704b42aa34c Content-Type: text/plain; charset=ISO-8859-1 Thanks Brian, this is the link: http://tools.ietf.org/id/draft-liu-mif-api-extension-06.txt -Hui 2011/12/16 Brian E Carpenter > Um, exact draft name please? > > Regards > Brian Carpenter > > On 2011-12-16 01:09, Hui Deng wrote: > > Hello all > > > > Based on last time IETF 82th MIF meeting, we are calling for the > adoption of API document as the working group document in the mailing list. > > Just want to conform if anybody have different opinion on this. > > > > thanks > > > > -Chairs > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > mif mailing list > > mif@ietf.org > > https://www.ietf.org/mailman/listinfo/mif > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > --20cf300e519dd3c14704b42aa34c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks Brian, this is the link:
=A0
-Hui

2011/12/16 Brian E Carpenter &= lt;brian.e.carpenter@gmail.c= om>
Um, exact draft name please?

R= egards
=A0 Brian Carpenter

On 2011-12-16 01:09, Hui Deng wrote:
> Hello al= l
>
> Based on last time IETF 82th MIF meeting, we are calling = for the adoption of API document as the working group document in the maili= ng list.
> Just want to conform if anybody have different opinion on this.
>= ;
> thanks
>
> -Chairs
>
>
>= ; ------------------------------------------------------------------------<= br> >
> _______________________________________________
> mif ma= iling list
> mif@ietf.org
>= ht= tps://www.ietf.org/mailman/listinfo/mif
_______________________________________________
mif mailing list
mif@ietf.org
https://www.ietf.org/mailman/l= istinfo/mif

--20cf300e519dd3c14704b42aa34c-- From brian.e.carpenter@gmail.com Thu Dec 15 17:43:10 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 AAB501F0C5D for ; Thu, 15 Dec 2011 17:43:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.566 X-Spam-Level: X-Spam-Status: No, score=-103.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, 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 e7jvSSZCpl8V for ; Thu, 15 Dec 2011 17:43:10 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id ED13B1F0C5B for ; Thu, 15 Dec 2011 17:43:09 -0800 (PST) Received: by werb14 with SMTP id b14so266191wer.31 for ; Thu, 15 Dec 2011 17:43:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=59PqzpV/7yASfR0zvveMLQc4ityv4JOIuI1PWhO8d1g=; b=hGidYxLGvixlDlafVL19lH7mzKCuPgzwUaeIF1A1FwU+btsXb8er+of4m1FhkYwCU6 1/y1NqjmcCNtKEOu+9GN92D1cwWhjc8RQoQYiM7ISyc3y2e1q2WvrKZ1FVHrslpk7aei YCBQ0EOUm4JeoKe1L2bDdodtN1BhNcvTLgtlk= Received: by 10.216.135.150 with SMTP id u22mr2404298wei.35.1323999787967; Thu, 15 Dec 2011 17:43:07 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz. [130.216.38.124]) by mx.google.com with ESMTPS id m5sm10996119wie.2.2011.12.15.17.43.05 (version=SSLv3 cipher=OTHER); Thu, 15 Dec 2011 17:43:07 -0800 (PST) Message-ID: <4EEAA231.606@gmail.com> Date: Fri, 16 Dec 2011 14:43:13 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Hui Deng References: <4EEA57DD.6070207@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Margaret , mif@ietf.org, Hui Deng Subject: Re: [mif] Adoption of API document as the MIF WG 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: Fri, 16 Dec 2011 01:43:10 -0000 Thanks. I think it's reasonable to adopt this draft. Regards Brian On 2011-12-16 13:25, Hui Deng wrote: > Thanks Brian, this is the link: > http://tools.ietf.org/id/draft-liu-mif-api-extension-06.txt > > -Hui > > 2011/12/16 Brian E Carpenter > >> Um, exact draft name please? >> >> Regards >> Brian Carpenter >> >> On 2011-12-16 01:09, Hui Deng wrote: >>> Hello all >>> >>> Based on last time IETF 82th MIF meeting, we are calling for the >> adoption of API document as the working group document in the mailing list. >>> Just want to conform if anybody have different opinion on this. >>> >>> thanks >>> >>> -Chairs >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> mif mailing list >>> mif@ietf.org >>> https://www.ietf.org/mailman/listinfo/mif >> _______________________________________________ >> mif mailing list >> mif@ietf.org >> https://www.ietf.org/mailman/listinfo/mif >> > From brian.e.carpenter@gmail.com Thu Dec 15 18:02:31 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 AE7811F0C61 for ; Thu, 15 Dec 2011 18:02:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.567 X-Spam-Level: X-Spam-Status: No, score=-103.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, 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 fhYsYQTBS07z for ; Thu, 15 Dec 2011 18:02:30 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6CE6D1F0C48 for ; Thu, 15 Dec 2011 18:02:30 -0800 (PST) Received: by wgbdr13 with SMTP id dr13so4018179wgb.13 for ; Thu, 15 Dec 2011 18:02:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=Pj5zK73bRiT+6s2n1fdYmySTOKe96WCEKOAKTieJbWc=; b=j6BotIoaUUs+t+M4Gs2kN8p8f8nwcDjRRDL74tXVdorBloOvgQKNyCeG8hgztJ10zq njC+BgsRRaqyFZSbPDN5Y9PnTpu2Ei35rjcQm+X+PBuu0KMgq10Gobx9Dc7uaVCeFYmf kE/4JA9abvagVNAjH3Ik7XVkXlwuUGrFe/+AA= Received: by 10.180.93.228 with SMTP id cx4mr9613654wib.19.1324000949650; Thu, 15 Dec 2011 18:02:29 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz. [130.216.38.124]) by mx.google.com with ESMTPS id ei9sm11051599wid.0.2011.12.15.18.02.28 (version=SSLv3 cipher=OTHER); Thu, 15 Dec 2011 18:02:29 -0800 (PST) Message-ID: <4EEAA6BC.7060402@gmail.com> Date: Fri, 16 Dec 2011 15:02:36 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: mif@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [mif] Question about draft-liu-mif-api-extension-06 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, 16 Dec 2011 02:02:31 -0000 I realise that this is a description of a conceptual API, not a concrete one, but I still have a concrete question. A provisioning domain is defined in RFC 6418 as "A set of consistent configuration information (e.g., default router, network prefixes, DNS) and the corresponding interface." Don't we need a notion of Provisioning Domain Identifier to go with that? Interfaces are identified by Zone Identifiers according to RFC 4007. Is there any reason that the existing concept of Zone Identifier can't be extended to cover provisioning domains? I would like some clarity about this, to ensure that draft-carpenter-6man-uri-zoneid is also valid for MIF. Regards Brian Carpenter From Ted.Lemon@nominum.com Thu Dec 15 22:07:28 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 8FD1621F85DB for ; Thu, 15 Dec 2011 22:07:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.549 X-Spam-Level: X-Spam-Status: No, score=-106.549 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 7MoL-yngESqH for ; Thu, 15 Dec 2011 22:07:28 -0800 (PST) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by ietfa.amsl.com (Postfix) with ESMTP id C4D7421F842F for ; Thu, 15 Dec 2011 22:07:27 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKTurgH+1INwJb5m0YTwsbOHJDy41blRZZ@postini.com; Thu, 15 Dec 2011 22:07:27 PST 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 B06061B82BB for ; Thu, 15 Dec 2011 22:07:26 -0800 (PST) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (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 A3004190052; Thu, 15 Dec 2011 22:07:26 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-02.WIN.NOMINUM.COM ([64.89.228.134]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.01.0339.001; Thu, 15 Dec 2011 22:07:26 -0800 From: Ted Lemon To: Brian E Carpenter Thread-Topic: [mif] Question about draft-liu-mif-api-extension-06 Thread-Index: AQHMu5bIB+1059uypEOzUwWDBsGI7pXegOWA Date: Fri, 16 Dec 2011 06:07:26 +0000 Message-ID: <3529E2B2-B8A4-45CB-A7E0-22E67F31BA6F@nominum.com> References: <4EEAA6BC.7060402@gmail.com> In-Reply-To: <4EEAA6BC.7060402@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_3529E2B2B8A445CBA7E022E67F31BA6Fnominumcom_" MIME-Version: 1.0 Cc: "" Subject: Re: [mif] Question about draft-liu-mif-api-extension-06 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, 16 Dec 2011 06:07:28 -0000 --_000_3529E2B2B8A445CBA7E022E67F31BA6Fnominumcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Dec 15, 2011, at 9:02 PM, Brian E Carpenter wrote: Don't we need a notion of Provisioning Domain Identifier to go with that? Interfaces are identified by Zone Identifiers according to RFC 4007. Is there any reason that the existing concept of Zone Identifier can't be extended to cover provisioning domains? Send text. --_000_3529E2B2B8A445CBA7E022E67F31BA6Fnominumcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <36DB214A56B538469F13AD5C2E55A71A@nominum.com> Content-Transfer-Encoding: quoted-printable
On Dec 15, 2011, at 9:02 PM, Brian E Carpenter wrote:
Don't we need a notion of Provisioning Domain Identifier to
go with that? Interfaces are identified by Zone Identifiers
according to RFC 4007. Is there any reason that the existing concept
of Zone Identifier can't be extended to cover provisioning domains?<= /blockquote>

Send text.

--_000_3529E2B2B8A445CBA7E022E67F31BA6Fnominumcom_-- From pierrick.seite@orange.com Fri Dec 16 01:01: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 A694221F899D for ; Fri, 16 Dec 2011 01:01:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 iZ96zEFCUoWc for ; Fri, 16 Dec 2011 01:01:13 -0800 (PST) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by ietfa.amsl.com (Postfix) with ESMTP id 7D77121F8511 for ; Fri, 16 Dec 2011 01:01:13 -0800 (PST) Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 193514110B0; Fri, 16 Dec 2011 10:02:20 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id 0FC1041104C; Fri, 16 Dec 2011 10:02:20 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 16 Dec 2011 10:01:11 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCBBD1.417ECD83" Date: Fri, 16 Dec 2011 10:01:10 +0100 Message-ID: <843DA8228A1BA74CA31FB4E111A5C4620216981F@ftrdmel0.rd.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mif] Adoption of API document as the MIF WG document Thread-Index: Acy7ImyoRLQe7m9oS/68npzg+vaLxQArbgqQ References: From: To: , , X-OriginalArrivalTime: 16 Dec 2011 09:01:11.0529 (UTC) FILETIME=[41E99D90:01CCBBD1] Subject: Re: [mif] Adoption of API document as the MIF WG 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: Fri, 16 Dec 2011 09:01:14 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCBBD1.417ECD83 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, =20 I support the adoption of this I-D. IMHO, the proposed API model would = allow to align our effort with the OMA-DM API. However, the liaison is = to be clarified.=20 =20 Pierrick =20 De : mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part de = Hui Deng Envoy=E9 : jeudi 15 d=E9cembre 2011 13:10 =C0 : mif@ietf.org; Margaret Objet : [mif] Adoption of API document as the MIF WG document =20 Hello all =20 Based on last time IETF 82th MIF meeting, we are calling for the = adoption of API document as the working group document in the mailing = list. Just want to conform if anybody have different opinion on this. =20 thanks =20 -Chairs ------_=_NextPart_001_01CCBBD1.417ECD83 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 

I support the adoption of this I-D. IMHO, the proposed = API model would allow to align our effort with the OMA-DM API. However, the = liaison is to be clarified.

 

Pierrick

 

De : mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part de = Hui Deng
Envoy=E9 : jeudi 15 d=E9cembre 2011 13:10
=C0 : mif@ietf.org; Margaret
Objet : [mif] Adoption of API document as the MIF WG = document

 

Hello all
 
Based on last time IETF 82th MIF meeting, we are calling for the = adoption of API document as the working group document in the mailing list.
Just want to conform if anybody have different opinion on this.
 
thanks
 
-Chairs

------_=_NextPart_001_01CCBBD1.417ECD83-- From simon.perreault@viagenie.ca Fri Dec 16 08:25:35 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 2FCD121F8B92 for ; Fri, 16 Dec 2011 08:25:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599] 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 NoOX89gYnsue for ; Fri, 16 Dec 2011 08:25:34 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by ietfa.amsl.com (Postfix) with ESMTP id 71B8921F8B8A for ; Fri, 16 Dec 2011 08:25:34 -0800 (PST) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id A950A20E37 for ; Fri, 16 Dec 2011 11:25:03 -0500 (EST) Message-ID: <4EEB70DF.3070201@viagenie.ca> Date: Fri, 16 Dec 2011 11:25:03 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111115 Thunderbird/8.0 MIME-Version: 1.0 To: mif@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [mif] Adoption of API document as the MIF WG 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: Fri, 16 Dec 2011 16:25:35 -0000 On 2011-12-15 07:09, Hui Deng wrote: > Based on last time IETF 82th MIF meeting, we are calling for the adoption of API > document as the working group document in the mailing list. > Just want to conform if anybody have different opinion on this. I've always felt uneasy with this draft. At the Québec meeting I went to the mic and argued, perhaps incoherently, that this was not what we needed. Since then I've had time to understand exactly what caused my uneasiness. As described in the RFC6419, applications currently do a lot of hackish (read "evil") things to try and guess what would be correct behaviour. Each app needs to reimplement this intelligence. Many apps get many things wrong. This is the mess we're in now. I feel that the API draft tries to standardize the various incompatible APIs we have on various platforms, the very APIs that are currently used by apps for their hackish behaviour. I think it will make it easier for applications to implement hackish behaviour. It will perpetuate the mess we're in. What is needed is a *very* high-level API, maybe based on happy eyeballs. This will avoid reinventing the wheel in each app. Something like a single function call, with flags to indicate desired aspects of the connection to be established, and the stack figures out the rest. I don't think standardizing a low-level API such as is described in the API draft is useful. Actually, I think it could very well be harmful, by encouraging applications to reinvent the wheel. And let me finish by preemptively addressing one possible rebuttal... Section 3.3.2 says this: 3.3.2. High Level API Applications are generally expected to originate connections using some general-purpose high-level API suited to their particular function. It is likely that different applications may use different high-level APIs to communicate, depending on their particular needs. We do not describe the functioning of such high-level APIs; however, one such API under current consideration is the Happy Eyeballs for MIF [reference]. These APIs are expected to be able to be implemented using functionality like that described in the MIF API. This section does not say why a low-level API needs to be *standardized*. I agree it needs to *exist* for a high-level API to be standardized. Low-level APIs already do exist in various platform-dependent forms, as evidenced by RFC6419. You can put this email in the "against adoption" bucket. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From Ted.Lemon@nominum.com Fri Dec 16 12:50:30 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 1CB8E1F0C4C for ; Fri, 16 Dec 2011 12:50:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.55 X-Spam-Level: X-Spam-Status: No, score=-106.55 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 TP10ZB1KBWj6 for ; Fri, 16 Dec 2011 12:50:29 -0800 (PST) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by ietfa.amsl.com (Postfix) with ESMTP id 1A81B1F0C3F for ; Fri, 16 Dec 2011 12:50:28 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKTuuvDoN/66ZtmYQjWfcKiBN4K+rv8odO@postini.com; Fri, 16 Dec 2011 12:50:29 PST 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 B63291B82D0 for ; Fri, 16 Dec 2011 12:50:21 -0800 (PST) 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 1E2E7190052; Fri, 16 Dec 2011 12:50:19 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-02.WIN.NOMINUM.COM ([64.89.228.134]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.01.0339.001; Fri, 16 Dec 2011 12:50:19 -0800 From: Ted Lemon To: Simon Perreault Thread-Topic: [mif] Adoption of API document as the MIF WG document Thread-Index: AQHMuyJrBXZGqHrIRk6m9t2t9A95k5XfLl6AgABKEAA= Date: Fri, 16 Dec 2011 20:50:18 +0000 Message-ID: <79DAA562-B463-4D11-A4E5-AEE1325531A0@nominum.com> References: <4EEB70DF.3070201@viagenie.ca> In-Reply-To: <4EEB70DF.3070201@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_79DAA562B4634D11A4E5AEE1325531A0nominumcom_" MIME-Version: 1.0 Cc: "" Subject: Re: [mif] Adoption of API document as the MIF WG 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: Fri, 16 Dec 2011 20:50:30 -0000 --_000_79DAA562B4634D11A4E5AEE1325531A0nominumcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Dec 16, 2011, at 11:25 AM, Simon Perreault wrote: I feel that the API draft tries to standardize the various incompatible API= s we have on various platforms, the very APIs that are currently used by ap= ps for their hackish behaviour. I think it will make it easier for applicat= ions to implement hackish behaviour. It will perpetuate the mess we're in. This is the same point you raised at the meeting in QC, and it's wrong for = the same reason: this API is not intended to be used by applications. It = is intended to describe all of the functionality that's required to impleme= nt a high-level API, which would then be used by applications. There is pretty broad agreement that no single high-level API will address = every use case: happy eyeballs is nice for certain use cases, but not for a= ll, for example. So we could try to enumerate every possible sort of high= -level API and then document each of these, or we can try to tease out the = functionality that any such API would require, and document that. This sp= ec is intended to serve the latter purpose. The question of whether applications will program to this API is then ortho= gonal to the question of whether the API itself is useful. You propose th= at if we don't define an API, applications will not use it, but in fact eac= h operating system already has an incomplete API that looks something like = what we are trying to document here. So right now, applications can alrea= dy misbehave in the way that you fear. However, right now, if they do so, they will do so in a different way on ea= ch operating system, and indeed may simply not work on some operating syste= ms because those systems do not provide any means to accomplish with a MIF-= capable application needs to accomplish. So by not documenting a low-leve= l MIF API, what we do is make the scenario you are concerned about worse, n= ot better. --_000_79DAA562B4634D11A4E5AEE1325531A0nominumcom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
On Dec 16, 2011, at 11:25 AM, Simon Perreault wrote:
I feel that the API draft tries to standardize the various incompatible APIs= we have on various platforms, the very APIs that are currently used by app= s for their hackish behaviour. I think it will make it easier for applicati= ons to implement hackish behaviour. It will perpetuate the mess we're in.

This is the same point you raised at the meeting in QC, and it's wrong= for the same reason: this API is not intended to be used by applications. =   It is intended to describe all of the functionality that's required = to implement a high-level API, which would then be used by applications.

There is pretty broad agreement that no single high-level API will add= ress every use case: happy eyeballs is nice for certain use cases, but not = for all, for example.   So we could try to enumerate every possible so= rt of high-level API and then document each of these, or we can try to tease out the functionality that any such = API would require, and document that.   This spec is intended to serve= the latter purpose.

The question of whether applications will program to this API is then = orthogonal to the question of whether the API itself is useful.   You = propose that if we don't define an API, applications will not use it, but i= n fact each operating system already has an incomplete API that looks something like what we are trying to docu= ment here.   So right now, applications can already misbehave in the w= ay that you fear.

However, right now, if they do so, they will do so in a different way = on each operating system, and indeed may simply not work on some operating = systems because those systems do not provide any means to accomplish with a= MIF-capable application needs to accomplish.   So by not documenting a low-level MIF API, what we do i= s make the scenario you are concerned about worse, not better.

--_000_79DAA562B4634D11A4E5AEE1325531A0nominumcom_-- From brian.e.carpenter@gmail.com Sun Dec 18 14:17: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 A763521F85B8 for ; Sun, 18 Dec 2011 14:17:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.392 X-Spam-Level: X-Spam-Status: No, score=-102.392 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, 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 xHDFz0Yz5D-u for ; Sun, 18 Dec 2011 14:17:41 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 26F5821F850D for ; Sun, 18 Dec 2011 14:17:41 -0800 (PST) Received: by qcsf15 with SMTP id f15so3394951qcs.31 for ; Sun, 18 Dec 2011 14:17:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=h1D14xP3x7x9yG/5kAjAoHsgJMwAOFM4K09fSIeZWfo=; b=HnpixObVr10e5237mAB0UFoPvLF2mRSyTL/n10jOF3YhzZx6UFvsf1dcuQXEdtOSiI VCp/1hjm5VWnB/sBmJyY9dar/g8tLc677xL3iaJ893s2OgeG7WrqMn56deu1G5x0BS5T x2bX5+TiAGiSAQQH/zcjYnuladXswTz1JSmMw= Received: by 10.229.78.68 with SMTP id j4mr4518145qck.37.1324246660597; Sun, 18 Dec 2011 14:17:40 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz. [130.216.38.124]) by mx.google.com with ESMTPS id v5sm35725887qao.21.2011.12.18.14.17.37 (version=SSLv3 cipher=OTHER); Sun, 18 Dec 2011 14:17:39 -0800 (PST) Message-ID: <4EEE667F.9040000@gmail.com> Date: Mon, 19 Dec 2011 11:17:35 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ted Lemon References: <4EEAA6BC.7060402@gmail.com> <3529E2B2-B8A4-45CB-A7E0-22E67F31BA6F@nominum.com> In-Reply-To: <3529E2B2-B8A4-45CB-A7E0-22E67F31BA6F@nominum.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "" Subject: Re: [mif] Question about draft-liu-mif-api-extension-06 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: Sun, 18 Dec 2011 22:17:41 -0000 On 2011-12-16 19:07, Ted Lemon wrote: >> On Dec 15, 2011, at 9:02 PM, Brian E Carpenter wrote: >> Don't we need a notion of Provisioning Domain Identifier to >> go with that? Interfaces are identified by Zone Identifiers >> according to RFC 4007. Is there any reason that the existing concept >> of Zone Identifier can't be extended to cover provisioning domains? > > Send text. OK. At the moment the draft says: 3.5.7. Provisioning Domain Announcement This message is sent by the MIF API to the subscriber to indicate that a new Provisioning Domain has successfully been configured on an interface. The announcement includes the interface identifier and the provisioning domain identifier. So let's add According to [RFC4007], a scope zone is identified by a Zone Identifier. In practice, a scope zone often corresponds to a single interface, so interfaces are also identified by Zone Identifiers. For consistency, provisioning domains too are identified by Zone Identifiers. In the simplest case, a single Zone Identifier will name an interface, a scope zone, and a provisioning domian. In more complex cases, an interface, the scope zone it reaches, and the corresponding provisioning domain will have different Zone Identifiers. Brian From Ted.Lemon@nominum.com Sun Dec 18 14:50: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 4BDF221F8AB9 for ; Sun, 18 Dec 2011 14:50:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.184 X-Spam-Level: X-Spam-Status: No, score=-104.184 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 rjK0szWFArNq for ; Sun, 18 Dec 2011 14:50:11 -0800 (PST) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by ietfa.amsl.com (Postfix) with ESMTP id 82A1521F888A for ; Sun, 18 Dec 2011 14:50:11 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKTu5uFvzJhBd4oBMo+IhiSh/vRGxMyD5B@postini.com; Sun, 18 Dec 2011 14:50:11 PST 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 782F01B82DA for ; Sun, 18 Dec 2011 14:49:58 -0800 (PST) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (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 0CCBA190052; Sun, 18 Dec 2011 14:49:57 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-02.WIN.NOMINUM.COM ([64.89.228.134]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.01.0339.001; Sun, 18 Dec 2011 14:49:57 -0800 From: Ted Lemon To: Brian E Carpenter Thread-Topic: [mif] Question about draft-liu-mif-api-extension-06 Thread-Index: AQHMu5bIB+1059uypEOzUwWDBsGI7pXegOWAgAQzuYCAAAkJgA== Date: Sun, 18 Dec 2011 22:49:55 +0000 Message-ID: <93D5D0ED-470A-4126-B4E8-8EA5FC4FA032@nominum.com> References: <4EEAA6BC.7060402@gmail.com> <3529E2B2-B8A4-45CB-A7E0-22E67F31BA6F@nominum.com> <4EEE667F.9040000@gmail.com> In-Reply-To: <4EEE667F.9040000@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_93D5D0ED470A4126B4E88EA5FC4FA032nominumcom_" MIME-Version: 1.0 Cc: "" Subject: Re: [mif] Question about draft-liu-mif-api-extension-06 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: Sun, 18 Dec 2011 22:50:12 -0000 --_000_93D5D0ED470A4126B4E88EA5FC4FA032nominumcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Dec 18, 2011, at 5:17 PM, Brian E Carpenter wrote: According to [RFC4007], a scope zone is identified by a Zone Identifier. In practice, a scope zone often corresponds to a single interface, so interfaces are also identified by Zone Identifiers. For consistency, provisioning domains too are identified by Zone Identifiers. In the simplest case, a single Zone Identifier will name an interface, a scope zone, and a provisioning domian. In more complex cases, an interface, the scope zone it reaches, and the corresponding provisioning domain will have different Zone Identifiers. So you're proposing to identify three different things with the same kind o= f identifier? --_000_93D5D0ED470A4126B4E88EA5FC4FA032nominumcom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
On Dec 18, 2011, at 5:17 PM, Brian E Carpenter wrote:
  According to [RFC4007], a scope zone is identified by a Zone Identifier.
  In practice, a scope zone often corresponds to a single interfa= ce, so
  interfaces are also identified by Zone Identifiers. For consist= ency,
  provisioning domains too are identified by Zone Identifiers. In= the
  simplest case, a single Zone Identifier will name an interface,= a scope
  zone, and a provisioning domian. In more complex cases, an inte= rface,
  the scope zone it reaches, and the corresponding provisioning d= omain
  will have different Zone Identifiers.

So you're proposing to identify three different things with the same k= ind of identifier?

--_000_93D5D0ED470A4126B4E88EA5FC4FA032nominumcom_-- From brian.e.carpenter@gmail.com Sun Dec 18 16:25: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 29D2521F8B1D for ; Sun, 18 Dec 2011 16:25:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.996 X-Spam-Level: X-Spam-Status: No, score=-102.996 tagged_above=-999 required=5 tests=[AWL=0.604, BAYES_00=-2.599, 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 BpRVhGm8fWm7 for ; Sun, 18 Dec 2011 16:25:11 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 21D8421F8AF9 for ; Sun, 18 Dec 2011 16:25:11 -0800 (PST) Received: by qcsf15 with SMTP id f15so3432074qcs.31 for ; Sun, 18 Dec 2011 16:25:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=q7JblkBM7p+en90zcnYHkbyuScYbji6PRhbQf8YBHos=; b=kg/dm2V/miCrXUvHHDscLVj3PJifRG6MuTUPIVeQixEpzWwtRK7wTnPC7i798ehP6e 3RUM6Atu4RIDBR3zhPInsZ57kP9tWou3fuyU24yNsGrpUWWNtbW5ZVRhbCiEn1aB3juz 4LePjH5nJFqSK00+vh5ZAWtJjeToC6KkeVOHA= Received: by 10.224.188.16 with SMTP id cy16mr22197108qab.32.1324254309680; Sun, 18 Dec 2011 16:25:09 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz. [130.216.38.124]) by mx.google.com with ESMTPS id ed2sm36393713qab.15.2011.12.18.16.25.07 (version=SSLv3 cipher=OTHER); Sun, 18 Dec 2011 16:25:08 -0800 (PST) Message-ID: <4EEE8460.7090403@gmail.com> Date: Mon, 19 Dec 2011 13:25:04 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ted Lemon References: <4EEAA6BC.7060402@gmail.com> <3529E2B2-B8A4-45CB-A7E0-22E67F31BA6F@nominum.com> <4EEE667F.9040000@gmail.com> <93D5D0ED-470A-4126-B4E8-8EA5FC4FA032@nominum.com> In-Reply-To: <93D5D0ED-470A-4126-B4E8-8EA5FC4FA032@nominum.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "" Subject: Re: [mif] Question about draft-liu-mif-api-extension-06 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, 19 Dec 2011 00:25:12 -0000 On 2011-12-19 11:49, Ted Lemon wrote: > On Dec 18, 2011, at 5:17 PM, Brian E Carpenter wrote: > According to [RFC4007], a scope zone is identified by a Zone Identifier. > In practice, a scope zone often corresponds to a single interface, so > interfaces are also identified by Zone Identifiers. For consistency, > provisioning domains too are identified by Zone Identifiers. In the > simplest case, a single Zone Identifier will name an interface, a scope > zone, and a provisioning domian. In more complex cases, an interface, > the scope zone it reaches, and the corresponding provisioning domain > will have different Zone Identifiers. > > So you're proposing to identify three different things with the same kind of identifier? Yes. RFC4007 and current practice already mean that interfaces and scopes use the same namespace, and this would be a seamless extension. Note that it's a completely unstructured namespace that's local to the host. It maps straight into draft-carpenter-6man-uri-zoneid in a very natural way, too. (We are still far from having a proper handle on naming and addressing scopes; but that is a very different question that I've been poking at uselessly for a while: http://tools.ietf.org/html/draft-carpenter-referral-ps ) Brian From Ted.Lemon@nominum.com Sun Dec 18 17:13: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 B153B21F8B27 for ; Sun, 18 Dec 2011 17:13:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.391 X-Spam-Level: X-Spam-Status: No, score=-105.391 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 BvjsMairGyOr for ; Sun, 18 Dec 2011 17:13:04 -0800 (PST) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by ietfa.amsl.com (Postfix) with ESMTP id D29E221F8B13 for ; Sun, 18 Dec 2011 17:13:03 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKTu6Pky1lKGQ2hhh4uYUeR5pTSiPL7CXW@postini.com; Sun, 18 Dec 2011 17:13:03 PST 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 9D1C91B82C3 for ; Sun, 18 Dec 2011 17:12:50 -0800 (PST) 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 08D3A190052; Sun, 18 Dec 2011 17:12:48 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-02.WIN.NOMINUM.COM ([64.89.228.134]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.01.0339.001; Sun, 18 Dec 2011 17:12:48 -0800 From: Ted Lemon To: Brian E Carpenter Thread-Topic: [mif] Question about draft-liu-mif-api-extension-06 Thread-Index: AQHMu5bIB+1059uypEOzUwWDBsGI7pXegOWAgAQzuYCAAAkJgIAAGpUAgAANVAA= Date: Mon, 19 Dec 2011 01:12:46 +0000 Message-ID: References: <4EEAA6BC.7060402@gmail.com> <3529E2B2-B8A4-45CB-A7E0-22E67F31BA6F@nominum.com> <4EEE667F.9040000@gmail.com> <93D5D0ED-470A-4126-B4E8-8EA5FC4FA032@nominum.com> <4EEE8460.7090403@gmail.com> In-Reply-To: <4EEE8460.7090403@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_CEC94FC2588F4D47A01E3CC39270A5B2nominumcom_" MIME-Version: 1.0 Cc: "" Subject: Re: [mif] Question about draft-liu-mif-api-extension-06 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, 19 Dec 2011 01:13:04 -0000 --_000_CEC94FC2588F4D47A01E3CC39270A5B2nominumcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Dec 18, 2011, at 7:25 PM, Brian E Carpenter wrote: Note that it's a completely unstructured namespace that's local to the host. It maps straight into draft-carpenter-6man-uri-zoneid in a very natural way, too. Okay, I'll take a look at it. Thanks for the pointer. --_000_CEC94FC2588F4D47A01E3CC39270A5B2nominumcom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
On Dec 18, 2011, at 7:25 PM, Brian E Carpenter wrote:
Note that it's a completely unstructured namespace that's local to
the host. It maps straight into draft-carpenter-6man-uri-zoneid
in a very natural way, too.

Okay, I'll take a look at it.   Thanks for the pointer.

--_000_CEC94FC2588F4D47A01E3CC39270A5B2nominumcom_-- From simon.perreault@viagenie.ca Mon Dec 19 07:04:56 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 3021821F8B52 for ; Mon, 19 Dec 2011 07:04:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11] 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 FYB9gdU3lE4z for ; Mon, 19 Dec 2011 07:04:55 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by ietfa.amsl.com (Postfix) with ESMTP id 8E8E121F8B33 for ; Mon, 19 Dec 2011 07:04:55 -0800 (PST) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id EB75E21F04; Mon, 19 Dec 2011 10:04:24 -0500 (EST) Message-ID: <4EEF5278.8040103@viagenie.ca> Date: Mon, 19 Dec 2011 10:04:24 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111115 Thunderbird/8.0 MIME-Version: 1.0 To: Ted Lemon References: <4EEB70DF.3070201@viagenie.ca> <79DAA562-B463-4D11-A4E5-AEE1325531A0@nominum.com> In-Reply-To: <79DAA562-B463-4D11-A4E5-AEE1325531A0@nominum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "" Subject: Re: [mif] Adoption of API document as the MIF WG 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, 19 Dec 2011 15:04:56 -0000 On 2011-12-16 15:50, Ted Lemon wrote: > This is the same point you raised at the meeting in QC, and it's wrong for the > same reason: this API is not intended to be used by applications. It is intended > to describe all of the functionality that's required to implement a high-level > API, which would then be used by applications. Why not just specify the high-level API right away? Why is this intermediate step necessary? As you say, all the underlying functionality is already available on the various platforms out there. I have the feeling that this will be the last step, and that no high-level API will be defined. My point is that this document does not completely fulfill the API milestone because it is too low-level. The important part, the one that would have real potential to fix the mess we're in, is the high-level API. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From Ted.Lemon@nominum.com Mon Dec 19 07:44:31 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 6C88721F8B92 for ; Mon, 19 Dec 2011 07:44:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.995 X-Spam-Level: X-Spam-Status: No, score=-105.995 tagged_above=-999 required=5 tests=[AWL=0.603, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 UdIFaxw5NtKG for ; Mon, 19 Dec 2011 07:44:30 -0800 (PST) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by ietfa.amsl.com (Postfix) with ESMTP id 72D3121F8B85 for ; Mon, 19 Dec 2011 07:44:30 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKTu9b3chOWtfgtuWSCElc1dlmlkY29vJT@postini.com; Mon, 19 Dec 2011 07:44:30 PST 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 878D21B8297 for ; Mon, 19 Dec 2011 07:44:29 -0800 (PST) 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 73A1E190052; Mon, 19 Dec 2011 07:44:28 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-02.WIN.NOMINUM.COM ([64.89.228.134]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.01.0339.001; Mon, 19 Dec 2011 07:44:28 -0800 From: Ted Lemon To: Simon Perreault Thread-Topic: [mif] Adoption of API document as the MIF WG document Thread-Index: AQHMuyJrBXZGqHrIRk6m9t2t9A95k5XfLl6AgABKEACABFZmAIAACzCA Date: Mon, 19 Dec 2011 15:44:27 +0000 Message-ID: <50824C2C-A4A8-4E92-A12D-45082B9CF5DC@nominum.com> References: <4EEB70DF.3070201@viagenie.ca> <79DAA562-B463-4D11-A4E5-AEE1325531A0@nominum.com> <4EEF5278.8040103@viagenie.ca> In-Reply-To: <4EEF5278.8040103@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_50824C2CA4A84E92A12D45082B9CF5DCnominumcom_" MIME-Version: 1.0 Cc: "" Subject: Re: [mif] Adoption of API document as the MIF WG 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, 19 Dec 2011 15:44:31 -0000 --_000_50824C2CA4A84E92A12D45082B9CF5DCnominumcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Dec 19, 2011, at 10:04 AM, Simon Perreault wrote: Why not just specify the high-level API right away? Why is this intermediat= e step necessary? As you say, all the underlying functionality is already a= vailable on the various platforms out there. Which high-level API should we define, Simon? There is no single high-lev= el API that addresses all use cases. And while there is piecemeal support= for features of the low-level API, at the moment hardly anybody supports a= ll the required functionality, as far as I can tell. Also, a lot of the f= unctionality is hidden under mid-level APIs that obscure features that woul= d be required to implement the high-level APIs we want. This is why I thi= nk this work is important. My point is that this document does not completely fulfill the API mileston= e because it is too low-level. The important part, the one that would have = real potential to fix the mess we're in, is the high-level API. This is an easy problem for you to solve: write a document describing the h= igh-level API you think we need. Not everyone sees the problem the same w= ay (obviously!) so this would be a very useful contribution, and I don't th= ink it's wrong for the WG to advance both documents, since they solve diffe= rent problems. --_000_50824C2CA4A84E92A12D45082B9CF5DCnominumcom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <2333AE6CBEE1C94DAB71002EE82CE84F@nominum.com> Content-Transfer-Encoding: quoted-printable
On Dec 19, 2011, at 10:04 AM, Simon Perreault wrote:
Why not just specify the high-level API right away? Why is this intermediate s= tep necessary? As you say, all the underlying functionality is already avai= lable on the various platforms out there.

Which high-level API should we define, Simon?   There is no singl= e high-level API that addresses all use cases.   And while there is pi= ecemeal support for features of the low-level API, at the moment hardly any= body supports all the required functionality, as far as I can tell.   Also, a lot of the functionality is hidden un= der mid-level APIs that obscure features that would be required to implemen= t the high-level APIs we want.   This is why I think this work is impo= rtant.

My point is that this document does not completel= y fulfill the API milestone because it is too low-level. The important part= , the one that would have real potential to fix the mess we're in, is the h= igh-level API.

This is an easy problem for you to solve: write a document describing = the high-level API you think we need.   Not everyone sees the problem = the same way (obviously!) so this would be a very useful contribution, and = I don't think it's wrong for the WG to advance both documents, since they solve different problems.

--_000_50824C2CA4A84E92A12D45082B9CF5DCnominumcom_-- From simon.perreault@viagenie.ca Mon Dec 19 07:50:30 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 1151E21F8B91 for ; Mon, 19 Dec 2011 07:50:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.855 X-Spam-Level: X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599] 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 gQoLCAb-w1ms for ; Mon, 19 Dec 2011 07:50:29 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by ietfa.amsl.com (Postfix) with ESMTP id 3E4CF21F8B90 for ; Mon, 19 Dec 2011 07:50:29 -0800 (PST) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id AA60620D1D; Mon, 19 Dec 2011 10:49:58 -0500 (EST) Message-ID: <4EEF5D26.3080203@viagenie.ca> Date: Mon, 19 Dec 2011 10:49:58 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111115 Thunderbird/8.0 MIME-Version: 1.0 To: Ted Lemon References: <4EEB70DF.3070201@viagenie.ca> <79DAA562-B463-4D11-A4E5-AEE1325531A0@nominum.com> <4EEF5278.8040103@viagenie.ca> <50824C2C-A4A8-4E92-A12D-45082B9CF5DC@nominum.com> In-Reply-To: <50824C2C-A4A8-4E92-A12D-45082B9CF5DC@nominum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "" Subject: Re: [mif] Adoption of API document as the MIF WG 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, 19 Dec 2011 15:50:30 -0000 On 2011-12-19 10:44, Ted Lemon wrote: > On Dec 19, 2011, at 10:04 AM, Simon Perreault wrote: >> Why not just specify the high-level API right away? Why is this intermediate >> step necessary? As you say, all the underlying functionality is already >> available on the various platforms out there. > > Which high-level API should we define, Simon? There is no single high-level API > that addresses all use cases. I disagree, I think it is a solvable problem. > And while there is piecemeal support for features > of the low-level API, at the moment hardly anybody supports all the required > functionality, as far as I can tell. Also, a lot of the functionality is hidden > under mid-level APIs that obscure features that would be required to implement > the high-level APIs we want. This is why I think this work is important. Understood, thanks. > This is an easy problem for you to solve: write a document describing the > high-level API you think we need. Yeah, I know. *sigh* I just don't want the WG to see this document as something that allows us to place a "DONE" checkmark next to the API milestone. There is still API work to be done. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From Ted.Lemon@nominum.com Mon Dec 19 08:24:58 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 A97A521F8801 for ; Mon, 19 Dec 2011 08:24:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.196 X-Spam-Level: X-Spam-Status: No, score=-106.196 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 6yIXKhmRv4im for ; Mon, 19 Dec 2011 08:24:58 -0800 (PST) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by ietfa.amsl.com (Postfix) with ESMTP id E31DA21F853E for ; Mon, 19 Dec 2011 08:24:57 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKTu9lTRh0PGueLTD01FhYqxFknFJZKpWR@postini.com; Mon, 19 Dec 2011 08:24:57 PST 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 D80991B8297 for ; Mon, 19 Dec 2011 08:24:44 -0800 (PST) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (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 C55E4190052; Mon, 19 Dec 2011 08:24:43 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-02.WIN.NOMINUM.COM ([64.89.228.134]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.01.0339.001; Mon, 19 Dec 2011 08:24:43 -0800 From: Ted Lemon To: Simon Perreault Thread-Topic: [mif] Adoption of API document as the MIF WG document Thread-Index: AQHMuyJrBXZGqHrIRk6m9t2t9A95k5XfLl6AgABKEACABFZmAIAACzCAgAABiwCAAAmzgA== Date: Mon, 19 Dec 2011 16:24:43 +0000 Message-ID: <0FECAD9E-E1EB-4849-BF8E-227F49975559@nominum.com> References: <4EEB70DF.3070201@viagenie.ca> <79DAA562-B463-4D11-A4E5-AEE1325531A0@nominum.com> <4EEF5278.8040103@viagenie.ca> <50824C2C-A4A8-4E92-A12D-45082B9CF5DC@nominum.com> <4EEF5D26.3080203@viagenie.ca> In-Reply-To: <4EEF5D26.3080203@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_0FECAD9EE1EB4849BF8E227F49975559nominumcom_" MIME-Version: 1.0 Cc: "" Subject: Re: [mif] Adoption of API document as the MIF WG 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, 19 Dec 2011 16:24:58 -0000 --_000_0FECAD9EE1EB4849BF8E227F49975559nominumcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Dec 19, 2011, at 10:49 AM, Simon Perreault wrote: I just don't want the WG to see this document as something that allows us t= o place a "DONE" checkmark next to the API milestone. There is still API wo= rk to be done. Well, an easy fix for this is to add a milestone that addresses this concer= n. --_000_0FECAD9EE1EB4849BF8E227F49975559nominumcom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
On Dec 19, 2011, at 10:49 AM, Simon Perreault wrote:
I just don't want the WG to see this document as something that allows us to= place a "DONE" checkmark next to the API milestone. There is sti= ll API work to be done.

Well, an easy fix for this is to add a milestone that addresses this c= oncern.

--_000_0FECAD9EE1EB4849BF8E227F49975559nominumcom_-- From simon.perreault@viagenie.ca Mon Dec 19 08:32:52 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 890CF21F8B50 for ; Mon, 19 Dec 2011 08:32:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.227 X-Spam-Level: X-Spam-Status: No, score=-2.227 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599] 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 hgoTf9OS7aHT for ; Mon, 19 Dec 2011 08:32:51 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by ietfa.amsl.com (Postfix) with ESMTP id 7438821F84C9 for ; Mon, 19 Dec 2011 08:32:51 -0800 (PST) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id A737F20E64; Mon, 19 Dec 2011 11:32:20 -0500 (EST) Message-ID: <4EEF6714.40804@viagenie.ca> Date: Mon, 19 Dec 2011 11:32:20 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111115 Thunderbird/8.0 MIME-Version: 1.0 To: Ted Lemon References: <4EEB70DF.3070201@viagenie.ca> <79DAA562-B463-4D11-A4E5-AEE1325531A0@nominum.com> <4EEF5278.8040103@viagenie.ca> <50824C2C-A4A8-4E92-A12D-45082B9CF5DC@nominum.com> <4EEF5D26.3080203@viagenie.ca> <0FECAD9E-E1EB-4849-BF8E-227F49975559@nominum.com> In-Reply-To: <0FECAD9E-E1EB-4849-BF8E-227F49975559@nominum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "" Subject: Re: [mif] Adoption of API document as the MIF WG 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, 19 Dec 2011 16:32:52 -0000 On 2011-12-19 11:24, Ted Lemon wrote: > On Dec 19, 2011, at 10:49 AM, Simon Perreault wrote: >> I just don't want the WG to see this document as something that allows us to >> place a "DONE" checkmark next to the API milestone. There is still API work to >> be done. > > Well, an easy fix for this is to add a milestone that addresses this concern. I'd be happy with that. Something like... 3) MIF API: While no changes are needed for applications to run on multiple interface hosts, a new API could provide additional services to applications running on hosts attached to multiple provisioning domains. For instance, these services could assist advanced applications in having greater control over first-hop, source address and/or DNS selection issues. This API will be defined as an abstract interface specification, i.e., specific details about mapping to operating system primitives or programming language will be left out. 3.1) Low-level API: This API will specify base functionality that a platform needs to make available for the high-level API to be possible. It is intended to be used by applications for most tasks: that will be the high-level API's role. Applications could still call into the low-level API to perform complex, infrequent tasks. 3.2) High-level API: This API will specify functionality intended for applications' frequent tasks. The term "high-level" means that it will abstract the tasks that need to be perform and minimize an application's knowledge of a node's network configuration. It should be easy to use and appropriate for most of tasks commonly performed by applications. If the charter was modified to something like the above then I'd change my position to "support"... Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From Ted.Lemon@nominum.com Mon Dec 19 08:42: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 1E88021F84B4 for ; Mon, 19 Dec 2011 08:42:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.296 X-Spam-Level: X-Spam-Status: No, score=-106.296 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 gSz0z6SmZxfR for ; Mon, 19 Dec 2011 08:42:11 -0800 (PST) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by ietfa.amsl.com (Postfix) with ESMTP id D244221F84A9 for ; Mon, 19 Dec 2011 08:42:10 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKTu9pYXnqLyLEw4376/9vp74KglhUhDCt@postini.com; Mon, 19 Dec 2011 08:42:10 PST 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 6F6DE1B827A for ; Mon, 19 Dec 2011 08:42:09 -0800 (PST) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (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 68F15190052; Mon, 19 Dec 2011 08:42:09 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-02.WIN.NOMINUM.COM ([64.89.228.134]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.01.0339.001; Mon, 19 Dec 2011 08:42:09 -0800 From: Ted Lemon To: Simon Perreault Thread-Topic: [mif] Adoption of API document as the MIF WG document Thread-Index: AQHMuyJrBXZGqHrIRk6m9t2t9A95k5XfLl6AgABKEACABFZmAIAACzCAgAABiwCAAAmzgIAAAiMAgAACvQA= Date: Mon, 19 Dec 2011 16:42:08 +0000 Message-ID: <79196499-DF0F-48AB-B9F3-95897080646F@nominum.com> References: <4EEB70DF.3070201@viagenie.ca> <79DAA562-B463-4D11-A4E5-AEE1325531A0@nominum.com> <4EEF5278.8040103@viagenie.ca> <50824C2C-A4A8-4E92-A12D-45082B9CF5DC@nominum.com> <4EEF5D26.3080203@viagenie.ca> <0FECAD9E-E1EB-4849-BF8E-227F49975559@nominum.com> <4EEF6714.40804@viagenie.ca> In-Reply-To: <4EEF6714.40804@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_79196499DF0F48ABB9F395897080646Fnominumcom_" MIME-Version: 1.0 Cc: "" Subject: Re: [mif] Adoption of API document as the MIF WG 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, 19 Dec 2011 16:42:12 -0000 --_000_79196499DF0F48ABB9F395897080646Fnominumcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Dec 19, 2011, at 11:32 AM, Simon Perreault wrote: I'd be happy with that. Something like... [...] Looks good to me! What do the chairs think? --_000_79196499DF0F48ABB9F395897080646Fnominumcom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
On Dec 19, 2011, at 11:32 AM, Simon Perreault wrote:
I'd be happy with that. Something like...

[...]

Looks good to me!

What do the chairs think?

--_000_79196499DF0F48ABB9F395897080646Fnominumcom_-- From Fred.L.Templin@boeing.com Mon Dec 19 09:44:18 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 3480B1F0C53 for ; Mon, 19 Dec 2011 09:44:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 6EM6s2PezJeS for ; Mon, 19 Dec 2011 09:44:17 -0800 (PST) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by ietfa.amsl.com (Postfix) with ESMTP id 5B9D91F0C52 for ; Mon, 19 Dec 2011 09:44:17 -0800 (PST) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by stl-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id pBJHiRnJ017881 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 19 Dec 2011 11:44:28 -0600 (CST) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id pBJHi4Ik009413; Mon, 19 Dec 2011 09:44:04 -0800 (PST) Received: from XCH-NWHT-06.nw.nos.boeing.com (xch-nwht-06.nw.nos.boeing.com [130.247.25.110]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id pBJHi4Nn009393 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 19 Dec 2011 09:44:04 -0800 (PST) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-06.nw.nos.boeing.com ([130.247.25.110]) with mapi; Mon, 19 Dec 2011 09:44:04 -0800 From: "Templin, Fred L" To: Hui Deng , "'Andrew Sullivan'" Date: Mon, 19 Dec 2011 09:44:00 -0800 Thread-Topic: [mif] IRON as a multiple interface solution Thread-Index: Acyt+SVzR1PpkUYRTvCp3A+bmVJOzQCYBPHAAB446gAAD8Pa0AKEviEwANQukcA= Message-ID: References: <4EC5B720.8020605@gmail.com> <83A7D27A-9036-4252-AC94-3A89125C961B@nominum.com> <4EC63ECC.8010700@gmail.com> <20111119220355.GA893@shinkuro.com> <20111128181115.GC45293@shinkuro.com> <01da01ccb0d2$72f6f630$58e4e290$@com> <01ee01ccbb24$48fb0950$daf11bf0$@com> In-Reply-To: <01ee01ccbb24$48fb0950$daf11bf0$@com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mif@ietf.org" Subject: Re: [mif] IRON as a multiple interface solution 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, 19 Dec 2011 17:44:18 -0000 Hi Hui,=20 > -----Original Message----- > From: Hui Deng [mailto:denghui@chinamobile.com]=20 > Sent: Thursday, December 15, 2011 4:23 AM > To: Templin, Fred L; 'Andrew Sullivan' > Cc: mif@ietf.org > Subject: RE: [mif] IRON as a multiple interface solution >=20 > Hi Fred, >=20 > This new interface type is also a kind of virtual interface=20 > which has been > mentioned in RFC 6418. Yes, I see where virtual interfaces are mentioned in several places in RFC6418. However, that document talks about the virtual interface *near-end* and does not talk about the virtual link itself nor coordination with the virtual interface *far-end(s)*. RFC6418, Section 3.8 is consistent with what the IRON virtual interface near end expects, but IRON goes to the full extent of describing coordinations between the near end and any prospective far-ends. Thanks - Fred fred.l.templin@boeing.com > -Hui >=20 > > -----Original Message----- > > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] > > Sent: Saturday, December 03, 2011 12:56 AM > > To: Hui Deng; 'Andrew Sullivan' > > Cc: mif@ietf.org > > Subject: RE: [mif] IRON as a multiple interface solution > >=20 > > Hi Hui, > >=20 > > I am saying that IRON defines a new interface type > > that would be one among possibly many interfaces of > > a mif node. The properties of this interface type > > include: > >=20 > > - maintains stable network layer addresses even > > if ISP connections change > > - supports session continutity and fault tolerance > > as ISP connections change > > - avoids end user network renumbering when ISP > > connections change in case the mif node acts > > as a router > >=20 > > There is more to it than just this, but the IRON > > interface is another mif node interface type and > > therefore needs to be taken under consideration, > > e.g., for interface selection, source address > > selection, etc. > >=20 > > Thanks - Fred > > fred.l.templin@boeing.com > >=20 > > > -----Original Message----- > > > From: Hui Deng [mailto:denghui@chinamobile.com] > > > Sent: Friday, December 02, 2011 1:12 AM > > > To: Templin, Fred L; 'Andrew Sullivan' > > > Cc: mif@ietf.org > > > Subject: RE: [mif] IRON as a multiple interface solution > > > > > > Hi Fred > > > > > > You are saying current MIF document is compatible with IRON. > > > And current MIF document has already solved MIF's issues, > > > so guess that IRON is proposing something else like generic > > > internet access > > > which is out of MIF. > > > > > > Regards, > > > > > > -Hui > > > > > > > -----Original Message----- > > > > From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On > > > Behalf Of > > > > Templin, Fred L > > > > Sent: Friday, December 02, 2011 4:10 AM > > > > To: Andrew Sullivan > > > > Cc: mif@ietf.org > > > > Subject: Re: [mif] IRON as a multiple interface solution > > > > > > > > Hi Andrew, > > > > > > > > I took the time to go off and look at the mif wg > > > > documents. All of it is good work - and all of it > > > > is compatible with IRON. > > > > > > > > The mif documents talk about two primary classes of > > > > interfaces: 1) ISP interfaces, and 2) VPN interfaces. > > > > IRON introduces a third class of interface which > > > > can be considered an "Internet interface". > > > > > > > > While it is true that most ISP interfaces provide > > > > access to the Internet, ISP interfaces have volatile > > > > configuration information that can change, e.g., if > > > > the ISP point of connection changes. Conversely, the > > > > IRON Internet interface has non-volatile configuration > > > > information that remains the same even if the ISP > > > > connections change (e.g., if the node is mobile). > > > > > > > > Since ISP interfaces may have access to private > > > > namespaces, those interfaces (along with their > > > > associated IP addresses) can be chosen for DNS > > > > resolution and for accessing services within the > > > > private namespace the same as described in the mif > > > > documents. Since the IRON Internet interface has > > > > a non-volatile configuration on the open Internet, > > > > however, it provides a stable handle for default > > > > communications with Internet-based correspondents. > > > > > > > > Again, this is all very compatible with the mif > > > > work, and fits like a glove with what IRON expects. > > > > > > > > Thanks - Fred > > > > fred.l.templin@boeing.com > > > > > > > > > -----Original Message----- > > > > > From: Andrew Sullivan [mailto:ajs@anvilwalrusden.com] > > > > > Sent: Monday, November 28, 2011 10:11 AM > > > > > To: Templin, Fred L > > > > > Cc: Hui Deng; Andrew Sullivan; mif@ietf.org > > > > > Subject: Re: [mif] IRON as a multiple interface solution > > > > > > > > > > On Mon, Nov 28, 2011 at 09:22:45AM -0800, Templin,=20 > Fred L wrote: > > > > > > That said, IRON does not preclude the host from accessing > > > > > > services within the underlying ISP networks. To do so, > > > > > > however, the host would have to use its ISP-delegated > > > > > > address(es) and not the VSP-delegated address. > > > > > > > > > > > > Does this match your understanding? > > > > > > > > > > The central problem, however, is that if you are=20 > looking up the > > > > > address for a name, you don't obviously know where it=20 > is (i.e. you > > > > > don't know what network you need to go to). What I don't > > > get in the > > > > > IRON approach is how you cope with the fact that a user > > > simply types > > > > > some name into an application. We can't hardly ask them > > > which network > > > > > they want to use to look up the name. The MIF approach, > > > as much as it > > > > > makes me airsick, does address that issue. > > > > > > > > > > A > > > > > > > > > > -- > > > > > Andrew Sullivan > > > > > ajs@anvilwalrusden.com > > > > > > > > > _______________________________________________ > > > > mif mailing list > > > > mif@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mif > > > > > > > > > >=20 >=20 > = From Fred.L.Templin@boeing.com Mon Dec 19 09:45:01 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 BCFE511E80AB for ; Mon, 19 Dec 2011 09:45:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 NTcGbc-AmbcE for ; Mon, 19 Dec 2011 09:45:01 -0800 (PST) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by ietfa.amsl.com (Postfix) with ESMTP id 3401011E8096 for ; Mon, 19 Dec 2011 09:45:01 -0800 (PST) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by blv-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id pBJHioF2026752 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 19 Dec 2011 09:44:52 -0800 (PST) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id pBJHioOp011051; Mon, 19 Dec 2011 09:44:50 -0800 (PST) Received: from XCH-NWHT-08.nw.nos.boeing.com (xch-nwht-08.nw.nos.boeing.com [130.247.25.112]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id pBJHioEb011027 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 19 Dec 2011 09:44:50 -0800 (PST) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-08.nw.nos.boeing.com ([130.247.25.112]) with mapi; Mon, 19 Dec 2011 09:44:50 -0800 From: "Templin, Fred L" To: Hui Deng , "'Andrew Sullivan'" Date: Mon, 19 Dec 2011 09:44:49 -0800 Thread-Topic: [mif] IRON as a multiple interface solution Thread-Index: Acyt+SSiV3nB5GxjQku3toj+zfni4wNKihNgANRZoKA= Message-ID: References: <4EC5B720.8020605@gmail.com> <83A7D27A-9036-4252-AC94-3A89125C961B@nominum.com> <4EC63ECC.8010700@gmail.com> <20111119220355.GA893@shinkuro.com> <20111128181115.GC45293@shinkuro.com> <01ed01ccbb23$7127e070$5377a150$@com> In-Reply-To: <01ed01ccbb23$7127e070$5377a150$@com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mif@ietf.org" Subject: Re: [mif] IRON as a multiple interface solution 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, 19 Dec 2011 17:45:01 -0000 Hi Hui, I thought I had addressed Andrew's points in my 12/1/2011 post: http://www.ietf.org/mail-archive/web/mif/current/msg01506.html Does that post clarify things? Thanks - Fred fred.l.templin@boeing.com > -----Original Message----- > From: Hui Deng [mailto:denghui@chinamobile.com]=20 > Sent: Thursday, December 15, 2011 4:17 AM > To: 'Andrew Sullivan'; Templin, Fred L > Cc: mif@ietf.org > Subject: RE: [mif] IRON as a multiple interface solution >=20 > I agree that Andrew's argument does make sense. You can't=20 > tell which service > it belongs to just based on FQDN >=20 > -Hui >=20 > > -----Original Message----- > > From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On=20 > Behalf Of > > Andrew Sullivan > > Sent: Tuesday, November 29, 2011 2:11 AM > > To: Templin, Fred L > > Cc: mif@ietf.org > > Subject: Re: [mif] IRON as a multiple interface solution > >=20 > > On Mon, Nov 28, 2011 at 09:22:45AM -0800, Templin, Fred L wrote: > > > That said, IRON does not preclude the host from accessing > > > services within the underlying ISP networks. To do so, > > > however, the host would have to use its ISP-delegated > > > address(es) and not the VSP-delegated address. > > > > > > Does this match your understanding? > >=20 > > The central problem, however, is that if you are looking up the > > address for a name, you don't obviously know where it is (i.e. you > > don't know what network you need to go to). What I don't get in the > > IRON approach is how you cope with the fact that a user simply types > > some name into an application. We can't hardly ask them=20 > which network > > they want to use to look up the name. The MIF approach, as=20 > much as it > > makes me airsick, does address that issue. > >=20 > > A > >=20 > > -- > > Andrew Sullivan > > ajs@anvilwalrusden.com > > _______________________________________________ > > mif mailing list > > mif@ietf.org > > https://www.ietf.org/mailman/listinfo/mif >=20 >=20 > = From denghui02@gmail.com Mon Dec 19 22:13:47 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 8C62721F842F for ; Mon, 19 Dec 2011 22:13:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.932 X-Spam-Level: X-Spam-Status: No, score=-101.932 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666, 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 VWk19g1SRmDU for ; Mon, 19 Dec 2011 22:13:46 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6E39821F842D for ; Mon, 19 Dec 2011 22:13:46 -0800 (PST) Received: by ggnk5 with SMTP id k5so5078588ggn.31 for ; Mon, 19 Dec 2011 22:13:44 -0800 (PST) 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=L40+X7fsWXLlidr4Sx7XcKhedeA2e5MhTeYyNrVi+Po=; b=oih8ebrAtbNifzHI7dZZR86lDjZbXZX+cGx24LNc1XpkAqeUWk7TSV2QmHv8p/5jHn Qfz7/nYyaad9rVcZw7yvik4FTSno0T+NfTBdI9YD+gNUUtrNXZwiXjai/O8c2t1OBhGt qiLvUcpvT111nh2yZT03EqZNXVFlmo89d8t84= MIME-Version: 1.0 Received: by 10.100.244.14 with SMTP id r14mr283599anh.51.1324361624229; Mon, 19 Dec 2011 22:13:44 -0800 (PST) Received: by 10.146.118.14 with HTTP; Mon, 19 Dec 2011 22:13:44 -0800 (PST) In-Reply-To: <4EEF6714.40804@viagenie.ca> References: <4EEB70DF.3070201@viagenie.ca> <79DAA562-B463-4D11-A4E5-AEE1325531A0@nominum.com> <4EEF5278.8040103@viagenie.ca> <50824C2C-A4A8-4E92-A12D-45082B9CF5DC@nominum.com> <4EEF5D26.3080203@viagenie.ca> <0FECAD9E-E1EB-4849-BF8E-227F49975559@nominum.com> <4EEF6714.40804@viagenie.ca> Date: Tue, 20 Dec 2011 14:13:44 +0800 Message-ID: From: Hui Deng To: Simon Perreault , MIF Mailing List Content-Type: multipart/alternative; boundary=001636c5bf262a95c304b47ff845 Subject: Re: [mif] Adoption of API document as the MIF WG 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: Tue, 20 Dec 2011 06:13:47 -0000 --001636c5bf262a95c304b47ff845 Content-Type: text/plain; charset=ISO-8859-1 This is a new recharter proposal which need to be discussed during next ietf meeting all together thanks -Hui 2011/12/20 Simon Perreault > On 2011-12-19 11:24, Ted Lemon wrote: > >> On Dec 19, 2011, at 10:49 AM, Simon Perreault wrote: >> >>> I just don't want the WG to see this document as something that allows >>> us to >>> place a "DONE" checkmark next to the API milestone. There is still API >>> work to >>> be done. >>> >> >> Well, an easy fix for this is to add a milestone that addresses this >> concern. >> > > I'd be happy with that. Something like... > > 3) MIF API: While no changes are needed for applications to run on > multiple interface hosts, a new API could provide additional services > to applications running on hosts attached to multiple provisioning > domains. For instance, these services could assist advanced > applications in having greater control over first-hop, source address > and/or DNS selection issues. This API will be defined as an abstract > interface specification, i.e., specific details about mapping to > operating system primitives or programming language will be left out. > > 3.1) Low-level API: This API will specify base functionality that a > platform needs to make available for the high-level API to be possible. > It is intended to be used by applications for most tasks: that will be > the > high-level API's role. Applications could still call into the low-level > API > to perform complex, infrequent tasks. > > 3.2) High-level API: This API will specify functionality intended for > applications' frequent tasks. The term "high-level" means that it will > abstract the tasks that need to be perform and minimize an application's > knowledge of a node's network configuration. It should be easy to use > and > appropriate for most of tasks commonly performed by applications. > > If the charter was modified to something like the above then I'd change my > position to "support"... > > > Simon > -- > DTN made easy, lean, and smart --> http://postellation.viagenie.**ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > ______________________________**_________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/**listinfo/mif > --001636c5bf262a95c304b47ff845 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
This is a=A0new recharter proposal which need to be discussed during n= ext ietf meeting all together
=A0
thanks
=A0
-Hui

2011/12/20 Simon Perreault <= ;simon.perreault@viagenie.ca= >
On 2011-12-19 11:24, Ted Lemon wrote:
On Dec 19, 2011, at 10:49 AM, Simon P= erreault wrote:
I just don't want the WG to see t= his document as something that allows us to
place a "DONE" che= ckmark next to the API milestone. There is still API work to
be done.

Well, an easy fix for this is to add a milesto= ne that addresses this concern.

I'd be = happy with that. Something like...

=A03) MIF API: While no changes a= re needed for applications to run on
=A0multiple interface hosts, a new API could provide additional services=A0to applications running on hosts attached to multiple provisioning
= =A0domains. For instance, these services could assist advanced
=A0applic= ations in having greater control over first-hop, source address
=A0and/or DNS selection issues. This API will be defined as an abstract
= =A0interface specification, i.e., specific details about mapping to
=A0o= perating system primitives or programming language will be left out.
=A0 =A03.1) Low-level API: This API will specify base functionality that a=
=A0 =A0platform needs to make available for the high-level API to be possib= le.
=A0 =A0It is intended to be used by applications for most tasks: tha= t will be the
=A0 =A0high-level API's role. Applications could still= call into the low-level API
=A0 =A0to perform complex, infrequent tasks.

=A0 =A03.2) High-level = API: This API will specify functionality intended for
=A0 =A0application= s' frequent tasks. The term "high-level" means that it will=A0 =A0abstract the tasks that need to be perform and minimize an applica= tion's
=A0 =A0knowledge of a node's network configuration. It should be easy t= o use and
=A0 =A0appropriate for most of tasks commonly performed by app= lications.

If the charter was modified to something like the above t= hen I'd change my position to "support"...=20


Simon
--
DTN made easy, lean, and smart --= > http://= postellation.viagenie.ca
NAT64/DNS64 open-source =A0 =A0 =A0 = =A0--> http://= ecdysis.viagenie.ca
STUN/TURN server =A0 =A0 =A0 =A0 =A0 =A0 =A0 --> http://numb.viagenie.ca
____________= ___________________________________
mif mailing list
mif@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/mif

--001636c5bf262a95c304b47ff845-- From denghui@chinamobile.com Mon Dec 19 22:23:19 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 5A7B911E80C6 for ; Mon, 19 Dec 2011 22:23:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.377 X-Spam-Level: X-Spam-Status: No, score=-0.377 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RELAY_IS_221=2.222] 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 0CZRC6Y6YxKI for ; Mon, 19 Dec 2011 22:23:18 -0800 (PST) Received: from imss.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 772FF11E80C7 for ; Mon, 19 Dec 2011 22:22:48 -0800 (PST) Received: from imss.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id 364EEE617; Tue, 20 Dec 2011 14:22:47 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by imss.chinamobile.com (Postfix) with ESMTP id 21E40E709; Tue, 20 Dec 2011 14:22:47 +0800 (CST) Received: from Hui ([10.2.43.49]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2011122014223708-9344 ; Tue, 20 Dec 2011 14:22:37 +0800 From: "Hui Deng" To: "'Templin, Fred L'" , "'Andrew Sullivan'" References: <4EC5B720.8020605@gmail.com> <83A7D27A-9036-4252-AC94-3A89125C961B@nominum.com> <4EC63ECC.8010700@gmail.com> <20111119220355.GA893@shinkuro.com> <20111128181115.GC45293@shinkuro.com> <01da01ccb0d2$72f6f630$58e4e290$@com> <01ee01ccbb24$48fb0950$daf11bf0$@com> In-Reply-To: Date: Tue, 20 Dec 2011 14:22:39 +0800 Message-ID: <008b01ccbedf$c5cb9620$5162c260$@com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acyt+SVzR1PpkUYRTvCp3A+bmVJOzQCYBPHAAB446gAAD8Pa0AKEviEwANQukcAAGomgYA== X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2011-12-20 14:22:37, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2011-12-20 14:22:46, Serialize complete at 2011-12-20 14:22:46 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" Content-Language: zh-cn X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-18594.005 X-TM-AS-Result: No--32.166-7.0-31-10 X-imss-scan-details: No--32.166-7.0-31-10;No--32.166-7.0-31-10 X-TM-AS-User-Approved-Sender: No;No X-TM-AS-User-Blocked-Sender: No Cc: mif@ietf.org Subject: Re: [mif] IRON as a multiple interface solution 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, 20 Dec 2011 06:23:19 -0000 Hi Fred There are multiple places discussing virtual interface(PMIP6, DSMIP6, 3GPP GTP, Connection Manager et al.), I don't know whether IETF is interested in documenting such implementation, Internet Area maybe the right place to discuss it. Thanks -Hui > -----Original Message----- > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] > Sent: Tuesday, December 20, 2011 1:44 AM > To: Hui Deng; 'Andrew Sullivan' > Cc: mif@ietf.org > Subject: RE: [mif] IRON as a multiple interface solution > > Hi Hui, > > > -----Original Message----- > > From: Hui Deng [mailto:denghui@chinamobile.com] > > Sent: Thursday, December 15, 2011 4:23 AM > > To: Templin, Fred L; 'Andrew Sullivan' > > Cc: mif@ietf.org > > Subject: RE: [mif] IRON as a multiple interface solution > > > > Hi Fred, > > > > This new interface type is also a kind of virtual interface > > which has been > > mentioned in RFC 6418. > > Yes, I see where virtual interfaces are mentioned in > several places in RFC6418. However, that document talks > about the virtual interface *near-end* and does not talk > about the virtual link itself nor coordination with the > virtual interface *far-end(s)*. > > RFC6418, Section 3.8 is consistent with what the IRON > virtual interface near end expects, but IRON goes to > the full extent of describing coordinations between > the near end and any prospective far-ends. > > Thanks - Fred > fred.l.templin@boeing.com > > > -Hui > > > > > -----Original Message----- > > > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] > > > Sent: Saturday, December 03, 2011 12:56 AM > > > To: Hui Deng; 'Andrew Sullivan' > > > Cc: mif@ietf.org > > > Subject: RE: [mif] IRON as a multiple interface solution > > > > > > Hi Hui, > > > > > > I am saying that IRON defines a new interface type > > > that would be one among possibly many interfaces of > > > a mif node. The properties of this interface type > > > include: > > > > > > - maintains stable network layer addresses even > > > if ISP connections change > > > - supports session continutity and fault tolerance > > > as ISP connections change > > > - avoids end user network renumbering when ISP > > > connections change in case the mif node acts > > > as a router > > > > > > There is more to it than just this, but the IRON > > > interface is another mif node interface type and > > > therefore needs to be taken under consideration, > > > e.g., for interface selection, source address > > > selection, etc. > > > > > > Thanks - Fred > > > fred.l.templin@boeing.com > > > > > > > -----Original Message----- > > > > From: Hui Deng [mailto:denghui@chinamobile.com] > > > > Sent: Friday, December 02, 2011 1:12 AM > > > > To: Templin, Fred L; 'Andrew Sullivan' > > > > Cc: mif@ietf.org > > > > Subject: RE: [mif] IRON as a multiple interface solution > > > > > > > > Hi Fred > > > > > > > > You are saying current MIF document is compatible with IRON. > > > > And current MIF document has already solved MIF's issues, > > > > so guess that IRON is proposing something else like generic > > > > internet access > > > > which is out of MIF. > > > > > > > > Regards, > > > > > > > > -Hui > > > > > > > > > -----Original Message----- > > > > > From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On > > > > Behalf Of > > > > > Templin, Fred L > > > > > Sent: Friday, December 02, 2011 4:10 AM > > > > > To: Andrew Sullivan > > > > > Cc: mif@ietf.org > > > > > Subject: Re: [mif] IRON as a multiple interface solution > > > > > > > > > > Hi Andrew, > > > > > > > > > > I took the time to go off and look at the mif wg > > > > > documents. All of it is good work - and all of it > > > > > is compatible with IRON. > > > > > > > > > > The mif documents talk about two primary classes of > > > > > interfaces: 1) ISP interfaces, and 2) VPN interfaces. > > > > > IRON introduces a third class of interface which > > > > > can be considered an "Internet interface". > > > > > > > > > > While it is true that most ISP interfaces provide > > > > > access to the Internet, ISP interfaces have volatile > > > > > configuration information that can change, e.g., if > > > > > the ISP point of connection changes. Conversely, the > > > > > IRON Internet interface has non-volatile configuration > > > > > information that remains the same even if the ISP > > > > > connections change (e.g., if the node is mobile). > > > > > > > > > > Since ISP interfaces may have access to private > > > > > namespaces, those interfaces (along with their > > > > > associated IP addresses) can be chosen for DNS > > > > > resolution and for accessing services within the > > > > > private namespace the same as described in the mif > > > > > documents. Since the IRON Internet interface has > > > > > a non-volatile configuration on the open Internet, > > > > > however, it provides a stable handle for default > > > > > communications with Internet-based correspondents. > > > > > > > > > > Again, this is all very compatible with the mif > > > > > work, and fits like a glove with what IRON expects. > > > > > > > > > > Thanks - Fred > > > > > fred.l.templin@boeing.com > > > > > > > > > > > -----Original Message----- > > > > > > From: Andrew Sullivan [mailto:ajs@anvilwalrusden.com] > > > > > > Sent: Monday, November 28, 2011 10:11 AM > > > > > > To: Templin, Fred L > > > > > > Cc: Hui Deng; Andrew Sullivan; mif@ietf.org > > > > > > Subject: Re: [mif] IRON as a multiple interface solution > > > > > > > > > > > > On Mon, Nov 28, 2011 at 09:22:45AM -0800, Templin, > > Fred L wrote: > > > > > > > That said, IRON does not preclude the host from accessing > > > > > > > services within the underlying ISP networks. To do so, > > > > > > > however, the host would have to use its ISP-delegated > > > > > > > address(es) and not the VSP-delegated address. > > > > > > > > > > > > > > Does this match your understanding? > > > > > > > > > > > > The central problem, however, is that if you are > > looking up the > > > > > > address for a name, you don't obviously know where it > > is (i.e. you > > > > > > don't know what network you need to go to). What I don't > > > > get in the > > > > > > IRON approach is how you cope with the fact that a user > > > > simply types > > > > > > some name into an application. We can't hardly ask them > > > > which network > > > > > > they want to use to look up the name. The MIF approach, > > > > as much as it > > > > > > makes me airsick, does address that issue. > > > > > > > > > > > > A > > > > > > > > > > > > -- > > > > > > Andrew Sullivan > > > > > > ajs@anvilwalrusden.com > > > > > > > > > > > _______________________________________________ > > > > > mif mailing list > > > > > mif@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/mif > > > > > > > > > > > > > > > > > > From denghui@chinamobile.com Mon Dec 19 22:54:45 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 B949C11E80D5 for ; Mon, 19 Dec 2011 22:54:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.377 X-Spam-Level: X-Spam-Status: No, score=-0.377 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RELAY_IS_221=2.222] 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 lFaaq+A2m-nY for ; Mon, 19 Dec 2011 22:54:45 -0800 (PST) Received: from imss.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id E174311E80D1 for ; Mon, 19 Dec 2011 22:54:44 -0800 (PST) Received: from imss.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id 0FD0BE619; Tue, 20 Dec 2011 14:54:44 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by imss.chinamobile.com (Postfix) with ESMTP id DE5F9E616; Tue, 20 Dec 2011 14:54:43 +0800 (CST) Received: from Hui ([10.2.43.49]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2011122014544095-10350 ; Tue, 20 Dec 2011 14:54:40 +0800 From: "Hui Deng" To: "'Templin, Fred L'" , "'Andrew Sullivan'" References: <4EC5B720.8020605@gmail.com> <83A7D27A-9036-4252-AC94-3A89125C961B@nominum.com> <4EC63ECC.8010700@gmail.com> <20111119220355.GA893@shinkuro.com> <20111128181115.GC45293@shinkuro.com> <01ed01ccbb23$7127e070$5377a150$@com> In-Reply-To: Date: Tue, 20 Dec 2011 14:54:44 +0800 Message-ID: <009401ccbee4$41104cf0$c330e6d0$@com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acyt+SSiV3nB5GxjQku3toj+zfni4wNKihNgANRZoKAAG9NZ4A== X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2011-12-20 14:54:40, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2011-12-20 14:54:43, Serialize complete at 2011-12-20 14:54:43 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" Content-Language: zh-cn X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-18594.005 X-TM-AS-Result: No--24.686-7.0-31-10 X-imss-scan-details: No--24.686-7.0-31-10;No--24.686-7.0-31-10 X-TM-AS-User-Approved-Sender: No;No X-TM-AS-User-Blocked-Sender: No Cc: mif@ietf.org Subject: Re: [mif] IRON as a multiple interface solution 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, 20 Dec 2011 06:54:45 -0000 Hi Fred, >From your reply, it says that MIF DNS does resolve the issue compatible with IRON, not a competing solution. If that is what you mean, that's fine. Thanks for discussion -Hui > -----Original Message----- > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] > Sent: Tuesday, December 20, 2011 1:45 AM > To: Hui Deng; 'Andrew Sullivan' > Cc: mif@ietf.org > Subject: RE: [mif] IRON as a multiple interface solution > > Hi Hui, > > I thought I had addressed Andrew's points in my > 12/1/2011 post: > > http://www.ietf.org/mail-archive/web/mif/current/msg01506.html > > Does that post clarify things? > > Thanks - Fred > fred.l.templin@boeing.com > > > -----Original Message----- > > From: Hui Deng [mailto:denghui@chinamobile.com] > > Sent: Thursday, December 15, 2011 4:17 AM > > To: 'Andrew Sullivan'; Templin, Fred L > > Cc: mif@ietf.org > > Subject: RE: [mif] IRON as a multiple interface solution > > > > I agree that Andrew's argument does make sense. You can't > > tell which service > > it belongs to just based on FQDN > > > > -Hui > > > > > -----Original Message----- > > > From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On > > Behalf Of > > > Andrew Sullivan > > > Sent: Tuesday, November 29, 2011 2:11 AM > > > To: Templin, Fred L > > > Cc: mif@ietf.org > > > Subject: Re: [mif] IRON as a multiple interface solution > > > > > > On Mon, Nov 28, 2011 at 09:22:45AM -0800, Templin, Fred L wrote: > > > > That said, IRON does not preclude the host from accessing > > > > services within the underlying ISP networks. To do so, > > > > however, the host would have to use its ISP-delegated > > > > address(es) and not the VSP-delegated address. > > > > > > > > Does this match your understanding? > > > > > > The central problem, however, is that if you are looking up the > > > address for a name, you don't obviously know where it is (i.e. you > > > don't know what network you need to go to). What I don't get in the > > > IRON approach is how you cope with the fact that a user simply types > > > some name into an application. We can't hardly ask them > > which network > > > they want to use to look up the name. The MIF approach, as > > much as it > > > makes me airsick, does address that issue. > > > > > > A > > > > > > -- > > > Andrew Sullivan > > > ajs@anvilwalrusden.com > > > _______________________________________________ > > > mif mailing list > > > mif@ietf.org > > > https://www.ietf.org/mailman/listinfo/mif > > > > > > From pierrick.seite@orange.com Tue Dec 20 05:49:58 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 59F3421F8B03 for ; Tue, 20 Dec 2011 05:49:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 hJ5+VSCPvD+m for ; Tue, 20 Dec 2011 05:49:56 -0800 (PST) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by ietfa.amsl.com (Postfix) with ESMTP id 50DA421F8B01 for ; Tue, 20 Dec 2011 05:49:55 -0800 (PST) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id A0E56A4438A; Tue, 20 Dec 2011 14:51:14 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id 9387FA4439E; Tue, 20 Dec 2011 14:51:14 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Dec 2011 14:48:46 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCBF1E.18077DE1" Date: Tue, 20 Dec 2011 14:48:45 +0100 Message-ID: <843DA8228A1BA74CA31FB4E111A5C46202169D56@ftrdmel0.rd.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mif] Adoption of API document as the MIF WG document Thread-Index: Acy+3ouPBL6BPXi3SlqlBHjZwYmH/QAO+DrA References: <4EEB70DF.3070201@viagenie.ca><79DAA562-B463-4D11-A4E5-AEE1325531A0@nominum.com><4EEF5278.8040103@viagenie.ca><50824C2C-A4A8-4E92-A12D-45082B9CF5DC@nominum.com><4EEF5D26.3080203@viagenie.ca><0FECAD9E-E1EB-4849-BF8E-227F49975559@nominum.com><4EEF6714.40804@viagenie.ca> From: To: , , X-OriginalArrivalTime: 20 Dec 2011 13:48:46.0756 (UTC) FILETIME=[187B4E40:01CCBF1E] Subject: Re: [mif] Adoption of API document as the MIF WG 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: Tue, 20 Dec 2011 13:49:58 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCBF1E.18077DE1 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, =20 I'm just trying to understand the scope of the MIF API and meaning of = high/low level API.=20 =20 So, thinking about high-level requirements: IMU, the MIF API should = address issues from the problem statement : DNS selection, source = address selection and routing. Right? Considering these problems, the = MIF API should be able to provide command/services to high level API = (e.g. OMA-DM API), or even applications (if we imagine application with = MIF management capabilities...). Typically, I'm thinking to the = following requirements for the MIF API: =20 DNS selection: - bound some DNS servers to an interface and suffixes.=20 source address selection:=20 - return the type of IP address (e.g. local, remote, mobile IP = anchored=20 - provide a valid IP address with a given type on a given = interface routing / first-hop selection:=20 - the API should allow to differentiate the traffic (i.e. = provide capability to configure traffic selector) - associate a routing table per type of traffic =20 Are we on the same page? =20 BR, Pierrick =20 =20 De : mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part de = Hui Deng Envoy=E9 : mardi 20 d=E9cembre 2011 07:14 =C0 : Simon Perreault; MIF Mailing List Objet : Re: [mif] Adoption of API document as the MIF WG document =20 This is a new recharter proposal which need to be discussed during next = ietf meeting all together =20 thanks =20 -Hui 2011/12/20 Simon Perreault On 2011-12-19 11:24, Ted Lemon wrote: On Dec 19, 2011, at 10:49 AM, Simon Perreault wrote: I just don't want the WG to see this document as something that allows = us to place a "DONE" checkmark next to the API milestone. There is still API = work to be done. Well, an easy fix for this is to add a milestone that addresses this = concern. =20 I'd be happy with that. Something like... 3) MIF API: While no changes are needed for applications to run on multiple interface hosts, a new API could provide additional services to applications running on hosts attached to multiple provisioning domains. For instance, these services could assist advanced applications in having greater control over first-hop, source address and/or DNS selection issues. This API will be defined as an abstract interface specification, i.e., specific details about mapping to operating system primitives or programming language will be left out. 3.1) Low-level API: This API will specify base functionality that a platform needs to make available for the high-level API to be = possible. It is intended to be used by applications for most tasks: that will = be the high-level API's role. Applications could still call into the = low-level API to perform complex, infrequent tasks. 3.2) High-level API: This API will specify functionality intended for applications' frequent tasks. The term "high-level" means that it = will abstract the tasks that need to be perform and minimize an = application's knowledge of a node's network configuration. It should be easy to use = and appropriate for most of tasks commonly performed by applications. If the charter was modified to something like the above then I'd change = my position to "support"...=20 Simon --=20 DTN made easy, lean, and smart --> http://postellation.viagenie.ca = =20 NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca = =20 STUN/TURN server --> http://numb.viagenie.ca = =20 _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif =20 ------_=_NextPart_001_01CCBF1E.18077DE1 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi = all,

 

I’m just trying to understand the scope of the MIF API and meaning of high/low = level API.

 

So, = thinking about high-level requirements: IMU, the MIF API should address issues = from the problem statement : DNS selection, source address selection and routing. = Right? Considering these problems, the MIF API should be able to provide command/services = to high level API (e.g. OMA-DM API), or even applications (if we imagine = application with MIF management capabilities…). Typically, I’m thinking to = the following requirements for the MIF API:

 

DNS = selection:

-          bound some DNS servers to an = interface and suffixes.

source address selection:

-          return the type of IP = address (e.g. local, remote, mobile IP anchored

-          provide a valid IP = address with a given type on a given interface

routing / first-hop = selection:

-          the API should allow = to differentiate the traffic (i.e. provide capability to configure traffic = selector)

-          associate a routing = table per type of traffic

 

Are we on the same = page?

 

BR,

Pierrick

 

 

De : = mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part de Hui Deng
Envoy=E9 : mardi 20 d=E9cembre 2011 07:14
=C0 : Simon Perreault; MIF Mailing List
Objet : Re: [mif] Adoption of API document as the MIF WG = document

 

This is a new recharter proposal which need to = be discussed during next ietf meeting all together

 

thanks

 

-Hui

2011/12/20 Simon Perreault <simon.perreault@viagenie.ca>

On 2011-12-19 11:24, Ted Lemon = wrote:

On Dec 19, 2011, at 10:49 AM, Simon Perreault = wrote:

I just don't want the WG to see this document as = something that allows us to
place a "DONE" checkmark next to the API milestone. There is = still API work to
be done.


Well, an easy fix for this is to add a milestone that addresses this = concern.

 

I'd be happy with that. Something like...

 3) MIF API: While no changes are needed for applications to run = on
 multiple interface hosts, a new API could provide additional = services
 to applications running on hosts attached to multiple = provisioning
 domains. For instance, these services could assist advanced
 applications in having greater control over first-hop, source = address
 and/or DNS selection issues. This API will be defined as an = abstract
 interface specification, i.e., specific details about mapping = to
 operating system primitives or programming language will be left = out.

   3.1) Low-level API: This API will specify base = functionality that a
   platform needs to make available for the high-level API to = be possible.
   It is intended to be used by applications for most tasks: = that will be the
   high-level API's role. Applications could still call into = the low-level API
   to perform complex, infrequent tasks.

   3.2) High-level API: This API will specify functionality = intended for
   applications' frequent tasks. The term = "high-level" means that it will
   abstract the tasks that need to be perform and minimize an application's
   knowledge of a node's network configuration. It should be = easy to use and
   appropriate for most of tasks commonly performed by = applications.

If the charter was modified to something like the above then I'd change = my position to "support"...



Simon
--
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> = http://numb.viagenie.ca
_______________________________________________
mif mailing list
mif@ietf.org
https://www.ietf.org/mailman/listinfo/mif

 

------_=_NextPart_001_01CCBF1E.18077DE1-- From simon.perreault@viagenie.ca Tue Dec 20 06:11:18 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 B1F7F21F8AFD for ; Tue, 20 Dec 2011 06:11:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.351 X-Spam-Level: X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599] 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 HFOLiqqGG839 for ; Tue, 20 Dec 2011 06:11:18 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by ietfa.amsl.com (Postfix) with ESMTP id 35A8221F8AF7 for ; Tue, 20 Dec 2011 06:11:18 -0800 (PST) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 66A1F20D2A; Tue, 20 Dec 2011 09:10:47 -0500 (EST) Message-ID: <4EF09766.9090800@viagenie.ca> Date: Tue, 20 Dec 2011 09:10:46 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111115 Thunderbird/8.0 MIME-Version: 1.0 To: pierrick.seite@orange.com References: <4EEB70DF.3070201@viagenie.ca><79DAA562-B463-4D11-A4E5-AEE1325531A0@nominum.com><4EEF5278.8040103@viagenie.ca><50824C2C-A4A8-4E92-A12D-45082B9CF5DC@nominum.com><4EEF5D26.3080203@viagenie.ca><0FECAD9E-E1EB-4849-BF8E-227F49975559@nominum.com><4EEF6714.40804@viagenie.ca> <843DA8228A1BA74CA31FB4E111A5C46202169D56@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <843DA8228A1BA74CA31FB4E111A5C46202169D56@ftrdmel0.rd.francetelecom.fr> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: mif@ietf.org Subject: Re: [mif] Adoption of API document as the MIF WG 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: Tue, 20 Dec 2011 14:11:18 -0000 On 2011-12-20 08:48, pierrick.seite@orange.com wrote: > I’m just trying to understand the scope of the MIF API and meaning of high/low > level API. > > So, thinking about high-level requirements: IMU, the MIF API should address > issues from the problem statement : DNS selection, source address selection and > routing. Right? Considering these problems, the MIF API should be able to provide > command/services to high level API (e.g. OMA-DM API), or even applications (if we > imagine application with MIF management capabilities…). Typically, I’m thinking > to the following requirements for the MIF API: > > DNS selection: > > -bound some DNS servers to an interface and suffixes. > > source address selection: > > -return the type of IP address (e.g. local, remote, mobile IP anchored > > -provide a valid IP address with a given type on a given interface > > routing / first-hop selection: > > -the API should allow to differentiate the traffic (i.e. provide capability to > configure traffic selector) > > -associate a routing table per type of traffic I think this is all low-level stuff. Ideally, an application shouldn't have to deal with this stuff. It should be handled as automatically as possible by the stack. The high-level API should be as close to the "use case" as possible. For example, (I'm just inventing stuff now, not sure it makes sense), with an appropriate high-level API an application could just pass a flag saying "don't use a cellular interface". The idea is that you don't want all apps to have to reimplement similar logic each time. The similar stuff can be abstracted away and put in the platform's stack. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From pierrick.seite@orange.com Tue Dec 20 06:26: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 47AEF21F8B09 for ; Tue, 20 Dec 2011 06:26:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] 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 9eQz4CB7OSNP for ; Tue, 20 Dec 2011 06:26:38 -0800 (PST) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id 2539421F8B06 for ; Tue, 20 Dec 2011 06:26:38 -0800 (PST) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 0F3815D88BD; Tue, 20 Dec 2011 15:26:36 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id 040585D88D2; Tue, 20 Dec 2011 15:26:36 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Dec 2011 15:25:35 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 20 Dec 2011 15:25:34 +0100 Message-ID: <843DA8228A1BA74CA31FB4E111A5C46202169D71@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <4EF09766.9090800@viagenie.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mif] Adoption of API document as the MIF WG document Thread-Index: Acy/IS4Onz6lcgthQGWbjmcC4hlMHQAAD3Ew References: <4EEB70DF.3070201@viagenie.ca><79DAA562-B463-4D11-A4E5-AEE1325531A0@nominum.com><4EEF5278.8040103@viagenie.ca><50824C2C-A4A8-4E92-A12D-45082B9CF5DC@nominum.com><4EEF5D26.3080203@viagenie.ca><0FECAD9E-E1EB-4849-BF8E-227F49975559@nominum.com><4EEF6714.40804@viagenie.ca> <843DA8228A1BA74CA31FB4E111A5C46202169D56@ftrdmel0.rd.francetelecom.fr> <4EF09766.9090800@viagenie.ca> From: To: X-OriginalArrivalTime: 20 Dec 2011 14:25:35.0588 (UTC) FILETIME=[3D0C5240:01CCBF23] Cc: mif@ietf.org Subject: Re: [mif] Adoption of API document as the MIF WG 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: Tue, 20 Dec 2011 14:26:39 -0000 > -----Message d'origine----- > De=A0: Simon Perreault [mailto:simon.perreault@viagenie.ca] > Envoy=E9=A0: mardi 20 d=E9cembre 2011 15:11 > =C0=A0: SEITE Pierrick RD-RESA-REN > Cc=A0: denghui02@gmail.com; mif@ietf.org > Objet=A0: Re: [mif] Adoption of API document as the MIF WG document >=20 > On 2011-12-20 08:48, pierrick.seite@orange.com wrote: > > I'm just trying to understand the scope of the MIF API and meaning = of > high/low > > level API. > > > > So, thinking about high-level requirements: IMU, the MIF API should > address > > issues from the problem statement : DNS selection, source address > selection and > > routing. Right? Considering these problems, the MIF API should be > able to provide > > command/services to high level API (e.g. OMA-DM API), or even > applications (if we > > imagine application with MIF management capabilities...). Typically, > I'm thinking > > to the following requirements for the MIF API: > > > > DNS selection: > > > > -bound some DNS servers to an interface and suffixes. > > > > source address selection: > > > > -return the type of IP address (e.g. local, remote, mobile IP > anchored > > > > -provide a valid IP address with a given type on a given interface > > > > routing / first-hop selection: > > > > -the API should allow to differentiate the traffic (i.e. provide > capability to > > configure traffic selector) > > > > -associate a routing table per type of traffic >=20 > I think this is all low-level stuff. >=20 Agreed. > Ideally, an application shouldn't have to deal with this stuff. It > should be > handled as automatically as possible by the stack. The high-level API > should be > as close to the "use case" as possible. For example, (I'm just > inventing stuff > now, not sure it makes sense), with an appropriate high-level API an > application > could just pass a flag saying "don't use a cellular interface". >=20 > The idea is that you don't want all apps to have to reimplement = similar > logic > each time. The similar stuff can be abstracted away and put in the > platform's stack. >=20 I couldn't agree more :-) Your high-level API is what I use to name "a = connection manager"... Whatever the terminology, I think this is the = right way to go if want harmonization in the field. At least, it should = be the default API model; however, some application developers may want = to keep control of the connectivity and may want to have access to = low-level API (I'm not sure it is desirable...). Let's see what the WG = think....=20 Pierrick > Simon > -- > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca From Ted.Lemon@nominum.com Tue Dec 20 06:31:59 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 D311E21F89BA for ; Tue, 20 Dec 2011 06:31:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.357 X-Spam-Level: X-Spam-Status: No, score=-106.357 tagged_above=-999 required=5 tests=[AWL=0.241, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 OXiE5r1IWmjS for ; Tue, 20 Dec 2011 06:31:59 -0800 (PST) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by ietfa.amsl.com (Postfix) with ESMTP id CF06A21F8906 for ; Tue, 20 Dec 2011 06:31:58 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKTvCcQ3cHbVeEvwHTQhgg2Zo+yhlNgyYV@postini.com; Tue, 20 Dec 2011 06:31:58 PST 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 CAA541B8062 for ; Tue, 20 Dec 2011 06:31:30 -0800 (PST) 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 35FB9190052; Tue, 20 Dec 2011 06:31:28 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-02.WIN.NOMINUM.COM ([64.89.228.134]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.01.0339.001; Tue, 20 Dec 2011 06:31:28 -0800 From: Ted Lemon To: " " Thread-Topic: [mif] Adoption of API document as the MIF WG document Thread-Index: AQHMuyJrBXZGqHrIRk6m9t2t9A95k5XfLl6AgABKEACABFZmAIAACzCAgAABiwCAAAmzgIAAAiMAgADlfwCAAH8igIAAC+0A Date: Tue, 20 Dec 2011 14:31:27 +0000 Message-ID: <0158B512-7C05-4F3D-8816-872035534E87@nominum.com> References: <4EEB70DF.3070201@viagenie.ca><79DAA562-B463-4D11-A4E5-AEE1325531A0@nominum.com><4EEF5278.8040103@viagenie.ca><50824C2C-A4A8-4E92-A12D-45082B9CF5DC@nominum.com><4EEF5D26.3080203@viagenie.ca><0FECAD9E-E1EB-4849-BF8E-227F49975559@nominum.com><4EEF6714.40804@viagenie.ca> <843DA8228A1BA74CA31FB4E111A5C46202169D56@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <843DA8228A1BA74CA31FB4E111A5C46202169D56@ftrdmel0.rd.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_0158B5127C054F3D8816872035534E87nominumcom_" MIME-Version: 1.0 Cc: "" Subject: Re: [mif] Adoption of API document as the MIF WG 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: Tue, 20 Dec 2011 14:32:00 -0000 --_000_0158B5127C054F3D8816872035534E87nominumcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Are we on the same page? The high-level API probably shouldn't expose interfaces=97it should simply = attempt to make a connection when you hand it a name. Two proposals for a= high-level interface that have been discussed are the MIF Happy Eyeballs A= PI, and the connect_to_name API. With both APIs, you basically hand the A= PI a name and it hands you back a socket connected to the host addressed by= that name. It does all the fiddling under the covers to figure out which= interface to use and which DNS servers to use and which protocol to use. What you described is more like the low-level API. One distinction that y= ou didn't mention in your description is that we intend have a lower level = of granularity than the interface. Because it's possible for more than on= e address family to be attached to an interface, and because it's possible = for an interface to be attached to a multi-homed network, we've defined a "= provisioning domain" which is the place where things like DNS server config= uration happen. There can be more than one provisioning domain per interf= ace; provisioning domains never span interfaces. You mention an additional concept in your summary: a routing table per type= of traffic. We have not talked about this, and I don't know that it's in= scope. I would very much like to know what other participants think abou= t this, and how it might be used. It's not really on my radar, but this i= s good: I'm by no means an expert on this problem space, and my hope was th= at people would read the MIF API doc and notice what's missing and bring it= up here on the mailing list. --_000_0158B5127C054F3D8816872035534E87nominumcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <56CC49BB8BD79F428A8FDD0CEB27A686@nominum.com> Content-Transfer-Encoding: quoted-printable
Are we on the same page?

The high-level API probably shouldn't expose interfaces=97it should si= mply attempt to make a connection when you hand it a name.   Two propo= sals for a high-level interface that have been discussed are the MIF Happy = Eyeballs API, and the connect_to_name API.   With both APIs, you basically hand the API a name and it hands you = back a socket connected to the host addressed by that name.   It does = all the fiddling under the covers to figure out which interface to use and = which DNS servers to use and which protocol to use.

What you described is more like the low-level API.   One distinct= ion that you didn't mention in your description is that we intend have a lo= wer level of granularity than the interface.   Because it's possible f= or more than one address family to be attached to an interface, and because it's possible for an interface to be attached= to a multi-homed network, we've defined a "provisioning domain" = which is the place where things like DNS server configuration happen.  = ; There can be more than one provisioning domain per interface; provisioning domains never span interfaces.

You mention an additional concept in your summary: a routing table per= type of traffic.   We have not talked about this, and I don't know th= at it's in scope.   I would very much like to know what other particip= ants think about this, and how it might be used.   It's not really on my radar, but this is good: I'm by no mean= s an expert on this problem space, and my hope was that people would read t= he MIF API doc and notice what's missing and bring it up here on the mailin= g list.


--_000_0158B5127C054F3D8816872035534E87nominumcom_-- From pierrick.seite@orange.com Tue Dec 20 06:59:57 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 612A221F8B01 for ; Tue, 20 Dec 2011 06:59:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 DF8dgY5ZSo3D for ; Tue, 20 Dec 2011 06:59:55 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by ietfa.amsl.com (Postfix) with ESMTP id 53F3C21F8AFD for ; Tue, 20 Dec 2011 06:59:55 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id D2DF6E306C6; Tue, 20 Dec 2011 16:10:50 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id C7DE4E306A8; Tue, 20 Dec 2011 16:10:50 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Dec 2011 15:59:54 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCBF28.07B3A292" Date: Tue, 20 Dec 2011 15:59:53 +0100 Message-ID: <843DA8228A1BA74CA31FB4E111A5C46202169D99@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <0158B512-7C05-4F3D-8816-872035534E87@nominum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mif] Adoption of API document as the MIF WG document Thread-Index: AQHMuyJrBXZGqHrIRk6m9t2t9A95k5XfLl6AgABKEACABFZmAIAACzCAgAABiwCAAAmzgIAAAiMAgADlfwCAAH8igIAAC+0A//9/mnA= References: <4EEB70DF.3070201@viagenie.ca><79DAA562-B463-4D11-A4E5-AEE1325531A0@nominum.com><4EEF5278.8040103@viagenie.ca><50824C2C-A4A8-4E92-A12D-45082B9CF5DC@nominum.com><4EEF5D26.3080203@viagenie.ca><0FECAD9E-E1EB-4849-BF8E-227F49975559@nominum.com><4EEF6714.40804@viagenie.ca> <843DA8228A1BA74CA31FB4E111A5C46202169D56@ftrdmel0.rd.francetelecom.fr> <0158B512-7C05-4F3D-8816-872035534E87@nominum.com> From: To: X-OriginalArrivalTime: 20 Dec 2011 14:59:54.0213 (UTC) FILETIME=[08159150:01CCBF28] Cc: mif@ietf.org Subject: Re: [mif] Adoption of API document as the MIF WG 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: Tue, 20 Dec 2011 14:59:57 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCBF28.07B3A292 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks for clarifications, I think we are on the same page J=20 =20 Regarding routing manipulation, I think it should be included in API = requirement; let's see what other people think. =20 Pierrick =20 De : Ted Lemon [mailto:Ted.Lemon@nominum.com]=20 Envoy=E9 : mardi 20 d=E9cembre 2011 15:31 =C0 : SEITE Pierrick RD-RESA-REN Cc : ; ; = Objet : Re: [mif] Adoption of API document as the MIF WG document =20 Are we on the same page? =20 The high-level API probably shouldn't expose interfaces-it should simply = attempt to make a connection when you hand it a name. Two proposals = for a high-level interface that have been discussed are the MIF Happy = Eyeballs API, and the connect_to_name API. With both APIs, you = basically hand the API a name and it hands you back a socket connected = to the host addressed by that name. It does all the fiddling under the = covers to figure out which interface to use and which DNS servers to use = and which protocol to use. =20 What you described is more like the low-level API. One distinction = that you didn't mention in your description is that we intend have a = lower level of granularity than the interface. Because it's possible = for more than one address family to be attached to an interface, and = because it's possible for an interface to be attached to a multi-homed = network, we've defined a "provisioning domain" which is the place where = things like DNS server configuration happen. There can be more than = one provisioning domain per interface; provisioning domains never span = interfaces. =20 You mention an additional concept in your summary: a routing table per = type of traffic. We have not talked about this, and I don't know that = it's in scope. I would very much like to know what other participants = think about this, and how it might be used. It's not really on my = radar, but this is good: I'm by no means an expert on this problem = space, and my hope was that people would read the MIF API doc and notice = what's missing and bring it up here on the mailing list. =20 =20 ------_=_NextPart_001_01CCBF28.07B3A292 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Thanks for clarifications, I think we are on the same = page J

 

Regarding routing manipulation, I think it should be = included in API requirement; let’s see what other people = think.

 

Pierrick

 

De : Ted Lemon [mailto:Ted.Lemon@nominum.com]
Envoy=E9 : mardi 20 d=E9cembre 2011 15:31
=C0 : SEITE Pierrick RD-RESA-REN
Cc : <denghui02@gmail.com>; <simon.perreault@viagenie.ca>; <mif@ietf.org>
Objet : Re: [mif] Adoption of API document as the MIF WG = document

 

Are we on the same = page?

 

The high-level API probably shouldn't expose interfaces—it should simply attempt to make a connection when you = hand it a name.   Two proposals for a high-level = interface that have been discussed are the MIF Happy Eyeballs API, and the = connect_to_name API.   With both APIs, you basically hand the API a name and = it hands you back a socket connected to the host addressed by that name. =   It does all the fiddling under the covers to figure out which interface to = use and which DNS servers to use and which protocol to use.

 

What you described is more like the low-level API. =   One distinction that you didn't mention in your description = is that we intend have a lower level of granularity than the interface.   = Because it's possible for more than one address family to be attached to an = interface, and because it's possible for an interface to be attached to a = multi-homed network, we've defined a "provisioning domain" which is the = place where things like DNS server configuration happen.   There can be = more than one provisioning domain per interface; provisioning domains never = span interfaces.

 

You mention an additional = concept in your summary: a routing table per type of traffic.   We have not = talked about this, and I don't know that it's in scope.   I would very = much like to know what other participants think about this, and how it might be = used.   It's not really on my radar, but this is good: I'm by no means an = expert on this problem space, and my hope was that people would read the MIF = API doc and notice what's missing and bring it up here on the mailing = list.

 

 

------_=_NextPart_001_01CCBF28.07B3A292-- From Fred.L.Templin@boeing.com Tue Dec 20 11:10:35 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 A522D21F889A for ; Tue, 20 Dec 2011 11:10:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 40kJT0477Zc6 for ; Tue, 20 Dec 2011 11:10:34 -0800 (PST) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by ietfa.amsl.com (Postfix) with ESMTP id B6FC421F86FF for ; Tue, 20 Dec 2011 11:10:34 -0800 (PST) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id pBKJAPgZ013825 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 20 Dec 2011 11:10:26 -0800 (PST) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id pBKJAOrb025509; Tue, 20 Dec 2011 11:10:24 -0800 (PST) Received: from XCH-NWHT-07.nw.nos.boeing.com (xch-nwht-07.nw.nos.boeing.com [130.247.25.111]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id pBKJ9hNQ023885 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 20 Dec 2011 11:10:22 -0800 (PST) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-07.nw.nos.boeing.com ([130.247.25.111]) with mapi; Tue, 20 Dec 2011 11:10:12 -0800 From: "Templin, Fred L" To: Hui Deng , "'Andrew Sullivan'" Date: Tue, 20 Dec 2011 11:10:11 -0800 Thread-Topic: [mif] IRON as a multiple interface solution Thread-Index: Acyt+SVzR1PpkUYRTvCp3A+bmVJOzQCYBPHAAB446gAAD8Pa0AKEviEwANQukcAAGomgYAAaRdXg Message-ID: References: <4EC5B720.8020605@gmail.com> <83A7D27A-9036-4252-AC94-3A89125C961B@nominum.com> <4EC63ECC.8010700@gmail.com> <20111119220355.GA893@shinkuro.com> <20111128181115.GC45293@shinkuro.com> <01da01ccb0d2$72f6f630$58e4e290$@com> <01ee01ccbb24$48fb0950$daf11bf0$@com> <008b01ccbedf$c5cb9620$5162c260$@com> In-Reply-To: <008b01ccbedf$c5cb9620$5162c260$@com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mif@ietf.org" Subject: Re: [mif] IRON as a multiple interface solution 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, 20 Dec 2011 19:10:35 -0000 Hi Hui,=20 > -----Original Message----- > From: Hui Deng [mailto:denghui@chinamobile.com]=20 > Sent: Monday, December 19, 2011 10:23 PM > To: Templin, Fred L; 'Andrew Sullivan' > Cc: mif@ietf.org > Subject: RE: [mif] IRON as a multiple interface solution >=20 > Hi Fred >=20 > There are multiple places discussing virtual interface(PMIP6,=20 > DSMIP6, 3GPP > GTP, Connection Manager et al.), Yes, virtual interfaces have been discussed in many contexts for many, many years. But, the virtual interface described in IRON is uniquely different. The virtual interface described in IRON is an NBMA interface that views other IRON nodes as on-link neighbors. Neighbor coordinations such as neighbor/router discovery, NUD, redirection, etc. are therefore supported. IRON also uniquely solves the well known virtual interface path MTU problem, and this is especially important for MIF nodes that connect to diverse L2 media. I have also already mentioned the ability to have a persistent L3 configuration on the IRON virtual interface even if the L3 configurations on the ISP interfaces change dynamically. This provides significant benefits for mobility, mobile networks, session survivability, etc. The document also mentions several other compelling functions applicable to MIF nodes that are enabled. > I don't know whether IETF is interested in documenting such=20 > implementation,=20 > Internet Area maybe the right place to discuss it. IRON is not an implementation; it is an architecture. Its functional components are VET, SEAL and AERO, which deal with specific aspects of concern to the MIF problem space. The four documents (IRON, VET, SEAL and AERO) go together as a group. Thanks - Fred fred.l.templin@boeing.com =20 > Thanks >=20 > -Hui > > -----Original Message----- > > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] > > Sent: Tuesday, December 20, 2011 1:44 AM > > To: Hui Deng; 'Andrew Sullivan' > > Cc: mif@ietf.org > > Subject: RE: [mif] IRON as a multiple interface solution > >=20 > > Hi Hui, > >=20 > > > -----Original Message----- > > > From: Hui Deng [mailto:denghui@chinamobile.com] > > > Sent: Thursday, December 15, 2011 4:23 AM > > > To: Templin, Fred L; 'Andrew Sullivan' > > > Cc: mif@ietf.org > > > Subject: RE: [mif] IRON as a multiple interface solution > > > > > > Hi Fred, > > > > > > This new interface type is also a kind of virtual interface > > > which has been > > > mentioned in RFC 6418. > >=20 > > Yes, I see where virtual interfaces are mentioned in > > several places in RFC6418. However, that document talks > > about the virtual interface *near-end* and does not talk > > about the virtual link itself nor coordination with the > > virtual interface *far-end(s)*. > >=20 > > RFC6418, Section 3.8 is consistent with what the IRON > > virtual interface near end expects, but IRON goes to > > the full extent of describing coordinations between > > the near end and any prospective far-ends. > >=20 > > Thanks - Fred > > fred.l.templin@boeing.com > >=20 > > > -Hui > > > > > > > -----Original Message----- > > > > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] > > > > Sent: Saturday, December 03, 2011 12:56 AM > > > > To: Hui Deng; 'Andrew Sullivan' > > > > Cc: mif@ietf.org > > > > Subject: RE: [mif] IRON as a multiple interface solution > > > > > > > > Hi Hui, > > > > > > > > I am saying that IRON defines a new interface type > > > > that would be one among possibly many interfaces of > > > > a mif node. The properties of this interface type > > > > include: > > > > > > > > - maintains stable network layer addresses even > > > > if ISP connections change > > > > - supports session continutity and fault tolerance > > > > as ISP connections change > > > > - avoids end user network renumbering when ISP > > > > connections change in case the mif node acts > > > > as a router > > > > > > > > There is more to it than just this, but the IRON > > > > interface is another mif node interface type and > > > > therefore needs to be taken under consideration, > > > > e.g., for interface selection, source address > > > > selection, etc. > > > > > > > > Thanks - Fred > > > > fred.l.templin@boeing.com > > > > > > > > > -----Original Message----- > > > > > From: Hui Deng [mailto:denghui@chinamobile.com] > > > > > Sent: Friday, December 02, 2011 1:12 AM > > > > > To: Templin, Fred L; 'Andrew Sullivan' > > > > > Cc: mif@ietf.org > > > > > Subject: RE: [mif] IRON as a multiple interface solution > > > > > > > > > > Hi Fred > > > > > > > > > > You are saying current MIF document is compatible with IRON. > > > > > And current MIF document has already solved MIF's issues, > > > > > so guess that IRON is proposing something else like generic > > > > > internet access > > > > > which is out of MIF. > > > > > > > > > > Regards, > > > > > > > > > > -Hui > > > > > > > > > > > -----Original Message----- > > > > > > From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On > > > > > Behalf Of > > > > > > Templin, Fred L > > > > > > Sent: Friday, December 02, 2011 4:10 AM > > > > > > To: Andrew Sullivan > > > > > > Cc: mif@ietf.org > > > > > > Subject: Re: [mif] IRON as a multiple interface solution > > > > > > > > > > > > Hi Andrew, > > > > > > > > > > > > I took the time to go off and look at the mif wg > > > > > > documents. All of it is good work - and all of it > > > > > > is compatible with IRON. > > > > > > > > > > > > The mif documents talk about two primary classes of > > > > > > interfaces: 1) ISP interfaces, and 2) VPN interfaces. > > > > > > IRON introduces a third class of interface which > > > > > > can be considered an "Internet interface". > > > > > > > > > > > > While it is true that most ISP interfaces provide > > > > > > access to the Internet, ISP interfaces have volatile > > > > > > configuration information that can change, e.g., if > > > > > > the ISP point of connection changes. Conversely, the > > > > > > IRON Internet interface has non-volatile configuration > > > > > > information that remains the same even if the ISP > > > > > > connections change (e.g., if the node is mobile). > > > > > > > > > > > > Since ISP interfaces may have access to private > > > > > > namespaces, those interfaces (along with their > > > > > > associated IP addresses) can be chosen for DNS > > > > > > resolution and for accessing services within the > > > > > > private namespace the same as described in the mif > > > > > > documents. Since the IRON Internet interface has > > > > > > a non-volatile configuration on the open Internet, > > > > > > however, it provides a stable handle for default > > > > > > communications with Internet-based correspondents. > > > > > > > > > > > > Again, this is all very compatible with the mif > > > > > > work, and fits like a glove with what IRON expects. > > > > > > > > > > > > Thanks - Fred > > > > > > fred.l.templin@boeing.com > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Andrew Sullivan [mailto:ajs@anvilwalrusden.com] > > > > > > > Sent: Monday, November 28, 2011 10:11 AM > > > > > > > To: Templin, Fred L > > > > > > > Cc: Hui Deng; Andrew Sullivan; mif@ietf.org > > > > > > > Subject: Re: [mif] IRON as a multiple interface solution > > > > > > > > > > > > > > On Mon, Nov 28, 2011 at 09:22:45AM -0800, Templin, > > > Fred L wrote: > > > > > > > > That said, IRON does not preclude the host from=20 > accessing > > > > > > > > services within the underlying ISP networks. To do so, > > > > > > > > however, the host would have to use its ISP-delegated > > > > > > > > address(es) and not the VSP-delegated address. > > > > > > > > > > > > > > > > Does this match your understanding? > > > > > > > > > > > > > > The central problem, however, is that if you are > > > looking up the > > > > > > > address for a name, you don't obviously know where it > > > is (i.e. you > > > > > > > don't know what network you need to go to). What I don't > > > > > get in the > > > > > > > IRON approach is how you cope with the fact that a user > > > > > simply types > > > > > > > some name into an application. We can't hardly ask them > > > > > which network > > > > > > > they want to use to look up the name. The MIF approach, > > > > > as much as it > > > > > > > makes me airsick, does address that issue. > > > > > > > > > > > > > > A > > > > > > > > > > > > > > -- > > > > > > > Andrew Sullivan > > > > > > > ajs@anvilwalrusden.com > > > > > > > > > > > > > _______________________________________________ > > > > > > mif mailing list > > > > > > mif@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/mif > > > > > > > > > > > > > > > > > > > > > > > > >=20 >=20 > = From zhou.sujing@zte.com.cn Wed Dec 21 01:38:56 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 E950C21F84DA for ; Wed, 21 Dec 2011 01:38:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.838 X-Spam-Level: X-Spam-Status: No, score=-101.838 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, 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 P8et-cDgCLOB for ; Wed, 21 Dec 2011 01:38:56 -0800 (PST) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 7BF3521F84C9 for ; Wed, 21 Dec 2011 01:38:55 -0800 (PST) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 5669078017210; Wed, 21 Dec 2011 17:19:56 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 74270.78017210; Wed, 21 Dec 2011 17:38:35 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id pBL9cWcB038784 for ; Wed, 21 Dec 2011 17:38:32 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn) To: mif@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhou.sujing@zte.com.cn Date: Wed, 21 Dec 2011 17:38:26 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-12-21 17:38:34, Serialize complete at 2011-12-21 17:38:34 Content-Type: multipart/alternative; boundary="=_alternative 0034F8504825796D_=" X-MAIL: mse02.zte.com.cn pBL9cWcB038784 Subject: [mif] a question about rfc6418 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, 21 Dec 2011 09:38:57 -0000 This is a multipart message in MIME format. --=_alternative 0034F8504825796D_= Content-Type: text/plain; charset="US-ASCII" in Section 4.4 The network requires a web-based authentication (e.g., the access network is a WiFi hot spot). In this case, the user can only access a captive portal. For instance, the network may perform HTTP redirection or modify DNS behavior (Section 4.1) until the user has not authenticated. I am quite confused by the last word. Is it possible a typo or something particular? Regards~~~ -Sujing Zhou --=_alternative 0034F8504825796D_= Content-Type: text/html; charset="US-ASCII"
    in Section 4.4

      The network requires a web-based authentication (e.g., the access
      network is a WiFi hot spot).  In this case, the user can only
      access a captive portal.  For instance, the network may perform
      HTTP redirection or modify DNS behavior (Section 4.1) until the
      user has not authenticated.
   I am quite confused by the last word. Is it possible a typo or something particular?


Regards~~~

-Sujing Zhou --=_alternative 0034F8504825796D_=-- From pierrick.seite@orange.com Wed Dec 21 01:42:38 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 2A0FA21F84F9 for ; Wed, 21 Dec 2011 01:42:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 dzOHJQYnkd6V for ; Wed, 21 Dec 2011 01:42:37 -0800 (PST) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id 5332921F84DD for ; Wed, 21 Dec 2011 01:42:37 -0800 (PST) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id DC4F25D88B7; Wed, 21 Dec 2011 10:42:35 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id CF0825D88B3; Wed, 21 Dec 2011 10:42:35 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 21 Dec 2011 10:42:35 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCBFC4.DE36343C" Date: Wed, 21 Dec 2011 10:42:34 +0100 Message-ID: <843DA8228A1BA74CA31FB4E111A5C462021AAEF7@ftrdmel0.rd.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mif] a question about rfc6418 Thread-Index: Acy/xGDdmLdgyDmNQZ6xzB5ErDEsXgAADP4Q References: From: To: , X-OriginalArrivalTime: 21 Dec 2011 09:42:35.0977 (UTC) FILETIME=[DED30B90:01CCBFC4] Subject: Re: [mif] a question about rfc6418 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, 21 Dec 2011 09:42:38 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCBFC4.DE36343C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, =20 Nothing particular, this sentence reflects what the user is currently = experiencing when getting access via a captive portal. =20 Pierrick =20 De : mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part de = zhou.sujing@zte.com.cn Envoy=E9 : mercredi 21 d=E9cembre 2011 10:38 =C0 : mif@ietf.org Objet : [mif] a question about rfc6418 =20 in Section 4.4=20 The network requires a web-based authentication (e.g., the access network is a WiFi hot spot). In this case, the user can only access a captive portal. For instance, the network may perform HTTP redirection or modify DNS behavior (Section 4.1 = ) until the user has not authenticated. I am quite confused by the last word. Is it possible a typo or = something particular?=20 Regards~~~ -Sujing Zhou ------_=_NextPart_001_01CCBFC4.DE36343C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 

Nothing particular, this sentence reflects what the user = is currently experiencing when getting access via a captive = portal.

 

Pierrick

 

De : = mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part de = zhou.sujing@zte.com.cn
Envoy=E9 : mercredi 21 d=E9cembre 2011 10:38
=C0 : mif@ietf.org
Objet : [mif] a question about rfc6418

 


    in Section 4.4

      The network requires a web-based authentication = (e.g., the access
      network is a WiFi hot spot).  In this = case, the user can only
      access a captive portal.  For instance, = the network may perform
      HTTP redirection or modify DNS behavior = (Section = 4.1) until the
      user has not authenticated.

   I am quite confused by the last word. Is it possible a = typo or something particular?


Regards~~~
-Sujing Zhou

------_=_NextPart_001_01CCBFC4.DE36343C-- From zhou.sujing@zte.com.cn Wed Dec 21 01:45:56 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 40F8221F84F9 for ; Wed, 21 Dec 2011 01:45:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.993 X-Spam-Level: X-Spam-Status: No, score=-96.993 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, 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 8omdn+1zwqh8 for ; Wed, 21 Dec 2011 01:45:55 -0800 (PST) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 41DCC21F8513 for ; Wed, 21 Dec 2011 01:45:55 -0800 (PST) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 5952878017210; Wed, 21 Dec 2011 17:44:26 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 95341.1463168568; Wed, 21 Dec 2011 17:45:52 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id pBL9jkux096369; Wed, 21 Dec 2011 17:45:46 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn) In-Reply-To: <843DA8228A1BA74CA31FB4E111A5C462021AAEF7@ftrdmel0.rd.francetelecom.fr> To: MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhou.sujing@zte.com.cn Date: Wed, 21 Dec 2011 17:45:39 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-12-21 17:45:47, Serialize complete at 2011-12-21 17:45:47 Content-Type: multipart/alternative; boundary="=_alternative 0035A1724825796D_=" X-MAIL: mse01.zte.com.cn pBL9jkux096369 Cc: mif@ietf.org Subject: [mif] =?gb2312?b?tPC4tDogUkU6ICBhIHF1ZXN0aW9uIGFib3V0IHJmYzY0MTg=?= 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, 21 Dec 2011 09:45:56 -0000 This is a multipart message in MIME format. --=_alternative 0035A1724825796D_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 dW50aWwgdGhlIHVzZXIgaGFzIE5PVCBhdXRoZW50aWNhdGVkPw0KDQoNClJlZ2FyZHN+fn4NCg0K LVN1amluZyBaaG91DQoNCjxwaWVycmljay5zZWl0ZUBvcmFuZ2UuY29tPiDlhpnkuo4gMjAxMS0x Mi0yMSAxNzo0MjozNDoNCg0KPiBIaSwNCj4gDQo+IE5vdGhpbmcgcGFydGljdWxhciwgdGhpcyBz ZW50ZW5jZSByZWZsZWN0cyB3aGF0IHRoZSB1c2VyIGlzIA0KPiBjdXJyZW50bHkgZXhwZXJpZW5j aW5nIHdoZW4gZ2V0dGluZyBhY2Nlc3MgdmlhIGEgY2FwdGl2ZSBwb3J0YWwuDQo+IA0KPiBQaWVy cmljaw0KPiANCj4gRGUgOiBtaWYtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1pZi1ib3VuY2Vz QGlldGYub3JnXSBEZSBsYSBwYXJ0IGRlDQo+IHpob3Uuc3VqaW5nQHp0ZS5jb20uY24NCj4gRW52 b3nDqSA6IG1lcmNyZWRpIDIxIGTDqWNlbWJyZSAyMDExIDEwOjM4DQo+IMOAIDogbWlmQGlldGYu b3JnDQo+IE9iamV0IDogW21pZl0gYSBxdWVzdGlvbiBhYm91dCByZmM2NDE4DQo+IA0KPiANCj4g ICAgIGluIFNlY3Rpb24gNC40IA0KPiANCj4gICAgICAgVGhlIG5ldHdvcmsgcmVxdWlyZXMgYSB3 ZWItYmFzZWQgYXV0aGVudGljYXRpb24gKGUuZy4sIHRoZSBhY2Nlc3MNCj4gICAgICAgbmV0d29y ayBpcyBhIFdpRmkgaG90IHNwb3QpLiAgSW4gdGhpcyBjYXNlLCB0aGUgdXNlciBjYW4gb25seQ0K PiAgICAgICBhY2Nlc3MgYSBjYXB0aXZlIHBvcnRhbC4gIEZvciBpbnN0YW5jZSwgdGhlIG5ldHdv cmsgbWF5IHBlcmZvcm0NCj4gICAgICAgSFRUUCByZWRpcmVjdGlvbiBvciBtb2RpZnkgRE5TIGJl aGF2aW9yIChTZWN0aW9uIDQuMSkgdW50aWwgdGhlDQo+ICAgICAgIHVzZXIgaGFzIG5vdCBhdXRo ZW50aWNhdGVkLg0KPiANCj4gICAgSSBhbSBxdWl0ZSBjb25mdXNlZCBieSB0aGUgbGFzdCB3b3Jk LiBJcyBpdCBwb3NzaWJsZSBhIHR5cG8gb3IgDQo+IHNvbWV0aGluZyBwYXJ0aWN1bGFyPyANCj4g DQo+IA0KPiBSZWdhcmRzfn5+DQo+IA0KPiAtU3VqaW5nIFpob3UNCg== --=_alternative 0035A1724825796D_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPnVudGlsIHRoZSB1c2VyIGhhcyBO T1QgYXV0aGVudGljYXRlZD88L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZh Y2U9InNhbnMtc2VyaWYiPlJlZ2FyZHN+fn48YnI+DQo8YnI+DQotU3VqaW5nIFpob3U8L2ZvbnQ+ DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mbHQ7cGllcnJpY2suc2VpdGVAb3JhbmdlLmNv bSZndDsg5YaZ5LqOIDIwMTEtMTItMjENCjE3OjQyOjM0Ojxicj4NCjxicj4NCiZndDsgSGksPC9m b250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOzwvZm9udD48L3R0Pg0K PGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBOb3RoaW5nIHBhcnRpY3VsYXIsIHRoaXMgc2VudGVu Y2UgcmVmbGVjdHMgd2hhdA0KdGhlIHVzZXIgaXMgPGJyPg0KJmd0OyBjdXJyZW50bHkgZXhwZXJp ZW5jaW5nIHdoZW4gZ2V0dGluZyBhY2Nlc3MgdmlhIGEgY2FwdGl2ZSBwb3J0YWwuPC9mb250Pjwv dHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOzwvZm9udD48L3R0Pg0KPGJyPjx0 dD48Zm9udCBzaXplPTI+Jmd0OyBQaWVycmljazwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBz aXplPTI+Jmd0OyAmbmJzcDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsg RGUgOiBtaWYtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1pZi1ib3VuY2VzQGlldGYub3JnXQ0K RGUgbGEgcGFydCBkZTxicj4NCiZndDsgemhvdS5zdWppbmdAenRlLmNvbS5jbjxicj4NCiZndDsg RW52b3nDqSA6IG1lcmNyZWRpIDIxIGTDqWNlbWJyZSAyMDExIDEwOjM4PGJyPg0KJmd0OyDDgCA6 IG1pZkBpZXRmLm9yZzxicj4NCiZndDsgT2JqZXQgOiBbbWlmXSBhIHF1ZXN0aW9uIGFib3V0IHJm YzY0MTg8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7PC9mb250 PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgJm5ic3A7ICZuYnNw OyBpbiBTZWN0aW9uIDQuNCA8YnI+DQomZ3Q7IDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgVGhlIG5ldHdvcmsgcmVxdWlyZXMgYSB3ZWItYmFzZWQgYXV0aGVudGljYXRpb24NCihlLmcu LCB0aGUgYWNjZXNzPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBuZXR3b3JrIGlzIGEg V2lGaSBob3Qgc3BvdCkuICZuYnNwO0luIHRoaXMgY2FzZSwNCnRoZSB1c2VyIGNhbiBvbmx5PGJy Pg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBhY2Nlc3MgYSBjYXB0aXZlIHBvcnRhbC4gJm5i c3A7Rm9yIGluc3RhbmNlLA0KdGhlIG5ldHdvcmsgbWF5IHBlcmZvcm08YnI+DQomZ3Q7ICZuYnNw OyAmbmJzcDsgJm5ic3A7IEhUVFAgcmVkaXJlY3Rpb24gb3IgbW9kaWZ5IEROUyBiZWhhdmlvciAo U2VjdGlvbg0KNC4xKSB1bnRpbCB0aGU8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHVz ZXIgaGFzIG5vdCBhdXRoZW50aWNhdGVkLjxicj4NCiZndDsgPGJyPg0KJmd0OyAmbmJzcDsgJm5i c3A7SSBhbSBxdWl0ZSBjb25mdXNlZCBieSB0aGUgbGFzdCB3b3JkLiBJcyBpdCBwb3NzaWJsZQ0K YSB0eXBvIG9yIDxicj4NCiZndDsgc29tZXRoaW5nIHBhcnRpY3VsYXI/IDxicj4NCiZndDsgPGJy Pg0KJmd0OyA8YnI+DQomZ3Q7IFJlZ2FyZHN+fn48YnI+DQomZ3Q7IDxicj4NCiZndDsgLVN1amlu ZyBaaG91PC9mb250PjwvdHQ+DQo= --=_alternative 0035A1724825796D_=-- From denghui@chinamobile.com Wed Dec 21 02:17:08 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 103A121F846A for ; Wed, 21 Dec 2011 02:17:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.377 X-Spam-Level: X-Spam-Status: No, score=-0.377 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RELAY_IS_221=2.222] 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 gvloqljo+JRM for ; Wed, 21 Dec 2011 02:17:07 -0800 (PST) Received: from imss.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id D9F2F21F8418 for ; Wed, 21 Dec 2011 02:17:06 -0800 (PST) Received: from imss.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id 6D671E463; Wed, 21 Dec 2011 18:17:05 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by imss.chinamobile.com (Postfix) with ESMTP id 61B90E3BC; Wed, 21 Dec 2011 18:17:05 +0800 (CST) Received: from Hui ([10.2.53.94]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2011122118170292-18781 ; Wed, 21 Dec 2011 18:17:02 +0800 From: "Hui Deng" To: "'Templin, Fred L'" , "'Andrew Sullivan'" References: <4EC5B720.8020605@gmail.com> <83A7D27A-9036-4252-AC94-3A89125C961B@nominum.com> <4EC63ECC.8010700@gmail.com> <20111119220355.GA893@shinkuro.com> <20111128181115.GC45293@shinkuro.com> <01da01ccb0d2$72f6f630$58e4e290$@com> <01ee01ccbb24$48fb0950$daf11bf0$@com> <008b01ccbedf$c5cb9620$5162c260$@com> In-Reply-To: Date: Wed, 21 Dec 2011 18:17:06 +0800 Message-ID: <00a001ccbfc9$b119ede0$134dc9a0$@com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acyt+SVzR1PpkUYRTvCp3A+bmVJOzQCYBPHAAB446gAAD8Pa0AKEviEwANQukcAAGomgYAAaRdXgACBYkTA= X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2011-12-21 18:17:02, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2011-12-21 18:17:04, Serialize complete at 2011-12-21 18:17:04 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" Content-Language: zh-cn X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-18596.006 X-TM-AS-Result: No--33.740-7.0-31-10 X-imss-scan-details: No--33.740-7.0-31-10;No--33.740-7.0-31-10 X-TM-AS-User-Approved-Sender: No;No X-TM-AS-User-Blocked-Sender: No Cc: mif@ietf.org Subject: Re: [mif] IRON as a multiple interface solution 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, 21 Dec 2011 10:17:08 -0000 Hi Fred Current MIF is discussing 3GPP and BBF scenarios and problems, If IRON is a new architecture, then it need to clarify which scenario and PS that IRON is targeting at. Thanks -Hui > -----Original Message----- > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] > Sent: Wednesday, December 21, 2011 3:10 AM > To: Hui Deng; 'Andrew Sullivan' > Cc: mif@ietf.org > Subject: RE: [mif] IRON as a multiple interface solution > > Hi Hui, > > > -----Original Message----- > > From: Hui Deng [mailto:denghui@chinamobile.com] > > Sent: Monday, December 19, 2011 10:23 PM > > To: Templin, Fred L; 'Andrew Sullivan' > > Cc: mif@ietf.org > > Subject: RE: [mif] IRON as a multiple interface solution > > > > Hi Fred > > > > There are multiple places discussing virtual interface(PMIP6, > > DSMIP6, 3GPP > > GTP, Connection Manager et al.), > > Yes, virtual interfaces have been discussed in many contexts > for many, many years. But, the virtual interface described in > IRON is uniquely different. > > The virtual interface described in IRON is an NBMA interface > that views other IRON nodes as on-link neighbors. Neighbor > coordinations such as neighbor/router discovery, NUD, > redirection, etc. are therefore supported. > > IRON also uniquely solves the well known virtual interface > path MTU problem, and this is especially important for MIF > nodes that connect to diverse L2 media. > > I have also already mentioned the ability to have a > persistent L3 configuration on the IRON virtual interface > even if the L3 configurations on the ISP interfaces change > dynamically. This provides significant benefits for mobility, > mobile networks, session survivability, etc. The document > also mentions several other compelling functions applicable > to MIF nodes that are enabled. > > > > I don't know whether IETF is interested in documenting such > > implementation, > > Internet Area maybe the right place to discuss it. > > IRON is not an implementation; it is an architecture. > Its functional components are VET, SEAL and AERO, which > deal with specific aspects of concern to the MIF problem > space. The four documents (IRON, VET, SEAL and AERO) go > together as a group. > > Thanks - Fred > fred.l.templin@boeing.com > > > Thanks > > > > -Hui > > > -----Original Message----- > > > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] > > > Sent: Tuesday, December 20, 2011 1:44 AM > > > To: Hui Deng; 'Andrew Sullivan' > > > Cc: mif@ietf.org > > > Subject: RE: [mif] IRON as a multiple interface solution > > > > > > Hi Hui, > > > > > > > -----Original Message----- > > > > From: Hui Deng [mailto:denghui@chinamobile.com] > > > > Sent: Thursday, December 15, 2011 4:23 AM > > > > To: Templin, Fred L; 'Andrew Sullivan' > > > > Cc: mif@ietf.org > > > > Subject: RE: [mif] IRON as a multiple interface solution > > > > > > > > Hi Fred, > > > > > > > > This new interface type is also a kind of virtual interface > > > > which has been > > > > mentioned in RFC 6418. > > > > > > Yes, I see where virtual interfaces are mentioned in > > > several places in RFC6418. However, that document talks > > > about the virtual interface *near-end* and does not talk > > > about the virtual link itself nor coordination with the > > > virtual interface *far-end(s)*. > > > > > > RFC6418, Section 3.8 is consistent with what the IRON > > > virtual interface near end expects, but IRON goes to > > > the full extent of describing coordinations between > > > the near end and any prospective far-ends. > > > > > > Thanks - Fred > > > fred.l.templin@boeing.com > > > > > > > -Hui > > > > > > > > > -----Original Message----- > > > > > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] > > > > > Sent: Saturday, December 03, 2011 12:56 AM > > > > > To: Hui Deng; 'Andrew Sullivan' > > > > > Cc: mif@ietf.org > > > > > Subject: RE: [mif] IRON as a multiple interface solution > > > > > > > > > > Hi Hui, > > > > > > > > > > I am saying that IRON defines a new interface type > > > > > that would be one among possibly many interfaces of > > > > > a mif node. The properties of this interface type > > > > > include: > > > > > > > > > > - maintains stable network layer addresses even > > > > > if ISP connections change > > > > > - supports session continutity and fault tolerance > > > > > as ISP connections change > > > > > - avoids end user network renumbering when ISP > > > > > connections change in case the mif node acts > > > > > as a router > > > > > > > > > > There is more to it than just this, but the IRON > > > > > interface is another mif node interface type and > > > > > therefore needs to be taken under consideration, > > > > > e.g., for interface selection, source address > > > > > selection, etc. > > > > > > > > > > Thanks - Fred > > > > > fred.l.templin@boeing.com > > > > > > > > > > > -----Original Message----- > > > > > > From: Hui Deng [mailto:denghui@chinamobile.com] > > > > > > Sent: Friday, December 02, 2011 1:12 AM > > > > > > To: Templin, Fred L; 'Andrew Sullivan' > > > > > > Cc: mif@ietf.org > > > > > > Subject: RE: [mif] IRON as a multiple interface solution > > > > > > > > > > > > Hi Fred > > > > > > > > > > > > You are saying current MIF document is compatible with IRON. > > > > > > And current MIF document has already solved MIF's issues, > > > > > > so guess that IRON is proposing something else like generic > > > > > > internet access > > > > > > which is out of MIF. > > > > > > > > > > > > Regards, > > > > > > > > > > > > -Hui > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] On > > > > > > Behalf Of > > > > > > > Templin, Fred L > > > > > > > Sent: Friday, December 02, 2011 4:10 AM > > > > > > > To: Andrew Sullivan > > > > > > > Cc: mif@ietf.org > > > > > > > Subject: Re: [mif] IRON as a multiple interface solution > > > > > > > > > > > > > > Hi Andrew, > > > > > > > > > > > > > > I took the time to go off and look at the mif wg > > > > > > > documents. All of it is good work - and all of it > > > > > > > is compatible with IRON. > > > > > > > > > > > > > > The mif documents talk about two primary classes of > > > > > > > interfaces: 1) ISP interfaces, and 2) VPN interfaces. > > > > > > > IRON introduces a third class of interface which > > > > > > > can be considered an "Internet interface". > > > > > > > > > > > > > > While it is true that most ISP interfaces provide > > > > > > > access to the Internet, ISP interfaces have volatile > > > > > > > configuration information that can change, e.g., if > > > > > > > the ISP point of connection changes. Conversely, the > > > > > > > IRON Internet interface has non-volatile configuration > > > > > > > information that remains the same even if the ISP > > > > > > > connections change (e.g., if the node is mobile). > > > > > > > > > > > > > > Since ISP interfaces may have access to private > > > > > > > namespaces, those interfaces (along with their > > > > > > > associated IP addresses) can be chosen for DNS > > > > > > > resolution and for accessing services within the > > > > > > > private namespace the same as described in the mif > > > > > > > documents. Since the IRON Internet interface has > > > > > > > a non-volatile configuration on the open Internet, > > > > > > > however, it provides a stable handle for default > > > > > > > communications with Internet-based correspondents. > > > > > > > > > > > > > > Again, this is all very compatible with the mif > > > > > > > work, and fits like a glove with what IRON expects. > > > > > > > > > > > > > > Thanks - Fred > > > > > > > fred.l.templin@boeing.com > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Andrew Sullivan [mailto:ajs@anvilwalrusden.com] > > > > > > > > Sent: Monday, November 28, 2011 10:11 AM > > > > > > > > To: Templin, Fred L > > > > > > > > Cc: Hui Deng; Andrew Sullivan; mif@ietf.org > > > > > > > > Subject: Re: [mif] IRON as a multiple interface solution > > > > > > > > > > > > > > > > On Mon, Nov 28, 2011 at 09:22:45AM -0800, Templin, > > > > Fred L wrote: > > > > > > > > > That said, IRON does not preclude the host from > > accessing > > > > > > > > > services within the underlying ISP networks. To do so, > > > > > > > > > however, the host would have to use its ISP-delegated > > > > > > > > > address(es) and not the VSP-delegated address. > > > > > > > > > > > > > > > > > > Does this match your understanding? > > > > > > > > > > > > > > > > The central problem, however, is that if you are > > > > looking up the > > > > > > > > address for a name, you don't obviously know where it > > > > is (i.e. you > > > > > > > > don't know what network you need to go to). What I don't > > > > > > get in the > > > > > > > > IRON approach is how you cope with the fact that a user > > > > > > simply types > > > > > > > > some name into an application. We can't hardly ask them > > > > > > which network > > > > > > > > they want to use to look up the name. The MIF approach, > > > > > > as much as it > > > > > > > > makes me airsick, does address that issue. > > > > > > > > > > > > > > > > A > > > > > > > > > > > > > > > > -- > > > > > > > > Andrew Sullivan > > > > > > > > ajs@anvilwalrusden.com > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > mif mailing list > > > > > > > mif@ietf.org > > > > > > > https://www.ietf.org/mailman/listinfo/mif > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From maxpassion@gmail.com Wed Dec 21 09:13: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 1605B1F0C51 for ; Wed, 21 Dec 2011 09:13:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 lDfoxXWyMahR for ; Wed, 21 Dec 2011 09:13:10 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7CC891F0C4C for ; Wed, 21 Dec 2011 09:13:10 -0800 (PST) Received: by iaen33 with SMTP id n33so4152491iae.31 for ; Wed, 21 Dec 2011 09:13:10 -0800 (PST) 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=/n/30ZI9TE5VRF3BKDm2n3APbHK+afh4+zodYvFIxO8=; b=oYnyJOVSvQ6eoITGK+CvKf4TnMvwCssdlz9Iud+zZ+7fphLvADKobSV6ARahvxVd94 FNTbMIazab1rUZXT8YAH7LTViZxqjzwrO5p3G1t3WZ6xa04NVPsYrNViYsAJygDN6olN 8g5rObRC1SLirhrmnk29OqX8ViPOXrGqDwucE= MIME-Version: 1.0 Received: by 10.42.76.66 with SMTP id d2mr7899053ick.7.1324487590150; Wed, 21 Dec 2011 09:13:10 -0800 (PST) Received: by 10.43.50.1 with HTTP; Wed, 21 Dec 2011 09:13:08 -0800 (PST) In-Reply-To: <4EEF6714.40804@viagenie.ca> References: <4EEB70DF.3070201@viagenie.ca> <79DAA562-B463-4D11-A4E5-AEE1325531A0@nominum.com> <4EEF5278.8040103@viagenie.ca> <50824C2C-A4A8-4E92-A12D-45082B9CF5DC@nominum.com> <4EEF5D26.3080203@viagenie.ca> <0FECAD9E-E1EB-4849-BF8E-227F49975559@nominum.com> <4EEF6714.40804@viagenie.ca> Date: Thu, 22 Dec 2011 01:13:08 +0800 Message-ID: From: liu dapeng To: Simon Perreault Content-Type: text/plain; charset=ISO-8859-1 Cc: "" Subject: Re: [mif] Adoption of API document as the MIF WG 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: Wed, 21 Dec 2011 17:13:12 -0000 Hi Simon, 2011/12/20, Simon Perreault : > On 2011-12-19 11:24, Ted Lemon wrote: >> On Dec 19, 2011, at 10:49 AM, Simon Perreault wrote: >>> I just don't want the WG to see this document as something that allows us >>> to >>> place a "DONE" checkmark next to the API milestone. There is still API >>> work to >>> be done. >> >> Well, an easy fix for this is to add a milestone that addresses this >> concern. > > I'd be happy with that. Something like... > > 3) MIF API: While no changes are needed for applications to run on > multiple interface hosts, a new API could provide additional services > to applications running on hosts attached to multiple provisioning > domains. For instance, these services could assist advanced > applications in having greater control over first-hop, source address > and/or DNS selection issues. This API will be defined as an abstract > interface specification, i.e., specific details about mapping to > operating system primitives or programming language will be left out. > > 3.1) Low-level API: This API will specify base functionality that a > platform needs to make available for the high-level API to be possible. > It is intended to be used by applications for most tasks: that will be > the > high-level API's role. Applications could still call into the low-level > API > to perform complex, infrequent tasks. > > 3.2) High-level API: This API will specify functionality intended for > applications' frequent tasks. The term "high-level" means that it will > abstract the tasks that need to be perform and minimize an > application's > knowledge of a node's network configuration. It should be easy to use > and > appropriate for most of tasks commonly performed by applications. > > If the charter was modified to something like the above then I'd change my > position to "support"... I am not sure what exactly the meaning of the "High-level API" here. Since current API draft also "sepcify functionality intended for applications's frequent tasks " and "abstract the tasks that need to be perform" since we are not defining concrete API here. regards, Dapeng > Simon > -- > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif > -- ------ Best Regards, Dapeng Liu From Fred.L.Templin@boeing.com Wed Dec 21 09:13: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 7FE331F0C57 for ; Wed, 21 Dec 2011 09:13:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 5kyHHtIfhedM for ; Wed, 21 Dec 2011 09:13:50 -0800 (PST) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by ietfa.amsl.com (Postfix) with ESMTP id 6E5601F0C4C for ; Wed, 21 Dec 2011 09:13:50 -0800 (PST) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by stl-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id pBLHE2PW009961 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 21 Dec 2011 11:14:04 -0600 (CST) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id pBLHDe9P024712; Wed, 21 Dec 2011 09:13:40 -0800 (PST) Received: from XCH-NWHT-06.nw.nos.boeing.com (xch-nwht-06.nw.nos.boeing.com [130.247.25.110]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id pBLHDeEL024687 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Wed, 21 Dec 2011 09:13:40 -0800 (PST) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-06.nw.nos.boeing.com ([130.247.25.110]) with mapi; Wed, 21 Dec 2011 09:13:39 -0800 From: "Templin, Fred L" To: Hui Deng , "'Andrew Sullivan'" Date: Wed, 21 Dec 2011 09:13:39 -0800 Thread-Topic: [mif] IRON as a multiple interface solution Thread-Index: Acyt+SVzR1PpkUYRTvCp3A+bmVJOzQCYBPHAAB446gAAD8Pa0AKEviEwANQukcAAGomgYAAaRdXgACBYkTAADaDnIA== Message-ID: References: <4EC5B720.8020605@gmail.com> <83A7D27A-9036-4252-AC94-3A89125C961B@nominum.com> <4EC63ECC.8010700@gmail.com> <20111119220355.GA893@shinkuro.com> <20111128181115.GC45293@shinkuro.com> <01da01ccb0d2$72f6f630$58e4e290$@com> <01ee01ccbb24$48fb0950$daf11bf0$@com> <008b01ccbedf$c5cb9620$5162c260$@com> <00a001ccbfc9$b119ede0$134dc9a0$@com> In-Reply-To: <00a001ccbfc9$b119ede0$134dc9a0$@com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mif@ietf.org" Subject: Re: [mif] IRON as a multiple interface solution 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, 21 Dec 2011 17:13:51 -0000 Hi Hui, I'll look into the scenarios and PS, but I'll add another thought before the holidays. IRON addresses the commercial aviation use case, but people don't seem to realize that modern airplanes are the ultimate MIF nodes. Airplanes today can have as many as 20 antennas. Not all of them support IP links, but many do and more are coming in the near future. Moreover, links come and go according to phase of flight. At the gate, the plane can expect WiFi and possibly wired-line links. In the terminal maneuvering area there is WiMAX (and a coming aviation derivative known as AeroMACS). Once airbore, VHF, 3G/4G, SATCOM, etc. become available. And, SATCOM and HF are often the only options available over the oceans and polar regions. So, the planes needs a way to manage this dynamically changing collection of links and still be reachable by correspondents such as airline operations and air traffic control. IRON provides a means to do exactly that, but its applicability extends far beyond just the aviation domain and can address any MIF use cases that I can imagine (including 3GPP and BBF). I will explain this further after the holidays. Thanks - Fred fred.l.templin@boeing.com =20 > -----Original Message----- > From: Hui Deng [mailto:denghui@chinamobile.com]=20 > Sent: Wednesday, December 21, 2011 2:17 AM > To: Templin, Fred L; 'Andrew Sullivan' > Cc: mif@ietf.org > Subject: RE: [mif] IRON as a multiple interface solution >=20 > Hi Fred >=20 > Current MIF is discussing 3GPP and BBF scenarios and problems, > If IRON is a new architecture, then it need to clarify which=20 > scenario and PS > that IRON is targeting at. >=20 > Thanks >=20 > -Hui >=20 > > -----Original Message----- > > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] > > Sent: Wednesday, December 21, 2011 3:10 AM > > To: Hui Deng; 'Andrew Sullivan' > > Cc: mif@ietf.org > > Subject: RE: [mif] IRON as a multiple interface solution > >=20 > > Hi Hui, > >=20 > > > -----Original Message----- > > > From: Hui Deng [mailto:denghui@chinamobile.com] > > > Sent: Monday, December 19, 2011 10:23 PM > > > To: Templin, Fred L; 'Andrew Sullivan' > > > Cc: mif@ietf.org > > > Subject: RE: [mif] IRON as a multiple interface solution > > > > > > Hi Fred > > > > > > There are multiple places discussing virtual interface(PMIP6, > > > DSMIP6, 3GPP > > > GTP, Connection Manager et al.), > >=20 > > Yes, virtual interfaces have been discussed in many contexts > > for many, many years. But, the virtual interface described in > > IRON is uniquely different. > >=20 > > The virtual interface described in IRON is an NBMA interface > > that views other IRON nodes as on-link neighbors. Neighbor > > coordinations such as neighbor/router discovery, NUD, > > redirection, etc. are therefore supported. > >=20 > > IRON also uniquely solves the well known virtual interface > > path MTU problem, and this is especially important for MIF > > nodes that connect to diverse L2 media. > >=20 > > I have also already mentioned the ability to have a > > persistent L3 configuration on the IRON virtual interface > > even if the L3 configurations on the ISP interfaces change > > dynamically. This provides significant benefits for mobility, > > mobile networks, session survivability, etc. The document > > also mentions several other compelling functions applicable > > to MIF nodes that are enabled. > >=20 > >=20 > > > I don't know whether IETF is interested in documenting such > > > implementation, > > > Internet Area maybe the right place to discuss it. > >=20 > > IRON is not an implementation; it is an architecture. > > Its functional components are VET, SEAL and AERO, which > > deal with specific aspects of concern to the MIF problem > > space. The four documents (IRON, VET, SEAL and AERO) go > > together as a group. > >=20 > > Thanks - Fred > > fred.l.templin@boeing.com > >=20 > > > Thanks > > > > > > -Hui > > > > -----Original Message----- > > > > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] > > > > Sent: Tuesday, December 20, 2011 1:44 AM > > > > To: Hui Deng; 'Andrew Sullivan' > > > > Cc: mif@ietf.org > > > > Subject: RE: [mif] IRON as a multiple interface solution > > > > > > > > Hi Hui, > > > > > > > > > -----Original Message----- > > > > > From: Hui Deng [mailto:denghui@chinamobile.com] > > > > > Sent: Thursday, December 15, 2011 4:23 AM > > > > > To: Templin, Fred L; 'Andrew Sullivan' > > > > > Cc: mif@ietf.org > > > > > Subject: RE: [mif] IRON as a multiple interface solution > > > > > > > > > > Hi Fred, > > > > > > > > > > This new interface type is also a kind of virtual interface > > > > > which has been > > > > > mentioned in RFC 6418. > > > > > > > > Yes, I see where virtual interfaces are mentioned in > > > > several places in RFC6418. However, that document talks > > > > about the virtual interface *near-end* and does not talk > > > > about the virtual link itself nor coordination with the > > > > virtual interface *far-end(s)*. > > > > > > > > RFC6418, Section 3.8 is consistent with what the IRON > > > > virtual interface near end expects, but IRON goes to > > > > the full extent of describing coordinations between > > > > the near end and any prospective far-ends. > > > > > > > > Thanks - Fred > > > > fred.l.templin@boeing.com > > > > > > > > > -Hui > > > > > > > > > > > -----Original Message----- > > > > > > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] > > > > > > Sent: Saturday, December 03, 2011 12:56 AM > > > > > > To: Hui Deng; 'Andrew Sullivan' > > > > > > Cc: mif@ietf.org > > > > > > Subject: RE: [mif] IRON as a multiple interface solution > > > > > > > > > > > > Hi Hui, > > > > > > > > > > > > I am saying that IRON defines a new interface type > > > > > > that would be one among possibly many interfaces of > > > > > > a mif node. The properties of this interface type > > > > > > include: > > > > > > > > > > > > - maintains stable network layer addresses even > > > > > > if ISP connections change > > > > > > - supports session continutity and fault tolerance > > > > > > as ISP connections change > > > > > > - avoids end user network renumbering when ISP > > > > > > connections change in case the mif node acts > > > > > > as a router > > > > > > > > > > > > There is more to it than just this, but the IRON > > > > > > interface is another mif node interface type and > > > > > > therefore needs to be taken under consideration, > > > > > > e.g., for interface selection, source address > > > > > > selection, etc. > > > > > > > > > > > > Thanks - Fred > > > > > > fred.l.templin@boeing.com > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Hui Deng [mailto:denghui@chinamobile.com] > > > > > > > Sent: Friday, December 02, 2011 1:12 AM > > > > > > > To: Templin, Fred L; 'Andrew Sullivan' > > > > > > > Cc: mif@ietf.org > > > > > > > Subject: RE: [mif] IRON as a multiple interface solution > > > > > > > > > > > > > > Hi Fred > > > > > > > > > > > > > > You are saying current MIF document is compatible=20 > with IRON. > > > > > > > And current MIF document has already solved MIF's issues, > > > > > > > so guess that IRON is proposing something else=20 > like generic > > > > > > > internet access > > > > > > > which is out of MIF. > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > -Hui > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: mif-bounces@ietf.org=20 > [mailto:mif-bounces@ietf.org] On > > > > > > > Behalf Of > > > > > > > > Templin, Fred L > > > > > > > > Sent: Friday, December 02, 2011 4:10 AM > > > > > > > > To: Andrew Sullivan > > > > > > > > Cc: mif@ietf.org > > > > > > > > Subject: Re: [mif] IRON as a multiple interface solution > > > > > > > > > > > > > > > > Hi Andrew, > > > > > > > > > > > > > > > > I took the time to go off and look at the mif wg > > > > > > > > documents. All of it is good work - and all of it > > > > > > > > is compatible with IRON. > > > > > > > > > > > > > > > > The mif documents talk about two primary classes of > > > > > > > > interfaces: 1) ISP interfaces, and 2) VPN interfaces. > > > > > > > > IRON introduces a third class of interface which > > > > > > > > can be considered an "Internet interface". > > > > > > > > > > > > > > > > While it is true that most ISP interfaces provide > > > > > > > > access to the Internet, ISP interfaces have volatile > > > > > > > > configuration information that can change, e.g., if > > > > > > > > the ISP point of connection changes. Conversely, the > > > > > > > > IRON Internet interface has non-volatile configuration > > > > > > > > information that remains the same even if the ISP > > > > > > > > connections change (e.g., if the node is mobile). > > > > > > > > > > > > > > > > Since ISP interfaces may have access to private > > > > > > > > namespaces, those interfaces (along with their > > > > > > > > associated IP addresses) can be chosen for DNS > > > > > > > > resolution and for accessing services within the > > > > > > > > private namespace the same as described in the mif > > > > > > > > documents. Since the IRON Internet interface has > > > > > > > > a non-volatile configuration on the open Internet, > > > > > > > > however, it provides a stable handle for default > > > > > > > > communications with Internet-based correspondents. > > > > > > > > > > > > > > > > Again, this is all very compatible with the mif > > > > > > > > work, and fits like a glove with what IRON expects. > > > > > > > > > > > > > > > > Thanks - Fred > > > > > > > > fred.l.templin@boeing.com > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Andrew Sullivan [mailto:ajs@anvilwalrusden.com] > > > > > > > > > Sent: Monday, November 28, 2011 10:11 AM > > > > > > > > > To: Templin, Fred L > > > > > > > > > Cc: Hui Deng; Andrew Sullivan; mif@ietf.org > > > > > > > > > Subject: Re: [mif] IRON as a multiple=20 > interface solution > > > > > > > > > > > > > > > > > > On Mon, Nov 28, 2011 at 09:22:45AM -0800, Templin, > > > > > Fred L wrote: > > > > > > > > > > That said, IRON does not preclude the host from > > > accessing > > > > > > > > > > services within the underlying ISP=20 > networks. To do so, > > > > > > > > > > however, the host would have to use its=20 > ISP-delegated > > > > > > > > > > address(es) and not the VSP-delegated address. > > > > > > > > > > > > > > > > > > > > Does this match your understanding? > > > > > > > > > > > > > > > > > > The central problem, however, is that if you are > > > > > looking up the > > > > > > > > > address for a name, you don't obviously know where it > > > > > is (i.e. you > > > > > > > > > don't know what network you need to go to). =20 > What I don't > > > > > > > get in the > > > > > > > > > IRON approach is how you cope with the fact=20 > that a user > > > > > > > simply types > > > > > > > > > some name into an application. We can't=20 > hardly ask them > > > > > > > which network > > > > > > > > > they want to use to look up the name. The=20 > MIF approach, > > > > > > > as much as it > > > > > > > > > makes me airsick, does address that issue. > > > > > > > > > > > > > > > > > > A > > > > > > > > > > > > > > > > > > -- > > > > > > > > > Andrew Sullivan > > > > > > > > > ajs@anvilwalrusden.com > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > mif mailing list > > > > > > > > mif@ietf.org > > > > > > > > https://www.ietf.org/mailman/listinfo/mif > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=20 >=20 > = From brian.e.carpenter@gmail.com Wed Dec 21 11:51:22 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 9FFFB11E80A3 for ; Wed, 21 Dec 2011 11:51:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.273 X-Spam-Level: X-Spam-Status: No, score=-103.273 tagged_above=-999 required=5 tests=[AWL=-0.126, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152, 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 9UUUbHCDNWmR for ; Wed, 21 Dec 2011 11:51:22 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id EB75E11E80B5 for ; Wed, 21 Dec 2011 11:51:21 -0800 (PST) Received: by eaak10 with SMTP id k10so795709eaa.31 for ; Wed, 21 Dec 2011 11:51:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=H6yT/hlb8/5YtAvNHKp99RFFSez95t2zhDRFLEdKZHY=; b=W+dlireMY8Qj+7xnpxWeaDWnTw4qp0GElgyfzZT4sa/FfbajqUxkGIMd2O4t8Ucbiq fzccH2JTsxdzFn9D6z0vgKGouviN5E2Ztjw3oiKnla5nKwnmRmuwpQtqoGNyc5duPlur jSHd0UPWWWyCL4S4WWkSVIMTcpxPUYcTL+wF0= Received: by 10.205.136.193 with SMTP id il1mr73063bkc.77.1324497080165; Wed, 21 Dec 2011 11:51:20 -0800 (PST) Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id d2sm13190472bky.11.2011.12.21.11.51.16 (version=SSLv3 cipher=OTHER); Wed, 21 Dec 2011 11:51:18 -0800 (PST) Message-ID: <4EF238AD.3070209@gmail.com> Date: Thu, 22 Dec 2011 08:51:09 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: zhou.sujing@zte.com.cn References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: mif@ietf.org Subject: Re: [mif] =?utf-8?b?562U5aSNOiBSRTogIGEgcXVlc3Rpb24gYWJvdXQgcmZjNjQx?= =?utf-8?q?8?= 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, 21 Dec 2011 19:51:22 -0000 This is an English error; the "not" should have been removed during editi= ng. I understand the origin of the error if the author was francophone. I suggest using http://www.rfc-editor.org/errata.php Regards Brian Carpenter On 2011-12-21 22:45, zhou.sujing@zte.com.cn wrote: > until the user has NOT authenticated? >=20 >=20 > Regards~~~ >=20 > -Sujing Zhou >=20 > =E5=86=99=E4=BA=8E 2011-12-21 17:42:34: >=20 >> Hi, >> >> Nothing particular, this sentence reflects what the user is=20 >> currently experiencing when getting access via a captive portal. >> >> Pierrick >> >> De : mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part de >> zhou.sujing@zte.com.cn >> Envoy=C3=A9 : mercredi 21 d=C3=A9cembre 2011 10:38 >> =C3=80 : mif@ietf.org >> Objet : [mif] a question about rfc6418 >> >> >> in Section 4.4=20 >> >> The network requires a web-based authentication (e.g., the acces= s >> network is a WiFi hot spot). In this case, the user can only >> access a captive portal. For instance, the network may perform >> HTTP redirection or modify DNS behavior (Section 4.1) until the >> user has not authenticated. >> >> I am quite confused by the last word. Is it possible a typo or=20 >> something particular?=20 >> >> >> Regards~~~ >> >> -Sujing Zhou >> >> ----------------------------------------------------------------------= -- >> >> _______________________________________________ >> mif mailing list >> mif@ietf.org >> https://www.ietf.org/mailman/listinfo/mif From wwwrun@rfc-editor.org Wed Dec 21 16:06:52 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 CDA7411E80DA for ; Wed, 21 Dec 2011 16:06:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.323 X-Spam-Level: X-Spam-Status: No, score=-102.323 tagged_above=-999 required=5 tests=[AWL=0.277, BAYES_00=-2.599, NO_RELAYS=-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 fPEx15gSyZow for ; Wed, 21 Dec 2011 16:06:52 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 464F211E8096 for ; Wed, 21 Dec 2011 16:06:52 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 5A49F72E004; Wed, 21 Dec 2011 16:05:27 -0800 (PST) To: Marc.Blanchet@viagenie.ca, pierrick.seite@orange.com, rdroms.ietf@gmail.com, jari.arkko@piuha.net, mrw@lilacglade.org, denghui02@hotmail.com From: RFC Errata System Message-Id: <20111222000527.5A49F72E004@rfc-editor.org> Date: Wed, 21 Dec 2011 16:05:27 -0800 (PST) Cc: rfc-editor@rfc-editor.org, mif@ietf.org Subject: [mif] [Editorial Errata Reported] RFC6418 (3057) 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, 22 Dec 2011 00:06:53 -0000 The following errata report has been submitted for RFC6418, "Multiple Interfaces and Provisioning Domains Problem Statement". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6418&eid=3057 -------------------------------------- Type: Editorial Reported by: Zhou Sujing Section: 4.4 Original Text ------------- For instance, the network may perform HTTP redirection or modify DNS behavior (Section 4.1) until the user has not authenticated. Corrected Text -------------- For instance, the network may perform HTTP redirection or modify DNS behavior (Section 4.1) until the user has been authenticated. Notes ----- Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6418 (draft-ietf-mif-problem-statement-15) -------------------------------------- Title : Multiple Interfaces and Provisioning Domains Problem Statement Publication Date : November 2011 Author(s) : M. Blanchet, P. Seite Category : INFORMATIONAL Source : Multiple Interfaces Area : Internet Stream : IETF Verifying Party : IESG From wwwrun@rfc-editor.org Wed Dec 21 16:12:49 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 524A921F85EF for ; Wed, 21 Dec 2011 16:12:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.343 X-Spam-Level: X-Spam-Status: No, score=-102.343 tagged_above=-999 required=5 tests=[AWL=0.257, BAYES_00=-2.599, NO_RELAYS=-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 2iWeoDETg0kz for ; Wed, 21 Dec 2011 16:12:48 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id CAEAB21F85C7 for ; Wed, 21 Dec 2011 16:12:48 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 112A872E008; Wed, 21 Dec 2011 16:11:24 -0800 (PST) To: Marc.Blanchet@viagenie.ca, pierrick.seite@orange.com, rdroms.ietf@gmail.com, jari.arkko@piuha.net, mrw@lilacglade.org, denghui02@hotmail.com From: RFC Errata System Message-Id: <20111222001124.112A872E008@rfc-editor.org> Date: Wed, 21 Dec 2011 16:11:24 -0800 (PST) Cc: rfc-editor@rfc-editor.org, mif@ietf.org Subject: [mif] [Editorial Errata Reported] RFC6418 (3058) 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, 22 Dec 2011 00:12:49 -0000 The following errata report has been submitted for RFC6418, "Multiple Interfaces and Provisioning Domains Problem Statement". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6418&eid=3058 -------------------------------------- Type: Editorial Reported by: Zhou Sujing Section: 4. 1 Original Text ------------- Until the user has not authenticated When the user has not authenticated Corrected Text -------------- Until the user has been authenticated When the user has been authenticated Notes ----- Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6418 (draft-ietf-mif-problem-statement-15) -------------------------------------- Title : Multiple Interfaces and Provisioning Domains Problem Statement Publication Date : November 2011 Author(s) : M. Blanchet, P. Seite Category : INFORMATIONAL Source : Multiple Interfaces Area : Internet Stream : IETF Verifying Party : IESG From mrw@lilacglade.org Wed Dec 21 16:13:36 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 B394821F8A4E for ; Wed, 21 Dec 2011 16:13:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 0FHQcw94OqOF for ; Wed, 21 Dec 2011 16:13:36 -0800 (PST) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 425F121F89BA for ; Wed, 21 Dec 2011 16:13:36 -0800 (PST) Received: from [10.36.0.36] (pool-108-7-232-64.bstnma.fios.verizon.net [108.7.232.64]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by mail.suchdamage.org (Postfix) with ESMTPSA id C826720134; Wed, 21 Dec 2011 19:13:30 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Margaret Wasserman In-Reply-To: <20111222000527.5A49F72E004@rfc-editor.org> Date: Wed, 21 Dec 2011 19:13:37 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20111222000527.5A49F72E004@rfc-editor.org> To: RFC Errata System X-Mailer: Apple Mail (2.1084) Cc: mif@ietf.org, denghui02@hotmail.com Subject: Re: [mif] [Editorial Errata Reported] RFC6418 (3057) 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, 22 Dec 2011 00:13:36 -0000 This erratum looks right to me. I think we should accept it. Margaret On Dec 21, 2011, at 7:05 PM, RFC Errata System wrote: >=20 > The following errata report has been submitted for RFC6418, > "Multiple Interfaces and Provisioning Domains Problem Statement". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D6418&eid=3D3057 >=20 > -------------------------------------- > Type: Editorial > Reported by: Zhou Sujing >=20 > Section: 4.4 >=20 > Original Text > ------------- > For instance, the network may perform HTTP redirection or modify DNS = behavior (Section 4.1) until the user has not authenticated. >=20 >=20 >=20 > Corrected Text > -------------- > For instance, the network may perform HTTP redirection or modify DNS = behavior (Section 4.1) until the user has been authenticated. >=20 >=20 > Notes > ----- >=20 >=20 > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC6418 (draft-ietf-mif-problem-statement-15) > -------------------------------------- > Title : Multiple Interfaces and Provisioning Domains = Problem Statement > Publication Date : November 2011 > Author(s) : M. Blanchet, P. Seite > Category : INFORMATIONAL > Source : Multiple Interfaces > Area : Internet > Stream : IETF > Verifying Party : IESG From Ted.Lemon@nominum.com Wed Dec 21 16:23:08 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 DB65E11E80DE for ; Wed, 21 Dec 2011 16:23:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.41 X-Spam-Level: X-Spam-Status: No, score=-106.41 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 MFllcDt3rkmK for ; Wed, 21 Dec 2011 16:23:08 -0800 (PST) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by ietfa.amsl.com (Postfix) with ESMTP id 1C7A511E8081 for ; Wed, 21 Dec 2011 16:23:08 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKTvJ4agMkQCMEml7B4HmoFjuUYEh23QSr@postini.com; Wed, 21 Dec 2011 16:23:08 PST 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 3ADF01B82CE for ; Wed, 21 Dec 2011 16:23:06 -0800 (PST) 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 0A675190052; Wed, 21 Dec 2011 16:23:06 -0800 (PST) (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.0339.001; Wed, 21 Dec 2011 16:23:06 -0800 From: Ted Lemon To: Margaret Wasserman Thread-Topic: [mif] [Editorial Errata Reported] RFC6418 (3057) Thread-Index: AQHMwD2eZ1Girr6p6UCkMc7m0R6i7JXngrqAgAACpAA= Date: Thu, 22 Dec 2011 00:23:05 +0000 Message-ID: References: <20111222000527.5A49F72E004@rfc-editor.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_AE3B6A2080EA49C482D779EC93873445nominumcom_" MIME-Version: 1.0 Cc: "" , "" , RFC Errata System Subject: Re: [mif] [Editorial Errata Reported] RFC6418 (3057) 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, 22 Dec 2011 00:23:09 -0000 --_000_AE3B6A2080EA49C482D779EC93873445nominumcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Dec 21, 2011, at 7:13 PM, Margaret Wasserman wrote: For instance, the network may perform HTTP redirection or modify DNS behavi= or (Section 4.1) until the user has not authenticated. Corrected Text -------------- For instance, the network may perform HTTP redirection or modify DNS behavi= or (Section 4.1) until the user has been authenticated. Isn't this talking about captive portals? If so, then *after* authenticat= ion you get unmodified DNS and HTTP; before authentication, you get forged = DNS responses that force you to the captive portal. --_000_AE3B6A2080EA49C482D779EC93873445nominumcom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
On Dec 21, 2011, at 7:13 PM, Margaret Wasserman wrote:
For instance, the network may perform HTTP redire= ction or modify DNS behavior (Section 4.1) until the user has not authentic= ated.



Corrected Text
--------------
For instance, the network may perform HTTP redire= ction or modify DNS behavior (Section 4.1) until the user has been authenti= cated.

Isn't this talking about captive portals?   If so, then *after* a= uthentication you get unmodified DNS and HTTP; before authentication, you g= et forged DNS responses that force you to the captive portal.

--_000_AE3B6A2080EA49C482D779EC93873445nominumcom_-- From pierrick.seite@orange.com Thu Dec 22 01:22:02 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 A812221F8AFE for ; Thu, 22 Dec 2011 01:22:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.023 X-Spam-Level: X-Spam-Status: No, score=-6.023 tagged_above=-999 required=5 tests=[AWL=-0.226, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_UTF8=0.152] 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 0pKpgbbVmNLU for ; Thu, 22 Dec 2011 01:22:02 -0800 (PST) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by ietfa.amsl.com (Postfix) with ESMTP id CE13C21F8A56 for ; Thu, 22 Dec 2011 01:22:01 -0800 (PST) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id D9CEAA4414A; Thu, 22 Dec 2011 10:23:25 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id CE9F2A44141; Thu, 22 Dec 2011 10:23:25 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 22 Dec 2011 10:21:59 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Thu, 22 Dec 2011 10:21:58 +0100 Message-ID: <843DA8228A1BA74CA31FB4E111A5C462021AB075@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <4EF238AD.3070209@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: =?utf-8?B?W21pZl0g562U5aSNOiBSRTogIGEgcXVlc3Rpb24gYWJvdXQg?= =?utf-8?B?cmZjNjQxOA==?= Thread-Index: AczAGf2B6HyDcPjPTwKZXxSY256MjAAcBnfg References: <4EF238AD.3070209@gmail.com> From: To: , X-OriginalArrivalTime: 22 Dec 2011 09:21:59.0606 (UTC) FILETIME=[284D8D60:01CCC08B] Cc: mif@ietf.org Subject: Re: [mif] =?utf-8?b?562U5aSNOiBSRTogIGEgcXVlc3Rpb24gYWJvdXQgcmZjNjQx?= =?utf-8?q?8?= 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, 22 Dec 2011 09:22:02 -0000 DQoNCj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+IERlwqA6IEJyaWFuIEUgQ2FycGVu dGVyIFttYWlsdG86YnJpYW4uZS5jYXJwZW50ZXJAZ21haWwuY29tXQ0KPiBFbnZvecOpwqA6IG1l cmNyZWRpIDIxIGTDqWNlbWJyZSAyMDExIDIwOjUxDQo+IMOAwqA6IHpob3Uuc3VqaW5nQHp0ZS5j b20uY24NCj4gQ2PCoDogU0VJVEUgUGllcnJpY2sgUkQtUkVTQS1SRU47IG1pZkBpZXRmLm9yZw0K PiBPYmpldMKgOiBSZTogW21pZl0g562U5aSNOiBSRTogYSBxdWVzdGlvbiBhYm91dCByZmM2NDE4 DQo+IA0KPiBUaGlzIGlzIGFuIEVuZ2xpc2ggZXJyb3I7IHRoZSAibm90IiBzaG91bGQgaGF2ZSBi ZWVuIHJlbW92ZWQgZHVyaW5nDQo+IGVkaXRpbmcuDQo+IA0KDQpSaWdodCwgdGhlIGNvcnJlY3Qg c2VudGVuY2UgaXMgIlVudGlsIHRoZSB1c2VyIGhhcyBhdXRoZW50aWNhdGVkIi4gVGhhbmtzIFpo b3UuIA0KDQo+IEkgdW5kZXJzdGFuZCB0aGUgb3JpZ2luIG9mIHRoZSBlcnJvciBpZiB0aGUgYXV0 aG9yIHdhcyBmcmFuY29waG9uZS4NCj4gDQoNClRoYXQncyB0aGUgcG9pbnQgOi0pIA0KDQo+IEkg c3VnZ2VzdCB1c2luZyBodHRwOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2VycmF0YS5waHANCj4gDQo+ IFJlZ2FyZHMNCj4gICAgQnJpYW4gQ2FycGVudGVyDQo+IA0KPiBPbiAyMDExLTEyLTIxIDIyOjQ1 LCB6aG91LnN1amluZ0B6dGUuY29tLmNuIHdyb3RlOg0KPiA+IHVudGlsIHRoZSB1c2VyIGhhcyBO T1QgYXV0aGVudGljYXRlZD8NCj4gPg0KPiA+DQo+ID4gUmVnYXJkc35+fg0KPiA+DQo+ID4gLVN1 amluZyBaaG91DQo+ID4NCj4gPiA8cGllcnJpY2suc2VpdGVAb3JhbmdlLmNvbT4g5YaZ5LqOIDIw MTEtMTItMjEgMTc6NDI6MzQ6DQo+ID4NCj4gPj4gSGksDQo+ID4+DQo+ID4+IE5vdGhpbmcgcGFy dGljdWxhciwgdGhpcyBzZW50ZW5jZSByZWZsZWN0cyB3aGF0IHRoZSB1c2VyIGlzDQo+ID4+IGN1 cnJlbnRseSBleHBlcmllbmNpbmcgd2hlbiBnZXR0aW5nIGFjY2VzcyB2aWEgYSBjYXB0aXZlIHBv cnRhbC4NCj4gPj4NCj4gPj4gUGllcnJpY2sNCj4gPj4NCj4gPj4gRGUgOiBtaWYtYm91bmNlc0Bp ZXRmLm9yZyBbbWFpbHRvOm1pZi1ib3VuY2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0DQo+IGRlDQo+ ID4+IHpob3Uuc3VqaW5nQHp0ZS5jb20uY24NCj4gPj4gRW52b3nDqSA6IG1lcmNyZWRpIDIxIGTD qWNlbWJyZSAyMDExIDEwOjM4DQo+ID4+IMOAIDogbWlmQGlldGYub3JnDQo+ID4+IE9iamV0IDog W21pZl0gYSBxdWVzdGlvbiBhYm91dCByZmM2NDE4DQo+ID4+DQo+ID4+DQo+ID4+ICAgICBpbiBT ZWN0aW9uIDQuNA0KPiA+Pg0KPiA+PiAgICAgICBUaGUgbmV0d29yayByZXF1aXJlcyBhIHdlYi1i YXNlZCBhdXRoZW50aWNhdGlvbiAoZS5nLiwgdGhlDQo+IGFjY2Vzcw0KPiA+PiAgICAgICBuZXR3 b3JrIGlzIGEgV2lGaSBob3Qgc3BvdCkuICBJbiB0aGlzIGNhc2UsIHRoZSB1c2VyIGNhbiBvbmx5 DQo+ID4+ICAgICAgIGFjY2VzcyBhIGNhcHRpdmUgcG9ydGFsLiAgRm9yIGluc3RhbmNlLCB0aGUg bmV0d29yayBtYXkNCj4gcGVyZm9ybQ0KPiA+PiAgICAgICBIVFRQIHJlZGlyZWN0aW9uIG9yIG1v ZGlmeSBETlMgYmVoYXZpb3IgKFNlY3Rpb24gNC4xKSB1bnRpbA0KPiB0aGUNCj4gPj4gICAgICAg dXNlciBoYXMgbm90IGF1dGhlbnRpY2F0ZWQuDQo+ID4+DQo+ID4+ICAgIEkgYW0gcXVpdGUgY29u ZnVzZWQgYnkgdGhlIGxhc3Qgd29yZC4gSXMgaXQgcG9zc2libGUgYSB0eXBvIG9yDQo+ID4+IHNv bWV0aGluZyBwYXJ0aWN1bGFyPw0KPiA+Pg0KPiA+Pg0KPiA+PiBSZWdhcmRzfn5+DQo+ID4+DQo+ ID4+IC1TdWppbmcgWmhvdQ0KPiA+Pg0KPiA+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiAtLS0tDQo+ID4+DQo+ ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+ IG1pZiBtYWlsaW5nIGxpc3QNCj4gPj4gbWlmQGlldGYub3JnDQo+ID4+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vbWlmDQoNCg== From pierrick.seite@orange.com Thu Dec 22 01:24:28 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 20D4C21F8B7C for ; Thu, 22 Dec 2011 01:24:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.204 X-Spam-Level: X-Spam-Status: No, score=-6.204 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] 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 rSsbuPfVRclb for ; Thu, 22 Dec 2011 01:24:27 -0800 (PST) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by ietfa.amsl.com (Postfix) with ESMTP id 2A5FB21F8B7B for ; Thu, 22 Dec 2011 01:24:27 -0800 (PST) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 95CE9A44141; Thu, 22 Dec 2011 10:25:52 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id 87057A440AE; Thu, 22 Dec 2011 10:25:52 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 22 Dec 2011 10:24:26 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 22 Dec 2011 10:24:24 +0100 Message-ID: <843DA8228A1BA74CA31FB4E111A5C462021AB078@ftrdmel0.rd.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Editorial Errata Reported] RFC6418 (3057) Thread-Index: AczAPqDbBVVR7bagTnOOqgtlFUBvbgATKAOg References: <20111222000527.5A49F72E004@rfc-editor.org> From: To: , X-OriginalArrivalTime: 22 Dec 2011 09:24:26.0416 (UTC) FILETIME=[7FCEFB00:01CCC08B] Cc: mif@ietf.org, denghui02@hotmail.com Subject: Re: [mif] [Editorial Errata Reported] RFC6418 (3057) 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, 22 Dec 2011 09:24:28 -0000 I agree. Pierrick > -----Message d'origine----- > De=A0: Margaret Wasserman [mailto:mrw@lilacglade.org] > Envoy=E9=A0: jeudi 22 d=E9cembre 2011 01:14 > =C0=A0: RFC Errata System > Cc=A0: Marc.Blanchet@viagenie.ca; SEITE Pierrick RD-RESA-REN; > rdroms.ietf@gmail.com; jari.arkko@piuha.net; denghui02@hotmail.com; > zhou.sujing@zte.com.cn; mif@ietf.org > Objet=A0: Re: [Editorial Errata Reported] RFC6418 (3057) >=20 >=20 > This erratum looks right to me. I think we should accept it. >=20 > Margaret >=20 >=20 > On Dec 21, 2011, at 7:05 PM, RFC Errata System wrote: >=20 > > > > The following errata report has been submitted for RFC6418, > > "Multiple Interfaces and Provisioning Domains Problem Statement". > > > > -------------------------------------- > > You may review the report below and at: > > http://www.rfc-editor.org/errata_search.php?rfc=3D6418&eid=3D3057 > > > > -------------------------------------- > > Type: Editorial > > Reported by: Zhou Sujing > > > > Section: 4.4 > > > > Original Text > > ------------- > > For instance, the network may perform HTTP redirection or modify DNS > behavior (Section 4.1) until the user has not authenticated. > > > > > > > > Corrected Text > > -------------- > > For instance, the network may perform HTTP redirection or modify DNS > behavior (Section 4.1) until the user has been authenticated. > > > > > > Notes > > ----- > > > > > > Instructions: > > ------------- > > This errata is currently posted as "Reported". If necessary, please > > use "Reply All" to discuss whether it should be verified or > > rejected. When a decision is reached, the verifying party (IESG) > > can log in to change the status and edit the report, if necessary. > > > > -------------------------------------- > > RFC6418 (draft-ietf-mif-problem-statement-15) > > -------------------------------------- > > Title : Multiple Interfaces and Provisioning Domains > Problem Statement > > Publication Date : November 2011 > > Author(s) : M. Blanchet, P. Seite > > Category : INFORMATIONAL > > Source : Multiple Interfaces > > Area : Internet > > Stream : IETF > > Verifying Party : IESG From simon.perreault@viagenie.ca Thu Dec 22 06:05:59 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 B088321F8AC9 for ; Thu, 22 Dec 2011 06:05:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.475 X-Spam-Level: X-Spam-Status: No, score=-2.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599] 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 4C950qQJ7bYy for ; Thu, 22 Dec 2011 06:05:59 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by ietfa.amsl.com (Postfix) with ESMTP id 0ECF921F8ABB for ; Thu, 22 Dec 2011 06:05:59 -0800 (PST) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 64B8E21CC2; Thu, 22 Dec 2011 09:05:28 -0500 (EST) Message-ID: <4EF33927.6000306@viagenie.ca> Date: Thu, 22 Dec 2011 09:05:27 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111115 Thunderbird/8.0 MIME-Version: 1.0 To: Ted Lemon References: <20111222000527.5A49F72E004@rfc-editor.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "" , "" Subject: Re: [mif] [Editorial Errata Reported] RFC6418 (3057) 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, 22 Dec 2011 14:05:59 -0000 On 2011-12-21 19:23, Ted Lemon wrote: > Isn't this talking about captive portals? If so, then *after* authentication you > get unmodified DNS and HTTP; before authentication, you get forged DNS responses > that force you to the captive portal. Just for the sake of discussion... Captive portals that modify DNS responses are exceedingly rare. Usually, captive portals work by NATing the destination address of packets emitted from clients having an unauthenticated link-layer addresses. The reason, I presume, is that DNS responses get cached by the OS and/or application, so sending "wrong" DNS responses to clients just doesn't work well. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From pierrick.seite@orange.com Thu Dec 22 06:10: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 0984A21F8B43 for ; Thu, 22 Dec 2011 06:10:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] 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 7-pNIIDMIoCm for ; Thu, 22 Dec 2011 06:10:40 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by ietfa.amsl.com (Postfix) with ESMTP id F204321F8B3C for ; Thu, 22 Dec 2011 06:10:39 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id C1938E304B3; Thu, 22 Dec 2011 15:21:33 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id B9664E30498; Thu, 22 Dec 2011 15:21:33 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 22 Dec 2011 15:10:35 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 22 Dec 2011 15:10:34 +0100 Message-ID: <843DA8228A1BA74CA31FB4E111A5C462021AB120@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <4EF33927.6000306@viagenie.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MIF] captive portal was RE: [mif] [Editorial Errata Reported] RFC6418 (3057) Thread-Index: AczAstaJNyGaxm7CT1+dtGUFTQHbNwAADOHw References: <20111222000527.5A49F72E004@rfc-editor.org> <4EF33927.6000306@viagenie.ca> From: To: , X-OriginalArrivalTime: 22 Dec 2011 14:10:35.0295 (UTC) FILETIME=[794202F0:01CCC0B3] Cc: denghui02@hotmail.com, mif@ietf.org Subject: [mif] [MIF] captive portal was RE: [Editorial Errata Reported] RFC6418 (3057) 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, 22 Dec 2011 14:10:41 -0000 > -----Message d'origine----- > De=A0: mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part = de > Simon Perreault > Envoy=E9=A0: jeudi 22 d=E9cembre 2011 15:05 > =C0=A0: Ted Lemon > Cc=A0: ; > Objet=A0: Re: [mif] [Editorial Errata Reported] RFC6418 (3057) >=20 > On 2011-12-21 19:23, Ted Lemon wrote: > > Isn't this talking about captive portals? If so, then *after* > authentication you > > get unmodified DNS and HTTP; before authentication, you get forged > DNS responses > > that force you to the captive portal. >=20 > Just for the sake of discussion... >=20 > Captive portals that modify DNS responses are exceedingly rare. > Usually, captive > portals work by NATing the destination address of packets emitted from > clients > having an unauthenticated link-layer addresses.=20 I'm not an expert in captive portals but I think NAT based solution is = as rare as DNS based :-) Captive portal are usually based on HTTP = redirection. Pierrick The reason, I presume, > is that > DNS responses get cached by the OS and/or application, so sending > "wrong" DNS > responses to clients just doesn't work well. >=20 > Simon > -- > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif From marc.blanchet@viagenie.ca Thu Dec 22 06:19: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 5EB0B21F86B3 for ; Thu, 22 Dec 2011 06:19:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.589 X-Spam-Level: X-Spam-Status: No, score=-101.589 tagged_above=-999 required=5 tests=[AWL=1.010, 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 odVNfbOpv+yp for ; Thu, 22 Dec 2011 06:19:03 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by ietfa.amsl.com (Postfix) with ESMTP id BCF3121F86AA for ; Thu, 22 Dec 2011 06:19:03 -0800 (PST) Received: from [IPv6:2607:fa48:6e6b:c280:ddf4:d3a4:3482:54bb] (unknown [IPv6:2607:fa48:6e6b:c280:ddf4:d3a4:3482:54bb]) by jazz.viagenie.ca (Postfix) with ESMTPSA id E5E8A21F07; Thu, 22 Dec 2011 09:18:31 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Marc Blanchet In-Reply-To: <843DA8228A1BA74CA31FB4E111A5C462021AB120@ftrdmel0.rd.francetelecom.fr> Date: Thu, 22 Dec 2011 09:18:31 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <1562467B-392E-464F-9286-B870E976B3ED@viagenie.ca> References: <20111222000527.5A49F72E004@rfc-editor.org> <4EF33927.6000306@viagenie.ca> <843DA8228A1BA74CA31FB4E111A5C462021AB120@ftrdmel0.rd.francetelecom.fr> To: X-Mailer: Apple Mail (2.1251.1) Cc: mif@ietf.org, denghui02@hotmail.com Subject: Re: [mif] [MIF] captive portal was RE: [Editorial Errata Reported] RFC6418 (3057) 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, 22 Dec 2011 14:19:04 -0000 Le 2011-12-22 =E0 09:10, a =E9crit : >=20 >=20 >> -----Message d'origine----- >> De : mif-bounces@ietf.org [mailto:mif-bounces@ietf.org] De la part de >> Simon Perreault >> Envoy=E9 : jeudi 22 d=E9cembre 2011 15:05 >> =C0 : Ted Lemon >> Cc : ; >> Objet : Re: [mif] [Editorial Errata Reported] RFC6418 (3057) >>=20 >> On 2011-12-21 19:23, Ted Lemon wrote: >>> Isn't this talking about captive portals? If so, then *after* >> authentication you >>> get unmodified DNS and HTTP; before authentication, you get forged >> DNS responses >>> that force you to the captive portal. >>=20 >> Just for the sake of discussion... >>=20 >> Captive portals that modify DNS responses are exceedingly rare. >> Usually, captive >> portals work by NATing the destination address of packets emitted = from >> clients >> having an unauthenticated link-layer addresses.=20 >=20 > I'm not an expert in captive portals but I think NAT based solution is = as rare as DNS based :-) Captive portal are usually based on HTTP = redirection. that is also my understanding: HTTP redirection is widely used. Marc. >=20 > Pierrick >=20 > The reason, I presume, >> is that >> DNS responses get cached by the OS and/or application, so sending >> "wrong" DNS >> responses to clients just doesn't work well. >>=20 >> Simon >> -- >> DTN made easy, lean, and smart --> http://postellation.viagenie.ca >> NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca >> STUN/TURN server --> http://numb.viagenie.ca >> _______________________________________________ >> mif mailing list >> mif@ietf.org >> https://www.ietf.org/mailman/listinfo/mif > _______________________________________________ > mif mailing list > mif@ietf.org > https://www.ietf.org/mailman/listinfo/mif From simon.perreault@viagenie.ca Thu Dec 22 06:43: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 E75E321F8B2A for ; Thu, 22 Dec 2011 06:43:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.493 X-Spam-Level: X-Spam-Status: No, score=-2.493 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599] 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 3oR-UIac3nmn for ; Thu, 22 Dec 2011 06:43:12 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by ietfa.amsl.com (Postfix) with ESMTP id 89AB321F8B29 for ; Thu, 22 Dec 2011 06:43:12 -0800 (PST) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id B642721F07; Thu, 22 Dec 2011 09:42:41 -0500 (EST) Message-ID: <4EF341E1.3090709@viagenie.ca> Date: Thu, 22 Dec 2011 09:42:41 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111115 Thunderbird/8.0 MIME-Version: 1.0 To: Marc Blanchet References: <20111222000527.5A49F72E004@rfc-editor.org> <4EF33927.6000306@viagenie.ca> <843DA8228A1BA74CA31FB4E111A5C462021AB120@ftrdmel0.rd.francetelecom.fr> <1562467B-392E-464F-9286-B870E976B3ED@viagenie.ca> In-Reply-To: <1562467B-392E-464F-9286-B870E976B3ED@viagenie.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mif@ietf.org, denghui02@hotmail.com Subject: Re: [mif] [MIF] captive portal was RE: [Editorial Errata Reported] RFC6418 (3057) 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, 22 Dec 2011 14:43:17 -0000 On 2011-12-22 09:18, Marc Blanchet wrote: >> I'm not an expert in captive portals but I think NAT based solution is as rare as DNS based :-) Captive portal are usually based on HTTP redirection. > > that is also my understanding: HTTP redirection is widely used. NAT is not "rare", at least at the places I go I see it quite often, but you're right that HTTP redirection is very common, probably more than NAT. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca